Question?


ECS Fargate 로 배포까지 성공적으로 테스트했습니다.

하지만 ECS Fargate에 배포가 완료 될때 까지 시간이 너무 오래 걸려 문의 드립니다.


해당 시간을 줄일 수 있는 방법이 있을까요?



원인


ECS 의 배포에 시간이 걸리는 일반적인 이유는 아래와 같습니다.

  1. 이미지 자체의 크기가 커서 컨테이너 레지스트리에서 컨테이너 이미지를 다운로드하거나 AWS 외부에 저장되는 시간이 길어질 수 있습니다.
  2. 작업 정의에는 다운로드 및 실행에 시간이 필요한 종속성이있을 수 있으며 이로 인해 시간이 오래 걸릴 수 있습니다.
  3. 정의 된 Fargate의 CPU / MEMORY가 이미지 컨테이너에 필요한 것보다 작은 경우.
  4. Fargate process


이번 시간에는 Fargate 로 ECS를 구성한 경우, ECS 컨테이너 배포 속도를 향상시키는 방법에 대해 안내드리겠습니다.




해결 방법

  1. 크기가 큰 이미지를 가져오는 동작 설정 (이미지 다운로드)

    이미지를 레지스트리에서 다운로드하는 대신 ECS 호스트에 캐시 된 이미지를 사용하여 컨테이너를 시작하도록 Amazon ECS를 구성 할 수 있습니다.

    이렇게하면 큰 이미지가 포함 된 컨테이너를 시작하거나 이미지가 AWS에 저장되지 않은 경우 더 빨리 시작할 수 있습니다.
    * ECS Fargate는 기본적으로 이미지 캐싱을 지원 하지 않습니다. 하지만 ECS Fargate는 이미지 캐시를 지원하지 않는다고 해서 이미지를 전혀 캐싱할 수 없는 것은 아닙니다. 다음과 같은 방법을 통해 이미지 캐싱을 활용할 수 있습니다.

    아래와 같이 ECS_IMAGE_PULL_BEHAVIOR: default 로 설정된 값을 once 혹은 prefer-cached 로 변경해주시길 바랍니다. 

    ECS_IMAGE_PULL_BEHAVIOR 환경 변수를 once 또는 prefer-cached로 설정하면 컨테이너 인스턴스가 동일한 이미지를 여러 번 다운로드하지 않도록 합니다.


    ECS_IMAGE_PULL_BEHAVIOR


    컨테이너 인스턴스에 대한 풀 이미지 프로세스를 사용자 지정하는 데 사용되는 동작입니다.
    • default : 원격으로 pull. 이미지 가져오기가 실패하면 컨테이너는 인스턴스의 캐시된 이미지를 사용합니다.

    • once : 이미지는 동일한 컨테이너 인스턴스의 이전 작업에서 가져오지 않았거나 캐시된 이미지가 자동화된 이미지 정리 프로세스에 의해 제거된 경우에만 원격으로 가져옵니다. 그렇지 않으면 인스턴스의 캐시된 이미지가 사용됩니다. 이렇게 하면 불필요한 이미지 가져오기가 시도되지 않습니다.

    • prefer-cached : 캐시된 이미지가 없는 경우에만 이미지를 원격으로 가져옵니다.

      기본 설정 :

    • ECS_IMAGE_PULL_BEHAVIOR: default 



      권장 설정 :

      ECS_IMAGE_PULL_BEHAVIOR: once or prefer-cached


      이로 인해 ECS는 원격 레지스트리에서 다운로드하는 대신 EC2 호스트의 디스크 캐시에 있는 기존 다운로드 이미지를 사용합니다. 이렇게 하면 작업 시작 시간을 절약할 수 있습니다. 특히 네트워크를 풀링하는 데 10-20초가 걸릴 수 있는 더 큰 Docker 이미지의 경우에는 더욱 그렇습니다.

  2. 로드 밸런서 연결 draining

    컨테이너를 종료하고 싶거나 다른 이유로 로드 밸런서에 컨테이너로의 트래픽 전송을 중지하는 신호를 전송하면 로드 밸런서는 다운스트림 컨테이너에 대한 새 연결 전송을 중지합니다. 하지만 기존 연결은 컨테이너가 close 될 때 까지 기다리며 deregistration delay 라 불리는 기간 이후에 연결 유지를 강제적으로 끊습니다.

    따라서 deregistration_delay.timeout_seconds 의 기본 값 숫자를 줄여줌으로서 해결할 수 있습니다.

    기본 설정 ( 대상 그룹 속성 ):

    deregistration_delay.timeout_seconds: 300


    :—> 300초

    기본적으로 로드 밸런서는 기존 연결 유지 연결을 강제로 끊기 전에 자체적으로 닫힐 때까지 최대 300초(또는 5분) 동안 기다립니다. ECS는 진행 중인 요청이 삭제되지 않도록 SIGTERM 신호를 컨테이너에 보내기 전에 이 등록 취소가 완료될 때까지 기다립니다.

    서비스가 평균 응답 시간이 1초 미만인 빠른 REST API와 같은 경우 이 지연을 줄이거나 완전히 제거하는 데 아무런 해가 없습니다. 느린 파일 업로드, 스트리밍 연결 등과 같이 오래 지속되는 요청이 있는 서비스가 있는 경우에는 이 작업을 수행하지 마십시오.

    권장 설정 ( 대상 그룹 속성 ):

    deregistration_delay.timeout_seconds: 5



    이렇게 하면 로드 밸런서가 클라이언트와 백엔드 서버 간의 연결 유지 연결을 끊기 전에 5초만 기다리게 한 다음 드레이닝이 완료되고 ECS가 작업을 중지할 수 있다고 ECS에 보고합니다.

  3. Fargate에 더 높은 cpu 와 memory 설정

    Fargate는 특정 크기가 설정되어 있으며 전용 Linux 커널에서 실행되기 때문에 다른 작업에 걸쳐 리소스를 오버 커밋할 수 없습니다. 또한 vCPU 1/4 및 512MB 메모리보다 작은 작업은 생성할 수 없으므로 여유있게 CPU 와 Memory를 설정하시는 것을 추천드립니다

  4. Fargate process 확인

    Fargate process 는 기본적으로 아래 순서로 진행 됩니다.

    a. Provision the Fargate worker instance

    b. Provision/attach the ENI

    c. Download the Docker image

    ‼️ 이 과정에서 Docker 이미지의 크기 줄임으로서 시간을 단축시킬 수 있습니다.

    → 네트워킹 처리량은 Fargate 작업에 대한 CPU 할당을 기반으로합니다. 더 많은 CPU를 할당하면 더 많은 네트워킹이 제공되고 이미지가 더 빨리 다운로드됩니다.


    d. Application Startup time

    Application에 상태 확인 유예 기간이 필요한 경우 다시 CPU 할당의 영향을 받으며 시간 지연에 영향을 줄 수 있습니다.

요약하자면, Fargate를 더 빠르게 배포하기 위해 아래와 같은 방법을 사용 해보시길 바랍니다.

  • CPU 및 메모리를 적절하게 할당
  • 등록 취소 지연 시간 감소 설정
  • 이미지 pull 방식 변경
  • Docker 이미지 크기 줄이기
  • 이미지 다운로드 최적화
  • 네트워크 성능 향상
  • ECR 활용