사례7건

7건 중 1~5번째

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-0063 Redis 스테이트풀셋을 다시 만들자 Redis 클러스터가 한꺼번에 재시작되며 일부가 망가졌고, 재연결 폭주로 백엔드가 OOM 으로 죽어 AdGuard VPN 이 약 50분 멈췄다.

   AdGuard VPN2025

   증상

   8:10 UTC 에 팀은 Redis 스테이트풀셋을 고아 삭제했다. 고아 삭제는 파드와 디스크는 그대로 두고 스테이트풀셋 객체만 지우는 방식이다. 스테이트풀셋을 다시 만들자 쿠버네티스가 8:10 부터 8:15 UTC 사이에 스테이트풀셋 전체를 빠르게 재시작했다. 처음에는 백엔드 서비스가 Redis 연결 오류를 냈지만 서비스 전체가 곧바로 무너지지는 않았다.

   서비스 중단OOMKilled프로브 실패지연 시간 증가

   촉발

   팀은 디스크를 온라인으로 늘린 뒤 Git 의 선언적 설정을 실제 상태와 맞추려고 Redis 스테이트풀셋을 고아 삭제했다. 고아 삭제는 파드와 디스크는 남기고 스테이트풀셋 객체만 지우는 방식이다. 그다음 늘린 크기를 적은 저장소 템플릿으로 스테이트풀셋을 다시 만들었다.

   원인

   설정 변경

   구성 요소

   영구 볼륨과 스테이트풀셋인메모리 캐시컨테이너 메모리 한도

   기여 요인

   헬스 프로브 부재미검증 가정단일 장애점재시도 폭주여유 용량 부재

   감지

   Redis 클러스터 여러 인스턴스의 디스크 여유 공간이 바닥나고 있다는 알림이 시작이었다. 그 뒤의 장애는 스테이트풀셋을 다시 만든 직후 백엔드 서비스가 Redis 연결 오류를 내면서 드러났다.

   조치

   • 망가진 Redis 클러스터를 손으로 복구했다. 마스터에서 쓸모없어진 노드 ID 를 지우고, 해당 레플리카를 리셋한 뒤 클러스터에 다시 붙이고 복제가 따라잡기를 기다렸다.
   • 실제로 메모리가 바닥난 구성 요소를 찾아낸 뒤, 백엔드 서비스를 확장하고 그 구성 요소의 메모리 한도를 올렸다.
   • 프로브를 잠시 느슨하게 해, 백엔드 인스턴스가 ready 와 not ready 를 오가지 않고 바로 트래픽을 받게 했다.
   • 10:00 UTC 에 임시 조치를 되돌렸다.

   후속 조치

   • 빠져 있던 스타트업 프로브를 넣는다. 데이터셋을 다 읽기 전에는 파드를 ready 로 표시하지 않는다.
   • 재시작한 파드가 옛 마스터 IP 주소에 묶여 있을 때 쓸 수 있도록 Redis 용 자체 컨트롤 플레인을 만든다.
   • 서비스 전체의 단일 장애점이 된 이 Redis 클러스터 의존을 줄인다. 중요한 정보 일부를 서버마다 따로 둔 Redis 클러스터 같은 다른 데이터 저장소로 옮기고, 백엔드 일부 구성 요소에 Kafka 를 쓰기 시작한다.

   교훈

   장애를 일으킨 것은 디스크 확장이 아니라 상태를 맞추려고 컨트롤러 객체를 다시 만든 단계였다. 고칠 수 없는 필드가 있으면 객체를 통째로 바꾸는 위험한 방법을 쓰게 된다. 그렇게 바꾸면 쿠버네티스가 워크로드를 넓은 범위에서 다시 조정할 수 있다. 스타트업 프로브와 엄격한 레디니스 프로브가 있어야 롤링 재시작이 현재 파드가 정말 준비될 때까지 기다린다. 이번 장애에서 가장 뼈아픈 것은 프로브가 없었다는 점이다. 분산 클러스터가 다시 붙고 복제를 따라잡는 데는 시간이 걸리므로, 의존하는 서비스는 그동안 기능을 줄여서라도 버티도록 설계해야 한다.

   사례 보기
3. IL-0168 새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.

   Scaleway2024

   증상

   2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 상태가 됐다.

   노드 NotReady컨트롤 플레인 지연OOMKilled

   촉발

   2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   재시도 폭주자동화 증폭단계적 배포 부재

   감지

   타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다.

   조치

   • Kubernetes API 에 배정한 자원을 01:46 과 02:20 두 차례 늘렸다.
   • 02:30 에 API 트래픽을 제한해 들어오는 트래픽을 고르게 만들고 혼잡을 줄였다.
   • 03:20 부터 트래픽 제한을 50-100 개 배치로 나눠 차례로 풀어 노드들이 다시 인증하고 "Ready" 가 되게 했다.
   • 03:40 에 API 혼잡 중에 만들어진 고장 노드를 교체하는 스크립트를 돌렸다.
   • 15:45 부터 노드 인증이 한꺼번에 몰리지 않게 일부 클러스터부터 예전 인증 방식으로 차례로 롤백했고, 2월 19일 모든 클러스터에서 롤백을 마쳤다.
   • 노드 인증이 동시에 몰릴 수 있는 클러스터 업그레이드와 설정 갱신 기능을 2월 20일 10:30 까지 껐다.

   후속 조치

   • Kubernetes API 자원 배정을 늘렸다.
   • 예전 인증 방식으로 롤백했다.
   • 노드에 로컬 인증 캐시를 둔다.
   • 부하가 치솟을 때 더 잘 버티도록 자원 배정 전략을 다시 짠다.
   • 쿠버네티스에 새 요청 큐잉 방식을 넣는다.
   • 높은 부하나 장애가 다른 구성 요소로 번지지 않게 구성 요소를 서로 분리한다.
   • 몇몇 지표를 꼼꼼히 지켜봐 이상 패턴을 더 일찍 찾는다.
   • 이 기간에 노드를 배포했지만 제대로 쓰지 못한 고객에게 환불한다.

   교훈

   고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.

   사례 보기
4. IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.

   Scaleway2024

   증상

   2024-01-24 23:48 CET, FR-PAR 리전에서 Kapsule 과 Kosmos 고객 클러스터의 일부 노드가 NotReady 로 바뀌었다. 같은 시각 API Gateway 로 들어오는 요청이 크게 치솟았다.

   노드 NotReadyOOMKilled간헐적 타임아웃모니터링 중단

   촉발

   FR-PAR 에서 동시에 몰린 배포가 Scaleway Kubernetes API 의 메모리를 바닥냈다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도kubelet

   기여 요인

   단일 장애점재시도 폭주

   감지

   23:48 에 API Gateway 부하가 늘어난 것이 감지됐고, 00:00:10 에 내부 에스컬레이션을 거쳐 당직 엔지니어가 맡았다.

   조치

   • 관리형 Kubernetes 서비스의 메모리 한도와 가비지 컬렉션 임계값을 곧바로 올렸다.
   • 늘어난 부하를 받도록 주요 서비스에 복제본을 추가로 배포했다.
   • 레지스트리 캐시를 비우고, 클러스터가 안정되는 동안 지켜봤다.
   • 장애 뒤에도 계속 모니터링하며 서비스 설정을 조정했다.

   후속 조치

   • 로컬 인증 캐시를 구현한다.
   • 노드 인증 방식을 더 개선한다.
   • 모니터링을 강화하고 레이트 리밋 전략을 조정했으며 장애 대응 절차를 개선했다.

   교훈

   탄탄한 모니터링과 빠른 대응 체계가 중요하다. Kubernetes API 가 노드 인증까지 맡고 있어서 API 의 메모리 부족이 곧장 노드 NotReady 로 번졌다. Scaleway 는 이를 막으려고 로컬 인증 캐시와 노드 인증 개선을 계획했다.

   사례 보기
5. IL-0461 메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다

   Datadog2022

   증상

   2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.

   오류율 상승DNS 조회 실패지연 시간 증가OOMKilled패킷 손실오래된 엔드포인트 라우팅

   촉발

   2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.

   원인

   설정 변경

   구성 요소

   conntrack 테이블Cilium리눅스 커널CoreDNS클라이언트 쪽 DNS 리졸버와 캐시external-dnsHTTP·RPC 클라이언트 라이브러리

   기여 요인

   늦게 드러난 변경재시도 폭주한계 미인지모니터링 사각지대

   감지

   2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.

   조치

   • node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
   • AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
   • SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.

   후속 조치

   • Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.

   교훈

   gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.

   사례 보기

원인별2