지난 1편에서는 프로젝트의 근간이 되는 네트워크 (VPC, Subnet, Gateway) 환경을 탄탄하게 구축해보았다.
이번에는 구축된 네트워크 위에 실제 애플리케이션이 구동될 컴퓨팅 자원(EC2)을 올리고, 트래픽을 효율적으로 분산해 주는 로드밸런서(ALB)를 설정하여 가용성을 극대화하는 것을 목표로 한다.
1. 아키텍쳐 설계 및 보안 전략
이번 단계의 핵심은 '폐쇄적인 보안'과 '유연한 확장성'이다.
보안 그룹 체이닝
단순히 포트를 여는 것이 아니라, 보안 그룹 간의 신뢰 관계를 설정한다
- ALG SG: 모든 외부 트래픽(80) 수용
- EC2 SG: 오직 ALB 보안 그룹의 ID로부터 오는 트래픽만 허용
이렇게 체이닝을 걸면, ALB를 거치지 않은 비정상적인 접근은 인프라 내부로 들어올 수 없다
Bastion Host 없는 관리 (AWS SSM)
프라이빗 서브넷에 있는 서버는 외부 SSH(22번포트) 접속이 불가능하다. 이를 해결하기 위해 IAM 역할을 부여하고 SSM Session Manager를 도입한다. 덕분에 키 페어 유출 걱정 없이 웹 브라우저에서 안전하게 서버를 관리할 수 있게 되었다.
2. 골든 이미지(AMI) 생성 및 서버 표준화
확장성 있는 인프라를 위해, 언제든 동일한 성능의 서버를 즉시 찍어낼 수 있는 '골든 이미지' 환경을 만든다
Nginx 및 환경 세팅 (User Data)
기준이 될 EC2를 생성할 때 User Data 스크립트를 사용하여 초기 환경 설정을 자동화 했다.
# Nginx 설치 및 실행
sudo su -
dnf update -y
dnf install nginx -y
systemctl start nginx
systemctl enable nginx
# 가용 영역(AZ) 식별용 테스트 페이지 생성
echo "<h1>Hello from project1-app-ec2-a (AZ: ap-northeast-2a)</h1>" > /usr/share/nginx/html/index.htmlAMI (Amazon Machine Image) 제작
설정이 완료된 서버를 기반으로 AMI를 생성했다. 이 이미지는 이후 Auto Scaling이새로운 서버를 띄울 때 사용할 '완성된 설계도'가 된다.
3. 고가용성을 위한 ALB 및 ASG 구축
이제 준비된 설계도를 바탕으로 트래픽에 따라 스스로 대응하는 시스템을 구성한다
ALB (Application Load Balancer)
사용자의 요청을 받아 건강한 서버로만 전달하는 관문이다. 1편에서 만든 두 개의 public subnet에 걸쳐 배치하여 리전 수준의 고가용성을 확보했다.
시작 템플릿 (Launch Template) & ASG (Auto Scaling Group)
- 시작 템플릿: 앞서 만든 커스텀 AMI와 web-app-sg 보안 그룹을 사용하여 서버 생성 규칙을 정의했다
- Auto Scaling Group: 두 가용 영역의 Private App Subnet을 대상으로 설정했다
- Desired Capacity: 2 (평소 유지할 서버 대수)
- Health Check: ELB 유형으로 설정하여 ALB가 직접 서버의 상태를 체크하도록 했다.
4. 최종 결과 및결론
ALB DNS 주소로 접속하여 부하 분산과 자동 복구를 최종 확인했다.
- 부하 분산 확인: 브라우저 새로고침 시 Server in 2a와 Server in 2C가 번갈아 출력되며 트래픽이 분산됨을 확인했다
- 보안 검증: 22번 포트가 닫힌 상태에서 오직 SSM을 통해서만 관리 접속이 가능함을 확인했다
결론적으로, Security Group Chaining으로 보안을 챙기고, SSM으로 관리 편의성을 높였으며, ASG를 통해 진정한고가용성 인프라의 기틀을 마련했다.
다음 3편에서는 이 서버들의 데이터를 안전하게 저장하고 관리할 Database Tier (RDS) 구축 과정을 다뤄보겠다.
