day-log

resources.limits.memory: 512Mi 한 줄. 이게 사실 얼마나 복잡한 일을 시키는 건지, 최근에 팀 내부에서 OOM 관련 장애를 하나 겪고 나서야 제대로 파봤다. 대충 "커널이 알아서 죽여준다" 수준으로만 알고 있었는데, cgroup v2로 넘어오면서 동작이 꽤 달라졌다는 걸 그제서야 알았다.이 글은 그때 정리한 노트에 가깝다. Kubernetes에서 메모리 limit이 실제로 커널까지 내려가서 어떤 파일에 어떤 값이 쓰이고, OOM이 터질 때 어떤 순서로 뭐가 일어나는지 — 이게 왜 최근 몇 년 사이 근본적으로 바뀌었는지 순서대로 짚어본다.메모리 limit이 커널로 내려가는 경로파드 매니페스트에 limits.memory: 512Mi를 적었다고 하자. 이 값은 kubelet → CRI..

DR 훈련 하다가 죽을 뻔한 이야기. 지난달에 우리 팀은 서울 리전 → 도쿄 리전 Kafka 클러스터 사이 MirrorMaker 2(MM2) 페일오버를 실제로 눌러봤다. 스테이징에서 몇 번 성공했고, 문서에도 "consumer group offset은 자동 translation 된다"라고 되어 있으니까 마음이 편했다.결론부터 말하면, 우리는 특정 컨슈머 그룹에서 메시지 4만 건을 재처리했다. idempotent하게 짜놓은 게 그나마 다행이었지, 안 그랬으면 리포트 팀이 한 달치 데이터를 다시 만들었어야 했다. 그리고 그 원인이 대부분 "offset translation을 너무 믿었다"에서 시작한다.액티브-패시브인데 왜 lag가 음수로 뜨죠우리 구성은 이렇다. 서울(source) → 도쿄(target) 단..

지난 목요일 새벽 두 시. 슬랙에 "prod 배포 30분째 안 끝나요"라는 메시지가 올라왔다. 나는 이미 자고 있었고, 폰 진동에 눈이 번쩍 떠졌다. 노트북을 열어보니 ArgoCD 대시보드가 애매한 상태였다. Application은 Syncing 인데 진행률은 그대로. 사실상 멈춰 있었다.이 글은 그날 새벽에 뭘 삽질했고, 왜 그런 일이 벌어졌는지에 대한 회고다. 결론부터 말하면 sync wave 하나가 조용히 우리 파이프라인을 인질로 잡고 있었다. 최근 ArgoCD 공식 문서와 오퍼레이션 노트를 다시 정리하다 보니 이 삽질담을 남기는 게 낫겠다 싶었다.상황: 어디가 막혔는지도 모르겠다우리 팀은 프로덕션 배포를 GitOps로 굴린다. Argo CD가 이십 몇 개 애플리케이션을 관리하고 있고, 그중 하나가..

오늘 사내 채널에서 후배가 "distroless 컨테이너 파드 안에서 tcpdump 뜨고 싶은데 어떻게 해요?" 라고 물어봐서 답해주다가, 생각보다 kubectl debug --profile 옵션을 모르는 사람이 많다는 걸 알았다. 나도 예전엔 급하면 그냥 securityContext.privileged: true 넣은 사이드카 파드 하나 붙여서 디버깅했는데, 지금은 그럴 필요가 없다.프로필이 뭘 해주냐면kubectl debug로 ephemeral container를 붙일 때 --profile 플래그 하나로 필요한 capability 조합을 미리 세팅해준다. 손으로 securityContext YAML을 쓰지 않아도 된다는 얘기다. 현재 지원되는 프로필은 다섯 개다.general — 일반적인 디버깅용 기..

지난달 새벽 2시 43분에 알람이 울렸다. Redis primary 노드가 죽었다는 알람이었는데, 문제는 Sentinel이 자동 failover를 안 해줬다는 거였다. 5분 정도 쳐다보다가 결국 손으로 promote 시켰다. 서비스는 그 사이 캐시 미스 폭탄으로 DB 커넥션 풀이 다 터졌고, 우리 팀 슬랙에는 "왜 자동 failover가 안 되냐"는 질문이 5개쯤 쌓였다.이 글은 그 원인을 찾아가는 과정과, 결국 뭐가 문제였는지에 대한 회고다.처음 봤을 때우리 구성은 이랬다. Redis 6.2에 primary 1대, replica 2대, Sentinel 3대. Sentinel은 Redis 노드와 같은 VM에 얹혀있었다 (사실 이게 나중에 원흉으로 밝혀진다). quorum은 2로 설정돼 있어서 이론상 Se..

autovacuum 이야기를 하면 대개 두 가지 반응이 나온다. 하나는 "그거 알아서 도는 거 아니냐"고, 다른 하나는 "우린 껐다"다. 둘 다 나름의 이유가 있는데, 결국 내부 동작을 잘 모르는 상태에서 기본값과 부딪히다 지친 사람들의 흔적이다. 사실 autovacuum은 상당히 정교한 스케줄러와 워커 조합이고, 각 파라미터가 어디에 걸려서 동작하는지 알면 튜닝이 아니라 그냥 논리적인 조합 문제가 된다.우리 팀에서는 최근 300GB 규모의 이벤트 로그 테이블에서 autovacuum이 "안 도는 것처럼" 보이는 문제를 파고들었다. 결론부터 말하면 안 돌던 게 아니라 계속 시작했다가 중간에 죽고 있었다. 이 이야기를 하려면 결국 내부 흐름부터 짚고 가야 한다.launcher와 worker의 관계Postgr..

작년 이맘때만 해도 사내에서 "OpenTofu 쓸까요?" 얘기가 나오면 반응은 두 종류였다. "일찍 넘어가는 건 위험하다" 아니면 "어차피 언젠간 넘어갈 텐데". 그 사이에서 결정을 못 하고 시간이 흘렀다.포크된 지 만 3년, BSL 전환 이슈가 터진 지도 그만큼 지났다. 이제는 어느 쪽이든 "지켜본다"라는 답이 힘을 잃었다. Fidelity가 상태 파일 5만 개, 리소스 400만 개를 OpenTofu로 옮겼다는 발표가 올해 초에 나왔고, 우리 팀 슬랙에도 그 링크가 다시 돌았다. 결국 지난달 두 주짜리 스파이크를 잡고 실제로 병행 운영을 해봤다. 그 기록을 정리한다.두 도구가 실제로 얼마나 벌어졌나핵심 CLI 동작만 놓고 보면 plan, apply, import, state mv 같은 워크플로우는 99..

cert-manager 무한 재발급 루프에 걸린 새벽 이야기새벽 3시. 폰이 울린다. 프로덕션 클러스터의 API 게이트웨이 인증서가 만료 2시간 전이라는 알림. 이상하다. cert-manager가 알아서 갱신했어야 정상인데. 눈을 비비면서 노트북을 열었다.처음엔 그냥 일시적인 문제인 줄 알았다kubectl get certificates -A 를 쳐봤다. Ready=False. kubectl describe로 이벤트를 보니 CertificateRequest가 계속 생성되고, 몇 초 뒤에 다시 실패하고, 또 다시 만들고... 초당 한 개꼴로 새 CR이 찍히고 있었다.$ kubectl get certificaterequests -n gateway | wc -l 38473847개. 헛웃음이 나왔다. 이 ..

지난주에 몇 년 방치된 AWS 계정 정리를 맡았다. 상태 파일이랑 실물 리소스가 서로 다른 우주에 있는 그런 계정. 늘 하던 대로 콘솔에서 목록 뽑아서 `terraform import`를 한 줄씩 돌리려다가 옆 팀 시니어가 "요즘 그거 안 써도 돼요, `terraform query` 있잖아요" 하길래 처음 알았다. 지난해 11월 GA된 Terraform 1.14 신규 기능인데, 소문만 들었지 실제로 안 써봤었다. 써보고 나서 후회했다. 이거 진작에 알았어야 했다.`.tfquery.hcl`이 하는 일이름 그대로 새로운 파일 타입이다. 확장자가 `.tfquery.hcl`이어야 인식한다. 안에는 `list` 블록이 들어간다. import 블록이 "이 리소스를 상태로 끌어와줘"라면, list 블록은 "일단 계정..

지난주에 클러스터 두 개 사이에 SPIRE Federation을 붙이려고 하다가 정말 삽질을 오지게 했다. 결국 붙이긴 했는데, 그 과정에서 문서만 봐서는 절대 안 걸리는 함정 몇 개를 밟았다. 다음에 또 이런 걸 세팅할 나 자신을 위한 기록이자, 혹시 지금 SPIRE federation을 붙이려는 분들을 위한 삽질 로그다.상황우리 팀은 원래 단일 EKS 클러스터에서 SPIRE로 워크로드 identity를 발급받아 쓰고 있었다. Istio가 sidecar mTLS에 SPIFFE ID를 쓰고, 몇몇 배치 잡이 Vault 대신 SPIRE-issued SVID로 S3에 접근한다. 잘 돌아갔다.문제는 데이터플랫폼 팀이 별도 계정, 별도 VPC, 별도 EKS 클러스터를 굴리기 시작하면서 시작됐다. 그쪽에서 우리 ..