안녕하세요, 클라우드 엔지니어 여러분! 오늘은 AWS RDS Multi-AZ 환경에서 발생하는 failover 과정에 대해 심층적으로 알아보겠습니다. 이 글을 통해 여러분은 RDS Multi-AZ의 내부 동작을 이해하고, 실제 장애 상황에서 어떻게 대처해야 할지 명확히 알 수 있을 것입니다.
📝 3줄요약
1. RDS Multi-AZ는 고가용성, 무중단 유지보수, 데이터 안정성을 제공합니다.
2. Failover 과정은 장애 감지, DNS 전환, 클라이언트 연결 재설정, 복제 재설정의 단계로 이루어집니다.
3. 연결 풀링, Read Replica 활용, 정기적인 failover 테스트, 애플리케이션 레벨 재시도 로직 구현 등으로 failover 과정을 최적화할 수 있습니다.
📌 RDS Multi-AZ가 필요한 이유
먼저, 왜 우리에게 RDS Multi-AZ가 필요한지 살펴보겠습니다.
- 고가용성 보장: 단일 AZ에서 운영되는 데이터베이스는 해당 AZ에 문제가 발생하면 서비스 중단으로 이어집니다. Multi-AZ는 이러한 위험을 크게 줄여줍니다.
- 무중단 유지보수: AWS에서 진행하는 정기 유지보수나 패치 적용 시에도 서비스 중단 없이 진행할 수 있습니다.
- 데이터 안정성: 동기식 복제를 통해 데이터 손실 위험을 최소화합니다.
이러한 이유로 프로덕션 환경에서는 Multi-AZ 구성이 필수적이라고 할 수 있습니다.
🔍 RDS Multi-AZ 아키텍처
RDS Multi-AZ의 기본 아키텍처를 살펴보겠습니다.
위 다이어그램에서 볼 수 있듯이, RDS Multi-AZ 구성은 다음과 같은 요소로 이루어져 있습니다:
- Primary DB Instance: 주 데이터베이스로, 실제 읽기/쓰기 작업이 이루어지는 인스턴스입니다.
- Standby DB Instance: 대기 데이터베이스로, Primary와 동기식으로 복제됩니다.
- DNS: 클라이언트의 연결을 관리하는 DNS 엔드포인트입니다.
이제 failover가 어떻게 일어나는지 단계별로 살펴보겠습니다.
🔄 RDS Multi-AZ Failover 프로세스
RDS Multi-AZ 설정에서의 failover 과정을 단계별로 설명해 드리겠습니다:
- 정상 운영 상태:
- 클라이언트는 RDS 인스턴스의 DNS 엔드포인트를 통해 연결합니다.
- DNS는 주 DB 인스턴스로 트래픽을 라우팅합니다.
- 주 DB 인스턴스는 다른 가용영역에 있는 대기 DB 인스턴스로 데이터를 동기식으로 복제합니다.
- 장애 감지:
- AWS는 주 DB 인스턴스의 상태를 지속적으로 모니터링합니다.
- 다음과 같은 상황에서 장애로 판단됩니다:
- 기본 가용 영역 중단
- 주 DB 인스턴스의 네트워크 연결 실패
- 주 DB 인스턴스의 컴퓨팅 유닛 장애
- 스토리지 장애
- Failover 시작:
- 장애가 감지되면 AWS는 자동으로 failover 프로세스를 시작합니다.
- 이 과정은 보통 1-2분 정도 소요됩니다.
- DNS 레코드 업데이트:
- RDS는 DNS 레코드를 업데이트하여 트래픽을 대기 DB 인스턴스로 리디렉션합니다.
- 대기 DB 승격:
- 대기 DB 인스턴스가 새로운 주 DB 인스턴스로 승격됩니다.
- 이 인스턴스는 모든 데이터베이스 연결을 처리하기 시작합니다.
- 클라이언트 재연결:
- 클라이언트 애플리케이션은 일시적인 연결 중단을 경험할 수 있습니다.
- DNS 변경사항이 전파되면 클라이언트는 자동으로 새로운 주 DB 인스턴스에 연결됩니다.
- 복구 및 동기화:
- 원래의 주 DB 인스턴스가 복구되면, 이는 새로운 대기 인스턴스가 됩니다.
- 새로운 주 DB에서 대기 DB로 데이터 동기화가 시작됩니다.
- 정상 운영 재개:
- 모든 프로세스가 완료되면, 시스템은 정상 운영 상태로 돌아갑니다.
- 이제 새로운 주 DB 인스턴스가 모든 읽기 및 쓰기 작업을 처리합니다.
이 프로세스는 대부분 자동으로 이루어지며, 관리자의 개입이 최소화됩니다. 그러나 애플리케이션 레벨에서 일시적인 연결 중단에 대비한 적절한 오류 처리 및 재시도 로직이 구현되어 있어야 합니다.
추가적인 설명이나 특정 부분에 대해 더 자세한 정보가 필요하시다면 말씀해 주세요.
🛠 Failover 최적화 팁
- 연결 풀링 사용: RDS Proxy나 PgBouncer와 같은 연결 풀링 솔루션을 사용하면 failover 시 연결 재설정 부담을 줄일 수 있습니다.
- Read Replica 활용: 읽기 전용 워크로드를 Read Replica로 분산시켜 Primary의 부하를 줄이세요.
- 정기적인 failover 테스트: 계획된 failover를 정기적으로 실행하여 시스템의 복원력을 테스트하세요.
- 애플리케이션 레벨 재시도 로직: 일시적인 연결 오류를 처리할 수 있는 재시도 로직을 구현하세요.
🔥Failback 프로세스
장애가 발생한 원래의 주 DB 인스턴스(A)가 복구되면 시스템을 원래 상태로 되돌릴 수 있습니다. 이 프로세스를 “failback”이라고 합니다. 이에 대해 자세히 설명해 드리겠습니다.
- 장애 복구:
- 원래의 주 DB 인스턴스 A의 문제가 해결되고 정상 작동 상태로 복구됩니다.
- 동기화:
- 복구된 인스턴스 A는 현재 주 DB 역할을 하고 있는 인스턴스 B와 동기화를 시작합니다.
- 이 과정에서 A는 대기 DB 역할을 수행하며, B의 모든 변경사항을 실시간으로 복제받습니다.
- Failback 결정:
- 관리자는 시스템을 원래 구성으로 되돌릴지 결정합니다. 이는 수동으로 시작되는 프로세스입니다.
- Failback 실행:
- 관리자가 failback을 시작하면, AWS RDS는 다음 단계를 수행합니다: a. 잠시 동안 쓰기 작업을 일시 중지합니다. b. 최종 데이터 동기화를 수행하여 A와 B가 완전히 동일한 상태가 되도록 합니다. c. DNS 레코드를 업데이트하여 트래픽을 다시 인스턴스 A로 리디렉션합니다.
- 역할 전환:
- 인스턴스 A가 다시 주 DB 역할을 맡습니다.
- 인스턴스 B는 대기 DB 역할로 전환됩니다.
- 클라이언트 재연결:
- DNS 변경사항이 전파되면 클라이언트 연결이 자동으로 인스턴스 A로 전환됩니다.
- 이 과정에서 짧은 연결 중단이 발생할 수 있습니다.
- 정상 운영 재개:
- 시스템이 원래의 구성으로 돌아가고, 인스턴스 A가 모든 읽기 및 쓰기 작업을 처리합니다.
- 인스턴스 B는 다시 대기 상태로 돌아가 실시간으로 데이터를 복제받습니다.
주의사항:
- Failback은 수동 프로세스이므로, 관리자가 적절한 시점을 선택하여 수행해야 합니다.
- 프로세스 동안 짧은 서비스 중단이 발생할 수 있으므로, 영향을 최소화할 수 있는 시간에 수행하는 것이 좋습니다.
- Failback 전에 두 인스턴스가 완전히 동기화되었는지 확인하는 것이 중요합니다.
이렇게 RDS Multi-AZ 설정에서는 장애 발생 후 시스템을 원래 상태로 되돌릴 수 있는 유연성을 제공합니다. 이는 시스템의 복원력과 가용성을 높이는 데 도움이 됩니다.
참고 자료
마치며
RDS Multi-AZ Failover는 고가용성을 보장하는 강력한 기능입니다. 이를 제대로 이해하고 활용하면, 예기치 못한 장애 상황에서도 서비스의 연속성을 유지할 수 있습니다.