day-log

오늘 알게 된 건 아니고, 얼마 전부터 팀 내부에서 오토스케일링 튜닝하다가 정리한 팁이다. 근데 이거 모르는 분들이 의외로 꽤 있어서 짧게 남긴다.HPA behavior 필드는 v2에서 나온 뒤로 GA 된 지가 좀 됐는데, 아직도 기본값 그대로 쓰는 팀이 많더라. 그 중에서도 stabilizationWindowSeconds가 특히 문제다.뭐가 문제였냐면트래픽이 규칙적으로 확 튀었다가 3-4분 안에 원상복구되는 서비스가 하나 있다. 이벤트 배너 서비스인데, CPU가 순간 60%까지 튀고 30초쯤 지나면 20% 아래로 떨어진다.HPA 기본 설정으로 놔뒀더니 이런 흐름이 반복됐다:트래픽 스파이크 → 5개 → 12개로 스케일 업30초 뒤 트래픽 원상복구5분 뒤 (기본 downscale stabilization ..

지난주에 진짜 며칠을 날렸다. 결론부터 말하면 범인은 ndots:5 였는데, 이 얘기 어디선가 다들 한 번씩은 들어봤을 거다. 근데 막상 우리 클러스터에서 실제로 터지니까 원인 찾는 데 이틀이 걸렸다. 이번엔 그 과정에 대한 기록이다.증상: 새벽 3시에 켜진 페이지노드 40대 규모의 EKS 클러스터에서 결제 관련 서비스 P99 레이턴시가 갑자기 튀기 시작했다. 평소엔 60ms 언저리였는데, 어느 순간부터 800ms까지 스파이크가 찍힌다. 새벽 3시에 폰이 울려서 잠이 확 깼다.처음 든 생각은 "또 RDS인가"였다. 요즘 우리 팀에선 뭐만 느려지면 일단 DB부터 의심하는 게 습관이 됐거든. 근데 커넥션 풀도, slow query 로그도, RDS CloudWatch도 다 깔끔했다. 애플리케이션 로그를 뒤져봐..

Fluent Bit vs OpenTelemetry Collector, 로그 파이프라인 뭘 쓸까로그 파이프라인 얘기가 나올 때마다 팀 내부에서 도는 논쟁이 하나 있다. "그냥 Fluent Bit 계속 쓰면 되지 않냐" vs "이제 OpenTelemetry Collector로 통합해야 하지 않냐". 사실 둘 다 맞는 말이라 답이 애매하다. 몇 달간 두 도구를 병렬로 굴려보고 정리한 감상을 적어둔다.어디서 마주치는 문제인가우리 팀 클러스터는 노드 40대 규모다. 로그는 원래 Fluent Bit DaemonSet으로 수집해서 사내 Loki로 밀어넣고 있었다. 문제는 그 다음 단계다. 트레이스는 OTel Collector로, 메트릭은 Prometheus로, 로그만 Fluent Bit로 각각 다른 파이프라인이 돌고..

지난달에 팀 내부에서 "이미지 취약점 스캔 좀 제대로 붙여야 하지 않냐"는 얘기가 나왔다. 그 전까진 CI 파이프라인에서 trivy image 한 줄로 빌드 시점에만 스캔하고 있었는데, 클러스터에 이미 떠 있는 워크로드는 아무도 안 챙기고 있었다. 이미지 태그가 latest인 것도 있고, 6개월 전에 배포하고 그대로인 것도 있었다. 그래서 Trivy Operator를 붙였다. 그리고 다음날 새벽에 슬랙 알림이 몇백 개 쏟아졌다.왜 Trivy Operator였나선택지는 몇 가지 있었다. Trivy Operator, Kubescape, Falco, StackRox 같은 것들. 우리는 이미 CI에서 Trivy를 쓰고 있었고 룰이 익숙했다. 그리고 Aqua가 계속 유지보수하고 있어서 커뮤니티가 가장 활발했다. ..

노드 drain 걸었는데 특정 파드가 계속 evict 안 되고 남아 있던 적, 다들 한 번쯤 있을 거다. 반대로 drain 명령 하나로 서비스가 순간적으로 다 내려가서 알람이 우수수 뜬 경험도. 이 두 상황 사이의 균형을 잡아주는 게 PodDisruptionBudget(PDB)인데, 막상 실무에서 어떻게 세팅해야 할지는 문서만 봐서는 잘 안 잡힌다.우리 팀도 노드 수십 대짜리 EKS 클러스터에서 Karpenter로 consolidation을 돌리면서 몇 번 삽질을 했다. PDB 하나 잘못 걸어서 consolidation이 몇 시간씩 멈춰 있던 적도 있고. 그래서 지금 팀 안에서 굳어진 룰 위주로 정리해본다.minAvailable vs maxUnavailable, 뭘 쓸까이거 은근히 헷갈리는데, 결론부터 ..

Kubernetes Service가 어떻게 Pod에 트래픽을 흘려보내는지, 표면적으로는 다들 안다. Service → Endpoints → Pod IP 이렇게 이어진다는 그림 말이다. 그런데 실제로 v1.33 기준으로 클러스터 안에서 벌어지는 일은 이 그림과 조금 다르다. Endpoints API는 이제 사실상 legacy로 밀려나 있고, 그 자리를 EndpointSlice가 완전히 차지했다. 최근에 우리 팀 신규 클러스터를 1.33으로 올리면서 노드 350대짜리 스테이징에서 Service 업데이트 지연을 재현하다가, 이 내부 동작을 다시 파고들 일이 있었다. 오늘은 그 정리다.이 글은 짧지 않다. Service의 실체가 궁금하거나, kube-proxy 성능이 왜 클러스터 규모에 따라 갑자기 무너지는지 ..

작년까지만 해도 "OpenTofu는 아직 지켜봐야지" 하는 분위기가 있었다. 그런데 올해 들어 상황이 좀 달라졌다. 우리 팀에서 최근 IaC 도구 재검토를 하면서 정리했던 내용을 공유하려고 한다. 결론부터 말하면 케이스 바이 케이스인데, 그 "케이스"를 어떻게 나눠서 봐야 하는지가 핵심이었다.시장 점유율만 놓고 보면 Terraform이 여전히 우세하다. 2026년 4월 기준으로 OpenTofu 채택률이 12% 정도, Terraform은 여전히 30%대 후반이다. 근데 이 숫자만 보면 안 되는 게, 신규 프로젝트에서 OpenTofu를 선택하는 비율이 훨씬 높다. 기존 Terraform 자산이 없는 팀 기준으로만 보면 이야기가 완전히 달라진다.라이선스 문제, 실제로 회사에 영향을 주나이게 우리 팀에서 가장 ..

이거 모르는 분 꽤 많더라. 어제 팀원이 "distroless 이미지로 바꿨더니 이제 파드 안 들여다볼 수가 없어요"라고 물어봐서, 그 자리에서 알려준 팁. 사실 별 것도 아닌데 정리해두면 다음에 또 물어보는 사람 나오니까.상황distroless 베이스로 만든 컨테이너는 셸도 없고 cat도 없다. 그러니 kubectl exec -it pod -- sh 는 당연히 안 먹힌다. 예전에는 어쩔 수 없이 debug용 이미지 하나 더 만들거나, 파드를 아예 복제해서 이미지만 갈아끼우거나 했었다. 근데 Kubernetes 1.25부터 ephemeral container가 stable 됐고, kubectl debug 로 훨씬 편해졌다.문제는 그냥 kubectl debug pod/foo -it --image=busyb..

애플리케이션에 DB 비밀번호를 어떻게 넣어놓고 계셨나요. 우리 팀은 예전에 Kubernetes Secret에 base64로 넣어놓고, 분기마다 수동으로 로테이션했다. 근데 이게 몇 년 이어지다 보니 문제가 쌓였다. 누가 언제 그 시크릿을 봤는지 감사 로그가 없고, 로테이션 날에는 여러 서비스가 동시에 재기동되면서 P99 레이턴시가 튀었다. 결국 Vault Dynamic Secrets로 넘어갔는데, 처음 설정할 때 헤맨 부분이 좀 있어서 정리해둔다.이 글은 PostgreSQL 기준이지만 MySQL이나 MongoDB도 큰 틀은 같다. 최근 Vault 1.19에서 rotation_schedule 필드로 크론 스타일 스케줄이 정식 지원되면서 static role 운용이 훨씬 편해졌다.Dynamic Secrets..

지난달에 결국 pgbouncer 풀 모드를 session에서 transaction으로 바꿨다. 결과부터 말하면 잘 됐다. 근데 그 3주 동안 두 번은 새벽에 잠에서 깼고, 한 번은 회의 도중에 대시보드 보고 얼굴이 하얘졌다. 기록 삼아 남긴다.왜 갈아탔나우리 서비스는 백엔드 20개 파드가 각각 커넥션 풀 20을 잡는다. 그러니까 idle 상태에서도 Postgres 쪽에는 400개 커넥션이 잡혀 있다는 얘기다. Aurora r6g.2xlarge 기준 max_connections가 900 남짓인데, 스케일 아웃 몇 번 하면 아슬아슬해진다.그동안 pgbouncer를 session pooling으로 쓰고 있었는데, 이건 사실상 아무 이득이 없었다. 클라이언트 커넥션 하나가 백엔드 커넥션 하나를 트랜잭션 단위가 ..