고가용성·재해 복구

01

장애는 반드시 난다: 가용성 숫자와 단일 장애점

가용성은 서비스가 쓸 수 있는 상태였던 시간의 비율입니다. 99.9%는 꽤 높아 보이지만 1년으로 바꾸면 약 8시간 45분 멈춘다는 뜻입니다. 9가 하나 늘 때마다 허용되는 멈춤은 10분의 1로 줄고, 그만큼 비용과 설계가 어려워집니다.

이어 붙이면 낮아지고, 나란히 두면 높아진다

서비스는 여러 구성 요소가 이어져 있습니다. 웹 서버, 앱 서버, DB를 차례로 거쳐야 응답이 나간다면 셋이 모두 살아 있어야 합니다. 그래서 전체 가용성은 각 구성 요소 가용성의 곱입니다. 99.9%짜리 셋을 이으면 약 99.7%로 떨어집니다. 반대로 같은 서버를 두 대 나란히 두면 둘 다 멈춰야 멈추니 그 계층은 99.9999%까지 올라갑니다(두 대의 장애가 서로 독립이라고 가정할 때). 아래 그림에서 계층마다 두 대로 늘려 보세요.

하나만 멈춰도 전체가 멈추는 지점을 단일 장애점이라고 합니다. 고가용성 설계는 단일 장애점을 찾아 하나씩 없애는 일입니다. 서버만이 아닙니다. DB, 로드 밸런서, 네트워크 경로, 심지어 "이 서버의 설정을 아는 사람 한 명"도 단일 장애점일 수 있습니다.

SLA는 보장이 아니라 보상 약속

클라우드 서비스마다 SLA(서비스 수준 협약)로 월 가동률을 약속합니다. 그런데 SLA는 "반드시 이만큼 돌아간다"는 보장이 아니라, "못 지키면 요금 일부를 크레딧으로 돌려준다"는 약속입니다. 멈춘 시간의 손실을 메워 주지는 않으니, 내 서비스의 가용성은 설계로 만들어야 합니다. 같은 서비스라도 서버 한 대일 때보다 여러 영역에 나눠 둘 때 SLA가 더 높습니다.

단일 장애점을 없애려고 서버를 두 대로 늘렸습니다. 그런데 그 두 대가 같은 건물에 있다면 어떨까요?

02

장애의 크기: 서버, 영역, 리전

장애는 크기가 다릅니다. 서버 한 대의 디스크가 고장 나기도 하고, 데이터센터 한 곳이 정전·화재·네트워크 장애로 통째로 멈추기도 하며, 드물게 지역 전체가 자연재해나 대규모 장애로 멈추기도 합니다. 한 번의 장애가 영향을 미치는 범위를 장애 범위(blast radius)라고 합니다.

클라우드는 이 범위를 가용 영역과 리전으로 나눠 보여 줍니다. 리전은 서울·도쿄 같은 지역이고, 그 안에 전원·냉각·네트워크가 서로 독립된 데이터센터 묶음인 가용 영역이 여럿 있습니다. 영역끼리는 동기 복제가 될 만큼 가깝고(지연 몇 밀리초), 한 영역의 재해가 다른 영역에 번지지 않을 만큼은 떨어져 있습니다.

대부분의 운영 서비스는 여러 영역을 기본으로 합니다. 같은 리전 안이라 지연이 작아 DB를 동기 복제할 수 있고, 영역 장애까지 버팁니다. 리전 장애까지 버텨야 하는 경우(법·규제, 매우 큰 서비스)에만 여러 리전으로 넓히고, 그 방법이 7장의 재해 복구 전략입니다.

어디까지 버틸지 정하려면 먼저 목표가 있어야 합니다. 멈춰도 되는 시간과 잃어도 되는 데이터는 얼마일까요?

03

무엇을 얼마나 지킬지: RTO와 RPO

재해 복구를 설계할 때 가장 먼저 정하는 숫자가 둘 있습니다. RPO(복구 시점 목표)는 "장애가 났을 때 얼마만큼의 데이터를 잃어도 되는가"를 시간으로 적은 것이고, RTO(복구 시간 목표)는 "얼마나 오래 멈춰 있어도 되는가"입니다.

장애 시점을 가운데 두고 보면 쉽습니다. 뒤로 마지막으로 데이터를 지켜 둔 지점(마지막 백업이나 복제)까지가 잃는 데이터, 즉 RPO입니다. 앞으로 서비스를 다시 열 때까지가 멈춘 시간, 즉 RTO입니다. 아래 그림에서 데이터를 지키는 법과 되살리는 법을 바꿔 보세요.

두 목표는 기술이 아니라 사업이 정합니다. 주문 시스템은 1분만 멈춰도 손해가 크고 주문 하나도 잃으면 안 되지만, 사내 리포트 시스템은 하루 멈춰도 괜찮을 수 있습니다. 목표를 짧게 잡을수록 비용이 커지니, 시스템마다 손실과 비용을 따져 정합니다. 복구에 드는 비용이 장애로 잃는 것보다 크다면 그 목표는 너무 높게 잡은 것입니다.

목표를 정했으니 이제 멈추지 않게 만들 차례입니다. 먼저, 요청이 갑자기 몰릴 때 서버가 버티게 하는 법부터 봅니다.