사례4건

4건 중 1~4번째

1. 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개까지만 넣을 수 있다.

   사례 보기
2. IL-0049 CoreDNS 파드가 줄어든 뒤 kube-proxy 가 conntrack 항목을 지우지 못해 일부 서비스의 DNS 요청이 없어진 파드로 가면서 5xx 가 쏟아졌다

   Preply2020

   증상

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 당직자를 호출했다. 당직 엔지니어들은 22시 18분부터 VictorOps 호출을 받기 시작했다. Kibana 에서도 5xx 비율이 올라간 것이 보였다.

   DNS 조회 실패오류율 상승오래된 엔드포인트 라우팅

   촉발

   클러스터 안의 부하가 낮아지자 CoreDNS-autoscaler 가 CoreDNS 파드를 3개에서 2개로 줄였다.

   원인

   DNS·네트워크 장애

   구성 요소

   CoreDNSkube-proxyconntrack 테이블

   기여 요인

   자동화 증폭초기 신호 무시캐시 부재

   감지

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 VictorOps 로 당직자를 호출했다. 포스트모템이 적은 감지 시간은 4분이다.

   조치

   • 22시 39분에 당직 엔지니어들이 해당 서비스의 최신 릴리스를 되돌렸다.
   • 정기 배포로 새 노드가 생기자 CoreDNS-autoscaler 가 CoreDNS 파드를 다시 늘렸고, conntrack 테이블이 자동으로 새로 쓰였다.

   후속 조치

   • CoreDNS 의 오토스케일러를 끈다.
   • 운영 환경에 DNS 캐시 서버를 둔다.
   • conntrack 사용량을 모니터링한다.

   교훈

   모니터링은 장애를 빨리 잡았고 대응도 빠르고 체계적이었다. 노드는 어떤 한도에도 닿지 않았다. 진짜 근본 원인은 아직 모른다. conntrack 의 특정 버그로 보인다. 팀이 정한 후속 조치는 모두 장애가 낳는 결과를 막는 것이지 근본 원인을 고치는 것이 아니다. 팀은 DNS 에서 문제가 날 수 있다는 것을 알고 있었지만 이 일을 우선해서 다루지 않았다.

   사례 보기
3. 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 설정이 대안이 된다.

   사례 보기
4. IL-0047 conntrack 경합으로 DNS 조회가 5초씩 늦어져 파드 사이 요청이 간헐적으로 5초, 10초, 15초씩 지연되었다.

   MindTickle2019

   증상

   클러스터 전체 네트워크 장애를 겪은 뒤, 팀은 파드 사이 통신이 간헐적으로 늦어지고 웹 애플리케이션 전체가 이따금 느려지는 것을 알아챘다.

   간헐적 타임아웃지연 시간 증가DNS 조회 실패

   촉발

   libc 리졸버가 A 레코드와 AAAA 레코드 조회를 같은 포트로 보냈고, DNAT 와 SNAT 변환이 일어나는 경로에서 conntrack 경합 조건 때문에 그중 하나가 응답을 받지 못했다.

   원인

   DNS·네트워크 장애

   구성 요소

   conntrack 테이블클라이언트 쪽 DNS 리졸버와 캐시리눅스 커널

   기여 요인

   기본 설정 방치

   감지

   웹 애플리케이션이 간헐적으로 느려지고 파드 사이 요청이 5초의 배수만큼 늦게 도착하는 것을 보고 알았다. 지연이 5초 단위라는 점에서 DNS 조회를 의심했고, tcpdump 로 확인했다.

   조치

   • 파드 스펙의 dnsConfig options 에 single-request-reopen 을 넣어 A 와 AAAA 조회가 서로 다른 포트로 나가게 했다.
   • gRPC 애플리케이션의 Dockerfile 에 GRPC_DNS_RESOLVER=native 를 넣어 ares 대신 libc 리졸버를 쓰게 했다.
   • `tcpdump port 53` 으로 A 와 AAAA 조회가 서로 다른 포트로 나가는 것을 확인했다.

   교훈

   지연이 5초, 10초, 15초처럼 5초의 배수로 나타나면 DNS 조회 재시도를 먼저 의심한다. 리눅스 이미지는 파드 dnsConfig 에 single-request-reopen 을 넣으면 된다. gRPC 는 기본 리졸버가 libc 를 쓰지 않을 수 있으므로 GRPC_DNS_RESOLVER=native 도 함께 설정해야 한다. 설정이 먹었는지는 tcpdump 로 A 와 AAAA 조회가 나가는 포트를 보고 확인한다.

   사례 보기

원인별1