사례6건

6건 중 1~5번째

1. IL-0128 1만 개 넘는 GPU 로 학습하는 클러스터에서 네트워크 인터페이스가 몇 초씩 끊겼다 붙는 플래핑이 NCCL 타임아웃을 일으켜 학습이 멈추거나 느려졌다.

   ByteDance2024

   증상

   학습이 멈추거나 학습 속도가 떨어지는 일이 가끔 일어났다. 원인은 네트워크 인터페이스가 자주 끊겼다 다시 붙는 플래핑이었다.

   링크 플래핑NCCL 타임아웃처리량 저하

   촉발

   네트워크 인터페이스가 몇 초 동안 내려갔다가 다시 올라오는 플래핑이 일어났다.

   원인

   DNS·네트워크 장애

   구성 요소

   NCCLNIC·케이블·스위치 포트 링크

   기여 요인

   기본 설정 방치

   감지

   MegaScale 은 초 단위 모니터링으로 링크 플래핑 같은 NIC 문제를 추적한다. 하트비트에 담긴 RDMA 트래픽 지표가 크게 떨어지거나 비정상적으로 흔들리면 드라이버가 사람이 조사하도록 알림을 보내고, 트래픽이 완전히 끊기면 자동으로 장애 복구 절차를 시작한다.

   조치

   • NCCL 의 타임아웃 기준을 기본값보다 큰 값으로 명시적으로 잡았다.
   • 링크 플래핑에서 빨리 회복하도록 NCCL 의 재전송 타이머와 재시도 횟수를 조정했다.
   • NIC 의 adap_retrans 기능을 켰다.
   • 네트워크 카드 신호 세기, AOC 케이블 품질, 스위치 쪽 신호 세기를 하드웨어 수준에서 관리해 플래핑 빈도를 줄였다.

   교훈

   타임아웃 기준은 기본값에 맡기지 말고 명시적으로 크게 잡아야 한다. 기본값으로 두면 NCCL 은 네트워크 카드가 돌아오기 전에 타임아웃을 낸다. 플래핑의 근본 원인은 링크 품질이었다. 네트워크 카드, AOC 케이블, 스위치의 신호 품질을 하드웨어 수준에서 관리하고 나서야 빈도가 줄었다.

   사례 보기
2. IL-0083 멀티 테넌트 쿠버네티스 클러스터에서 노드 로컬 dnsmasq 가 동시 질의 한도에 걸리고 cluster.local 응답을 캐시하지 못한 데다 ndots 검색 도메인 질의가 CoreDNS 로 몰려, 서비스 간 호출이 간헐적인 5xx 를 냈다.

   Adevinta2023

   증상

   어느 금요일 오후, 고객 한 곳이 SCHIP 에서 돌리는 일부 서비스에서 HTTP 5xx 오류가 튄다고 알려 왔다. 팀은 바로 장애를 선언했다.

   오류율 상승DNS 조회 실패지연 시간 증가

   원인

   DNS·네트워크 장애

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시텔레메트리 에이전트

   기여 요인

   기본 설정 방치한계 미인지초기 신호 무시미검증 가정

   감지

   고객이 SCHIP 에서 돌리는 일부 서비스의 HTTP 5xx 가 튄다고 알려 와서 알았다. DNS 와의 관계는 한참 뒤에야 드러났고, 그때 보니 그동안 무시해 온 이 클러스터의 DNS Latency SLI 가 다른 클러스터보다 낮아져 있었다.

   조치

   • dnsmasq 의 노드당 동시 DNS 질의 한도를 150에서 Google 권장값인 1500으로 올렸다.
   • CoreDNS 가 응답에 RA 비트를 항상 넣도록 header 설정에 set ra aa, clear rd 를 넣어 dnsmasq 가 cluster.local 응답을 캐시하게 했다.
   • 노드 로컬 dnsmasq 에서 ndots 때문에 생긴 풀 수 없는 도메인 질의를 가로채 NXDOMAIN 으로 응답하도록 설정해 CoreDNS 로 넘어가지 않게 했다.
   • fluent-bit 가 로그 라우터에 접속할 때 쓰는 호스트 이름을 서비스 이름에서 FQDN 으로 바꿨다.
   • 영향받은 고객에게 앱의 내부 이름 해석을 FQDN 으로 바꾸도록 요청했다.

   교훈

   SLO 를 보기 좋은 지표로만 두지 말고 안전장치로 써야 한다. 이번에는 나빠진 DNS Latency SLI 를 오래 무시한 탓에 원인을 늦게 찾았다. SLO 를 안전장치로 쓰려면 믿을 수 있는 SLI 가 먼저 있어야 한다. 조사가 여러 당직자에게 흩어져 있었고, 관찰 결과와 가설을 한곳에 모으지 않아 같은 가설이나 이미 버린 가설을 다시 붙잡기도 했다. 가설 하나를 버린 뒤에 다음 가설로 넘어가야 한다. 기존 지표에 없는 데이터는 DNStop 처럼 직접 모아야 한다. 멀티 테넌트 환경에서는 DNS 를 한 번 개선하면 모든 고객이 그 효과를 본다.

   사례 보기
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-0056 kops 에서 EKS 로 옮긴 뒤 AWS VPC CNI 의 SNAT 때문에 파드에서 다른 VPC 의 NLB 뒤 서비스로 가는 호출이 간헐적으로 실패했다

   MindTickle2020

   증상

   새해 첫 주말, 운영 클러스터를 kops 에서 EKS 로 옮긴 날 아침에 팀장이 전화로 플랫폼이 매우 느리게 동작한다고 알렸다. 아직 패턴은 보이지 않았고, 너무 불안정해서 계속 운영할 수 없는 상태였다.

   간헐적 연결 실패지연 시간 증가

   촉발

   운영 클러스터를 kops 에서 EKS 로 옮겼고, AWS VPC CNI 가 다른 VPC 에 있는 NLB 로 가는 파드 트래픽의 출발지 주소를 노드에서 변환했다.

   원인

   DNS·네트워크 장애

   구성 요소

   AWS VPC CNI

   기여 요인

   기본 설정 방치미검증 가정

   감지

   EKS 로 옮긴 날 팀이 플랫폼이 매우 느리게 동작하는 것을 보았다. 실패하는 호출의 패턴은 AWS 네트워크 전문가가 요청한 패킷 캡처를 하고 나서야 보였다.

   조치

   • 플랫폼이 너무 불안정해 운영을 이어 갈 수 없었으므로 EKS 이전을 되돌렸다.
   • AWS VPC CNI 에 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 를 설정해 외부 SNAT 을 켰다. 이제 CNI 플러그인은 주소를 변환하지 않고 NAT 게이트웨이가 변환한다.

   후속 조치

   • AWS CNI 에 모니터링과 경보를 설정했다.

   교훈

   장애를 디버깅할 때, 특히 네트워크 문제라면 스택 전체의 구성 요소를 모두 의심해야 한다. EKS 를 원인 후보에서 일찍 뺀 탓에 귀중한 시간을 많이 잃었다. 관측 도구를 작업 흐름에 넣어야 한다. 모든 구성 요소가 서로 핑을 보내는 pinger DaemonSet 으로 이상한 연결 현상을 보고 나서야 해결에 다가갈 수 있었다. 쓰는 시스템을 알아야 한다. 팀은 EKS 로 옮기기 전에 AWS CNI 문서를 훑어보기만 하고 구현을 제대로 살피지 않았다. 내부 동작을 알았다면 디버깅 방법과 가설을 더 잘 세웠을 것이다.

   사례 보기
5. IL-0057 EKS 노드의 SNAT 과정에서 conntrack 경합으로 바깥으로 나가는 TCP 연결이 1초나 3초씩 늦어져, 서비스 간 호출이 많은 서비스의 p99 지연이 늘었다.

   Prezi2019

   증상

   Nginx 기반 리버스 프록시를 쿠버네티스로 옮긴 뒤, Prometheus 가 몇몇 서비스의 p99 지연 증가에 알림을 보냈다. 그래프에서 p99 지연은 7/24 부터 올라가 있었다.

   지연 시간 증가간헐적 타임아웃

   촉발

   리버스 프록시를 전용 ElasticBeanstalk 머신에서 공용 EKS 워커 노드로 옮기자, 프록시가 다른 서비스로 보내는 패킷이 노드에서 iptables 규칙에 따라 SNAT 를 거치게 되었다.

   원인

   DNS·네트워크 장애

   구성 요소

   conntrack 테이블AWS VPC CNI리눅스 커널노드 운영체제 이미지

   기여 요인

   기본 설정 방치미패치 알려진 버그

   감지

   Prometheus 가 몇몇 서비스의 p99 지연 증가에 알림을 보냈다. 예전처럼 평균 응답 시간만 봤다면 꼬리 지연만 오른 이번 문제는 십중팔구 놓쳤을 것이다.

   조치

   • 지연이 생기는 곳을 찾으려고 AWS X-Ray 추적을 붙이고, 추적에 $upstream_connect_time 속성을 더했다.
   • 해당 서비스의 파드를 더 많은 노드에 더 많이 띄웠다. 지연은 줄었지만 사라지지 않았다.
   • AWS VPC CNI 에 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 를 설정해 노드에서 SNAT 를 껐다.

   교훈

   쿠버네티스 같은 복잡한 시스템을 디버깅할 때는 관측 가능성이 핵심이다. 평균 응답 시간 대신 p99 를 보고 있었기에 문제를 알아챘고, 추적을 붙여 느린 요청의 특징을 알게 되자 원인 가까이 갈 수 있었다. 실제 해법을 찾으려면 SNAT 가 어떻게 동작하는지, EKS 내부와 amazon-vpc-cni-k8s 플러그인이 어떤 역할을 하는지까지 이해해야 했다. EKS 에서는 노드 AMI 의 iptables 가 무작위 포트 할당을 지원하지 않을 수 있고, 그때는 외부 SNAT 설정이 대안이 된다.

   사례 보기

원인별1