day-log

오늘 알게 된 건 아닌데, 의외로 안 걸어둔 팀이 꽤 있더라. idle_in_transaction_session_timeout 얘기다.내용은 단순하다. BEGIN 떠놓고 클라이언트가 다음 쿼리 안 보내고 가만히 있는 세션을 지정 시간 지나면 서버가 죽인다. 기본값이 0(비활성)이라 그냥 둔 클러스터가 많은데, 한 번 사고 겪고 나면 절대 안 빼게 된다.왜 굳이 켜야 하나문제는 두 갈래다.첫째, 락 점유. 누가 어딘가에서 UPDATE 치고 COMMIT 안 한 채 자리 비우면 그 행은 계속 잠긴 채로 다른 쿼리들이 줄을 선다. 우리 팀에선 예전에 어드민 페이지에서 BEGIN; UPDATE ... WHERE id=?; 까지 가놓고 응답 안 돌아온 세션 하나 때문에 결제 트래픽 P99가 8초까지 튀었다.둘째, ..

지난주 화요일 새벽 3시쯤이었다. 슬랙 oncall 채널에 "그라파나 대시보드 일부 패널이 No data로 뜬다"는 핑이 올라왔다. 자다가 받은 알림이라 멘탈이 좀 나간 상태에서 노트북을 열었는데, 진짜로 우리 결제 서비스 P99 레이턴시 그래프가 새벽 1시 47분부터 약 한 시간 동안 비어 있었다.문제는 Prometheus 자체는 멀쩡했다는 거다. up{} 메트릭도 정상이고 로컬 쿼리도 잘 됐다. 그런데 Thanos를 통해 보던 장기 보관 대시보드에서만 그 구간이 통째로 비어 있었다. 결론부터 말하면 remote_write 큐가 막혀서 WAL에서 읽기가 블록됐고, 그 사이에 들어온 샘플들이 일부 누락됐다. 이게 내가 새벽 4시까지 깨어 있었던 이유다.처음 의심한 것들 (다 틀렸음)가장 먼저 의심한 건 ..

Kyverno ClusterPolicy를 ValidatingPolicy(CEL)로 옮기는 법Kyverno가 3월 KubeCon EU 암스테르담에서 CNCF graduated 프로젝트로 승격됐다. 같은 흐름에서 1.17부터 CEL 기반의 새 정책 타입(ValidatingPolicy, MutatingPolicy 등)이 GA로 바뀌었고, 기존 ClusterPolicy API는 2026년 10월 제거 예정이라는 공지가 같이 나왔다. 우리 팀은 그동안 ClusterPolicy로 30개 가까운 정책을 운영하고 있었는데, 일정상 7월까지는 옮겨야 한다. 이번 글은 그 마이그레이션 작업을 하면서 정리한 가이드다.대상 독자는 Kyverno를 이미 한 번이라도 운영해 본 사람이다. CEL 자체가 처음이라면 마지막 섹션의 ..

이거 모르는 분 꽤 많더라. 우리 팀 모듈 plan에 8분 넘게 걸리던 게 4분으로 줄었다. 코드 한 줄도 안 고쳤다.뭐가 문제였냐면terraform plan 돌리면 기본적으로 state에 있는 모든 리소스를 클라우드 API에 한 번씩 조회한다(refresh). 리소스 200개짜리 모듈이면 200번 API 콜이 도는데, AWS provider 같이 throttling 걸리면 더 느려진다.CI에서 PR마다 plan을 돌리는 입장에서는, 매번 fresh한 state가 필요한 것도 아닌데 이 refresh 때문에 시간을 다 까먹는다. 특히 우리는 monorepo에 모듈 30개 있어서 PR 하나 올리면 plan job 30개가 동시에 돌고, 그러면 AWS API throttling까지 같이 터진다.그래서 이렇게..

cgroup v2 전환 후 OOMKill 동작이 바뀐 이유올해 초 우리 팀 클러스터를 EKS 1.28에서 1.30으로 올리면서 cgroup v2 노드 비율이 100%가 됐다. 그 직후부터 묘하게 신경 쓰이는 현상이 생겼다. 예전 같으면 사이드카 하나만 OOM으로 죽고 메인 컨테이너는 살아 있던 케이스가, 이제는 컨테이너 안의 모든 프로세스가 한꺼번에 같이 죽고 있었다. 처음에는 "그래, 이게 더 깔끔하긴 한데" 정도로 넘겼는데, 일부 멀티 프로세스 워크로드가 갑자기 불안정해지는 걸 보고 한참을 파봤다. 결론부터 말하면 이건 버그가 아니라 의도된 변경이고, 알고 쓰면 오히려 운영이 단순해진다. 다만 모르고 쓰면 황당한 장애를 만난다.이 글은 그 동작이 왜, 어디서, 어떻게 바뀌었는지를 cgroup, kub..

새벽 3시 7분에 진동이 왔다새벽 3시 7분. 폰이 진동했다. etcd_mvcc_db_total_size_in_bytes 가 6GiB를 넘었다는 알람이었다. 우리 클러스터는 컨트롤플레인이 EKS가 아니라 자체 운영이고, etcd quota를 8GiB로 잡아놨다. 8GiB를 넘기는 순간 클러스터가 read-only로 떨어진다. 일어났다.평소에는 etcd db size가 1.2~1.5GiB 사이를 왔다 갔다 한다. 그게 6GiB라는 건 어딘가가 단단히 잘못됐다는 뜻이다. 처음엔 그냥 defrag 한번 돌리면 되겠지 했는데, 이게 그렇게 단순한 얘기가 아니었다.일단 무슨 일이 일어났는지부터 봤다ssh로 컨트롤플레인 노드 3대에 붙어서 etcdctl로 상태를 봤다.ETCDCTL_API=3 etcdctl \ -..

GitOps 도구 고민은 의외로 끝나지 않는다. 작년 이맘때 우리 팀은 ArgoCD를 쓰고 있었는데, 어쩌다보니 한 분기를 Flux로 갈아엎고 돌렸다가 결국 다시 ArgoCD로 돌아왔다. 비교 글은 인터넷에 차고 넘치지만, 둘 다 운영 환경에서 한 사이클씩 굴려본 입장에서 쓸 만한 글은 의외로 적었다. 그래서 정리해본다.전제부터 깔자. 우리 팀은 EKS 클러스터 7개(prod 3, staging 2, dev 2), 약 220개 마이크로서비스, 배포는 하루 평균 60건쯤이다. 큰 조직은 아니지만 작지도 않다. 이 규모에서 우리가 겪은 차이를 적는다.왜 갈아탔다가 다시 돌아왔나원래 ArgoCD 2.10대를 1년 정도 잘 쓰고 있었다. 그런데 ApplicationSet generator 설정이 점점 비대해지고..

지난주 새벽에 알림으로 깼다. otel-collector 데몬셋의 절반이 CrashLoopBackOff로 떨어졌다는 메시지. 그 시점에 트레이스 수집이 사실상 끊겨 있어서 우리 팀이 운영하는 서비스 절반 정도의 트레이스 대시보드가 비어 있었다. 평일 새벽 두 시였고 멘탈은 그닥이었다.처음엔 단순히 노드 메모리 압박이려니 했다. 그런데 살펴보니까 콜렉터만 죽는 거다. 다른 파드는 다 멀쩡. OOMKilled가 한두 번이 아니라 5분에 3-4번씩 반복되고 있었다. 메모리 limit이 1Gi였는데, 어떻게 잡힌 메모리가 그 한도를 매번 풀로 채우고 떨어졌다 다시 살아나고를 반복.일단 상황 정리kubectl describe로 보니까 Last State가 Terminated, Reason: OOMKilled, E..

마이그레이션 전에 점검할 것ingress-nginx가 결국 작년 3월에 EOL됐다. 깃허브 저장소는 archived 처리됐고, 보안 패치도 더 이상 안 나온다. 그동안 미루고 미뤘는데 이제는 정말 도망갈 데가 없다. 우리 팀도 6월 들어서야 본격적으로 Gateway API 마이그레이션을 시작했고, 이 글은 그 과정에서 정리한 가이드다.처음에는 막막했다. Ingress 리소스가 200개가 넘는데 이걸 일일이 손으로 옮긴다고? 다행히 SIG-Network에서 올해 3월에 ingress2gateway 1.0을 정식 릴리스했다. 이걸 쓰면 대부분의 Ingress 리소스가 자동으로 변환된다. 물론 자동 변환이 모든 걸 해결해주지는 않는다는 게 함정이지만.본격적으로 시작하기 전에 두 가지를 먼저 확인했다.첫 번째는..

작년 이맘때쯤 우리 팀에 Chaos Engineering 도입 미션이 떨어졌다. SRE 본부에서 "장애 대응 훈련을 코드로 돌릴 수 있게 만들자"라는 좀 추상적인 OKR이 내려왔고, 첫 분기는 Chaos Mesh, 두 번째 분기부터는 Litmus로 갈아탔다가, 결국 둘을 섞어서 쓰고 있다. 1년이 지나서 다시 정리해보니 둘 중 뭘 골라야 하느냐는 질문이 잘못된 질문이었다는 결론이 났다. 어느 팀이 어느 부분을 책임지냐에 따라 답이 달라진다.Litmus는 작년 가을 3.0으로 메이저 버전이 올라가면서 UI가 Harness UIcore 기반으로 싹 바뀌었고, Chaos Workflow가 Chaos Experiments로, Chaos Experiments가 Chaos Faults로 용어가 재정의됐다. 올해 1..