모니터링 서버(1)

한창 사이드 프로젝트 중이다. 목표는 기능 구현에 그치지 않고 트래픽 제어 및 성능 향상까지 바라보는 중이라서, 다들 기능 구현에 집중하고 있을 때 정도 대신 사파를 지향하는 나는 성능 계측 및 서버 모니터링을 위한 작업을 먼저 선행하면 어떨까... 생각하고 작업에 들어갔다. 마침 작업도 약간 지지부진해던 찰나여서 미리 모니터링을 세팅해서 서버 가용성 및 트래픽 등을 계측할 수 있도록 대비해야겠다고 생각했다.

1. 모니터링 수단

모니터링이라 함은, 특정 대상에만 한정되는 것이 아닌 모니터링 대상의 시스템, 메트릭 등 다양한 정보들을 수집해서 서버의 가용성을 높게 유지하는 데에 일조하는 것을 목표로 한다. 정확히는 시스템 모니터링을 통해 서버, 네트워크, 데이터베이스, 애플리케이션 등 IT 인프라의 전반적인 상태와 성능을 감시하고, 메트릭 모니터링을 통해 시스템, 애플리케이션, 비즈니스 프로세스의 특정 성능 지표(메트릭)를 수집하는 것이다.

모니터링을 수행할 수 있는 수단에는 프로메테우스 & 그라파나, TICK 스택 등이 있는데 이 둘에 대해서 간단하게 비교를 하고 직접 모니터링 서버를 구축하는 작업을 진행할 예정. 사실 내가 말한 수단들에는 이미 모니터링 수집 정보들에 대한 출력 및 도표화가 잘 정리되어 있다. 그라파나, 키바나 등의 출력 수단들은 이미 내가 생각한 것들을 보유하고 있다. 그래서 괜히 바퀴를 발명하려고 하는 게 아닌가 싶었다.

그렇지만, 개인적으로 느꼈던 기존의 모니터링 툴은, 러닝 커브가 너무 높으며 너무 많은 정보들은 오히려 불필요한 정보들이 과하게 포함되었다는 것이었다. 예전에 트래픽 제어 프로젝트를 했을 때, 모니터링을 구축했지만 이걸 유의미하게 활용하지는 못했다. 그라파나 대시보드를 이해하지 못했으니...

여튼 위와 같은 이유로, 직접 모니터링 서버를 구축해서 로그를 히카리풀에 출력하는 과정을 밟아보려고 한다.

2. 모니터링 툴

모니터링 방식에는 애플리케이션에서 필요한 데이터들을 직접 모니터링 시스템으로 보내주는 Push based 방식과 모니터링 시스템에서 모니터링할 애플리케이션에 직접 접속하여 필요한 데이터를 가져가는 Pull based 방식이 있다. 위에서 언급했던 TICK 스택이 Push 방식에 해당되고, 프로메테우스 & 그라파나가 Pull 방식에 해당된다.

1) TICK 스택

Telegraf는 메트릭과 이벤트를 수집하여 InfluxDB로 보내주는 역할을 하고, InfluxDB에 저장된 데이터를 Chronograf를 통해 웹으로 시각화한다. Kapacitor는 필수요소는 아니고 선택사항이며 이벤트 발생을 감지하고 사용자에게 알리는 역할을 맡는다.

2) 프로메테우스 & 그라파나

각 서버에 클라이언트를 띄우고, 서버가 클라이언트에 주기적으로 접속해 데이터를 Pull 방식을 통해 메트릭 정보를 가져온다. 수집된 메트릭을 이용하면 애플리케이션의 각 시스템에서의 대기 시간과 처리하는 데이터의 양을 추적해서 성능 저하의 원인이 정확히 무엇인지 손쉽게 확인이 가능해진다.

이외에도 DataDog 등의 다양한 모니터링 툴이 존재하며, 향후 MSA를 고려했을 때에는 모니터링 외에도 로깅, 트레이싱 등까지 같이 고려되어야 한다.

3. 툴 선택 및 모니터링 아키텍처

위에 언급한 각각의 툴들에는 장단점이 존재하며, 심지어 처음에는 툴 없이 직접 메트릭 정보를 수집하는 서버를 구현할까... 생각했지만 이건 너무 에바세바참치 같아서 최소한의 모니터링 툴로 메트릭 정보는 수집하되, 거기에서 내가 요구하는 커스텀 메트릭 정보를 조회 및 데이터베이스에 저장시키고 그것과 관련된 필요한 로직을 구현하는 것으로 방향을 잡았다.

하여, 의존하려는 모니터링 툴은 프로메테우스로 선택했다. 현재 및 향후 완성될 프로젝트의 규모를 고려했을 때, Pull-based 방식이어서 모니터링 대상인 앱 서버에 대한 추가적인 부하를 걸지 않으며, 인프라가 광범위하지 않다는 장점을 고려했다.

1) 프로메테우스 중심 아키텍처

현재 개발하는 프로젝트는 스프링부트를 기반으로 진행되고 있다. 스프링 액추에이터를 활용하면 메트릭 정보를 노출시킬 수 있고, 이걸 프로메테우스가 포착해서 PromQL을 기반으로 선별적인 메트릭 정보를 가져올 수 있다.

현재의 모니터링 모식은 위와 같으며, 사실 모니터링 정보를 수집할 때도 리소스 공유가 발생하지 않는 것이 좋기 때문에 별개의 EC2 인스턴스 등을 띄워서 구축하는 것이 옳으나 우선은 내 로컬에서 커스텀된 모니터링 서버를 구축할 예정.

2) 커스텀 모니터링 서버

가상의 앱 서버는 예전에 구축해둔 간단한 JPA 기반 도서 대여 관련 서버를 바탕으로 프로메테우스 및 그라파나를 구축하고, 구축된 프로메테우스로부터 커스텀 모니터링 서버가 WebFlux를 통해 정보를 가져오는 방식을 채택한다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    implementation 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

    // WebClient 사용을 위한 의존성
    implementation 'org.springframework.boot:spring-boot-starter-webflux'
    
    // ...

의존성에 WebFlux가 포함된 이유는 WebFlux의 비동기적이고 논블로킹(non-blocking) 특성 때문이다. 이를 통해 HTTP 요청을 통해 프로메테우스의 API 엔드포인트에 접근하여 메트릭 데이터를 비동기적으로 가져오게 된다.

(1) WebFlux와 비동기 처리

Spring WebFlux는 리액티브 프로그래밍 모델을 기반으로 하며, 비동기적이고 논블로킹 방식으로 HTTP 요청을 처리하는데 전통적인 서블릿 기반의 Spring MVC와는 달리, WebFlux는 이벤트 루프를 통해 처리하며 대규모 동시 요청을 효율적으로 처리할 수 있다.

리액티브 스트림(Reactive Streams)

WebFlux는 Publisher, Subscriber, Flux, Mono 등의 리액티브 스트림 API를 사용하여 데이터 스트림을 처리하며 이러한 리액티브 타입을 통해 프로메테우스와 같은 외부 시스템과 통신할 때 비동기적으로 데이터를 가져올 수 있다.

비동기적으로 데이터가 수집되면서 확장성, 성능 측면에서 유리함을 가질 수 있고 향후 MSA에서도 활용이 가능하다.

(2) WebClient를 통한 HTTP 요청

WebFlux의 핵심 컴포넌트 중 하나인 WebClient는 HTTP 클라이언트로, 비동기 방식으로 HTTP 요청을 보낼 수 있다. 이를 사용하여 프로메테우스의 API 엔드포인트에 요청을 보내고, 응답으로부터 메트릭 데이터를 받아올 수 있게 된다.

(3) 프로메테우스 API와의 통합

프로메테우스는 메트릭 데이터를 쿼리할 수 있는 HTTP API를 제공하는데, 이를 통해 프로메테우스 서버에서 데이터를 직접 가져올 수 있게 된다.

/api/v1/query와 같은 엔드포인트를 통해 PromQL 쿼리를 실행하고, 해당 결과를 JSON 형태로 반환하면서 메트릭 정보를 커스터마이징 하는 데에 활용할 수 있게 된다.