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가 실제로..

지난 화요일 새벽 3시쯤이었다. 알람이 울렸다. P99 latency가 400ms를 넘겼다는 알림. 자다 깨서 노트북을 열었을 때 제일 먼저 든 생각은 "또 뭐가 문제냐"였다.우리 EKS 클러스터는 노드 40대 정도 되고, 트래픽이 특별히 튀지도 않았다. Grafana에서 애플리케이션 CPU도 여유롭고, DB 지표도 정상. 근데 왜 느려졌지? 한참 파고 나서야 원인이 나왔다. DNS였다. CoreDNS 파드는 CPU 20%도 안 쓰고 있는데 DNS 응답이 느렸다. 좀 어이가 없었다.처음엔 CoreDNS 스케일업을 의심했다당연히 첫 반응은 "CoreDNS 파드 수 늘려야겠다"였다. 그런데 grafana를 보니 CoreDNS 자체는 문제가 없었다. coredns_dns_request_duration_seco..

지난주 화요일 새벽 3시 12분, 폰이 울렸다. 사내 슬랙 챗봇이 coredns_cache_misses_total 급증을 감지해서 온콜을 깨웠다. 처음엔 흔한 오탐이겠거니 하고 눈을 감으려다가, 대시보드를 열어보니 정말로 뭔가 이상했다. 클러스터 전체 파드에서 DNS 실패 로그가 초당 수천 건씩 쏟아지고 있었다.노드 24대, 파드 2100여 개가 돌고 있는 EKS 1.30 클러스터였다. 평소에도 CoreDNS는 조용한 편이라서 크게 신경 쓰던 컴포넌트는 아니었는데, 이날 이후로 우리 팀의 DNS 관측 표준이 완전히 바뀌었다.처음 본 지표먼저 CoreDNS 메트릭을 봤다. 평소 P99 응답 시간이 3ms 언저리에서 놀던 게 갑자기 800ms까지 튀어 있었다. 그리고 coredns_dns_responses_..

지난주에 진짜 며칠을 날렸다. 결론부터 말하면 범인은 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..

클러스터 트래픽이 늘 때 우리 팀이 가장 먼저 듣는 얘기는 보통 이거다. "노드 부족한 거 아니에요?" 근데 막상 들여다보면 노드는 멀쩡한데 DNS 쪽에서 병목이 생긴 경우가 절반쯤 된다. 특히 EKS에서 default 설정 그대로 굴리고 있으면 CoreDNS는 2개 파드로 묶여서 같은 AZ에 떨어져 있는 일도 흔하다.이 글은 EKS CoreDNS를 운영하면서 트래픽이 늘기 시작했을 때 가장 먼저 점검해야 하는 3가지를 정리한 가이드다. 정말로 노드를 더 붙이기 전에, DNS 레이어부터 들여다보자는 얘기.1. CoreDNS 파드 분산 — topologySpreadConstraints이게 의외로 묻혀 있는 변화인데, EKS의 CoreDNS add-on이 v1.9.3-eksbuild.11 그리고 v1.10...