ECS Task Auto Scaling 정책 - 100-hours-a-week/KTB4-3rd-CLOUD GitHub Wiki
ECS Task의 Auto Scaling Group(ASG)
V2 서비스의 성장을 가정해 예상되는 운영 문제를 해결하고자, ECS on EC2 기반 애플리케이션 서버에 Auto Scaling Group(ASG)을 도입하기로 결정했다. ASG를 통해 시간대별 트래픽 편차로 발생하는 인스턴스 유휴 자원과 인프라 비용 낭비를 줄이고, 비정기적인 이벤트 트래픽 급증에도 애플리케이션의 가용성과 확장성을 확보하고자 한다.
V2의 시간대별 트래픽 유입량 분석
모여타 서비스의 타겟 그룹은 출퇴근을 하는 직장인으로 평균적인 출퇴근 시간대는 7시9시, 17시19시로 출퇴근 시간대와 그 외의 시간대의 트래픽 유입량의 차이가 뚜렷한 서비스이다. 따라서 성장 지표 문서에서 시간대별 유입량에 대해 V2 기준 DAU 36,000명, 사용자당 하루 2세션(출근·퇴근 각 1회), 세션당 HTTP 요청 13건을 가정한다.
일일 요청의 70%가 출근·퇴근 피크 구간 합계 4시간에 발생하면 해당 구간의 평균 부하는 45.5 RPS다. 시간대 내 순간 피크를 평균의 2배로 가정해 순간 피크 목표를 91 RPS로 둔다. 45.5 RPS는 하루 1세션 가정의 순간 피크 값으로 가정한다. 지표는 아래와 같이 확인할 수 있다.
| 산정 지표 | 하루 1세션 가정 | 하루 2세션 가정 |
|---|---|---|
| 일일 HTTP 요청량(DAU 36,000 × 세션 수 × 세션당 13건) | 468,000건 | 936,000건 |
| 출퇴근 피크 유입량(일일 요청의 70%) | 327,600건 | 655,200건 |
| 출퇴근 피크 평균(총 4시간 기준) | 22.75 RPS | 45.5 RPS |
| 순간 피크(시간대 평균의 2배) | 45.5 RPS | 91 RPS |
| 평시 평균(나머지 20시간) | 1.95 RPS | 3.9 RPS |
위의 일일 전체 HTTP 요청량과 출퇴근 시간대와 평시 시간대의 요청 간의 차이를 지표로 정리했다. 이에 따라 출퇴근 시간대와 평시와 트래픽 유입량의 차이는 11.7배 차이가 발생한다.
| 지표 | 평시(피크 외 20시간) | 출퇴근 시간대(평균, 합계 4시간) | 순간 피크 | 비교 |
|---|---|---|---|---|
| 일일 요청 비중 | 30% | 70% | — | 하루 요청의 대부분이 4시간에 집중 |
| 해당 구간 요청량 | 280,800건 | 655,200건 | — | 출퇴근 4시간 요청이 평시 20시간 합계의 약 2.33배 |
| 평균 유입량 | 3.9 RPS | 45.5 RPS | — | 출퇴근 시간대 평균은 평시의 11.7배; 순간 피크는 23.3배 |
| 피크 유입량 | — | — | 91 RPS | |
| 평시 대비 증가량 | 기준 | +41.6 RPS | +87.1 RPS | 각각 약 +1,067%, +2,233% |
출퇴근 시간에 평시 인스턴스와의 유입량의 차이점으로 유휴 인스턴스 용량이 있기 때문에 인프라 비용 누수 상황이 발생한다. (인프라 비용 비교, 시간대 별 트래픽 유입량 수치화)
ASG 구성은 온디멘드(On-Demand)와 스팟(Spot) 인스턴스를 조합해 비용을 최적화할 수 있다. 여유 공간을 가진 instance의 효율적인 비용 관리를 위해 기존 온디멘드(On-demand) 대비 t3.small의 Spot 인스턴트는 최대 90%까지 저렴하다. (task 스펙 별 인프라 비용 표로 제시)
(절감되는 인프라 비용 차이 표 제시)
가용성 관점
REST·WebSocket 서버의 분리 후 다중 인스턴스를 ECS Cluster에 등록해 Container instances 로 관리하며 가용성을 보장한다.
(ECS Service 동작 방식) (rest task instance가 다운되는 경우 롤백 등등) (V2부터 무중단 배포를 도입 -> V2부터 왜 바뀌었는지 작성 필요)
확장성 관점
스파이크 트래픽에 대한 확장성 -> 서버 다운이 발생할 수 있는 부분
(평시 출퇴근길 트래픽 이외에 비정기적으로 행사나 이벤트 인근 주변에 트래픽 발생을 가정) (이런 경우 빠르게 확장이 필요함) (spot 인스턴스를 활용) (spot 인스턴스의 단점을 어떻게 처리해야할 지를 추후 과제로 전달) (spot 인스턴스는 AWS 인프라 자원에서 금방 회수될 수 있기 때문에 처리하는 API를 지정이 필요할 것같음)
ECS Service Auto Scaling 방식
AWS ECS Capacity Provider(용량 공급자)
Application-First
(내용 정리 필요)
- 인프라의 추상화
- 선언적 인프라 (IaC)
- 비즈니스 가치 집중
스케일링 정책(Scaling Policy)
트래픽 외에 CloudWatch 지표(Metric) 기준으로 언제, 어떤 기준으로 인스턴스를 Scale-out 하고 Scale-in을 USE method 지표(CPU 사용률, 네트워크 입출력, Disk I/O)와 애플리케이션 지표, 사용자가 정의한 서비스 커스텀 지표 등을 기준 삼아 트래픽뿐만 아니라 리소스 사용량과 애플리케이션 상태까지 반영해 안정적인 운영을 가능하게 해준다.
- 수동 스케일링
- 예약 스케일링
- 동적 스케일링
- 예측 스케일링
REST Task Scale-out·Scale-in 정책
REST Task 스펙
(부하테스트 지표 기반으로 수용 가능한 임의의 REST Task 스펙 결론)
max min desired 정리
ASG의 REST EC2 인스턴스 생명 주기 정책
ASG EC2 인스턴스 Health Check
ECS 설정 후 실험 테스트도 문서로 따로 작성