사례3건

3건 중 1~3번째

1. IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.

   Buildkite2026

   증상

   22:47 UTC 부터 Buildkite 웹 화면, REST API, Agent API, 작업 큐, 알림이 한꺼번에 장애를 겪었다. 모든 고객이 웹 화면이나 REST API 로 새 빌드를 만들 수 없었고, 작업 배정이 늦어졌다.

   서비스 중단DNS 조회 실패OOMKilled오토스케일러 오동작

   촉발

   22:44 UTC 에 애플리케이션을 배포하면서 파드가 한꺼번에 늘어 이미 떠 있던 노드의 여유 용량이 바닥났다. 같은 시각 알림 워커를 비롯한 백그라운드 워커들도 확장하려 했고, 노드 공급이 늦어지자 확장 지표가 그대로인 채 파드를 계속 더 요청했다. 이 워커들의 최대 레플리카 수는 평소보다 높게 잡혀 있었다.

   원인

   용량 한계

   구성 요소

   CoreDNS컨테이너 메모리 한도수평 파드 오토스케일러노드 풀

   기여 요인

   여유 용량 부재자동화 증폭재시도 폭주모니터링 사각지대

   감지

   장애는 22:47 UTC 에 시작됐고, Buildkite 는 22:55 UTC 에 문제를 조사 중이라고 상태 페이지에 처음 알렸다. 23:05 UTC 에는 사이트 전체 장애를 조사 중이라고 올렸다. CoreDNS 쿼리 처리 시간은 클러스터가 커지면서 늘고 있었지만, 핵심 모니터링 쿼리의 결함과 쿼리량 모니터링 부족 때문에 장애 전에는 이를 알아채지 못했다.

   조치

   • 추가 애플리케이션 배포를 멈췄다.
   • CoreDNS 파드를 3개에서 12개로 늘렸다.
   • CoreDNS 파드마다 메모리 한도를 512 MiB 에서 2 GiB 로 올렸다.
   • CoreDNS 를 돌리는 시스템 노드 풀을 늘렸다.

   후속 조치

   • CoreDNS 파드를 3개에서 12개로 늘리고, 파드당 메모리 한도를 512 MiB 에서 2 GiB 로 올리고, 이 파드들을 돌릴 시스템 노드 풀을 넓혔다.
   • EKS 관리형 CoreDNS 오토스케일링을 켠다. 검증한 최소 레플리카 수를 정하고, 레플리카를 여러 노드와 가용 영역에 나눠 둘 만큼 용량을 확보한다.
   • CoreDNS 쿼리 처리 시간, 쿼리량, 고루틴 증가, 메모리 압박, OOM 재시작, 사용 가능한 레플리카 수에 직접 알림을 건다. 장기 추세도 용량 계획에 넣어 지켜본다.
   • 클러스터에 꼭 필요한 다른 서비스도 살핀다. 검증된 용량, 직접 알림, 장애 도메인 분산이 없는 서비스, 그리고 안전한 오토스케일링도 문서로 정한 고정 여유분도 없는 서비스를 찾아 고친다.

   교훈

   크기를 고정해 둔 CoreDNS 는 클러스터가 커지고 변경 속도가 빨라지면 한순간에 무너질 수 있다. 나중에 낮출 생각으로 높게 잡아 둔 워커의 최대 레플리카 수는 노드 공급이 늦어질 때 오토스케일링 폭주를 막지 못했다. 모니터링 쿼리에 결함이 있고 쿼리량을 제대로 감시하지 않아 장기 추세가 보이지 않았다. 클러스터 핵심 서비스는 급격한 저하와 여유분 감소를 둘 다 직접 감시해야 한다.

   사례 보기
2. IL-0163 자동 테스트가 잡지 못한 API 변경이 배포돼 LKE 클러스터 크기를 바꿀 때 노드가 잘못된 수만큼 만들어졌고, 고객 계정에 과금되는 노드가 늘었다

   Linode2023

   증상

   2023년 5월 31일 16시 UTC 무렵부터 일부 고객의 LKE 클러스터 크기가 예상하지 못한 방식으로 바뀌었다. 클러스터 크기를 조정하면 잘못된 수의 노드가 만들어졌고, 고객 계정에 과금되는 자원이 추가됐다.

   오토스케일러 오동작

   촉발

   5월 31일 16시 UTC 무렵 LKE 클러스터를 잘못 스케일링하게 만드는 API 변경이 운영에 배포됐다. 자동 테스트에 빈틈이 있어 이 실패를 잡지 못했다.

   원인

   배포 결함

   구성 요소

   노드 풀

   기여 요인

   자동 테스트 공백

   감지

   Linode 는 6월 1일 05시 07분 UTC 에 LKE 클러스터 크기를 조정하면 잘못된 수의 노드가 생기는 문제를 알고 있다고 공지했다. 변경이 나간 지 약 13시간 뒤였다.

   조치

   • 6월 1일 05시 07분 UTC 고객에게 가능하면 클러스터 크기 조정을 피하라고 안내했다.
   • 09시 40분 UTC 잘못된 스케일링을 바로잡는 핫픽스를 적용했다.
   • 고객 워크로드에 영향을 주지 않도록 늘어난 워커 노드를 지우지 않고 그대로 두었다.
   • 영향받은 고객에게 티켓으로 요금 조정과 추가 조치 방법을 알렸다.

   후속 조치

   • 자동 테스트를 점검한다.
   • 같은 일이 다시 일어나지 않도록 배포 전 체크리스트 항목을 추가했다.

   교훈

   자동 테스트가 잡지 못한 API 변경 하나가 고객 클러스터의 노드 수를 바꾸고 요금까지 늘렸다. Linode 는 테스트를 점검하고 배포 전 체크리스트를 늘리는 것으로 대응했다. 잘못 늘어난 노드라도 지우면 고객 워크로드에 영향을 줄 수 있어서, Linode 는 노드를 지우지 않고 요금 조정으로 보정했다.

   사례 보기
3. IL-0014 GKE 를 1.12.5-gke.10 으로 올리는 중 노드 풀 업그레이드가 멈추고 인그레스와 HPA 가 망가졌다

   loveholidays2019

   증상

   미뤄 둔 GKE 업그레이드를 하던 저녁, 마스터는 문제없이 올라갔지만 노드 풀 업그레이드가 예상보다 훨씬 오래 걸렸다. 노드가 14개이고 노드당 5분쯤 걸리는 클러스터도 한 시간 넘게 걸렸고, 일부 노드는 드레인에 15분 넘게 걸렸다. emptyDir 를 쓰는 파드와 5분에서 10분짜리 terminationGracePeriodSeconds 가 드레인을 늦췄다.

   업그레이드 정체파드 Pending노드 증설 실패서비스 중단오토스케일러 오동작

   촉발

   마이그레이션에 쫓겨 미뤄 둔 업그레이드로 운영 클러스터를 1.10.X 에서 1.12.5-gke.10 으로 올렸다. 구글은 3월 14일 GKE 릴리스 노트에서, 이 버전으로 올린 마스터의 오류율이 높아진다는 보고가 있어 새 클러스터와 마스터 업그레이드에서 이 버전을 빼는 중이라고 밝혔다. 그런데도 3월 19일에 이 버전을 고를 수 있었다.

   원인

   클라우드 제공자 장애

   구성 요소

   GKE 컨트롤 플레인노드 풀클러스터 오토스케일러인그레스 컨트롤러수평 파드 오토스케일러

   기여 요인

   스테이징 불일치장애 중첩초기 신호 무시

   감지

   업그레이드하던 엔지니어가 드레인이 느리고 노드 풀 업그레이드가 멈추고 파드가 Pending 에 머무는 것을 직접 보았다. 인그레스 장애는 업그레이드 뒤에 드러났고, 로그로 원인을 찾지 못해 구글 지원팀에 물어 알려진 버그라는 것을 알았다. HPA 이상은 업그레이드 다음 날 발견했다.

   조치

   • 노드 풀의 노드 목록을 뽑아 kubectl drain 에 --ignore-daemonsets --delete-local-data 를 주어 노드를 미리 드레인했다.
   • 노드 풀에 해당하는 관리형 인스턴스 그룹을 찾아 gcloud compute instance-groups managed delete-instances 로 멈춘 인스턴스를 지웠다.
   • gcloud container operations list 로 operationType: UPGRADE_NODES, status: RUNNING 인 작업을 찾아 gcloud beta container operations cancel 로 멈춘 노드 풀 업그레이드를 취소했다.
   • 동작을 멈춘 내부 인그레스 대신 한동안 port-forward 로 접근했다.
   • HPA 가 이상해진 배포에서 활성 레플리카셋이 두 개면 오래된 레플리카셋을 천천히 줄였고, 하나면 더미 환경 변수를 바꿔 다시 배포했다.

   후속 조치

   • HorizontalPodAutoscaler 가 최대치의 70% 와 100% 에 닿으면 Alertmanager, Prometheus, Slack 으로 경보를 보내게 했다.
   • 배포에 활성 레플리카셋 두 개가 30분 동안 남아 있을 때와 60분 동안 남아 있을 때 경보를 보내게 했다.
   • 임의로 크게 잡은 종료 유예 시간을 다시 따져 본다.
   • 클러스터를 업그레이드하기 전에 GKE 릴리스 노트를 먼저 확인한다.
   • 운영이 아닌 환경에는 자동 업그레이드를 쓰고, 운영 환경은 클러스터를 수동으로 업그레이드하고 노드는 자동 업그레이드를 쓴다.
   • 사전 검증 환경을 이름까지 운영과 최대한 똑같이 맞춘다.

   교훈

   클러스터를 업그레이드하기 전에는 GKE 릴리스 노트를 먼저 봐야 한다. 운영이 아닌 환경에는 자동 업그레이드를 써서 영향을 먼저 겪고, 운영에는 수동 클러스터 업그레이드와 자동 노드 업그레이드를 섞어 예측 가능성과 유지 부담 사이에서 균형을 잡는다. 사전 검증 환경은 이름까지 운영과 같게 둬야 한다. 노드 풀 업그레이드 시간은 노드 수와 드레인 시간에 달려 있다. emptyDir 를 쓰는 파드에 safe-to-evict 어노테이션을 달고, 지나치게 긴 종료 유예 시간을 다시 따져 보고, PodDisruptionBudget 을 두면 드레인이 빨라진다.

   사례 보기

원인별3