Kubernetes 노드 드레인 중 503 급증을 막는 무중단 운영 플레이북

월요일 오전 정기 보안 패치를 위해 워커 노드 두 대를 순차 드레인하던 중, 에러 대시보드에 503이 계단처럼 올라간 적이 있었습니다. CPU와 메모리는 여유였고 파드 수치도 얼핏 정상처럼 보였는데, 실제로는 결제 API 파드가 Terminating 상태에서 오래 머무는 동안 새 트래픽이 대체 파드로 충분히 분산되지 못했습니다. 특히 우리 서비스는 점심시간 직전 트래픽이 급히 치솟는데, 그 시간대에 드레인 윈도우를 잡아 작은 지연이 곧바로 장애 체감으로 번졌습니다. 현장에서 가장 아찔했던 장면은 "노드 하나만 비우면 끝난다"고 판단해 두 번째 드레인을 바로 누르려던 순간이었습니다. 온콜 엔지니어가 재시도율 그래프를 먼저 보자고 멈춰 세웠고, 그 5분 덕분에 전체 롤백 없이 사고를 수습했습니다. 이 경험 이후 우리 팀은 드레인을 단순 인프라 작업이 아니라, 트래픽 전환 실험을 동반한 애플리케이션 이벤트로 다루기 시작했습니다.

원인 분석 기준은 세 가지로 통일했습니다. 첫째, PodDisruptionBudget이 현재 레플리카와 요청량을 감당하도록 설정됐는지 확인합니다. minAvailable을 고정값으로만 두면 평소에는 안전해 보여도 피크 타임에는 실질 가용 파드가 부족해집니다. 둘째, readinessProbe와 preStop 훅의 관계를 점검합니다. 우리는 과거에 종료 신호를 받은 파드가 로드밸런서에서 제외되기 전에 8~12초 추가 요청을 받는 구간이 있었고, 이 짧은 틈에서 503이 집중됐습니다. 셋째, 노드당 여유 용량을 숫자로 선언합니다. "대충 버틸 것"이 아니라 드레인 직전 기준으로 서비스별 요청량 상위 3개를 뽑아, 남은 노드 조합에서 파드당 동시 처리량이 어느 정도인지 계산해야 합니다. 이 기준을 문서화하자 장애 회의가 감정적 추측에서 빠져나왔고, 누가 교대 근무에 들어와도 같은 순서로 의사결정을 이어갈 수 있었습니다.

실행 절차는 준비, 단일 드레인, 검증, 다음 드레인 네 단계로 운영합니다. 준비 단계에서는 대상 노드의 파드 목록을 서비스별로 정렬해 상태 저장 워크로드와 지연 민감 워크로드를 먼저 분리합니다. 그리고 kubectl drain을 바로 치지 않고, 대체 노드에 임시로 버스트가 걸렸을 때 HPA가 확장 가능한지 이벤트 로그를 10분 선확인합니다. 단일 드레인 단계에서는 한 번에 한 노드만 비우고 --grace-period와 --timeout을 팀 표준값으로 강제합니다. 검증 단계가 핵심인데, 여기서 평균 지연만 보면 실패합니다. 우리는 성공률, 재시도율, 메시지 큐 지연, 파드 재시작 횟수를 같은 화면에 띄워 15분 동안 추적합니다. 지난 분기에는 이 검증 구간에서 큐 지연이 3배로 튀는 것을 먼저 잡아, 두 번째 드레인을 연기하고 캐시 워머 파드를 선배치해 확산을 차단했습니다. 마지막으로 다음 드레인은 "첫 드레인 이후 지표가 기준선 ±10% 안으로 복귀"라는 조건이 충족될 때만 진행합니다.

운영 체크리스트는 간결하지만 생략하면 바로 사고가 납니다. 배포 전에는 서비스별 종료 시간 예산을 표로 남기고, 드레인 중지 조건을 슬랙 채널 토픽에 고정해 의사결정 흔들림을 줄이세요. 드레인 도중에는 작업자 한 명이 명령만 실행하고, 다른 한 명은 지표와 이벤트만 감시하는 2인 체계를 권장합니다. 또한 노드 교체 작업이 길어질 경우를 대비해 "30분 내 회복 실패 시 즉시 언코돈 및 이전 스케줄 복원" 같은 복구 문장을 미리 준비해야 합니다. 우리는 실제로 한 번, 스토리지 어태치 지연 때문에 새 파드 준비가 늦어졌을 때 이 문장대로 되돌려 사용자 영향 시간을 12분 안에 끊었습니다. 요약하면 노드 드레인은 쿠버네티스 명령 지식보다 운영 리듬이 더 중요합니다. 순서를 고정하고, 중지 기준을 숫자로 정의하고, 한 단계씩 확인하면 503 급증은 충분히 예방 가능한 이벤트가 됩니다.