사례2건

2건 중 1~2번째

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-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 의 조금 더 큰 자원 사용량이 문제가 되지 않았다.

   사례 보기

원인별2