day-log

정책 엔진 이야기다. 두 달 전쯤 팀 내부에서 Kyverno로 다 밀어붙이던 policy를 재정비하기로 했다. 계기는 별거 아니다. 신규 클러스터를 하나 더 세팅하는데 Kyverno controller 파드가 죽었다는 알람이 새벽에 두 번 울렸고, 새벽에 눈 뜬 내가 생각했다. "이거, 정말 다 Kyverno여야 되나."Kubernetes 1.30에서 ValidatingAdmissionPolicy(이하 VAP)가 GA된 게 2024년 4월이다. 지금은 2026년 중반이니 GA된 지 2년이 넘었고, EKS든 GKE든 안정 채널에서 이미 쓸 수 있는 상태다. CEL 기반이라 API 서버 안에서 바로 평가되고, 웹훅이 없다. 이 두 가지가 결국 우리 결정의 핵심이 됐다.Kyverno 하나로 밀어붙였을 때의 문..

왜 지금 넘어가야 하나Grafana Agent(Static/Flow/Operator)가 2025년 11월 1일에 공식적으로 EOL을 맞았다. 우리 팀도 그 전에 다 넘겨야 했는데, 막상 문서를 보면 "convert 명령어 쓰세요" 정도로 뭉뚱그려져 있어서 실무에서 걸리는 지점이 꽤 있었다. 이 글은 프로덕션 클러스터 3개(스테이징 1, 프로덕션 2 — 노드 합쳐서 80대 정도)에서 넘긴 기록을 정리한 것이다.Alloy는 이제 단순히 Agent 후속작이 아니라 Grafana Labs가 OpenTelemetry Collector를 자기네 방식으로 배포하는 형태에 가깝다. 이게 왜 중요하냐면, 기존에 metrics {}, logs {} 블록으로 쪼개 놓던 것이 otelcol.* 파이프라인과 나란히 놓이면서 c..

처음엔 KEDA 버그를 의심했다지난 금요일 오후, 대시보드를 열었다가 눈을 의심했다. SQS 큐 depth는 0인데 워커 파드가 40대씩 떠 있었다. minReplicaCount 는 2로 잡아뒀는데 왜 안 내려가지?KEDA를 SQS와 붙여 쓰는 팀이라면 한 번쯤 겪는 함정인 것 같아 정리해둔다.우리 팀은 이미지 후처리 워커를 EKS에서 KEDA로 굴린다. SQS 큐 depth 기반으로 스케일 아웃/인 시키는 흔한 구조다. 큐가 비면 minReplicaCount인 2대까지 내려가야 하는데, 그날은 40대에서 요지부동이었다. kubectl describe scaledobject를 찍어보니 metricValue가 계속 큰 값으로 나왔다.근데 SQS 콘솔에서 큐 depth는 진짜 0이다. Approximate ..

오늘 알게 된 건 아니고 예전부터 알고는 있었는데, 최근에 신규 서비스 튜닝 도우면서 "아 이거 진짜 모르는 팀 아직도 많구나" 싶어서 짧게 남긴다.PostgreSQL 파라미터 중에 idle_in_transaction_session_timeout 라는 게 있다. 이름 그대로 트랜잭션 시작해놓고 아무것도 안 하는 세션을 강제 종료해주는 값이다. 기본값은 0, 즉 비활성이다.왜 이게 문제가 되나전형적인 시나리오는 이렇다.앱에서 BEGIN 날려서 트랜잭션 열어놓고, 그 사이에 외부 API 호출한다. 근데 그 API가 30초쯤 걸린다. 그동안 이 커넥션은 어떤 상태냐면 idle in transaction. 살아는 있는데 아무 일도 안 하고, 그런데 락은 잡고 있을 수도 있다.이런 커넥션이 몇 개 쌓이면 pg_s..

Deployment를 Rollout으로 마이그레이션배포할 때마다 심박수가 올라가는 사람 있으면 손. 나만 그런 거 아닐 거다. 특히 트래픽이 몰리는 시간대에 롤아웃 눌러야 할 때는 정말 부담이다. Deployment의 기본 RollingUpdate 전략이 나쁜 건 아닌데, 문제는 "일단 다 밀리고 나면 되돌리기가 귀찮다"는 점이다. HPA에 물려 있는 상황에서 새 버전이 죽으면 롤백 중에도 오토스케일이 계속 돌아서 상황이 더 꼬인다.그래서 우리 팀은 몇 달 전부터 Argo Rollouts를 도입해서 카나리 배포로 옮기고 있다. 이 글은 도입 과정에서 배운 것과, "이건 처음에 알았으면 좋았을 텐데" 싶은 것들을 정리한 실무 가이드다.이달 말에 열리는 ArgoCon Japan 2026 세션 리스트를 훑어보..

배포는 빨라졌는데, 왜 그래프가 자꾸 뻘겋게 되나배포 시간이 오래 걸리는 게 싫어서 ALB target group의 deregistration_delay를 30초까지 내렸다가, 몇 주 동안 배포 때마다 5xx가 조용히 튀는 걸 뒤늦게 알아챈 이야기다. 뭐 그렇게 대단한 사건은 아닌데, 원인이 좀 얄궂어서 기록으로 남긴다.우리 팀은 ECS on EC2로 앱을 굴린다. 배포는 하루에 5~7번, 카나리 없이 rolling update. 처음에는 deregistration_delay=300 (기본값 5분)이었는데, 배포가 뭘 하나만 바꿔도 10분씩 걸리는 게 아까워서 30초로 내렸다. task 자체는 gracefully shutdown 잘 하니까 30초면 넉넉하다고 판단했다.며칠 뒤부터 CloudWatch 대시..

지난주에 OpenTelemetry Collector가 새벽에 세 번이나 OOM으로 재시작됐다. 알림이 잔뜩 쌓여있었고, 아침에 슬랙 열자마자 "이거 뭐야" 소리가 절로 나왔다. 원인은 결국 tail sampling processor였는데, 문제를 잡기까지 꽤 돌아왔다. 기록 삼아 남긴다.처음엔 그냥 트래픽 스파이크인 줄 알았다우리 팀은 최근에 head sampling에서 tail sampling으로 옮겼다. 이유는 명확했다. 에러 트레이스나 P99 넘어가는 느린 트레이스는 무조건 살려두고 싶은데, head sampling으로는 그게 불가능하니까. 트레이스 전체가 다 모여야 판단할 수 있는 정책들, 예를 들어 "이 트레이스에 5xx가 하나라도 있으면 keep" 같은 것들 말이다.옮긴 지 2주 정도는 조용했..

오늘 알게 된 건데, GitHub Actions에 queue: max 옵션이 생겼다. 5월 초에 조용히 릴리즈된 것 같다. 이거 모르는 분 꽤 많을 것 같아서 짧게 정리한다.기존 방식의 아쉬움우리 팀은 배포 파이프라인에 concurrency 그룹을 걸어 놨었다. 같은 환경에 두 개가 동시에 배포되면 곤란하니까.concurrency: group: deploy-${{ github.ref }} cancel-in-progress: false문제는 이 설정으로 큐잉되는 최대 개수가 딱 1개였다는 거다. 진행 중 1개 + 대기 중 1개, 총 2개까지만. 세 번째 잡이 들어오면 대기 중이던 잡이 그냥 취소됐다. 배포 트리거가 몰리는 날에는 중간 잡이 스킵돼 버려서, PR 머지 순서움 실제 배포 순서가 어긋나는 상..

지난 주 화요일 아침에 백엔드 팀장이 슬랙 DM으로 물어봤다. "요즘 CI가 왜 이렇게 느려요? 예전에는 8분이면 됐는데 요새는 20분 넘게 걸리는 것 같은데." 확인해보니 정말 그랬다. Go 서비스 하나의 build job이 12분에서 19분으로 늘어나 있었다. 뭐 변경한 것도 없는데.내가 저 CI를 마지막으로 만진 게 6월 초였다. --mount=type=cache를 붙여서 Go module 다운로드를 캐싱하도록 바꿨다. 그때는 확실히 빨라졌다. 첫 빌드가 14분, 두 번째부터는 5분대. 팀 슬랙에 자랑까지 했다. 그런데 한 달 반이 지난 지금은 20분이 나오고 있었다.처음엔 러너 탓인 줄 알았다첫 번째 추측은 GitHub Actions runner가 지역별로 느려졌나 하는 것이었다. 요새 self-..

Terraform을 몇 년 굴려본 팀이면 한 번쯤은 겪는 상황이 있다. state 파일 하나에 리소스가 500개, 800개 넘게 쌓이면 plan 한 번 돌리는 데 몇 분씩 걸리고, 누구 하나가 apply 걸어놓으면 다른 사람은 하염없이 기다려야 한다. 그러다 어느 날 실수로 리소스 하나 잘못 지우면 blast radius가 너무 커서 롤백도 쉽지 않다.우리 팀도 초기에는 그냥 terraform/ 폴더 하나에 다 몰아넣고 시작했다. 편하긴 한데, 팀 규모가 커지고 환경이 dev/stage/prod로 늘어나면서 이 구조가 점점 부담스러워졌다. 이 글은 state 파일을 어떻게 쪼개고, 원격 백엔드는 어떻게 설정하고, drift는 어떻게 감지하는지 실무 관점에서 정리한 가이드다.최근에 OpenTofu 1.10..