Multi-AZ 고가용성 운영기 — 아키텍트 자격증이 묻는 리전 단위 재해 복구와의 거리

TL;DR

• 계기: AWS 아키텍트 자격증(SAP-C02)의 재해 복구 파트는 제가 몇 년간 운영한 고가용성 구조와 층위가 달랐습니다
• 시험이 묻는 범위: 다른 리전에 시스템을 통째로 하나 더 두는 멀티 리전 재해 복구
• 제가 한 것: 한 리전 안에서 두 가용영역(AZ)에 나눠 자동 페일오버까지. 멀티 리전은 안 해봤습니다
• 소득: 파일럿 라이트와 웜 스탠바이가 뭘 맞바꾸는 선택인지 정리됐습니다. 이전엔 이름만 알았습니다
• 한계: 리전 간 복제 지연이 실제로 얼마나 되는지, 장애 조치 중 데이터가 어긋나면 어떻게 수습하는지는 여전히 모릅니다

자동 페일오버가 도는 걸 처음 봤던 날

몇 년 전 협업툴 서비스를 운영할 때 얘기입니다. 하루 사용자가 십수만 명 규모였고 잠깐이라도 멈추면 바로 문의가 쏟아지는 서비스라 고가용성이 중요했습니다.

DB 페일오버가 실제로 도는 걸 처음 겪었을 때, 자동 승격은 분명히 됐습니다. 그런데 그 몇십 초 동안 커넥션이 끊기고 에러가 튀었습니다. 자동 페일오버는 무중단이 아니라 짧은 끊김 뒤의 자동 복구라는 걸 그때 알았습니다.

나중에 AWS 아키텍트 자격증(SAP-C02)을 준비하면서 이 장면이 다시 떠올랐습니다. 시험에서 RTO(복구까지 걸리는 시간)와 RPO(잃어도 되는 데이터의 시간 폭)는 이 시나리오에 맞는 값을 고르라는 객관식 숫자로 나옵니다. 저한테 그 숫자는 문서 위의 목표값이기 전에 새벽에 울리던 알림이었습니다. 그래서 이 문제들은 오히려 편했습니다. 걸린 건 그다음이었습니다.

1편에서 검색 이야기를 했으니, 이번엔 인프라 쪽입니다.

시험은 도시 하나가 통째로 꺼진 상황을 묻습니다

SAP-C02에서 재해 복구는 큰 비중을 차지합니다. 시험은 보통 이런 문제를 냅니다.

“리전 전체 장애가 발생해도 서비스가 몇 분 안에 복구되어야 한다. 비용은 합리적으로 유지하고 싶다. 어떤 재해 복구 전략이 적합한가?”

정답 후보로는 네 단계가 등장합니다. 백업 후 복구(Backup & Restore), 최소 구성만 켜두는 파일럿 라이트(Pilot Light), 축소판을 상시 돌리는 웜 스탠바이(Warm Standby), 양쪽을 다 살려두는 액티브-액티브(Multi-Site Active/Active). 여기에 RTO와 RPO로 어디까지 감수할지 저울질하게 합니다.

문제를 풀면서 계속 걸린 게 이겁니다. 이 전략들은 전부 리전 단위로 이야기합니다. 서울 리전이 통째로 죽으면 도쿄 리전이 받는 식입니다. 그런데 제가 실제로 운영해본 건 그 아래층, 한 리전 안의 이중화였습니다.

집으로 비유하면 이렇습니다. 시험이 묻는 멀티 리전 재해 복구는 다른 도시에 똑같은 집을 하나 더 지어두는 쪽입니다. 제가 한 건 한 집 안에서 두꺼비집을 두 개로 나눠, 한쪽이 나가도 다른 쪽으로 넘어가게 해둔 정도입니다. 무너져도 버티게 한다는 목표는 같은데 다루는 규모가 다릅니다.

제가 운영한 건 한 리전 안의 이중화였습니다

앞서 말한 협업툴 서비스는 인프라를 한 리전 안의 두 가용영역(AZ)에 나눠서 돌렸습니다. 가용영역은 물리적으로 떨어진 데이터센터라고 보면 됩니다. 한쪽 건물에 불이 나도 다른 건물이 받게 하는 구조입니다.

graph TB
    LB["로드밸런서<br/>트래픽 분산"]
    LB --> AZa
    LB --> AZc

    subgraph AZa["가용영역 A"]
        APPa["애플리케이션 서버"]
        DBa["DB 주"]
    end

    subgraph AZc["가용영역 C"]
        APPc["애플리케이션 서버"]
        DBc["DB 대기(자동 승격)"]
    end

    DBa -. "동기 복제" .-> DBc

• 로드밸런서를 Multi-AZ로 걸어 두 영역에 트래픽을 분산
• 관계형 DB를 Multi-AZ로 구성해 주 DB가 죽으면 대기 DB가 자동으로 승격(페일오버)
• 캐시와 메시지 큐도 두 영역에 걸친 클러스터로

한 영역이 통째로 나가도 다른 영역이 받아내도록 실제로 운영했습니다. 시험 용어로 하면 재해 복구(DR)보다는 고가용성(HA)에 가깝습니다. 리전이 죽는 상황까지는 아니고 리전 안의 한 구획이 죽는 상황을 막습니다.

여기서 정직하게 밝혀둡니다. 저는 멀티 리전은 운영해본 적이 없습니다. 단일 리전 안의 Multi-AZ까지가 제가 직접 손댄 범위입니다. 서울이 통째로 죽으면 도쿄가 받는다는 시험 속 상황은 저한테 겪은 일이 아니라 배운 지식입니다.

숫자 하나 뒤에 커넥션 풀 설정이 붙어 있었습니다

시험은 RTO를 몇 분 이내라는 목표값으로 깔끔하게 제시합니다. 실제로는 그 목표를 맞추려고 커넥션 풀 재시도 설정을 만지고, 헬스체크 주기를 조정하고, 페일오버 중에 쌓이는 요청을 어떻게 흘려보낼지 고민해야 했습니다. 숫자 하나 뒤에 이런 고민이 붙어 있다는 말은 문제집에 안 적혀 있었습니다.

반대 방향도 있습니다. 제가 안 해본 멀티 리전의 RTO·RPO는 저도 여전히 숫자로만 압니다. 리전 간 복제 지연이 실제로 얼마나 되는지, 장애 조치 중에 데이터가 어긋나면 어떻게 수습하는지는 겪어봐야 아는 영역입니다. Multi-AZ 쪽 숫자는 몸으로 알지만 멀티 리전 숫자는 아직 문서로만 압니다.

파일럿 라이트와 웜 스탠바이의 차이

Multi-AZ까지는 손에 익었지만 그 위층인 리전 단위 복구는 이름만 흐릿하게 알고 있었습니다. 시험을 준비하면서 이 부분이 정리됐습니다.

• 파일럿 라이트 vs 웜 스탠바이: 둘 다 다른 리전에 대비책을 두는 방식인데 평소에 얼마나 켜두느냐가 다릅니다. 비용과 복구 속도를 맞바꾸는 축으로 이해했습니다
• RTO/RPO를 비용과 엮는 사고: 빠른 복구가 비싸다는 건 당연하게 말하지만 어느 전략이 어느 RTO 구간에 맞는지는 시험이 표로 정리해줬습니다
• 글로벌 서비스로 확장할 때: 제 경험은 단일 리전에 갇혀 있었는데 사용자가 여러 대륙에 흩어지면 뭘 고려해야 하는지 처음 봤습니다

셋 다 “다른 리전에 얼마나 켜둘 것인가”를 비용과 맞바꾸는 선택이었습니다. 이렇게 한 축으로 정리되고 나니 그동안 왜 헷갈렸는지도 알겠더군요. 평소에 볼 일이 없으니 이름만 따로 외우고 있었던 겁니다.

페일오버를 한 번도 안 돌려봤다면

고가용성 구조를 운영하고 있거나 재해 복구 전략을 고르는 중이라면 아래를 짚어보면 됩니다.

• 지금 막고 있는 게 AZ 장애인가 리전 장애인가? (둘은 층위가 다르고 비용도 다름)
• DB 자동 페일오버 중의 짧은 끊김을 애플리케이션이 견디는가? (재시도·타임아웃 설정 확인)
• RTO·RPO를 숫자로만 정하고 실제 페일오버를 안 돌려본 건 아닌가?
• 멀티 리전이 정말 필요한가, 아니면 Multi-AZ로 충분한가? (필요 이상은 비용만 늘어남)
• 재해 복구 전략의 복구 절차를 한 번이라도 실제로 훈련해봤는가?

멀티 리전은 여전히 안 해본 채로 남았습니다

제가 해본 Multi-AZ 부분은 시험이 새로 알려준 게 거의 없었습니다. 페일오버가 도는 것도, 그 몇십 초 동안 에러가 튀는 것도 이미 봤기 때문입니다. 그런데 그 위층인 리전 단위 복구는 시험이 아니었으면 여전히 이름만 알고 넘어갔을 겁니다.

물론 이름을 안다고 해본 게 되진 않습니다. 멀티 리전을 실제로 굴리면 복제 지연이며 비용이며 제가 아직 모르는 함정이 잔뜩 나올 겁니다. 그건 그 규모를 다룰 일이 생겨야 알게 될 겁니다.

다음 편은 DevOps 자격증(DOP-C02)입니다. 밤새 혼자 도는 개인 시스템이 한밤중에 스스로 죽고 스스로 살아나는 이야기를, 시험이 다루는 배포·모니터링·자동 복구와 나란히 놓아보려 합니다.

읽어주셔서 감사합니다.🖐