[AWS-ECS] Cluster & Service AutoScaling

Transcript

1. 육승찬 username.loup@gmail.com ECS 클러스터 & 서비스 오토스케일링
2. ECS 확장성이 뛰어난 고성능 컨테이너 오케스트레이션 서비스로서, Docker 컨테이너를 지원하며 AWS에서 컨테이너식 애플리케이션을 쉽게 실행하고 확장 및 축소할 수 있습니다. a
3. “쉽게 실행하고 확장 및 축소할 수 있습니다” 24시간 손스케일링 오토스케일링
4. 이런게 쉽지 않다더라 - 1 두 가지(클러스터, 서비스) 오토스케일링을 관리
5. 이런게 쉽지 않다더라 - 2 클러스터 인스턴스가 오토스케일링 될때, 서비스의 작업을 적절하게 배치 instance instance instance instance Auto Scaling group instance instance instance instance Auto Scaling group
6. 이런게 쉽지 않다더라 - 3 서비스가 오토스케일링 될때 클러스터 인스턴스에 분배될 수 있어야 함 instance instance instance Auto Scaling group instance instance instance instance Auto Scaling group Task
7. ECS 클러스터 & 서비스 오토스케일링 1. 오토스케일링 쉽게 시작하기 2. 오토스케일링 적용하기 3. 오토스케일링 날개 달기
8. 오토스케일링 쉽게 시작하기 - 1 오토스케일링이 필요한 서비스와 아닌 서비스의 클러스터를 분리하기 Availability Zone #1 ECS Instance ECS Instance ECS Cluster AZ #1 ECS Instance ECS Cluster AZ #1 ECS Instance ECS Cluster
9. 오토스케일링 쉽게 시작하기 - 2 서비스의 배치 전략 세우기 (Placement Strategy) Availability Zone #1 ECS Instance – A ECS ECS Instance - B Spread (InstanceId) 1 2 3 4
10. 오토스케일링 쉽게 시작하기 - 2 서비스의 배치 전략 세우기 (Placement Strategy)
11. 오토스케일링 쉽게 시작하기 - 3 서비스 작업의 크기 정하기 • 여유 메모리 400MB 이상 잡아두기 • 최소 2개 이상 추천 • 웹 애플리케이션용 시작점으로 300~500MB 권장 ECS Instance (t2.small) 1vCPU 2GiB Task per 206CPU 412Mib Task per 412CPU 824Mib 여유 메모리 400mb 제외
12. 오토스케일링 쉽게 시작하기 – 4 오토스케일링 룰 정하기 • 최소 백분율 100% 유지하기 100% 아래로 잡을 수도 있지만 서비스의 장애가 발생하는 포인트가 될 수 있음 • 스케일 아웃은 느슨하게, 스케일 인은 엄하게 처리량이 줄어드는 건 장애 요인이 될 수 있음
13. 클러스터 인스턴스 오토스케일링 1. 서비스의 작업이 언제라도 실행될 수 있게 리소스 확보 2. CPU, MEM 사용률에 따라 스케일링 • MemoryReservation • MemoryUtilization • CPU Utilization
14. 클러스터 인스턴스 오토스케일링 – 리소스 확보 예약된 메모리가 70% 이상 4분 지속 => 스케일 아웃 지표: MemoryReservation 조건: >= 70 기간 4 / 4 작업: 인스턴스 1 추가 ECS Instance (t2.medium) 2vCPU 4GiB AZ-1 Task per 860Mib (860 * 3) / 4096 * 100 = 63% ECS Instance (t2.medium) 2vCPU 4GiB AZ-1 ECS Instance Task per 860Mib (860 * 4) / 4096 * 100 = 84% ECS Instance
15. 클러스터 인스턴스 오토스케일링 – 리소스 확보 예약된 메모리가 40% 이하 20분 지속 => 스케일 인 지표: MemoryReservation 조건: <= 40 기간 20 / 20 작업: 인스턴스 1 삭제 ECS Instance (t2.medium) 2vCPU 4GiB AZ-1 ECS Instance Task per 860Mib (860 * 4) / 8192 * 100 = 42% ECS Instance ECS Instance (t2.medium) 2vCPU 4GiB AZ-1 ECS Instance Task per 860Mib (860 * 3) / 8192 * 100 = 31% ECS Instance
16. 클러스터 인스턴스 오토스케일링 – CPU or MEM • 클러스터 CPU Utilization = 클러스터의 모든 작업이 사용중인 유닛 클러스터 인스턴스 전체의 유닛 합 ∗ 100 • Ex) t2.medium 클러스터 인스턴스 1개에 300 CPU 유닛을 사용하고 있는 작업 2개 • 300 ∗ 2 2048 ∗ 1 ∗ 100 = 29% • 클러스터 Mem Utilization = 클러스터의 모든 작업이 사용중인 메모리 클러스터 인스턴스 전체의 메모리의 합 ∗ 100 • Ex) t2.medium 클러스터 인스턴스 1개에 420MB 메모리를 사용하고 있는 작업 2개 • 420 ∗2 4096 ∗1 ∗ 100 = 20%
17. 클러스터 인스턴스 오토스케일링 – CPU or MEM • 클러스터 인스턴스 CPU 사용률 평균 60% 이상 1분 지속 => 스케일 아웃 지표: CPUUtilization 조건: >= 60 기간 1 / 1 작업: 인스턴스 1 추가 • 클러스터 인스턴스 메모리 사용률 평균 60% 이상 1분 지속 => 스케일 아웃 지표: MemoryUtilization 조건: >= 60 기간 1 / 1 작업: 인스턴스 1 추가
18. 서비스 오토스케일링 1. CPU, MEM 사용률에 따라 스케일링 • CPU Utilization • MemoryUtilization
19. 서비스 오토스케일링 – CPU or MEM • 서비스 CPU Utilization = 모든 작업이 사용중인 유닛 사용량 작업 1개당 유닛 제한 ∗ 전체 작업 수 ∗ 100 • Ex) 400 CPU 유닛 제한 작업 2개가 각 150 CPU 유닛 사용 • 150 ∗ 2 400 ∗ 2 ∗ 100 = 37.5% • 서비스 Mem Utilization = 모든 작업이 사용중인 메모리 사용량 작업 1개당 메모리 제한 ∗ 전체 작업 수 ∗ 100 • Ex) 420MB 제한 작업 2개가 각 250MB 메모리 사용 • 250 ∗ 2 420 ∗ 2 ∗ 100 = 59.5%
20. 서비스 오토스케일링 – CPU or MEM • 서비스 CPU 사용률 평균 60% 이상 1분 지속 => 스케일 아웃 지표: CPUUtilization 조건: >= 60 기간 1 / 1 작업: 작업 1 추가 • 서비스 메모리 사용률 평균 60% 이상 1분 지속 => 스케일 아웃 지표: MemoryUtilization 조건: >= 60 기간 1 / 1 작업: 작업 1 추가 • 서비스 CPU 사용률 평균 30 미만 10분 지속 => 스케일 인 지표: CPUUtilization 조건: < 30 기간 10 / 10 작업: 작업 1 삭제
21. 오토스케일링 날개 달기 • 클러스터 인스턴스가 스케일 아웃 될 때, 작업 재배치 해주기 (Rebalancing) • 클러스터 인스턴스가 스케일 인 될 때, 드레이닝 해주기 (Draining) instance instance instance instance Auto Scaling group instance instance instance instance Auto Scaling group
22. 오토스케일링 날개 달기 - Rebalancing • 오토스케일링 그룹의 알림(Notification) 사용 (알림 => SNS => Lambda) • ECS 서비스의 새배포 기능 이용
23. 오토스케일링 날개 달기 - Rebalancing Auto Scaling group instances 인스턴스 1 추가 Amazon SNS AWS Lambda STEP 1 STEP 3 인스턴스가 ECS에 붙었나? 아니오 Amazon ECS 예 STEP 5 새배포 실행 STEP 4 Delay 10 STEP 2 ASG 그룹 알림(Notification) Hook
24. 오토스케일링 날개 달기 - Draining • 오토스케일링 그룹의 수명주기(Lifecycle) 사용 (수명주기 => SNS => Lambda) • ECS 서비스의 드레이닝 기능 이용
25. 오토스케일링 날개 달기 - Draining Auto Scaling group instances 인스턴스 1 삭제 Amazon SNS AWS Lambda STEP 3 Amazon ECS 드레이닝 작업 개수 = 0 아니오 예 STEP 5 ECS API Call STEP 4 Delay 10 수명주기 TTL 만료 STEP 1 STEP 2 ASG 그룹 수명주기(Lifecycle) 종료 Hook 인스턴스가 드레이닝 상태 ? 아니오 예 STEP 6 수명주기 Hook 종료
26. T2 계열 인스턴스 사용시 TIP • 클러스터 인스턴스 오토스케일링 룰에 크레딧 조건 추가하기 크레딧 없으면 죽은 서버라고 생각해야… • 한대 정도는 무한 크레딧 옵션을 켜고 ALB에 붙여놓기 ASG가 무한 크레딧 옵션을 지원 안함 • ASG의 종료 정책을 “NewestInstance” 사용하기 크레딧이 축척된 인스턴스가 날라가면 아깝잖아요
27. 오토스케일링 Before Availability Zone #1 ECS Instance ECS Instance ECS
28. 오토스케일링 After Application Load Balancer ECS instance Auto Scaling group instances Amazon SNS AWS Lambda • Rebalancing • Draining CloudWatch
29. 마치며.. • 오늘 발표드린 내용은 방법중 하나일 뿐이고 정답은 아니에요. • 앞에 말씀드린 리발란싱은 깃허브 ECS-Agent 레포지토리 이슈에 아직도 열려 있는 상태입니다. (알림 받아놓으시면 더 좋은 방법을 얻을 수도...) • 지금도 여전히 서비스를 운영하며 더 나은 방법을 찾고 있습니다. (어쩌면 저는 그게 Fargate 서울 출시라고 생각하고요..)