day-log

지난주 새벽에 우리 팀 메인 OLTP 클러스터를 PG 16.4에서 17.4로 올렸다. 사실 이 업그레이드는 한 달 전부터 일정에 잡혀 있었고, 나는 자신이 있었다. 17부터는 pg_upgrade가 logical replication slot을 살려준다는 그 기능 때문이었다. 16까지는 메이저 올릴 때마다 슬롯을 다 날리고, subscriber 쪽에서 다시 풀 싱크를 떠야 했는데 그게 진짜 끔찍했었다. 우리는 분석계로 빠지는 publication이 4개 있었고, 가장 큰 테이블이 압축 후 1.2TB짜리라 풀 싱크 한 번 뜨면 6시간이 그냥 사라졌다.근데 그 자신감이 새벽 3시 17분에 박살 났다. 정확히 어디서 박살났는지, 그리고 다음에 같은 작업을 하는 분들이 같은 데서 안 깨지길 바라는 마음으로 적어둔..

오늘 PR 리뷰하다가 Dockerfile에서 발견한 게 있어서 짧게 적어둔다. CI 빌드 시간 길다고 투덜대는 동료가 있는데, 정작 Dockerfile에는 RUN apt-get install -y ... 한 줄만 덩그러니 있더라. cache mount를 안 쓰고 있었다.이게 좀 의외였다. Docker 18.09에서 BuildKit 들어온 게 한참 됐고, cache mount도 새 기능이 아닌데, 의외로 실무에서 안 쓰는 사람이 많다. 한번 적용하면 빌드 시간이 절반 이하로 떨어지는 걸 자주 본다.그래서 뭐하는 건데RUN --mount=type=cache,target=... 한 줄을 RUN 명령에 붙이면, BuildKit이 그 디렉토리를 빌드 간에 영속화해준다. 캐시 레이어가 깨져서 RUN을 다시 돌려도,..

월말마다 AWS 비용 리포트 보다가 NAT Gateway 항목에서 한숨 쉬어본 적 있다면 이 글이 도움이 될지도 모르겠다. 우리 팀도 작년에 비슷한 상황이었고, VPC Endpoint 몇 개 깔아둔 것만으로 NAT 처리 비용이 한 달 기준 40% 가까이 빠졌다. 거창한 아키텍처 변경 없이.이번 4월 AWS 비용 가이드들을 다시 훑어봤는데 NAT Gateway 단가는 여전히 시간당 $0.045, GB당 $0.045다. 게이트웨이 하나 띄워놓으면 가만히 있어도 월 $32. 거기에 처리량까지 붙으니 트래픽 많은 클러스터는 NAT 항목 하나가 인스턴스 비용을 추월하는 일도 흔하다. 이 글은 그 비용을 내리는 가장 확실한 방법인 VPC Endpoint 적용 가이드다.어디부터 손대야 하나VPC Endpoint는 두..

P99 레이턴시가 살짝 튀었다고 한밤중에 페이저가 울리는 경험, 다들 한 번쯤 해봤을 것 같다. 우리 팀도 작년에 SLO를 도입하고 단일 burn rate 알람으로 굴리다가 알람 피로도 때문에 결국 6개월 만에 갈아엎었다. 이번 글에서는 그때 갈아탔던 멀티 윈도우, 멀티 burn rate 방식의 셋업 가이드를 정리해본다. Google SRE workbook에 나온 것을 우리 팀 환경에 맞춰 변형한 버전이고, Prometheus 기반이라면 거의 그대로 쓸 수 있다.단일 burn rate가 왜 안 되냐먼저 단일 윈도우 알람이 왜 망가지는지부터 짚고 가자. SLO 99.9% 가용성을 가정해보자. 30일 기준 에러 버짓은 약 43분이다. burn rate가 1이면 에러 버짓을 정확히 30일에 걸쳐 다 쓰는 속도..

오늘 알게 된 건데, Prometheus 3.8에서 native histogram이 드디어 stable로 올라왔다. 나처럼 몇 년째 "언젠간 써봐야지" 하고 미뤄두신 분들 꽤 있을 것 같아서 짧게 정리해둔다.왜 지금이냐기존 classic histogram 써본 분들은 아마 버킷 설계에서 한 번쯤 멘붕 겪어봤을 거다. 레이턴시 분포가 어떻게 생겼는지도 모르고 le 버킷을 깎아야 하고, 세밀하게 하자니 카디널리티 폭발, 대충 하자니 P99가 거짓말을 한다. 이걸 수년째 "일단 이 정도면 됐지" 하면서 쓰고 있었다.Native histogram은 버킷 경계를 exponential하게 자동 생성한다. 즉 설정 한 줄로 버킷 설계가 끝난다. 거기에 Remote Write 2.0에서 native form 그대로 전..

OpenTofu 1.0이 나온 게 2024년 초였다. 당시 팀에서 "일단 지켜보자"고 결정한 뒤로 약 2년이 지났고, 그 사이에 우리 팀은 한쪽 서비스 군을 OpenTofu로 옮겨봤다. 나머지는 여전히 Terraform이다. 의도한 건 아니고 어쩌다 보니 그렇게 됐는데, 결과적으로는 같은 조직 안에서 둘을 병행 운영하는 꽤 좋은 비교 실험이 됐다.요즘 들어 "이제 OpenTofu로 갈아타야 하는 거 아니냐"는 질문을 사내외에서 자주 받는다. 특히 작년 12월에 IBM이 HashiCorp 인수 마무리하면서 분위기가 또 한 번 바뀌었다. 이 글은 그 질문에 대한 내 나름의 답이다. 결론부터 말하면 "상황에 따라 다르다"는 재미없는 답이 맞는데, 적어도 어떤 상황에서 뭘 고려해야 하는지는 좀 정리가 됐다.2년..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. Terraform 1.10부터 S3 backend에 native state locking이 들어왔다. 그동안 DynamoDB 테이블 하나 따로 만들어서 lock 걸던 그거, 이제 안 해도 된다.우리 팀도 스테이지/프로덕션 합쳐서 DynamoDB lock 테이블 5개를 굴리고 있었는데, 최근에 신규 모듈 정리하면서 이걸 다 걷어냈다. 후기 짧게 남긴다.뭐가 달라졌나기존에는 backend "s3" 블록에 dynamodb_table을 반드시 지정해야 동시성 제어가 됐다. 1.10부터는 use_lockfile = true 한 줄이면 끝. S3 객체 자체에 conditional write로 lock 파일을 만들어 거는 방식이다.terraform { backend..

지난달에 결국 Karpenter로 갈아탔다. 팀에서 반년 넘게 "다음 분기에 해야지" 하며 미뤄왔던 숙제였는데, 예상대로 쉽지 않았다. 이 글은 자랑이 아니라 그냥 기록이다. 비슷한 고민 하는 분들에게 조금이라도 도움이 됐으면 해서 적는다.Karpenter가 v1.0 GA 찍은 지도 벌써 한참 됐고, 최근에는 OCI provider까지 GA 나오면서 더 이상 "AWS 전용 실험 프로젝트" 소리는 못 듣는 상황이다. 그래도 막상 프로덕션에 올려보면 문서에 안 나오는 함정이 꽤 있다.왜 옮겼나솔직히 Cluster Autoscaler(CAS)가 못 쓸 물건은 아니다. 노드 18대 규모에서 몇 년을 잘 돌았다. 문제는 배치 잡 비중이 커지면서부터였다.우리 팀은 데이터 파이프라인 일부가 Kubernetes Job..

클러스터가 3개를 넘어가면서 ArgoCD Application 매니페스트를 하나하나 만들어 관리하는 게 현실적으로 불가능해진 경험이 있을 것이다. dev, staging, production에 각각 마이크로서비스 10개만 배포해도 Application YAML이 30개다. 여기에 리전별 클러스터까지 추가되면 관리 포인트가 기하급수적으로 늘어난다.ArgoCD ApplicationSet Controller는 이 문제를 정면으로 해결한다. 템플릿 하나로 여러 클러스터, 여러 환경에 Application을 자동 생성하고 라이프사이클까지 관리할 수 있다. 이 글에서는 실무에서 바로 적용할 수 있는 ApplicationSet 패턴들을 다룬다.ApplicationSet이 필요한 이유기존 방식에서는 새 클러스터를 추가..

운영 환경에서 Pod가 CrashLoopBackOff에 빠지거나, 네트워크 연결이 안 되거나, 파일시스템 상태를 확인해야 할 때가 있습니다. 문제는 대부분의 프로덕션 컨테이너 이미지에는 curl, dig, netstat 같은 디버깅 도구가 없다는 것입니다.distroless 이미지나 최소화된 Alpine 기반 이미지를 사용하면 보안과 이미지 크기 면에서 이점이 있지만, 장애 상황에서 원인을 파악하기가 까다로워집니다. kubectl debug는 이런 상황을 위해 만들어진 도구입니다.이 글에서는 kubectl debug의 세 가지 모드를 실전 예제와 함께 살펴보겠습니다.Ephemeral Container로 실행 중인 Pod 디버깅가장 많이 쓰이는 패턴입니다. 실행 중인 Pod에 임시 컨테이너(Ephemera..