SW BBANG K

새벽 2시에 온콜 알림이 울렸다. EC2 인스턴스가 응답을 멈췄는데, DNS가 여전히 죽은 서버를 가리키고 있어서 사용자들은 그냥 타임아웃 화면만 보고 있었다. Route 53 DNS 페일오버를 미리 구성해뒀다면, 헬스 체크가 실패하는 순간 트래픽이 S3 정적 백업 사이트로 자동 전환됐을 것이다. 이 글은 그 설정을 처음부터 끝까지 다룬다. TL;DR — Route 53 DNS 페일오버 핵심 요약 단계 구성 요소 역할 1 Route 53 헬스 체크 EC2 엔드포인트 상태를 주기적으로 확인 2 Primary 레코드 (Failover) EC2를 가리키며 헬스 체크와 연결 3 Secondary 레코드 (Failover) S3 정적 웹사이트 엔드포인트를 가리킴 4 S3 버킷 정적 웹사이트 호스팅 백업 페이지 서빙 5 자동 전환 헬스 체크 실패 시 Secondary로 DNS 응답 변경 Route 53 DNS 페일오버 동작 원리 Route 53의 페일오버 라우팅 정책은 Active-Passive 구조다. Primary 레코드에 헬스 체크를 연결해두면, Route 53 헬스 체커가 전 세계 여러 위치에서 해당 엔드포인트를 주기적으로 폴링한다. 헬스 체크가 임계값 이상 실패하면 Route 53은 해당 레코드를 'Unhealthy'로 표시하고, 동일한 이름과 타입을 가진 Secondary 레코드로 DNS 응답을 전환한다. 중요한 점은 이것이 DNS 레벨의 전환이라는 것이다. 기존 TCP 연결은 끊기지 않으며, TTL이 만료된 이후 새로운 DNS 조회부터 Secondary 주소를 받게 된다. 따라서 TTL 값 설정이 실제 전환 속도에 직접적인 영향을 준다. sequenceDiagram participant Client as 클라이언트 participant R53 as Route...

프로덕션 RDS 인스턴스를 처음 설정할 때 Multi-AZ 옵션을 보고 '이거 켜면 성능도 좋아지겠지?'라고 생각했다면, 그 가정이 장애 대응 중에 당신을 배신할 수 있다. Multi-AZ는 고가용성과 페일오버 를 위한 기능이지, 읽기 성능 향상을 위한 기능이 아니다. TL;DR: RDS Multi-AZ 핵심 요약 항목 Multi-AZ 동작 목적 고가용성 및 자동 페일오버 스탠바이 인스턴스 직접 접근 불가 (읽기/쓰기 모두 차단) 읽기 성능 향상 없음 — 읽기 스케일아웃은 Read Replica 사용 쓰기 성능 영향 동기 복제로 인한 소폭 지연 가능 페일오버 소요 시간 일반적으로 60~120초 (공식 보장 없음) 데이터 내구성 동기 복제로 RPO ≈ 0 자동 백업 스탠바이에서 수행 (프라이머리 I/O 영향 감소) RDS Multi-AZ가 실제로 하는 일 Multi-AZ를 활성화하면 AWS는 다른 가용 영역(AZ)에 스탠바이 인스턴스를 자동으로 프로비저닝한다. 프라이머리 인스턴스에 쓰기가 발생하면 Amazon RDS는 동기식 블록 수준 복제를 통해 스탠바이에 데이터를 미러링한다. 애플리케이션은 항상 프라이머리 엔드포인트 하나만 바라본다. 여기서 핵심은 동기(synchronous) 복제 라는 점이다. 프라이머리가 트랜잭션을 커밋하기 전에 스탠바이에도 기록이 완료되어야 한다. 이 구조 덕분에 페일오버 시 데이터 손실이 없지만, 반대로 스탠바이는 항상 '대기 중'이지 '서비스 중'이 아니다. graph LR App["애플리케이션"] -->|"단일 엔드포인트 (DNS)"| Primary["프라이머리 인스턴스 AZ-A"] Primary -->|"동기 ...