day-log

지난주 수요일 새벽이었다. 새벽 2시쯤 자다가 슬랙 멘션 알림에 깼다. "어제 오후 4시부터 지금까지 로그가 안 보여요." 운영팀 야간 담당자였다. 휴대폰 화면 밝기에 눈이 시리면서도 멘탈은 이미 깨어버린 상태. 우리 클러스터는 노드 80대 규모에 Loki 3.7.x를 미러 모드로 돌리고 있었고, 하루에 1.5TB 정도의 로그를 받는다. 그게 7시간 동안 사라졌다는 얘기다.솔직히 처음엔 좀 의심했다. "진짜 7시간 동안 아무도 모를 수가 있나?" 근데 확인해보니 진짜였다. Grafana에서 last 24h로 보면 오후 4시 지점에서 갑자기 라인이 뚝 끊겨 있었다. 그래프가 그렇게 정직하게 끊긴 건 처음 봤다.ingester pod 상태부터 봤다가장 먼저 한 일은 ingester pod의 상태 확인이었다...

새벽에 burn rate 알람이 안 울렸다 — multiwindow SLO 알람 삽질 노트지난주 금요일, 정확히는 토요일 새벽 4시쯤에 한 통의 메시지로 잠에서 깼다. 새벽이라 페이저는 아니었다. 결제 팀 PL이 슬랙 DM으로 "혹시 새벽 2시 ~ 3시 사이에 결제 실패 폭주한 거 알고 있냐"고 물어본 게 시작이었다. 모니터링 알람은 한 통도 받지 못한 상태였다.대시보드를 켜보니 새벽 2시 12분부터 약 32분간 결제 API의 5xx 비율이 8%까지 튀었다가 자연 복구됐다. 우리 SLO는 가용성 99.9%, 즉 한 달에 약 43분의 에러 예산이 전부였다. 사실상 한 번의 사고로 한 달치를 다 태운 거다. 그런데 왜 burn rate 알람이 안 울렸지? 이날 알게 된 multiwindow burn rate..

Distroless 이미지는 좋다. CVE 스캔 결과가 깨끗하고, attack surface가 작고, 이미지 크기도 작다. 그런데 사고가 났을 때가 문제다. sh도 없고 curl도 없고 ls도 없다. 컨테이너 안에 들어가서 뭔가 보고 싶어도 들어갈 수단 자체가 없는 셈이다.kubectl debug 한 줄이면 끝나는 일이긴 하다. -it --image=nicolaka/netshoot --target=app. 이렇게 치면 netshoot 컨테이너가 붙고, ps도 보이고, tcpdump도 된다. 신기하다. 분명히 distroless 컨테이너 안에는 셸이 없는데 어떻게 그 컨테이너의 프로세스를 들여다보고 있는 걸까. 이게 사실 처음 봤을 때 좀 헷갈렸다. 그래서 한번 파봤다.표면적으로는 pod.spec.ephe..

작년 이맘때쯤 우리 팀은 Prometheus 단일 인스턴스로 버티는 게 한계에 다다랐다. 노드 800대, 활성 시리즈 3천만개를 넘기면서 메모리는 80GB를 넘어가고, 재시작 시 WAL 리플레이에 20분이 걸렸다. 장기 저장도 필요했다. 그래서 VictoriaMetrics 클러스터와 Grafana Mimir 두 개를 PoC로 띄워서 6개월씩 돌려봤고, 결국 메인을 VictoriaMetrics로 갔다. 이 글은 그 1년치 의사결정 기록이다.근데 미리 말해두면, 이건 "VM이 무조건 좋다"는 글이 아니다. 우리 팀 상황에 VM이 맞았던 거지, 다른 팀은 Mimir가 더 나을 수 있다. 그 경계가 어디인지 정리해보려고 한다.리소스 사용량 차이가 진짜였다벤치마크 자료들이 "VM이 메모리 5배 효율"이라고 떠드는..

지난 주말에 클러스터 노드 OS 패치 작업이 있었다. 24대짜리 워커 노드를 하나씩 cordon → drain → 재부팅 → uncordon 하는 흔한 작업이다. 자동화 스크립트도 있고, 평소엔 노드 한 대당 5분 정도면 끝난다. 그런데 그날따라 9번째 노드에서 kubectl drain 명령이 멈췄다. 30분이 지나도 진척이 없었다. 새벽 2시였고, 나는 졸린 눈으로 터미널을 노려보고 있었다.일단 진정하고 상태 확인부터drain 로그를 보니 이런 메시지가 반복되고 있었다.evicting pod default/payment-api-7c8d9-x4k2perror when evicting pods/"payment-api-7c8d9-x4k2p" -n default(will retry after 5s): Cann..

ndots가 뭐길래지난주 화요일이었다. 외부 API 호출이 많은 워크로드 하나가 P99 레이턴시가 갑자기 700ms를 넘기 시작했다. APM 그래프를 보니 외부 API 자체는 멀쩡한데 우리 쪽 클라이언트에서 응답을 받기 전까지의 시간이 길었다. 처음엔 또 NAT Gateway냐 싶었는데, 그건 아니었다.원인은 결국 DNS였다. 정확히는 ndots:5 였다. 그리고 그걸 ndots:1로 내리는 한 줄짜리 패치를 만들었다가, 다음날 아침에 멘탈이 나갔다.쿠버네티스에서 파드가 뜨면 /etc/resolv.conf에 기본적으로 이런 게 들어간다.search default.svc.cluster.local svc.cluster.local cluster.localnameserver 10.96.0.10options nd..

지난달에 우리 팀이 운영하던 EKS 클러스터 두 개를 Auto Mode로 갈아탔다. "노드 관리 안 해도 된다", "Karpenter 직접 안 만져도 된다", 이런 얘기 듣고 한 달만에 슬쩍 옮긴 건데, 첫 달 청구서 받고 멘탈이 살짝 나갔다. 결론부터 말하면 망한 건 아니다. 다만 예상하고 옮긴 그림이랑은 꽤 달랐다는 얘기다.어떻게 옮겼나원래 우리 클러스터는 Karpenter 0.37로 NodePool 4개 돌리고 있었다. 일반 워크로드, batch job용 spot, GPU 추론, 그리고 좀 큰 메모리 잡아먹는 streaming consumer용. 인스턴스 타입은 직접 골랐다. m6i.2xlarge, r6i.4xlarge, g5.xlarge 이런 식으로. 한 1년 운영하면서 어떤 패밀리가 어디에 잘 ..

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

새벽 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 \ -..

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