1227 마이크로서비스 아키텍처(MSA) 운영: 로깅, 모니터링, 추적
✅ 1. 분산 환경에서의 로깅 (Centralized Logging)
-
모놀리식 환경: 로그 파일이 하나의 서버에만 존재하므로, 문제가 발생하면 해당 서버에 접속하여 로그 파일을 직접 확인하면 됩니다.
-
MSA의 문제점: 수십, 수백 개의 서비스 인스턴스가 각자 로그 파일을 생성합니다. 특정 요청 처리 중 발생한 오류를 찾기 위해, 어떤 서비스의 어떤 인스턴스에 로그가 남았는지 알 수 없어 문제 추적이 매우 어렵습니다.
-
해결책 (중앙 집중식 로깅 시스템):
- 개념: 모든 마이크로서비스 인스턴스에서 발생하는 로그를 하나의 중앙 서버(또는 클러스터)로 수집하여, 한 곳에서 모든 로그를 검색, 분석, 시각화하는 시스템입니다.
- 구축 (ELK/EFK 스택):
- Log Collector (Fluentd, Logstash): 각 서버나 컨테이너에 에이전트(Agent)로 설치되어, 로그 파일을 수집하고 중앙 서버로 전송합니다.
- Log Storage/Search Engine (Elasticsearch): 수집된 대량의 로그를 저장하고, 강력한 전문(Full-text) 검색 기능을 제공하는 검색 엔진입니다.
- Log Visualizer (Kibana): Elasticsearch에 저장된 로그를 시각적으로 탐색하고, 대시보드를 통해 모니터링할 수 있는 웹 UI 도구입니다.
-
핵심: 모든 로그를 한 곳에 모아 통합 검색이 가능하도록 만드는 것이 분산 로깅의 핵심입니다.
✅ 2. 분산 환경에서의 모니터링 (Centralized Monitoring)
-
모놀리식 환경: 모니터링 대상이 되는 서버와 애플리케이션이 소수이므로, 각 서버의 CPU, 메모리 등을 개별적으로 확인하는 것이 가능합니다.
-
MSA의 문제점: 수많은 서비스 인스턴스와 그 기반 인프라(컨테이너, VM 등)의 상태를 개별적으로 모니터링하는 것은 불가능합니다. 전체 시스템의 건강 상태를 한눈에 파악할 수 있는 통합된 뷰가 필요합니다.
-
해결책 (중앙 집중식 모니터링 시스템):
- 개념: 모든 인프라와 애플리케이션의 성능 지표(Metric)를 중앙 서버로 수집하여, 이를 시각화하고 이상 징후 발생 시 알림(Alert)을 보내는 시스템입니다.
- 구축 (프로메테우스 & 그라파나):
- Metric Collector (Prometheus): 각 서비스와 인프라로부터 CPU 사용률, 메모리 사용량, API 요청 수, 응답 시간 등 다양한 시계열(Time-series) 메트릭을 주기적으로 수집(Pull)하여 저장합니다. (Spring Boot Actuator와 쉽게 연동됨)
- Metric Visualizer (Grafana): 프로메테우스에 저장된 메트릭 데이터를 연결하여, 그래프와 차트로 구성된 동적인 대시보드를 만들어주는 시각화 도구입니다.
- Alerting (Alertmanager): 프로메테우스와 연동하여, "CPU 사용률이 5분 이상 90%를 초과하면"과 같은 규칙을 설정하고, 조건 충족 시 슬랙(Slack), 이메일 등으로 경고 알림을 보냅니다.
✅ 3. 분산 추적 (Distributed Tracing)
-
문제점: MSA 환경에서 클라이언트의 요청 하나는 내부적으로 여러 마이크로서비스를 거쳐 처리됩니다. (e.g.,
API 게이트웨이→주문 서비스→결제 서비스→알림 서비스) 만약 전체 응답 시간이 느려졌을 때, 어떤 서비스 구간에서 병목이 발생했는지를 파악하기가 매우 어렵습니다. -
분산 추적:
-
개념: 여러 서비스에 걸쳐 이루어지는 요청의 전체 여정(Journey)을 시각화하고, 각 단계에서 소요된 시간을 측정하여 성능 병목과 에러의 원인을 분석하는 기술입니다.
-
동작 원리:
- Trace ID 전파: 외부에서 첫 요청이 들어올 때, 고유한
Trace ID를 생성합니다. - 이 요청이 다음 서비스로 전달될 때, HTTP 헤더 등을 통해 이
Trace ID를 계속해서 전파합니다. - 각 서비스는 요청을 받으면,
Trace ID와 함께 자신의 작업 단위를 나타내는Span ID를 생성하여 로그나 추적 시스템에 기록합니다. - 시각화 도구는 수집된
Trace ID와Span ID정보를 재구성하여, 아래와 같은 타임라인 그래프(Gantt Chart) 형태로 보여줍니다.
[ Trace ID: abc-123 ] API Gateway: |██████████████████████████████████████| 300ms └── 주문 서비스: |██████████████████████████| 200ms └── 결제 서비스: |██████████| 100ms └── 알림 서비스: |███| 30ms (비동기) - Trace ID 전파: 외부에서 첫 요청이 들어올 때, 고유한
-
효과: 위와 같은 시각화를 통해, "결제 서비스에서 100ms나 걸려서 전체 응답이 느려졌구나!" 와 같이 병목 지점을 명확하게 식별할 수 있습니다.
-
대표적인 표준 및 도구: OpenTelemetry (표준), Jaeger, Zipkin
-
📌 요약
- MSA 운영의 핵심은 "가시성(Observability)"을 확보하는 것입니다. 이를 위한 3대 요소는 로깅, 모니터링, 추적입니다.
- 중앙 집중식 로깅 (ELK/EFK)은 흩어져 있는 모든 로그를 한 곳으로 모아 "무슨 일이 일어났는지(What)"를 검색할 수 있게 해줍니다.
- 중앙 집중식 모니터링 (프로메테우스/그라파나)은 모든 시스템의 성능 지표를 수집하여 "시스템이 건강한지(How)"를 시각적으로 보여주고, 이상 징후 시 알림을 보냅니다.
- 분산 추적 (OpenTelemetry/Jaeger)은 서비스 간의 요청 흐름을 추적하여, "느린 이유가 무엇인지(Why)"에 대한 성능 병목의 근본 원인을 분석할 수 있게 해줍니다.
- 이 세 가지 시스템은 상호 보완적으로 동작하며, 복잡한 MSA 환경에서 발생하는 문제를 진단하고 해결하는 데 필수적인 도구입니다.
