AWS Fargate - how to shorten Fargate startup time

---

AWS Fargate - how to shorten Fargate startup time

 

 

 

AWS Fargate를 사용하면서 좀 더 빠르게 사용하기 위한 여러 포인트를 고민하실텐데요, 해당 내용에 대하여 case open 했던 내용입니다. 단순한 이렇게 해봐라라는 정도의 가이드라는 점 참고하시면 좋을 것 같습니다.

 

질문

I am using eks fargate as a Gitlab-runner excuter.
The startup time of the pod takes about 1 minute 30 seconds to 2 minutes. Is there any way to shorten this startup time?

-----

Gitlab-runner excuter로 eks fargate를 사용하고 있습니다.
포드의 시작 시간은 약 1분 30초에서 2분 정도 걸립니다. 이 시작 시간을 단축할 수 있는 방법이 있습니까?

 

답변

I understand that you are seeking information regarding Pod launch times when using EKS Fargate and you would like to reduce these delays if possible. Please correct me if I have misunderstood anything.

The expected startup time for Fargate Pods will typically be longer than scheduling directly to your Worker Nodes.

This is because deploying a Fargate Pod needs the EKS Service to deploy a dedicated Fargate Node. Before launching a Pod, the underlying infrastructure must be provisioned and completely bootstrapped. This causes a delay in the scheduling of Pods. The Image extract time, Load balancer, and Container size are additional elements that contribute to this time delay. Additionally, the size of the Docker image impacts the starting time. This is because the host must download the image before the process can begin and the larger the size of the Docker image, the longer the startup time.

I have conducted comparable testing on my own Cluster to confirm this. I have found that the typical launch time for Pods on Fargate is between 1 and 2 minutes.

I am aware that this is not ideal, however it is currently a constraint of the underlying architecture.

Other customers have already opened a feature request to ask for faster Fargate startup times; you may be interested in adding a +1 with your use case here to raise the ticket's visibility amongst the EKS Service Team [1].

If you have specific Pods whose starting time is critical, I would suggest scheduling them on standard EC2 Worker Nodes. This will result in quicker startup times, particularly if you maintain a few warm instances available for scheduling.

I trust the above information provides additional clarity and would be of some assistance. Should you have any further queries or concerns please feel free to reach out again. I would be happy to assist in any way that I can.

[1] https://github.com/aws/containers-roadmap/issues/649  

-----

EKS Fargate를 사용할 때 포드 시작 시간에 대한 정보를 찾고 있으며 가능한 경우 이러한 지연을 줄이고 싶다는 점을 이해합니다. 내가 잘못 이해한 것이 있으면 정정해 주십시오.

Fargate 포드의 예상 시작 시간은 일반적으로 작업자 노드에 직접 예약하는 것보다 깁니다.

Fargate 포드를 배포하려면 전용 Fargate 노드를 배포하기 위해 EKS 서비스가 필요하기 때문입니다. Pod를 시작하기 전에 기본 인프라를 프로비저닝하고 완전히 부트스트랩해야 합니다. 이로 인해 Pod 예약이 지연됩니다. 이미지 추출 시간, 로드 밸런서 및 컨테이너 크기는 이 시간 지연에 기여하는 추가 요소입니다. 또한 Docker 이미지의 크기는 시작 시간에 영향을 미칩니다. 프로세스가 시작되기 전에 호스트가 이미지를 다운로드해야 하고 Docker 이미지의 크기가 클수록 시작 시간이 길어지기 때문입니다.

이를 확인하기 위해 자체 클러스터에서 유사한 테스트를 수행했습니다. Fargate에서 포드의 일반적인 시작 시간이 1분에서 2분 사이인 것으로 나타났습니다.

이것이 이상적이지 않다는 것을 알고 있지만 현재 기본 아키텍처의 제약 조건입니다.

다른 고객은 이미 더 빠른 Fargate 시작 시간을 요청하는 기능 요청을 열었습니다. 여기에서 사용 사례에 +1을 추가하여 EKS 서비스 팀[1]에서 티켓의 가시성을 높이는 데 관심이 있을 수 있습니다.

시작 시간이 중요한 특정 포드가 있는 경우 표준 EC2 작업자 노드에서 예약하는 것이 좋습니다. 이렇게 하면 특히 예약에 사용할 수 있는 몇 개의 웜 인스턴스를 유지 관리하는 경우 시작 시간이 빨라집니다.

본인은 위의 정보가 추가적인 명확성을 제공하고 어느 정도 도움이 될 것이라고 믿습니다. 추가 질문이나 우려 사항이 있으면 언제든지 다시 문의해 주세요. 최선을 다해 도와드리겠습니다.

[1] https://github.com/aws/containers-roadmap/issues/649

 

 

 

---

by mkdir-chandler

---