Spot 노드에 중단 통지가 왔을 때 큐 작업·게임 세션·대체 용량을 어떻게 처리해야 하나요?

Spot 중단 통지는 노드가 곧 회수될 가능성을 알려 새 작업을 멈추고 기존 작업을 정리할 기회를 줍니다. 하지만 통지가 항상 전달되거나 충분한 시간을 보장하는 것은 아니므로, 통지 없는 즉시 종료에도 작업이 유실되지 않고 재처리되도록 설계하는 것이 기본입니다. Karpenter의 interruption handling과 drain은 종료 순서를 돕지만, 큐 작업의 원자성이나 게임 세션 상태의 이전을 자동으로 보장하지 않습니다.

큐 소비자는 통지를 받으면 새 메시지 수신을 중단하고 처리 중인 작업을 제한 시간 안에 마무리할지 판단합니다. 외부 DB 변경이나 결제를 먼저 반영한 뒤 ACK를 보내야 하며, 시간 안에 끝나지 않으면 ACK하지 않고 visibility timeout·redelivery 정책에 따라 재전달되게 합니다. 처리 중 checkpoint를 저장할 수 있다면 재개 위치를 기록하되, checkpoint와 외부 효과 사이에도 간격이 있으므로 같은 메시지가 다시 와도 멱등 키로 중복 반영을 막겠습니다.

통지의 기회와 장애 내구성을 나눕니다

중단 이벤트가 전달되면 node를 cordon하고 새 Pod 유입을 막은 뒤, 기존 Pod에 종료 신호를 보내고 terminationGracePeriod 안에서 드레이닝합니다. 소비자는 새 메시지 fetch를 멈추고 현재 작업을 ACK할지 중단할지 결정합니다. ACK를 먼저 보내면 노드가 꺼져도 작업이 사라질 수 있고, 외부 효과 뒤 ACK가 유실되면 같은 메시지가 다시 처리될 수 있습니다. 그러므로 ACK는 처리 완료의 신뢰 가능한 지점으로만 사용하고, DB 조건부 갱신·멱등 작업 ID·결과 조회를 조합합니다.

통지가 늦거나 누락된 경우에는 프로세스가 갑자기 죽습니다. 이 경우 재시작한 consumer가 메시지를 다시 받고 같은 효과를 한 번 더 시도할 수 있으므로 중복 처리 방지가 핵심입니다. 긴 작업은 checkpoint 주기를 너무 길게 두면 유실 작업량이 커지고, 너무 짧게 두면 저장 부하와 재개 복잡성이 늘어납니다. 허용 가능한 재처리량과 작업 비용으로 주기를 정하겠습니다.

게임 세션은 큐 작업과 다릅니다. 메모리에만 있는 위치·전투 상태를 짧은 종료 유예 안에 통째로 옮길 수 있다고 가정하면 안 됩니다. 상태를 주기적으로 복제하거나 checkpoint하고, 새 서버가 마지막 승인 틱·입력 위치부터 재개하게 하며, 이전 서버의 입력이 늦게 도착해 중복 적용되지 않는 소유권 전환점을 둡니다. 단순히 새 Pod가 뜨면 사용자가 같은 세션을 자동으로 이어간다는 보장은 없습니다.

대체 용량과 비용을 같이 설계합니다

Spot이 회수된 뒤 다른 Spot 인스턴스가 즉시 생긴다는 보장도 없습니다. 여러 인스턴스 유형·가용 영역·가격 용량을 허용하고, 핵심 최소 용량은 on-demand나 별도 pool로 유지할지 정하겠습니다. 한 유형만 허용하면 통지 후 대체 노드가 Pending으로 남을 수 있습니다. 대체 Node Ready까지의 시간과 Pod readiness, 이미지 예열을 측정해 drain 유예보다 긴 경우에는 사전 여유 용량을 둡니다.

검증은 통지 있음·통지 없음·대체 용량 부족·ACK 직전 종료·checkpoint 직후 종료·게임 재접속을 나눠 실행합니다. 작업 유실·중복, 외부 효과의 최종 횟수, 재처리 시간, 대체 노드 Ready 시간, 세션 복구 위치와 사용자 오류율을 확인하겠습니다. Spot은 중단 가능한 용량(interruptible capacity)이므로 비용 이득을 얻는 대신 임의 종료와 재배치 가능성을 애플리케이션 계약에 포함해야 합니다.