인프라의 구축보다 중요한 것은 "장애 상황에서도 서비스가 유지되는가?"이다. 이번 포스팅에서는 EC2와 RDS를 각각 강제로 종료시킨 후, 설계한 Multi-AZ 아키텍처가 어떻게 가용성을 보장하는지 테스트를 해보도록 하겠다.
1. 테스트 시나리오 및 목표
이번 테스트의 핵심은 단일 장애지점 (SPoF)의 부재를 증명하는 것이다.
- EC2 장애: 특정 가용 영역(AZ)의 서버가 다운되었을 때 Auto Scaling과 ALB의 대응 확인
- RDS 장애: 기본 DB가 가동 불능일 때 예비(Standby) DB로의 자동 전환 확인
2. EC2 인스턴스 강제 종료 테스트
테스트
ap-northeast-2a에 실행 중인 EC2 인스턴스를 콘솔에서 강제로 종료시킨다.
결과
- ALB의 대응: 로드밸런서가 중지된 인스턴스를 'Unhealthy'로 감지하고, 즉시 모든 트래픽을 2c 영역의 인스턴스로 전달한다
- Auto Scaling의 자가 치유: 설정한 Desired Capacity(2대) 를 유지하기 위해 ASG가 새로운 인스턴스를 자동으로 생성한다
결론: 개별 인스턴스에 장애가 발생해도 ALB와 ASG의 협업을통해 서비스 중단없이 가용성이 보장됨을 확인했다.
3. RDS 데이터베이스 강제 중단 테스트
테스트
RDS 콘솔에서 재부팅을 실행하여 의도적인 장애 상황을 만든다.
결과
- 자동 교체: 기존 Primary DB가 다운되면 AWS가 자동으로 DNS 정보를 변경하여 Standby DB를 새로운 Primary로 승격시킨다
- 연결 지속성: EC2 애플리케이션 서버는 엔드포인트 주소를 그대로 사용하므로, 짧은 전환 시간 이후 별도의설정변경 없이 DB와 다시 연결된다
결론: RDS Multi-AZ 설정을 통해 데이터 유실 없이 몇 분 내에 서비스가 정상 복구되는 고가용성을 검증했다.
최종 회고: 고가용성 설계의 가치
이번 테스트를 통해 이론으로만 알던 Multi-AZ의 실제 작동 원리를 체감했다.
- 자동화의 중요성: 관리자가 개입하지 않아도 인프라 스스로 장애를 판단하고 복구하는 과정이 인상적이었다
- 보안과 가용성의 조화: SSM 접속을 통한 안전한 관리 환경 속에서도 장애 대응 체계는 완벽하게 작동함을 확인할 수 있었다
