고가용성과 재해 복구 설계

고가용성과 재해 복구

한 데이터센터 안에서 완벽하게 이중화해도, 그 건물이 멈추면 아무 소용이 없다. HA와 DR은 따로 설계해야 한다. 노드 단위의 이중화 구조(주-백업, 주-보조, 리더 없는 복제)와 장애 감지는 고가용성 이중화 구조와 장애 감지에 있다.

목표부터 정한다: RTO와 RPO

RTO·RPO가 0에 가까울수록 비용과 복잡도는 가파르게 오른다. 그래서 모든 기능에 같은 목표를 주지 않는다. 메시지 전송·로그인·결제처럼 멈추면 안 되는 핵심 기능은 완전 다중화하고, 나머지는 기능별 목표 트래픽과 목표 복구 시간을 따로 정한다.

DR 전략 네 가지

오른쪽으로 갈수록 비용·복잡도는 낮음에서 높음으로, 복구 시간은 김에서 0에 가까움으로 바뀐다.

flowchart LR
  a["백업·복원"] --> b["파일럿 라이트"] --> c["웜 스탠바이"] --> d["멀티 사이트 액티브-액티브"]

전략별로 기대할 수 있는 RTO·RPO의 대략적인 범위는 다음과 같다. 실제 값은 자동화 수준과 데이터 동기화 주기로 정해진다.

전통적인 용어로는 대기 사이트를 콜드 사이트(cold site, 기본 인프라만 갖춘 두 번째 장소. 장애 때 장비를 켜고 데이터를 복원한다)와 핫 사이트(hot site, 늘 최신 데이터 사본을 유지해 바로 넘어간다)로 나눈다. 콜드 사이트는 싸지만 복구가 느리고, 핫 사이트는 구축·유지가 비싸지만 중단 시간이 크게 준다. 위 표에서 파일럿 라이트가 콜드 쪽, 웜·핫 스탠바이가 핫 쪽에 가깝다. 어느 쪽이든 재해의 영향을 받지 않는 다른 장소에 데이터와 처리 능력을 복제해 두는 것이 재해 복구의 바탕이다.

앞의 셋은 액티브-스탠바이(active/passive) 계열이다. 평소에는 주 사이트만 일하고, 장애 때 대기 사이트를 승격(promote) 한다. 대기 사이트를 운영 규모 그대로 켜 두되 트래픽은 주지 않는 형태는 핫 스탠바이라 부른다.

액티브-액티브에서 쓰기를 다루는 방법은 셋이다. 쓰기를 한 곳으로 모으는 write global, 가장 가까운 곳에 쓰고 마지막 쓰기가 이기게 하는 write local, 사용자 ID 같은 키로 쓰기 사이트를 나누는 write partitioned다. 어느 쪽이든 복제는 실수로 지운 데이터도 그대로 복제한다. 시점 복구(point-in-time) 백업은 따로 둔다.

모든 계층을 다중화한다

장애 범위를 키우는 것은 대개 아무도 다중화를 챙기지 않은 한 계층이다.

운영 도구가 가장 자주 빠진다

서비스는 다중화하면서 서비스를 복구하는 데 쓰는 도구는 한 곳에 두기 쉽다. 그러면 장애 때 이런 일이 생긴다.

• 모니터링·로그 시스템이 같이 죽어 무엇이 망가졌는지 보이지 않는다. 장애 구간 로그도 사라진다.
• VPN·사내 인증이 막혀 엔지니어가 서버에 들어가지 못한다.
• 배포 도구와 빌드 산출물 저장소가 없어 다른 센터에 서비스를 다시 띄우지 못한다.
• 클러스터 관리 도구가 없어 수백 대를 손으로 점검한다.

복구 경로에 있는 모든 것은 서비스와 같은 수준으로 다중화한다. 장애 중에는 고장 난 시스템을 고치는 것보다 다른 곳에 새로 구성하는 편이 빠른 경우가 많으므로, 재구성 도구와 IaC 코드가 어느 센터에서든 돌아야 한다. 클라우드에서는 같은 이유로 전환 절차를 설정을 바꾸는 컨트롤 플레인이 아니라 실제 트래픽을 처리하는 데이터 플레인 동작(헬스 체크 기반 DNS 전환 등)에 의존하게 만든다.

전환을 자동화하고 훈련한다

• 전환은 버튼 하나가 되게 만든다. 승격, DNS·GSLB 전환, 연결 문자열 변경을 스크립트로 묶는다. 수동으로 연결을 옮기는 플랫폼은 장애 때 가장 늦게 돌아온다.
• 자동 전환은 신중히 쓴다. 오탐으로 넘어가도 RTO·RPO만큼의 손실이 생기므로, 판단은 사람이 하고 실행은 자동으로 하는 구성이 흔하다.
• 실환경을 가정한 모의 훈련을 정기적으로 한다. 액티브-스탠바이의 승격은 해 보기 전까지 몇 분이 걸릴지 아무도 모른다. 전사 단위 시나리오(센터 하나 전체 차단)로 해 봐야 계층 간 빈틈이 드러난다.
• 백업은 복원해 봐야 백업이다. 복원을 주기적으로 실행해 시간을 잰다.
• 조직마다 다른 기준을 통일한다. 계층을 맡은 팀이 각자 다른 일정과 전략으로 이중화하면, 한 팀이 「센터 내 HA」에서 멈춘 곳이 전체의 약점이 된다. 공통 설계 기준을 거버넌스로 강제한다.

정리

• HA는 장비 고장, DR은 사이트 소멸에 대비한다. 둘은 따로 설계한다.
• RTO·RPO를 기능별로 정하고, 그에 맞춰 백업·파일럿 라이트·웜 스탠바이·액티브-액티브 중에서 고른다.
• 데이터 복제본은 센터 단위로 나눈다. 복제본 수보다 배치가 중요하다.
• 모니터링·인증·VPN·배포 도구처럼 복구에 쓰는 도구를 서비스와 같은 수준으로 다중화한다.
• 전환은 자동화하고, 실제처럼 훈련해서 검증한다. 해 보지 않은 전환은 동작하지 않는다고 가정한다.

관련 노트: 고가용성 이중화 구조와 장애 감지, AWS 클라우드 기초, 대규모 트래픽에서 서비스를 지키는 설계, 캐시 클러스터 운영과 장애 대응, 데이터베이스 모델: RDB, NoSQL, NewSQL, 트랜잭션과 회복, 스타트업 인프라 선택 원칙, 클라우드 SLA와 계약