예시 답변 1
약 90초
멀티 리전 배포 장애 허용 설계 결
멀티 리전 배포 구조를 처음 설계한 것은 클라우드 아키텍처 스터디에서 가용성 케이스 스터디로 다뤘을 때입니다. 단일 리전 장애가 서비스 전체에 영향을 주지 않도록 하려면, 트래픽을 여러 리전으로 분산하고 한 리전이 내려가도 다른 리전이 대신 처리하는 구조가 중요합니다. 글로벌 로드 밸런서를 앞단에 두고, 헬스체크 기반으로 비정상 리전을 자동 제외하는 방식을 설계했습니다.
DB 복제 전략도 중요한데, 활성-수동 방식은 장애 복구 시간이 있고, 활성-활성은 쓰기 충돌 관리가 복잡해집니다. RTO와 RPO 목표를 먼저 정의하는 것이 설계 방향을 결정하는 기준이 됐는데, 허용 가능한 다운타임과 데이터 손실 범위에 따라 아키텍처가 달라집니다. 한계는 실제 장애 상황에서 자동 복구가 의도대로 동작하는지를 직접 검증한 경험이 없다는 점입니다. 고가용성은 장애를 막는 것보다 장애 시 자동으로 복구되는 구조를 만드는 것이 결임을 배웠습니다.
이 결의 특징
단일 리전 장애가 전체 영향을 주지 않도록 글로벌 로드 밸런서 앞단에 두고 헬스체크 기반 자동 제외 구조를 설계한 고가용성 아키텍처가 드러납니다. RTO와 RPO를 설계 기준으로 명시한 의사결정이 목표 지향적이고, DB 복제 전략의 트레이드오프를 명확히 인식한 성숙함이 보입니다.
이 결이 통하는 자리
추상적 '가용성' 개념을 구체 수치 목표로 변환했을 때, 아키텍처 선택의 이유가 명확해지는 자리입니다.