bluegreen-배포-환경에서-prometheus-메트릭이-끊겨-보이던-이유와-해결-방법

Blue/Green 배포 환경에서 Prometheus 메트릭이 끊겨 보이던 이유와 해결 방법

Blue/Green 배포 환경에서 Prometheus의 target을 인스턴스 기준으로 설정한 상태에서 모니터링을 하다 보니, Grafana 그래프가 배포 시점마다 끊겨 보이는 문제가 발생했습니다.

현재 Spring Boot + Actuator를 사용해 메트릭을 노출하고, Prometheus와 Grafana를 통해 이를 모니터링하고 있습니다.

서비스는 Blue/Green 배포 방식으로 운영 중이며, 배포 시점에 따라 Spring Boot 인스턴스가 blue 또는 green으로 전환되는 구조입니다.

 

문제는 Prometheus가 특정 시점에는 dev-blue 인스턴스를 바라보다가, 배포 이후에는 dev-green 인스턴스를 바라보도록 설정이 변경된다는 점이었습니다.

Prometheus 입장에서는 blue와 green을 서로 다른 서버로 인식하게 되고, 이로 인해 Grafana에서는 동일한 서비스임에도 불구하고 메트릭이 연속되지 않는 것처럼 보이게 됩니다.

 

이를 해결하기 위해 Prometheus가 개별 인스턴스(blue/green)를 직접 바라보는 방식이 아니라,현재 서비스 중인 엔드포인트 하나만을 바라보도록 구조를 변경하기로 했습니다.

현재 서비스 앞단에는 ELB(Application Load Balancer)가 존재하며, ELB가 blue 또는 green 중 실제로 트래픽을 처리하고 있는 인스턴스로 요청을 라우팅하고 있는 상태입니다.

따라서 Prometheus가 개별 인스턴스가 아닌, ELB가 바라보고 있는 서비스 엔드포인트를 기준으로 메트릭을 수집하도록 변경하면, Blue/Green 전환으로 인해 모니터링 그래프가 끊겨 보이는 문제를 해결할 수 있다고 판단했습니다.

 

아래 순서로 변경을 진행해 보겠습니다.

1. Spring Boot Actuator의 Prometheus endpoint 경로 변경
2. 변경된 endpoint가 ELB를 통해 blue/green 인스턴스로 라우팅되도록 리스너 규칙 추가
3. Prometheus 설정에서 scrape target을 인스턴스가 아닌 ELB DNS로 변경

 

1. Spring Boot Actuator의 Prometheus endpoint 경로 변경

기존 actuator.yml

management:
  endpoints:
    web:
      base-path: /management
      exposure:
        include: prometheus

기존에는 /management 경로를 통해 Actuator 메트릭을 수집하고 있었습니다.

이번 변경에서는 Actuator의 base path를 /management에서 /internal/metrics으로 변경하여, Prometheus 전용 메트릭 엔드포인트를 별도로 분리해보겠습니다.

 

변경후 actuator.yml

management:
  endpoints:
    web:
      base-path: /internal/metrics
      exposure:
        include: prometheus

이제 /internal/metrics/prometheus 경로를 통해 Prometheus가 메트릭을 수집할 수 있도록 변경되었습니다.

 

2. 변경된 endpoint가 ELB를 통해 blue/green 인스턴스로 라우팅되도록 리스너 규칙 추가

현재 ELB 의 리스너 규칙은 아래와 같습니다.

기존 BE 트래픽은 /api/*, /ws* 경로를 기준으로 be-rule을 통해 blue/green 인스턴스로 라우팅되고 있습니다.

이번에 추가한 /internal/metrics/prometheus 엔드포인트 역시 동일한 BE 애플리케이션에서 제공되기 때문에, 우선은 별도의 리스너 규칙을 추가하지 않고 기존 be-rule에 /internal* 경로를 함께 포함하도록 구성해보겠습니다.

 

사진처럼 구성하게 되면 Prometheus가 /internal/metrics/prometheus로 요청하더라도, 기존 BE 트래픽과 동일하게 현재 서비스 중인 blue 또는 green 인스턴스로 자동 라우팅됩니다.

다만 /internal/* 경로는 비즈니스 API와 성격이 다른 운영/관측용 엔드포인트이기 때문에, 운영 환경에서는 별도의 리스너 규칙으로 분리하거나, IP 제한 등의 추가적인 보안 설정을 적용하는 것이 더 적절할 수 있습니다.

 

3. Prometheus 설정에서 target을 인스턴스가 아닌 ELB DNS로 변경

마지막으로 Prometheus 설정에서 scrape target을 개별 인스턴스가 아닌, ELB의 DNS를 바라보도록 변경합니다.

 

기존 prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    metrics_path: "/management/prometheus"
    static_configs:
      - targets: ["dev-green:8082"]

 

변경후 prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    scheme: https
    metrics_path: "/internal/metrics/prometheus"
    static_configs:
      - targets: ["로드 밸런서의 DNS 이름"]

 

이 변경을 통해 Prometheus는 더 이상 dev-blue 또는 dev-green 인스턴스를 직접 바라보지 않고, 항상 동일한 ELB DNS를 기준으로 메트릭을 수집하게 됩니다.

따라서 Blue/Green 배포로 인해 인스턴스가 교체되더라도, Prometheus 설정을 다시 수정할 필요가 없게 됩니다.

 

4. 테스트

Prometheus가 정상적으로 연결되어 메트릭을 수집하고 있다면, Grafana 대시보드에서 아래와 같이 메트릭이 정상적으로 표시되는 것을 확인할 수 있습니다.

 

보다 빠르게 확인하고 싶다면, Prometheus의 Targets 페이지를 통해 메트릭 수집 상태를 직접 확인할 수 있습니다.

http://<prometheus-host>:9090/targets

이 페이지에서 대상(target)의 상태가 UP으로 표시된다면, Prometheus가 해당 엔드포인트로부터 정상적으로 메트릭을 수집하고 있다는 의미입니다.

 

4.1 TLS 인증서 오류 발생

저의 경우, 위 Targets 페이지에서 아래와 같은 오류를 확인할 수 있었습니다.

해당 오류는 Prometheus가 ELB의 DNS 주소로 HTTPS 요청을 시도하면서 발생했습니다.

ELB에는 제 서비스 도메인에 대한 TLS 인증서만 적용되어 있었고, ELB 고유의 DNS 주소에 대한 인증서는 존재하지 않았기 때문입니다.

즉,

• 도메인(example.com) → ELB → 정상
• ELB DNS(xxx.elb.amazonaws.com) → 인증서 불일치 → 오류 발생

이라는 상황이었습니다.

 

해결 방법

이를 해결하기 위해 Prometheus 설정에서 target을 ELB의 DNS 주소가 아닌, TLS 인증서가 적용된 서비스 도메인으로 변경했습니다.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    scheme: https
    metrics_path: "/internal/metrics/prometheus"
    static_configs:
      - targets: ["도메인명 ex) example.com"]

이렇게 설정하면 TLS 인증서 검증 문제 없이 정상적으로 메트릭을 수집할 수 있으며, Blue/Green 배포 환경에서도 Prometheus 설정을 변경할 필요가 없어집니다.