AWS Auto Scaling Group Warmpool

AWS Auto Scaling Group의 Warm Pool: 요약 및 장단점

Warm Pool이란?

AWS Auto Scaling Group (ASG)의 Warm Pool은 ASG가 필요로 하는 인스턴스를 미리 프로비저닝하고 준비 상태(A Warm Pool is a pool of pre-initialized EC2 instances)로 유지하여, 새로운 인스턴스가 필요한 경우 더 빠르게 스케일링할 수 있도록 돕는 기능입니다. Warm Pool에 있는 인스턴스는 사용자가 설정한 상태 (Stopped, Running, 또는 Hibernated)로 유지됩니다. 이를 통해 ASG는 일반적으로 새 인스턴스를 시작하는 데 걸리는 시간을 줄이고 애플리케이션의 응답성을 높일 수 있습니다.

Warm Pool 설정 옵션

• Instance State (인스턴스 상태):
  • Running: 인스턴스가 실행 중인 상태로 유지되어 즉시 사용 가능.
  • Stopped: 인스턴스가 중지된 상태로 유지되어 필요 시 재부팅이 필요함.
  • Hibernated: 인스턴스가 최대 절전 모드 상태로 유지되어 메모리 상태를 보존하고 빠르게 재개 가능.

from aws

 

Hibernate를 사용하는 Warm Pool의 경우:

Hibernate(최대 절전 모드)는 인스턴스를 종료하지 않고 메모리와 프로세스 상태를 디스크에 저장한 후 중지하여, 다시 시작할 때 이전 상태를 복원할 수 있도록 하는 기능입니다. Hibernate 상태의 인스턴스는 시작 시점에 애플리케이션과 데이터를 메모리에 유지하고 있기 때문에, 응답 속도가 매우 빠릅니다.

장점:

1. 빠른 스케일링 응답 시간: Warm Pool에 인스턴스를 준비해 두면 스케일 아웃 시 새로운 인스턴스를 생성하고 부팅하는 시간을 줄일 수 있어, 더 빠르게 트래픽 증가에 대응할 수 있습니다.
2. 비용 절감: Warm Pool에서 인스턴스를 Hibernated 상태로 유지하면, 실행 중인 인스턴스에 비해 비용을 절감하면서도 빠른 복구 속도를 유지할 수 있습니다.
3. 애플리케이션 상태 유지: Hibernate를 사용하면 애플리케이션의 상태를 메모리에 저장한 채로 유지할 수 있어, 재부팅 시에도 이전 세션을 빠르게 복구할 수 있습니다. 이는 데이터 손실 위험을 줄이고, 사용자 경험을 향상시킵니다.
4. 유연한 설정: Warm Pool 크기와 인스턴스 상태를 사용자 요구에 맞게 조정할 수 있어, 다양한 시나리오에 맞는 유연한 스케일링 전략을 설정할 수 있습니다.

단점:

1. 비용 부담: Hibernated 상태의 인스턴스는 완전히 중지된 인스턴스보다 비용이 높을 수 있으며, Warm Pool에 인스턴스를 유지하는 데에도 추가 비용이 발생할 수 있습니다.
   1. 하지만 Hibernated 상태일 때는 instance는 stop으로 consider되어 비용이 부과되지 않고 EBS 볼륨에 대한 비용만 부과됩니다.
2. 복잡한 설정: Warm Pool을 효과적으로 관리하려면 설정과 모니터링이 필요하며, Hibernate 기능을 사용하려면 EC2 인스턴스 유형이 지원하는지 확인해야 합니다.
   1. 2024년 7월부터 ARM 기반 instance도 지원하기 때문에 사용이 가능합니다.
   2. Hybrid Platform은 지원하지 않습니다. (예: arm + amd )
3. 인스턴스 재사용 제한: Hibernate 상태에서 인스턴스를 재사용하려면, 사용 중이던 인스턴스의 애플리케이션 및 운영 체제가 지원해야 하며, 이로 인해 특정 유형의 인스턴스나 애플리케이션에는 적용이 어려울 수 있습니다.
4. 서비스 통합 문제: Amazon EKS 또는 ECS와 Warm Pool을 함께 사용할 때, 초기화 중인 인스턴스가 클러스터에 너무 일찍 등록될 수 있습니다. 이를 방지하려면 런치 템플릿 또는 구성에서 특정 설정이 필요합니다.
   1. Lifecycle Hooks(라이프사이클 훅):
      • 라이프사이클 훅을 사용하여 인스턴스가 초기화 과정 중에 특정 작업을 완료할 때까지 '대기(wait)' 상태에 있도록 설정할 수 있습니다. 이를 통해, 인스턴스가 준비되기 전에 Amazon EKS 또는 ECS 클러스터에 등록되지 않도록 할 수 있습니다.
      • AWS Management Console, AWS CLI, 또는 SDK를 통해 Auto Scaling 그룹에 라이프사이클 훅을 추가할 수 있습니다. 예를 들어, autoscaling:EC2_INSTANCE_LAUNCHING 훅을 사용하여 인스턴스가 서비스에 투입되기 전에 필요한 초기화 작업(데이터 로드, 애플리케이션 설치 등)을 수행할 수 있습니다.
   2. User Data Scripts(사용자 데이터 스크립트):
      • 런치 템플릿 또는 런치 구성에서 사용자 데이터 스크립트를 설정하여 인스턴스가 시작될 때 초기화 작업을 수행할 수 있습니다. 이 스크립트는 인스턴스가 완전히 준비되기 전에 Amazon EKS 또는 ECS 클러스터에 등록되지 않도록 보장하는 작업을 포함해야 합니다.
      • 예를 들어, 초기화가 완료되기 전에 클러스터에 등록되지 않도록 Kubernetes kubelet 프로세스의 시작을 지연시키거나, ECS 에이전트 설정 파일을 수정하여 클러스터 등록을 지연시킬 수 있습니다.
   3. Instance Metadata 활용:
      • 인스턴스 메타데이터를 사용하여 초기화가 완료된 상태를 확인하고, 클러스터에 등록할 수 있도록 설정할 수 있습니다. 사용자 데이터 스크립트에서 인스턴스 메타데이터를 조회하여 초기화가 완료된 경우에만 클러스터에 등록되도록 제어할 수 있습니다.

설정 예시

AWS CLI를 이용한 Lifecycle Hook 설정 예시:

aws autoscaling put-lifecycle-hook --lifecycle-hook-name "MyHook" \
 --auto-scaling-group-name "my-asg" \
 --lifecycle-transition "autoscaling:EC2_INSTANCE_LAUNCHING" \
 --heartbeat-timeout 300 --default-result "ABANDON"

이 설정은 인스턴스가 준비될 때까지 Auto Scaling 그룹이 해당 인스턴스의 상태를 '대기(wait)'로 유지하도록 합니다.

사용자 데이터 스크립트 예시 (Amazon EKS를 위한 초기화 지연):

#!/bin/bash
# Kubernetes 노드로 등록하기 전에 필요한 초기화 작업 수행
# 초기화 작업 완료 후에 kubelet을 시작
sleep 60 # 초기화 시간을 지연시킴
/etc/eks/bootstrap.sh my-cluster-name

위와 같은 스크립트를 사용하여 인스턴스가 준비되기 전까지 Kubernetes 클러스터에 등록되지 않도록 설정할 수 있습니다.

추가 참고 자료

• AWS EC2 Auto Scaling Lifecycle Hooks Documentation
• Amazon EKS User Guide
• Amazon ECS User Guide

이러한 설정을 통해 초기화 중인 인스턴스가 너무 일찍 클러스터에 등록되는 문제를 효과적으로 방지할 수 있습니다.