day-log

지난주 새벽에 페이지가 울렸다. OTel Collector DaemonSet이 또 OOMKilled. 이번 분기에만 세 번째다. 솔직히 처음 두 번은 "그냥 limit을 올리지" 하고 넘어갔는데, 이번엔 메모리를 2Gi → 4Gi로 올렸는데도 또 죽으니까 멘탈이 살짝 나갔다.근본 원인을 보려고 새벽 3시에 노트북을 열었다. 결론부터 말하면 memory_limiter 설정과 GOMEMLIMIT이 둘 다 잘못 잡혀 있었고, batch processor의 순서까지 어긋나 있었다. 우리 팀은 1년 전에 OTel Collector를 처음 도입했을 때 공식 예제 그대로 복붙해 놓고 그동안 트래픽이 4배가 늘었는데도 손을 안 댔던 거다. 부끄럽다.일단 무슨 일이 일어났던 건가우리 클러스터는 노드 80대 정도 되고 각..

지난주에 우리 팀 dev/staging 클러스터의 ArgoCD를 2.14에서 3.0으로 올렸다. 공식 블로그에서는 "small but mighty"라고 했고, 업그레이드 노트도 "low-risk upgrade"라고 적혀 있길래 점심 먹기 전에 끝낼 수 있을 줄 알았다. 근데 점심을 굶었다. 그리고 저녁도 거의 굶을 뻔했다.운영 클러스터 올리기 전에 dev에서 한 번 더 정리하고 가는 게 좋을 것 같아서, 우리가 어디서 발이 걸렸는지 기록으로 남긴다. 공식 문서가 빠뜨린 건 없는데, 문서가 짧고 담백해서 "어 이게 진짜 우리한테 영향 있나?" 라고 흘려 보기 쉽다. 우리는 흘려 봤고 결과는 위 문단대로다.첫 번째 지뢰: logs RBAC 강제3.0부터 logs RBAC enforcement가 default..

분기 OKR 중에 "Service Mesh 운영 단순화" 항목이 있었다. 우리 팀은 Istio Ambient를 작년 가을부터 운영 중인데, ztunnel 업그레이드 때마다 신경 쓸 게 많고, waypoint를 namespace 단위로 풀 때 라우팅 정책 디버깅이 여전히 만만치 않다. 작년에 Linkerd가 stable 보안 모델로 가는 동안 우리는 "Istio가 ambient만 잘 굴리면 Linkerd보다 가벼울 거다"라고 베팅했었다.그런데 4월에 Linkerd 2.18이 나오면서 동료 한 명이 "이제 GitOps 친화적으로 multicluster가 된다는데, 우리 멀티 리전 셋업이랑 잘 맞을 것 같지 않아?"라고 슬랙에 던졌다. 솔직히 한 번 더 비교해보지 않으면 찝찝할 것 같았다. 그래서 2주 정도 ..

지난주 일요일 새벽 2시쯤 알림이 왔다. 결제 API 쪽에서 prepared statement "S_3" does not exist 에러가 분당 수백 건씩 찍히고 있었다. 그 전날 PgBouncer를 1.25.1로 올린 게 화근이었다. 안 그래도 PG16.11에 PgBouncer 1.25.1 조합에서 prepared statement 관련 버그 리포트가 올라온 게 있었는데, 우리도 그 케이스에 정확히 걸려든 거였다.이번 글은 그날 새벽 내가 뭘 보고 뭘 했고, 최종적으로 어떻게 마무리됐는지에 대한 기록이다. 깔끔한 해결책 같은 건 아직 없다. 워크어라운드로 일단 막아둔 상태.배경: 왜 transaction mode + prepared statement를 켰나작년에 우리 팀은 PgBouncer를 1.21로..

작년쯤만 해도 우리 팀 CI 파이프라인의 절반은 Kaniko로 굴러갔다. EKS 안에서 in-cluster 빌드를 돌리는 게 너무 깔끔했기 때문에. 근데 2025년 6월 3일에 GoogleContainerTools/kaniko 리포가 read-only로 archived 돼 버렸다. 그 다음 주에 사내 보안팀에서 "유지보수 안 되는 OSS는 점진적으로 걷어내자"는 공지가 떴고, 우리도 슬슬 다른 길을 찾기 시작했다.이 글은 그 과정에서 Buildx, Kaniko(Chainguard fork 포함), ko 세 가지를 다 돌려보고 결정한 이야기다. "이게 정답이다" 같은 결론은 없다. 워크로드에 따라 답이 갈렸다.우리가 쓰던 환경먼저 맥락을 좀 깔자. 우리 팀 빌드 워크로드는 대략 60개의 서비스 이미지인데,..

지난 분기에 ML 팀이랑 한바탕했다. 정확히 말하면 싸운 건 아니고, 슬랙 채널에서 매주 같은 문장이 반복됐다. "노드 비어있어요?", "어제 학습 잡 중간에 죽었는데 누가 뺏어갔나요?", "공정하게 좀 합시다."우리 팀에서 운영하는 GPU 노드 풀은 A100 8장씩 박힌 노드 6대. ML 팀이 4개 프로젝트로 나뉘어 있고, 각 프로젝트마다 학습 잡을 그냥 kubectl apply -f job.yaml 식으로 던지고 있었다. 누가 먼저 던지면 임자. 누군가가 8장짜리 잡을 큐잉 없이 던지면 한 노드 통째로 점유, 그 다음 사람은 Pending. 이게 P0 잡이든 실험성 잡이든 구분이 없었다.결국 Kueue를 도입했다. 3개월 지난 지금, 슬랙에서 그 문장들이 사라졌다. 도입 과정에서 삽질도 많았고, 처음..

작년 말에 우리 팀은 사내 서비스용 도메인의 TLS 인증서를 ACM에서 cert-manager로 옮겼다. EKS 클러스터가 늘어나면서 ALB마다 ACM 인증서 attach하고 갱신 알람 처리하는 게 점점 귀찮아진 게 직접적인 이유였고, 비용보다는 운영 부담 쪽이 컸다. 6개월쯤 굴려보니 마이그레이션 직후엔 안 보이던 문제들이 슬슬 보이기 시작해서, 정리해 두면 누군가는 덜 헤맬 것 같아 글로 남긴다.먼저 짚고 가야 할 거 하나. Wildcard 인증서(*.internal.example.com)는 HTTP01 challenge로 못 받는다. DNS01만 된다. 이건 Let's Encrypt 정책이라 우회할 방법이 없다. 그래서 cert-manager + Route53(우리 환경 기준) 조합이 사실상 표준 ..

매달 AWS 청구서를 열어볼 때 가장 짜증나는 항목이 뭘까. 우리 팀은 단연 NAT Gateway였다. EC2랑 RDS는 어느 정도 예상 가능한데, NAT는 매번 "어, 이게 왜 이렇게 나왔지?" 하면서 Cost Explorer를 파게 된다. 특히 EKS 클러스터를 운영하다 보면 이미지 pull, 로그 전송, S3 접근 같은 트래픽이 죄다 NAT를 거치게 되는데, 이 데이터 처리 비용이 의외로 크다.이번 글은 우리 팀에서 NAT Gateway 데이터 처리 비용을 한 달 만에 60% 가까이 줄인 방법을 정리한 거다. 정공법이지만 의외로 안 챙겨 쓰는 팀이 많아서 가이드로 남긴다.왜 NAT Gateway가 비싼가NAT Gateway 요금 구조부터 짚고 가자. 두 가지 축이 있다.시간당 고정비: $0.045/..

지난주 화요일 새벽 2시. 슬랙 알림 한 통에 잠이 깼다. P99 레이턴시가 800ms를 찍었고, 한 가용영역의 한 노드만 CPU가 95%를 치고 있었다. 다른 두 노드는 30%. 분명히 우리는 topologySpreadConstraints 를 걸어뒀는데, 왜 한 쪽으로만 쏠렸을까.결론부터 말하면, matchLabelKeys 를 안 써서 그렇다. 그게 무슨 소리인지 정리해보겠다.우리 환경EKS 1.32, 노드 12대(3 AZ × 4대), Deployment replicas 18. 매니페스트의 spread 설정은 이렇게 생겼었다.topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisf..

오늘 알게 된 건데, 의외로 모르는 분 꽤 많더라. External Secrets Operator(ESO) 쓰면서 ClusterSecretStore를 그냥 kind: ClusterSecretStore만 박아두고 끝내는 경우. 그러면 클러스터 안의 모든 네임스페이스가 그 SecretStore를 참조할 수 있게 된다. 즉, Vault나 AWS Secrets Manager로 가는 인증 경로가 사실상 클러스터 전체에 열려 있는 셈이다.ESO 공식 문서의 보안 베스트 프랙티스에서도 ClusterSecretStore와 ClusterExternalSecret는 cluster-scoped라 특히 조심하라고 강조한다. 근데 막상 helm chart로 깔고 나면 example manifest를 그대로 복붙해서 쓰니까 이 ..