사례6건

6건 중 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-0071 작은 파일이 4만 개 넘게 든 단일 스테이지 이미지의 containerd 스냅샷이 쌓여 워커 노드의 inode 가 디스크보다 빠르게 소진되고 있었다

   Onkar Raghunath Shelke2026

   증상

   워커 노드 한 대에서 NodeFilesystemFilesFillingUp 알림이 울려 담당자가 호출됐다. inode 가 바닥날 추세라는 알림이었다.

   노드 디스크 가득 참

   촉발

   단일 스테이지로 빌드한 이미지에 소스, 빌드 결과물, 개발 의존성까지 포함한 node_modules 전체가 들어갔고, 새 레이어 다이제스트가 생길 때마다 노드에 새 스냅샷이 풀렸다.

   원인

   용량 한계

   구성 요소

   노드 루트 디스크kubelet컨테이너 런타임

   기여 요인

   기본 설정 방치모니터링 사각지대한계 미인지

   감지

   node_exporter mixin 에 들어 있는 NodeFilesystemFilesFillingUp 알림이 inode 사용률 67% 에서 울렸다. predict_linear 로 inode 가 바닥날 시점을 예측하는 추세 알림이다.

   후속 조치

   • 멀티 스테이지 Dockerfile 로 바꿔, 한 스테이지에서 의존성을 설치하고 빌드한 뒤 최종 이미지에는 nginx:alpine 위에 컴파일된 결과물만 넣는다.
   • 추세 알림과 별도로 루트 파일 시스템의 inode 사용률이 0.80 을 넘으면 울리는 고정 기준 알림을 for: 30m 으로 둔다.
   • 노드마다 inode 사용률에서 디스크 사용률을 뺀 값을 큰 순서로 보여 주는 Prometheus 쿼리를 대시보드에 둔다.
   • 노드에 이미 쌓인 오래된 스냅샷은 crictl rmi --prune 으로 어떤 컨테이너도 쓰지 않는 이미지를 지워 정리한다.

   교훈

   kubelet 의 백그라운드 정리는 바이트를 기준으로 돈다. 용량보다 파일 수가 먼저 차는 워크로드에는 미리 손쓸 장치가 없다. kubelet 은 inode 가 5% 남았을 때 파드 축출로 처음 개입한다. 파드 축출은 노드를 지키는 마지막 수단일 뿐 해결책이 아니다. ext4 의 inode 수는 포맷할 때 정해진다. 작은 파일이 많으면 디스크가 넉넉해도 inode 가 먼저 바닥난다. 추세 알림은 증가가 잠시 멈추면 조용해진다. kubelet 의 95% eviction 지점보다 한참 앞에서 울리는 고정 기준 알림을 함께 둔다. node_modules 뿐 아니라 Python virtualenv, 벤더링한 PHP 패키지, Ruby gem 처럼 작은 파일이 많은 의존성 트리를 담은 이미지는 모두 같은 문제를 일으킨다.

   사례 보기
3. IL-0087 RKE2 클러스터 노드를 재부팅한 뒤 Multus 가 쿠버네티스 API 에 닿지 못해 파드가 IP 를 받지 못했고, 같은 장애가 모든 노드로 번져 전체 서비스가 멈췄다.

   Fyra Labs2023

   증상

   ICT 기준 2023-04-09 새벽 2시쯤 클러스터 노드 하나가 평소와 다른 CPU 사용을 보였다. 팀은 containerd 와 runc 의 상위 프로젝트에 있는 CRI 버그로 추정했다. 이 노드가 다른 서비스를 모두 스로틀링해 서비스가 실패하고 있었다.

   노드 CPU 고부하서비스 중단

   촉발

   평소와 다른 CPU 사용을 보인 노드를 바로잡으려고, 시스템을 쓰는 사람이 없는 시간이라고 보고 클러스터를 정비 상태로 내린 뒤 영향받은 노드를 전부 재부팅했다.

   원인

   unknown

   구성 요소

   Multus 메타 CNICalico컨테이너 런타임

   기여 요인

   수동 조치 악화미검증 가정

   감지

   새벽 2시쯤 노드 하나의 평소와 다른 CPU 사용을 발견했다. 재부팅 뒤 2시 30분쯤 일부 서비스에서 이상한 문제가 보여 네트워크 장애를 알아챘고, 6시 31분에는 개발자들이 Terra 저장소가 내려갔다고 알려 왔다.

   조치

   • Multus 와 Calico 를 완전히 지우고 Cilium CNI 로 바꿨다.
   • 14:30 ICT 까지 CNI 를 뺀 클러스터 설정 대부분을 되돌려 모든 서비스를 다시 올렸다.

   교훈

   팀은 처음 장애를 저절로 풀릴 일시적인 문제로 보고 다른 노드까지 재부팅했는데, 이 판단은 완전히 틀렸고 장애가 모든 노드로 번졌다. 바꿔 넣은 Cilium 은 이 클러스터에서 Calico 보다도 잘 동작했다. 팀은 한 블로그 글의 자원 사용량 비교를 보고 Cilium 을 피했었지만, 실제로는 Calico, Canal, Flannel 과 마찬가지로 노드당 1코어라는 허용 범위 안에서 돌았다. 작은 클러스터에서는 Cilium 의 조금 더 큰 자원 사용량이 문제가 되지 않았다.

   사례 보기
4. IL-0109 로그 수집을 고치려던 EKS 노드 롤오버가 꼬이면서 Auto Scaling 그룹이 정상 워커 노드를 모두 종료해 클러스터에 노드가 하나도 남지 않았다.

   DFDS2023sev1

   증상

   2023-02-14 09:33 UTC, 최종 사용자들이 CloudWatch 로그가 제대로 들어오지 않는다고 알려 왔다. 팀은 fluentd 를 조사하다가 컨테이너 런타임이 docker-shim 이 아니라 containerd 로 바뀌어 있다는 것을 찾았다. 전날 07:30 UTC 의 정기 노드 롤오버 때 containerd 가 실수로 기본 런타임으로 설정돼 있었다.

   서비스 중단리소스 삭제모니터링 중단

   촉발

   쿠버네티스 로그가 CloudWatch 로 가지 않는 문제를 고치려고 예정에 없던 노드 롤오버를 시작했다.

   원인

   설정 변경

   구성 요소

   컨테이너 런타임노드 런치 템플릿노드 풀Terraform텔레메트리 에이전트

   기여 요인

   자동화 증폭기본 설정 방치스테이징 불일치설정 테스트 부재런북 부재수동 조치 악화

   감지

   로그 문제는 최종 사용자들이 CloudWatch 로그가 이상하다고 알려 오면서 드러났다. 노드가 사라진 장애는 사후 분석 기준으로 2분 만에 감지됐다.

   조치

   • 10:49 UTC 에 노드 롤오버 스크립트로 새 노드를 추가하려 했지만 Docker Hub 타임아웃으로 실패했다.
   • 10:52 UTC 에 노드 롤오버 스크립트를 다시 돌려 새 노드를 추가했고, 11:01 UTC 에 로드밸런서가 새 노드를 정상으로 판단해 트래픽을 다시 보냈다.

   후속 조치

   • 롤오버 절차를 문서로 남기고, 특히 롤오버가 잘못됐을 때 할 수 있는 일을 적는다.
   • 롤오버 절차를 개선할 방법을 찾는다.
   • QA 시험에 fluentd 로그 수집을 넣어 로그가 처음부터 끝까지 전달되는지 확인한다.
   • fluentd 가 보내는 로그 데이터가 부족하거나 없을 때 울리는 경보를 추가한다.
   • 스테이징 환경을 만든다.
   • 잘못된 컨테이너 런타임을 고르지 못하게 막는 장치를 넣었다.

   교훈

   상황이 심각해져도 침착해야 한다. 서둘러 고치다 피해를 키우기보다 알려진 정상 설정으로 롤백하는 편이 낫다. 새 워커 노드를 띄우는 일은 cloudinit 스크립트의 어느 단계도 실패하지 않는다는 전제에 크게 기대고 있다.

   사례 보기
5. IL-0073 Kafka 연결이 끊기자 로깅 사이드카가 Docker 데몬에 부하를 주어 노드가 줄줄이 비정상이 되었고, 재스케줄링으로 생긴 노드 약 41,000개가 Consul gossip 메시를 오염시켜 Vault 와 배포 엔진까지 멈췄다

   Target2019sev1

   증상

   어느 저녁 데이터센터 OpenStack 의 네트워크 하위 시스템을 업그레이드한 뒤 Kafka 연결이 몇 시간 동안 간헐적으로 끊겼다. 개발 환경 워크로드 약 2,000개를 올린 큰 쿠버네티스 클러스터에서 노드들이 쿠버네티스에 비정상이라고 보고하기 시작했다.

   노드 NotReady부하 불균형지연 시간 증가자격 증명 획득 실패

   촉발

   OpenStack 의 네트워크 하위 시스템을 업그레이드하다가 예상과 달리 네트워크가 몇 시간 동안 끊겼고, Kafka 에는 간헐적으로만 닿았다. 그러자 모든 워크로드에 딸린 로깅 사이드카가 한꺼번에 깨어나 노드의 Docker 데몬에 높은 부하를 주었다.

   원인

   의존성 장애

   구성 요소

   컨테이너 런타임서비스 디스커버리텔레메트리 에이전트파드용 자격 증명 중개자

   기여 요인

   과도한 영향 범위자동화 증폭단일 장애점미패치 알려진 버그

   조치

   • Consul 의 gossip 암호화를 켜서 오염된 gossip 메시에서 오는 메시지를 바로 거부하게 했고, 이것으로 Consul 과 Vault 를 되살렸다.
   • 배포 엔진을 안정시킨 뒤 암호화 설정을 반영하려고 개발 환경 전체를 다시 배포했고, 암호화가 설정되지 않은 인스턴스는 종료했다.
   • 큰 클러스터를 다루는 수정이 들어간 Consul 1.2.3 으로 제자리 업그레이드했고, UI 버그 때문에 최종적으로 1.3.0 으로 올렸다. 운영 환경의 오염된 gossip 메시도 이 업그레이드로 빠르게 정리됐다.

   후속 조치

   • 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이므로, 데몬 하나의 장애가 미치는 범위를 줄이는 데 더 힘쓴다. 작은 클러스터를 여러 개 두는 방침과 같은 방향이다.

   교훈

   글쓴이는 작은 클러스터를 여러 개 두라는 자신의 원칙이 옳았다고 확인했다. 더 작은 개발 클러스터와 운영 클러스터의 워크로드는 큰 클러스터처럼 영향을 받지 않았고, 개발과 운영이 한 클러스터에 있었다면 훨씬 큰 일이 났을 것이다. 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이다. 워크로드마다 자기 로깅 사이드카와 메트릭 사이드카를 두는 방식이 옳다고도 확신하게 됐다. 이것들이 클러스터 공용 자원이었다면 문제가 거의 틀림없이 더 커졌고 고치기도 훨씬 어려웠을 것이다.

   사례 보기

원인별4