[Observability] Observability & Push and Pull Method

Sunwu Park·2024년 12월 5일

Observability

목록 보기

1/3

서론

프로젝트를 진행함에 있어 이번에는 라즈베리파이 서버 위에서 실행을 하고 있다. 하지만 이 서버들이 불안정한 서버위에서 동작을 하다보니깐 이것이 정말 잘 동작을 할 것인가? 언제 에러가 날것인가? 에 대해서 실시간으로 알람의 필요성도 느꼈고 또한 서버가 꺼지면 자동으로 재시작이 되면서 다시 잘 실행중이다 라는 것을 알고싶었다. 또한 각 서버들이 얼마나 많은 리소스들을 잡아먹는지, 커넥션 풀에서 에러는 없는지 등의 다양한 고민거리가 있었고 이에 있어 기존에는 그저 메트릭, 로그들을 보기만 하였으나 정확한 Observability의 개념은 무엇이고 어떻게 하면 이와 같은 고민을 해결할 수 있을지, 어떤 서비스들이 있는지들을 알아보려고 한다

Observability(옵저버빌리티)?

출력으로 시스템을 얼마나 잘 이해할 수 있는가? 라는 것이다. 즉, 로그, 메트릭, 트레이스등 다양하게 생성된 데이터를 기반으로 시스템을 분석하고 최적화할 수 있는 접근방식을 제공하는 것이다. 이와 같은 방식을 통해 애플리케이션, 인프라에 대한 질문을 하여 시스템의 동작을 이해하고 성능 개선할 수 있는 방향성을 제공하는 것이다.

현재의 시스템들은 보통 쿠버네티스 클러스터와 클라우드 인프라에 복잡하게 마이크로서비스 형태로 실행되고 있다. 전체 소프트웨어 배포 프로세스가 빠르고 많기 때문에 문제가 발생을 하였을때 감지하기가 어렵다고 한다. 옵저버빌리티 솔루션이 없다면, 이러한 복잡한 분산 시스템에서 작업할 때, 체인의 어느 부분이 끊어졌는지를 발견해낸다는 것이 거의 불가능하다.

Observability vs Monitoring

모니터링이란?
어떠한 대상을 감시 한다는 뜻으로 대상의 상태, 가용성, 변화 등을 확인하고 대비하는 것이다!. 즉 "어떤 대상의 상태나 상황을 지속적으로 감시, 관찰하여 예기치 못한 상황과 오류를 대비하고 극복한다"

Observability vs Monitoring: 무엇이 다를까?

소프트웨어 시스템이 복잡해지고 분산화되면서, 모니터링과 옵저버빌리티는 시스템의 신뢰성을 유지하는 데 핵심적인 역할을 한다. 하지만 두 개념은 목적과 기능에서 큰 차이가 있다.

Monitoring: 알려진 문제를 추적하는 도구

모니터링은 시스템에서 이미 알고 있는 문제나 이상 행동을 추적하는 데 초점을 맞춘다

한계점:
- 사전에 정의된 임계값(threshold)이나 변화율(rate-of-change) 위반에 기반한 알림만 제공.
- 알려지지 않은 문제를 탐지하거나 근본 원인을 파악하는 데는 적합하지 않다.
- 분산 시스템 환경에서는 각 구성 요소의 신호를 개별적으로 관찰하기 때문에, 전체 시스템의 상태를 이해하기 어렵다.

Observability: 더 깊은 통찰을 제공하는 개념

옵저버빌리티(Observability)는 모니터링을 넘어, 알려지지 않은 문제를 탐지하고 근본 원인을 이해하는 데 초점을 둔다.

특징:
- 단순히 "문제가 발생했다"는 것을 넘어 왜 문제가 발생했는지를 이해할 수 있는 역량을 제공
- 분산 시스템에서 예상치 못한 패턴을 파악할 수 있는 유연성을 제공
- 시스템의 상태와 성능에 대한 더 깊은 통찰을 통해 고객 경험을 개선합니다.

옵저버빌리티의 핵심 요소: MELT

옵저버빌리티는 다음 네 가지 요소로 구성됩니다. 이를 합쳐서 MELT라고 부릅니다:

Metrics (메트릭):
- 수치화된 데이터로 시스템의 성능을 나타냄
- 예: CPU 사용률, 메모리 사용량, 요청 처리 시간
Events (이벤트):
- 시스템에서 발생한 특정 활동이나 상태 변화
- 예: 사용자 로그인, 데이터베이스 갱신
Logs (로그):
- 시스템이 수행한 작업의 기록으로, 디버깅 및 문제 분석에 사용
- 예: 에러 메시지, 요청 응답 정보
Traces (트레이스):
- 분산 시스템에서 요청의 흐름을 추적
- 예: 서비스 간 호출 체인

MELT는 시스템의 상태를 이해하는 데 중요한 역할을 하지만, 고품질 소프트웨어 시스템을 설계하고 운영하기 위해서는 MELT만으로는 충분하지 않다.

옵저버빌리티를 극대화하는 방법: 개방형 계측(Open Instrumentation)

개방형 계측은 애플리케이션 코드 또는 에이전트를 사용하여 시스템 내 데이터 흐름을 추적하고 측정하는 방식이다. 특정 공급업체에 종속되지 않고 데이터를 수집할 수 있다.

대표적인 개방형 계측 도구

오픈텔레메트리(OpenTelemetry):
- 분산 시스템의 메트릭, 로그, 트레이스를 통합적으로 수집, 처리, 전송하는 오픈소스 프레임워크.
- 다양한 언어와 라이브러리를 지원하며, 특정 벤더에 의존하지 않는 텔레메트리 데이터 처리를 제공
프로메테우스(Prometheus):
- 메트릭 수집 및 쿼리를 위한 강력한 오픈소스 도구.
- 주로 메트릭 기반 모니터링에 사용되며, Grafana와 같은 대시보드 도구와 통합하여 시각화 가능.

Metric 수집 방식

Push vs Pull based System

Pull Based System: 능동적으로 지표를 획득하는 시스템

수집 서버에 대한 정보를 agent나 서비스들이 알지 못함

Push Based System: 모니터링이 필요한 오브젝트가 적극적으로 지표를 푸시

수집 서버의 정보 + Agent에는 System Agent가 설치

중앙에 있는 서버에 메트릭을 보내야하므로 서버의 End-Point IP를 알아야한다.

Pull

프로메테우스와 같은 모니터링 백엔드와 함께 일반적으로 배포되는 Pull Module(Service Discovery System)에 연결
Remote End에서 데이터를 Pull하기 위해 공통 프로토콜을 사용
Application-end SDK 는 풀을 위한 고정 포트를 제공

SDK는 애플리케이션 내부에서 메트릭 데이터를 수집하고 HTTP를 통해 특정 고정된 포트에서 제공

예: http://<application_host>:<fixed_port>/metrics
Prometheus 설정 파일 (prometheus.yml)에서 Spring Actuator의 엔드포인트를 다음과 같이 등록:
  scrape_configs:
    - job_name: 'spring_app'
      static_configs:
        - targets: ['<application_host>:<port>']

Prometheus의 Pull 프로토콜과 호환되지 않는 경우 Exporter(Agent)라는 중간 단계를 도입
Exporter는 해당 시스템의 메트릭을 수집하고, 이를 Prometheus가 읽을 수 있는 표준 Pull 인터페이스로 변환하는 역할

PUSH

Push Agent는 모니터링되는 다양한 오브젝트의 메트릭 데이터를 가져와 서버에 푸시 지원
애플리케이션 내부에 통합 OR 애플리케이션과는 분리된 독립 실행형 에이전트
Application-end SDK는 모니터링 백엔드나 로컬 에이전트로의 데이터 전송을 지원

ConfigCenter (Optional)

역할:
- Push Agent의 동작 방식을 중앙에서 동적으로 관리하고 구성할 수 있도록 도와주는 도구
- 메트릭, 수집 주기, 필터링 규칙 등
- 모니터링 대상이 많거나 복잡한 환경에서도 중앙에서 손쉽게 관리

Pull Distributed Solution

Push는 기본적으로 데이터 수집이 분산되기때문에 수평적확장이 가능하지만 Pull 방식에서는 더 복잡
Pull Module이 모니터링 백엔드와 분리, Pull은 에이전트 별로 배포
Service Discovery system 으로 부터 모니터링되는 시스템 목록을 가져오고 이러한 시스템에서 해시 모듈 작업을 수행하고 Pull through 샤딩을 담당하는 에이전트를 확인

샤딩(Sharding)의 역할

샤딩은 모니터링 대상을 특정 기준으로 나누고, 각 Pull Agent에 작업을 분배하는 방식

해시 기반 샤딩: 해시 함수로 모니터링 대상을 나누어 각 Agent에 할당.
작업 분배: 각 Agent는 자신에게 할당된 대상만 데이터를 요청(Pull)하여 중복 없이 처리.
Configuration center(optional)을 추가해서 각 Pull agent를 관리할 수 있음

Configuration Center는 Pull Agent의 작업을 중앙에서 동적으로 관리하는 시스템

Pull Agent가 수집해야 할 대상 목록, 수집 주기 등을 중앙에서 정의
모니터링 대상이 변경되더라도 자동으로 조정하여 유연성을 제공

단일 지점 병목 현상이 여전히 존재하며, 모든 agent가 service discovery module을 요청해야 한다.
agent가 확장되면, 모니터링 대상이 변경되어, 데이터 중복 또는 누락이 발생

Monitoring Capabilities Comparison

모니터링 시스템에서 Pull과 Push 방식의 주요 특징을 비교하고, 각각의 장단점과 적용 사례를 정리했습니다.

전략	장점	단점
Push 기반 전략	1️⃣ 낮은 지연 시간: 데이터가 즉시 클라이언트로 전달되어 실시간 업데이트 가능.	1️⃣ 확장성 문제: 다수의 클라이언트를 관리해야 하는 서버의 리소스 부담이 증가.
	2️⃣ 클라이언트 복잡성 감소: 클라이언트는 데이터를 요청할 필요 없이 수동적으로 수신.	2️⃣ 네트워크 혼잡: 빈번한 데이터 전송으로 네트워크 과부하 발생 가능.
	3️⃣ 이벤트 기반 아키텍처에 적합: 특정 이벤트 발생 시 즉각적으로 반응해야 하는 시스템에서 자연스럽게 활용.	3️⃣ 데이터 손실 위험: 클라이언트가 업데이트 속도를 따라가지 못하면 중요한 데이터를 놓칠 가능성.

전략	장점	단점
Pull 기반 전략	1️⃣ 자원 효율성: 필요한 경우에만 데이터를 가져오므로 서버와 네트워크 리소스 절약.	1️⃣ 높은 지연 시간: 데이터가 즉시 제공되지 않아 클라이언트는 다음 요청 시점까지 대기해야 함.
	2️⃣ 로드 분산 가능: 클라이언트가 데이터 요청 시점을 결정하므로 서버 부하를 균등하게 분산 가능.	2️⃣ 복잡한 클라이언트 로직: 클라이언트가 데이터 요청, 에러 처리, 갱신 주기 관리 로직을 직접 구현해야 함.
	3️⃣ 점진적 성능 저하 처리 용이: 서버가 일시적으로 다운되더라도 클라이언트가 캐시된 데이터나 재시도를 통해 동작 가능.	3️⃣ 확장성 문제: 클라이언트의 잦은 요청이 서버에 과부하를 유발할 수 있음.

항목	Pull Mode	Push Mode
생존 가능성 확인	타겟 지표 요청 실패 시 오류로 쉽게 원인 파악 가능	보고되지 않을 경우 원인 파악이 어려움
데이터 완전성 계산	실패율을 계산하여 불완전성을 명확히 파악 가능	데이터 Push 간격/지연으로 인해 계산 비용이 높음
짧은 생명 주기/서버리스 모니터링	일반 Pull 모델로는 어렵고 Push Gateway 등 추가 계층 필요	애플리케이션이 사전 예방적으로 Push 가능, 짧은 주기에 적합
유연성	지표 구성, 2차 처리 등 유연하며 백엔드와 결합도가 낮음	Configuration Center를 활용해 유연성 확보 가능, 그러나 백엔드 주소 및 인증 정보 필요

Push는 짧은 수명 주기와 유연한 애플리케이션에 적합
Pull은 데이터 완전성 관리와 타겟 생존 가능성 확인에서 유리

Resource and O&M Cost Comparison

항목	Pull Mode	Push Mode
Resource Cost	모니터링 시스템 측 비용 높음, 애플리케이션 측 낮음	Push Agent 측 비용 높음, 모니터링 시스템 측 낮음
O&M Cost	유지보수 대상이 많아 복잡 (Exporters, SD 등)	유지보수 대상이 적고 간단 (Push Agent, Backend 등)
네트워크 고려	클라이언트-서버 간 ACL 등 복잡한 네트워크 설정 필요	도메인 이름만 설정하면 간단한 네트워크 연결

DevOps Observability (2) — Prometheus, By: 민인아
[Monitoring] Prometheus 총 정리 - Hoon
[Monitoring] Pull vs Push 동작 방식 및 원리 이해 - Hoon