LG CNS 부트캠프 학습일지 52일차

학습 내용

• Zipkin으로 로그 통합 관리하기
• Prometheus으로 매트릭을 통합하기
• Grafana으로 대시보드 구성하기
• MSA 패턴 개요

Zipkin으로 로그 통합 관리하기

마이크로서비스를 여러 개 관리하면 로그메세지가 각 마이크로서비스에 나뉘어져 있다. 분산화된 시스템 그 자체로는 문제가 생겼을 때 그 문제가 어디서 어떻게 그리고 왜 발생했는지 추적하기가 어렵다. 문제의 원인을 추적하고 해결하기 위해 로그메세지를 한 곳에 통합시킬 수 있다면 좋을 것이다. Zipkin을 사용하면 그 목적을 달성할 수 있다. 로그메세지에 Trace ID와 Span ID라는 것을 부여해서

<dependency>
	<groupId>io.zipkin.brave</groupId>
	<artifactId>brave-instrumentation-spring-web</artifactId>
</dependency>

  zipkin:
    image: openzipkin/zipkin:3
    container_name: zipkin
    ports:
      - "9411:9411"
    restart: unless-stopped

Prometheus으로 매트릭을 통합하기

Prometheus(프로메테우스)는 매트릭(Metric)을 통합해주는 어플리케이션이다. 마이크로서비스마다 메모리 사용량, CPU 사용량 등의 통계정보를 가지고 있는데, 그 정보를 한 곳에 모아서 데이터소스(Data Source)로서의 역할을 담당해준다.

<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

  prometheus:
    image: prom/prometheus:v3.5.0
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
    restart: unless-stopped

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "user-service"
    metrics_path: "/user-service/actuator/prometheus"
    static_configs:
      - targets:
          - "172.30.1.6:8080"
  - job_name: "order-service"
    metrics_path: "/order-service/actuator/prometheus"
    static_configs:
      - targets:
          - "172.30.1.6:8080"
  - job_name: "catalog-service"
    metrics_path: "/catalog-service/actuator/prometheus"
    static_configs:
      - targets:
          - "172.30.1.6:8080"

prometheus.yml 파일을 작성할 때는 한 가지 주의할 점이 있었다. 컨테이너에서 Intellij로 실행하는 스프링부트 어플리케이션에 접근해야하기 때문에, localhost를 사용해서는 안된다. 컨네티어 입장에서 localhost는 자기 자신이기 때문이다.

Grafana으로 대시보드 구성하기

Grafana는 데이터를 보기좋게 만들어주는 대시보드 어플리케이션이다. Prometheus를 데이터소스로서 활용해서 사용자가 자기 필요에 맞게 대시보드를 구성할 수 있게 해준다. PromQL (Prometheus Query Language) 라는 것을 활용해서 어떤 데이터를 어떻게 보여줄지 만들어줄 수 있었다.

  grafana:
    image: grafana/grafana
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin
    restart: unless-stopped

MSA 패턴 개요

마이크로서비스들이 어떻게 상호작용하고 자료를 동기화시키는지를 정하는 일정한 패턴이 있다. 그 중 SAGA 패턴이라는 것을 정리해보려고 한다. SAGA 패턴은 크게 두 가지로 나뉜다. Chorerography based SAGA 그리고 Orchestration based SAGA. SAGA 패턴은 Kafka와 같은 메세지 브로커 시스템을 중심으로 마이크로서비스들 간에 상호작용하는 패턴이다. 만약 문제가 발생하면 그 문제가 발생하기 이전 상태로 되돌아가는 작업이 필요한데, Chorerography 방식을 채택하느냐 또는 Orchestration 방식을 채택하느냐에 따라 구체적인 방식이 조금 달라진다.

Choreography와 Orchestration 방식의 차이점은 일련의 트랜젝션을 통제하는 주체가 있는가 없는가에 있다. Choreography 방식은 각 마이크로서비스가 독립적으로 작동하며 메세지 브로커에게 자신이 작업을 제대로 완료했는지 여부를 통지함으로서 다른 마이크로서비스들과 상호작용한다. 반면 Orchestration 방식은 이름에서 드러나듯이 중심 서비스가 다른 마이크로서비스에게 명령을 보내서 일련의 트랜젝션을 관리한다. 간단히 말하면 분권화되어있느냐 또는 중앙집권적이냐의 차이인데, 현실에서처럼 분권화되어 있는 경우에는 문제가 발생했을 때 원상복구하는 것이 까다로워지고, 중앙집권적이면 그 중앙서비스에 문제가 생겼을 때 전체시스템이 작동하지 못하는 문제가 발생한다.