day-log

지난주 화요일 밤, 스테이징에서 새 서비스를 릴리즈하는 중이었다. ArgoCD 앱 하나 만들고, sync 눌렀고, 커피 한 잔 뜨러 갔다 왔다. 돌아왔더니 sync 상태가 Progressing에서 멈춰 있었다. 40분째. 그때부터 새벽 두 시까지 이걸 풀었다.뭐가 문제였나우리 팀은 요즘 ArgoCD 앱에 argocd.argoproj.io/sync-wave annotation을 적극적으로 쓴다. 이유는 단순하다. Helm chart 하나에 CRD, Namespace, ConfigMap, Deployment, Service, Ingress가 다 들어 있으면 순서가 꼬인다. CRD가 만들어지기 전에 Custom Resource가 apply되면 sync가 실패한다. 그래서 CRD는 wave 0, Namespac..

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

지난 주말 새벽 3시, 알림이 울려서 눈을 떴다. 사내 스테이징 API 게이트웨이가 TLS handshake failure를 뱉고 있었다. 그때만 해도 "그냥 인증서 문제겠지, 아침에 보자" 하고 다시 누웠는데, 아침이 되니 프로덕션까지 같은 증상이 번지고 있었다.결론부터 말하면 cert-manager는 인증서를 잘 발급하고 있었다. Kubernetes Secret도 잘 갱신됐다. 그런데 워크로드가 새 인증서를 안 읽고 있었다. 이 삽질 이야기를 정리해둔다.처음엔 cert-manager를 의심했다먼저 한 게 이거다.kubectl describe certificate api-gateway-tls -n gatewaykubectl get certificaterequest -n gateway --sort-by=..

CI에서 이미지 빌드가 답답할 때가 있다. Dockerfile에 COPY . . 한 줄 아래에 npm ci나 pip install을 넣어놨는데, 소스 하나만 바뀌어도 매번 의존성을 처음부터 다시 받는다. 결국 5분씩 걸리던 빌드가 CI 러너 열댓 대에서 동시에 돌면서 팀 전체 개발 흐름을 갉아먹는다. 이 글은 BuildKit의 --mount=type=cache를 CI 파이프라인에 어떻게 붙이는지, 그리고 ephemeral 러너 환경에서 캐시를 어떻게 살려두는지 정리한 가이드다. 실제로 우리 팀에서 프론트/백엔드 이미지 30여 개에 이걸 굴려보고 정리한 내용이다.왜 layer cache만으로는 부족한가BuildKit 없이도 Docker는 layer cache를 쓴다. RUN npm ci 라인이 바뀌지 않으..

지난주에 관측성 파이프라인이 새벽에 두 번 죽었다. 슬랙 알람이 4시 47분에 왔고, 눈 뜨자마자 노트북 열어서 로그부터 봤다. OTel Collector가 OOM으로 재시작을 반복하고 있었다. 이번 글은 그 삽질을 정리한 회고다. 결론부터 말하면 tail sampling 튜닝을 잘못했고, 트래픽 스파이크와 겹치면서 폭탄이 터졌다.상황우리 팀은 대략 40개 서비스에서 스팬을 뽑아 OpenTelemetry Collector 게이트웨이 → tail sampling 전용 Collector → 백엔드(Tempo)로 흘려보내고 있다. 게이트웨이는 15대, 샘플링 Collector는 6대. 각각 c6i.xlarge. 사고 당일 트래픽은 평소 대비 2.3배쯤 튀었다. 프로모션 이벤트가 있었는데 관측성 팀은 그 스케줄..

Postgres 커넥션 풀러 얘기다. 15년 넘게 PgBouncer가 사실상 표준이었다. 근데 최근 몇 년 사이에 pgcat(Rust), Supavisor(Elixir) 같은 대안이 부쩍 눈에 띈다. 우리 팀에서도 지난 분기에 새 서비스용 풀러를 뭘로 갈지 논의가 있었고, 실제로 각각을 조금씩 다르게 굴려봤다. 이 글은 그 경험을 바탕으로 세 개를 나열해보는 글이다. "이거 써라"는 아니고, 어떤 상황에서 뭐가 맞더라 정도의 정리.세 개가 각자 어떤 물건인가PgBouncer는 여전히 단일 바이너리에 2MB짜리 프로세스로 커넥션 수천 개를 받아낸다. 트랜잭션 모드 풀링, 심플한 config, 문서화 잘 되어 있고, 튜닝 노하우가 인터넷에 널려있다. 단점은 단일 스레드라는 것. CPU 하나를 다 태우면 그게..

지난 3주 동안 팀 인프라 코드를 Terraform 1.5.7에서 OpenTofu 1.10으로 넘겼다. "5분이면 된다"는 블로그 글들에 낚였다. 실제로는 5분이 아니라 3주였고, 그 중 절반은 예상 못 한 곳에서 시간이 갔다.기록해둔다. 언젠가 같은 삽을 뜨는 사람이 이 글을 보길.왜 굳이 지금 옮겼나솔직히 얼마 전까지는 옮길 이유가 별로 없다고 봤다. HCL 문법도 거의 같고 프로바이더도 호환되고, 우리 팀 규모(모듈 40개, workspace 12개)에서 라이선스 이슈가 당장 발등의 불도 아니었다.바뀐 계기는 두 가지였다.첫째, state encryption. OpenTofu 1.10에는 native state encryption이 들어있는데 Terraform은 아직 없다. 우리는 지금까지 S3 b..

올해 2월에 Kyverno 1.17이 나오면서 재밌는 변화가 하나 있었다. ClusterPolicy와 CleanupPolicy가 공식적으로 Deprecated로 마킹된 것. 아직 지워지진 않았지만, Kyverno 팀이 CEL(Common Expression Language) 중심 아키텍처로 방향을 확 틀었다는 신호다. 우리 팀은 지난달부터 조금씩 이 전환을 시작했는데, 처음 시작하는 팀들을 위해 몇 가지 정리해두려고 한다.왜 갑자기 CEL인가간단히 말하면, Kubernetes 자체가 1.30부터 ValidatingAdmissionPolicy(VAP)를 GA로 넣으면서 admission control 계층에 CEL 기반 표현식을 표준으로 밀기 시작했다. Kyverno가 오랫동안 자체 DSL로 정책을 표현해..

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

지난 화요일 밤이었다. 정확히는 수요일 새벽 2시 40분. 폰이 진동했고, 나는 다음날 반차를 쓸까 진지하게 고민 중이었다.Karpenter를 도입한 지 4개월쯤 됐다. 처음에는 얌전하게 consolidationPolicy: WhenEmpty로 돌렸는데, 팀 내부에서 "이럴 거면 왜 Karpenter 썼냐"는 얘기가 슬슬 나왔다. 우리 EKS 클러스터는 노드 30대 규모, 대부분 m6i 계열이었고 야간에는 40% 정도 놀고 있었다. AWS 비용 리뷰에서 매번 얻어맞다 보니 결국 이번 분기에 WhenEmptyOrUnderutilized로 넘어가기로 했다. Karpenter 문서에 최근 이게 코스트 민감한 팀의 기본값이라고까지 적혀 있었으니 뭐 걱정할 게 있겠나 싶었다.그날 새벽에 걸린 알람은 Payment..