가용 영역과 리전에 걸친 가용성 설계 선택하기

사용자 작업에서 시작하세요

고가용성인 HA는 구성 요소가 실패해도 서비스를 사용할 수 있게 유지하는 것을 목표로 합니다. 아키텍처를 선택하기 전에 사용 가능의 의미를 정하세요. 예약 페이지가 정상적으로 열려도 모든 예약 요청이 실패한다면 예약 서비스를 사용할 수 있는 것이 아닙니다.

중요한 작업에 대한 서비스 수준 목표인 SLO를 정하세요. 어떤 요청을 집계하고 성공이 무엇을 뜻하며 측정 기간이 얼마인지 정의하세요. 클라우드 서비스의 SLA는 해당 제공자의 약속을 설명합니다. 애플리케이션의 측정된 가용성을 입증하지는 않습니다.

예를 들어 시간 기준 가용성 99.9%는 30일인 한 달에 43.2분의 사용 불가 시간을 허용합니다. 요청 기준 SLO는 분모가 다릅니다. 어느 지표도 허용되는 데이터 손실량을 말하거나 개별 장애의 최대 시간을 보장하지 않습니다.

실패 경계를 이해하세요

AWS 가용 영역인 AZ는 리전 안의 격리된 인프라 위치입니다. 한 리전에는 여러 AZ가 있습니다. 멀티 리전 설계는 워크로드 구성 요소를 여러 리전에 분산합니다. 다른 제공자는 자체 경계와 서비스 동작을 갖고 있으므로 선택한 서비스를 살펴보세요.

이는 가능한 설계이지 가용성 보장이 아닙니다. 이름만으로 필요한 모든 구성 요소가 의도한 경계를 사용한다고 입증할 수는 없습니다.

전체 요청 경로를 추적하세요

가상의 예약 서비스를 생각해 보세요. 두 AZ에서 웹 복제본이 실행됩니다. 둘 다 AZ A의 데이터베이스 하나와 외부 연결 게이트웨이 하나를 사용합니다. 결제 제공자를 호출하려면 게이트웨이가 필요합니다.

AZ A가 실패하면 AZ B의 웹 복제본은 정상이어도 예약은 실패할 수 있습니다. 팀은 데이터베이스, 네트워크 경로, ID 제공자, 결제 의존성, 라우팅을 평가해야 합니다. 실제 관리형 데이터베이스의 모드를 살펴보세요. 복제, 장애 조치, 읽기 동작은 제품과 구성에 따라 다릅니다.

용량도 확인하세요. 남은 리소스가 필요한 부하를 처리해야 합니다. 사고 중에 용량을 추가하는 설계는 할당량, 가용 리소스, 제어 영역 작업에 의존합니다.

경계, 중지 조건, 담당자가 정해진 통제된 훈련을 수행하세요. 결제 대사를 포함한 전체 예약 과정을 검증하세요. 실패한 요청과 실제로 사용할 수 있는 운영 상태까지 복구하는 데 걸린 시간을 기록하세요.

다른 리전이 문제를 해결하는지 판단하세요

멀티 리전 운영은 데이터 전송, 중복 리소스, 배포 조율, 운영 작업을 추가합니다. 액티브/패시브는 한 환경이 트래픽을 받을 준비를 유지합니다. 액티브/액티브는 여러 환경에서 트래픽을 처리합니다. 필요한 준비 상태와 데이터 동작은 서로 다릅니다.

예약 서비스에서 동시 쓰기는 질문 하나를 만듭니다. 두 리전이 같은 좌석을 판매할 수 있을까요? 예약을 확정할 권한과 복제가 중단되었을 때의 동작을 정하세요. ‘데이터베이스를 복제한다’만으로는 충분한 답이 아닙니다.

허용된 데이터 위치, 암호화 키, 인증서, DNS, 비밀 정보, 외부 서비스를 확인하세요. 공통 ID 서비스의 장애나 잘못된 릴리스는 여러 리전에 영향을 줄 수 있습니다. 위치를 늘려도 모든 공통 원인이 사라지지는 않습니다.

가용성과 복구를 연결하세요

HA는 운영 중에 명시된 실패를 처리합니다. 재해 복구는 운영을 방해하는 사건 이후 사용 가능한 서비스와 데이터를 복원합니다. 멀티 리전 서비스에도 삭제나 데이터 손상에 대한 복구 계획이 필요합니다.

선택한 실패 시나리오와 비즈니스가 수용한 시나리오를 문서화하세요. 애플리케이션이 바뀔 때 테스트와 인프라 정의를 일치시키세요. RTO, RPO, 재해 복구에서 계속 학습하세요.