day-log

작년 말쯤 로그 파이프라인을 다시 손볼 일이 생겼다. 기존엔 모든 노드에 Fluent Bit DaemonSet으로 쓰고 있었는데, 트랜스폼 규칙이 복잡해지면서 Lua 필터가 점점 괴물이 되어가는 게 보였다. 그래서 한쪽 클러스터에 Vector를 시범 도입했고, 결국 6개월 동안 두 도구를 같은 워크로드에 나란히 굴려보게 됐다. 이 글은 그 결과 정리다. 결론부터 말하면, 둘 다 자리가 있다. 다만 자리가 다르다.우리 환경먼저 맥락. 이걸 안 깔면 비교가 의미가 없다.EKS 클러스터 2개, 합쳐서 노드 약 90대 (m6i.2xlarge ~ m7i.4xlarge 혼재)로그 발생량: 평시 평균 35k logs/sec, 피크 110k logs/sec목적지: S3 (장기), OpenSearch (검색), Kafk..

Pod resize, kubelet은 사실 어떻게 하는가 — 1.35 GA 내부 동작작년 12월 1.35에서 in-place pod resize가 드디어 GA로 올라왔다. 1.27 알파(2023년 봄), 1.33 베타(2025년 봄)를 거쳐 약 2년 반 만이다. 베타 시점부터 우리 팀 일부 워크로드에 켜놨고, GA 이후엔 좀 더 적극적으로 쓰고 있다. 그런데 운영하다 보면 "왜 이건 resize가 한 번에 안 되지?", "왜 어떤 컨테이너는 restart 되고 어떤 건 안 되지?" 같은 질문이 자꾸 나온다.사실 내부적으로는 kubelet이 꽤 복잡한 상태 머신을 돌리고 있다. KEP-1287과 1.33/1.35 GA 변경분을 같이 읽어보면 그림이 좀 잡힌다. 이 글에서는 kubelet → CRI → 컨테..

새벽 3시 47분. 핸드폰이 미친 듯이 울렸다.PagerDuty가 동시에 네 건. P99 레이턴시, 5xx 비율, 큐 적체, 그리고 결제 워커 alive 체크 실패까지 줄줄이 빨간색. 잠이 깰 새도 없었다. 노트북을 열고 Grafana부터 켰는데, 노드 수가 떡 하니 23대에서 6대로 떨어져 있었다. 누가 그랬을까. 범인은 나였다. 정확히는, 일주일 전 내가 만진 Karpenter 설정이.무슨 짓을 했길래배경부터. 우리 팀은 EKS에서 Karpenter로 노드를 굴린다. NodePool 두 개 — 일반 워크로드용 default, 그리고 결제/주문 같은 stability-sensitive 워크로드용 payments. 한 달 전쯤 FinOps 압박이 들어왔다. "비용 너무 많이 나온다, 야간에 트래픽 적은 ..

Terraform ephemeral과 write-only, 1년 굴리고 정리한 진짜 사용 패턴작년 이맘때쯤 Terraform 1.10이 나왔고, 그때부터 ephemeral 블록과 write-only 인자를 본격적으로 우리 코드베이스에 섞기 시작했다. 1.11에서 managed resource에도 write-only argument가 들어오면서 본격적으로 "state에서 시크릿을 빼는" 작업을 했고, 지금은 1.15.3까지 와있다. 1년이 지난 지금 다시 보면, 처음에 우리가 잘못 이해하고 있던 것들이 꽤 있었다. 단순히 "state에 안 남는 변수"가 아니라, 라이프사이클 자체가 다른 객체라는 것을 운영하면서야 체감했다.이 글은 "ephemeral이 뭔지 알려주는" 글이 아니다. 그건 hashicorp ..

우리 팀이 자주 쓰는 형태오늘 점심에 동료가 "운영 Pod에 strace 한 번만 떠보면 알 것 같은데 못 들어간다"고 한참 끙끙대길래 옆에서 봤다. distroless 이미지라 shell이 없고, 그렇다고 ephemeral container를 그냥 띄우자니 같은 PID namespace가 아니라 프로세스가 안 보인다는 거였다. 사실 이거 의외로 많이들 모르고 지나가더라.kubectl debug에 --copy-to랑 --share-processes를 같이 주면 거의 다 해결된다. 1.30 GA 이후로 옵션 동작도 안정돼서 운영에서 그냥 쓰면 된다.원본 Pod는 그대로 두고, 동일한 spec의 복제 Pod에 디버그 컨테이너를 끼워넣는 방식. 트래픽 받는 Pod 직접 손대지 않아도 된다.kubectl deb..

KEDA로 Kafka consumer를 오토스케일링하는 건 ScaledObject 하나 적용하면 끝나는 것처럼 보인다. 실제로 키워드만 보면 그렇다. 근데 트래픽 패턴이 살짝만 비대칭이거나 consumer가 commit을 게으르게 하는 순간 스케일러가 엉뚱한 방향으로 움직인다. 우리 팀에서 지난 분기에 partition 24개짜리 topic 두 개를 KEDA 기반으로 옮기면서 정리한 내용을 가이드 형태로 풀어둔다. 최근 KEDA 2.19 기준이다.0. 기본 ScaledObject부터Sarama 기반 기본 스케일러는 deprecated 경고가 종종 뜨므로, 신규 도입이면 apache-kafka 트리거(Go 클라이언트 기반) 쪽을 권장한다. 가장 단순한 형태는 이렇다.apiVersion: keda.sh/v1..

런타임 보안을 도입한다고 하면 결국 두 갈래로 갈린다. Falco를 깔고 SIEM에 알람을 흘릴 거냐, Tetragon으로 정책 위반을 커널 레벨에서 막을 거냐. 우리 팀은 작년에 Falco부터 시작했고, 올해 초부터 일부 클러스터에 Tetragon을 같이 굴리고 있다. 둘 다 한참 써본 뒤 정리한 얘기를 풀어보려고 한다.겉으로 보면 "둘 다 eBPF 쓰는 컨테이너 런타임 보안 툴"인데, 막상 운영하다 보면 결이 꽤 다르다.출발점이 다르다: 감지냐, 차단이냐가장 큰 차이는 단순하다. Falco는 알람을 쏘고, Tetragon은 막는다. 누가 더 좋다는 얘기가 아니다.Falco는 시스템콜과 컨테이너 이벤트를 보고 "이런 일이 벌어졌다"고 통지한다. 비유하자면 CCTV다. 의심스러운 행위가 일어나면 알람을 ..

지난주 목요일 새벽 2시 47분. 알림 톡이 울려서 핸드폰을 봤더니 ArgoCD에서 동시에 11개 애플리케이션의 sync가 Degraded로 떨어졌다는 메시지였다. 처음엔 또 누군가가 이미지 태그를 잘못 박았겠지 싶었다. 새벽에 배포 멘션이 와있던 팀이 두 팀이었고, 자동 sync wave가 한꺼번에 돌고 있었으니까.그런데 콘솔을 열어보니 좀 이상했다. Pod 이벤트에 ImagePullBackOff가 줄줄이 떠있는데, 에러 메시지가 익숙하지 않았다.Failed to pull image ".dkr.ecr.ap-northeast-2.amazonaws.com/svc-foo:v1.42.0":rpc error: code = Unknown desc = failed to pull and unpack image:fai..

오늘 알게 된 건데, 아니 정확히는 어제 새벽 4시쯤 깨달은 건데, absent() 알람을 그냥 쓰면 staleness 때문에 정말 중요한 순간에 침묵할 수 있다. 이거 모르는 분 꽤 많더라. 우리 팀도 6개월째 이 룰을 쓰고 있다가 한 번 데였다.무슨 일이 있었나배치 잡 하나가 죽었다. 정확히는 메트릭을 push하는 사이드카가 OOM으로 재시작되면서 job_last_success_timestamp 시리즈가 사라졌다. 알람 룰은 이렇게 생겼었다.- alert: BatchJobMissing expr: absent(job_last_success_timestamp{job="nightly-etl"}) for: 10m근데 안 울렸다. 왜냐, Prometheus 3.x부터(사실 2.x 후반부터지만) stalen..

지난주 화요일 새벽 2시, 메이저 버전 업그레이드를 한다고 멘션이 와있었고 나는 콘솔 앞에 있었다. 사전 리허설은 두 번 했다. 스위치오버 30초, 길어야 1분. 그런데 실제 작업은 7분 걸렸다. 7분이라는 숫자 자체보다, 그 7분 동안 회사 메인 서비스의 결제 API가 절반쯤 죽어있었다는 게 문제였다.이 글은 그날 무슨 일이 있었는지, 그리고 다음에 같은 작업을 또 한다면 뭘 다르게 할지에 대한 기록이다. AWS 공식 문서나 베스트 프랙티스 글들이 말하지 않는 것들이 좀 있더라.시작은 평범했다대상은 Aurora PostgreSQL 14.10 클러스터다. 14가 2026년 11월에 standard support가 끝난다는 공지가 작년 말에 나왔고, 우리는 6월 안에 16으로 올리기로 했다. 17이 아니라..