LiJell's 성장기

ECS Speeding up deployments 본문

Cloud

ECS Speeding up deployments

All_is_LiJell 2023. 8. 17. 18:59
반응형

이 글은 AWS Docs에 있는  ECS Deployment 속도 개선을 관련 내용을 정리한 내용입니다. 

배포가 느려 개발에 지연을 주고, Scaling시에도 Traffic이 몰렸을 때 서버가 죽는 경우까지 발생하여 글을 읽고 적어봤습니다. 

아직은 한글 번역 글은 없기 때문에 도움이 되면 좋겠네요! 

 

ECS Deployment 속도 개선을 위해 아래와 같은 방법을 사용할 수 있습니다.

  1. HealthCheckIntervalSeconds , HealthyThresholdCount 값을 적정 수준으로 낮게 잡는다.
  2. deregistration_delay.timeout_seconds 과 ECS_CONTAINER_STOP_TIMEOUT를 적정 수준 낮게잡아 drain 시간을 줄인다.
  3. 가벼운 이미지 타입을 사용한다
  4. vCPU가 더 많은 큰 task를 사용하고, ECR과 ECS를 같은 region에 위치시킨다.
  5. minimumHealthyPercent, maximumPercent 를 조정하여 적은 수의 task를 유지하고 여유 공간을 줘 새로운 task가 빠르게 올라오게 한다.

상세 내용은 아래를 참고해 주세요


1. Load balancer health check

로드 밸런서는 주기적으로 health check를 통해 ECS container의 Health status를 확인합니다.

출처: AWS

 

Health check에 관한 두가지 parameters가 Elastic Load Balancing API에 있습니다.

  • HealthCheckIntervalSeconds
    • Health check를 하는 주기를 조절해 줍니다.
    • Default는 30초 주기를 가지고 있습니다.
  • HealthThresholdCount
    • Unhealthy container를 healthy 하다고 판단하기 위해 health check하는 횟수를 설정합니다.
    • Default는 5번 체크합니다. ( health check 5번 pass 후 healthy하다고 판단 )

즉, Default 기준 한개의 container 가 Healthy 하다고 판단하는데 총 150초가 걸립니다. ( 30초 * 5번 )

서비스가 시작되고 안정되는게 10초 미만일 때 아래와 같이 설정하면 health check 과정이 10초로 줄어듭니다. ( 5초 * 2번)

  • HealthCheckIntervalSeconds (Elastic Load Balancing API name) or Interval (Amazon EC2 console name): 5
  • HealthyThresholdCount (Elastic Load Balancing API name) or Healthy threshold (Amazon EC2 console name): 2

결과적으로 두 설정값을 적절하게 조절하면 Health check 속도가 빨라집니다.

위 설정은 Target groups 페이지의 Health checks tab에서 수정 가능합니다.


2. Load balancer connection draining

클라이언트는 최적화를 위해 Container 서비스와의 연결을 유지하고 있습니다. 따라서 Container를 drain하기 전에 트래픽 중단이 필요합니다. 방식은 아래 그림과 같습니다.

출처: AWS

 

로드밸런서가 기다려주는 시간을 설정해주는 parameter이 있습니다. 이 시간을 줄이면 배포 속도를 빠르게 할 수 있습니다.

  • deregistration_delay.timeout_seconds
    • Default값은 300초 입니다.

서비스와 응답속도가 1초 미만일 이라면, client와 backend의 connection을 끊는데 5초만 기다리게 할 수 있습니다. 즉 container drain 속도가 빨라집니다.

• deregistration_delay.timeout_seconds: 5

SIGTERM responsiveness

아래 그림은 Amazon ECS가 task을 종료하는 방법을 보여줍니다. Amazon ECS는 먼저 task에 SIGTERM 신호를 보내어 애플리케이션이 종료되어야 하며 종료되어야 한다는 것을 알립니다. 그런 다음 Amazon ECS는 SIGKILL 메시지를 보냅니다. 애플리케이션이 SIGTERM을 무시하는 경우 Amazon ECS 서비스는 SIGKILL 신호를 보내서 프로세스를 종료하기 위해 기다려야 합니다.

출처: AWS

ECS가 기다려 주는 시간을 조절하는 Parameter은 아래와 같습니다.

  • ECS_CONTAINER_STOP_TIMEOUT
    • Default 값은 30초 입니다.

ECS_CONTAINER_STOP_TIMEOUT 를 2로 설정하면 Container이 shut down되는것을 2초 기다립니다. 그리고 application이 멈추지 않으면 SIGKILL을 보냅니다.

또한, 애플리케이션의 동작을 조정하기 위해 코드를 수정하여 SIGTERM 신호를 처리하고 적절하게 대응하도록 할 수 있습니다. application JS기준으로 아래와 같습니다.

process.on('SIGTERM', function() { 
  server.close(); 
})
  • 위 코드에서 SIGTERM 신호를 받으면 HTTP 서버에게 새로운 요청 수신을 중단하라는 지시를 전달합니다.
  • 서버는 현재 처리 중인 요청에 응답한 다음 Node.js 프로세스가 종료될 수 있도록 합니다. 이는 Node.js 프로세스의 이벤트 루프가 더 이상 수행할 작업이 없기 때문에 발생합니다.
  • 만약 처리 중인 요청이 짧은 시간(예: 500ms) 내에 완료된다면, 프로세스는 stop timeout 경과하기 전에 종료되어 SIGKILL 신호를 대기하지 않아도 됩니다.

3. Container image type

Container를 가벼운 image type을 사용하면 Container 시작 시간을 줄일 수 있습니다.

  • slim versions (Debian-slim, Ubuntu-slim, and Amazon-slim)
  • smaller base images (Alpine) >> 툰스퀘어는 Alpine 이미지를 사용하려 합니다.

4. Container image pull behavior

Fargate tasks를 위한 이미지는 아래의 내용을 따르면 좋습니다.

  • 추가 vCPU가 있는 더 큰 task를 사용
  • 더 작은 기본 이미지를 사용
  • 이미지를 저장하는 저장소를 task와 동일한 리전에 위치

5. Task deployment

두 개의 ECS 서비스 구성 옵션을 사용하여 다음과 같이 task 수를 수정할 수 있습니다:

  • minimumHealthyPercent: 100% (기본값)

배포 중에 서비스의 상태가 RUNNING인 task 수의 하한선을 나타냅니다. 이는 desiredCount의 백분율로 표시되며, 가장 가까운 정수로 반올림됩니다. 이 param은 추가 클러스터 용량을 사용하지 않고 배포할 수 있도록 합니다.

  • maximumPercent: 200% (기본값)

배포 중에 서비스의 상태가 RUNNING 또는 PENDING인 task 수의 상한선을 나타냅니다. 이는 desiredCount의 백분율로 표시되며, 가장 가까운 정수로 내림됩니다.

기본적으로 ECS는 minimumHealthyPercent 값을 유지하면서 task를 교체하는 방식을 취합니다. 이 때, task 시작에 따른 대기 시간과 이전 task 중지에 따른 대기 시간이 발생할 수 있습니다.

  1. minimumHealthyPercent 값을 50%로 설정하여 서비스가 상대적으로 적은 수의 task를 유지하도록 할 수 있습니다. 이렇게 하면 새로운 task가 빠르게 시작될 가능성이 높아지며, 배포 속도가 향상될 수 있습니다.
  2. maximumPercent로 더 많은 여유 공간을 추가하여 추가 task를 실행할 수 있는 상태를 유지할 수 있도록 할 수도 있습니다. 이를 통해 더 많은 task들이 동시에 실행될 수 있어 배포가 더 빠르게 완료될 수 있습니다.
반응형

'Cloud' 카테고리의 다른 글

EC2 Auto Scaling Multiple Launch Templates  (0) 2023.12.29
S3 Cache-Control  (0) 2023.10.13
AWS Lambda@Edge  (0) 2023.08.06
웹 애플리케이션 서비스 개요  (0) 2023.08.06
NAT GateWay와 이중화의 중요성  (0) 2023.08.06
Comments