사례10건

10건 중 1~5번째

1. IL-0104 Istio 의 공격적인 DNS 캐시 갱신과 클라이언트 포트 재사용, kube-proxy 가 종료된 파드의 conntrack 항목을 정리하지 않는 문제, 2분짜리 UDP conntrack 기본 타임아웃이 겹쳐 CoreDNS 파드가 OOMKilled 됐다.

   Cisco ThousandEyes2025

   증상

   2025년 9월 4일, CoreDNS 파드 하나가 OOMKilled 됐다.

   DNS 조회 실패오래된 엔드포인트 라우팅OOMKilled

   촉발

   CoreDNS 파드 하나가 OOMKilled 됐다.

   원인

   소프트웨어 결함

   구성 요소

   CoreDNSkube-proxyconntrack 테이블Istio

   기여 요인

   기본 설정 방치

   교훈

   장애는 Istio, kube-proxy, conntrack 각각의 동작이 겹쳐 생겼다. Istio 는 DNS 캐시를 공격적으로 갱신하며 클라이언트 포트를 다시 썼고, kube-proxy 는 conntrack 항목을 정리하지 않았고, conntrack 의 UDP 기본 타임아웃은 2분이었다. kube-proxy 쪽 문제는 쿠버네티스 v1.32 에서 고쳐졌다. 발표자는 Istio 가 아주 복잡한 일은 단순하게 만들지만 아주 단순한 일은 복잡하게 만든다고 평했다. 발표자는 또 Cilium 을 소개했다. Cilium 은 iptables 체인을 차례로 훑는 대신 맵으로 Service 를 찾고, eBPF 데이터 경로로 kube-proxy 를 완전히 대체할 수 있다.

   사례 보기
2. IL-0170 설날 이벤트 트래픽이 평소의 3배를 넘자 Istio ingressGateway 가 있는 EKS 노드의 nf_conntrack 테이블이 가득 차 패킷이 버려졌고, 웹과 앱 서비스 전체가 멈췄다.

   Backpackr2025

   증상

   2024년 1월 설날 이벤트 중에 개발자 한 명이 Slack 에 장애가 의심된다고 알렸다. 여러 사람이 상황을 확인하는 사이에 웹과 앱 서비스 전체가 멈췄고, 백패커는 이벤트를 중단하기로 했다.

   서비스 중단

   촉발

   2024년 1월 설날 이벤트로 트래픽이 평소보다 3배 넘게 몰렸다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블인그레스 컨트롤러Istio

   기여 요인

   단일 장애점기본 설정 방치모니터링 사각지대

   감지

   개발자 한 명이 Slack 에 장애가 의심된다고 제보했다. 여러 사람이 확인하는 동안 장애가 웹과 앱 서비스 전체로 번졌다.

   조치

   • 서비스 전체가 멈추자 설날 이벤트를 중단했다.

   후속 조치

   • 모든 노드의 nf_conntrack_max 를 올렸다. 일반 노드는 인스턴스 전체 메모리 바이트를 16384 로 나누고 다시 2로 나눈 값, istio 노드는 그 값의 3배를 쓴다. 메모리 16GB 인스턴스라면 net.netfilter.nf_conntrack_max 가 약 50만이 된다. 이 설정은 nodeOptimizer 데몬셋에 넣어 모든 노드에 자동으로 적용했다.
   • VirtualService 의 gateways 에 mesh 를 넣어 사이드카끼리 ingressGateway 를 거치지 않고 직접 통신하게 했다. HTTPS 로 도메인을 호출하면 TLS 오프로딩 때문에 여전히 ingressGateway 나 NLB 를 거쳐야 하므로, 메시 통신은 HTTP 호출에서 쓴다.
   • istio 노드를 12.5Gbps 의 c6.xlarge 에서 최대 25Gbps 대역폭을 내는 n 타입 인스턴스로 바꿨다.
   • 모니터링을 늘렸다. ENA 의 네트워크 대역폭과 패킷 드롭, ingressGateway 와 사이드카 프로세스 상태, CPU 와 메모리 사용률과 포화 상태를 지켜본다.

   교훈

   모든 트래픽이 노드 하나의 ingressGateway 를 거치면 그 노드가 단일 장애점이 된다. nf_conntrack 테이블은 기본 크기로 두면 트래픽이 갑자기 몇 배로 늘 때 가득 차고, 그 순간부터 패킷이 버려진다. 게이트웨이 노드는 일반 노드보다 conntrack 한도와 네트워크 대역폭을 넉넉하게 잡고, 네트워크 대역폭과 패킷 드롭 지표를 따로 지켜봐야 한다.

   사례 보기
3. IL-0178 EKS 에서 HPA 가 파드를 줄일 때 엔드포인트 제거보다 컨테이너 종료가 먼저 끝나 502 가 났고, 블루/그린 전환 뒤에는 conntrack 에 남은 연결이 삭제된 파드로 가서 클라이언트가 타임아웃을 받았다.

   Lotte E-commerce2022

   증상

   롯데온 서비스에서 HPA 가 파드 수를 줄이는 스케일 인 때마다 일정 시간 동안 요청이 오류로 끝났다. 엔드포인트에서 파드 IP 가 빠지기 전에 컨테이너가 먼저 지워지면, 들어오는 트래픽이 여전히 지워진 컨테이너로 가서 502 에러가 났다.

   오류율 상승간헐적 타임아웃오래된 엔드포인트 라우팅

   촉발

   두 가지 작업이 각각 장애를 일으켰다. 하나는 HPA 가 파드를 줄이는 스케일 인이고, 다른 하나는 Service 레이블 셀렉터를 그린 디플로이먼트로 바꾼 뒤 블루 파드를 지우는 블루/그린 배포다.

   원인

   DNS·네트워크 장애

   구성 요소

   수평 파드 오토스케일러파드 종료 처리kube-proxyconntrack 테이블클라우드 로드 밸런서인그레스 컨트롤러

   기여 요인

   기본 설정 방치

   조치

   • 컨테이너 종료를 늦춰 Service 엔드포인트에서 파드가 빠질 때까지 기다리게 했다. 방법은 애플리케이션의 SIGTERM 처리 로직에서 기다리게 하거나 preStop 훅에 sleep 을 넣는 것이다. 무한정 기다리지 않도록 terminationGracePeriodSeconds 도 함께 설정한다.
   • 대상 그룹 한도인 1000개를 넘지 않는 일부 워크로드에서 ingress 로 만드는 ALB 를 instance 모드에서 IP 모드로 바꿨다.

   후속 조치

   • ALB IP 모드를 전체 워크로드에 점진적으로 적용한다.

   교훈

   Kubernetes 에서 엔드포인트 제거와 컨테이너 종료는 동시에 진행되므로, 종료를 늦추지 않으면 스케일 인 때 지워진 컨테이너로 트래픽이 가서 502 가 날 수 있다. preStop 훅으로 기다릴 때는 terminationGracePeriodSeconds 로 최대 대기 시간을 함께 정해야 한다. ALB 를 instance 모드로 쓰면 트래픽이 노드의 iptables 와 conntrack 을 거치므로, 블루/그린 전환 뒤에도 established 연결이 지워진 파드로 갈 수 있다. IP 모드는 이 경로를 없애고 네트워크 홉도 줄이지만, 대상 그룹에 대상을 1000개까지만 넣을 수 있다.

   사례 보기
4. IL-0177 다른 팀의 설정 배포로 공유 L7 HAProxy 가 재로드될 때마다 messaging-hub 의 웹소켓 연결이 한꺼번에 끊겼다.

   LINE Plus2022

   증상

   LINE 의 messaging-hub 는 일본 음식 배달 서비스 Demaecan 의 Merchant 앱과 Driver 앱에 웹소켓으로 메시지를 보낸다. 어느 날 최대 트래픽 시간이 아닌데도 웹소켓 연결 수 그래프가 순간적으로 크게 떨어졌다. 이 현상은 한 번으로 끝나지 않고 불규칙하게 계속 일어났다.

   연결 리셋데이터베이스 과부하간헐적 연결 실패지연 시간 증가

   촉발

   같은 L7 로드밸런서를 공유하는 다른 서비스 담당자가 자기 LB 설정을 배포하면 HAProxy 가 재로드됐다. hard-stop-after 로 정한 30분이 지나 이전 프로세스가 종료되면서 거기 붙어 있던 웹소켓 연결이 모두 끊겼다.

   원인

   설정 변경

   구성 요소

   HAProxy클라우드 로드 밸런서conntrack 테이블인그레스 컨트롤러

   기여 요인

   늦게 드러난 변경과도한 영향 범위재시도 폭주미검증 가정

   감지

   웹소켓 연결 수 그래프에서 최대 트래픽 시간이 아닌데도 연결 수가 순간적으로 뚝 떨어지는 것을 보고 알았다. Nginx 패킷 드롭은 네트워크 모니터링으로 원인을 찾았다.

   조치

   • Merchant 팀이 토큰 발급 API 를 따로 떼어 배포해 토큰 요청이 몰려도 다른 Merchant API 가 지연되지 않게 했다.
   • Nginx 를 늘리고 파드 안티 어피니티와 레이블 셀렉터로 Nginx 파드가 서로 다른 노드에 뜨게 해서 NF_CONNTRACK 테이블 포화로 생기던 패킷 드롭을 없앴다.
   • Ingress Nginx 의 proxy-read-timeout 과 proxy-send-timeout 을 300s 에서 3600s 로, LB timeout 도 3600s 로 올렸지만 웹소켓 드롭은 멈추지 않았다.
   • 공유하던 L7 LB 를 L4 LB 로 바꿔 웹소켓 드롭을 없앴다.

   교훈

   문제의 범위를 미리 단정해 스스로 제한하면 안 된다. 인프라 팀과 네트워크 팀이 문제없다고 답했다는 이유로 직접 다룰 수 있는 영역만 뒤지다가 공유 L7 LB 를 늦게 의심했다. LB 같은 기술 리소스를 다른 서비스와 공유하면 다른 팀의 배포가 내 서비스의 연결을 끊을 수 있다. Nginx 를 늘려 NF_CONNTRACK 부담을 나눌 때는 파드가 서로 다른 노드에 뜨게 해야 하고, 노드 수보다 많이 늘리면 Pending 상태로 남는 파드가 생긴다는 점도 알아야 한다.

   사례 보기
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 전파 시간은 여러 요인에 좌우된다.

   사례 보기

원인별4