AWS 멀티 AZ 고가용성 웹 아키텍처 실습기 – Route53·ALB·ASG·Aurora로 완성한 실제 구축 경험

AWS 멀티 AZ 고가용성 웹 아키텍처 실습기 – Route53·ALB·ASG·Aurora로 완성한 실제 구축 경험
이번 실습의 목표는 단순히 EC2 인스턴스를 하나 띄우는 것이 아니었다. “정상 서비스 경로”와 “장애 대응 경로”를 모두 포함한 고가용성(High Availability) 아키텍처를 실제로 설계하고 구현하는 것이 핵심이었다. 구성 목표는 다음과 같았다. 정상 경로는 Route53 → ALB(Application Load Balancer) → ASG(Auto Scaling Group, 자동 확장 그룹) → EC2(Apache+PHP) → Aurora(MySQL)로 이어지도록 하고, 장애 시에는 S3 정적 웹사이트로 전환 가능한 구조를 마련하는 것이었다. 이 글은 그 과정을 처음 설계부터 테스트까지 단계별로 기록한 실습 경험기이다.

 

서론 – 단순 서버 구축을 넘어 ‘아키텍처’를 설계하다

AWS를 배우면서 가장 많이 접하는 개념이 멀티 AZ(Multi Availability Zone) 구조다. 하지만 다이어그램으로 보는 것과 직접 콘솔에서 구성하는 것은 완전히 다르다. 이번 실습에서는 VPC(가상 사설 네트워크) 설계부터 시작해 서브넷 분리, 라우팅 테이블 구성, Internet Gateway와 NAT Gateway 배치, 보안그룹 설계, Aurora Multi-AZ 구성, 그리고 Auto Scaling과 Load Balancer 연동까지 전체 흐름을 직접 연결해 보았다.
먼저 VPC를 10.0.0.0/16 CIDR 블록으로 생성하고, 두 개의 가용 영역(ap-northeast-2a, 2c)에 퍼블릭 서브넷과 프라이빗 서브넷을 각각 구성했다. 퍼블릭 서브넷에는 Internet Gateway를 통해 외부 트래픽이 들어올 수 있도록 하고, 프라이빗 서브넷은 NAT Gateway를 통해서만 외부로 나가도록 설정했다. 이 과정에서 라우팅 테이블을 퍼블릭과 프라이빗으로 분리하고, 각각 0.0.0.0/0 경로를 올바르게 지정하는 것이 핵심이었다. 이 설계 단계에서 이미 인프라의 안정성과 보안 수준이 결정된다는 것을 체감했다.
 

본론 – 단계별 구축과 실제 테스트 과정

네트워크 구성 이후 가장 중요한 단계는 보안그룹(Security Group, 가상 방화벽) 설정이었다. ALB용 보안그룹은 80번 포트를 0.0.0.0/0에서 허용했고, EC2 보안그룹은 ALB 보안그룹에서만 80번 포트를 허용하도록 참조 방식으로 설정했다. 이는 IP가 아닌 보안그룹을 기준으로 허용함으로써 인스턴스가 교체되더라도 자동으로 정책이 유지되는 구조다. Aurora DB용 보안그룹은 EC2 보안그룹에서만 3306 포트를 허용하도록 구성해 외부 접근을 차단했다.
Aurora MySQL을 생성할 때는 DB Subnet Group에 서로 다른 가용 영역의 프라이빗 서브넷을 반드시 포함시켰다. Public Access는 비활성화했고, Multi-AZ 구성을 통해 Writer와 Standby 구조를 자동으로 형성했다. 생성 후 Writer Endpoint를 확인해두고, 이를 PHP 코드에 연결 정보로 입력했다.
다음 단계는 웹 서버 구성이다. 퍼블릭 서브넷의 EC2 인스턴스를 하나 생성하고 Apache(웹 서버)와 PHP를 설치했다. /var/www/html 경로에 DB 연결 테스트 페이지를 만들고, Aurora 엔드포인트와 DB 계정 정보를 입력해 실제 연결 테스트를 진행했다. 브라우저에서 Public IP로 접속했을 때 “DB 연결 성공” 메시지가 출력되는 순간, 네트워크·보안·DB 설정이 모두 정확히 연결되었음을 확인할 수 있었다.
이후 해당 인스턴스를 기반으로 AMI를 생성하고 Launch Template을 구성했다. Auto Scaling Group을 만들 때는 인스턴스를 프라이빗 서브넷에 배치하고, 기존에 생성한 Target Group과 연결했다. Desired Capacity를 2로 설정해 최소 두 개의 인스턴스가 동작하도록 구성했다. 페이지에 hostname을 출력하도록 설정해 새로고침할 때마다 서로 다른 인스턴스가 응답하는지 확인했다. 이는 ALB가 트래픽을 정상적으로 분산하고 있다는 실질적인 증거였다.
ALB는 Internet-facing 모드로 생성하고, 두 개의 퍼블릭 서브넷을 연결했다. Listener는 HTTP 80으로 설정하고 Target Group으로 포워딩했다. ALB DNS 주소로 접속했을 때 웹 페이지가 정상 출력되는 것을 확인했다. 이후 Route53에서 A 레코드 Alias를 생성해 도메인을 ALB에 연결했다. 도메인 주소로 접속해도 동일한 결과가 나오는 것을 확인하며 서비스 경로가 완성되었다.
마지막으로 장애 대응 경로를 준비했다. S3 버킷을 생성하고 정적 웹사이트 호스팅을 활성화한 뒤, “서비스 점검 중입니다”라는 index.html 파일을 업로드했다. Route53에서 Failover 레코드를 설정해 Primary는 ALB, Secondary는 S3로 지정하고 헬스 체크를 연결했다. 만약 ALB의 헬스 체크가 실패하면 자동으로 S3 페이지로 전환되는 구조를 설계했다. 실제로 ALB 타겟 인스턴스를 일시 중지해보고 헬스 체크 변화를 관찰하며 전환 메커니즘을 이해했다.
 

결론 – 이번 실습이 남긴 기술적 통찰

이번 멀티 AZ 아키텍처 실습은 단순한 과제 수행이 아니라, 클라우드 설계의 전체 흐름을 경험한 과정이었다. 네트워크 분리의 중요성, 보안그룹 참조 방식의 안정성, DB Subnet Group 구성 원칙, 로드 밸런싱의 실제 동작, 자동 확장의 의미, 장애 대비 설계의 필요성을 하나의 구조 안에서 체험했다.
특히 인상 깊었던 점은 “정상 동작”보다 “장애 상황을 가정한 설계”였다. 단순히 서버가 동작하는 것이 아니라, 인스턴스가 교체되어도 서비스가 유지되고, 한 AZ가 장애가 나도 트래픽이 다른 AZ로 전달되며, DB는 자동으로 Standby로 전환되는 구조를 이해하게 되었다. 이것이 바로 고가용성의 본질이었다.
이번 경험을 통해 AWS를 단순히 사용하는 수준을 넘어, 인프라를 설계하고 설명할 수 있는 단계로 한 발 나아갔다고 느낀다. 향후 MRV 플랫폼이나 데이터 기반 서비스 모델을 구축할 때도 이러한 아키텍처 설계 능력이 핵심 자산이 될 것이다. 단순한 실습이었지만, 실무적 관점에서 매우 의미 있는 훈련이었다.