사례3건

3건 중 1~3번째

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-0105 VPC CNI 교체로 ALB 에서 타깃 그룹이 떨어져 나가 쿠버네티스 클러스터의 모든 서비스가 503 을 냈다

   DFDS2021

   증상

   2021-06-22 08:29 UTC 에 알림이 울렸다. 쿠버네티스 클러스터로 들어오는 트래픽이 모두 실패했고, 모든 서비스가 503 을 냈다.

   서비스 중단오류율 상승

   촉발

   EKS 애드온을 kubectl 대신 Terraform 으로 관리하려는 리팩터링과 정리 작업 중에 파이프라인이 VPC CNI 를 교체했다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI클라우드 로드 밸런서Terraform

   기여 요인

   미검증 가정설정 테스트 부재

   감지

   08:29 UTC 에 알림으로 감지했다. 파이프라인이 VPC CNI 를 교체한 지 8분 뒤였다. 08:32 에는 고객도 문제를 알려 왔다.

   조치

   • infrastructure-modules 참조를 되돌리는 수정을 커밋했다.
   • AWS API 타임아웃으로 멈춘 파이프라인을 다시 돌렸다.
   • 파이프라인이 타깃 그룹을 ALB 에 다시 붙였다.

   후속 조치

   • ALB 의 등록 해제 지연을 기본값 300초로 되돌린다.
   • 노드 교체 스크립트가 교체 전에 ALB 등록 해제 지연을 잠시 0 으로 낮추도록 고친다.
   • Ingress 테스트 스위트를 만든다.

   교훈

   팀은 등록 해제 지연을 주로 성능 측면에서만 보고 바꿨다. 중요한 파이프라인 실행은 끝날 때까지 지켜봐야 한다. 알림은 모든 사람이 받고 대응해야 한다. 뜻이 분명하지 않은 알림 문구는 고쳐 써야 한다.

   사례 보기
3. IL-0066 ConfigMap 만 바꾸고 디플로이먼트는 그대로 둔 탓에 잘못된 설정이 몇 주 뒤 노드 교체 때 모든 브리지 파드에 퍼져 Pusher 의 모든 트래픽이 끊겼다

   Pusher2019

   증상

   Pusher 의 모든 제품으로 가는 트래픽이 멈췄다. 고객 트래픽은 ELB 와 nginx 를 지나, 브리지라고 부르는 자체 개발 7계층 프록시를 거쳐 각 제품 서비스로 간다. 그래서 브리지가 망가지면 플랫폼 전체가 내려간다. 발표자는 이때 요청이 모두 500 오류였던 것으로 기억했다.

   서비스 중단오류율 상승

   촉발

   동료가 ConfigMap 의 설정을 바꿔 운영 클러스터에 배포했지만, 그 설정에 의존하는 디플로이먼트는 갱신하지 않았다. 3주에서 4주 뒤 클러스터 업그레이드로 노드를 교체하면서 브리지 파드가 새로 떴다.

   원인

   설정 변경

   구성 요소

   컨피그맵과 시크릿

   기여 요인

   늦게 드러난 변경미검증 가정

   후속 조치

   • 오픈소스 컨트롤러 Wave 를 만들었다. Wave 는 디플로이먼트, 스테이트풀셋, 데몬셋이 참조하는 ConfigMap 과 Secret 의 해시를 파드 템플릿에 넣어, 설정이 바뀌면 곧바로 새 파드가 롤아웃되게 한다.

   교훈

   ConfigMap 을 바꿔도 디플로이먼트는 새 파드를 만들지 않는다. 설정을 실행 중에 다시 읽지 못하는 애플리케이션은 파드가 다시 뜰 때에야 새 설정을 읽으므로, 잘못된 설정이 몇 주 뒤에 드러날 수 있다. 설정을 바꾸면 곧바로 새 파드가 뜨게 해야 설정이 맞는지 그 자리에서 확인할 수 있다.

   사례 보기

원인별1