한 회사에서 현재 단일 AWS 리전에 배포되어 있는 중요 애플리케이션에 대한 재해 복구를 구현해야 합니다. 웹 프런트엔드는 Application Load Balancer(ALB) 뒤의 EC2 인스턴스를 사용합니다. 애플리케이션은 Amazon RDS for MySQL DB 인스턴스에 데이터를 쓰고 처리된 문서를 Amazon S3 버킷에 출력합니다. 재무팀은 데이터베이스에 직접 쿼리를 실행하여 보고서를 생성하는데, 피크 시간 동안 이러한 쿼리가 DB 리소스를 소비하고 애플리케이션 성능을 저하시킵니다. 데이터 손실을 최소화하고 재무팀 쿼리의 성능 영향을 제거하는 재해 복구 솔루션을 설계하십시오. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

정답은 재해 복구(DR) 목표를 달성하고 재무팀 쿼리의 성능 영향을 완화합니다. 다른 리전에 RDS 읽기 복제본을 생성하면 재무팀이 프로덕션 데이터베이스에 영향을 주지 않고 보고서 쿼리를 실행할 수 있습니다. S3 CRR은 S3 버킷의 데이터를 다른 리전에 자동으로 복제하여 데이터 손실을 최소화합니다. AMI를 복사하고 재해 발생 시 EC2 인스턴스를 시작하는 것은 RTO(복구 시간 목표)를 충족하는 일반적인 전략입니다. 오답 1은 DynamoDB로 마이그레이션하는 것은 상당한 애플리케이션 변경이 필요하며, 기존 MySQL RDS 인스턴스를 유지하면서 DR 및 성능 문제를 해결하는 더 간단한 방법이 있습니다. 오답 2는 DR 시나리오에서 애플리케이션을 호스팅하는 추가 EC2 인스턴스를 다른 리전에 시작하고 ALB에 추가하는 것은 활성-활성 구성에 가깝지만, 재해 발생 시 읽기 복제본을 승격하고 애플리케이션을 재구성하는 것은 수동 개입이 필요하여 RTO를 증가시킬 수 있습니다. 오답 4는 RDS 스냅샷을 매시간 복사하는 것은 RPO(복구 시점 목표)를 충족하지 못할 수 있으며, ElastiCache는 읽기 부하를 줄일 수 있지만 재무팀 쿼리 문제를 완전히 해결하지는 못합니다.