Route 53 자동 장애 조치 3단계
1단계: 상태 확인(Health Check) 생성
먼저 Route 53가 주 서버(Primary)의 생사 여부를 판단할 수 있도록 감시관을 배치해야 합니다.
Route 53 콘솔 → [상태 확인(Health checks)] → [상태 확인 생성]을 클릭합니다.
모니터링 대상: 주 서버의 IP 주소 또는 도메인 이름(ALB DNS 등)을 입력합니다.
고급 구성:
요청 간격:
빠름(10초)을 선택하면 장애 감지 속도가 빨라집니다.임계값:
3회로 설정 시, 30초(10초 × 3회) 연속 실패 시 장애로 판단합니다.
CloudWatch 알람(선택): 상태가 'Unhealthy'로 변할 때 이메일 알림을 받도록 설정할 수 있습니다.
2단계: 주 레코드(Primary) 생성
평상시 모든 트래픽을 처리할 메인 서버용 레코드입니다.
호스트 존 → [레코드 생성]을 클릭합니다.
라우팅 정책: [장애 조치(Failover)]를 선택합니다.
장애 조치 레코드 유형: [기본(Primary)]을 선택합니다.
상태 확인 연결: 위 1단계에서 만든 상태 확인을 연결합니다.
Evaluate Target Health: Alias(별칭) 레코드 사용 시 '예'를 권장합니다.
3단계: 보조 레코드(Secondary) 생성
주 서버 장애 시 트래픽을 넘겨받을 대기 서버용 레코드입니다.
[레코드 생성]을 다시 클릭하여 동일한 이름(예:
www.example.com)으로 만듭니다.라우팅 정책: [장애 조치(Failover)]를 선택합니다.
장애 조치 레코드 유형: [보조(Secondary)]를 선택합니다.
대상: 대기 중인 인스턴스, S3 정적 웹 사이트 엔드포인트 등을 지정합니다.
참고: 보조 레코드에는 별도의 상태 확인을 연결하지 않아도 되지만, 대기 서버 자체도 죽었을 경우를 대비해 연결하는 것이 좋습니다.
자동 전환 시간(MTTR) 계산법
장애가 발생했을 때 사용자가 실제 대기 서버로 넘어가기까지 걸리는 총 시간은 다음과 같습니다.
$$Total Time = (Interval \times Threshold) + Record TTL + Client Cache$$
Health Check 감지: 약 30~60초
DNS TTL: 레코드 설정 값 (예: 60초)
브라우저 캐시: 사용자 환경에 따라 상이
액티브-패시브 vs 액티브-액티브
구분 | 액티브-패시브 (Active-Passive) | 액티브-액티브 (Active-Active) |
작동 방식 | 평소엔 메인만, 장애 시만 백업 가동 | 모든 서버가 항상 트래픽 분산 처리 |
라우팅 정책 | Failover | Weighted, Latency, Multivalue |
비용 효율 | 백업 서버 유지 비용 발생 | 자원 활용도가 높음 |
권장 용도 | 재해 복구(DR), 유지보수용 페이지 | 글로벌 서비스, 고부하 애플리케이션 |
Tip
TTL(Time To Live)을 낮추는 것만큼 중요한 게 없습니다.
아무리 Route 53가 0.1초 만에 장애를 감지해도, 레코드의 TTL이 300초(5분)로 설정되어 있다면 사용자의 브라우저는 5분 동안 계속 죽은 서버로 접속을 시도합니다. 장애 조치용 레코드의 TTL은 반드시 60초 이하로 설정하세요. 대기 서버로 단순히 S3 정적 페이지를 띄워 "현재 점검 중입니다"라고 안내하는 방식이 비용 대비 가장 효율적인 DR 전략으로 꼽힙니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.