promkr 뉴스레터 2025년 1월호

이 호에 실린 소식 10개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2025년 소식에 있습니다.

1. 조직의 학습과 행동으로 확장하는 Observability 3.0

원문: The Future of Observability: Observability 3.0 · Hazel Weakly

Hazel Weakly는 데이터를 수집하고 분석하는 것만으로는 옵저버빌리티의 목적을 달성하지 못한다고 주장합니다. 저자가 제시하는 정의는 의미 있는 질문을 던지고, 유용한 답을 얻고, 배운 내용을 바탕으로 효과적으로 행동하는 능력을 기르는 과정입니다. 데이터와 도구를 갖춘 뒤 조직이 무엇을 해야 하는지가 글의 출발점입니다.

저자는 Observability 1.0을 로그·추적·메트릭이 분리되고, 데이터를 기록할 때 앞으로 던질 질문이 결정되는 방식으로 설명합니다. 서로 연결하기 어려운 여러 정보원이 질문의 범위를 제한한다는 주장입니다. Observability 2.0에서는 데이터 형식과 저장 위치, 기준 정보원이 통일됩니다. 넓은 범위의 속성을 담은 이벤트를 연결하면서 의미 있는 질문을 던질 가능성이 생깁니다. 이때도 기록 시점에 어떤 상관관계를 분석할 수 있는지는 결정됩니다.

Observability 3.0은 저자가 제안하는 미래 전망입니다. 백엔드는 데이터 레이크하우스와 비슷해지고, 쿼리 기능이 확장되어 기록 시점과 조회 시점의 처리 구분이 상당 부분 사라질 것으로 예상합니다. 가장 큰 변화는 성공의 기준입니다. 엔지니어링 조직의 효용을 넘어, 다른 사업 부서가 얻는 가치가 도입 성과를 주로 결정할 것이라고 봅니다. 효과적인 공동 행동과 조직의 학습이 그 목표입니다.

저자는 이런 변화가 특정 벤더나 기존 도구의 교체를 필수로 요구하지는 않는다고 강조합니다. 기존 도구로도 상관관계 분석은 가능하지만 구현이 어려울 수 있습니다. 최신 도구를 사용해도 계측이 잘못되거나 분산 추적이 끊기면 가치를 얻지 못합니다. 따라서 3.0을 좌우하는 요인은 기술뿐 아니라 조직이 함께 배우고 행동하는 방식이라는 주장입니다.

2. 옵저버빌리티 버전 구분에 대한 반론

원문: Thoughts on Oddly Specific Versioning in Observability

원문 페이지를 받지 못해 뉴스레터 소개만 옮깁니다. 뉴스레터는 이 글을 앞선 Observability 3.0 글에 반론을 제기하는 글로 볼 수 있다고 소개합니다. 소개에 따르면 이 글은 1.0의 SLI/SLO로 해결할 수 있는 문제가 많을 수 있다고 보고, 2.0으로의 전환 자체가 중요한 문제인지 묻습니다.

3. PromQL 벡터 매칭과 레이블별 비율 계산

원문: PromQL vector matching: what it is and how it affects your Prometheus queries · Dawid Dębowski · 2024-12-14

Dawid Dębowski는 PromQL 쿼리 양쪽에 데이터가 있는데도 결과가 없거나 예상과 다른 비율이 나오는 원인을 벡터 매칭으로 설명합니다. 벡터끼리 산술 연산을 할 때는 instant vector를 사용하며, range vector끼리 나누면 오류가 발생합니다. 연산은 왼쪽의 각 항목과 오른쪽에서 대응하는 항목 사이에 적용됩니다. 기본 매칭에서는 레이블을 비교하고, 짝을 찾지 못한 항목은 결과에서 제외합니다.

예제는 type 레이블이 붙은 pokemon_caught_total 카운터입니다. 전체 포켓몬 285마리 중 물 타입의 비율은 약 5.26%입니다. 물 타입 시계열을 전체 타입의 시계열 집합으로 나누면, 레이블이 같은 물 타입끼리만 매칭되어 100%가 나옵니다. 분모를 sum으로 합산해도 해결되지 않습니다. 집계 결과에는 레이블이 없고 분자에는 type이 남아 있어 매칭이 실패하기 때문입니다.

물 타입의 비율만 필요하다면 분자에도 sum을 적용해 양쪽 레이블을 없앨 수 있습니다. 레이블 구성을 유지하면서 계산하려면 on으로 비교할 레이블을 지정하거나 ignoring으로 제외할 레이블을 지정합니다. 물 타입 시계열 하나와 전체 합계 하나를 연결하는 경우에는 빈 레이블 집합을 지정한 on()으로 일대일 매칭을 수행할 수 있습니다.

모든 타입의 비율을 한 번에 계산할 때는 여러 시계열이 합계 하나와 연결되는 다대일 매칭이 필요합니다. 이 경우 group_left로 왼쪽의 레이블을 유지하며, 다수의 시계열이 오른쪽에 있다면 group_right를 사용합니다. 저자는 같은 원리를 HTTP 상태 코드별 오류 비율 계산에도 적용할 수 있다고 설명합니다. 또한 Prometheus 문서가 그룹 수정자를 신중히 고려해야 하는 고급 사용법으로 분류한다는 점을 덧붙입니다.

4. Loki 3.3의 구조화된 메타데이터 기반 Bloom 필터

원문: Grafana Loki 3.3 release: faster query results via Blooms for structured metadata · Salva Corts · 2024-11-22

Grafana Labs는 Loki 3.3에서 Bloom 필터의 생성 대상을 로그 본문에서 구조화된 메타데이터로 바꿨습니다. 특정 사용자 ID나 장치 ID에 해당하는 소수의 로그를 찾을 때 검색할 필요가 없는 데이터를 먼저 제외하려는 변경입니다. 구조화된 메타데이터는 Loki 2.9에서 인덱스에 넣기 어려운 높은 카디널리티의 레이블 등을 위해 도입했습니다. Loki 3.0의 네이티브 OpenTelemetry 지원도 각 로그의 속성을 여기에 저장합니다.

Bloom 필터는 이전처럼 시계열별로 만들지만, 로그 전체에서 추출한 n-gram 대신 메타데이터 필드의 키와 키·값 쌍을 담습니다. Grafana Labs는 이 방식의 Bloom이 이전보다 규모 차이가 날 만큼 작아져 생성·다운로드·조회가 빨라진다고 설명합니다. OpenTelemetry를 사용하지 않아도 Grafana Alloy의 Loki 파이프라인으로 메타데이터를 붙일 수 있습니다.

가속하려면 조회 시간 구간의 Bloom 블록이 Bloom gateway에 준비되어 있어야 합니다. 쿼리도 구조화된 메타데이터를 조회하는 문법을 사용해야 합니다. 예를 들어 traceID 조건을 적용하면 해당 키·값 쌍이 없다고 확신하는 청크를 먼저 제외합니다. 이후 남은 청크에만 JSON 파싱과 출력 형식을 적용하므로 다운로드하고 압축을 풀어 처리할 데이터가 줄어듭니다.

이 기능은 Loki와 Grafana Enterprise Logs 3.3에서 실험적 기능이며, 대규모 Grafana Cloud 고객에게는 퍼블릭 프리뷰로 제공됩니다. 새 Bloom 블록 형식은 이전 형식과 호환되지 않습니다. Grafana Labs는 업그레이드 전에 객체 저장소의 bloom 경로를 삭제해 기존 블록을 정리하도록 권고합니다. 또한 Bloom compactor를 planner와 builder로 대체했습니다. TSDB의 청크 크기 통계에 따라 작업을 나누는 새 전략과 디스크 기반 작업 큐도 추가했습니다. 기본 계획 전략은 그대로 유지하며, 두 기능은 모두 설정으로 선택해 사용할 수 있습니다.

5. Retina로 측정하는 가용 영역 간 파드 트래픽

원문: Monitoring Inter-Pod Traffic at the AZ Level with eBPF based tool Retina · Aslanov Javid · 2024-08-25

Aslanov Javid는 AWS 비용에서 큰 비중을 차지하는 가용 영역 간 트래픽을 분석하기 위해 Retina를 사용했습니다. 서비스에 topology-aware routing을 적용하기 전에, 어떤 통신이 가용 영역 경계를 넘는지 파악하는 것이 목적입니다. 저자는 eBPF 기반 파드 단위 관측을 선택했으며, 네임스페이스나 파드별로 수집 범위를 제한하기 쉬운 점을 Retina의 선택 이유로 설명합니다.

실습에서는 서로 다른 네임스페이스에 서버 파드 6개와 클라이언트 파드 10개를 배포하고 여러 가용 영역에 나눠 배치합니다. Flask 서버는 자신의 가용 영역을 응답하고, 클라이언트는 요청을 반복하며 양쪽의 가용 영역을 기록합니다. 관측 대상 네임스페이스에는 retina.sh=observe를 붙입니다. Helm으로 Retina를 설치하고 MetricsConfiguration에서 수집할 네임스페이스와 출발지·목적지 레이블을 지정한 뒤 Prometheus가 메트릭을 수집하도록 구성합니다.

분석에 사용하는 networkobservability_adv_forward_bytes에는 출발지와 목적지의 파드·네임스페이스·워크로드 정보가 담깁니다. direction 레이블은 목적지 파드 관점의 트래픽 방향을 나타냅니다. 가용 영역 정보는 kube_pod_info로 파드와 노드를 연결하고, kube_node_labels의 topology.kubernetes.io/zone 정보와 결합해 얻습니다.

제시한 PromQL은 바이트 카운터의 변화율을 집계하고 파드별 노드와 가용 영역을 연결합니다. 저자는 출발지와 목적지의 가용 영역이 일치하는 항목을 on() 매칭으로 골라 같은 가용 영역의 트래픽을 계산한다고 설명합니다. 전체에서 이 계산에 포함되지 않는 바이트를 가용 영역 간 트래픽으로 분류하고 Grafana에서 시각화합니다.

6. OpenTelemetry Collector를 기반으로 재설계한 Jaeger v2

원문: Jaeger v2 released: OpenTelemetry in the core! · Jaeger maintainers · 2024-11-12

Jaeger 유지관리자들은 v2에서 OpenTelemetry Collector 프레임워크를 기반으로 구성 요소를 재설계했다고 설명합니다. 수신·처리·내보내기 파이프라인을 재사용하고, Jaeger에 필요한 저장소와 조회 기능을 확장하는 방식입니다. 네이티브 OTLP 처리로 내부 형식 변환 단계를 없애며, 배치 처리 파이프라인을 활용합니다. 인증, 인증서 재로딩, 내부 모니터링과 상태 검사 등 Collector의 기능도 함께 사용합니다.

트레이스 조회와 UI는 Collector extension으로 구현합니다. 저장소도 extension으로 추상화해 조회 구성 요소와 범용 exporter가 같은 저장소에 접근하도록 했습니다. 이 설계는 읽기와 쓰기가 모두 필요한 Jaeger의 특성을 반영하면서 v1의 여러 저장소 지원을 유지합니다. Collector 생태계의 프로세서와 커넥터를 사용할 수 있고, Kafka receiver와 exporter로 기존 collector-ingester 배치 방식도 재현합니다.

배포에는 단일 jaeger 바이너리를 사용하며 YAML 설정으로 collector, ingester, query 등의 역할을 선택합니다. 유지관리자들이 측정한 컨테이너 이미지 크기는 압축된 UI 자산 약 3Mb를 포함해 약 40Mb이며, v1은 약 30Mb였습니다. v2는 기존 Remote·Adaptive head sampling에 더해 OpenTelemetry-contrib 프로세서를 이용한 tail sampling도 지원합니다. 공식 저장소 백엔드의 v1 호환성, 기본·보관 저장소, Service Performance Management도 지원 범위에 포함됩니다.

글은 2.0.0이 Jaeger의 주요 기능을 지원하며, 남은 기능 대응과 성능 개선을 2025년에 이어갈 계획이라고 밝힙니다. Jaeger v2용 Helm chart와 OpenTelemetry Operator의 네이티브 지원은 후속 작업입니다. ClickHouse의 공식 저장소 백엔드 지원도 로드맵에 포함됩니다. 저장소와 UI가 OpenTelemetry 데이터를 네이티브로 사용하도록 바꾸는 작업 역시 이후 계획에 포함됩니다.

7. 옵저버빌리티 비용과 오픈소스 플랫폼의 역할

원문: Datadog is the new Oracle · Peter Zaitsev · 2024-05-20

Peter Zaitsev는 Coroot 블로그에서 옵저버빌리티 비용 문제를 과거 데이터베이스 시장과 비교합니다. 저자는 2000년대 초·중반 Oracle의 높은 비용과 고객에 대한 통제가 데이터 활용과 혁신을 제약했다고 평가합니다. 이어 MySQL과 PostgreSQL 같은 대안이 더 적은 비용으로 데이터를 저장하고 처리하는 기반이 되었다고 설명합니다. Datadog을 둘러싼 고액 청구 사례에서 비슷한 상황을 본다는 것이 글의 주장입니다.

저자는 자신이 만난 사용자들이 예산에 맞추기 위해 관측 범위를 줄였다고 전합니다. 모든 노드와 서비스를 모니터링하지 못하거나, 저장할 로그와 트레이스를 크게 걸러 내는 사례입니다. 애플리케이션의 가용성·성능·보안에 옵저버빌리티가 필수적인 기능으로 인식되지만, 원하는 수준의 관측을 비용 때문에 확보하지 못한다는 문제를 제기합니다.

대안으로는 완성된 오픈소스 옵저버빌리티 플랫폼의 성장을 제시합니다. Prometheus, Grafana, OpenTelemetry 같은 구성 요소는 이미 있지만, Datadog·Dynatrace·New Relic 같은 통합 플랫폼은 대부분 독점 소프트웨어이며 비싸다는 평가입니다. 저자는 Signoz, NetData, Coroot를 오픈소스 또는 오픈코어 대안으로 거론합니다. 글을 쓴 시점부터 향후 5년 동안 이들 플랫폼이 성숙하고 시장에서 상당한 비중을 차지할 것으로 전망합니다.

8. 파드로 실행하는 Kuberhealthy 합성 검사

원문: Kuberhealthy · GitHub

제공된 Kuberhealthy 저장소 README는 합성 모니터링과 지속적 검증을 Kubernetes 리소스로 관리하는 방법을 설명합니다. Kuberhealthy는 검사 파드의 실행 일정을 잡고, 실행 상태와 결과를 관리하는 오퍼레이터입니다. 로그인한 뒤 레코드를 생성하고 확인·삭제하는 것처럼 여러 단계의 사용자 흐름을 검사할 수 있습니다. 검사 로직은 컨테이너에서 실행할 수 있는 언어로 작성하며, Kubernetes 매니페스트로 애플리케이션과 함께 관리합니다.

HealthCheck 사용자 정의 리소스에는 실행할 검사 컨테이너, 실행 주기, 실패로 판단하기까지 기다릴 시간을 지정합니다. 컨트롤러가 일정에 따라 짧게 실행되는 검사 파드를 만들면, 파드가 검증을 수행하고 결과를 보고합니다. 결과는 기본 상태 UI, JSON API, Prometheus 메트릭 엔드포인트에 표시됩니다. 설치 방식으로는 Helm, Kustomize, ArgoCD를 안내합니다.

README의 배포 검사 예제는 테스트용 Deployment를 만들고 롤아웃한 뒤 정리합니다. 실행 주기는 10m, 제한 시간은 5m이며, 복제본 수를 4로 지정하고 롤링 업데이트 검사를 활성화합니다. Prometheus에는 검사 상태를 나타내는 kuberhealthy_check, 실행 시간인 kuberhealthy_check_duration_seconds, 성공 횟수인 kuberhealthy_check_success_total 등을 노출합니다. /json에서는 검사별 오류와 마지막 실행 시각, 실행 시간을 조회할 수 있습니다.

직접 검사를 작성할 때 사용할 Go, Python, TypeScript, JavaScript, Rust, Ruby, Java, Bash 클라이언트도 안내합니다. Go 예제는 내부 API에 HTTP 요청을 보내고 응답 상태가 정상인지 확인한 뒤 성공 또는 실패를 보고합니다. 검사 클라이언트는 KH_REPORTING_URL, KH_RUN_UUID와 실행 기한 처리를 자동으로 담당합니다.

9. EKS 컨트롤 플레인 대시보드와 메트릭 확대

원문: Amazon EKS enhances Kubernetes control plane observability · Ashok Srirama, George John, Leo Li, Prateek Gogia · 2024-11-18

AWS는 EKS 콘솔에 컨트롤 플레인 대시보드를 추가하고, 기존 API 서버 메트릭에 더해 kube-scheduler와 controller-manager 메트릭을 제공합니다. 워크로드의 동작이나 설정 때문에 생기는 스케줄링 지연과 컨트롤 플레인 부하를 사용자가 파악하도록 돕는 기능입니다. Kubernetes 1.28 이상과 지원되는 플랫폼 버전을 사용하는 클러스터에 적용하며, CloudWatch의 AWS/EKS 네임스페이스에 제공하는 해당 메트릭은 추가 요금이 없습니다.

대시보드에는 API 요청의 전체 건수와 HTTP 4XX·5XX·429, etcd 데이터베이스 크기, 스케줄링 시도 등이 표시됩니다. 컨트롤 플레인 로그를 활성화하면 CloudWatch Logs Insights의 준비된 쿼리로 요청이 많은 주체, 느린 요청, 제한된 클라이언트, 고장 난 webhook을 분석할 수 있습니다. CloudWatch 메트릭으로 스케줄러 지연이나 API 서버 요청 제한 오류에 대한 알람도 구성합니다.

Prometheus 수집용 메트릭은 metrics.eks.amazonaws.com API 그룹에 노출합니다. kube-scheduler 경로는 /apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics, controller-manager 경로는 /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics입니다. 글은 AWS 관리형 수집기로 이를 Amazon Managed Service for Prometheus에 보내고 Grafana에서 조회하는 과정을 보여 줍니다. 자체 운영하는 kube-prometheus-stack에서는 해당 API 그룹의 kcm/metrics, ksh/metrics 조회 권한과 ServiceMonitor를 추가합니다.

실습은 워커 노드 2개인 클러스터에 복제본 500개의 Deployment를 만들어 대기 파드를 발생시킵니다. 이후 스케줄링 지연, 재시도, 큐별 대기 파드를 메트릭으로 확인합니다. 기능은 상용·중국·AWS GovCloud(US) 리전에 제공되며, EKS가 노출하는 범위는 사용자가 조치할 수 있도록 선별한 메트릭입니다. AWS는 성능 문제를 피하기 위해 Prometheus 수집 간격을 1초 미만으로 설정하지 않도록 권고합니다.

10. EBS 상세 성능 통계의 Prometheus 수집

원문: Monitor EBS Detailed Performance Statistics with Amazon Managed Service for Prometheus · Mike George, Girish B, Eddie Torres · 2024-11-20

AWS는 EKS 워크로드의 EBS 상세 성능 통계를 Amazon Managed Service for Prometheus에 수집하는 절차를 소개합니다. EBS 상세 성능 통계는 1분 미만의 세분성으로 11개 메트릭을 제공해 볼륨의 I/O 상태를 살펴보게 합니다. AWS는 이전에 세밀한 볼륨 관측을 위해 여러 시스템 도구를 조합해야 했던 작업을 이 통계로 수행할 수 있다고 설명합니다.

준비에는 EKS 클러스터, OIDC 설정, EBS CSI Driver용 IAM 역할, Amazon EBS CSI Driver가 필요합니다. Prometheus 워크스페이스와 EKS의 AWS 관리형 수집기도 미리 구성해야 합니다. 글은 OIDC로 Kubernetes 서비스 계정과 IAM 역할을 연결하고, CSI Driver가 스토리지 볼륨에 접근하도록 권한을 부여하는 순서로 안내합니다.

메트릭 활성화 단계에서는 aws-ebs-csi-driver 애드온의 v1.37.0 이상을 확인하고, 고급 설정에 node.enableMetrics: true를 지정해 애드온을 갱신합니다. 이 설정이 노드 플러그인의 상세 성능 통계 수집을 활성화합니다. 앞서 관리형 수집기를 구성한 상태라면 메트릭이 자동으로 수집되어 Prometheus 워크스페이스로 전송됩니다.

검증은 CSI 노드 파드의 3302 포트를 포워딩하고 /metrics를 조회하는 방식입니다. 출력의 nvme_collector_scrapes_total로 수집 동작을 확인하며, Grafana에서는 Prometheus 워크스페이스를 데이터 소스로 연결해 nvme_read_bytes_total 같은 볼륨 메트릭을 조회합니다. AWS는 이 통계가 볼륨 성능의 영향과 처리량 한도 초과를 파악하는 데 쓰인다고 설명합니다. 메트릭 자체는 무료지만 Prometheus 워크스페이스에는 수집한 메트릭 수와 사용한 저장 공간에 따른 요금이 부과됩니다.