블로그
프로젝트를 만들며 정리한 기술 노트와 회고를 기록하는 공간이에요.
EKS 2개로 관측 플랫폼 만들기 — Terraform, Cilium, EFK, Prometheus, ArgoCD
dev 클러스터의 로그·지표를 별도 ops 클러스터로 모으는 hub-and-spoke 관측 플랫폼을 Terraform으로 처음부터 만들면서 겪은 것들. Cilium overlay가 EKS admission webhook을 깨뜨린 이유, LB Controller webhook 순서 문제, ArgoCD의 Synced≠Healthy, 그리고 finalizer가 teardown을 막는 지옥까지 삽질 위주로 정리합니다.
읽어보기KEDA와 Karpenter — 큐가 쌓이면 파드가 늘고, 파드가 밀리면 노드가 생긴다
HPA는 CPU·메모리 기준이라 0으로 못 줄이고 큐 길이 같은 이벤트에 직접 반응하지 못합니다. KEDA가 이벤트 소스(RabbitMQ 큐 등)를 보고 파드를 0↔N으로 조절하고, Karpenter가 그렇게 늘어난 파드에 맞춰 노드를 즉석에서 프로비저닝하는 구조를, RabbitMQ 기반 inference-worker를 예로 정리합니다.
읽어보기로그는 이미 모으고 있는데, 그럼 SIEM은 뭐가 다른가
fluent-bit → Elasticsearch → Kibana로 관측(Observability) 스택을 만들고 나면 "이거 SIEM이랑 뭐가 달라?"라는 질문을 받게 됩니다. 둘 다 로그를 모으지만 목적, 데이터 모델, 보존 정책, 그 위에 얹는 로직이 다릅니다. SIEM이 실제로 하는 일(수집·정규화·상관분석·탐지·대응)을 정리하고, 이미 있는 EFK 스택에 최소한의 SIEM 기능을 얹는다면 어디를 손대야 하는지, Sigma 탐지 규칙 예시와 함께 남깁니다.
읽어보기SRE란 무엇인가 — 왜 필요한가
EKS 관측 플랫폼, KEDA/Karpenter 오토스케일링, 장애 대응 같은 걸 만들다 보면 "이거 결국 SRE 아니야?"라는 질문에 닿습니다. SRE가 정확히 무엇이고, 왜 전통적인 Dev/Ops 구조로는 부족해서 등장했는지, Google SRE 책의 정의를 기준으로 정리합니다.
읽어보기