Spring Boot

모니터링 vs 가시성(Observability) (feat. OpenTelemetry)

최-코드 2024. 9. 14. 17:37
메트릭(Metrics): 성능 지표로, 시스템의 성능 및 효율성을 수치적으로 표현합니다. 예를 들어 CPU 사용률, 메모리 사용량, 응답 시간, 트랜잭션 성공률이 있다.
로그(Logs): 시스템에서 발생하는 각종 이벤트나 오류 정보를 기록합니다. 각 이벤트의 구체적인 내용이나 원인을 추적하는 데 중요합니다.
분산 추적(Tracing): 특히 마이크로서비스와 같은 분산 시스템에서, 요청이 서비스 간에 어떻게 이동하는지를 추적하여 성능 병목이나 지연의 원인을 파악할 수 있습니다.

 

모니터링

  • 주된 목표는 시스템의 현재 상태를 지속적으로 추적하고 이상 상태를 감지하는 것이다.
  • 주로 사전 정의된 메트릭에 초점을 맞춘다. 
  • 정해진 규칙에 따라 경고를 발송하거나 자동화된 대응을 트리거하는데 사용된다.
  • 예기치 않은 문제를 진단하는 데는 한계가 있다.

 

가시성 

  • 주된 목표는 시스템의 상태를 추적하는 것 이상으로, 시스탬 내부의 동작 방식과 상호작용을 깊이 이해하는데에 있다.
  • 예기치 않은 문제나 미리 정의되지 않은 상태를 분석할 수 있는 능력을 제공한다.
  • 가시성은 메트릭 뿐만 아니라 로그, 트레이스 등 다양한 데이터를 수집하고 상관관계를 분석하여 시스템의 내부 상황을 확인한다.
  • 동적이고 복잡한 시스템의 상호작용을 이해하는데에 초점을 맞추며, 특히 분산 시스템(마이크로서비스)에서 요청이 어떻게 처리되는지 분석할 수 있다.

 

모니터링 vs 가시성 예시(미리 정의되지 않은 상태 분석)

1. 모니터링만으로 분석하는 경우

모니터링 도구에서 CPU 사용률, 메모리 사용량, 응답 시간 등의 메트릭을 수집하여 애플리케이션을 모니터링하고 있다고 가정해보자.

  • 갑자기 시스템의 전체 응답 시간이 평소보다 2배 이상 느려졌다.(예기치 못한 문제 발생)
  • 모니터링 도구에서 CPU 사용률이 급격히 상승하고 있다는 경고가 발생했다.
  • 하지만 각 마이크로서비스의 CPU 사용률, 메모리 사용량은 정상적으로 보인다. 각 서비스의 메트릭만 확인할 때는 어느 부분에서 문제가 발생하고 있는지 쉽게 파악하기 어렵다.

이 상황에서는 모니터링 시스템을 통해 CPU 사용률이 높아졌다는 정보는 알 수 있지만, 어떤 요청이 문제를 유발했는지, 왜 전체 응답 시간이 느려졌는지를 분석하기는 어렵다.

 

2. 트레이싱을 사용한 가시성으로 분석하는 경우

이제 같은 상황에서 트레이싱 도구를 사용해 문제를 분석하는 예시이다.

  • 분산 트레이싱 도구를 사용하면, 개별 주문 요청이 여러 마이크로서비스를 어떻게 거치는지 추적할 수 있다.
  • 트레이싱 도구는 주문 요청이 사용자 서비스 → 상품 서비스 → 결제 서비스 → 배송 서비스 순으로 처리되는 과정을 시각적으로 보여준다.
  • 트레이싱 결과, 요청이 상품 서비스에서 처리될 때 특정 상품에 대한 재고를 조회하는 동안 지연이 발생하고 있음을 발견합니다. 즉, 상품 서비스의 데이터베이스 쿼리가 느리게 동작하고 있는 것을 알 수 있다.

 

OpenTelemetry 개념 : 트레이스, 매트릭, 로그와 같은 데이터를 계측, 생성, 수집 및 내보내기를 위한 특정 벤더에 종립되지 않은 오픈소스 Observability framework이다. 내보내기의 경우 jaeger , zipkin 같은 다양한 백엔드 시스템에 내보낸다. 트레이싱에 초점이 맞춰져 있다.

 

애플리케이션 계측이란 애플리케이션 실행 중 성능, 상태, 동작을 모니터링할 수 있도록 하는 측정, 기록하는 과정이다. 
전통적인 모니터링 솔루션은 각각의 시스템이나 언어에 맞게 계측 방식을 달리해야 했다. 이는 여러 언어와 서비스로 구성된 마이크로서비스 환경에서 관리하기 어렵고, 데이터 분석과 모니터링에 불일치를 초래할 수 있다.

 

OpenTelemetry 주요 목적

  • 애플리케이션 계측의 표준화 : 여러 언어, 프레임워크, 플랫폼에 걸쳐 일관된 계측 표준을 제공하여 개발자가 복잡한 설정을 할 필요 없이 손쉽게 계측 코드를 추가할 수 있다. 
  • 자동 계측 : 코드 수정 없이 OpenTelemetry 에이전트를 통해 자동으로 트레이스, 메트릭을 수집할 수 있다.
  • 유연한 통합 : 다양한 백엔드 시스템(예: Jaeger, Prometheus, Zipkin)과의 호환성을 제공하며, 데이터를 중앙 집중식으로 수집하여 모니터링하고 분석할 수 있다.

OpenTelemetry 구조

  • API : 애플리케이션이 데이터를 생성하는 표준화된 인터페이스를 제공한다. 개발자는 OpenTelemetry API를 사용하여 직접 트레이스, 메트릭, 로그 데이터를 생성할 수 있다.
  • SDK : API를 언어마다 구현한 구현체로서 실질적으로 이를 통해 데이터를 생성한다.
  • Collector : 데이터를 중앙에서 수집하고, 필요한 경우 추가 처리(집계, 필터링 등)를 한 뒤 Exporter에 전송한다. 별도의 프로세스에서 실행되며, 애플리케이션 외부에서 동작하기 때문에 애플리케이션에 부하를 주지 않고 데이터를 처리할 수 있다. 이 때 Collector를 경우하지 않고 바로 내보내기할 수 있다.
  • Exporters : 수집된 데이터를 다양한 백엔드 시스템으로 전송하는 역할을 한다. 이는 별도의 프로세스가 아닌, SDK, Collector 내에서 동작하는 모듈이다.

OpenTelemetry 주요 기능

  1. 분산 추적
    • OpenTelemetry는 분산된 애플리케이션에서 개별 요청이 시스템을 어떻게 통과하는지를 추적할 수 있도록 한다.
    • span이라는 단위를 사용하여 요청이 (마이크로)서비스를 거쳐갈 때의 경로와 시간을 기록한다. 
    • 각 span은 trace의 일부이며, 요청이 여러 서비스나 컴포넌트를 통과할 때 발생하는 모든 스팬이 모여 하나의 트레이스를 형성한다.
    • 이를 통해 어떤 서비스에서 지연이나 병목이 발생했는지 쉽게 파악할 수 있다.
  2. 매트릭 수집
    • 시스템의 성능 상태를 모니터링할 수 있는 메트릭을 수집한다.
    • 메트릭은 시간 경과에 따라 변화를 추적할 수 있으며, 이를 통해 시스템의 성능을 지속적으로 모니터링할 수 있다.
  3. 로그 수집
    • 시스템에서 발생하는 로그 데이터를 수집하고, 이 로그를 다른 텔레메트리 데이터와 연결하여 문제의 원인을 분석하는데 사용할 수 있다.
    • 특히, 분산 시스템에서 발생하는 로그와 트레이스를 연결하면, 특정 요청이 처리되는 동안 발생한 모든 로그를 쉽게 추적할 수 있다.

OpenTelemetry와 다른 도구의 통합

  • Prometheus: 메트릭 데이터를 수집하고 시각화
  • Grafana: Prometheus와 결합하여 메트릭을 시각화하거나, Grafana Loki와 통합하여 로그를 시각화
  • Jaeger 또는 Zipkin: 분산 트레이싱 데이터를 수집하고 시각화하는 도구로, OpenTelemetry와 쉽게 연동
  • Elasticsearch: 로그 데이터를 저장하고 검색할 수 있는 강력한 로그 관리 시스템