Karpenter + Spot 조합을 알아보자 (2)

두개의 조합을 사용했을 때 문제없이 완벽할 수 있을까??

장,단점이 궁금해서 발생할 수 있는 경우를 정리해본다.

 

karpenter 의 문제보다는 Spot 인스턴스의 트레이트오프에서 발생하는 문제점이 있을 수 있다.

 

1. 콜드 스타트 문제

콜드 스타트는 새로운 인스턴스나 컨테이너가 처음 시작될 때 발생하는 초기화 지연이 발생하는 것을 의미한다.

Karpenter는 이러한 것을 보완해줄 수 있지만 완벽히 해결,없애지는 못한다.

 

Spot 인터럽트 발생 시 pod가 트래픽을 받기까지 걸리는 시간 

- 노드 프로비저닝 ~60초 (Karpenter가 빠르게 처리)

- 이미지 pull ~5~60초 

- Spring boot 기동 ~30~120초

- 헬스체크 최대 00초 (설정에 따라)

이렇게 까지보면 평균 2~3분은 걸릴 것 같다.

 

그럼 서비스 중단이 일어나지 않을까??

콜드 스타트가 있어도 서비스가 끊기지 않는 이유는 Karpenter가 아니라 아키텍처 설계 때문이다.

보통 운영에서는 파드 1개로 운영하지는 않기때문에..

service-spot 노드 A -> pod-1 (트래픽 처리 중)
service-spot 노드 B -> pod-2 (트래픽 처리 중)

노드 A Spot 인터럽트 발생 (회수될 예정) 

-> pod-1 종료 
-> pod-2가 혼자 트래픽 전부 처리
-> 노드 C 생성 + pod-1 재기동 완료 후 복귀

 

Pod Anti-Affinity : 2개 파드가 반드시 다른 노드에 배치

HPA minReplicas: 2 (항상 최소 2개 유지)

startupProbe: 기동 완료 전까지 트래픽을 받지 않음 

 

위와 같은 설정으로 서비스 중단없이 진행할 수 있다.

다시 한번 그림으로 보면 아래와 같다.

 

[ 정상 상태 ]
  ──────────────────────────────────────────────────────
    노드 A (Spot)          노드 B (Spot)
    ┌─────────────┐        ┌─────────────┐
    │  Pod-1 ✅   │         │  Pod-2 ✅   │
    │  트래픽 50% │          │  트래픽 50%  │
    └─────────────┘        └─────────────┘
           ↑                      ↑
           └──────────────────────┘
                    ALB


  [ T+0 : Spot 인터럽트 신호 수신 ]
  ──────────────────────────────────────────────────────
    노드 A (Spot) ⚠️        노드 B (Spot)
    ┌─────────────┐        ┌─────────────┐
    │  Pod-1 🔄   │        │  Pod-2 ✅    │
    │  Drain 시작  │        │  트래픽 100%  │  ← 혼자 처리
    └─────────────┘        └─────────────┘

    Karpenter: 새 노드 C 프로비저닝 시작 (~60초)


  [ T+60초 : 새 노드 준비 완료 ]
  ──────────────────────────────────────────────────────
    노드 A (종료)           노드 B (Spot)    노드 C (Spot) 🆕
                           ┌─────────────┐  ┌─────────────┐
                           │  Pod-2 ✅   │  │  Pod-1 ❄️    │
                           │  트래픽 100%  │  │  기동 중...  │
                           └─────────────┘  └─────────────┘

                           ← startupProbe 통과 전까지 트래픽 차단


  [ T+60~180초 : 콜드 스타트 구간 ]
  ──────────────────────────────────────────────────────
                           노드 B (Spot)    노드 C (Spot)
                           ┌─────────────┐  ┌─────────────┐
                           │  Pod-2 ✅   │  │  Pod-1 ❄️   │
                           │  트래픽 100%  │  │  이미지 pull │
                           └─────────────┘  │  JVM 기동    │
                                            │  헬스체크     │
                                            └─────────────┘
                                ↑
                           사용자는 영향 없음


  [ T+180초~ : 정상 복구 ]
  ──────────────────────────────────────────────────────
                           노드 B (Spot)    노드 C (Spot)
                           ┌─────────────┐  ┌─────────────┐
                           │  Pod-2 ✅   │  │  Pod-1 ✅   │
                           │  트래픽 50%   │  │  트래픽 50%  │
                           └─────────────┘  └─────────────┘
                                  ↑                ↑
                                  └────────────────┘
                                         ALB

 

--

 

2. spot은 실제로 얼마나 자주 회수될까 ?

AWS Spot Instance Advisor 기준 ARM64 Graviton 인스턴스의 회수 빈도는 

- 회수 빈도: < 5~15% (한 달 기준)

- 즉, 한 달에 한 번 회수될까 말까 수준

 

일반 x86 대비 Gravition이 회수율이 낮은 이유는 수요가 상대적으로 적어서 AWS 유휴 자원이 더 풍부하다고 한다.

* https://aws.amazon.com/ko/ec2/spot/instance-advisor/ 

인스턴스 별 온디맨드 대비 절감액, 중단빈도 등 확인할 수 있다. 

Amazon EC2 스팟 인스턴스 - AWS

 

--

 

3. 진행 중인 API 요청은 유실될까? 

설정이 올바르면 유실되지 않는다.

- ALB에서 해당 파드 제거 (신규 요청 차단)

- 진행 중인 요청 처리 완료 대기

- 대기 시간 초과 시 강제 종료 (terminationGracePeriodSeconds 설정)

 * 설정안하면 기본 시간 30초 -> spot 인터럽트가 최대 2분이므로, 2분 초과는 효과 없음

 

--

 

4. Gravition(ARM64)을 선택한 이유

인프라 계획시 비용을 가장 우선시했다.

같은 스펙 기준 대비 약 20% 이상 저렴하다.

m6i.xlarge  (x86, 4코어/16GB): $0.192/h
m6g.xlarge  (ARM64, 4코어/16GB): $0.154/h  → 20% 저렴

여기서 Spot 할인까지 적용하면 차이가 더 벌어진다.

추가적으로 Spot 재고는 x86 대비 수요가 적어서 비교적 풍부하고 회수율이 낮은 장점이 있다. 

 

성능적인 면에서도 x86보다 최대 40% 높은 성능을 제공하고, 

현재 프로젝트인 spring boot 기반 java 애플리케이션에서도 ARM64가 호환이 가능하다.

 

단점으로는 Graviton이 비용/성능 면에서 유리하지만 생태계가 x86보다 좁다.

새 도구를 도입할 떄마다 ARM64 지원 여부를 먼저 확인해야 하는 단점이 있다.

 

--

 

5. Spot 노드가 모두 동시에 회수되면?

특정 AZ 전체 장애가 나거나, 특정 인스턴스 타입 재고가 완전 소진되는 경우가 있을 '수' 있다.

이를 대비하기 위한 방법으로는 인스턴스 타입을 다양화 시키는 방안이 있다.

  # 현재: 4코어 고정
  { key = "karpenter.k8s.aws/instance-cpu", values = ["4"] }

  # 개선: 4코어 + 8코어 허용
  { key = "karpenter.k8s.aws/instance-cpu", values = ["4", "8"] }
  { key = "karpenter.k8s.aws/instance-family", values = ["m6g", "c6g", "r6g", "m7g", "c7g"] }

인스턴스 타입 풀이 넓을수록 동시 회수 리스크가 줄어든다.

 

--

 

6. Karpenter가 죽으면?

먼저 Karpenter가 하는 일은 

- 새 pod 생성 요청이 오면 노드 프로비저닝

- 노드가 비어있을 때 노드 삭제

- spot 인터럽트가 오면 신호 수신 후 대응

 

이러한 역할을 하는데 죽게 되면

- 기존 노드와 pod는 영향이 없다 (계속 동작)

- 신규 노드 생성이 불가능

- spot 인터럽트가 일어나면 노드는 강제종료 되지만 pod 이동이 불가능하다.

- Consolidation도 중단

 

즉, 기존 서비스는 살아있지만 확장/복구 능력을 잃는다.