일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- python
- visualizing
- ECS
- 애자일
- data
- keras
- Project
- angular
- DANAWA
- instance
- 프로젝트
- adaptive life cycle
- Method
- matplotlib
- 크롤링
- webcrawling
- Agile
- analyzing
- data analyze
- algorithm
- pandas
- AWS
- Crawling
- Scrum
- TypeScript
- opencv
- 자바스크립트
- 다나와
- tensorflow
- javascript
Archives
- Today
- Total
LiJell's 성장기
ECS EC2 Spot instance scaling 속도 개선 방법 본문
반응형
개요
이 글을 쓰게된 이유는 비용 절감을 위해 ECS Fargate에서 ECS EC2 Spot instance로 전환하면서 발생한 문제로 작성하게 됐다. Capacity Provider로 Fargate 이용시 task scaling이 빠른데 비하여, EC2 Spot instance를 이용시 instance 생성할 때 그리고 생성된 isntance를 capacity provider에 배치할 때 두번 시간이 들기 때문에 instace에 배정될 task 뿐만 아니라 instance의 scaling out 속도 개선이 절실했다. Amazon EC2 Auto Scaling의 웜 풀 등 다른 대안도 있지만, 혼합 인스턴스 그룹은 지원하지 않기 때문에 다른 부분에서 최적화가 필요했다.
방법
1. Capacity provider step scaling sizes
minimumScalingStepSize
와maximumScalingStepSize
는 scaling을 몇개식 할 수 있는지에 대한 설정이다. 따라서, 두 옵션을 조정하여 이용하면 좀 더 공격적인 scaling이 가능해진다. 특히maximumScalingStepSize
이 낮을경우 scaling의 속도가 오래걸려 결과적으로 deployment가 느려지는 점을 유의 할 필요가 있다.
2. Instance warm-up period
- warm-up period가 끝난 이후 ASG metrics에 반영되게 된다. 그 후 Cluster Auto Scaling(CAS)이 다음 iteration 때 몇개의 instance가 더 필요한지 계산하게 된다.
- default
instanceWarmupPeriod
는 300 seconds 이며, capacity provider을 새로 생성할 땐CreateCapacityProvider
, 이미 있을 떈UpdateCapacityProvider
로InstanceWarmupPeriod
를 조절하여 더 반응이 좋은 scaling이 가능해진다. 예를 들어, instance large 경우 2-3분 정도의 initializing time을 가지고, xlarge instance 타입경우 5-10분 정도 시간이 걸린다고 한다. 따라서 xlarge instance 하나에 더 많은 task를 띄우는 방법도 있지만, instance scaling이 더 느리기 때문에 large instance를 좀 더 공격적으로 scaling 하는 방법이 더 나을 수 있다.
*InstanceWarmupPeriod
: 새 인스턴스가 스케일링 작업에 투입되기 전에 준비하는 시간(s)을 설정 할 수 있다.
3. Spare capacity
- Spare capacity는 두가지 접근 방식이 있다.
Target Capacity
는 클러스터에 얼마나 많은 여유 분의 capacitor을 가질 수 있는가에 대한 설정값이다. 예를들어Target Capacity
값을 80%로 한다면, 클러스터는 20%의 여유분을 항상 가지고 있는다. 결과적으로 20% 여유분에 task가 바로 실행될 수 있기 때문에 scaling중에 throttled을 어느정도 예방 가능하다. 하지만 비용이 좀 더 부과된다.. 핳- 다른 방법으로는 service에 여유분을 두는건데,
the target tracking scaling metric
또는the step scaling thresholds of the service auto scaling
를 이용하여 복제본을 만들어둘 수 있다. 이 접근 방식은 갑자기 workloads가 튈때만 도움이 된다. 하지만 이 방법은 새로운 서비스를 배포하거나, task를 0에서 N개의 task로 올리는 처음 딱 한번만 도움이 되지 않는다. --> 이건 안해봐서 사실 잘 모르겠다
결과
세가지 방법을 모두 적용하였고, Spare capacity 경우 Target Capacity 방법을 활용했다. 결과적으로 속도 개선에는 성공했지만, 아직 지속적으로 개선중이라 정확한 수치는 아직 확인하지 못했다.
반응형
'Cloud' 카테고리의 다른 글
Amazon ECS managed instance draining (0) | 2024.01.31 |
---|---|
Efficient Multi-Architecture and Multi-Region Container Deployment with Amazon ECS and EC2 Spot Instances (2) | 2024.01.22 |
EC2 Auto Scaling Multiple Launch Templates (0) | 2023.12.29 |
S3 Cache-Control (0) | 2023.10.13 |
ECS Speeding up deployments (0) | 2023.08.17 |
Comments