day-log

지난주에 우리 팀 리포팅 DB — Postgres 18로 올린 지 두 달째다 — 에 async I/O를 본격적으로 켜보자고 결심했다. Postgres 18에서 들어온 AIO가 sequential scan, bitmap heap scan, vacuum 같은 read-heavy 작업에서 최대 2~3배까지 빨라진다는 얘기가 릴리스 노트부터 pganalyze 벤치까지 여기저기 도배돼 있었고, 우리 리포팅 워크로드는 딱 그 형태였다. NVMe 붙은 i4i 계열, 대형 seq scan이 하루에도 수백 번 도는 그런 곳.결과부터 말하면 결국 io_method = worker로 되돌렸고, io_uring은 우리 환경에서 못 썼다. 왜 그렇게 됐는지 시간 순서대로 남겨둔다.첫 번째 삽질: `io_method=io_uri..

Django, SQLAlchemy, node-postgres 같은 걸 쓰다가 PgBouncer 뒤에 붙이면 한 번쯤 만나는 에러가 있다. prepared statement "S_1" does not exist. 그 순간 대부분의 팀은 두 갈래로 갈라진다. 하나는 transaction pool을 포기하고 session pool로 내리는 쪽. 다른 하나는 앱단에서 prepared statement를 아예 끄는 쪽. 어느 쪽이든 성능을 반쯤 반납하는 거였다.PgBouncer 1.21에서 transaction pool에서도 protocol-level prepared statement를 쓸 수 있게 됐고, 최근 1.22가 나오면서 DISCARD ALL / DEALLOCATE ALL까지 다뤄져서 실무에서 쓰기가 훨..

sigstoreDevSecOpsGitHub-Actions공급망보안keyless 오늘 후배가 "이미지 서명하려는데 KMS 키 발급받아야 하냐"고 물어서 답해준 김에 정리한다. 2026년에 아직도 cosign에 개인 키 파일 물려서 쓰고 있다면 이 글이 도움 될 거다. GitHub Actions만 쓰면 키 관리 자체가 필요 없다.keyless가 뭐하는 건가cosign keyless는 서명할 때 개인 키 대신 CI의 OIDC 토큰을 쓴다. 흐름은 이렇다.GitHub Actions가 워크플로우 실행 중에 짧은 수명의 OIDC 토큰을 발급한다. 이 토큰에는 리포지토리, 브랜치, 워크플로우 경로 같은 identity 정보가 들어있다.cosign이 이 토큰을 Sigstore의 Fulcio에 넘긴다. Fulcio는 토..

지난주 화요일 새벽이었다. EKS 컨트롤 플레인 마이너 버전 업그레이드에 맞춰 노드 그룹 rolling 교체를 걸어놨는데, 새벽 3시쯤 슬랙에 "노드 3대가 30분째 SchedulingDisabled 상태로 안 빠진다"는 알림이 떴다. 새벽에 눈이 번쩍 떠졌다.원인은 결국 우리가 반년 전쯤 붙여둔 PodDisruptionBudget 이었다. 그런데 이게 왜 하필 이번 업그레이드에서 터졌는지, 어디서 계산이 어긋났는지를 정리해두려고 이 글을 쓴다.뭐가 문제였나우리 팀은 결제 관련 워크로드 몇 개에 minAvailable: 2 로 PDB를 걸어뒀다. 처음 붙일 때 replica가 4~5개였고, "최소 2개는 살아있어야 한다"는 서비스 팀 요구를 반영한 값이었다.문제는 그 사이에 트래픽 특성이 바뀌면서 몇몇 ..

작년 12월 1.35에서 In-place Pod Resize가 드디어 GA로 승격됐다. KEP-1287, alpha가 1.27에서 붙었으니 거의 3년을 굴러 온 셈이다. 사내에서도 "이제 VPA를 Recreate 없이 돌릴 수 있는 거냐"는 얘기가 나왔고, 실제로 몇 개 워크로드에는 붙여봤다. 근데 붙여보고 나서 든 생각은, 스펙 문서만 보고 판단하기엔 내부 동작이 좀 미묘하다는 거였다.이 글은 우리 팀이 실제로 어떤 지점에서 걸렸고, 왜 GA인데도 아직 전 클러스터 롤아웃을 안 했는지에 대한 이야기다. 스펙 요약이 아니라 kubelet과 컨테이너 런타임 경계에서 실제로 무슨 일이 벌어지는지를 파고들어 본다.리사이즈 요청이 실제로 통과하는 경로kubectl로 파드 리소스를 patch하면, 그 요청은 po..

로그 파이프라인 재설계 얘기가 팀 내부에서 다시 나왔다. 3년 전에 Fluentd로 깔아둔 걸 언제까지 끌고 갈지, 지금 시점에서 갈아탄다면 Fluent Bit이냐 Vector냐. 두 도구 모두 몇 달씩 붙잡고 굴려봤기 때문에 이 참에 정리해두려고 한다.결론부터 말하면 "무조건 이거"는 없다. 다만 우리 팀이 어떤 상황에서 뭘 골랐는지, 왜 그랬는지는 명확하게 얘기할 수 있다.두 도구를 다시 보자Fluent Bit은 C로 짜였고 CNCF 공식 프로젝트다. Kubernetes 생태계 안에서는 사실상 표준처럼 자리잡은 지 오래다. 바이너리 크기 작고, 메모리 몇십 MB로 노드마다 DaemonSet으로 깔아둬도 티가 안 난다. Kubernetes metadata filter가 안정적이고, tail input의..

Terraform state 정리, 아직도 terraform state mv 로컬에서 치고 있는지? 우리 팀도 얼마 전까지는 그랬다. 리소스 하나 옮길 때마다 누군가 로컬에서 state 조작을 하고, PR에는 코드만 올라가고, "state는 내가 미리 옮겨놨어요" 슬랙 메시지가 흘러가고. 그러다 한 명이 실수하면 다음 사람이 apply 돌릴 때 리소스가 destroy/create 로 뜬다. 새벽에.이 문제를 해결하려고 나온 게 declarative state 관리 블록 세 개다. moved (1.1+), import (1.5+), removed (1.7+). 이름만 들으면 뻔한데, 실제로 팀 컨벤션으로 못박아 놓으면 state 관련 사고가 눈에 띄게 줄어든다. 최근 Terraform 1.11 대까지 오면..

지난주 화요일 새벽 3시 반쯤, 슬랙 알림에 깼다. "CI 전체 실패 중" 이라는 온콜 메시지. 눈 비비고 노트북 열었더니 GitHub Actions 화면이 온통 빨간색이었다. 로그를 열어보니 다들 같은 메시지를 뱉고 있었다.No space left on device우리 팀은 self-hosted runner를 EC2 위에 올려서 쓴다. 처음 세팅했을 때부터 "언젠가 디스크 문제 터진다"는 거 알고 있었는데, 대응을 미루다가 결국 새벽에 얻어맞은 케이스였다. 그날 겪은 삽질을 정리해둔다.상황우리 러너 구성은 대략 이랬다.c6i.2xlarge EC2 3대, ephemeral 아니고 long-runninggp3 100GB 루트 볼륨 하나Docker in Docker로 이미지 빌드/테스트하루 평균 400개 정..

Karpenter 1.x가 굴러가는 클러스터를 몇 개 운영해보니, "왜 이 노드가 갑자기 사라졌지?" 하는 질문이 종종 나온다. 특히 consolidation 정책을 WhenEmptyOrUnderutilized로 두면 (1.x 기본값이다) 반쯤 차 있는 노드도 사라진다. 사실 내부적으로는 꽤 정교한 시뮬레이션을 돌리고 있는데, 이걸 모르면 로그만 봐도 무슨 소린지 모르겠다.이 글은 Karpenter가 노드 하나를 지우기로 결정하기까지 내부에서 무슨 일이 벌어지는지, 코드 구조와 로그를 따라가면서 풀어본다. 우리 팀에서 Karpenter를 도입한 지 반년쯤 됐는데, 이 흐름을 이해하고 나니 disruption budget 튜닝이 훨씬 편해졌다.disruption controller가 하는 일Karpente..

지난달 얘기다. SLO 도입한 지 반 년쯤 지났고, 이제 대시보드에 error budget 남은 % 뜨는 것도 익숙해질 무렵이었다. 그런데 정작 알림이 이상하게 울렸다. 새벽 2시에 페이지 오는데 실제로 보면 이미 회복돼 있고, 반대로 며칠에 걸쳐 조금씩 새는 장애는 누구도 눈치를 못 챘다. 팀 회고 때 한 명이 "우리 burn rate alert가 알림 역할을 못 하고 있는 것 같다"고 얘기했고, 그때부터 3주 동안 정말 여러 번 갈아엎었다.처음엔 그냥 5분 창이었다부끄러운 얘기지만, 처음 세팅한 알림은 "최근 5분 error rate가 SLO 임계값의 10배 넘으면 페이지" 정도였다. 이게 왜 문제인지는 세팅한 사람도 알고 있었을 텐데, 그냥 다들 바빠서 방치돼 있었다.문제는 두 가지였다.첫째, 트래..