Spot 인스턴스를 안정적으로 쓰는 방법: ASG + Capacity-Optimized + Capacity Rebalancing 2편(단점, 무중단, 장점)

 

 

 

공식 문서에서 말하는 한계 & 주의사항

AWS 문서 “Capacity Rebalancing in Auto Scaling”에 따르면 다음 같은 고려사항들이 있어요: AWS Documentation

 

항목	내용
Application의 관용성	애플리케이션이 Spot 중단/교체에 내성이 있어야 함. 상태 저장(stateful) 작업이나 연결 유지가 중요한 경우, graceful shutdown, 데이터 복제, 리플리카/리스너 종료 처리 등이 필요. AWS Documentation
Launch Template / 인스턴스 타입 / AZ 다양성	Spot 풀(pool)의 여유(capacity)가 많은 타입/AZ들을 여러 개 열어야 재보충(reserve)이 가능. 단일 타입/AZ만 쓰면 그 풀의 여유가 없을 때 복구가 어려움. AWS Documentation
Lifecycle Hook / 종료 처리 시간	인스턴스 교체 시 종료 시그널 → 애플리케이션 종료/트래픽 정리 등이 필요하다면 그 시간만큼 여유를 줘야 함. Hook timeout을 적절히 설정해야 함. AWS Documentation
최대/최소 규모(max/min size) & 오버헤드(overshoot)	Capacity Rebalancing 활성 시, 새로운 인스턴스가 올라오기 전에 기존 인스턴스가 유지되므로, ASG가 최대 용량(max size) 설정 близ으면 오버슈트(over-capacity)가 제한되거나 못 할 수 있음. 때때로 실행되는 replacement가 최대치 도달 시 지연됨. AWS Documentation
비용 증가 가능성	미리 새 인스턴스를 띄우는 동작이 있으므로, “한 시점에 두 인스턴스”가 동시에 존재하는 경우가 생김. 특히 용량 교체(replacement) 중이면 잠시 중복비용 발생할 수 있음. 또한 low-price allocation 전략을 쓰면 위험(새로 띄운 인스턴스도 곧 중단될 가능성 있는 풀) 있음. AWS Documentation

---

추가 단점 & 실무에서 겪는 문제들

공식 문서 외 실제 사용자 경험 및 업계 지침 보면 다음도 문제로 자주 나와요:

1. 인스턴스 교체 빈도 증가(churn 증가)
   • 리밸런스 추천(rebalance recommendation)이 자주 오면 브로커 교체가 잦아짐 → 연결 재설정, 파티션 리밸런스, 서비스 핫스팟 등이 생길 수 있음.
2. Graceful Shutdown 및 연결 끊김 시간 손실
   • Kafka 브로커나 상태 유지(workload)가 많은 서비스는 인스턴스 종료 전에 “연결 종료 / 리더 이동 / 파티션 정리 / 메모리 플러시” 등이 필요. 종료 요청이 빠르게 오면 충분한 시간이 안 될 수 있음.
3. DNS / 광고(advertised) 블록 재갱신 지연
   • 브로커 주소가 바뀌면 DNS / 광고된 주소(advertised.listeners) 갱신 + 클라이언트 메타데이터 갱신까지 시간이 걸림 → 클라이언트 쪽 연결 오류 또는 시간 지연.
4. On-Demand fallback / Spot 종속성 위험
   • Spot 여유(capacity)가 전혀 없을 경우 배포가 지연됨. 또는 아예 원하는 타입·AZ에서 Spot 용량이 사라질 수 있음. 이럴 경우 On-Demand가 필요하거나 대체 계획(fallback) 있어야 함. AWS ASG 또는 Fleet은 일부 On-Demand 혼합(mixed instances) 옵션을 포함하는 게 좋다는 권장사항 있음. AWS Documentation
5. 복잡성 증가
   • 초기 설정할 항목이 많아짐: mixed types policy, AZ 분산, lifecycle hooks, 건강 체크(Health Check), 종료 처리 루틴, DNS 자동 갱신 등.
   • 모니터링/알림/로깅이 보다 중요해짐(어느 인스턴스가 왜 대체되는지, 종료 예고를 받았는지, 교체 후 정상 작동했는지 등).
6. 비용 관리가 복잡해질 수 있음
   • Spot은 싸지만, 중복 인스턴스 또는 중복 리소스 (예: 데이터 복사, 중복 이동, 중복 EBS 볼륨 등)가 잠시 있을 수 있고, 리밸런스 동작이 잦으면 그만큼 리소스 소비도 늘 수 있음.

---

 “거의 단점 없이”일 수도, 하지만 …

Capacity Rebalancing + ASG + capacity-optimized 조합은 Spot 인스턴스를 “상당히 안정적으로” 쓸 수 있게 해 줍니다. 많은 경우에는 초기 구성/설정만 제대로 해두면 실질적으로 단점이 거의 드러나지 않기도 하고, 비용 절감 & 유연성이 큰 장점이 되죠.

그렇지만 아래 조건들이 만족되지 않으면 여전히 위험 요소가 남습니다:

• 애플리케이션이 중단에 내성을 가져야 함 (stateful한 서비스라면 복제/무정지 이전 준비가 돼야 함).
• 인스턴스 타입/AZ 다양성 확보.
• 종료/교체 시 정리(clean-shutdown) & 연결 끊김 최소화 설계.
• DNS / 브로커 광고 주소(advertised.listeners) 같은 주소 변경 대응 구조.
• 비용/중복 사용 가능성 이해 및 예상.

 

---

 

 

왜 무중단이 아닌가?

1. Warm-up & 오버슈트
   • Rebalancing은 “중단 위험 알림”을 받으면 새 인스턴스를 먼저 띄운 뒤 기존 인스턴스를 종료합니다.
   • 이때 순간적으로 두 인스턴스가 동시에 존재(비용 증가) → 무조건 무중단은 아니고, 새 인스턴스가 정상화될 때까지는 전환 과정이 필요합니다.
2. 애플리케이션 레벨 전환
   • EC2 인스턴스 교체가 끝나도, Kafka 브로커·DB 노드·웹 서버 같은 애플리케이션은 연결 해제 → 새 노드로 이동 과정이 필요합니다.
   • 이때 클라이언트 재시도, DNS 재조회, 세션 재연결이 발생 → 사용자 입장에서는 짧은 끊김이 느껴질 수 있음.
3. 교체 신호 타이밍 불확실성
   • AWS의 “rebalance recommendation”은 중단 2분 전에 오는 Spot interruption 알림보다 조기에 올 수 있지만, 항상 보장되는 건 아님.
   • 늦게 오거나 거의 동시에 오면 Warm-up 효과가 제한됨.
4. 상태 관리 문제
   • 상태ful 워크로드(예: Kafka, RDS, 캐시 클러스터)는 종료 시 데이터를 flush하거나 리플리카를 재배치하는 시간이 필요합니다. 이 과정을 graceful하게 처리하지 않으면 잠깐의 데이터 손실/중단 발생 가능.

---

현실적인 결론

• “무중단” = 불가능에 가깝습니다. (특히 상태ful 서비스)
• 다만 Capacity Rebalancing 덕분에:
  • 새 인스턴스를 미리 준비 → 끊김 시간을 크게 줄일 수 있음
  • ASG의 Desired Capacity를 유지 → 전체 클러스터 안정성 확보
• 즉, **“거의 무중단 수준”**으로 체감되게 만들 수는 있지만, 완벽하게 다운타임 0으로 만드는 건 불가능합니다.

---

보완 전략

• Multi-AZ / Multi-broker 구성: Kafka라면 RF=3, min.insync.replicas≥2로 데이터 내구성 확보.
• 클라이언트 레벨 튜닝: DNS TTL 단축, client.dns.lookup=use_all_dns_ips, metadata.max.age.ms 조정 → 빠른 재연결.
• Graceful shutdown + Lifecycle Hook: 종료 전에 브로커에서 파티션 리더 이동, 세션 종료 처리.
• Fallback 계획: Spot 풀에 용량이 없을 경우를 대비해 일부 On-Demand 혼합.

---

👉 요약:
Capacity Rebalancing은 Spot 단점을 크게 줄여주지만 무중단은 아님.
중단 시 짧은 이동/전환 시간은 불가피하며, 이를 최소화하려면 애플리케이션 레벨에서 failover, graceful shutdown, 클라이언트 재연결 전략까지 함께 설계해야 합니다.

 

 

---

 

무중단이 아님에도장점은 존재한다. 비용!

 

왜 Spot이 유리한가?

1. 비용 절감 효과 극대화
   • 동일 성능 대비 최대 70~90% 절감 가능.
   • 웹서비스 계층(Stateless App 서버, API 서버)은 트래픽에 따라 스케일인/아웃이 잦기 때문에 변동성이 큰 Spot과 잘 맞음.
2. 상태 비저장(Stateless) 특성과 궁합
   • 웹서비스는 보통 세션/상태를 DB나 Redis 같은 외부 저장소에 위임.
   • 인스턴스가 중단되어도 사용자는 큰 차이를 못 느낌. (로드밸런서가 다른 서버로 트래픽 라우팅)
3. ASG + ALB 통합 시 자동 복구
   • Spot 인스턴스가 중단되면 ASG가 즉시 새 인스턴스를 보충.
   • ALB/ELB가 헬스체크로 불량 인스턴스를 빼고 새 인스턴스를 자동 등록.
4. Capacity Rebalancing으로 안정성 보완
   • 중단 리스크는 남지만, Capacity Rebalancing 덕분에 새 인스턴스를 미리 준비 → 체감 다운타임 최소화.

---

단, 고려할 점

• 멀티 AZ + 여러 타입 열어두기
  Spot 용량 풀은 언제든 고갈될 수 있음. 따라서 여러 인스턴스 타입, 여러 AZ를 허용해 두는 게 안정적.
  (예: t3.large, t3a.large, m5.large, m6g.large 등 혼합)
• 중단 이벤트 대비
  서비스 자체가 끊기지 않더라도, 갑작스런 scale-in/out이 로그/모니터링에 영향을 줄 수 있음.
  → 종료 알림(EventBridge → Lambda/Slack)으로 가시성 확보 권장.
• 일부 On-Demand 혼합 고려
  핵심 워커 20%는 On-Demand로 두고, 나머지 80%를 Spot으로 구성하면 중단 시에도 최소 용량 확보.
• 데이터 저장 금지
  Spot 인스턴스는 언제든 날아갈 수 있으므로 로컬 디스크에 중요한 데이터를 두지 말아야 함.
  (EBS, S3, RDS 등 외부 스토리지 활용)

---

결론

• 웹서비스 / API 서버 / 백오피스 / 주기적 배치 잡 → Spot 인스턴스에 매우 적합.
• 밀리초/초 단위 지연이 치명적인 스트리밍·금융거래 서비스 → 여전히 On-Demand/Reserved 권장.
• 혼합 전략(20% On-Demand + 80% Spot) → 안정성과 비용 절감의 밸런스.

---

👉 정리하면:
웹서비스나 시간 민감도가 낮은 서비스에서는 Spot = 비용 절감의 거의 필수 카드고,
ASG + Capacity-Optimized + Rebalancing을 붙이면 안정성도 충분히 보장할 수 있습니다.