day-log

멀티클러스터 네트워킹 붙일 일이 생겼다. 처음엔 별 생각 없었는데, 막상 후보를 놓고 보니 결정이 애매했다. Cilium ClusterMesh랑 Submariner. 둘 다 CNCF 프로젝트고, 둘 다 "서비스가 클러스터 경계를 넘어서 통신하게 해준다"는 결과물은 비슷하다.근데 실제로 붙여보면 완전 다른 물건이다. 우리 팀은 결국 ClusterMesh로 갔지만, 그게 정답이라고는 못 하겠다. 상황에 따라 다르다.왜 이 결정을 해야 했나우리 쪽은 EKS 두 개 리전에 걸쳐 있다. 서울 + 도쿄. 원래는 리전간 통신이 필요 없었는데, 이번에 특정 서비스(주문/결제 쪽)를 DR 목적으로 양쪽에 띄우기로 하면서 상황이 바뀌었다.요구사항이 이랬다:서비스가 다른 리전 클러스터의 파드도 endpoint로 인식해야 함..

Istio Ambient mode가 1.24에서 GA 된 게 벌써 1년 반 전이다. 우리 팀도 사이드카 지옥에서 벗어나려고 작년 말부터 조금씩 옮겨왔는데, 처음에는 그냥 "사이드카가 사라진 서비스 메시" 정도로 이해하고 시작했다. 그러다 프로덕션에서 이상한 이슈 몇 개 만나면서 결국 ztunnel 내부를 뜯어보게 됐다. 이 글은 그 과정에서 정리한 내용이다.한 가지 미리 얘기하자면, 이 글은 "Ambient가 좋다/나쁘다" 얘기는 아니다. 내부 동작이 어떻게 되어 있는지, 그리고 왜 그렇게 설계됐는지에 대한 노트에 가깝다.ztunnel은 왜 노드마다 하나만 뜨는가Ambient mode의 첫 번째 특징은 데이터 플레인이 두 층으로 쪼개져 있다는 것이다. L4(TCP, mTLS)는 ztunnel이, L7(H..

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

Ingress-NGINX를 4년 넘게 써왔다. 그동안 별문제 없이 잘 굴러갔는데, 올해 초부터 팀 내부에서 Gateway API로 넘어가야 하는 것 아니냐는 이야기가 계속 나왔다. 근거는 나쁘지 않았다. Gateway API v1.5가 2026년 2월에 나오면서 상당수 기능이 Stable로 승격됐고, 6월에 v1.6까지 이어졌다. Ingress에 없던 표준 트래픽 분할, 리트라이 버짓, BackendTLSPolicy 같은 것들이 실제로 필요했다.두 달 넘게 검토했고, 결론은 "전면 이관은 아니고, 신규 서비스부터 단계적으로"였다. 그 결정에 이르기까지 뭘 봤는지 정리해둔다.뭐가 다른가가장 큰 차이는 리소스 모델이다. Ingress는 하나의 오브젝트가 라우팅과 컨트롤러 설정을 다 짊어진다. 그래서 어노테이..

3월 24일에 ingress-nginx가 공식적으로 EOL 됐다. 이제는 CVE 패치도 안 나온다. 우리 팀도 절반이 아직 ingress-nginx를 쓰고 있어서 지난 두 달 동안 대체제 검토를 이어왔다. Envoy Gateway, Cilium Gateway, Traefik, kgateway. 이 네 개를 실제로 클러스터에 붙여봤고, 그 중 하나로 결정을 내렸다. 결정 자체보다는 각각 뭐가 다른지, 어디서 삽질했는지를 정리해보려 한다.전제 조건부터 짚자. 우리는 EKS 위에서 돌아가고, 노드는 대략 90대. 트래픽은 RPS 8k 정도이고 대부분 gRPC와 HTTP/2. 사내 서비스 60여개가 하나의 Ingress 컨트롤러 뒤에 붙어있는 형태다. 만약 여러분 환경이 GKE 매니지드 게이트웨이를 그냥 켜면 ..

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

DR 훈련 하다가 죽을 뻔한 이야기. 지난달에 우리 팀은 서울 리전 → 도쿄 리전 Kafka 클러스터 사이 MirrorMaker 2(MM2) 페일오버를 실제로 눌러봤다. 스테이징에서 몇 번 성공했고, 문서에도 "consumer group offset은 자동 translation 된다"라고 되어 있으니까 마음이 편했다.결론부터 말하면, 우리는 특정 컨슈머 그룹에서 메시지 4만 건을 재처리했다. idempotent하게 짜놓은 게 그나마 다행이었지, 안 그랬으면 리포트 팀이 한 달치 데이터를 다시 만들었어야 했다. 그리고 그 원인이 대부분 "offset translation을 너무 믿었다"에서 시작한다.액티브-패시브인데 왜 lag가 음수로 뜨죠우리 구성은 이렇다. 서울(source) → 도쿄(target) 단..

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

멀티 클러스터 20개를 한꺼번에 sync 걸어놓고 잠들었던 적이 있다. 다음 날 아침 슬랙이 폭발해 있었다. 카나리 배포한다고 flag까지 걸어뒀는데도 20개 클러스터가 동시에 다 뒤집혀버린 상황. 그때 알았다. ApplicationSet 자체는 "언제 sync할지"에 대해 아무 개념이 없다는 걸.ArgoCD 2.9에서 Progressive Sync가 stable로 승격된 지도 꽤 됐고, 2026년 들어서는 pause/resume 애노테이션 같은 기능도 얹혀서 실전 쓸만해졌다. 그런데 이게 정확히 뭘 하는 놈인지, RollingSync strategy가 내부적으로 어떤 순서로 Application을 다루는지 이해 못한 채 쓰는 사람이 꽤 있는 것 같아서 정리해본다. 사실 나도 최근에 다시 파봐서야 명확해..

Istio ambient mode가 1.24에서 GA된 지 반년 좀 넘었다. 우리 팀은 sidecar 기반으로 운영해온 클러스터가 3개 있고, 신규로 붙일 클러스터가 하나 더 생기면서 자연스럽게 "이번엔 ambient로 갈까?"라는 논의가 시작됐다. 결론부터 말하면 신규 클러스터는 ambient, 기존 3개는 당분간 sidecar 유지다. 왜 그런 판단을 했는지 정리한다.솔직히 처음엔 나도 "ztunnel이 좀 무섭다"는 인상이 있었다. 노드 단위로 프록시가 돌고, 특정 노드가 죽으면 그 노드에 있는 모든 워크로드의 mTLS가 흔들리는 거 아닌가 하는 걱정. 근데 몇 주 파보면서 그건 좀 오해였다.리소스 관점: 이건 진짜 크다sidecar 방식 클러스터에서 Envoy가 잡아먹는 리소스가 얼마나 되는지 실..