모범 사례 - 작업 시작 가속화

Amazon ECS에서 작업을 시작하는 데 걸리는 시간을 단축하기 위해 몇 가지 개선 사항을 적용할 수 있습니다.

Amazon ECS 태스크 시작 워크플로

Amazon ECS가 작업을 프로비저닝하는 방법을 이해하면 작업 시작 속도를 높이기 위한 최적화를 추론하는 데 도움이 됩니다. Amazon ECS 작업 (독립형 작업 또는 Amazon ECS 서비스에 의해) 을 시작하면 작업이 생성되고 해당 PROVISIONING 상태로 성공적으로 시작되기 전의 상태가 됩니다 RUNNING (자세한 내용은 Amazon ECS 개발자 안내서의 작업 수명 주기 참조). PROVISIONING상태에서는 Amazon ECS가 작업을 배치하기 위한 컴퓨팅 파워를 찾아야 하기 때문에 작업도 컨테이너도 존재하지 않습니다.

Amazon ECS는 시작 유형 또는 용량 공급자 구성을 기반으로 작업에 적합한 컴퓨팅 용량을 선택합니다. 시작 유형은 Amazon EC2가 켜져 AWS Fargate (Fargate) 있고 Amazon ECS AWSEXTERNAL Anywhere와 함께 사용되는 유형입니다. 용량 공급자와 용량 공급자 전략은 Fargate 및 Amazon EC2 시작 유형 모두에서 사용할 수 있습니다. Fargate를 사용하면 클러스터 용량의 프로비저닝, 구성 및 규모 조정에 대해 걱정할 필요가 없습니다. Fargate에서 작업에 필요한 모든 인프라 관리를 처리합니다. Amazon EC2를 사용하는 Amazon ECS의 경우 Amazon EC2 인스턴스를 클러스터에 등록하여 클러스터 용량을 관리하거나 Amazon ECS Cluster Auto Scaling (CAS) 을 사용하여 컴퓨팅 파워 관리를 단순화할 수 있습니다. CAS는 클러스터 용량을 동적으로 확장하므로 사용자는 작업 실행에만 집중할 수 있습니다. Amazon ECS는 CPU와 메모리, 배치 제약 조건 및 전략과 같이 작업 정의에서 지정한 요구 사항에 따라 작업 배치 위치를 결정합니다. 작업 배치에 대한 자세한 내용은 Amazon ECS 작업 배치를 참조하십시오.

작업을 배치할 용량을 찾은 후 Amazon ECS는 필요한 첨부 파일 (예: awsvpc 모드 작업에 필요한 ENI)) 을 프로비저닝하고 Amazon ECS 컨테이너 에이전트를 사용하여 컨테이너 이미지를 가져오고 컨테이너를 시작합니다. 이 모든 작업이 완료되고 관련 컨테이너가 시작되면 Amazon ECS는 작업을 상태로 RUNNING 이동합니다.

Amazon ECS 서비스 스케줄러 워크플로

Amazon ECS는 서비스 상태를 관리하기 위한 서비스 스케줄러를 제공합니다. 서비스 스케줄러는 사용자가 지정한 일정 전략을 준수하도록 하고 실패한 작업을 다시 예약합니다. 예를 들어 기본 인프라가 실패하면 서비스 스케줄러가 작업 일정을 조정합니다. 서비스 스케줄러의 주요 책임은 애플리케이션이 항상 원하는 수의 작업을 실행하도록 하는 것입니다. 즉, 서비스 구성에서 지정한 원하는 개수 또는 서비스 자동 확장을 사용하는 경우 애플리케이션 로드에 따라 자동 조정된 작업 수를 기준으로 합니다. 서비스 스케줄러는 비동기 워크플로를 사용하여 작업을 일괄적으로 시작합니다. 서비스 스케줄러가 어떻게 작동하는지 이해하기 위해 트래픽이 많은 대규모 웹 API용 Amazon ECS 서비스를 생성한다고 가정해 보겠습니다. 이 서비스가 많은 웹 트래픽을 처리할 것으로 예상하는데, 서비스에 필요한 적절한 작업 수가 1,000개라고 판단할 수 있습니다. 이 서비스를 배포할 때 Amazon ECS 서비스 스케줄러는 1,000개의 작업을 모두 한 번에 시작하지 않습니다. 대신 현재 상태 (작업 0개) 를 원하는 상태 (1,000개 작업) 로 만들기 위해 워크플로 주기를 실행하기 시작하며, 각 워크플로 주기마다 새로운 작업이 일괄적으로 시작됩니다. 서비스 스케줄러는 Fargate, Amazon EC2 및 외부 시작 유형에 대해 서비스당 분당 최대 500개의 작업을 프로비저닝할 수 있습니다. Amazon ECS에서 허용되는 요금 및 할당량에 대한 자세한 내용은 Amazon ECS 서비스 할당량을 참조하십시오.

이제 Amazon ECS 작업 시작 워크플로를 이해했으므로 이러한 지식을 사용하여 작업 시작 속도를 높이는 방법을 설명해 보겠습니다.

작업 시작 속도를 높이기 위한 권장 사항

이전 섹션에서 설명한 바와 같이, Amazon ECS API 또는 서비스 스케줄러를 통한 작업 시작 트리거와 컨테이너의 성공적인 시작까지 걸리는 시간은 Amazon ECS, 구성 및 컨테이너 자체의 다양한 요인에 의해 영향을 받습니다. 작업 시작 속도를 높이려면 다음 권장 사항을 고려합니다.

• 컨테이너 이미지와 binpack 인스턴스를 캐시합니다.

  Amazon EC2에서 Amazon ECS를 실행하는 경우, Amazon ECS 컨테이너 에이전트가 이전에 사용한 컨테이너 이미지를 캐싱하도록 구성하여 후속 시작 시 이미지 풀 타임을 줄일 수 있습니다. 배치 전략을 사용하여 구성할 수 있는 컨테이너 인스턴스의 작업 밀도가 높으면 캐싱의 효과가 더욱 커집니다. binpack 컨테이너 이미지 캐싱은 일반적으로 컨테이너 이미지 크기가 큰 Windows 기반 워크로드(수십 단위의 GB)에 특히 유용합니다. binpack배치 전략을 사용할 때는 각 컨테이너 인스턴스에 네트워크 모드로 더 많은 작업을 배치하기 위해 ENI (Elastic Network Interface) 트렁킹을 사용하는 것도 고려해 볼 awsvpc 수 있습니다. ENI 트렁킹은 awsvpc 모드에서 실행할 수 있는 작업 수를 늘립니다. 예를 들어 2개의 작업 실행만 지원하는 c5.large 인스턴스는 ENI 트렁킹으로 최대 10개의 작업을 실행할 수 있습니다.

• 최적의 네트워크 모드를 선택하세요.

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

• 작업 시작 라이프사이클을 추적하여 최적화 기회를 찾아보세요.

  애플리케이션을 시작하는 데 걸리는 시간을 파악하기 어려운 경우가 많습니다. 애플리케이션 시작 중에 컨테이너 이미지를 시작하고, 시작 스크립트를 실행하며, 기타 구성을 실행하는 데 매우 많은 시간이 걸릴 수 있습니다. ECS 에이전트 메타데이터 엔드포인트를 사용하여 메트릭을 게시하여 애플리케이션이 트래픽을 처리할 준비가 된 ContainerStartTime 시점까지의 애플리케이션 시작 시간을 추적할 수 있습니다. 이 데이터를 통해 애플리케이션이 총 시작 시간에 미치는 영향을 파악하고, 불필요한 애플리케이션별 오버헤드를 줄이며 컨테이너 이미지를 최적화할 수 있는 영역을 찾을 수 있습니다.

• 최적의 인스턴스 유형을 선택합니다 (Amazon EC2에서 Amazon ECS를 사용하는 경우).

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

• Amazon ECS 서비스 스케줄러를 사용하여 서비스를 동시에 시작할 수 있습니다.

  이전 섹션에서 설명한 것처럼 서비스 스케줄러는 비동기 워크플로를 사용하여 여러 서비스의 작업을 동시에 시작할 수 있습니다. 따라서 응용 프로그램을 작업 수가 많은 대규모 서비스가 아닌 작업 수가 적은 소규모 서비스로 설계하여 배포 속도를 높일 수 있습니다. 예를 들어, 서비스 스케줄러가 모든 서비스에 대한 작업 프로비저닝을 병렬로 시작하므로 서비스 스케줄러가 1,000개의 태스크로 구성된 단일 서비스를 사용하는 대신 10개의 서비스에 대해 각각 100개의 태스크를 포함하도록 하면 배포 속도가 훨씬 빨라집니다.