RDS Multi-AZ 페일오버 대응 및 연결 전략
1. DNS 캐싱 설정 최적화 (가장 빈번한 이슈)
애플리케이션이나 운영체제(OS)가 예전 Primary의 IP 주소를 너무 오래 기억(캐싱)하고 있으면, DNS가 바뀌어도 계속 죽은 서버에 접속을 시도하게 됩니다.
Java/JVM 환경: JVM은 보안상의 이유로 DNS 조회 결과를 영원히(forever) 캐싱하는 경우가 많습니다.
networkaddress.cache.ttl값을 60초 이하로 반드시 설정해야 합니다.OS 레벨:
nscd같은 DNS 캐싱 서비스를 사용 중이라면 TTL 설정을 확인하세요. AWS RDS의 DNS TTL은 기본적으로 60초입니다.
2. RDS Proxy 도입 (권장 전략)
2026년 현재, 대규모 트래픽을 다루는 서비스에서 RDS Proxy는 선택이 아닌 필수입니다.
작동 원리: 애플리케이션과 DB 사이에 위치하며, 페일오버 발생 시 애플리케이션의 연결을 끊지 않고 잠시 대기시켰다가 새 DB가 준비되면 즉시 트래픽을 넘겨줍니다.
장점: 일반적인 DNS 방식보다 페일오버 시간을 최대 66%까지 단축시킬 수 있으며(보통 수십 초 내외), 애플리케이션에서 별도의 복잡한 재연결 로직을 짤 필요가 없습니다.
3. 애플리케이션 레벨의 재연결 로직 (Retry Logic)
네트워크는 언제든 끊길 수 있다는 가정하에 코드를 작성해야 합니다.
Connection Pool 설정: HikariCP 같은 라이브러리를 사용한다면,
maxLifetime과connectionTimeout을 적절히 설정하여 유효하지 않은 연결을 빠르게 버리고 새로 맺도록 하세요.에러 핸들링:
ReadOnly에러나Connection Timeout이 발생했을 때, 즉시 에러를 뱉는 대신 지수 백오프(Exponential Backoff) 알고리즘을 적용한 재시도 로직을 구현하세요.
페일오버 방식별 비교
항목 | 일반 DNS 방식 | RDS Proxy 사용 방식 |
복구 시간 | 60 ~ 120초 | 30 ~ 60초 미만 |
앱 연결 상태 | 기존 연결 모두 끊김 (에러 발생) | 연결 유지 (지연 발생 후 재개) |
설정 복잡도 | OS/JVM DNS 설정 필요 | AWS 서비스 설정 필요 |
비용 | 추가 비용 없음 | 인스턴스 크기 기반 추가 과금 |
AWS 전용: AWS Advanced JDBC Driver
일반 MySQL/PostgreSQL 드라이버는 DNS가 바뀌기만을 기다립니다. 하지만 AWS Advanced JDBC Driver는 클러스터의 상태(Topology)를 직접 확인하여 페일오버 시간을 수초 내로 단축시킵니다.
특징: DB 서버가 죽으면 드라이버가 즉시 다른 노드를 찾아서 연결을 전환합니다.
사용 방법: 기존 드라이버 대신
aws-advanced-jdbc-wrapper를 의존성에 추가하고 접속 URL 형식을 바꿉니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.