사례35건

35건 중 1~5번째

1. IL-0179 DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.

   MUSINSA2026

   증상

   트래픽이 많은 한 서비스에서 요청이 30초마다 무더기로 실패했다. 당직자가 처음 받은 알림도 이 증상이었다.

   오류율 상승간헐적 타임아웃커넥션 풀 고갈

   촉발

   트래픽이 많은 서비스의 운영 환경에서 DEBUG 레벨 로깅이 켜진 채 트래픽이 몰렸다. 쿼리 한 건마다 로그가 수십 줄씩 나오면서 로그량이 평소의 약 100배로 늘었다.

   원인

   설정 변경

   구성 요소

   애플리케이션 로깅 라이브러리컨테이너 런타임텔레메트리 에이전트애플리케이션 데이터베이스

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   당직자가 처음 받은 알림은 요청이 30초마다 무더기로 실패한다는 내용이었다. 이후 부하테스트의 근본 원인 분석 데이터에서 30초 주기의 커넥션 풀 고갈과, stdout write 에서 멈춘 스레드들이 담긴 스레드 덤프를 확인했다.

   후속 조치

   • AsyncAppender 를 상속해 큐에 넣기 전 요청 스레드에서 trace_id 와 span_id 를 캡처하는 TraceAwareAsyncAppender 를 만들고, neverBlock=true 로 큐가 차면 로그를 버리게 해 비동기 로깅과 trace_id 보존을 함께 유지했다.
   • 지속적인 부하에 대응하도록 출력하는 로그량 자체를 적정 수준으로 관리한다.

   교훈

   AsyncAppender 를 떼어 내면서 trace_id 누락은 막았지만, 요청 스레드를 로그 출력 대기에서 지켜 주던 기능도 함께 사라졌다. 여러 서비스에 한꺼번에 적용하는 표준일수록 해결하려는 문제뿐 아니라 기존에 동작하던 무엇이 바뀌는지도 확인해야 한다. 표준의 결론이 어떤 제약을 전제로 하는지 먼저 봐야 하며, 이번에는 trace 값을 읽는 시점을 바꾸자 그 제약이 풀렸다. 비동기 로깅에서는 ThreadLocal 값이 스레드 경계를 넘지 않는다는 점을 먼저 확인해야 한다. AsyncAppender 로도 지속적인 과부하는 막을 수 없으므로 로그량 자체를 적정하게 관리해야 한다.

   사례 보기
2. IL-0058 Argo CD 에서 여러 앱이 함께 선언한 네임스페이스가 force 동기화로 지워져 앱 약 97개가 Missing/OutOfSync 상태에서 빠져나오지 못했다.

   Argo CD users2026

   증상

   application-controller 를 롤링 재시작한 뒤, 여러 앱이 함께 쓰는 네임스페이스가 Terminating 상태가 됐다. 이 네임스페이스를 쓰는 앱 약 97개가 Missing/OutOfSync 상태에서 빠져나오지 못했다.

   리소스 삭제

   촉발

   여러 앱이 같은 네임스페이스를 매니페스트에 선언했고, 네임스페이스의 app.kubernetes.io/instance 레이블은 그중 다른 앱을 가리켰다. application-controller 를 롤링 재시작한 직후, UI 에서 레이블이 가리키지 않는 앱을 force: true 로 수동 동기화했다. Argo CD 가 kubectl replace --force 로 네임스페이스를 지우고 다시 만들었다.

   원인

   소프트웨어 결함

   구성 요소

   Argo CD

   기여 요인

   파괴적 변경 보호 장치 부재미검증 가정수동 조치 악화

   후속 조치

   • 보고자가 이 이슈를 닫고, 재시작과 상관없는 재현 절차와 함께 force 동기화와 tracking-ID 충돌 문제를 다루는 #29739 를 새로 열었다.

   교훈

   argocd.argoproj.io/sync-options: Prune=false 는 prune 경로만 막고, force replace 로 일어나는 삭제는 막지 않는다. 수동 동기화는 자동 동기화와 달리 OutOfSync 검사를 거치지 않으므로 언제든 실행된다. 여러 앱이 같은 클러스터 범위 리소스를 선언하면 tracking-ID 충돌이 생기고, 소유하지 않은 앱을 force 동기화하면 그 리소스가 지워졌다가 다시 만들어질 수 있다. 처음 세운 재시작과 캐시 가설은 코드를 읽어 보니 맞지 않았다.

   사례 보기
3. IL-0097 cluster autoscaler 버전을 올린 뒤 Kubernetes 1.33 에 남아 있던 클러스터에서 스케일업이 일어나지 않아 새 노드가 만들어지지 않았다

   2i2c2026

   증상

   2026-03-31 15:10 부쿠레슈티 시각에 PagerDuty 알림 "[FIRING:1] At least two servers failed to start in the last 30m cluster=berkeley-geojupyter hub=prod (provider=aws immediate action needed)" 이 울렸다. 이 알림은 서버를 못 띄운 사용자의 신고가 아니라 자동 상태 점검에서 나왔다.

   노드 증설 실패

   촉발

   하루 전에 머지한 업그레이드에서 cluster autoscaler 버전이 올라갔다. berkeley-geojupyter 클러스터는 대다수 클러스터보다 오래된 Kubernetes 1.33 을 쓰고 있었고, 새 autoscaler 버전과 맞지 않았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   클러스터 오토스케일러

   기여 요인

   미뤄 둔 업그레이드미검증 가정

   감지

   15:10 에 자동 상태 점검이 서버 시작 실패를 잡아 PagerDuty 알림 "[FIRING:1] At least two servers failed to start in the last 30m" 을 API 로 띄웠고, 장애 #2057 이 열렸다. 실제 사용자가 서버를 못 띄워 알게 된 것이 아니었다.

   조치

   • 클러스터의 Kubernetes 버전을 1.33 에서 1.34 로 올렸다.
   • cluster autoscaler 를 한 패치 버전 내려 k8s 1.34 용인 9.55.0 으로 맞췄다.

   후속 조치

   • 2i2c-org/infrastructure 저장소의 PR 8008 로 후속 수정을 한다.
   • recurrent-k8s-aws-upgrades.yaml 워크플로가 만드는 정기 업그레이드 이슈를 통해 클러스터마다 다른 Kubernetes 버전을 하나로 맞춘다.

   교훈

   대응자들이 autoscaler 버전을 올린 맥락을 생생히 기억하고 있어서 처음부터 올바른 방향으로 조사했다. 반면 팀이 업그레이드 묶음을 설계할 때 1.32 클러스터만 염두에 둬서 1.33 클러스터가 빠졌다. 이번에 맞춘 autoscaler 9.55.0 은 Kubernetes 1.34 용 버전이었다.

   사례 보기
4. IL-0160 고쳐서 다시 돌린 레거시 GPU 모니터링 스크립트의 펌웨어 조회가 GSP 레이스 컨디션을 일으켜 Linode 의 RTX 4000 Ada GPU 가 잠기고 LKE 워커 노드의 GPU 작업이 멈췄다

   Linode2026

   증상

   2026년 3월 4일 21:00 UTC 무렵부터 NVIDIA RTX 4000 Ada GPU 를 쓰는 Linode 인스턴스가 잠기기 시작했다. 처음에는 Linode Kubernetes Engine 의 워커 노드만 겪는 문제로 보였지만, 나중에 이 하드웨어를 쓰는 모든 Linode 가 영향을 받은 것으로 확인됐다. 일반 컴퓨트 인스턴스와 RTX 4000 이 아닌 GPU 인스턴스는 영향이 없었다.

   GPU 인식 불가컨트롤 플레인 무응답

   촉발

   내부 관측 대시보드에서 빠진 지표를 되살리려고 고장 난 레거시 GPU 모니터링 스크립트를 고쳐 배포했다.

   원인

   배포 결함

   구성 요소

   텔레메트리 에이전트GPU 드라이버

   기여 요인

   리뷰 누락미검증 가정

   감지

   고객은 21:00 UTC 무렵부터 잠김을 겪었고, 상태 페이지 첫 공지는 약 5시간 뒤인 3월 5일 02:07 UTC 에 올라왔다. 처음에는 LKE 워커 노드에서만 생기는 문제로 보였다.

   조치

   • 모든 GPU 에서 문제의 모니터링 스크립트를 껐다.
   • 영향을 받은 노드를 재부팅했다.

   후속 조치

   • 재발을 막을 개선 조치와 예방 조치를 마련한다.

   교훈

   모니터링 스크립트가 자기가 지켜보는 하드웨어를 멈출 수 있다. 빠진 지표 하나를 되살리려던 수정이 이전 세대 GPU 용으로 쓴 펌웨어 조회까지 되살렸다. RTX 4000 Ada 아키텍처에서는 동작 중인 GPU 에 이 조회를 보내면 GPU 가 잠긴다. 스크립트가 모든 GPU 에서 돌았기 때문에 여러 리전에서 이 GPU 를 쓰는 모든 Linode 가 영향을 받았다. 엔지니어들은 처음에 호스트 하이퍼바이저나 GPU 펌웨어의 회귀를 의심했다.

   사례 보기
5. 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 를 쓰기 시작한다.

   교훈

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

   사례 보기

원인별10