Day 5 - Week 13 종합 복습: 고가용성·멀티 리전·DR·복원력 검증을 하나로 꿰다

글로벌 게임 서비스가 UDP 트래픽을 쓰고, 한 리전이 죽으면 클라이언트의 DNS 캐시와 무관하게 즉각 다른 리전으로 페일오버해야 한다. 동시에 클라이언트는 고정 IP 2개만 알면 되도록 하려 한다. 가장 적합한 것은?

• ARoute 53 Failover Routing + 짧은 TTL(예: 10초)로 캐시 만료를 앞당겨 빠른 페일오버 유도
• BAWS Global Accelerator — anycast 고정 IP 2개 + 헬스 체크 기반 즉각 재라우팅
• CCloudFront 배포 + Origin Failover로 엣지에서 건강한 리전 오리진으로 자동 전환
• DRoute 53 Latency Routing + 헬스 체크로 지연 최저이면서 건강한 리전으로 라우팅

결제 시스템이 RTO 0·RPO 0에 가까워야 하고 비용은 제약이 거의 없다. 두 리전에서 동시에 쓰기를 받아야 한다. 데이터 계층 구성과 반드시 검증할 위험은?

• AAurora Global Database(단일 리더) — secondary는 읽기 전용이나 충돌이 없어 정합성이 가장 안전
• BDynamoDB Global Tables(멀티 마스터, LWW) + Route 53 Latency Routing, 단 "같은 키 동시 갱신 시 silent lost update"와 "한 리전이 전체 트래픽 감당 용량"을 반드시 검증
• CRDS Multi-AZ + 리전 간 Read Replica로 한 리전 쓰기·다른 리전 읽기를 구성
• DS3 CRR(Cross-Region Replication)로 양 리전 객체를 양방향 복제해 동시 쓰기를 수용

전통적 RDS Multi-AZ를 쓰는 시스템에서 읽기 부하가 커졌다. Standby로 읽기를 분산하려 했으나 불가능했다. 이유와 올바른 해법은?

• AStandby가 다른 리전에 있어 cross-region 읽기가 차단된 것 — Standby를 같은 리전·AZ로 옮긴다
• BMulti-AZ Standby는 블록 레벨 물리 복제라 독립 쿼리 엔진이 없어 read 불가 — Read Replica(논리 비동기 복제)를 추가하거나 Multi-AZ DB Cluster(readable standby)로 전환
• CStandby 엔드포인트에 대한 IAM/SG 읽기 권한이 빠진 것 — 읽기 권한과 보안 그룹 규칙을 추가
• DStandby를 promote해 독립 읽기 인스턴스로 승격한 뒤 읽기 트래픽을 분산

Aurora MySQL에서 운영자가 실수로 대량 UPDATE를 실행했다. 5분 전 상태로 클러스터 전체를 가장 빠르게 되돌리려 한다. 또한 별도 케이스로 "30일 전 특정 테이블만" 복구해야 할 때의 차이는?

• A둘 다 스냅샷에서 새 클러스터로 복원하고 필요한 시점·테이블을 추출해 적용
• B5분 전 전체 되돌리기는 Backtrack(in-place, 최대 72h), 30일 전 특정 테이블은 PITR/스냅샷 복원(새 클러스터). Backtrack은 MySQL만·활성화 이후만 가능
• C둘 다 Backtrack으로 in-place 되감기 — 5분 전과 30일 전 모두 윈도우 내에서 처리
• D둘 다 Read Replica를 promote해 해당 시점 데이터를 가진 인스턴스로 분리 복구

Lambda 기반 서버리스 앱이 트래픽 급증 시 RDS의 "too many connections"로 실패하고, DB 페일오버 시 커넥션이 일제히 끊겨 connection storm이 난다. 한 번에 해결하는 표준은?

• ADB 인스턴스 클래스를 키워 max_connections 한도를 높이고 더 많은 동시 커넥션을 수용
• BRDS Proxy — 커넥션을 풀링·다중화해 실제 DB 커넥션 수를 억제하고, 페일오버 시 클라이언트 커넥션을 유지해 storm을 완화
• CLambda 예약 동시성을 1로 제한해 동시에 열리는 DB 커넥션 수 자체를 강하게 묶는다
• DRead Replica를 추가해 읽기 커넥션을 분산함으로써 Primary의 커넥션 압박을 완화

금융 규제로 백업을 보존 기간 내 절대 삭제·변조 불가하게 만들어 랜섬웨어가 백업까지 지우는 것을 막아야 한다. root 사용자조차 예외가 없어야 한다. 올바른 구성은?

• AAWS Backup Vault Lock — Governance Mode로 보존을 강제하되 지정 IAM 권한자에게만 우회를 허용
• BAWS Backup Vault Lock — Compliance Mode(WORM, root 포함 누구도 보존 기간 내 삭제 불가)
• CIAM 정책에 백업 삭제(backup:DeleteRecoveryPoint) 명시적 Deny를 걸어 삭제를 차단
• D백업을 격리된 별도 계정의 Vault로 cross-account 복사해 원본 손상에 대비

Tier 3 비중요 워크로드의 DR 비용을 최소화해야 한다. 전체 인프라는 Terraform으로 코드화돼 있고, RTO는 한두 시간까지 허용된다. 가장 적합한 전략과 그 이유는?

• AActive-Active — 두 리전에 풀 용량을 상시 가동해 RTO를 0에 가깝게 만드는 가장 안전한 선택
• BBackup & Restore — DR 리전에 인프라를 전혀 안 켜 비용 최소, IaC로 스택 배포 + 백업 복원을 자동화하면 RTO 한두 시간 달성 가능
• CWarm Standby — DR 리전에 축소판을 상시 가동해 경로를 검증해 두고 장애 시 스케일 업
• DPilot Light — DR 리전에 데이터 복제만 켜두고 앱 tier는 꺼둬 비용과 RTO를 절충

Pilot Light DR을 자동 발동하는 절차를 코드화하려 한다. 발동 시 수행할 단계와 도구로 올바른 것은?

• A엔지니어가 콘솔에서 기억과 경험에 의존해 발동 단계를 수동으로 순서대로 실행
• BStep Functions/SSM Runbook으로 "Read Replica promote → ASG desired 0→N → ALB 헬스 통과 대기 → Route 53(ARC) 페일오버 → 알림"을 코드화하고 정기 drill로 검증
• C발동 절차의 모든 단계를 위키 런북 문서에 상세히 적어 두고 사고 시 따라 실행
• DRPO를 줄이도록 Backup 주기를 더 짧게 잡아 발동 시 복원 데이터 손실을 최소화

EC2 운영 인스턴스 중 무작위 30%에 5분간 CPU 부하를 주입해 Auto Scaling 자가 치유를 검증하되, 실험이 진짜 장애로 번지면 즉시 중단되게 하려 한다. FIS 구성은?

• ATarget SelectionMode ALL + CPU-Stress(PT5M)로 전수에 부하를 줘 최악 상황을 한 번에 검증, Stop Condition 없음
• BTarget SelectionMode PERCENT(30) + Action CPU-Stress(PT5M) + Stop Condition(CloudWatch P99/에러율 Alarm)
• CAction으로 무작위 30% 인스턴스를 Terminate해 ASG의 인스턴스 교체 자가 치유를 검증
• D운영자가 30% 인스턴스에 직접 부하 발생기를 실행하고 이상 시 수동으로 중단

코드와 인프라가 자주 바뀌는 환경에서, 복원력이 시간이 지나며 조용히 깨지는 것(regression)을 막으려 한다. 가장 적합한 운영 패턴은?

• A분기마다 한 번 엔지니어가 복원력 구성을 수동으로 점검하고 갭을 문서화
• BEventBridge Scheduler로 FIS 카오스 실험을 주기 실행하고 결과를 Resilience Hub/CloudWatch로 모아 측정·실험·개선 루프를 정기 자동화
• C실제 장애가 발생했을 때 대응하며 그 경험을 다음 설계 개선에 반영
• D복원력 지표에 대한 CloudWatch 알람을 더 촘촘히 추가해 regression을 조기 감지

한 워크로드의 실제 복원력이 설정한 RTO/RPO 목표(AZ 장애 RTO 600초 등)를 충족하는지 측정하고, 미달 항목에 대한 개선안과 그 비용 영향을 자동으로 받고 싶다. 가장 적합한 서비스는?

• ACloudWatch Dashboard — RTO/RPO 관련 지표를 한 화면에 시각화해 목표 미달을 눈으로 확인
• BAWS Resilience Hub — 워크로드를 분석해 장애 유형별(Hardware/Software/AZ/Region) 목표 대비 실측 갭·권장 개선안·비용을 제시하고 FIS로 검증
• CAWS Config — 복원력 관련 리소스 구성(Multi-AZ 여부 등)을 규칙으로 평가해 비준수를 탐지
• DFIS 단독 — 장애를 주입해 실제 복구 시간을 측정하고 RTO/RPO 목표 충족을 직접 확인

글로벌 사용자에게 평소엔 지연 최저 리전으로 서비스하되, 한 리전이 죽으면 자동으로 건강한 리전만 응답하고, 데이터는 리전 간 비동기 복제로 유지하려 한다(관계형 DB, 쓰기는 한 곳). 올바른 조합은?

• ARoute 53 Simple Routing + RDS Single-AZ로 단일 리전에 단순 구성하고 장애 시 수동 전환
• BRoute 53 Latency Routing + 헬스 체크 + Aurora Global Database(단일 리더 비동기 <1초, 장애 시 secondary promote)
• CRoute 53 Weighted 50:50 + DynamoDB Global Tables로 트래픽을 균등 분산하고 멀티 마스터 복제
• DGlobal Accelerator(anycast IP) + S3 CRR로 즉각 페일오버하고 데이터는 리전 간 객체 복제