day-log

CoreDNS NXDOMAIN 캐시가 만든 30초 지옥, ndots:5의 그림자지난주 화요일 새벽 4시쯤, 온콜 알림이 울렸다. checkout-service 의 외부 결제사 API 콜 P99 레이턴시가 갑자기 5초, 10초를 찍고 있었다. 눈이 번쩍 떠졌다. 결제 흐름이라 반쯤 정신이 나간 채로 노트북을 열었다.결론부터 말하면 범인은 CoreDNS의 NXDOMAIN 네거티브 캐시였다. 그런데 이게 그냥 캐시 문제가 아니라, ndots:5랑 얽혀서 아주 재미없게 터졌다. 몇 시간 동안 헤맨 이야기를 정리해둔다.처음엔 결제사 문제인 줄 알았다첫 반응은 당연히 "결제사 쪽에서 뭐 하나" 였다. 상태 페이지 열어봤다. 정상. 결제사 담당자한테 슬랙 DM 날렸다. "저희 쪽 아무 이슈 없는데요."그럼 우리 클러..

ndots:5, 왜 우리 Pod은 DNS 하나 찍는 데 다섯 번을 물어보는가DNS 지연 얘기를 하면 다들 NodeLocal DNSCache부터 붙이라고 한다. 맞는 얘기다. 근데 그 앞에 왜 이런 일이 벌어지는지 원리를 짚고 넘어가는 사람은 의외로 적더라. 우리 팀도 몇 달 전 P99가 튀는 걸 잡으렬고 노드로컬 캐시부터 붙였는데, 그때는 됐지만 나중에 다른 클러스터에 적용할 때 왜 되는지 설명을 못 해서 좀 창피했다.그래서 이 글은 ndots가 뭐고, 왜 하필 5이며, 그 값 하나가 어떻게 매 요청마다 5~6번의 DNS lookup을 유발하는지 밑바닥부터 파본다. 최근 Medium 등에서 "ndots:5 latency tax"라는 표현이 다시 돌기 시작한 것도 이유가 있다.resolv.conf가 실제로..

지난주에 진짜 며칠을 날렸다. 결론부터 말하면 범인은 ndots:5 였는데, 이 얘기 어디선가 다들 한 번씩은 들어봤을 거다. 근데 막상 우리 클러스터에서 실제로 터지니까 원인 찾는 데 이틀이 걸렸다. 이번엔 그 과정에 대한 기록이다.증상: 새벽 3시에 켜진 페이지노드 40대 규모의 EKS 클러스터에서 결제 관련 서비스 P99 레이턴시가 갑자기 튀기 시작했다. 평소엔 60ms 언저리였는데, 어느 순간부터 800ms까지 스파이크가 찍힌다. 새벽 3시에 폰이 울려서 잠이 확 깼다.처음 든 생각은 "또 RDS인가"였다. 요즘 우리 팀에선 뭐만 느려지면 일단 DB부터 의심하는 게 습관이 됐거든. 근데 커넥션 풀도, slow query 로그도, RDS CloudWatch도 다 깔끔했다. 애플리케이션 로그를 뒤져봐..

지난주 화요일 새벽 3시 12분. 폰이 울렸다. 결제 서비스에서 upstream timeout이 폭발하고 있다는 페이지. 잠결에 노트북 열었을 때 나는 진짜 결제 API가 죽은 줄 알았다.처음 본 지표Grafana 대시보드를 열어보니 결제 API 자체는 멀쩡했다. P99 레이턴시가 평소 80ms에서 4초로 튀었을 뿐, 컨테이너는 다 살아있고 로그에도 별다른 에러가 없었다. 근데 트래픽은 확실히 흐르지 못하고 있었다. 뭔가 이상해서 istio access log를 뒤져보니 upstream 접속 자체가 안 되는 케이스가 계속 찍히고 있었다.노드 자체 리소스는 여유로웠다. CPU 40%, 메모리는 60%대. 그런데 왜?정신이 살짝 들어서 kube-system 네임스페이스를 봤다. CoreDNS 파드 로그가 도..

지난주 화요일 새벽 2시 47분, 슬랙 알림이 무더기로 떴다. P99 레이턴시 그래프가 평소 80ms 근처에서 600ms 위로 튕겨 올라가더니, API 5xx 비율이 0.1%에서 4%까지 치솟았다. 결제 트래픽이 한창 몰리는 시간대였다.처음엔 또 어디서 메모리가 새는 건가 싶었다. 근데 컨테이너 메모리는 멀쩡했고, CPU도 평소 수준이었다. 그러다 어떤 마이크로서비스 로그를 까보니 거의 모든 요청에 dial tcp: lookup api.stripe.com on 10.96.0.10:53: i/o timeout 같은 줄이 박혀 있었다. DNS였다.첫 의심: CoreDNS 파드가 죽었나당연한 수순으로 kubectl -n kube-system get pods -l k8s-app=kube-dns 부터 쳐봤다. 다..

처음엔 외부 API를 의심했다새벽 3시 12분. 슬랙 알림이 한 번에 17개 쌓였다. P99 외부 API 호출 latency가 평소 80ms에서 4초까지 튀었다. 처음엔 SaaS 벤더 쪽 장애인가 싶었는데, 우리 쪽 다른 서비스들도 다 같이 느려지고 있었다. 멘탈이 한번 나가고, 노트북을 켰다.결론부터 말하면 CoreDNS NXDOMAIN 폭주였다. 솔직히 DNS 문제는 항상 의심해야 한다는 걸 머리로는 알았는데, 실제로 새벽에 당해보니 또 한 번 새겼다. 우리 팀이 운영하는 EKS 클러스터, 노드 38대, 워크로드 약 400개 정도 되는 규모다.알림 내용은 단순했다. httpClient.get 호출 P99가 폭증 중이라는 거. 외부 결제 SaaS 호출이 대부분이라 벤더 status 페이지부터 봤다. 다..

ndots가 뭐길래지난주 화요일이었다. 외부 API 호출이 많은 워크로드 하나가 P99 레이턴시가 갑자기 700ms를 넘기 시작했다. APM 그래프를 보니 외부 API 자체는 멀쩡한데 우리 쪽 클라이언트에서 응답을 받기 전까지의 시간이 길었다. 처음엔 또 NAT Gateway냐 싶었는데, 그건 아니었다.원인은 결국 DNS였다. 정확히는 ndots:5 였다. 그리고 그걸 ndots:1로 내리는 한 줄짜리 패치를 만들었다가, 다음날 아침에 멘탈이 나갔다.쿠버네티스에서 파드가 뜨면 /etc/resolv.conf에 기본적으로 이런 게 들어간다.search default.svc.cluster.local svc.cluster.local cluster.localnameserver 10.96.0.10options nd..