Ops Insights

01 Claude Code 관측 — OTel 내보내기·대시보드·백필

Tue, 08 Sep 2026 00:00:00 +0000

Claude Code 관측 — 토큰이 어디로 새는지 숫자로 보기

홈랩 개발환경 편의 code-server 터미널에서 하루 종일 Claude Code를 돌립니다. 얼마를 쓰는지는 /cost로 그때그때 볼 수 있지만, 어느 에이전트가 먹는지, 세션을 새로 열 때마다 얼마가 고정비로 나가는지, 훅이 몇 분을 잡아먹는지는 안 보입니다. 이 글은 그걸 hub 클러스터의 관측 스택(VictoriaMetrics·VictoriaLogs·Tempo·Grafana)으로 끌어온 하루치 기록입니다. 공식 문서는 monitoring-usage 한 장이고, 실제로 발목을 잡은 건 문서 밖에 있었습니다.

우리 배포 형상 — 자체 RUM 컨버터·6 실행 단위·stage/prod 격차

Thu, 13 Aug 2026 00:00:00 +0000

우리 배포 형상 — 자체 RUM 컨버터·6 실행 단위·stage/prod 격차

우리가 실제로 돌리는 것은 표준 조립에 컴포넌트 하나가 더 붙은 형상입니다.

HyperDX / ClickStack 심층 분석

Mon, 13 Jul 2026 00:00:00 +0000

HyperDX / ClickStack 심층 분석 — RUM/플랫폼 도입 실사

웹 RUM 대체 후보로는 사실상 유일하지만 OSS 접근통제 공백(SSO·RBAC·멀티테넌시·감사로그 전무)이 다중 팀 도입의 결정적 게이트입니다.
3 코어(ClickHouse·HyperDX·OTel Collector)에 메타데이터 전용 MongoDB가 필수 의존성으로 붙습니다. 자체(self-hosted) ClickHouse에 연결하는 ‘HyperDX Only’ 모드에서도 사라지지 않습니다.
배포 6모드 중 프로덕션 적합은 Managed 또는 Helm뿐이고 자체 인프라를 지키려면 HyperDX Only가 정답 축입니다.
기능 성숙도: 로그검색·트레이스·웹 세션 리플레이는 🟢, 모바일 RUM은 🔴(네이티브 리플레이 없음), 메트릭은 🟡(PromQL은 실험 기능이며 기본 비활성).
RBAC는 Managed(ClickHouse Cloud) 전용으로만 GA됐고 OSS는 SSO/RBAC/멀티테넌시/감사로그가 전무합니다. self-host를 고수하려면 oauth2-proxy·팀별 인스턴스·row policy를 조합해야 합니다.

HyperDX/ClickStack을 “Datadog RUM 대체 + 통합 관측성 플랫폼” 후보로 도입할 때의 실사(due-diligence) 페이지입니다. “로그 스토어 선택지로서의 요약 판단"은 로깅 챕터의 HyperDX / ClickStack가 이미 다루므로 강점·약점은 다시 늘어놓지 않습니다. 이 페이지는 도입 결정에 필요한 팩트 — 연혁·아키텍처·배포 모드·기능 성숙도·라이선스·거버넌스 갭 — 을 플랫폼 실사 관점에서 심화합니다.

Datadog RUM 커버리지 — 어디까지 대체되나

Mon, 13 Jul 2026 00:00:00 +0000

Datadog RUM 커버리지 — 어디까지 대체되나

RUM을 하나로 묶어 “대체된다/안 된다"고 답하면 틀립니다 — 성격이 다른 하위 제품 4개로 쪼개야 판정이 섭니다.
RUM-Core(세션 리플레이+CWV 수집/에러+트레이스 상관) 🟢 PoC(Wave 1) · RUM-Frustration 🟡 SQL 사후계산 · RUM-PA(퍼널/리텐션) 🔴 자작/PostHog 병행 · RUM-Mobile 🔴 OTel+Embrace/OpenReplay.
대체는 프록시가 아니라 @hyperdx/browser SDK 교체입니다 — datadogreceiver는 브라우저 RUM intake(/api/v2/rum)를 아예 수신하지 않습니다.
좌절 신호·모바일 리플레이는 네이티브 프리미티브가 없다고 확인했습니다(추측 격상 아님) — ClickHouse SQL(sequenceMatch/windowFunnel) 자작 또는 전용 툴이 필요합니다.
“Datadog RUM을 HyperDX로 대체한 공개 프로덕션 사례"는 찾지 못했습니다 → dual-instrument PoC 성공을 Wave 1 진입 게이트로 명문화합니다.

“coverage가 어디까지 되나"에 답하는 페이지입니다. HyperDX 심층 실사가 플랫폼 관점(연혁·아키텍처·거버넌스 갭)을 다뤘다면 여기서는 Datadog RUM의 기능을 하나씩 @hyperdx/browser와 대조해 어디까지 1:1로 넘어오고 어디서 끊기는지를 확정합니다.

Datadog 프로토콜 프록시 매핑

Mon, 13 Jul 2026 00:00:00 +0000

Datadog 프로토콜 프록시 매핑 — 어디까지 성립하나

프록시는 Agent intake(로그·인프라 메트릭·APM 트레이스)에서만 성립하고 브라우저 RUM·세션 리플레이 intake에는 성립하지 않습니다 — RUM은 @hyperdx/browser SDK 교체가 정답입니다.
성립하는 영역조차 datadogreceiver가 전 신호 alpha라 과도기 무중단 브릿지로만 쓸 만하고 영구 아키텍처로는 맞지 않습니다.
dd browser-sdk의 proxy 옵션은 트래픽을 우회시키는 진입점일 뿐 변환용은 아닙니다 — 본문 불변(바이너리 그대로 포워딩)이 설계 전제입니다.
변환 계층은 native 대비 최대 ~200배 CPU, delta 메트릭 30~70% 손실(#44907) 등 fidelity 결함이 실증됐습니다.
“dd 인테이크를 ClickHouse/HyperDX로 변환해 프로덕션 운영한다"는 회사명이 붙은 1차 사례를 찾지 못했습니다.

“dd agent/dd-trace 오픈소스 코드를 참조해 Datadog 인테이크 트래픽을 그대로 받아 HyperDX/ClickHouse로 변환하는 프록시 계층"을 직접 만들 수 있는지 검증합니다. 결론부터: 프록시는 Agent intake(로그·인프라 메트릭·APM 트레이스)에서만 성립하고 브라우저 RUM·세션 리플레이 intake에는 성립하지 않습니다. RUM은 SDK 교체가 정답입니다(Datadog RUM 커버리지). 로그/메트릭/APM에서 성립하는 프록시도 과도기 무중단 브릿지까지만 합당하고 영구 아키텍처로 두기엔 무리입니다 — 성숙도(alpha), 변환 CPU 세금, 프로덕션 전례 부재 때문입니다.

Datadog 전 제품군 대체 매트릭스

Mon, 13 Jul 2026 00:00:00 +0000

Datadog 전 제품군 대체 매트릭스 — RUM 너머로 확장하기

HyperDX/ClickStack은 Datadog의 MELT+세션리플레이 코어(Logs·Traces·RUM 웹코어·Session Replay)를 커버하지만 나머지 절반(Security·Synthetics·NPM/DBM·CI·On-Call 등)은 범위 밖 — 전용 OSS 개별 이관 또는 Datadog 잔류.
메트릭 계층은 VictoriaMetrics+Grafana로 분리합니다 — HyperDX의 PromQL은 실험 기능이고 일반 otel_metrics_*에 자동 적용되지 않으며 ClickHouse SQL을 겨냥한 변환기도 없습니다.
Wave 이관: 1 RUM웹코어 → 2 Logs → 3 APM → 4 Metrics(VM) → 5 나머지 개별. Wave 4를 HyperDX로 잡으면 공수가 2~4배 팽창합니다.
절감은 대부분 스토리지 이관에서 나오지만 host high-water mark·custom metrics tax 같은 과금 함정과 인건비 상쇄를 함께 계산해야 합니다.
Grafana OnCall OSS는 2026-03-24 아카이브 예정이므로 On-Call 대안으로 신규 채택하지 않습니다.

RUM 하나만 빼오는 것으로는 Datadog 청구서가 크게 줄지 않습니다. RUM은 진입점이고 실제 절감은 로그·트레이스·메트릭 “스토리지"를 옮길 때 나옵니다. 이 페이지는 웹 RUM 내재화(RUM 대체 커버리지)를 넘어 Datadog 전 제품군을 어디까지, 무엇으로 대체하는가를 의사결정 관점에서 정리합니다.

마이그레이션 로드맵

Mon, 13 Jul 2026 00:00:00 +0000

마이그레이션 로드맵 — Datadog 이관 실행 계획

이 로드맵은 2026-07의 표준 SDK 교체·로컬 NVMe 전제에 따른 계획입니다. 아래 체크리스트는 실행 완료 기록이 아닙니다. 이후의 우리 배포 형상은 자체 RUM 컨버터·EBS 기반 stage를 기록하므로 그 경로에 맞춰 검증 항목을 조정해야 합니다. 2026-09의 PromQL·Terraform·Datadog 수신 변경은 커버리지 재판정을 기준으로 읽습니다.

RUM 참고 자료

Mon, 13 Jul 2026 00:00:00 +0000

출처 — RUM 섹션 조사 문서 원본 링크

RUM 섹션(01~~05)의 근거는 research/hyperdx-clickhouse/ 아래 조사 문서 8개입니다 — 01-hyperdx-deep-dive, 02-rum-replacement, 03-datadog-replacement-matrix, 07-recommendation, 08-supplement-1~~2·4~5. 이 페이지는 그 문서들의 “## 출처” 섹션에 나열된 URL을 전부 모아 중복을 걷어내고 주제별로 재정리했습니다. 개별 URL이 본문 어느 주장을 뒷받침하는지는 각 조사 문서를 직접 대조해야 합니다. 이 페이지는 색인 목적으로만 씁니다. HyperDX의 MongoDB(07)는 별도 딥리서치(3-vote 적대검증, 2026-07-15) 기반입니다. 그 근거 URL도 아래 표에 포함했습니다. 조사 기준 2026-07.

HyperDX 커버리지 재판정 — Datadog 대비 2026-09

Tue, 08 Sep 2026 00:00:00 +0000

HyperDX 커버리지 재판정 — Datadog 대비 2026-09

HyperDX의 Datadog 대체 범위는 넓어졌습니다. PromQL은 실험적 경로가 생겼고, Terraform은 셀프호스트도 지원하는 Beta입니다. 알림 평가 이력과 그룹별 발화도 있습니다.
Datadog Agent의 로그·메트릭·트레이스를 받는 것과 Datadog RUM·세션 리플레이·모니터 설정을 그대로 옮기는 것은 별도 문제입니다.
이 글은 2026-09-08에 확인한 공식 문서·upstream 소스 기준입니다. 우리 배포의 이미지 버전과 자체 컨버터를 실행 검증한 결과는 아닙니다.

플랫폼 심층 분석, RUM 커버리지, 전 제품군 대체 매트릭스의 2026-07 조사에서 바뀐 판단을 정리합니다. 기능의 존재, Datadog과의 동등성, 우리 배포에서의 가용성을 따로 확인합니다.

S3 계정 간 복사 — aws s3 sync · rclone · rsync

Mon, 07 Sep 2026 00:00:00 +0000

01 · 계정 간 복사 — aws s3 sync · rclone · rsync는 어디서 갈리나

rsync는 선택지가 아니다. S3 API를 모르니 FUSE 마운트가 필요하고 그 위에서는 델타 전송·rename·mtime이 전부 무너진다.
소규모 일회성 복사는 aws s3 sync. 서버사이드 CopyObject라 데이터가 내 머신을 거치지 않고 같은 리전이면 요청 요금만 낸다.
객체 수십만 개 이상이거나 반복 동기화면 rclone. 단 --server-side-across-configs가 없으면 에러 없이 다운로드→업로드로 돌아서고 mtime 비교는 객체마다 HEAD를 한 번씩 더 부른다.
셋 다 현재 버전만 옮기고 태그·ACL·스토리지 클래스는 도구마다 다르게 잃는다. 버전 이력까지 보존해야 하면 S3 Replication(Batch Replication)으로 간다.
계정 간이면 도구와 무관하게 SSE-KMS 키 정책과 Object Ownership 설정이 먼저 걸린다.

기준일은 2026-09-07, 요금은 버지니아 북부(us-east-1) S3 Standard 기준입니다.

이 사이트에 대하여

Sun, 30 Aug 2026 00:00:00 +0000

누가 쓰나

Mont(mont kim)이 씁니다. EKS 위에서 Istio·Karpenter·VictoriaMetrics·ClickHouse·HyperDX 같은 것을 운영하며 남긴 기록이 중심입니다. 같은 사람이 쓰는 블로그는 makgol.com이고, 프로필은 makgol.com/about에 있습니다.

Prometheus가 하지 않는 일

Sun, 30 Aug 2026 00:00:00 +0000

Prometheus가 하지 않는 일 — 리텐션의 경계

Prometheus 리텐션을 늘려 장기 보관을 해결하려다 보면 곧 벽을 만납니다. 기간을 늘리면 용량이 선형으로 늡니다. 해상도를 깎아 완만하게 만들 방법이 Prometheus 안에는 없습니다.

Thanos Compactor가 채우는 자리

Sun, 30 Aug 2026 00:00:00 +0000

Thanos Compactor가 채우는 자리 — 다운샘플링의 실제 동작

Prometheus에 없는 해상도 티어링은 Thanos Compactor가 맡습니다. 오브젝트 스토리지 버킷을 훑으면서 블록을 병합하고 해상도를 깎은 블록을 새로 만들고 만료된 블록을 지웁니다.

Sidecar vs Receive

Sun, 30 Aug 2026 00:00:00 +0000

Prometheus에 붙이는 두 방식 — Sidecar vs Receive

“Thanos를 붙인다"는 한마디가 전혀 다른 배치 둘을 가리킵니다. 어느 쪽을 고르느냐에 따라 방화벽 정책과 장애 반경이 달라집니다.

VictoriaMetrics에 Thanos를 붙일 수 있나

Sun, 30 Aug 2026 00:00:00 +0000

VictoriaMetrics에 Thanos를 붙일 수 있나

“Prometheus를 VictoriaMetrics로 바꾸고 뒤에 Thanos를 붙여 S3 장기 보관을 한다"는 그림이 자연스러워 보입니다. 성립하지 않습니다.

Receive 실전 구성

Sun, 30 Aug 2026 00:00:00 +0000

Thanos Receive 실전 구성

앞 문서들의 결론을 배치로 옮깁니다. 파드 넷이 뜹니다 — Receive, Compactor, Store Gateway, Querier. 여기에 캐시를 붙이면 다섯입니다.

vmagent / Prometheus(agent) ──remote write──▶ Receive (로컬 TSDB → 2h마다 업로드)
│
▼
오브젝트 스토리지
▲
Compactor (병합·다운샘플·리텐션, 싱글턴)
│
Grafana ◀── Querier ◀── Store Gateway ────────────┘
└────── Receive (최근 구간)

버킷 설정 (공통)

네 컴포넌트가 같은 파일을 Secret으로 마운트합니다.

Thanos·VM·Mimir 선택 가이드

Sun, 30 Aug 2026 00:00:00 +0000

무엇을 고를 것인가

앞의 다섯 문서를 판단 순서로 압축합니다.

첫 질문 — 해상도 티어링이 정말 필요한가

필요 없을 수 있습니다. 카디널리티가 크지 않으면 raw를 그대로 오래 들고 가는 편이 단순하고 쌉니다.

JVM vs GraalVM

Sat, 29 Aug 2026 00:00:00 +0000

01 · JVM vs GraalVM — 시동을 사면 무엇으로 값을 치르나

지도가 2025년 9월에 바뀌었습니다. Graal JIT은 Oracle JDK 24가 마지막이고 JDK 25에서 빠졌습니다. Native Image도 Java SE 구독의 지원 범위에서 제외됐고 Oracle은 같은 목표를 Project Leyden으로 가져갔습니다. 기술이 죽은 건 아니지만 “중간 지대"였던 Graal JIT은 실제로 사라졌습니다.
“Native Image가 C2보다 빠르다"는 유료 전제 위에 서 있습니다. Oracle의 Petclinic 수치(13,075 vs 12,488 req/s)는 PGO와 G1을 켠 조합인데 둘 다 Community Edition에는 빠져 있습니다. CE + Serial GC + PGO 없음이라는 실제 오픈소스 조합의 공개 수치는 어느 벤더 자료에도 없습니다.
CE Native Image는 Serial GC 고정입니다. 기본 최대 힙이 물리 메모리의 80%(G1은 25%)이고 문서가 “GC 중 RSS가 최대 힙의 2배까지 일시 증가할 수 있어 컨테이너에서 문제가 된다"고 직접 경고합니다. -Xmx를 지정하지 않으면 컨테이너에서 터집니다.
동시성 논쟁의 실제 변수는 실행 모델이 아니라 acceptor입니다. 6만 연결 실측에서 Tomcat은 CPU 20%인 채로 2만에서 99.9% 실패했습니다. TCP 연결을 받아들이는 쪽이 먼저 막혔고 처리 능력은 남아 있었습니다.
리액티브가 메모리에 유리하다는 통념은 조건부입니다. 같은 실측에서 1.6KB 응답으로 바꾸자 WebFlux는 GC에 108초를 쓰며 P50이 1.17초로 무너졌고 가상 스레드가 31% 더 처리했습니다.
시동만 문제라면 런타임을 안 바꾸는 답이 생겼습니다. JDK 24/25의 AOT 캐시는 Spring PetClinic 시동을 4.486초에서 2.604초로 줄이면서(42%) JIT을 그대로 둡니다.

회사에서 런타임을 바꿔보자는 말이 나오는 이유는 대개 비슷합니다. 시동이 느리다, 메모리를 많이 먹는다, 오토스케일이 붙을 때마다 처음 몇 초가 아프다. 그래서 GraalVM을 꺼내 봅니다.

Python 워커 16개 vs 워커 2 + 스레드 32

Sat, 29 Aug 2026 00:00:00 +0000

02 · 워커 16개 vs 워커 2개 + 스레드 32개 — 무엇이 정말 달라지나

--threads 32를 주는 순간 워커 클래스가 통째로 바뀝니다. gunicorn 문서가 명시합니다 — “If you try to use the sync worker type and set the threads setting to more than 1, the gthread worker type will be used instead.” “동기 워커에 스레드를 붙였다"는 표현부터 성립하지 않습니다.
최대 처리량은 거의 같습니다. 같은 CPU limit 아래에서 두 배치의 상한은 둘 다 limit ÷ 요청당 CPU 시간입니다. 달라지는 건 그 상한에 어떻게 도달하는지, 상한을 넘긴 부하가 어디에 쌓이는지입니다.
스레드 32개가 실제로 겹치는 건 GIL을 놓는 구간뿐입니다. DB 대기와 외부 HTTP는 GIL 밖이고 ORM이 행을 객체로 바꾸는 순간부터 직렬화·템플릿까지는 전부 GIL 안입니다. 그래서 이득은 요청 시간에서 대기가 차지하는 비중에 정비례합니다.
--timeout의 의미가 달라집니다. 동기 워커에서는 사실상 요청 상한이지만 gthread에서는 “프로세스가 살아 있다"는 신호일 뿐입니다. 옮겨 심지 않으면 요청 상한이 사라집니다.
“느린 요청 하나가 그 워커의 후속을 막는다"는 서술은 기본 설정에서 틀렸습니다. 커널 accept 큐가 하나라 워커에 미리 배정된 후속 요청이 없습니다. 오히려 gthread가 커넥션을 미리 집어가면서 그 한 줄을 워커 수만큼 쪼갭니다.
장애 반경이 16배 차이 납니다. 워커 하나가 죽을 때 잃는 것은 (A)에서 요청 1개, (B)에서 최대 32개 + 그 워커가 물고 있던 keep-alive 커넥션 전부입니다.
스레드는 동시성을 늘리지 durability를 만들지 않습니다. Celery의 대체재가 아닙니다. 순서가 반대입니다 — Celery로 무거운 작업을 빼야 (B)가 유리해지는 조건이 만들어집니다.

같은 파드, 같은 CPU limit에서 두 배치를 놓고 고민하는 상황입니다.

Python GIL × CPU Limit

Thu, 06 Aug 2026 00:00:00 +0000

06 · Python GIL × CPU Limit — “1코어 런타임"은 왜 잘리는가

GIL은 성능 장치가 아니라 뮤텍스입니다. 바이트코드를 실행하는 스레드가 한 순간에 하나뿐이므로 순수 파이썬 프로세스의 CPU 소비는 정의상 코어 하나 분을 넘지 못합니다 — limit이 1코어 이상이면 바이트코드만으로는 스로틀이 성립하지 않습니다.
CFS quota는 “코어당 지분"이 아니라 시간 예산 풀입니다. 4코어 노드의 limit 1이 “코어마다 25%씩"을 뜻하지는 않습니다. 실행할 스레드가 있는 런큐만 전역 풀에서 5ms 슬라이스를 꺼내가는 구조입니다.
그런데도 실제 파이썬 컨테이너는 잘립니다. 경로는 네 갈래입니다 — 워커 프로세스 다중화 · GIL을 놓는 네이티브 스레드풀 · 1코어 미만 limit의 슬라이스 입도 · free-threading. 현행 커널의 파이썬 스로틀 사고는 전부 여기 속합니다.
잘리면 더 아픕니다. throttle은 per-CPU 단위라 GIL 홀더가 있는 코어만 잘려도 프로세스 전체가 유저스페이스에서 멈춥니다. 커널은 이 문제의 커널 락 버전을 고치는 중이지만 GIL은 유저스페이스 락이라 보호 밖입니다.
Python은 Go 1.25와 달리 cgroup을 안 봅니다. os.cpu_count()는 노드 코어 수를 돌려주고 3.13의 해법(PYTHON_CPU_COUNT)도 수동 주입입니다. 처방은 전부 배포 파이프라인의 몫입니다.

왜 이 문서가 따로 있나. 02 CPU Throttling이 “스로틀이 무엇이고, 어떻게 보이고, 무엇으로 대응하나"를 다룬다면 이 문서는 같은 문제를 언어 런타임 쪽에서 봅니다. 파이썬의 GIL은 두 개의 그럴듯한 오해를 만듭니다 — “GIL은 1코어를 갈구도록 설계된 구조다"와 “limit 1은 4코어에서 25%씩 배급받는다는 뜻이다”. 이 문서는 두 오해를 커널·CPython 소스 수준에서 바로잡고 그 위에서 “그런데 왜 실제 파이썬 컨테이너는 잘리는가"를 답합니다. 02 §4의 런타임 표(Go·JVM·Node.js)에서 비어 있던 Python 행이 이 문서입니다.

01 승격 이전 — step과 AnalysisRun

Fri, 28 Aug 2026 00:00:00 +0000

승격 이전 — step과 AnalysisRun

Rollout에서 “승격(promotion)“이 하는 일은 하나입니다. status.stableRS를 새 ReplicaSet의 pod-template-hash로 바꾸는 것. 그 한 줄이 일어나기 전까지의 모든 구간이 step입니다.

02 롤백이 스스로를 취소한다

Fri, 28 Aug 2026 00:00:00 +0000

롤백이 스스로를 취소한다

롤백은 컨트롤러에게 새 rollout입니다. 이 한 문장에서 사고 두 건이 나옵니다.

첫 번째는 롤백이 취소되는 것입니다. 새 rollout이니 AnalysisRun이 새로 붙습니다. 인시던트 중이라 오류율은 아직 높습니다. 되돌리려는 행위가 판정에 걸려 abort됩니다.

03 그래서 무엇을 할 것인가

Fri, 28 Aug 2026 00:00:00 +0000

그래서 무엇을 할 것인가

2부는 기전으로 끝났습니다. rollbackWindow가 인덱스를 스텝 끝으로 던지고 역탐색이 방금 건너뛴 마지막 setWeight: 100을 도로 집어오고 가용량 게이트는 canary를 보지 않는다는 것까지.

02 개발환경 — 브라우저와 아이패드

Tue, 25 Aug 2026 00:00:00 +0000

개발환경 — 터미널 하나를 어디서든 같은 자리로 연다

앞 편은 클러스터 쪽 이야기였습니다. 이번엔 그 클러스터 위에서 제가 실제로 코드를 만지는 자리를 다룹니다. 한 문장으로 줄이면 hub 클러스터에 code-server를 pod로 띄워 두고 노트북이든 데스크탑이든 브라우저로 들어가 그 터미널에 앉는 구조입니다. 같은 터미널에 아이패드로도 붙습니다. 이 글도 그 터미널 안에서 쓰고 있습니다.

01 hub/edge 2-클러스터 구조

Thu, 20 Aug 2026 00:00:00 +0000

hub / edge — 스토리지 없는 클러스터를 스포크로 두는 홈랩

홈랩 클러스터가 두 집에 걸쳐 두 개입니다. 하나는 지금 사는 집, 하나는 본가. 오랫동안 이 둘을 stage / prod라고 불러왔는데, 어느 순간부터 이 이름이 거짓말을 하고 있었습니다. “prod"라던 본가 클러스터는 스토리지도 없이 서버만 켜져 있고 “stage"라던 현재 집이 노드 2대에 시놀로지까지 붙은 실질적 중앙이었으니까. 이름과 실체가 어긋나면 도메인 매핑을 매번 머릿속에서 뒤집어야 합니다. 실제로 과거에 stage/prod 도메인이 한 번 스왑된 이력까지 있어서 혼동이 잦았습니다.

레이어 1 — 클러스터 파라미터와 가변성 3분류

Sat, 15 Aug 2026 00:00:00 +0000

레이어 1 — 클러스터 파라미터와 가변성 3분류

finance blue를 만들 때 정해둘 것 셋 — upgradePolicy.supportType = STANDARD(기본값이 EXTENDED입니다), deletionProtection = true, 그리고 serviceIpv4Cidr·ipFamily·bootstrapClusterCreatorAdminPermissions. 뒤 셋은 지금 틀리면 재생성뿐입니다.
최상위 29개 파라미터는 create-only 8 · 단방향 불가역 6 · day-2 가변 15로 갈립니다(§1).
upgradePolicy.supportType 기본값은 EXTENDED입니다. 명시하지 않으면 표준지원 종료일부터 시간당 $0.60이 자동으로 붙고 확장지원에 실제로 진입한 뒤에는 STANDARD로 못 돌아옵니다(§4).
되돌릴 수 없는 문 넷 — controlPlaneEgressMode(CUSTOMER_ROUTED 진입), encryptionConfig(DisassociateEncryptionConfig API가 아예 없습니다), authenticationMode(전진만), ipFamily(생성 시 영구 고정)(§2).
Terraform은 되돌리기를 클러스터 재생성으로 모델링합니다 — plan에 뜨는 # forces replacement는 버그가 아니라 안전장치입니다(§3).
버전은 2026-07부터 되돌릴 수 있습니다(7일 창·마이너 1단계·컨트롤 플레인만). 단 --force는 PDB도 어드미션 웹훅도 우회하지 않습니다(§5).

이 페이지가 다루는 범위는 CreateCluster·UpdateClusterConfig·UpdateClusterVersion이 받는 클러스터 레벨 최상위 필드입니다. 판정하는 것은 하나뿐입니다. 그 값을 언제 정할 수 있고 정한 뒤에 되돌릴 수 있는가. 2026-08에 새로 열린 컨트롤 플레인 컴포넌트 파라미터의 내부 동작과 튜닝 판단은 레이어 2, 용량 축인 Provisioned Control Plane 티어는 용량 축, 애초에 손댈 수 없는 영역은 레이어 3이 갖습니다.

2,000노드 Valkey — 무엇이 먼저 부러지는가

Thu, 06 Aug 2026 00:00:00 +0000

01 · 2,000노드 Valkey — 무엇이 먼저 부러지고, 그중 무엇이 Kubernetes로 넘어오는가

간판 수치는 Kubernetes에서 잰 게 아닙니다. 2,000노드·1B RPS의 서면판인 valkey.io 블로그 원문에 Kubernetes·pod·StatefulSet·container가 한 번도 나오지 않고, 실험대는 r7g.2xlarge(8코어/64GB) 클러스터 + 부하 생성기 c7g.16xlarge 750대였습니다. 발표 시작 13초에 본인들이 “we come from Amazon, which is mostly a VM based world“라고 밝힙니다.
그래도 엔진 수정 4건은 인프라와 무관하게 넘어옵니다. #654·#1018·#2154·#2277은 배포 방식이 아니라 cluster bus 코드 안에 들어갔습니다. 버전만 맞추면 됩니다. 각각 8.0 / 8.1 / 9.0 / 9.0.
CPU 100% 그래프를 클러스터 전체로 읽으면 틀립니다. 슬라이드에서 천장에 붙는 계열은 engine_cpu_percent_p99고 같은 차트의 p90·avg는 한 자릿수입니다(스냅샷 p90 6.2 / avg 5.80). 발표자 노트는 포화 범위를 “atleast 5% of the nodes”(오타는 원문 그대로)라 적습니다. 하한이지 점추정이 아닙니다. 2,000노드가 전부 탄 게 아니라 최소 100대가 탔다는 뜻이고, 발표는 이 구분을 하지 않습니다.
Kubernetes 조언 중 실측이 뒷받침하는 건 사실상 하나입니다. CPU limit을 걸지 마라. 나머지(StatefulSet, headless service 부트스트랩, IP 직결, AZ 분산)는 전부 경험칙이고 발표에 수치가 붙지 않습니다.
operator는 아직 도입 대상이 아닙니다. API가 v1alpha1이고 README가 “not ready for production use"라고 명시하며 scale-out/in에 Valkey 9.0+를 요구합니다. 그런데 spec.shards는 진짜 최상위 필드라 Q&A의 “shard가 first-class” 주장 자체는 맞습니다.
2,000노드에서 먼저 부러지는 건 처리량이 아니라 장애 복구입니다. 정상 상태 gossip 비용은 노드 수에 선형이었고, 터진 곳은 전부 primary를 수백 개씩 한 번에 죽였을 때의 재접속(415~455 kill)·failure report(499 kill)·투표 경로였습니다.

왜 이 문서인가. 발표 제목은 Kubernetes at XL Scale인데 간판 수치인 2,000노드 / 1B RPS는 EC2에서 나왔습니다. 그래서 이 문서는 발표가 증명한 것(엔진 한계와 그 수정)과 조언에 그친 것(Kubernetes 배치·리소스)을 나눠 놓고, 그중 무엇이 Kubernetes로 전이되는지만 남깁니다. 검증 기준은 발표 전사(942줄), 발표자 노트가 붙은 슬라이드 원본 54장, valkey.io 블로그, 업스트림 PR 4건, valkey.conf unstable 브랜치입니다.

Redis 581샤드를 무중단으로 Kubernetes에 올리기

Thu, 06 Aug 2026 00:00:00 +0000

01 · Redis 581샤드를 무중단으로 Kubernetes에 올리기 — 그리고 90%라는 숫자의 진실

한눈에

문제의 형태 — API Gateway를 떠나는 진짜 이유

Thu, 06 Aug 2026 00:00:00 +0000

01 · 문제의 형태 — API Gateway를 떠나는 진짜 이유

Connection duration for WebSocket API: 2 hours · Can be increased: No. 이 전환의 유일한 논거입니다. 상시 연결이 전제인 단말에 2시간마다 강제 종료가 걸립니다.
비용 논거는 성립하지 않습니다. 5만 대 상시 연결의 connection-minutes는 월 $540입니다. “비싸서 나간다"고 쓰면 첫 질문에서 무너집니다. 싸지만 맞지 않습니다.
2시간 종료의 비용은 쿼터에서 나오지 않습니다. 재접속률 자체는 초당 7건으로 500/s 쿼터의 1.4%에 불과합니다. 재개 메커니즘이 없으면 2시간마다 5만 대가 전량 재동기화합니다. 그게 실제 비용입니다.
Idle Connection Timeout: 10 minutes도 상향 불가라 하트비트를 뺄 선택지가 없습니다. 자체 구현으로 옮겨도 이 제약은 없어지지 않고 LB idle timeout으로 이름만 바뀝니다.
프레임 32KB / 페이로드 128KB. 초과하면 에러 응답 대신 close code 1009로 연결이 끊깁니다. 페이로드가 자랄 여지가 있으면 이 상한에 언제 걸릴지 알 수 없습니다.
흐름이 일방향이면 WebSocket의 양방향성은 안 쓰는 기능입니다. SSE로 내려가면 재연결과 재개(Last-Event-ID)가 프로토콜에 내장되어 따라옵니다. WebSocket에서는 전부 직접 만들어야 하는 것들입니다.

왜 이 문서인가. 전환 검토서의 첫 문장이 “API Gateway가 비싸서"이면 그 검토는 거기서 끝납니다. 실제로 계산해보면 쌉니다. 이 문서는 떠나야 하는 이유를 하나로 좁히고 자체 구현으로 넘어갔을 때 따라오는 제약과 없어지는 제약을 구분합니다. 검증 기준: AWS 공식 쿼터 표, API Gateway 요금표, WHATWG HTML 명세의 server-sent events 절.

2009 첫 커밋부터 6.2 까지

Thu, 06 Aug 2026 00:00:00 +0000

01 · 자료구조 서버는 왜 이렇게 생겼나 — 2009 첫 커밋부터 6.2 까지

최초 문제는 “캐시가 필요하다"가 아니라 “값이 blob 이면 안 된다"였습니다. 첫 커밋에 동봉된 FAQ 가 프로젝트 시작 이유를 한 줄로 적습니다 — In order to scale LLOOGG.(redis ed9b544e1:doc/FAQ.html) 같은 커밋의 doc/README.html 은 memcached 와의 차이를 자료형과 영속성 두 축으로만 설명합니다 ✓
첫 커밋(2009-03-22 ed9b544e1)은 캐시가 아니었습니다. saveDb() 가 .rdb 로 쓰고 매직 REDIS0000 을 박고 fork() 기반 BGSAVE 와 save 900 1 / save 300 10 / save 60 10000 이 이미 있습니다 — 그 3줄은 6.0.0 의 기본값과 값까지 동일합니다 ✓
없던 것이 더 많습니다 — EXPIRE·hash·sorted set·AOF·epoll·RESP·MULTI·pub/sub·Lua·Cluster·src/ 전부. 이벤트 루프는 연결 리스트 + select(2) 단일 구현이고 응답은 nil\r\n·0\r\n 같은 타입 프리픽스 없는 raw 문자열입니다 ✓
단일 스레드는 성능 최적화가 아니라 API 계약이었습니다. “락을 지원하지 않는다, 대신 원자 프리미티브를 준다"가 day-1 문서의 답이고(ed9b544e1:doc/README.html), INCR·LPUSH·SINTERSTORE 가 별도 동기화 없이 원자인 이유가 이것뿐입니다 Σ
MANIFESTO 는 두 판본입니다. v1 은 2011-03-01(be14f38de, 7개 항목)이고 스레딩 항목이 없습니다. 7 - Threading is not a silver bullet 은 2019-03-18 v2(a5af648fd)에서 추가됐습니다 — 6.0.0 GA(2020-04-30)보다 약 13개월 앞서, 같은 문단이 we may explore parallelism only for I/O, which is the low hanging fruit 라고 예고합니다 ✓
버린 것을 보면 철학이 더 잘 보입니다. Virtual Memory 는 2.0 에 vm-enabled 로 실렸고 2.4 conf 가 WARNING! Virtual Memory is deprecated in Redis 2.4 를 붙였고 2.6.0 에서 제거됐습니다(Virtual Memory removed (was deprecated in 2.4)). 그 자리를 MANIFESTO 2번 Memory storage is #1 이 대신 지킵니다 ✓
6.0 threaded I/O 는 커맨드를 병렬로 돌리지 않습니다. 워커가 하는 일은 writeToClient() 또는 readQueryFromClient() 둘 중 하나뿐이고 커맨드는 배리어 통과 뒤 메인 스레드의 processCommandAndResetClient() 가 실행합니다. 기본값은 io-threads 1(비활성) + io-threads-do-reads no 로 둘 다 IMMUTABLE_CONFIG 이며 SSL 이 켜져 있으면 동작하지 않습니다 ✓
6.0 릴리스노트의 “2배” 주장에는 인스턴스·코어 수·값 크기·클라이언트 수가 없습니다 — when pipelining cannot be used 라는 한정만 있습니다 Ⓥ

왜 이 문서인가. Redis 를 기능 목록으로 읽으면 “왜 이 기능은 이렇게 생겼나"에 답할 수 없습니다. 이 구간(2009~2021)에서 정해진 것은 기능이 아니라 제약입니다 — 값이 자료구조라는 결정이 단일 스레드를 불렀습니다. 단일 스레드가 원자성을 공짜로 줬고 그 대가를 6.0 이 threaded I/O 로 처음 갚기 시작했습니다. 7.0 이후에 나오는 거의 모든 논쟁(스레딩·메모리 레이아웃·cluster 제약)의 전제가 여기서 굳었습니다.

0.36 → 1.6 — v1 전환과 그 직후

Sat, 01 Aug 2026 00:00:00 +0000

01 · 0.36 → 1.6 — v1이 바꾼 것은 API가 아니라 동작이다

v1beta1→v1을 “필드 이름이 바뀐 일"로 읽으면 사고가 납니다. changelog에서 위험한 절은 Behavior Changes이고 그중 둘은 옵트아웃이 없습니다 — drift는 Stable 승격과 함께 feature gate가 삭제됐고(core#1311), expiration은 forceful로 되돌아갔습니다(core#1333).
forceful expiration이 무시하는 건 PodDisruptionBudget(PDB)이 아닙니다. 무시하는 것은 “대체 노드가 Initialized가 될 때까지 드레인을 시작하지 않는다"는 사전 안전장치와 disruption budget입니다. nodeclaim.expiration 컨트롤러는 후보 평가 없이 NodeClaim을 바로 Delete합니다(controllers/nodeclaim/expiration/controller.go:82).
consolidateAfter가 v1에서 필수 필드입니다. v1beta1의 WhenUnderutilized에서는 설정조차 불가능했던 값이라 기존 동작을 유지하려면 0s를 명시해야 합니다. Never는 그 NodePool의 consolidation을 통째로 끕니다.
terminationGracePeriod(core#916)가 최종 승자입니다. 만료되면 PDB·do-not-disrupt 무관하게 남은 파드가 강제 삭제됩니다. 반대로 TGP를 걸면 drift가 “PDB·do-not-disrupt 파드가 있는 노드"까지 후보로 채택합니다 — 안전장치를 스스로 꺼주는 대가로 CVE 패치를 밀 수 있게 됩니다. 노드 최대 수명 = expireAfter(기본 720h, 상한이지 하한이 아닙니다) + TGP.
disruption budgets가 Drifted/Underutilized/Empty reason별로 나뉘었습니다(core#991, core#1377). 삭제된 drift feature gate의 자리를 reason별 budget이 메웁니다 — 업스트림이 제시하는 유일한 drift 통제 수단입니다.
1.1.0이 v1beta1 서빙을 끝냈습니다. nodeClassRef.group/kind가 강제 필수가 되고 kubelet 호환 어노테이션이 사라집니다. 같은 릴리스의 Bottlerocket + instanceStorePolicy: RAID0은 v1.22.0 미만 이미지에서 노드가 join하지 못합니다.
1.2.0의 메트릭 reason 라벨 snake_case 전환은 CI가 못 잡는 알람 무효화입니다. reason="Drifted" 쿼리는 에러 없이 결과가 0이 됩니다. 같은 릴리스에서 nodeclass.status·nodeclass.termination이 nodeclass로 합쳐졌습니다(aws#7597).
1.6.0에서 native On-Demand Capacity Reservation(ODCR)이 beta·기본 활성화됐습니다(core#2365). open eligibility ODCR을 capacityReservationSelectorTerms에 등재하지 않고 올리면 예약을 안 쓰면서 요금은 계속 나갑니다 — 이 구간에서 가장 비싼 회귀입니다.
MinValuesPolicy(1.6, core#2299·aws#8250)는 전역 옵션이고 기본값은 Strict입니다. minValues 자체는 v0.35.0(core#963)부터 있던 API로 0.36 운영자에게 새 기능이 아닙니다.

v1 마이그레이션 가이드 763줄의 절반은 “필드가 어디로 갔다"는 표라 kubectl apply 실패로 바로 드러납니다. 진짜 위험한 건 매니페스트가 그대로 통과하는데 클러스터가 다르게 행동하는 항목입니다 — 만료된 노드가 대체 없이 드레인을 시작하고, 끄고 있던 drift가 켜지고, 쓴 적 없는 consolidateAfter가 필수가 됩니다.

In-Place Pod Resize (1.35 GA)

Sat, 01 Aug 2026 00:00:00 +0000

01 · In-Place Pod Resize — 재시작 없이 파드 리소스를 바꾼다

1.27 alpha → 1.33 beta → 1.35 GA. 파드를 재시작하지 않고 CPU/메모리를 바꿉니다. 반드시 resize 서브리소스로만 통합니다. 손댈 수 있는 건 cpu·memory 값뿐입니다(QoS 변경·항목 제거·GPU는 전부 거부).
수락 판정 기준은 실사용량이 아니라 “다른 파드들의 requests 합 vs node allocatable”. 노드가 붐비면 Deferred(재시도됨), 정책 위반이면 Infeasible(spec을 고치기 전까지 재평가 안 됨).
늘리는 쪽은 사실상 무위험, 줄이는 쪽만 조심. 메모리 축소에는 kubelet 사용량 체크의 TOCTOU 레이스가 남아 OOM-kill을 확실히 막지 못합니다(#135670, open). CPU 축소는 재시작이 없다는 뜻일 뿐 스로틀 비용을 낳는데 그건 사용률 그래프에 안 보입니다(throttled_periods로 봐야 합니다).
케이스가 전부입니다. 재시작이 비싼 stateful(DB·캐시·롱커넥션)에 최적이고 기동 부스트에도 좋습니다. JVM/Node 힙에는 반쪽(CPU만 in-place), VPA 자동화는 아직 이르고 static CPU manager 노드는 사실상 미지원입니다.

왜 6년이 걸렸을까요. “실행 중인 컨테이너의 cgroup 값만 바꾸면 되는 것 아닌가” 싶지만 이 기능에서는 스케줄러가 보는 값·kubelet이 약속한 값·커널에 실제 쓰인 값이 서로 다른 순간이 반드시 생깁니다. 그 셋의 정합성에 kubelet 재시작 후의 복구까지 맞추는 데 KEP-1287은 alpha에서 GA까지 6년을 썼습니다. 그래서 이 문서는 공식 문서에서 멈추지 않고 kubelet이 실제로 하는 일 · 열린 버그 · 케이스별 득실까지 내려갑니다.

네이버 검색 SRE 시계열 DB 운영기

Sat, 01 Aug 2026 00:00:00 +0000

01 · 네이버 검색 SRE의 시계열 데이터베이스 운영기 (2024-02)

참조한 내용정리 · 이 문서는 아래 네이버 D2 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니며 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

배경 — 왜 CAPI in-place를 버리고 blue-green인가

Sat, 01 Aug 2026 00:00:00 +0000

배경 — 왜 CAPI in-place를 버리고 blue-green인가

finance EKS 클러스터는 원래 CAPI GitOps로 관리하도록 설계돼 있었습니다. 그런데 조사 시점(2026-07)에 그 설계는 이미 반쯤 무너져 있었습니다. 최초 계획은 CAPI GitOps in-place 업그레이드였지만, 조사 과정에서 진단이 두 번 뒤집힌 끝에 신규 blue 클러스터를 Terraform으로 생성하는 blue-green으로 방향이 굳었습니다. 랜딩이 요약한 이 전환의 근거를 아래 네 포인트로 풀어냅니다.

서비스 메시와 Istio 기초

Sat, 01 Aug 2026 00:00:00 +0000

01 · 서비스 메시와 Istio 기초 — 왜 EKS에 메시를 얹나

서비스 메시 = 데이터 플레인(파드마다 붙는 Envoy 사이드카) + 컨트롤 플레인(istiod). 이 분리가 챕터 전체의 뼈대입니다.
사이드카는 iptables로 트래픽을 가로채 앱 코드를 그대로 둔 채 mTLS·라우팅·재시도·관측성을 더합니다.
메시는 공짜가 아닙니다 — 프록시 오버헤드·컨트롤 플레인 부하·설정 복잡도·디버깅 난이도라는 네 비용을 집니다.
Ambient 모드(사이드카리스, ztunnel+waypoint)는 이 비용을 줄이려는 후속 설계지만, 이 챕터는 사이드카 모드 운영을 전제로 합니다.

02~05는 메시를 운영하며 겪은 사건의 기록입니다. 그 기록이 읽히려면 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지를 먼저 잡아야 합니다. 이 문서는 서비스 메시의 두 축(데이터 플레인·컨트롤 플레인), 메시가 해주는 것, 그 비용을 다룹니다.

스택 구성

Sat, 01 Aug 2026 00:00:00 +0000

01 · 우리 스택 구성

k8s 위 VM operator가 vmagent를 Deployment(stateless)로 띄우고 중앙 VM 클러스터의 vminsert 엔드포인트로 remote_write 합니다.
목적지 경로 /insert/0/prometheus는 클러스터 모드 · tenant 0을 뜻합니다.
stage/prod는 값이 다릅니다 — 리소스·maxDiskUsagePerURL이 환경별로 달라지고 prod는 vmagent가 두 계열(용도별 분리)이라 extraArgs가 양쪽에 함께 걸립니다.
공통 수집 설정은 scrapeInterval 30s · promscrape.streamParse=true · promscrape.maxScrapeSize=24GiB.

우리 환경에서 지표가 어디서 만들어져 어디로 흘러가는지, 그 구조와 stage/prod 값 차이를 정리합니다. 전송 안정화 Phase 1 튜닝은 02 vmagent 전송 튜닝에서, 장기보관 아키텍처는 메트릭 장기보관 챕터에서 따로 다룹니다.

스택 토폴로지 — 4컴포넌트 배치·데이터 흐름·MongoDB 최소 배포

Sat, 01 Aug 2026 00:00:00 +0000

스택 토폴로지 — 4컴포넌트 배치·데이터 흐름·MongoDB 최소 배포

ClickStack은 HyperDX(app+api) · OTel Collector · ClickHouse · MongoDB 4컴포넌트를 2개 Helm 차트(clickstack-operators → clickstack)로 올립니다. 차트 기본은 모든 스테이트풀 컴포넌트가 단일 인스턴스(PoC용) 이지 HA가 아닙니다 ✓.
operator 분기(중요): 표준 차트가 딸려오는 ClickHouse operator는 ClickHouse Inc. 공식 operator(ClickHouseCluster/KeeperCluster CRD)입니다. 우리는 이걸 그대로 쓰지 않고 clickhouse.enabled: false(자체(self-hosted) ClickHouse에 연결하는 ‘HyperDX Only’)로 CH/Keeper를 Altinity CHI/CHK로 분리 운영합니다 → /hyperdx/04-operator-topology-downtime/.
RUM 인제스트 경로에 MongoDB는 없습니다. 브라우저 → OTLP/HTTP :4318 → Collector → ClickHouse. MongoDB는 UI에서 대시보드/알럿/소스를 만들 때만 쓰입니다 — 인제스트 경로에 없으니 아주 작게 돌려도 됩니다.
MongoDB 최소 배포 형상: 메타데이터 전용이라 단일 멤버 실효 바닥 ~~0.4 vCPU / 0.75~~1.25Gi / gp3 10Gi. prod는 members:3(≈1.2 vCPU/3Gi, 값싼 보험)에 SCRAM + mongodump CronJob이 실전 권고입니다.

이 페이지는 HyperDX ClickStack을 실제 K8s에 조립하는 배치 청사진을 다룹니다. 4컴포넌트의 정체성·배포 6모드·HyperDX Only 개념은 HyperDX / ClickStack 심층 분석이, 로그 스토어로서의 요약 판단은 로깅 챕터가 이미 다뤘으므로 재나열하지 않습니다. 여기서는 각 컴포넌트를 어느 파드로 어디에 올리고 데이터가 어디로 흐르며 MongoDB를 얼마나 작게 배포할 수 있는지에 집중합니다.

왜 Ambient mode인가

Sat, 01 Aug 2026 00:00:00 +0000

01 · 왜 Istio Ambient mode인가 — 사이드카를 건너뛴 선택 (2026-03)

참조한 내용정리 · 이 문서는 아래 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니며 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

카디널리티

Sat, 01 Aug 2026 00:00:00 +0000

01 · 카디널리티 — 시계열 폭발의 원리와 설계 원칙

시계열 = 지표 이름 + 레이블 집합. 레이블 값 하나만 달라도 완전히 다른 시계열이 됩니다.
New TSID 발급(=처음 보는 시계열)이 곧 카디널리티 폭발입니다. IndexDB에 인덱스를 쓰는 연산이라 데이터포인트 추가보다 CPU·메모리를 훨씬 많이 먹습니다.
Worst case는 pod_name·session_id처럼 자주 바뀌는 값을 레이블로 쓰는 것입니다. Best case는 설계 단계에서 배제하는 것 — 서비스 이름 같은 안정 레이블만 쓰고 자주 바뀌는 값은 로그·트레이스로 뺍니다.
런타임에는 churn rate(신규 시계열 생성 속도)와 slow insert rate(지속 10% 초과 시 메모리 부족 경고)를 봅니다.

VM 운영에서 가장 자주 사고를 내는 개념이 카디널리티입니다. 출발점은 “한 시계열이 무엇으로 정의되는가"입니다. 거기서 카디널리티 폭발이 왜 곧 메모리·인덱스 폭발인지, 설계 단계에서 어떻게 막는지까지 이어 봅니다.

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

Tue, 21 Jul 2026 00:00:00 +0000

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

컨트롤러를 0.36.2에서 최신 stable 1.14.0(2026-07-11 릴리스)로 올립니다. 목표 k8s 1.35를 지원하는 최소가 1.9이고 1.14는 1.30~1.36을 커버하니 “가능한 최신 stable” 방침에 맞습니다 — 1.36으로 재검토할 때도 하한이 1.13이라 1.14.0이 그대로 유효합니다 ✓
넘을 스키마 경계는 v1beta1 → v1 하나뿐입니다. finance의 0.36.2는 이미 v1beta1(karpenter.sh/v1beta1 NodePool·karpenter.k8s.aws/v1beta1 EC2NodeClass)입니다. v1alpha5의 Provisioner·AWSNodeTemplate은 v0.33에서 졸업해 애초에 없습니다 ✓
v1에서 amiSelectorTerms가 필수가 됩니다. 빠뜨리면 EC2NodeClass와 이를 참조하는 모든 NodePool이 통째로 NotReady가 됩니다 ✓
v1은 drift를 GA로 승격시키면서 끄는 수단을 없앱니다. finance가 명시한 featureGates.drift: false는 무효가 되고 drift가 강제로 켜집니다 ✓
blue-green 신규 클러스터라 conversion 웹훅을 왕복하지 않습니다. 기존 클러스터를 in-place로 올릴 때만 밟아야 하는 0.36 → 0.36.9 → 1.0.x → 1.1+ 순차 경로를 건너뛰고 v1 CRD와 v1 매니페스트로 1.14.0을 처음부터 세웁니다 ✓

1. 왜 1.14.0인가

목표 클러스터가 k8s 1.35라서 버전은 거의 정해집니다. karpenter 호환 매트릭스에서 1.35를 받는 최소 버전이 1.9이고 1.14는 1.30~1.36을 커버합니다. “가능한 최신 stable"이라는 방침과 하한 조건이 같은 답을 가리킵니다. 나중에 1.36으로 재검토하더라도 그때의 하한이 1.13이라 1.14.0은 그대로 쓸 수 있습니다.

Managed vs Self-hosted — TCO 크로스오버

Mon, 13 Jul 2026 00:00:00 +0000

Managed vs Self-hosted — TCO 크로스오버

판단을 좌우하는 축은 데이터 크기보다 운영 인력 보유 여부입니다 — 팀 <5명이면 Cloud, 전담 인프라 인력을 낀 10명+면 self-host.
크로스오버는 ~20TB / 24-7 구간. 인프라 비용은 거의 붙어서 결정은 월 $1,600~4,800의 people TCO에서 납니다.
SharedMergeTree(진짜 storage-compute 분리)는 ClickHouse Cloud 전용 — self-host는 RMT 강제. 이 선택은 가격 비교가 아니라 아키텍처 선택입니다.
인력이 이미 있으면 self-host가 비용·성능(로컬 NVMe 수십만 IOPS)에서 모두 앞섭니다.

ClickHouse를 어디에 둘지는 데이터 크기보다 운영 인력을 이미 보유했는지에 달렸습니다. 데이터가 ~5TB에 머물고 사용이 간헐적이면 Cloud가 압승합니다. 60TB+ / 24-7이면 self-host가 명확히 쌉니다. 접전 구간(~~20TB / 24-7)에서는 인프라 비용이 거의 붙어서 결정이 월 $1,600~~4,800의 people TCO ≈로 넘어갑니다. 인력이 이미 있으면 self-host의 유일한 약점이 상쇄돼 성능·비용 모두에서 앞섭니다.

OpenSearch (EFK)

Sun, 12 Jul 2026 00:00:00 +0000

OpenSearch (EFK) — 지금 쓰는 것, 왜 뚱뚱해 보이는가

강점은 임의 필드 ad-hoc 풀텍스트·고카디널리티 검색, SIEM/보안 완제품, 관리형 운영의 낮은 인건비입니다.
약점은 로그 저장 목적에 비해 컴퓨트가 무겁다는 점입니다 — 비용의 ~90%가 인스턴스 시간이고 스토리지는 ~10%뿐입니다.
UltraWarm은 예약(RI) 불가(hot만 예약 가능)라 전 클러스터 블렌디드 절감 상한이 ~25%에 그칩니다 — “40% 절감” 기대는 성립하지 않습니다.
진짜 절감은 보존 tail을 컬럼나+S3로 옮기고 hot을 축소·OR로 전환하는 데서 나옵니다. 이게 hot RI 최대 절감보다 큽니다.
우리 케이스: 90일 보존이 정말 필요한지부터 되묻습니다. tail 이전 + in-place 최적화를 먼저 합니다.

Apache Lucene 기반 분산 검색·분석 엔진입니다. 2021년 Elastic이 SSPL로 전환한 뒤 Elasticsearch 7.10.2 / Kibana를 포크해 만들었습니다. 라이선스는 Apache 2.0이고 지금은 OpenSearch Software Foundation(Linux Foundation)이 관리합니다 — 성숙도·생태계가 넓고 프로덕션 채택이 두텁습니다. AWS에서는 관리형 Amazon OpenSearch Service로 제공됩니다. 고객사는 fluent-bit → Firehose → OpenSearch(+ UltraWarm)로 운영 중입니다. 파이프라인 구성 자체는 정석입니다. 쟁점은 로그 저장 용도에 비춘 요금 구조입니다.

TSDB와 VictoriaMetrics

Sun, 12 Jul 2026 00:00:00 +0000

01 · 시계열 데이터와 VictoriaMetrics

시계열은 “언제 어떤 숫자가 찍혔나"가 이어지는 데이터입니다. 지표에는 Counter/Gauge/Histogram/Summary 4타입이 있습니다. 그중 Counter류 단조증가값이 압축이 가장 잘 됩니다.
“대용량"을 나누는 기준은 시계열 개수와 보관 기간입니다. 수백만 개까지는 Prometheus 단일로 충분하지만 수천만~수십억 개부터는 별도 솔루션이 필요합니다.
TSDB 계보: Prometheus(2012) → Gorilla 압축(2015, Facebook) → Thanos/Cortex(Prometheus 확장) vs VictoriaMetrics(완전히 다른 계열).
VM은 Prometheus 호환(PromQL·remote_write 그대로)을 지키면서 자체 벤치마크 기준 메모리 5배·스토리지 7배 효율을 주장하는 오픈소스 TSDB입니다.

시계열 데이터가 무엇인지, 왜 “대용량"이 별도의 문제로 떨어져 나오는지, 그 문제를 푸는 도구로서 VictoriaMetrics(이하 VM)가 어디에 서 있는지를 정리합니다. VM 내부의 컴포넌트 구조는 02 아키텍처로 넘깁니다.

문제와 결정 2축

Sun, 12 Jul 2026 00:00:00 +0000

문제 정의와 결정 2축

목적은 과거 장애 재조사용 메트릭 400일 보관. >90d 구간은 5m 해상도 허용(확정), 전 메트릭 커버리지 필요, OSS 우선.
결정은 2축: (1) 무엇을 보관하나(raw 400d 전부 vs raw 90d + 5m 집계 400d — 후자가 비용을 자릿수로 낮춥니다) · (2) 어디에 저장하나(VM은 S3를 primary로 지원하지 않아 EBS 위에 둡니다).
서울 리전 단가는 sc1 < S3 Standard < st1 < gp3 — “S3라서 싸다"는 성립하지 않습니다.
확정 시나리오(raw 90d + 5m 집계 400d) 기준 VM 아카이브안이 월 $385~416로 최저, 단순 확장($1,642)보다 자릿수로 쌉니다.

메트릭 400일 보관 문제를 정의하고 비용을 자릿수 단위로 좌우하는 두 결정축(무엇을 보관 / 어디에 저장)을 정리합니다. 시나리오별 저장량·비용 규모와 검증된 서울 리전 단가 요약표를 함께 싣습니다.

레이어 2 — 2026-08 열린 4종과 karpenter 가중치

Sat, 15 Aug 2026 00:00:00 +0000

레이어 2 — 2026-08 열린 4종과 karpenter 가중치

실제 후보는 MostAllocated 하나뿐이고 그것도 blue 안정화 이후 별건입니다. create 시점에는 4개 전부 기본값으로 둡니다(§8).
4개가 열렸고 그중 3개는 추가 과금이 없습니다. scoringStrategy·eventTtl·serviceNodePortRange는 k8s 1.31+ 전 리전에서 무료로 쓸 수 있고 HPA syncPeriod만 Provisioned Control Plane(월 증분 +$1,204.50)이 전제입니다.
완전 개방이 아니라 검증된 범위 안의 개방입니다. 범위 폭(HPA 5초 · eventTtl 축소 방향만 · 스케줄러 전략 2종만)이 그대로 AWS의 책임 경계 선언입니다 — 업스트림 kube-controller-manager에는 sync period validation이 아예 없습니다(§2).
karpenter는 이 설정을 읽지 않습니다. karpenter-core v1.14.0 전체에서 scoringStrategy 관련 심볼이 grep 0건입니다. 점수 공식이 각 항을 그 노드 자신의 allocatable로 나누므로 “노드의 cpu/memory 비율에 맞춰 가중치를 조정한다"는 작업은 애초에 필요하지 않습니다(§4).
AWS 문서와 실제가 어긋납니다. User Guide는 Terraform을 “coming soon"이라 쓰지만 provider v6.59.0(발표 당일)에 이미 들어왔고 eksctl·CDK는 반대로 과대 서술입니다(§6).

2026-08-12, EKS가 관리형 컨트롤 플레인 3개 컴포넌트의 파라미터 4종을 고객 설정 대상으로 열었습니다. 지금까지 kube-scheduler·kube-apiserver·kube-controller-manager 설정은 손댈 수 없는 영역이었습니다. 노드를 채워 써서 컴퓨트 비용을 줄이고 싶어도 관리형 스케줄러의 전략을 바꿀 방법이 없었습니다. 목표버전에서 확정한 blue의 목표는 1.35이고 이 4종의 하한은 1.31입니다. blue는 4개를 전부 쓸 수 있는 상태로 태어납니다. 이 페이지는 **“써야 하나”**를 판정합니다. “쓸 수 있나"는 이미 답이 나와 있습니다. 클러스터 레벨 파라미터와 가변성 3분류는 레이어 1, HPA syncPeriod가 요구하는 용량 축은 Provisioned Control Plane, 이번에도 여전히 닫혀 있는 플래그들은 레이어 3이 다룹니다.

운영 런북 — 장애·변경이 났을 때 무엇을 어떤 순서로

Thu, 13 Aug 2026 00:00:00 +0000

운영 런북 — 장애·변경이 났을 때 무엇을 어떤 순서로

이 페이지는 메커니즘을 설명하지 않고 순서와 판별 신호만 담습니다.

부록 · 발표 전사 — Braze Redis→Valkey

Thu, 06 Aug 2026 00:00:00 +0000

02 · 발표 전사 — Redis on EC2 to Valkey on Kubernetes: A Zero-Downtime Case Study

이 문서는 KubeCon + CloudNativeCon Europe 2026 발표 Redis on EC2 to Valkey on Kubernetes: A Zero-Downtime Case Study(Joe Heyburn, Braze)의 전사 정리본입니다. YouTube 자동 자막(타임스탬프 714줄)을 원본으로 삼되 발표자 본인의 슬라이드 덱과 대조해 오인식을 교정했습니다 — Joe Hayburn/Joe Haben→Joe Heyburn(핸들 @jdheyburn), “psychic shard”→Sidekiq shard, “a free phase approach”→three-phase approach, “no network load balancer”→an NLB, “at Redis, we use AZ affinity”→at Braze, “31,000”→nodePort 31000, “custom resharding”→Cluster resharding.

부록 · 발표 전사 — Scaling Valkey

Thu, 06 Aug 2026 00:00:00 +0000

02 · 발표 전사 — Scaling Valkey the Right Way: Kubernetes at XL Scale

이 문서는 KubeCon + CloudNativeCon Europe 2026 발표 Scaling Valkey the Right Way: Kubernetes at XL Scale(Sarthak Aggarwal · Madelyn Olson, AWS ElastiCache)의 전사 정리본입니다. YouTube 자동 자막(타임스탬프 942줄)을 원본으로 삼되 발표자 본인의 슬라이드 덱과 대조해 오인식을 교정했습니다. Valkyrie→Valkey, Madeline/Merlin/Marlin→Madelyn, “as a stateless set”→StatefulSet, “something like that, CD”→etcd, “16,000 슬롯”→16384, “REST protocol”→RESP, “Bin Bin”→Binbin.

수립 방향이라는 분기점

Thu, 06 Aug 2026 00:00:00 +0000

02 · 수립 방향이라는 분기점

“연결을 누가 거느냐"와 “데이터가 어디로 흐르느냐"는 별개입니다. 중앙 → 단말 일방 푸시라는 요구는 두 분기가 모두 만족합니다. SSE·WebSocket·long-polling이 존재하는 이유 자체가 클라이언트가 건 연결 위에서 서버가 일방적으로 미는 것이기 때문입니다.
현행 구성이 이미 답을 알고 있습니다. API Gateway WebSocket API에는 클라이언트 개시 외의 모드가 없습니다. 지금 돌아간다면 POS가 outbound로 걸고 있다는 뜻입니다 — 서비스 제약이 그것 말고는 허용하지 않습니다.
판정은 액세스 로그 한 줄이면 끝납니다. $context.identity.sourceIp가 매장 회선의 NAT 공인 IP로 찍히면 분기 A가 확정됩니다.
분기는 링의 유무 말고도 여럿을 바꿉니다. 전송 프로토콜(SSE가 맞는가), k8s 워크로드 종류(Deployment냐 StatefulSet이냐), 장애 감지 주체가 전부 뒤집힙니다.
분기 B가 네트워크상 가능해도 보통은 A를 택합니다. 5만 대의 주소 인벤토리, 단말별 TLS 서버 인증서와 그 갱신, 매장 방화벽 인바운드 규칙이 전부 새 운영 비용으로 붙기 때문입니다. B는 “가능한가"가 아니라 “그 값을 치를 만한가"로 판정해야 합니다.
혼재는 A로 수렴시킵니다. 일부 매장이 전용망이라 해서 두 경로를 함께 유지하면 장애 모드가 두 배가 됩니다. 전용망 매장도 outbound로 걸게 하면 A 하나로 끝납니다.

왜 이 문서인가. 이 질문 하나가 04와 05 중 어느 쪽을 읽어야 하는지를 정합니다. 그런데 실무에서는 이 질문이 “중앙에서 단말로 밀어야 하니 중앙이 연결을 걸어야 하는 것 아닌가” 라는 형태로 자주 뒤섞입니다. 여기서는 두 방향을 분리하고 판정을 코드 한 줄 짜지 않고 끝내는 절차를 남깁니다.

memcached — 같은 문제를 다르게 푼 6년 선배

Thu, 06 Aug 2026 00:00:00 +0000

02 · memcached — 같은 문제를 다르게 푼 6년 선배

memcached 는 Redis 의 열등한 과거가 아닙니다. “캐시는 캐시여야 한다"를 끝까지 밀어서 Redis 가 갖지 못한 성질(한 프로세스로 코어를 먹는 확장, 느린 커맨드가 존재할 수 없는 지연 예측성, 값을 NVMe 로 내리는 용량 확장)을 얻고 자료구조·영속성·복제·다중 키 원자성을 포기했습니다 Σ
첫 커밋(2003-05-27)에는 slab allocator 도 자체 해시 테이블도 없었습니다. malloc() + Judy 트라이 + 전역 단일 LRU 였고 slab 은 3일 뒤·자체 해시는 3주 뒤에 둘 다 파편화 때문에 들어왔습니다 ✓
slab allocator 의 대가가 calcification 이고 그것을 갚는 데 21년이 걸렸습니다. 문제 인지 2003-06-24, 첫 공식 해법 1.4.11(2012-01-16), 기본값 승격 1.5.0(2017-07-21), 그리고 1.6.34(2024-12-22)의 mover 전면 재작성이 “페이지를 옮기면 아이템을 잃는다"는 대가 자체를 제거했습니다 ✓
LRU 는 HOT/WARM/COLD/TEMP 4단 segmented LRU 이고 1.5.0 부터 기본입니다. Redis 와 근사의 위치가 반대입니다 — memcached 는 접근 기록을 스레드별 bump buffer 에 비동기로 쌓고 넘치면 버리며, Redis 는 축출 시점에 표본을 뽑습니다(maxmemory-samples 5) ✓
워커 스레드 N개가 각자 이벤트 루프를 돌려 read·parse·execute·write 를 끝냅니다. -t 16 한 프로세스가 16코어를 씁니다. Redis 8.10.0 redis.conf 는 2026년에도 “Redis is mostly single threaded” 이고 io-threads 는 소켓 읽기·쓰기와 프로토콜 파싱까지입니다 — 커맨드 실행은 메인 스레드입니다 ✓
그 대가가 원자성입니다. 보장 단위가 아이템 하나뿐이라 MULTI/EXEC·Lua·다중 키 트랜잭션에 대응할 방법이 원리적으로 없습니다 ✓
binary protocol 은 1.6.0(2020-03-08)에 공식 deprecated 됐고 후계는 meta 커맨드입니다. 2026년에 클라이언트를 고를 때 meta 지원 여부가 1순위인 이유는 stampede 방어(W/Z)와 serve-stale 이 서버에서 원자적으로 되는 유일한 경로이기 때문입니다 ✓
프로젝트는 살아 있지만 기능 개발은 멈춰 있습니다. 2026년 릴리스 4개(1.6.42~1.6.45)가 전부 보안·안정화이고 최근 1년의 사용자 노출 신기능은 1.6.40 의 mg 조건부 CAS 페치 하나입니다 ✓
memcached 와 Redis 를 같은 하드웨어에서 1:1 로 측정한 1차 벤치마크는 없습니다. 그래서 이 문서는 “몇 배 빠르다"를 쓰지 않고 구조와 단독 측정치만 씁니다 ?

왜 이 문서인가. memcached 를 “Redis 가 나오기 전에 쓰던 것"으로 읽으면 두 번 틀립니다. 하나, memcached 는 2003년에 멈춘 소프트웨어가 아닙니다 — segmented LRU(1.4.23), SSD 확장(1.5.4), 재시작 생존 캐시(1.5.18), meta 프로토콜(1.6.0), 내장 proxy(1.6.13), slab mover 재작성(1.6.34)이 전부 그 뒤에 들어왔습니다. 둘, 둘의 차이는 기능 개수가 아니라 선택한 축입니다. memcached 는 값을 해석하지 않기로 한 대가로 스레드를 열었고, Redis 는 자료구조를 서버에서 실행하기로 한 대가로 실행 스레드를 하나로 묶었습니다. 이 문서는 그 교환을 소스와 릴리스노트로 확인합니다.