AWS ECS Fargate 활용하기, 서비스 생성부터 오토스케일링까지

ECS Fargate로 컨테이너를 운영하면서 정리한 순서와 개념이다. 서버를 직접 관리하지 않고 컨테이너만 올리면 되는 게 Fargate의 핵심이다.

CODE 영역

• Dockerfile 생성
• buildspec.yaml 작성

AWS 영역 준비 순서

• 클러스터 생성
• 리포지토리(ECR) 생성
• 작업 정의(Task Definition) 생성
• 보안 그룹(SG) 생성
• Application Load Balancer 생성 (미리 해둬야 편함)
• Target Group 생성 (로드밸런서 생성할 때 미리 생성, 필수는 아님)
• 서비스 및 작업 생성

ALB를 먼저 만들어두라는 게 실무 팁이다. 서비스를 생성하는 화면에서 ALB를 고르게 되는데, 그 자리에서 새로 만들려면 화면을 왔다 갔다 해야 한다.

서비스와 작업의 차이

• 서비스는 항상 돌아가는 개념
• 작업(Task)은 1회성 개념이 강함
• 하지만 서비스도 내부에서는 작업을 실행한다

정리하면 작업 정의는 설계도, 작업은 그 설계도로 만든 컨테이너 인스턴스, 서비스는 지정한 개수만큼 작업을 항상 유지시켜주는 관리자다.

작업이 죽으면 서비스가 새로 띄운다. 웹 서버처럼 계속 떠 있어야 하는 건 서비스로, 배치 작업처럼 한 번 돌고 끝나는 건 단독 작업으로 실행한다.

예약된 작업 (크론)

정기적으로 도는 배치는 EventBridge 규칙으로 스케줄을 걸어 작업을 실행한다. 별도 크론 서버를 둘 필요가 없다.

서비스 생성 시 설정 항목

• 시작 유형 — Fargate
• 작업 정의, 클러스터 선택
• 서비스 이름 생성 (생성 후 이 이름이 노출됨)
• 작업 개수 — 몇 개의 작업을 돌릴지 선택. 후에 나오는 오토스케일링과 콤보를 이룰 수 있음

최소 정상 상태 백분율 및 최대 백분율

말이 좀 어려운데 배포 시 적용되는 값이다.

최소 정상 백분율은 작업 개수를 10개 했을 때, 배포 시도 시 백분율이 50%면 5개가 새로운 배포를 위해서 쓰일 수 있다는 뜻이다. 나머지 5개는 계속 요청을 받아야 하므로 건드리지 않는다.

최대 백분율은 작업 개수가 10개일 때 백분율이 200%면 추가로 10개를 생성한 후에 거기에 새 배포를 넣고 교체하는 방식이다.

이걸 이해하기 위해서 배포를 50번 넘게 한 것 같다.

조합에 따라 배포 방식이 달라진다

최소 / 최대	동작
100% / 200%	기존을 유지한 채 새 작업을 전부 띄우고 교체. 무중단이지만 리소스가 2배 필요
50% / 100%	절반씩 내리고 올린다. 리소스는 아끼지만 배포 중 용량 감소
0% / 100%	전부 내리고 새로 올린다. 다운타임 발생

운영 서비스라면 100/200을 기본으로 두는 게 안전하다. 비용이 걱정되면 50/100으로 하되, 트래픽이 적은 시간대에 배포하는 식으로 운영한다.

네트워크 구성

Fargate는 awsvpc 네트워크 모드를 쓴다. 작업마다 ENI가 하나씩 붙어서 자체 IP를 갖는다.

• 프라이빗 서브넷에 두고 ALB만 퍼블릭에 노출하는 게 기본 구성이다
• 프라이빗 서브넷에서 ECR 이미지를 받으려면 NAT 게이트웨이 또는 VPC 엔드포인트가 필요하다. 이걸 빠뜨리면 작업이 이미지를 못 받아 계속 실패한다
• NAT 게이트웨이는 비용이 꾸준히 나가므로, ECR·S3·CloudWatch Logs 엔드포인트를 만드는 쪽이 저렴할 수 있다

처음 구축할 때 "작업이 PENDING에서 멈춰 있다"는 문제의 상당수가 이 네트워크 설정이다.

오토스케일링

어렵지 않게 설정 가능하다. 하지만 커스텀하고 복잡한 지표를 원하면 CloudWatch에서 작업하여 적용해야 한다.

기본 제공되는 지표는 CPU, 메모리, 요청 수(ALBRequestCountPerTarget) 세 가지다. 응답 지연 시간 같은 다른 지표를 쓰고 싶으면 커스텀 지표를 만들어야 한다.

# 대상 추적 정책 예시
지표: ECSServiceAverageCPUUtilization
목표값: 70
스케일 아웃 쿨다운: 60초
스케일 인 쿨다운: 300초

스케일 인 쿨다운을 길게 잡는 게 요령이다. 트래픽이 출렁일 때 작업을 내렸다 올렸다 반복하면 오히려 불안정해진다.

처음 구축할 때 자주 막히는 것들

• 작업이 계속 재시작된다 — 헬스체크 실패. ALB 헬스체크 경로가 실제로 200을 반환하는지, 애플리케이션 부팅 시간보다 유예 기간이 긴지 확인
• PENDING에서 안 넘어간다 — 이미지를 못 받는 경우. NAT/VPC 엔드포인트, ECR 권한 확인
• 로그가 안 보인다 — 작업 정의에 awslogs 드라이버 설정 누락
• 환경 변수에 비밀값을 넣었다 — Secrets Manager나 SSM Parameter Store를 쓰고 작업 정의에서 참조하는 게 맞다
• 배포가 오래 걸린다 — ALB 등록 해제 지연(deregistration delay) 기본값이 300초다. 30~60초로 줄이면 배포가 빨라진다

정리

• ALB와 타깃 그룹은 미리 만들어두면 서비스 생성이 수월하다
• 서비스는 상시, 작업은 일회성. 배치는 EventBridge로 스케줄
• 최소/최대 백분율은 배포 전략을 결정한다. 무중단이면 100/200
• Fargate는 awsvpc 모드. 프라이빗 서브넷이면 NAT 또는 VPC 엔드포인트 필수
• 오토스케일링 기본 지표는 CPU·메모리·요청 수. 그 외는 CloudWatch 커스텀
• 스케일 인 쿨다운은 길게 잡는다