MSA에서 가장 어려운 문제는 데이터가 아니라 ‘관측(Observability)’이다

분산 시스템에서 무엇이 일어나고 있는지 아는 방법

마이크로서비스 아키텍처(MSA)는 시스템을 여러 개의 작은 서비스로 분리한다.

이 구조는 다음과 같은 장점을 제공한다.

• 서비스 독립 배포
• 확장성 증가
• 장애 격리
• 팀 단위 개발

하지만 시스템이 커질수록 새로운 문제가 등장한다.

그 문제는 바로

지금 시스템에서 무슨 일이 일어나고 있는지 알기 어렵다

 

라는 것이다.

모놀리식 시스템에서는 하나의 애플리케이션 로그만 보면
문제 원인을 찾는 것이 비교적 쉬웠다.

하지만 MSA에서는 상황이 완전히 달라진다.

---

모놀리스에서의 문제 추적

모놀리식 구조에서는 요청 흐름이 단순하다.

예를 들어 다음과 같은 구조다.

Client
→ Application
→ Database

 

문제가 발생하면 보통 다음 순서로 확인한다.

• 애플리케이션 로그
• DB 로그
• 에러 스택

대부분의 문제는 하나의 서비스 안에서 해결된다.

---

MSA에서의 문제 추적

MSA에서는 요청 흐름이 훨씬 복잡하다.

예를 들어 하나의 API 요청이 다음 서비스를 거칠 수 있다.

Client
→ API Gateway
→ Auth Service
→ Order Service
→ Payment Service
→ Inventory Service

 

여기서 문제가 발생하면 다음 질문이 생긴다.

어느 서비스에서 문제가 발생했는가

 

그리고 더 어려운 질문이 있다.

어떤 요청 흐름에서 문제가 발생했는가

 

MSA에서는 하나의 사용자 요청이 여러 서비스 로그에 흩어져 있기 때문이다.

이 문제를 해결하기 위해 등장한 개념이
바로 Observability(관측성)이다.

---

Observability란 무엇인가

Observability는 시스템 내부 상태를
외부에서 관찰할 수 있는 능력을 의미한다.

즉 다음 질문에 답할 수 있어야 한다.

지금 시스템에서 무슨 일이 일어나고 있는가
왜 문제가 발생했는가
어디에서 병목이 발생하는가

 

이를 위해 보통 다음 세 가지 요소가 필요하다.

요소설명

Metrics	시스템 상태 수치
Logs	이벤트 기록
Tracing	요청 흐름 추적

이 세 가지를 흔히

Observability 3 Pillars

 

라고 부른다.

---

1. Metrics (메트릭)

Metrics는 시스템 상태를 숫자로 표현한 것이다.

예를 들어 다음과 같은 정보다.

• CPU 사용률
• 메모리 사용량
• API 응답 시간
• 에러율
• 요청 처리량

이 정보는 시스템 상태를 빠르게 파악하는 데 도움이 된다.

대표적인 모니터링 도구로는

• Prometheus
• Grafana

같은 도구들이 있다.

Metrics는 보통 시스템 상태를 빠르게 확인하는 용도로 사용된다.

---

2. Logs (로그)

Logs는 시스템에서 발생한 이벤트 기록이다.

 

예를 들어

사용자 로그인 성공
주문 생성
결제 실패

 

같은 정보가 로그로 남는다.

문제가 발생하면 로그를 통해 원인을 분석할 수 있다.

하지만 MSA에서는 로그가 여러 서비스에 분산되어 있기 때문에
중앙 로그 시스템이 필요하다.

대표적인 로그 스택은 다음과 같다.

• Elasticsearch
• Logstash
• Kibana

이 조합을 보통 ELK 스택이라고 부른다.

---

3. Tracing (분산 추적)

Tracing은 MSA에서 특히 중요한 기능이다.

Tracing은 하나의 요청이 여러 서비스를 거치는 과정을 추적한다.

예를 들어 다음 요청 흐름이 있다고 가정하자.

Client Request
→ Gateway
→ Auth Service
→ Order Service
→ Payment Service

 

Tracing 시스템은 이 요청 흐름을 하나의 트랜잭션처럼 추적한다.

즉 다음 질문에 답할 수 있다.

어느 서비스에서 지연이 발생했는가
어느 서비스에서 에러가 발생했는가

 

대표적인 도구는 다음과 같다.

• Jaeger
• Zipkin

---

Observability가 중요한 이유

MSA에서는 서비스 수가 늘어나면서
시스템 복잡성이 크게 증가한다.

예를 들어 다음 구조를 생각해 보자.

30개의 서비스
100개의 API
수천 개의 요청

 

이 상황에서 Observability가 없다면

문제 원인을 찾는 것이 거의 불가능하다

 

즉 Observability는 MSA에서 선택이 아니라 필수 요소다.

---

좋은 MSA 시스템의 Observability 구조

일반적인 MSA 운영 환경에서는 다음 구조를 사용한다.

Metrics
→ Prometheus
→ Grafana

Logs
→ ELK Stack

Tracing
→ Jaeger / Zipkin

 

이 구조를 통해 다음 정보를 확인할 수 있다.

• 시스템 상태
• 서비스 간 요청 흐름
• 에러 발생 위치

---

정리

마이크로서비스 아키텍처에서는
시스템이 여러 서비스로 분리되기 때문에

문제 원인을 파악하는 것이 훨씬 어려워진다

 

이 문제를 해결하기 위해 Observability가 필요하다.

Observability는 보통 다음 세 가지 요소로 구성된다.

요소역할

Metrics	시스템 상태 측정
Logs	이벤트 기록
Tracing	요청 흐름 추적

결국 MSA에서 가장 어려운 문제는
서비스 분리가 아니라

분산 시스템을 이해하는 것

 

이다.

그리고 Observability는
그 문제를 해결하는 핵심 도구다.