Amazon ECS 태스크 실행 시간 최적화

태스크 실행 속도를 높이기 위해 다음 권장 사항을 고려해 보세요.

출처: 문서

본문

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

EC2를 사용한다면 Amazon ECS 컨테이너 에이전트의 pull 동작을 ECS_IMAGE_PULL_BEHAVIOR: prefer-cached로 구성할 수 있어요. 캐시된 이미지가 없으면 이미지를 원격으로 pull 하고, 있으면 인스턴스의 캐시된 이미지를 사용해요. 캐시된 이미지가 제거되지 않도록 컨테이너의 자동 이미지 정리는 꺼져 있어요. 이렇게 하면 이후 실행에서 이미지 pull 시간이 줄어들어요. 컨테이너 인스턴스에 태스크 밀도가 높을 때 캐싱 효과는 더 커지는데, 이는 binpack 배치 전략을 사용해 구성할 수 있어요. 컨테이너 이미지 캐싱은 특히 대개 수십 GB 크기의 큰 컨테이너 이미지를 갖는 Windows 기반 워크로드에 유용해요. binpack 배치 전략을 사용할 때는 Elastic Network Interface(ENI) 트렁킹을 사용해 각 컨테이너 인스턴스에 awsvpc 네트워크 모드로 더 많은 태스크를 배치하는 것도 고려해 보세요. ENI 트렁킹은 awsvpc 모드에서 실행할 수 있는 태스크 수를 늘려 줘요. 예를 들어 c5.large 인스턴스는 동시에 2개 태스크만 실행할 수 있지만, ENI 트렁킹을 사용하면 최대 10개 태스크를 실행할 수 있어요.

최적의 네트워크 모드 선택

awsvpc 네트워크 모드가 이상적인 경우가 많지만, 이 네트워크 모드는 태스크 실행 지연 시간을 본질적으로 늘릴 수 있어요. awsvpc 모드의 각 태스크마다 Amazon ECS 워크플로가 Amazon EC2 API를 호출해 ENI를 프로비저닝하고 연결해야 하므로 태스크 실행에 몇 초의 오버헤드가 추가되기 때문이에요. 반면 awsvpc 네트워크 모드의 핵심 장점은 각 태스크에 트래픽을 허용하거나 거부하는 보안 그룹이 있다는 점이에요. 즉 태스크와 서비스 간 통신을 더 세밀하게 제어할 수 있는 유연성이 생겨요. 배포 속도가 최우선이라면 bridge 모드를 사용해 태스크 실행을 빠르게 하는 것을 고려해 보세요. 자세한 내용은 Allocate a network interface for an Amazon ECS task를 참고하세요.

태스크 실행 수명 주기 추적해 최적화 기회 찾기

애플리케이션 시작에 걸리는 시간을 아는 것은 어려운 경우가 많아요. 컨테이너 이미지 실행, 시작 스크립트 실행, 애플리케이션 시작 중의 다른 구성들은 놀라울 정도로 많은 시간이 걸릴 수 있어요. Task metadata endpoint를 사용해 지표를 게시하면, 컨테이너 메타데이터 응답의 StartedAt부터 태스크 또는 서비스의 StartedAt 시간까지 애플리케이션 시작 시간을 추적할 수 있어요. 이 데이터를 통해 애플리케이션이 전체 실행 시간에 얼마나 기여하는지 이해하고, 불필요한 애플리케이션별 오버헤드를 줄이고 컨테이너 이미지를 최적화할 수 있는 영역을 찾을 수 있어요. 자세한 내용은 Amazon ECS Auto scaling and capacity management best practices를 참고하세요.

최적의 인스턴스 유형 선택 (EC2)

올바른 인스턴스 유형을 선택하는 것은 태스크에 구성한 리소스 예약(예: CPU, 메모리)에 기반해요. 따라서 인스턴스 크기를 정할 때 단일 인스턴스에 몇 개의 태스크를 배치할 수 있는지 계산할 수 있어요. 잘 배치된 태스크의 간단한 예로, 0.5 vCPU와 2GB 메모리를 예약하는 4개 태스크를 m5.large 인스턴스(2 vCPU, 8GB 메모리 지원)에 호스팅하는 경우가 있어요. 이 태스크 정의의 예약은 인스턴스의 리소스를 완전히 활용해요.