day-log

Kafka 4.0이 나오면서 ZooKeeper 지원이 완전히 잘려나갔다. 더 정확히는, 3.9가 ZK를 지원하는 마지막 버전이고 4.0부터는 KRaft 전용이다. 우리 팀도 3.7에서 한동안 버티고 있었는데, 보안 패치 백포팅이 점점 줄어드는 게 보여서 결국 마이그레이션 일정을 잡았다. 클러스터 8대(브로커 24개, ZK 5노드 앙상블)를 다운타임 없이 옮겨야 하는 상황이라, 정리 차원에서 절차를 적어둔다.왜 3.9를 거쳐야 하는가4.0으로 직행이 안 된다. 공식 가이드에서도 명시적으로 "3.x에서 KRaft로 먼저 옮긴 다음 4.0으로 올려라"라고 못 박는다. 그 이유는 마이그레이션 도구 자체가 3.x 브로커 안에 들어있기 때문이다. 3.4에서 처음 등장했고, 3.7부터 production-ready,..

지난주 화요일 오후, 모니터링 알람이 울렸다. PgBouncer 앞단의 connection 사용량이 평소 대비 3배 가까이 튀어 있었고, 어플리케이션 쪽 P99 레이턴시는 슬슬 200ms를 넘기고 있었다. 트래픽은 평소 수준. 이상한 점은 RDS Postgres의 active connection 수가 거의 변동이 없다는 거였다. 즉, 클라이언트 → PgBouncer 사이에서 뭔가 막혀 있다는 뜻이다.이번 글은 그날 밤 새벽 2시까지 잡고 있던 이 문제를 어떻게 추적했는지, 그리고 결국 prepared statement와 transaction pooling이 충돌하던 지점을 어떻게 풀어냈는지에 대한 기록이다. 결론부터 말하면, 우리가 두 달 전에 한 PgBouncer 버전 업그레이드가 진짜 원인이었다.처음..

오늘 알게 된 거 아니고, 사실 꽤 됐는데 의외로 모르는 분이 많더라. 지난주에도 동료가 "JVM 앱이 livenessProbe 때문에 자꾸 재시작된다, initialDelaySeconds를 300초로 박았는데도 가끔 죽는다"는 얘길 했다. 그때 startupProbe 얘기를 꺼내면서 "어 진짜? 그런 게 있었어?"라는 반응이 나왔다. 1.20부터 GA였는데도 말이다.근데 이게 한두 명 얘기가 아니라서, 짧게 정리해둔다.initialDelaySeconds로 버티는 게 왜 문제냐흔히 쓰는 패턴이 이거다.livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 180 periodSeconds: 10 failureThresh..

월요일 아침에 출근하니 재무팀에서 슬랙이 와있었다. "지난달 AWS 비용 한 번만 확인 부탁드려요." 평소엔 무시할 만한 변동이었는데 이번엔 NAT Gateway 라인 하나만 전월 대비 3.2배가 찍혀 있었다. 다른 항목은 거의 그대로였다. 보자마자 멘탈이 살짝 흔들렸다. 우리 팀은 분기 비용 가이드라인이 있어서 한 항목이 갑자기 튀면 그게 곧 회고 거리다.여기에 진단부터 해결까지 일주일 동안 삽질한 기록을 남긴다. 결론부터 말하면 범인은 단순했고, 우리가 그동안 NAT Gateway 트래픽 구성을 너무 안 들여다본 게 진짜 문제였다.첫 번째 가설: 누가 풀데이터를 빨아 가나처음엔 누군가 새 워크로드 띄우면서 외부 데이터셋이라도 받아오는 줄 알았다. 그런데 워크로드 추가된 거 없었다. 노드 수도 그대로(..

왜 또 kube-proxy 얘기인가kube-proxy는 Kubernetes에서 가장 오래된 컴포넌트 중 하나다. 그런데 사람들은 의외로 이 친구가 실제로 뭘 하는지 잘 모른다. Service ClusterIP로 패킷이 들어오면 Pod로 잘 가더라, 정도가 평균적인 이해다. 나도 한참 그랬다.올해 1.33에서 nftables 모드가 정식으로 GA가 됐고, 이제 Linux 노드에서는 공식 권장 모드가 nftables라는 분위기가 만들어졌다. 우리 팀에서도 다음 분기 클러스터 업그레이드 때 nftables로 넘어갈지를 두고 논의 중이다. 결정을 하려면 세 모드가 도대체 어떻게 다른지를 손에 쥐고 있어야 하는데, 매번 검색해서 보다 보니 한번 정리해두자 싶었다.이 글은 "어느 모드가 빠른가" 같은 표 비교가 아..

왜 Operator인가이미지 스캔(Trivy)이랑 시그니처 검증(cosign)까지는 잘 깔아뒀는데, 정작 "이 컨테이너가 지금 이상한 짓을 하고 있는지"는 안 보이더라. 빌드 타임 보안과 런타임 보안은 다른 문제다. 컨테이너 안에서 nc -e /bin/sh가 떠도 우리는 모른다. 그래서 팀에서 Falco를 본격적으로 깔았다. 헬름 차트로 한 번 깔아본 적은 있는데 이번에 Falco Operator(0.43 기준)로 새로 정비하면서 정리한 가이드다.대상 독자는 EKS/온프렘 K8s에 Falco를 처음 도입하거나, 옛날 헬름 설치를 Operator로 옮기려는 사람.지난해까진 우리도 falcosecurity/falco 헬름 차트로 깔았다. 근데 룰을 ConfigMap으로 관리하다 보니 룰 한 줄 바꾸면 Dae..

작년 봄에 시크릿 관리 체계를 갈아엎으면서 ESO(External Secrets Operator)랑 SOPS를 둘 다 도입했다. 처음엔 하나로 통일하자는 의견이 강했는데, 1년 굴려보니 둘 중 하나만으로는 답이 안 나오더라. 결국 우리 팀은 둘을 역할로 갈라놓고 쓰는 쪽으로 정착했다.최근에 신규 팀 합류한 사람한테 이 구조를 설명할 일이 있었는데, 막상 글로 정리해두니 우리도 모호하게 쓰고 있던 부분이 꽤 보였다. 그래서 한번 정리해본다.우리 환경 간단히EKS 클러스터 4개 (dev/stage/prod 2개 — 리전 분리)ArgoCD 기반 GitOpsAWS Secrets Manager, Parameter Store 둘 다 사용 중코드 저장소는 GitHub Enterprise원래는 sealed-secret..

지난주 화요일 오전이었다. 평소처럼 백오피스 서비스 배포를 돌렸는데, 운영팀 슬랙에 "1분쯤 전에 잠깐 페이지가 안 떴어요"라는 메시지가 떴다. 처음 듣는 얘기는 아니다. 사실 우리 팀에서는 배포할 때 5xx가 한두 건 튀는 걸 그냥 "Kubernetes의 미세한 빈틈"이라고 부르며 넘기고 있었다. 근데 이번엔 운영팀 화면에 명확히 보일 정도로 길었다는 게 문제였다.Grafana로 들어가서 Ingress 컨트롤러의 5xx 그래프를 봤다. 배포 시점에 503이 약 7초간 spike. 평소에는 1초 미만이었는데 이번엔 길었다. 우리 환경은 EKS 1.32, NGINX Ingress Controller, replicas 6짜리 평범한 Deployment. 이쯤이면 "또 종료 시퀀스 문제겠지" 싶었지만, 막상 ..

출발점: 우리 환경ArgoCD 이미 운영 중 (2년 차)Istio 1.24, ambient mode는 일부 네임스페이스만마이크로서비스 약 80개, 일주일 배포 횟수 평균 120건옵저버빌리티는 Prometheus + Thanos + Grafana 조합이 시점에서 Flux CD를 쓰고 있었다면 Flagger를 골랐을 가능성이 높다. 두 도구 모두 기술적으로 충분하지만, 같은 진영의 도구를 모으는 게 운영 단순도 측면에서 유리하다는 게 1년 후 더 분명해졌다.매니페스트 마이그레이션 비용Flagger의 가장 강력한 매력은 "기존 Deployment를 그대로 두고 Canary CR만 추가하면 된다"는 점이다. 처음 PoC 할 때 이게 정말 좋았다. 30분 만에 한 서비스가 카나리 배포로 전환됐다. 반면 Argo ..