AWS 기술 블로그

AWS Fault Injection Service와Amazon ARC Region Switch로 복원력 향상하기

“이 게시글은 AWS Cloud Operations Blog의 ‘Improve the resiliency with AWS Fault Injection service and Amazon ARC Region switch by Rajakumar Sampathkumar‘를 번역 및 편집하였습니다”

분산 클라우드 환경에서는 시스템 장애가 자주 발생하기 때문에 애플리케이션 복원력이 고객에게 매우 중요합니다. 기존의 재해 복구 테스트 방식은 대부분 수동적이고 시간이 많이 소요되지만, 현대적인 카오스 엔지니어링 방식은 애플리케이션이 자동으로 장애를 처리하는 능력을 검증하는 데 도움이 됩니다.

Amazon Application Recovery Controller(ARC)는 준비 상태 확인 및 라우팅 제어를 제공하여 AWS 리전 및 가용 영역 전반에 걸친 애플리케이션 복구를 간소화합니다. 새로운 Region switch 서비스는 유연한 워크플로우로 원활한 복구를 조율하며, 액티브/패시브 및 액티브/액티브 구성을 모두 지원합니다. 이 완전 관리형 서비스는 진행 상황을 모니터링하는 실시간 복구 대시보드, 자동 장애 조치 기능, 그리고 장애 조치 시나리오에서 최대 신뢰성을 위한 독립적인 데이터 플레인을 제공합니다.

AWS Fault Injection Service(FIS)를 사용하면 AWS 워크로드에서 제어된 카오스 엔지니어링 실험을 수행하여 다양한 장애 시나리오에 애플리케이션이 어떻게 대응하는지 관찰할 수 있습니다. 이러한 사전 예방적 접근 방식은 실제 사고가 발생하기 전에 애플리케이션의 신뢰성과 가용성을 향상시키는 데 도움이 됩니다.

AWS Fault Injection Service와 Amazon Application Recovery Controller를 결합하면 복원력이 뛰어난 다중 리전 아키텍처를 구축하고 검증할 수 있습니다. 이 블로그 게시물에서는 다음 방법을 보여드립니다.

  • 자동 장애 조치를 위한 ARC Region switch 구성
  • 리전 장애를 시뮬레이션하는 FIS 실험 생성
  • Synthetics Canary 및 CloudWatch를 사용한 복구 대시보드 모니터링
  • 크로스 리전 복원력 자동 검증

사전 요구 사항

애플리케이션 아키텍처 – 샘플 워크로드

여러 AWS 리전에 배포된 고가용성 3계층 웹 아키텍처를 보여주는 예시를 살펴보겠습니다.

아키텍처 개요

그림 1: ARC를 활용한 다중 리전 아키텍처

이 솔루션은 함께 작동하는 세 가지 주요 계층으로 구성됩니다. 프론트엔드 계층은 여러 AZ와 리전에 분산된 Application Load Balancer를 사용하며, Amazon Route 53가 DNS 라우팅을 처리합니다. 애플리케이션 계층은 두 개의 AZ에 있는 Elastic Compute Cloud(EC2) 인스턴스의 Auto Scaling 그룹을 사용하여 장애 조치 시나리오를 시연하기 위한 맞춤형 “ARC 데모” 웹사이트 애플리케이션을 호스팅합니다.

데이터베이스 계층의 경우, US West(오레곤)에 기본 클러스터와 라이터 인스턴스가 구성된 Amazon Aurora Global Database를 활용하며, 읽기 확장을 위한 기본 리전과 재해 복구를 위한 US East(오하이오)에 읽기 전용 복제본이 보완됩니다. US West(오레곤)를 기본 리전으로, US East(오하이오)를 보조 리전으로 하는 이 액티브/패시브 배포 모델은 AZ와 리전 전반에 걸쳐 고가용성을 제공하며, 자동 장애 조치 기능, 다양한 워크로드에서의 확장 가능한 성능, 그리고 리전 간 일관된 데이터 복제를 제공합니다.

솔루션 워크스루

1. 기본 웹사이트 구성 확인

장애 조치 테스트를 진행하기 전에 ARC 데모 웹사이트의 현재 상태를 확인해 보겠습니다. 웹사이트 URL에 액세스하면 “Hello, World! PRIMARY REGION – Oregon”이 표시되어, 트래픽이 액티브 모드의 US West(오레곤) 리전에서 제공되고 있음을 확인할 수 있습니다. 이 웹사이트는 Route 53 퍼블릭 호스팅 영역에 장애 조치 라우팅 정책을 사용하여 구성되어 있으며 ARC 라우팅 제어 상태 확인과 연결되어 있습니다. 기본적으로 US West(오레곤)와 US East(오하이오) 리전 모두에서 라우팅 제어 상태가 꺼져 있을 때, 트래픽은 US West(오레곤)의 기본 레코드로 라우팅됩니다.

그림 2: 기본 리전에서 서비스 중인 ARC 데모 웹사이트

그림 3: 기본 US West(오레곤) 및 US East(오하이오) 리전에 대한 라우팅 제어

2. Application Recovery Controller – 리전 전환 계획 설정

Amazon Application Recovery Controller(ARC) 리전 전환은 AWS 리전 간 애플리케이션 복구를 조율하는 데 도움이 됩니다. AWS Management Console에서 ARC로 이동하여 액티브/패시브 다중 리전 복구 접근 방식을 구현하는 새 리전 전환 계획을 생성합니다. 이 구성은 US West(오레곤)를 기본 리전으로, US East(오하이오)를 대기 리전으로 지정하며, 복구 시간 목표(RTO)는 30분입니다. 이 RTO 기준은 실제 장애 조치 성능을 측정하고 비즈니스 연속성을 위한 복구 절차를 최적화하는 데 도움이 됩니다.

그림 4: 리전 전환 계획

3. ARC에서 리전 장애 조치 워크플로우 설계

리전 전환 워크플로우는 AWS 리전 전반에 걸쳐 복잡한 복구 작업을 체계적으로 조율하여 운영 오버헤드를 줄이면서 비즈니스 연속성을 유지할 수 있도록 도와줍니다. 복구 작업을 자동화하고 순서를 지정함으로써 장애 조치 프로세스 전반에 걸쳐 진행 상황을 모니터링하고 제어를 유지할 수 있습니다. 리전 전환 계획이 준비되었음을 확인한 후(그림 4에 표시된 것처럼 녹색 평가 상태로 표시됨), AWS Application Recovery Controller의 그래픽 디자인 편집기를 사용하여 구조화된 워크플로우를 생성합니다. 이 순차적 실행 흐름을 통해 제어되고 신뢰할 수 있는 리전 전환이 가능합니다. 이 워크플로우에는 다음과 같은 주요 실행 블록이 포함됩니다.

  • Auto Scaling 구성: 활성화된 리전에서 100% 용량 매칭 활성화
  • 수동 승인: 적절한 IAM 권한을 통한 수동 확인 구현
  • Aurora Global DB 관리: 데이터베이스 전환 작업 처리
  • 라우트 제어: 기본 및 보조 리전 간 트래픽 흐름 관리

각 실행 블록은 장애 조치 프로세스 중 애플리케이션 가용성을 유지하면서 잠재적 중단을 최소화하기 위해 전략적으로 순서가 지정됩니다.

그림 5: 다중 리전 조율을 위한 리전 전환 계획 워크플로우

4. AWS Synthetic canary를 사용한 웹사이트 성능 사전 모니터링

ARC 리전 전환에서 자동 재해 복구를 활성화하려면 리전 전환 트리거를 구성하기 위한 모니터링 지표가 필요합니다. AWS Synthetic canaries에서 “website-monitoring”를 구현하세요 – 이는 웹사이트 엔드포인트를 정기적으로 확인하는 자동화된 스크립트입니다. 이러한 canary는 가상 사용자 역할을 하며, 예약된 간격으로 다양한 브라우저에서 이 웹사이트를 체계적으로 테스트합니다.

canary는 실제 고객 행동을 반영하는 미리 정의된 경로를 따라 실제 사용자 상호 작용을 시뮬레이션합니다. 이러한 사전 모니터링 접근 방식은 사용자에게 영향을 미치기 전에 잠재적 문제를 감지하는 데 도움이 되며 웹사이트 기능의 지속적인 검증을 통해 안정적인 서비스 제공을 가능하게 합니다.
이 모니터링 설정에는 다음이 포함됩니다.

  • 기본 웹사이트 상태를 확인하는 정기적인 canary 테스트
  • website-monitoring canary에서 “실패한 요청”에 대한 CloudWatch 지표 구성
  • 1분 내에 실패가 1 이상일 때 활성화되도록 설정된 경보 트리거

그림 6: Synthetic canary를 사용한 웹사이트 모니터링

5. 복구 자동화: 리전 전환 계획 트리거 구성

자동 재해 복구를 활성화하기 위해 기본 리전 장애에 대응하는 트리거를 리전 전환 계획에 통합했습니다. 이 시스템은 Synthetic canary의 website-monitoring와 CloudWatch 경보를 사용하여 중단을 감지합니다. canary가 웹사이트 사용 불가를 감지하고 CloudWatch 경보가 ALARM 상태로 전환되면 자동으로 ARC 리전 전환 계획이 시작됩니다.

이 자동화된 트리거 메커니즘은 리전 장애에 신속하게 대응하여 수동 개입을 제거하고 복구 시간을 단축합니다. 모니터링과 복구 절차 간의 직접적인 연결은 기본 리전 문제를 감지하는 즉시 활성화되는 원활한 장애 조치 프로세스를 생성합니다.

그림 7: ARC 리전 전환에 트리거 추가

6. AWS Fault Injection Simulator(FIS)를 사용한 기본 리전 장애 시뮬레이션

이 시나리오에서는 FIS를 사용하여 기본 리전(US West)에서 네트워크 장애를 시뮬레이션합니다. 실험 템플릿은 다음 사양으로 구성됩니다.

  • AWS FIS 실험 템플릿 생성
  • 장애 작업: aws:network:disrupt-connectivity
  • 기본 리전(US West)의 대상 리소스:
    • Application Load Balancer(ALB) 퍼블릭 서브넷
    • EC2 웹서버 프라이빗 서브넷

이 실험은 기본 리전의 ALB 및 애플리케이션 서브넷에 대한 특정 트래픽을 차단하여 장애 조치 메커니즘을 검증하기 위한 리전 장애를 시뮬레이션합니다.

그림 8: FIS-네트워크-연결성-실험

그림 9: FIS-네트워크-연결성-실험 작업 및 대상

7. 합성 모니터링을 통한 기본 리전 장애 감지

Synthetic canary 모니터링이 기본 리전에서 네트워크 연결이 중단되었을 때 즉각적인 영향을 감지했습니다. ARC 데모 웹사이트를 지속적으로 모니터링하는 canary가 실패한 요청을 보고하여 CloudWatch 경보를 트리거했고, 이로 인해 빠르게 ALARM 상태로 전환되었습니다.

이러한 실시간 모니터링 응답은 리전 중단을 식별하는 데 있어 Synthetic canary 설정의 효과를 검증합니다. 성공적인 canary 테스트에서 실패한 테스트로의 전환은 기본 리전에 연결 문제가 발생하여 즉각적인 장애 조치 조치가 필요함을 확인했습니다.

그림 10: Canary 대시보드를 사용한 웹사이트 상태 확인

그림 11: 기본 사이트 다운을 나타내는 CloudWatch 경보

그림 12: 계획이 활성 상태이며 실행 단계에 있음을 보여줌

장애 조치 시퀀스가 수동 승인 실행 블록에서 일시 중지되었습니다. 모니터링을 통해 기본 리전 중단을 확인한 후, 보조 리전으로의 전환 요청이 승인되어 재해 복구 프로세스가 계속 진행될 수 있었습니다.

그림 13: 장애 조치 중 수동 승인

리전 전환 실행이 성공적으로 완료되었습니다. 실행 기록은 자동화된 트리거를 통해 시작된 프로세스를 확인하여 자동화된 재해 복구 시스템이 설계된 대로 작동함을 검증합니다.

그림 14: 리전 전환 실행 결과

최종 실행 블록은 자동으로 ‘east’의 라우팅 제어를 ON 상태로 업데이트하여 그림 15에 표시된 것처럼 모든 트래픽을 보조 리전으로 성공적으로 리디렉션했습니다.

그림 15: 최종 라우팅 제어 업데이트

9. 보조 리전 활성화 확인

ARC 데모 웹사이트가 이제 US East(오하이오)의 보조 리전에서 성공적으로 트래픽을 제공하고 있어 완전한 장애 조치 실행을 확인합니다.

그림 16: 보조 리전 활성화 확인

정리

Amazon Route 53 ARC는 추가 비용 없이 제공되지만, 사용되는 다른 AWS 리소스는 표준 요금이 발생합니다. 지속적인 비용을 방지하려면 리전 전환 계획, AWS Synthetic canary, CloudWatch 경보, FIS 실험 템플릿, Route 53 구성, EC2 인스턴스, Auto Scaling 그룹, Application Load Balancer 및 두 리전의 Aurora Global Database 클러스터를 삭제하세요. 마지막으로, ARC 및 FIS를 위해 생성된 역할과 관련 권한을 삭제하는 것을 권장합니다. 적절한 리소스 종속성 처리를 위해 생성 순서의 역순으로 이러한 정리 단계를 따르는 것을 권장합니다.

결론

이 게시물에서는 전통적인 3계층 웹 아키텍처와 함께 Amazon Route 53 Application Recovery Controller(ARC)를 사용하여 자동화된 크로스 리전 장애 조치를 구현하는 방법을 보여드렸습니다. ARC 리전 전환과 AWS Synthetic canary 및 Fault Injection 서비스를 결합하여 리전 장애를 자동으로 감지하고 대응하는 강력한 재해 복구 솔루션을 만들었습니다.

이 솔루션은 다음과 같은 주요 기능을 제공합니다.

  • 최소한의 중단으로 자동화된 복구
  • 실시간 모니터링 및 장애 감지
  • 제어된 장애 조치 오케스트레이션
  • 복구 절차의 체계적인 테스트

이 구현은 ARC가 성능 저하부터 계획된 유지 보수에 이르기까지 다양한 시나리오를 처리할 수 있는 유연성을 제공하면서 재해 복구 관리를 어떻게 간소화하는지 보여줍니다. 이 접근 방식을 따르면 리전 중단 시에도 가용성을 유지하는 복원력 있는 애플리케이션을 구축하여 비즈니스 연속성과 향상된 고객 경험을 지원할 수 있습니다. AWS 서비스를 사용한 재해 복구 솔루션 구현 및 테스트에 대해 자세히 알아보려면 다음 리소스를 참조하세요:

Anselmo Shin

Anselmo Shin

신안셀모 Cloud Architect는 AWS Professional Services 팀의 일원으로서 고객에게 가장 AWS 기반 서비스를 통해 보다 복원력 있고 신뢰성 있는 아키텍쳐를 제공하고, 자동화된 프로세스와 GenAI를 활용한 운영 고도화에 여러 기술적 도움을 드리고 있습니다.