Cloud

Web Service 3 Tier Architecture (3) - AutoScaling

dog-pawwer 2025. 4. 6. 23:35
반응형

1. Auto Scaling 설정

우리가 원하는 최종 아키텍쳐에서는 가용성을 위해 뒷단 서버가 Auto Scaling 되는 것을 원했다.

  • 기존 인스턴스 → [작업] → [인스턴스에서 템플릿 생성]을 하면,
    • 자동으로 해당 인스턴스 기반으로 한 AMI가 생성된다.

  • 하지만 이 방식은 AMI 이름이 자동으로 정해져서 헷갈릴 수 있고,
  • AMI를 명시적으로 관리하지 않으면 추적이 어렵기 때문에,
  • 직접 AMI를 먼저 만든 다음 → Launch Template에서 선택하는 방식이 더 안전하다.

 

1-1. AMI 이미지 생성

  • EC2-web-3tier-nginx를 기반으로 AMI 이미지를 만들어보자.
    • 그 전에 대상그룹에서 Healthy 상태인지 확인하고! (안에 Nginx 제대로 돌아가는 지 확인한 뒤 이미지 만들 것)
    • sudo systemctl enable nginx 로 재부팅 시 자동 실행도 등록해둔다.

 

1-2. 시작 템플릿 생성

  • AMI가 (대기 중) → (사용 가능)으로 바뀔 때 까지 대기
  • [인스턴스] → [시작 템플릿] → [시작 템플릿 생성]
  • 이름 : launch-template-web-3tier-nginx
  • 이미지 : 내 AMI > web-3tier-nginx-ami

  • 인스턴스 유형, 보안 그룹, 키페어
  • 네트워크 : 서브넷은 “시작 템플릿에 포함하지 않음”
    • Auto Scaling Group이 실제로 인스턴스를 배치할 VPC / 서브넷을 직접 지정

 

1-3. Auto Scaling Group

  • [좌측 메뉴의 하단] → [Auto Scaling 그룹] → [생성]

시작 템플릿 선택

  • Auto Scaling 그룹 이름 : asg-3tier-web-nginx
  • 시작 템플릿 : launch-template-web-3tier-nginx (직전 만든 템플릿)

인스턴스 시작 옵션 선택

  • VPC : vpc-web-3tier
  • 서브넷 : NGINX가 있을 프라이빗 영역 가용 영역 2개 이상 선택
    • subnet-web-3tier-nat-Azone
    • subnet-web-3tier-nat-Czone

 

다른 서비스와 통합

  • 로드 밸런싱 : 기존 로드 밸런서에 연결
    • 대상 그룹 선택 : TG-web-3tier
  • VPC Lattice 통합 옵션 : 서비스 없음
  • 상태 확인 - ELB 상태 확인 켜기
    • 유예 기간 : 약 60초

그룹 크기 및 크기 조정 구성

  • 원하는 용량 : 1
  • 원하는 최소 용량 : 1
  • 원하는 최대 용량 : 2 ~ 5 사이 값 (현재 2)
  • 대상 추적 크기 조정 정책
    • 평균 CPU 사용률 대상 값 = 80 (%)
  • 나머지 기본
  • 모니터링 : CloudWatch 내에서 그룹 지표 수집 활성화

알림 추가

  • X

태그 추가

  • Name : EC2-web-3tier-nginx-asg

검토

  • (기존 수동으로 만든 nginx는 일단 중지시켜놓자)

 

2. 부하 테스트

2-1. 세부 모니터링

  • Auto Scaling 그룹 → [편집] → 하단 [인스턴스 관리]
    • = CPU 모니터링 대상 인스턴스

  • 해당 인스턴스 → [모니터링 및 문제 해결] → 세부 모니터링 관리
    • = 세부 모니터링을 1분 동안 활성화할 수 있다.
    • → EC2 콘솔에 인스턴스에 대한 1분 기간의 모니터링 그래프가 표시된다.

  • 우리는 Private Subnet에 인스턴스가 있으니까, 바로 콘솔로 확인할 수 없고,
  • OpenVPN을 켜고 터미널로 들어가서 확인해보자.

 

2-2. 부하 걸기

sudo yum install stress -y
stress -c 2
  • stress 명령어로 CPU 부하를 인위적으로 준다.
  • 현재 우리 인스턴스는 micro (2개의 vCPU)이므로 CPU 2개를 풀로 사용하도록 부하를 주어본다.

  • top 명령어로 확인한 CPU 자원 사용률은 50% 50% 로 100%가 되는걸 볼 수 있고,
  • AWS 모니터링 툴에서도 100% 까지 치솟는 걸 볼 수 있다.

⇒ 예상 : 그럼 AutoScaling이 제대로 동작했는지 확인해보자.

 

2-3. Auto Scaling 확인

Auto Scaling 그룹 - 인스턴스 관리

  • C존에 하나가 더 올라간 걸 볼 수 있다.

  • [활동]

 

Target Group - 등록된 대상

 

2-4. 축소 확인

  • Ctrl + c 로 부하를 끄고 축소되는지 확인해보자.
  • 먼저 CPU 자원 사용률은 80% 밑으로 떨어졌다.

  • 그러나 바로 인스턴스가 Terminating 되지는 않는다.
    • 인스턴스를 끄는 동작은 매우 민감한 문제이기 때문에 “유예 기간”이 있다.
    • 빠른 시간 내에 끄고 싶다면 Auto Scaling → [편집] → [상태 확인 유예 기간]을 줄여주자.

축소 확인

 

2-5. 그룹의 인스턴스 종료

  • 일시적으로 그룹의 인스턴스들을 종료하려면 원하는 용량과 최소 용량을 0으로 지정
  • 인스턴스를 영구적으로 종료하려면 자동 확장 그룹을 삭제해야 함

참고

  • 실무에서는 실제로 계속 코드를 수정하여 변경사항을 서버에 올릴 것이다.
  • Auto Scaling Group(ASG)는 ‘기존에 지정한 AMI 기반’으로만 인스턴스를 만들기 때문에, 최신 코드나 설정이 반영되지 않는다.
    • ⇒ CI/CD + 시작 템플릿 갱신 방식을 이용하야 한다.
    • (최후에는 Terraform으로 시작템플릿을 갱신하는 방법까지 적용해보자)
반응형
저작자표시 (새창열림)