공부일지/클라우드 SA 교육

EC2 + ALB + Auto Scaling 기반 웹 구조 자동화 실습

박수빈98 2025. 5. 22. 17:38

오늘은 AWS 실습 최종 복습을 진행했다.

첫번째로 단일 EC2 인스턴스에 정적 웹 서버를 구성한 뒤,

ALB를 이용해 경로 기반 라우팅을 설정하고, 트래픽 증가에 따라 Auto Scaling Group이

자동으로 인스턴스를 확장하도록 구성했다.

 

1. EC2 인스턴스 프로비저닝

기본 웹 서버가 동작하도록 Apache 기반 환경을 설정하였다. OS에 따라 사용자 데이터 스크립트는 다음과 같다.

Rocky Linux

#!/bin/bash
# 시스템 패키지 업데이트
dnf update -y

# httpd 설치
dnf install -y httpd

# httpd 서비스 시작 및 부팅 시 자동 시작 설정
systemctl start httpd
systemctl enable httpd 

Ubuntu

#!/bin/bash
# 시스템 패키지 목록 업데이트
apt update -y

# apache2 설치
apt install -y apache2

# index.html 생성
echo "<h1>Hello from Ubuntu EC2!</h1>" > /var/www/html/index.html

# apache2 서비스 시작 및 부팅 시 자동 시작 설정
systemctl start apache2
systemctl enable apache2

2. ALB 구성 및 리스너 규칙 설정

  • ALB는 HTTPS(443 포트)로 외부 요청을 수신하였다.
  • 내부 Target Group은 80 포트로 연결되었다.
  • HTTPS 통신을 위해 ACM에서 인증서를 발급하였다.
  • 인증서 검증은 Route 53의 CNAME 레코드 등록을 통해 진행하였다.

HTTPS를 위해 인증서가 필요하다

리스너 규칙은 요청 경로 기준으로 설정하였다. 예를 들어 /sale, /food에 대해 서로 다른 Target Group으로 분기되도록 구성하였다.


3. 경로 기반 라우팅 구현

ALB는 다음과 같은 방식으로 트래픽을 분기한다.


 

요청  경로전달 대상
/sale 또는 /sale/* my-tg-sale Target Group
/food 또는 /food/* my-tg-food Target Group
 

각 대상 그룹에는 해당 경로에 대응되는 index.html이 포함된 EC2가 존재해야 한다. 예를 들어 /sale 요청 시 EC2 내부에 /var/www/html/sale/index.html 또는 .htaccess 라우팅 처리 등이 있어야 한다. 그렇지 않으면 404 오류가 발생한다.


4. Auto Scaling 구성

특정 서비스(/sale)에 트래픽이 집중되는 상황을 가정하여 Auto Scaling을 설정하였다. 이를 위해 다음 절차를 따랐다.

4.1. AMI 생성

  • 현재 서비스가 구성된 EC2에서 Amazon Machine Image(AMI)를 생성하였다.
  • Apache 설정, 웹 파일, 사용자 데이터 등이 포함되어야 한다.

4.2. Launch Template 생성

  • 위에서 만든 AMI를 기반으로 인스턴스를 자동 생성할 수 있도록 템플릿을 구성하였다.
  • 인스턴스 타입, 키 페어, 보안 그룹, 사용자 데이터 등을 포함하였다.

4.3. Auto Scaling Group 생성

  • Launch Template과 연결하여 Auto Scaling Group을 생성하였다.
  • 최소 인스턴스 수: 1
  • 최대 인스턴스 수: 4
  • 선호 인스턴스 수(desired capacity): 2
  • Target Group은 /sale 경로를 처리하는 my-tg-sale과 연결하였다.

4.4. Scaling 정책 설정

  • 스케일 아웃 정책: 평균 CPU 사용률이 70% 이상일 경우 인스턴스를 1개 추가

  • 스케일 인 정책: 평균 CPU 사용률이 30% 이하일 경우 인스턴스를 1개 감소

 

정책 설정 후 EC2 인스턴스에 부하 테스트 명령(yes > /dev/null &)을 실행하면 CPU 사용률이 상승하고, 이에 따라 인스턴스가 자동으로 생성됨을 확인할 수 있다. 반대로 프로세스를 종료하면 사용률이 하락하며 인스턴스 수가 감소한다.

 

사용한 건 단순 크기 조정이었다. 나머지 정책들도 간단하게만 적으면

. 단순 크기 조정(Simple Scaling Policy)

  • 동작 방식:
    • 조건이 만족되면 정해진 인스턴스 수만큼 확장 또는 축소함
  • 예시:
    • CPU > 70% → 인스턴스 1개 추가
    • CPU < 30% → 인스턴스 1개 제거

2. 단계 크기 조정(Step Scaling Policy)

  • 동작 방식:
    • 조건이 다단계로 구성됨
    • 사용률에 따라 추가하는 인스턴스 수가 다름
  • 예시:
    • CPU > 70% → 1개
    • CPU > 90% → 2개

3. 대상 추적 조정(Target Tracking Policy)

  • 동작 방식:
    • 특정 지표(예: 평균 CPU 사용률)를 타겟으로 유지함
    • CloudWatch가 자동으로 확장/축소 결정
  • 예시:
    • 평균 CPU 사용률을 50%로 유지하도록 자동 조정

4. 예측 기반 조정(Predictive Scaling)

  • 설명: 머신러닝을 기반으로 미래 트래픽 패턴을 예측하여 미리 인스턴스를 조정함
  • 조건: 일정 기간의 모니터링 데이터가 필요함

Auto Scaling 과부화 실습

1. 인스턴스에 과부화

yes > /dev/null &

 

yes > /dev/null &

  • 설명: yes 명령어를 무한 반복하며 CPU 부하를 인위적으로 발생시킴
  • 사용 목적: Auto Scaling 테스트를 위한 부하 유도

pkill -9 yes

  • 설명: yes 프로세스를 강제 종료함
  • 사용 목적: 부하를 제거하여 스케일 인 테스트 진행

이걸로 2개의 인스턴스에 CPU 사용량 높임

CloudWatch 알람

메일이 오면서 EC2 하나가 스케일아웃 된 모습

CPU 사용량 70퍼 넘었다는 알람

그렇기에 스케일아웃 되어 인스턴스 증가했다는 알

asg 인스턴스가 생김

 

pkill -9 yes 로 해당 프로세스 죽여서 CPU 사용률 정상

 

프로세스 죽이니 낮아진 모습

 

CPU 사용률 낮아져 ScaleInAlarm

이전에 asg02가 종료되어 인스턴스가 2개로 유지되는 모습


결론

이번 실습을 통해 ALB 기반 경로 라우팅과 EC2 자동 확장 기능을 함께 구성할 수 있었다. 트래픽에 따라 유연하게 확장되는 웹 아키텍처의 기본 원리를 이해하는 데 유용한 실습이었다.

지금은 단순 크기 조정을 통해 Auto Scaling을 했지만 단계 크기 조정이랑 대상 추적 크기 조정도 많이 쓰인다고 한다.

추가적으로 실습을 진행하면 좋을 것 같다.

 

이제 추가적으로 보안 그룹, NACL, EFS 마운트 구조와 S3 웹호스팅 + CloudFront 연계 실습도 진행하겠다.