개발자들이 안심할 수 있는 삐삐 서비스 만들기 1탄 (프로메테우스, 그라파나)

들어가기 전에

서비스 런칭 초기 유저가 급격히 유입되었지만, 사소한 버그가 유저 경험에 악영향을 미쳐 유저 이탈이 발생하는 것을 종종 보았습니다. 실제로 삐삐 서비스(https://bibbi.app/) 배포 이후 발생한 버그를 뒤늦게 발견하고 일하던 중 급히 뛰어나가 전화를 돌리며 문제를 파악하고 핫픽스 하는 경험을 했고.... 🥲 이로인해 팀 내에서 서비스 모니터링이 필요하다는 의견이 나왔습니다.

 

실제로 서비스를 운영하고 많은 양의 트래픽이 발생하면서 기존의 스프링 부트 터미널 로그로는 에러 추적이나 트래픽 관측이 불가능하다고 느꼈습니다. 실시간으로 많은 양의 로그가 쌓이고 있기 때문에 터미널에서 plain text로부터 원하는 데이터를 찾는 것은 굉장히 어려웠고, 24시간 로그를 확인할 수 없는 노릇이니 트래픽을 모니터링할 수 있는 대시보드와 경보 시스템도 필요했습니다.

 

따라서 다양한 모니터링 시스템을 추가해왔는데, 당시에는 몰랐지만 이 작업들이 말로만 듣던 SRE(Site Reliability Engineering)이었던 것 같습니다. 모니터링 시스템을 통해 예외와 에러를 감지하고, 감지한 데이터들을 담당 팀원에게 전달하여 디버깅할 수 있도록 도와주었습니다. 본 게시글들을 통해 모니터링 시스템을 구축하는 과정과 저만의 노하우를 공유해보고자 합니다.

 

 

 

---

프로메테우스 & 그라파나 도입

첫 모니터링 시스템은 프로메테우스 & 그라파나를 통한 트래픽 모니터링 대시보드였습니다. 추가적인 서비스 유지 비용없이 클라우드 크레딧으로 구현하길 원했기 때문에, 오픈소스이면서 스프링 부트와 호환성이 높은 프로메테우스와 PromQL만 알면 다양한 대시보드를 손쉽게 꾸밀 수 있으며 프로메테우스와 호환성이 좋은 그라파나를 선택하였습니다.

 

또한 클라우드 크레딧과 비용 관계에 따라 인프라를 자주 이관할 것이 예상되었기 때문에, 컨테이너 기반으로 시스템들을 관리했으며, 불필요하게 시간이 소요되는 네트워크 설정은 솔루션에 맡기기 위해 Nginx Proxy Manager을 도입했습니다.

삐삐 서비스의 프로메테우스 & 그라파나 시스템 아키텍처

 

 

Nginx Proxy Manager 설치

백엔드를 배포해본 사람이라면 HTTPS 연결을 위해 한 번쯤은 Let's Encrypt나 ACME와 씨름해보았을 것 입니다. 하지만 모니터링 백오피스를 위해 프록시, SSL에 시간을 쓰긴 아깝죠. Nginx Proxy Manager는 nginx의 GUI 솔루션으로서, nginx.conf 를 통한 프록시 설정을 간단한 UI를 통해 가능케하며 Let's Encrypt기반 인증서 설정이 원클릭으로 가능합니다. 이에 대한 자세한 설정 가이드는 이후 별도의 게시글로 정리해보겠습니다.

 

1. docker-compose-nginx.yml 작성 및 실행

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx
    restart: always
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./nginx/data:/data
      - ./nginx/letsencrypt:/etc/letsencrypt

• restart: always : 인스턴스가 재부팅하더라도 프록시 컨테이너가 늘 재실행하도록 설정
• ports: - '81:81' : Nginx Proxy Manager 콘솔 디폴트 포트
• volumes: - ~ : 컨테이너 이미지를 내려받을 때 자동으로 다운로드되는 패키지 파일들 (매핑하는 좌측 소스 디렉토리는 자유롭게 변경 가능)

 

2. Let's Encrypt 기반 SSL 인증서 설정

 

3. 호스트 프록시 설정

 

 

프로메테우스 & 그라파나 설치

함께 사용하는 프로메테우스와 그라파나는 하나의 docker compose 파일에 관리하였습니다.

 

1. ./monitor, ./monitor/prometheus.yml 생성

2. docker-compose-monitor.yml 작성 및 실행

version: '3'

services:
        prometheus:
                image: prom/prometheus
                container_name: prometheus
                volumes:
                        - ./monitor/prometheus.yml:/prometheus/prometheus.yml:ro
                        - /root/ecs-discovery/ecs_file_sd.yml:/etc/prometheus/bibbi.yml:ro
                ports:
                        - 8080:9090
                command:
                        - "--web.enable-lifecycle"
                restart: always
                networks:
                        - promnet
                user: root

        grafana:
                image: grafana/grafana
                container_name: grafana
                volumes:
                        - ./monitor/grafana-volume:/var/lib/grafana
                restart: always
                environment:
                    GF_SERVER_ROOT_URL: <https://grafana.no5ing.kr:443>
                    GF_SERVER_DOMAIN: grafana.no5ing.kr
                networks:
                        - promnet
                ports:
                        - 8070:3000
                user: root

networks:
        promnet:
                driver: bridge

• volumnes: ./monitor/prometheus.yml:~~ : 메트릭 포링 주기 등의 프로메테우스 설정값을 담은 파일
• ports: -8080:9090 ports: -8070:3000 : 프로메테우스의 디폴트 포트는 9090, 그라파나는 3000
• networks: promnet: driver: bridge : 컨테이너 명을 통해 컨테이너에 접속할 수 있도록, promnet이라는 bridge Docker network를 생성하고 연결

3. 프로메테우스 콘솔 접속

 

4. 그라파나 콘솔 접속

• 🚨 반드시 디폴트 계정 변경하세요 🚨
• 디폴트 아이디 : admin / 디폴트 비밀번호 : admin

 

 

스프링 모니터링 환경 설정

모니터링 시스템 설치는 끝났으니, 스프링에서 모니터링 할 매트릭을 제공하기 위한 환경설정을 할 차례입니다.

Spring boot Actuator를 통해 HTTP나 JMX를 이용한 매트릭을 생성합니다. 그리고 생성된 매트릭들을 프로메테우스와 같은 다양한 매트릭 수집 소프트웨어들이 폴링할 수 있도록 추상화된 파사드를 제공하는 Micrometer를 설치합니다.

 

1. build.gradle 에 의존성 추가

• 멀티모듈의 경우, 서버 실행 주체가 되는 모듈(API, Gateway)에 추가하면 됩니다.

implementation 'org.springframework.boot:spring-boot-starter-actuator'  // actuator
implementation 'io.micrometer:micrometer-registry-prometheus'  // micrometer for prometheus

 

2. application.yaml 에 Actuator 환경 설정

management:
  endpoints:
    web:
      exposure:
        include: "*"

---
management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus

 

설치가 완료되면, https://DOMAIN/actuator 에서 각 매트릭을 확인할 수 있는 actuator url들에 대한 정보를 제공합니다. 필요한 매트릭 외에 공개하지 않는 것이 보안적으로 안전하므로, 화이트리스트 방식으로 필요한 url을 설정하는 것을 추천합니다. 저의 경우는 instance server 정보, health check, prometheus 매트릭이 필요하므로 3가지 url만 노출시켰습니다.

설정이 완료되었습니다!

 

 

프로메테우스 타켓 설정

이제 다시 프로메테우스로 돌아가 매트릭 환경설정이 완료된 서버를 모니터링 타켓으로 설정하는 절차를 마치면, 프로메테우스가 정상적으로 매트릭을 폴링할 수 있습니다.

1. ./monitor/prometheus.yaml 에서 매트릭 수집 타켓 설정

global:
  scrape_interval: 10s
  evaluation_interval: 10s

scrape_configs:
  - job_name: 'bibbi-prod-was'   // 모니터링 Target 이름
    metrics_path: '/actuator/prometheus'   // 매트릭 url
    static_configs:   // 정적 모니터링 대상
      - targets: ['api.no5ing.kr']   // Target 목록

 

이전에 생성한 프로메테우스 설정파일에 위와 같이 설정한 후, 프로메테우스 컨테이너를 재기동하면(docker compose -f ./docker-compose-monitor.yml up -d) 변경된 내역이 반영됩니다. 프로메테우스 콘솔에서 Status > Targets 을 들어가서 설정한 엔드포인트가의 상태가 'up'이면 정상적으로 폴링되고 있는 것입니다. Graph에서 아무 매트릭을 입력하고 조회하고 정상적으로 확인할 수 있습니다.

 

 

 

---

 

그라파나 대시보드 구성하기

시스템을 도입하는 것보다 중요한 것은 어떻게 잘 활용하냐일 것입니다. 그라파나를 구성하는 방법은 두가지인데, 1. 주어진 시각화 도구를 이용해 직접 대시보드를 구성하는 것이고, 2. 다른 사랑의 대시보드를 import 하는 것입니다. 물론 import한 대시보드를 커스터마이징하는 것도 가능합니다.

 

Grafana Labs(🔗 Link) 이나 Github에서 다양한 대시보드를 url이나 json 형태로 import 할 수 있습니다. 저의 경우에는 Grafana Labs에서 가장 마음에 드는 대시보드를 적용시켜 PromQL 활용법을 연습하고, 저희 시스템에 필요한 대시보드로 조금씩 커스터마이징해 나갔습니다.

 

여기서는 제가 커스터마이징한 대시보드를 공유하고, 이를 간단히 설명하여 핵심 PromQL을 설명해보겠습니다. 대시보드 json 파일은 제 깃허브에서 확인할 수 있습니다.(🔗 Github 링크)

 

 

PromQL

PromQL(Prometheus Query Language)은 Prometheus에서 사용되는 쿼리 언어로, 시계열 데이터를 쿼리하고 분석하는데 사용됩니다. 따라서 프로메테우스로 부터 받아온 데이터를 분석하고 시각화하도록 그라파나를 지원합니다. 다양한 문법이 존재하지만 increase 와 rate 의 활용법을 이해한다면 다양한 시각화를 만들 수 있습니다.

 

Increase (API 요청량_2XX 정상 응답만)

increase(http_server_requests_seconds_count{instance="$instance", application="$application", uri!~".*actuator.*", uri!~".*swagger*.*", uri!~".*api-docs*.*", status=~"2.*"}[30s])

 

 

 

• http_server_requests_seconds_count : 서버에 들어온 http 요청의 누적 갯수
  • 프로메테우스가 수집한 매트릭을 그대로 입력할 경우 선택한 시각화 그래프에 맞게 표현됩니다

 

• http_server_requests_seconds_count{instance="$instance", application="$application", uri!~".**actuator.**", uri!~".**swagger**.**", uri!~".*api-docs*.**", status=~"2.*"} : 설정된 인스턴스, 어플리케이션에서 url에 actuator, swagger, api-docs를 포함하지 않고 응답 결과가 2로 시작한 http 요청 누적 갯수 (실제 클라이언트의 요청만 확인하기 위해 개발자용 url과 매트릭을 수집하기 위한 actuator url을 제외함)
  • 매트릭에 중괄호를 붙여 데이터에 다양한 필터를 적용할 수 있습니다.
    • $CONDITION : 상단바에서 유저가 선택한 조건 기준 (인스턴스, 어플리케이션, 조회 interval 등)
    • !~ : 같지 않음, =~ : 같음, .* : 0개 이상의 임의의 문자

 

• increase(http_server_requests_seconds_count{instance="$instance", application="$application", uri!~".actuator.", uri!~".swagger.", uri!~".api-docs.", status=~"2.*"}[30s]) : 30초 간격으로 http 요청 갯수의 변화량 ( = 30초마다 발생한 http 요청 수)
  • 특정 시간 범위 내에서 주어진 데이터의 증가량을 계산합니다.

 

Increase 응용 (Status code 비율)

increase와 간격을 응용하면 다음과 같은 대시보드도 만들 수 있습니다.

• sum(increase(http_server_requests_seconds_count{application="$application", uri!~".*actuator.*", uri!~".*swagger*.*", uri!~".api-docs.*", status="200"}[$__range]))
• sum(increase(http_server_requests_seconds_count{application="$application", uri!~".*actuator.*", uri!~".*swagger*.*", uri!~".api-docs.*", status="204"}[$__range]))
• sum(increase(http_server_requests_seconds_count{application="$application", uri!~".*actuator.*", uri!~".*swagger*.*", uri!~".api-docs.*", status="400"}[$__range]))
• …
  • 10초, 1시간, 6월 첫째주 등 대시보드의 조회 시간을 다양하게 조절할 수 있는데, 설정한 시간 동안 발생한 http 의 status code 비율을 나타냅니다.
  • increase()를 통해 url 별 요청 갯수를 조회하므로, sum() 을 통해 동일한 status code의 응답 갯수의 합계를 구합니다.

 

Increase 응용 (업로드 된 게시글 수)

• increase(http_server_requests_seconds_count{application="$application", uri="/v1/posts", method="POST", status="200"}[$__range])
  • 특정 기간동안 /v1/posts에 POST 요청을 보내고 200 정상응답을 받은 요청의 수 (업로드 된 게시글 수)
  • 🚨 시계열 데이터의 변화량을 계산하는 쿼리이므로, 정량적인 데이터나 성과의 정확한 수치를 얻기위한 용도로 사용하는 것은 추천하지 않습니다.

 

rate (API 요청량_2XX 정상 응답만)

rate()[TIME] 는 일정 시간동안 시계열 데이터의 비율(변화율)을 계산하는데 사용됩니다. 주로 카운터 메트릭(지속적으로 증가하는 값, ex: HTTP 요청 수, 에러 수 등)의 변화율을 계산하여 주어진 시간동안 얼마나 변화했는지 나타냅니다.

• sum(rate(http_server_requests_seconds_count{application="$application", uri!~".actuator.", uri!~".swagger.", uri!~".api-docs."}[1m]))
  • 지난 1분 동안 HTTP 요청 비율

 

 

 

---

마치며

사실 런칭 후 대내외적으로 사용 후기를 전해들었기 때문에 저희가 출시한 서비스가 사용되고 있다는 것은 알고 있었습니다. 하지만 대시보드를 통해 얼마나 서비스가 사용되었는지 수치로 확인하고 실시간으로 반응하는 트래픽을 보면서 지난 몇 년간의 코딩 경험 중 가장 뿌듯한 시점이였던 것 같습니다.

 

삐삐 서비스에 대한 애정과 열정을 다시 한 번 불태울 수 있었고, 도입한 시스템을 잘 활용하고 발전하여 더 멋진 삐삐로 만들어 나가겠습니다.