Spot 인스턴스 안정성 확보: ASG + Capacity-Optimized + Capacity Rebalancing 활용하기

인프라 비용 절감 측면에서 Spot 인스턴스는 매력적입니다. 할인폭이 크지만, 중요한 단점은 “언제든 종료(interruption)”될 수 있다는 것.

이 글에서는 Auto Scaling Group(ASG) + Capacity-Optimized 할당 전략 + Capacity Rebalancing 조합을 써서 Spot 인스턴스의 불안정성을 완화하고 높은 가용성을 확보하는 방법을, AWS 문서와 실제 운영 팁 중심으로 설명합니다.

---

주요 컴포넌트 개념 정리

구성 요소	역할 요약
Auto Scaling Group (ASG)	인스턴스 수(desired capacity)를 자동으로 유지하며, Spot/On-Demand 혼합 가능. 실패/종료 시 보충 가능.
Capacity-Optimized Allocation Strategy	Spot 풀(Spot capacity pool) 중 여유(capacity)가 많은 것 위주로 인스턴스 요청. “가장 가격이 싼” 전략보다 중단 리스크가 낮음. AWS Documentation
Capacity Rebalancing	AWS Spot 서비스가 “중단 위험(rebalance recommendation)” 알림을 보내면 미리 새 인스턴스를 띄우고 오래된 인스턴스를 그 뒤에 종료하는 기능. 사전에 준비할 시간을 벌어 줌. AWS Documentation

---

왜 이 조합을 써야 하나?

• Spot 인스턴스는 **불확실한 종료 위험(interruption risk)**이 있음.
• 단순히 “종료 후 대체”만 하면 중단 시점부터 대체 인스턴스 가동까지의 다운타임이 생김.
• Capacity-Optimized + Mixed Instance Policy로 **여러 타입/가용 영역(AZ)**을 열어두면 AWS가 더 안정적인 Spot 풀에서 인스턴스를 확보할 가능성이 커짐.
• Capacity Rebalancing을 켜면 “종료 직전 2분 알림(interruption notice)”이 아니라, 그보다 조기에 보내는 “rebalance recommendation” 기반으로 미리 교체 가능. AWS Documentation+1

---

AWS 공식 가이드에서 제안하는 Best Practice

아래 항목들은 AWS 문서에서 권장하는 Spot 인스턴스 안정성 확보 방법들입니다:

1. 다중 인스턴스 타입 & 다중 AZ 사용
2. 여러 인스턴스 패밀리/세대(instance type)를 ASG에 등록해 두면, 특정 타입이나 AZ에서 Spot 여유 용량이 줄어들어도 다른 풀에서 대체 가능. AWS Documentation
3. Allocation Strategy: price-capacity-optimized (또는 capacity-optimized) 선택
   • capacity-optimized: 여유 용량이 많은 풀 중심으로 선정. 중단 리스크 최소화. AWS Documentation
   • price-capacity-optimized: 조금 더 가격 절약도 고려하면서 여유가 있는 풀을 우선 선택. AWS Documentation
4. Capacity Rebalancing 활성화
   • ASG 설정 시 CapacityRebalance=true 옵션 사용. AWS Documentation
   • 리밸런스 알림 받으면 새 인스턴스를 먼저 시작 → 건강 체크 통과 후 이전 인스턴스 종료. AWS Documentation
   • 필요한 경우 Lifecycle Hook을 등록해 종료 처리(graceful shutdown) 로직 수행 가능. AWS Documentation
5. Health Checks / 상태 관리 강화
   • 인스턴스가 교체될 때 애플리케이션 상태가 새 인스턴스에서 정상인지 체크 (예: ALB/ELB 건강 체크, 커스텀 health endpoint).
   • 종료 직전(또는 종료 알림 시) 애플리케이션 정리(clean-up) 및 로그 업로드, 연결 종료 등 수행 가능하도록 준비. (Lifecycle Hook 활용) AWS Documentation
6. 필요한 시간 확보 & 오버 프로비저닝 고려
   • Capacity Rebalancing 동작 시 기존 인스턴스 종료 전 새 인스턴스가 가동되고 헬스 체크 통과할 때까지 기다림. 이를 위해 약간의 여유 용량(max size) 또는 오버헤드 허용 필요. AWS Documentation
   • 종료 핸들링 간 필요한 시간(드레인, DNS 반영, 데이터 flush 등)을 고려해 Lifecycle Hook timeout 설정. AWS Documentation

---

실전 구성 샘플

아래는 Terraform 또는 CLI 기반으로 이 조합을 적용했을 때의 구조 예시 + 설정 키 포인트입니다:

# CLI 구성 예시 (AWS CLI JSON/YAML)
{
  "AutoScalingGroupName": "kafka-broker-asg-prod",
  "MinSize": 3,
  "MaxSize": 6,
  "DesiredCapacity": 3,
  "CapacityRebalance": true,
  "MixedInstancesPolicy": {
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 0,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "price-capacity-optimized"
    },
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "kafka-broker-template",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5a.large"},
        {"InstanceType": "c5.large"},
        {"InstanceType": "c5a.large"}
      ]
    }
  },
  "VPCZoneIdentifier": "subnet-a,subnet-b,subnet-c",
  "Tags": [...]
}

• OnDemandPercentageAboveBaseCapacity: 필요 시 일부 On Demand 혼합 가능
• Overrides: 여러 인스턴스 타입을 준비해 둠
• CapacityRebalance: true 설정으로 rebalancing 활성화
• Launch Template 내부 설정: Spot 예약, AMI, EBS, 태그, IAM Role etc.

---

한계와 주의사항

• Signal 타이밍 보장 불가
• rebalance recommendation 알림이 Spot 종료 알림과 거의 동시에 오거나 늦게 도착하는 경우 있음. AWS Documentation
• 리스너/로드밸런서 제거 지연
• Lifecycle Hook + ELB/ALB deregistration 이야기 필요. 종료 전에 트래픽 정리 시간이 충분히 확보되어야 함.
• DNS/Advertised Listeners 등 클라이언트 구성 중요
• Kafka처럼 브로커 광고주소가 고정 FQDN이라면, 새 인스턴스로 교체 시 DNS 갱신 & 클라이언트 메타데이터 갱신 주기 단축 필요.
• 오버헤드 비용 가능성 존재
• 대체 인스턴스를 미리 띄우는 것이므로 순간적으로 용량 초과 및 비용 증가 가능.

---

추가 팁 & 트릭

• EventBridge 리밸런스 알림 감지
• 자동화 스크립트나 알림 시스템이 EC2 Instance Rebalance Recommendation 이벤트를 구독하도록 설정 → 로그/Slack/모니터링 통합 가능. AWS Documentation
• Lifecycle Hook 활용
• 종료 전 애플리케이션 graceful shutdown, Kafka 브로커라면 리플리카 제거 / 파티션 이동 등을 수행. 종료 완전하게 하기 전에 새 인스턴스 준비 완료를 기다리는 구조가 안정적.
• 인스턴스 타입 우선순위 고려 (Overrides + 우선도)
• 일부 타입이 더 비용 효율 좋거나 퍼포먼스 좋다면 우선순위 붙여 사용 가능. 혼합 정책에서 가중치를 두는 방식.
• 적절한 TTL + DNS 전략
• 브로커 교체 시 DNS 시간이 지연되는 걸 줄이기 위해 FQDN + 짧은 TTL + 클라이언트 쪽 캐시 제어 설정 필요.

---

마무리

“비용 절감” + “운영 안정성”이라는 두 마리 토끼를 잡고 싶다면, Spot 인스턴스의 단점을 보완해 주는 이 조합이 현재 AWS 환경에서 매우 검증된 패턴입니다.

• ASG로 기본 Desired Capacity 유지
• Capacity-Optimized 전략으로 Spot 풀 리스크 낮춤
• Capacity Rebalancing으로 종료 예고 + 교체 처리 자동화

위 패턴을 Kafka 브로커나 유사 상태ful 서비스에 적용하시면, Spot 기반이라도 상당히 안정성 있게 운영 가능하실 거예요.