day-log

크로스존 트래픽 비용 청구서를 보고 눈을 의심한 적이 있다. AZ 세 개에 노드가 흩어져 있는 EKS 클러스터에서, 결제 API가 유저 서비스를 호출하는데 세 번에 한 번은 다른 AZ로 넘어간다. NAT는 아니지만 AZ 간 트래픽은 GB당 $0.01. 요청 하나로는 티끌인데 P99 QPS로 곱해보면 월 결제서에 꽤 나온다.Kubernetes 1.34에서 Service의 spec.trafficDistribution에 PreferSameNode가 GA로 붙었다. 원래 있던 PreferClose(구 PreferSameZone)에 이어서 나온건데, 같은 노드에 엔드포인트가 있으면 무조건 거기로 보낸다. 없을 때만 외부로 나간다. 아주 간단한데 효과가 크다.어떻게 쓰나apiVersion: v1kind: Servi..

Loki 라벨 하나로 인제스터가 죽었다지난주 금요일 오후, Slack 알람이 미친 듯이 울렸다. loki-ingester가 OOMKilled로 재시작 루프에 빠진 것이다. 그날 배포한 건 아무것도 없었다. 근데 왜 갑자기?결론부터 말하면 개발팀 한 곳이 애플리케이션 로그에 trace_id를 라벨로 추가했다. 그거 하나 때문에 클러스터가 죽을 뻔했다. 이 삽질을 공유한다.처음엔 그냥 트래픽 스파이크인 줄 알았다인제스터 3대 중 2대가 메모리 12Gi 리밋을 찍고 OOMKilled. 남은 1대에 부하가 몰리면서 그것도 죽고. 클래식한 캐스케이딩 실패였다.처음엔 그냥 로그가 늘어난 줄 알았다. 배포 이력을 봐도 로키 관련 변경은 2주 전이 마지막이었고, 그라파나 대시보드에서 로그 인입량(loki_distrib..

EKS 쓰다 보면 언젠가 한 번은 부딪히는 질문. 파드가 AWS 리소스에 접근할 때 IAM을 어떻게 붙일 것인가. 예전에는 답이 하나였다. IRSA. 근데 몇 년 전 Pod Identity가 나오고, 올해 초 우리 팀은 결국 이걸로 옮겼다. 왜 옮겼는지, 뭐가 좋고 뭐가 애매한지 정리해본다.IRSA는 그동안 잘 써왔는데솔직히 IRSA에 큰 불만은 없었다. OIDC provider 만들어놓고, ServiceAccount에 어노테이션 붙이고, IAM 역할의 trust policy에 그 SA를 넣어주면 끝. 몇 년째 잘 굴러왔다.문제는 클러스터가 늘어나면서 시작됐다. 우리 팀은 dev/staging/prod로 클러스터가 세 개, 여기에 데이터 팀이 요청한 별도 클러스터 하나가 더 붙어서 총 네 개다. 각 클러..

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

지난주에 팀에서 PG16 → PG17 업그레이드 검증하다가 알게 된 건데, 이거 모르는 분 꽤 많더라. 짧게 하나만 짚고 넘어간다.핵심: 1GB 상한이 사라졌다PG16까지는 autovacuum_work_mem(또는 fallback으로 maintenance_work_mem)이 아무리 커도 실질적으로 1GB 제한이 있었다. dead tuple ID를 저장하는 자료구조가 단순 배열이었고, TIDStore가 아니라 6바이트짜리 ItemPointerData 배열이라 메모리 크기와 상관없이 내부적으로 1GB(정확히는 MaxAllocSize)까지만 쓸 수 있었기 때문이다.이게 뭐가 문제였냐면, 큰 테이블에서 dead tuple이 1GB 배열에 다 안 들어가는 순간 인덱스 vacuum 페이즈가 여러 번 반복된다. 인덱..

며칠 전에 팀 신입한테 SLO 세팅을 맡겼는데, 결과물이 좀 아쉬웠다. Availability SLO 99.9% 걸어놓고 burn rate 알람을 하나만 만들어놨더라. 1시간 윈도우에 14.4x 넘으면 알람. 이거 흔한 실수라서 짧게 정리해둔다.왜 하나면 부족한가burn rate 알람 하나만 두면 두 가지 중 하나 문제가 무조건 생긴다.윈도우를 짧게 잡으면 (예: 5분/1시간) — 트래픽 스파이크 한 번에 알람을 뜬다. 새벽에 CDN이 잠깐 흔들려서 5분간 에러율 튀었다? 알람 온다. 근데 실제로는 15분 후에 자동 복구됐다. 오탐이다. 이런 게 반복되면 팀이 알람을 무시하기 시작한다.윈도우를 길게 잡으면 (예: 6시간/3일) — 진짜 큰 장애가 났는데 알람이 늦게 온다. 30분간 API가 완전히 죽어 ..

Trivy vs Grype, 컨테이너 스캐너 뭘 쓸까CI 파이프라인에 컨테이너 이미지 스캐너를 하나 박아 넣어야 하는 상황이 최근에 또 왔다. 사내에서 새 서비스 하나 띄우는데 보안팀에서 "이미지 CVE 스캔 결과 붙여주세요"라는 요구를 걸었다. 예전에는 그냥 Trivy 박고 끝이었는데, 이번엔 좀 다르게 접근해봤다.솔직히 말하면 요즘 Grype가 꽤 좋아졌다. 최근 몇 달 사이 EPSS 통합, KEV 카탈로그 반영, 컴포지트 리스크 스코어 같은 게 붙으면서 "이거 진짜 실무에 쓸만한데?" 싶은 느낌이 확실히 있다. 그래서 이번 기회에 두 스캐너를 나란히 놓고 우리 파이프라인에 뭘 넣을지 다시 판단했다.두 도구의 성격이 다르다같은 카테고리로 묶어서 비교하기엔 사실 두 도구가 지향점이 좀 다르다.Trivy..

Terraform 1.11에서 S3 backend에 use_lockfile = true 옵션이 GA로 들어온 뒤로, 팀에서도 슬슬 DynamoDB lock table을 걷어내자는 얘기가 나왔다. 이유는 단순했다. DynamoDB 테이블 하나 유지하려고 IAM 정책 관리, provisioned capacity 알람, TTL 스크립트까지 붙어 있는 게 웃긴 상황이었다. state 파일 하나 지키자고 별도 서비스를 하나 더 굴리는 셈이니까.그런데 "S3 하나로 lock까지 다 처리한다"는 말이 처음엔 어색했다. S3는 오래도록 eventual consistency로 유명했던 스토리지고, DynamoDB의 conditional write처럼 원자적인 락을 걸 수 있는 프리미티브가 없다고 알고 있었기 때문이다. ..

Karpenter를 도입하고 Spot으로 전환하면 비용은 30~70% 아낀다. 근데 이걸 유지하는 게 진짜 문제다. 우리 팀에서도 초반에 몇 번 겪었다. 어느 날 갑자기 특정 Availability Zone에서 c6i.4xlarge만 골라서 반복적으로 회수(termination) 되는데, 노드가 뜨자마자 5분도 안 돼서 다시 죽는 상황이 이어졌다.원인은 결국 하나였다. NodePool 정의가 너무 좁게 잡혀 있었다. Karpenter가 아무리 똑똑해도 선택할 수 있는 Spot capacity pool 자체가 몇 개 없으면 대체할 수단이 없다. 최근 AWS 문서에서도 Spot-to-Spot consolidation을 사용하려면 최소 15개 이상의 인스턴스 타입을 허용해야 한다고 명시하고 있는데, 이게 그냥..

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