사례2건

2건 중 1~2번째

1. 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 를 한 번 개선하면 모든 고객이 그 효과를 본다.

   사례 보기
2. 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 문서를 훑어보기만 하고 구현을 제대로 살피지 않았다. 내부 동작을 알았다면 디버깅 방법과 가설을 더 잘 세웠을 것이다.

   사례 보기

원인별1