우리 AWS 서비스에 EC2 Spot을 적용해도 될까?

AWS EC2 Spot 인스턴스 도입을 "쓸까 말까"의 이분법이 아니라, 어떤 워크로드에 어떤 비율로 어떤 안전장치와 함께 써야 하는지를 이항분포 기반 정량 분석으로 판단한 사례다. LG U+는 On-Demand 대비 약 60% 비용 절감이 가능한 Spot을 실제 서비스에 적용하면서 가용성 리스크를 계산하고, Karpenter로 비율을 선언적으로 제어하는 구성을 공유한다.

핵심 포인트

Spot은 On-Demand 대비 약 60% 저렴하지만 Interruption(2분 전 통보 후 회수)과 Capacity Shortage(용량 자체 부재) 두 가지 리스크를 구분해야 한다.
평균 3시간 중단 주기, 10분 회복 시간을 가정하면 개별 Spot 인스턴스의 특정 시점 가용 확률은 약 94.44%다.
이항분포로 계산 시 Spot 3대 구성에서 동시 불가용 확률은 약 0.02% 수준으로 낮아진다.
통합 ID 서비스는 Spot:On-Demand = 2:1 비율로 공격적 적용, Stateful 워크로드인 멤버십 서비스는 On-Demand만 유지하는 워크로드별 차별화 전략을 택했다.
Karpenter NodePool의 capacity-spread 라벨과 topologySpreadConstraints로 Spot 비율을 코드로 선언적 제어한다.

상세 정리

비용 동기: Spot은 On-Demand 대비 약 60% 저렴하지만 AWS가 언제든 회수할 수 있어, 이 리스크를 정량화하지 않으면 도입 결정을 내리기 어렵다.
리스크 분류: Interruption(2분 전 통보, 특정 인스턴스 회수)과 Capacity Shortage(해당 AZ/타입 용량 자체 부재)를 구분하고, 후자는 인스턴스 패밀리 다양화로 대응한다.
가용 확률 계산: 평균 3시간(180분) 중단 주기, 10분 회복을 가정하면 P(가용) = 180 / (180+10) ≈ 94.44%. 이 수치를 이항분포 입력으로 사용한다.
이항분포 적용: n대 Spot 중 k대 이상이 동시 불가용할 확률 P(X≥k)를 계산 — Spot 3대 시 동시 불가용 확률은 약 0.02%로 현실적으로 수용 가능한 수준이다.
부하 증가 분석: Spot 비율 50% 시스템에서 모든 Spot이 동시 회수되면 On-Demand 노드당 부하가 2배로 급증한다. HPA CPU target을 60%로 여유 있게 설정해 Spot 회수 시 스케일아웃 시간을 확보한다.
서비스 차별화: 통합 ID 서비스는 Stateless + HPA 스케일링 용이로 Spot:On-Demand = 2:1 적극 적용. 멤버십 서비스는 Stateful 특성으로 On-Demand 전용 유지 — 동일 Karpenter 구성 내에서 워크로드 성격에 따라 비율을 달리한다.
Karpenter NodePool 구성: On-Demand NodePool에 capacity-spread 라벨 "1", Spot NodePool에 "2"와 "3"을 부여하고 topologySpreadConstraints로 1:2 비율을 선언적으로 제어한다. 인스턴스 패밀리는 c5/m5/c6i/m6i/c7i/m7i 6종 혼합으로 특정 패밀리 Capacity Shortage 리스크를 분산한다.
인프라 안전장치: PDB(Pod Disruption Budget)로 동시 제거 수를 제한하고, 6개 패밀리 분산으로 모든 Spot이 동시 회수될 가능성을 극소화한다.
앱 안전장치: Graceful shutdown으로 진행 중인 요청을 정상 완료한 뒤 종료하고, ALB deregistration delay로 라우팅에서 먼저 제외한 후 노드를 안전하게 제거한다.
결론: Spot 도입의 핵심 질문은 "쓸까 말까"가 아니라 "어떤 워크로드에, 어떤 비율로, 어떤 안전장치와 함께"이며, 이항분포로 정량화한 뒤 워크로드 성격에 맞게 비율을 결정하는 것이 실전 접근법이다.