day-log

지난주 화요일 새벽 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...

쿠버네티스 클러스터가 어느 정도 커지면 DNS가 가장 먼저 비명을 지른다. 우리 팀도 노드 80대 규모 EKS에서 CoreDNS QPS가 2만을 넘기면서 P99 레이턴시가 200ms 가까이 튀는 걸 보고 나서야 손을 댔다. NodeLocal DNSCache는 들어봤는데, autopath는 의외로 안 쓰는 팀이 많더라. 이 둘을 같이 써야 진짜 효과가 난다.이 글은 두 컴포넌트를 같이 도입하는 가이드다. 각각의 역할, 설정 순서, 그리고 같이 쓸 때 주의할 점까지 정리했다.ndots:5가 만드는 N+1 쿼리 문제쿠버네티스 파드에 들어가서 cat /etc/resolv.conf를 찍어보면 이런 게 나온다.search default.svc.cluster.local svc.cluster.local cluster...

지난주 화요일 새벽 2시 17분에 페이저가 울렸다. 결제 API의 P99 레이턴시가 1.2초를 찍고 있었다. 보통 80ms대로 노는 애가 갑자기 15배가 됐는데, 이게 가끔 한 번씩 튀고 끝나는 게 아니라 5분 동안 꾸준히 그 모양이었다. 멘탈이 살짝 나갔다. 결제는 트래픽 자체는 크지 않은데 도미노가 한번 시작되면 SLO 까먹는 속도가 가차 없는 구간이라.결론부터 적자면, 그날 밤 범인은 애플리케이션도, DB도, 네트워크 장비도 아니었다. CoreDNS와 conntrack이었다. 며칠 뒤 NodeLocal DNSCache를 깐 후로는 같은 증상이 안 났는데, 이 일을 글로 정리해두고 싶었다. 비슷한 패턴은 의외로 흔한 것 같아서.처음에 의심한 것들알람 받자마자 떠오른 후보는 셋이었다. 결제 DB의 락,..