복구 시간이 1분 미만인 가용성 99.999% 이상의 시나리오

애플리케이션의 이 가용성 목표를 달성하려면 가동 중단 시간이나 특정 시간에 손실되는 데이터가 거의 없어야 합니다. 이 가용성 목표를 설정할 수 있는 애플리케이션에는 특정 뱅킹, 투자, 금융, 정부 애플리케이션 및 매출 수준이 매우 높은 초대형 기업의 핵심 업무에 사용되는 중요한 비즈니스 애플리케이션이 포함됩니다. 이러한 목표를 달성하려면 모든 계층에서 항상 일정한 데이터 스토어와 완벽한 중복성을 갖춰야 합니다. 이 시나리오에서는 SQL 기반 데이터 스토어를 선택했습니다. 하지만 매우 짧은 RPO를 달성하기가 어려운 시나리오도 있습니다. 데이터를 분할할 수 있다면 데이터 손실을 방지할 수 있습니다. 단, 이 경우에는 여러 지리적 위치 간에 데이터 일관성이 유지되도록 애플리케이션 논리와 지연 시간을 추가해야 할 수 있으며, 파티션 간에 데이터를 이동하거나 복사하는 기능도 추가해야 할 수 있습니다. NoSQL 데이터베이스를 사용하는 경우 이 파티셔닝을 더 쉽게 수행할 수 있습니다.

여러 AWS 리전에서 활성/활성 방식을 사용하면 가용성을 더 높일 수 있습니다. 워크로드는 리전 간 정적 안정성 (한 리전이 손실될 경우 나머지 리전에서 로드를 처리할 수 있음)을 유지하는 원하는 모든 리전에 워크로드가 배포됩니다. A 라우팅 계층은 현재 정상 상태인 지리적 위치로 트래픽을 전송하고, 특정 위치가 비정상 상태가 되면 대상을 자동으로 변경하는 동시에 데이터 복제 계층을 일시적으로 중지합니다. Amazon Route 53에서는 10초 간격으로 상태 확인이 진행되며, 레코드 세트의 TTL도 매우 짧습니다(최저 1초부터).

리소스 모니터링

가용성 99.95% 시나리오와 동일하며 리전이 비정상인 것으로 감지되고 트래픽이 비정상 리전에서 먼 위치로 라우팅될 때 알림이 생성됩니다.

수요 변화에 맞게 구현 조정

가용성 99.95% 시나리오와 동일합니다.

변경 구현

배포 파이프라인에는 성능, 로드 및 장애 삽입 테스트를 비롯한 전체 테스트 집합이 포함됩니다. 이 시나리오에서는 Canary 또는 블루/그린 배포를 사용하여 한 번에 한 격리 영역에 업데이트를 배포합니다(한 리전에 업데이트를 배포한 후에 다음 리전으로의 배포를 시작함). 배포 중에는 롤백을 더 빠르게 수행할 수 있도록 이전 버전이 인스턴스에서 계속 실행됩니다. 이 과정은 완전히 자동화되며 KPI에서 문제가 확인되는 롤백 작업도 자동으로 수행됩니다. 모니터링에는 성공 지표와 문제 발생 시의 알림이 모두 포함됩니다.

런북은 엄격한 보고 요구 사항 및 성능 추적을 위해 사용됩니다. 정상적으로 진행된 작업에서 장애 발생 추세가 나타나는 경우에는 성능 또는 가용성 목표 충족을 위해 플레이북을 사용하여 해당 추세의 원인을 파악합니다. 플레이북은 검색되지 않은 장애 모드 및 보안 인시던트 확인용으로, 혹은 장애의 근본 원인 파악을 위해서 사용됩니다.

웹 사이트 개발 팀이 운영 또한 담당합니다. 해당 팀은 예기치 않은 장애를 발생시키는 오류 수정 사항을 확인하고, 해당 오류의 수정이 구현된 후 우선적으로 배포되도록 우선 순위를 지정합니다. 또한 Infrastructure Event Management와 관련하여 AWS Support에서 지원을 제공합니다.

데이터 백업

가용성 99.95% 시나리오와 동일합니다.

복원력을 위한 아키텍처 설계

애플리케이션은 소프트웨어/애플리케이션 복원력 패턴을 사용하여 빌드해야 합니다. 필요한 가용성을 구현하려면 기타 여러 라우팅 계층을 구현해야 할 수도 있습니다. 이 추가 구현은 복잡하므로 가용성 설계 시에 이 부분을 충분히 감안해야 합니다. 애플리케이션은 배포 결함 격리 영역에서 구현되며, 리전 전체에서 이벤트가 발생하더라도 모든 고객에게 영향을 주지는 않도록 분할/배포됩니다.

복원 기능 테스트

이 시나리오에서는 게임 데이를 통해 아키텍처를 확인합니다. 이때 런북을 사용하여 해당 절차를 준수하면서 작업을 수행할 수 있는지를 확인합니다.

DR(재해 복구) 계획

활성/활성 다중 리전 배포(전체 워크로드 인프라 및 데이터가 여러 리전에 배포됨). 로컬 읽기, 전역 쓰기 전략을 사용하면 한 리전이 모든 쓰기에 대한 기본 데이터베이스가 되고 데이터는 읽기 작업을 위해 다른 리전으로 복제됩니다. 기본 DB 리전에 장애가 발생하면 새 DB를 승격해야 합니다. 로컬 읽기, 전역 쓰기에서는 DB 쓰기가 처리되는 홈 리전에 사용자를 할당합니다. 따라서 사용자는 어느 리전에서든 읽거나 쓸 수 있지만, 서로 다른 리전에 있는 쓰기 간의 잠재적인 데이터 충돌을 관리하기 위한 복잡한 로직이 필요합니다.

리전이 비정상인 것으로 감지되면 라우팅 계층이 나머지 정상 리전으로 트래픽을 자동으로 라우팅합니다. 수동 개입은 필요하지 않습니다.

충돌 가능성을 해결할 수 있는 방식으로 리전 간에 데이터 스토어를 복제해야 합니다. 지연 시간을 단축하고 각 파티션에서 요청 수나 데이터 양의 균형을 유지할 수 있도록 파티션 간에 데이터를 복사하거나 이동하기 위한 도구와 자동화된 프로세스를 생성해야 합니다. 데이터 충돌을 해결하려면 추가 운영 런북도 필요합니다.

가용성 설계 목표

모든 복구를 자동화하기 위해 대규모 투자를 한 결과 1분 이내에 복구를 완료할 수 있다고 가정합니다. 그리고 복구는 수동으로 트리거되지 않으며 분기별로 자동 복구 작업이 1회까지만 수행된다고 가정합니다. 즉, 연간 복구 소요 시간은 4분입니다. 업데이트 과정 전반에 걸쳐 애플리케이션은 계속 온라인 상태라고 가정합니다. 이 가정을 토대로 할 때 가용성 설계 목표 는 99.999%입니다.

요약

주제	구현
리소스 모니터링	AWS 리전의 DNS 상태를 포함하여 모든 계층과 KPI에서 상태 확인. 구성된 경보가 작동하면 알림이 전송됨. 모든 장애 발생 시 알림이 전송됨. 운영 회의에서 철저하게 트렌드를 탐지하고 목표 설계를 관리함
수요 변화에 맞게 구현 조정	ELB를 웹 및 자동 조정 애플리케이션 계층에 사용. Aurora RDS의 액티브 및 패시브 리전에 있는 여러 영역에 자동 조정 스토리지 및 읽기 전용 복제본 배포. 정적 안정성을 위해 AWS 리전 간에 데이터 및 인프라가 동기화됨
변경 구현	Canary 또는 블루/그린을 통한 자동 배포. KPI 또는 알림이 애플리케이션에서 감지되지 않은 문제를 나타내는 경우 자동으로 롤백. 배포는 한 번에 하나의 AWS 리전에 있는 단일 격리 영역에 수행됨
데이터 백업	각 AWS 리전에서 RDS를 통한 자동 백업으로 RPO를 충족하고 실전 연습에서 자동 복원을 주기적으로 시행. Aurora RDS 및 S3 데이터는 액티브 리전에서 패시브 리전으로 비동기식으로 자동 복제됨
복원력을 위한 아키텍처 설계	애플리케이션을 위한 장애 격리 영역을 구현하고 자동 조정을 통해 자가 복구 웹 및 애플리케이션 계층 제공. RDS는 다중 AZ에 위치함. 리전 장애 조치는 자동화됨
복원 기능 테스트	구성 요소 및 격리 영역 장애 테스트가 파이프라인에 포함되고 운영 직원이 실전 연습을 통해 주기적으로 시행. 알려지지 않은 문제 진단을 위한 플레이북과 근본 원인 분석 프로세스가 마련되어 있으며 문제의 내용과 수정 또는 차단 방법을 알리는 커뮤니케이션 경로가 있음. RCA 수정은 즉각적인 구현 및 배포를 위해 기능 릴리스보다 우선적으로 적용됨
DR(재해 복구) 계획	2개 이상의 리전에 배포되는 액티브–액티브 방식. 인프라는 리전 전체로 완전히 확장되며 정적으로 안정적임. 데이터는 리전 간에 분할되고 동기화됨. RDS를 통한 암호화된 백업. 리전 장애는 게임 데이에 AWS와 조율하여 시행됩니다. 복원 중에 새 데이터베이스 기본을 승격해야 할 수 있습니다.