Amazon ECS 태스크 시작 시간 최적화 - Amazon Elastic Container Service

Amazon ECS 태스크 시작 시간 최적화

작업 시작 속도를 높이려면 다음 권장 사항을 고려합니다.

  • 컨테이너 이미지 및 binpack 인스턴스 캐싱

    EC2 시작 유형을 사용하는 경우 Amazon ECS 컨테이너 에이전트 가져오기 동작을 ECS_IMAGE_PULL_BEHAVIOR: prefer-cached로 구성할 수 있습니다. 캐시된 이미지가 없으면 이미지를 원격에서 가져옵니다. 그렇지 않으면 인스턴스에 캐시된 이미지가 사용됩니다. 캐시된 이미지가 제거되지 않도록 컨테이너에서 자동 이미지 정리는 꺼져 있습니다. 그러면 후속 시작 시 이미지 가져오기 시간이 줄어듭니다. binpack 배치 전략을 사용하여 구성할 수 있는 컨테이너 인스턴스의 작업 밀도가 높으면 캐싱의 효과가 더욱 커집니다. 컨테이너 이미지 캐싱은 일반적으로 컨테이너 이미지 크기가 큰 Windows 기반 워크로드(수십 단위의 GB)에 특히 유용합니다. binpack 배치 전략을 사용할 때는 각 컨테이너 인스턴스에 awsvpc 네트워크 모드로 더 많은 작업을 배치하기 위해 탄력적 네트워크 인터페이스(ENI) 트렁킹을 사용하는 방법도 고려할 수 있습니다. ENI 트렁킹은 awsvpc 모드에서 실행할 수 있는 작업 수를 늘립니다. 예를 들어 2개의 작업 실행만 지원하는 c5.large 인스턴스는 ENI 트렁킹으로 최대 10개의 작업을 실행할 수 있습니다.

  • 최적의 네트워크 모드 선택

    많은 인스턴스에서 awsvpc 네트워크 모드가 이상적이지만 이 네트워크 모드는 작업 시작 지연 시간을 본질적으로 증가시킬 수 있습니다. awsvpc 모드에서 각 작업에 대해 Amazon ECS 워크플로는 Amazon EC2 API를 간접 호출하여 ENI를 프로비저닝하고 연결해야 하기 때문에 작업 시작 시 몇 초의 오버헤드가 추가되기 때문입니다. 반면 awsvpc 네트워크 모드를 사용할 때 주요 이점은 각 작업에 트래픽을 허용하거나 거부하는 보안 그룹이 있다는 점입니다. 즉, 작업과 서비스 간 통신을 보다 세분화된 수준에서 제어할 수 있는 유연성이 향상됩니다. 배포 속도가 우선이라면 작업 시작 속도를 높이기 위해 bridge 모드를 사용하는 방법을 고려할 수 있습니다. 자세한 내용은 Amazon ECS 작업에 대한 네트워크 인터페이스 할당 단원을 참조하십시오.

  • 작업 시작 수명 주기를 추적하여 최적화 기회를 모색합니다.

    애플리케이션을 시작하는 데 걸리는 시간을 파악하기란 쉽지 않습니다. 애플리케이션 시작 중에 컨테이너 이미지를 시작하고, 시작 스크립트를 실행하며, 기타 구성을 실행하는 데 매우 많은 시간이 걸릴 수 있습니다. 작업 메타데이터 엔드포인트를 통해 지표를 게시하여 ContainerStartTime부터 애플리케이션이 트래픽을 처리할 준비가 된 시점까지 애플리케이션 시작 시간을 추적할 수 있습니다. 이 데이터를 통해 애플리케이션이 총 시작 시간에 미치는 영향을 파악하고, 불필요한 애플리케이션별 오버헤드를 줄이며 컨테이너 이미지를 최적화할 수 있는 영역을 찾을 수 있습니다. 자세한 내용은 Amazon ECS 용량 및 가용성 최적화 단원을 참조하십시오.

  • 최적의 인스턴스 유형 선택(EC2 시작 유형의 경우)

    올바른 인스턴스 유형 선택은 작업에서 구성한 리소스 예약(예: CPU, 메모리)을 기반으로 합니다. 따라서 인스턴스 규모를 조정할 때 단일 인스턴스에 배치할 수 있는 작업 수를 계산할 수 있습니다. 잘 배치된 작업의 간단한 예제로, m5.large 인스턴스(2 vCPU 및 8GB 메모리 지원)에서 0.5 vCPU와 2GB의 메모리 예약이 필요한 4개의 작업을 호스팅할 수 있습니다. 이 작업 정의를 예약하면 인스턴스의 리소스를 최대한 활용할 수 있습니다.