과금 지표 vs 파드 런타임 상태

컨테이너가 안 뜬다는 제보를 받고 사용량 DB 부터 열었더니 그 사용자 행은 state = active 였습니다. 요청한 환경은 돌고 있다는 얘기라 앱이나 접속 경로 쪽을 봐야 하나 싶었는데, 정작 파드는 안 떠 있었습니다.

브라우저로 접속해 쓰는 원격 개발 환경 서비스라 환경 하나가 파드 하나고, 작업하던 파일이 남아야 하니 EBS 볼륨을 PVC 로 붙여 둡니다. 과금은 컨테이너를 띄워 둔 시간으로 매기는데 쿠버네티스에는 그 시간을 집계하는 기능이 없어서, 띄우고 내릴 때마다 애플리케이션이 자체 DB 에 행을 남기고 그 행으로 사용량을 계산합니다. 그 DB 가 정산의 근거이면서 지금 누가 환경을 쓰는지 볼 때도 제일 먼저 여는 곳이라, 제보를 받고도 거기부터 연 겁니다.

state 컬럼이 재는 것 — 파드 상태가 아님

state 는 애초에 과금을 집계하려고 만든 컬럼입니다. 사용자가 환경 생성을 요청한 시점에 active 로 기록되면서 거기서 과금 시작 시각이 잡히는 값이라 파드가 실제로 Ready 까지 갔는지는 반영되지 않습니다. 파드가 ContainerCreating 이나 Pending 에서 멈춰 있어도 요청은 이미 접수됐으니 사용량 DB 에는 active 로 남습니다.

신호	실제로 뜻하는 것
사용량 DB state=active	실행을 요청했다
파드 Running + Ready	컨테이너가 떠 있다

재는 게 다르니 앞의 값으로 뒤의 상태를 판단할 수 있는 게 아닙니다.

실제 상태 — 볼륨 attach 실패로 멈춘 파드

파드 이벤트를 보니 볼륨 Attach 가 실패하고 재시도를 반복하는 중이었습니다.

Warning  FailedAttachVolume  ...  AttachVolume.Attach failed for volume "pvc-..."

이벤트에는 볼륨이 안 붙는다는 사실만 있고 왜 안 붙는지가 없어서 같은 시각의 CloudTrail AttachVolume 이벤트에서 errorCode 를 찾았습니다.

errorCode: Client.InvalidVolume.NotFound

붙이려던 EBS 볼륨이 이미 없어져 있었고, 볼륨이 사라진 이상 Attach 는 몇 번을 재시도해도 실패하니 파드는 ContainerCreating 에서 못 벗어나고 그동안에도 사용량 DB 는 active 라 과금은 계속 붙었습니다.

신호별 확인처 — 요청과 런타임은 답하는 질문이 다름

제보 하나를 설명하는 데 신호가 셋 필요했고, 각각 답해 준 건 여기까지였습니다. 사용량 DB 는 사용자가 환경을 요청했다는 것까지, 파드 이벤트는 볼륨이 안 붙어서 멈춰 있다는 것까지, CloudTrail 은 그 볼륨이 이미 없다는 것까지입니다. 어느 하나도 나머지 둘의 질문에는 답해 주지 않습니다.

그래서 과금 로그로 파드 헬스를 판단하면 멈춘 파드가 정상으로 보이고, 반대로 파드 상태만 보고 과금을 판단하면 요청은 들어왔는데 정산이 빠집니다.

active는 실행 상태가 아니라 요청 접수

active 나 running 같은 이름이 붙어 있어도 그게 런타임 상태라는 보장은 없어서, 이 컬럼도 요청을 접수한 시각을 남기는 값이었습니다. 지표가 틀린 값을 준 게 아니라 자기가 재는 것만 정확히 답한 건데, 그걸 다른 질문의 답으로 읽은 쪽이 문제였습니다.

같은 제보를 다시 받으면 확인 순서를 이렇게 잡으면 됩니다. 과금·사용량 지표는 사용자가 무엇을 요청했나까지만 답해 주니 거기서 멈추고 실제로 떠 있는지는 파드 상태와 이벤트로, 왜 못 떴는지는 클라우드 API 의 에러코드까지 내려가서 확인합니다.