본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 log4j를 활용한 로깅과 Spring에서의 예외 처리 전략을 소개했다. 먼저 로깅의 네 가지 핵심 목적을 배웠는데, 성능 모니터링을 통해 병목 지점을 파악하고, 디버깅 및 에러 식별로 문제 원인을 빠르게 찾을 수 있으며, 보안 측면에서 비정상적인 접근을 추적하고, 이력 추적을 통해 시스템의 동작 기록을 남길 수 있다는 점이었다.
예외 처리 부분에서는 전략을 전역 예외 처리, 특정 예외 처리, 사용자 정의 예외 클래스, 트랜잭션 관리 등을 언급해주셨고 @ControllerAdvice를 사용한 전역 예외 처리 정도 실습 내용이었다. 간단한 오버뷰 정도의 챕터였던 것 같고 많은 내용이 있지가 않은터라 MSA 관측성에 대해 추가로 학습했다.
관측성(Observability)
Observability는 시스템의 상태를 외부에서 측정할 수 있도록 하는 능력을 의미한다. 단순한 수치나 지표를 확인하는 것이 아니라, 그 데이터가 의미하는 바를 해석하고, 문제의 원인을 파악하며, 필요한 조치를 취할 수 있도록 하는 것이 Observability의 핵심이다.
Observability는 로그(Logs), 메트릭(Metrics), 트레이스(Traces)라는 세 가지 핵심 요소로 구성된다.
- 로그: 시간 순서대로 기록된 이벤트 메시지로, 시스템 내에서 발생한 사건에 대한 자세한 정보를 제공한다.
- 서비스에서 발생한 이벤트를 기록한 것으로, 일반적으로 구조화된 JSON 형태로 저장된다.
- 예) “사용자 A가 주문을 생성함”, “결제 요청이 실패함”
- 장애 원인을 분석할 때, 가장 직접적인 단서를 제공한다.
- 메트릭: 시스템의 성능과 관련된 수치 데이터로, CPU 사용률, 메모리 사용량, 응답 시간 등을 포함한다.
- CPU 사용량, 메모리 소비, 요청 응답 시간 등 수치화된 데이터이다.
- 대량의 데이터를 처리할 수 있고, 장기적인 트렌드 분석이 가능하다.
- 예) “평균 응답 시간이 500ms를 초과함”, “에러율이 1% 증가함”
- 추적: 특정 요청이 시스템을 거치는 동안의 경로를 나타내는 정보로, 분산 시스템에서 요청의 흐름을 추적하는 데 유용하다.
- 하나의 요청이 시스템 내부에서 어떻게 처리되는지 파악할 수 있다.
- 예) “주문 요청 → 결제 서비스 → 재고 확인 → 배송 서비스”
- 장애의 근본 원인을 빠르게 찾는 데 필수적이다.
이 세 가지 요소를 적절히 활용하면 단순히 문제가 발생했는지 여부를 아는 것을 넘어, “왜” 문제가 발생했는지를 알 수 있다.
MSA 환경에서 Observability가 중요한 이유
분산 시스템에서 가장 어려운 과제 중 하나는 “어떤 문제가 발생했는가?”를 빠르고 정확하게 파악하는 것이다. 모놀리식 아키텍처에서는 애플리케이션의 내부 상태를 비교적 쉽게 추적할 수 있지만, MSA 환경에서는 수십, 수백 개의 마이크로서비스가 서로 다른 환경에서 실행되고 있으며, 각 서비스가 다양한 방식으로 데이터를 주고받는다. 이러한 환경에서는 단순한 모니터링만으로는 충분하지 않다. 우리가 원하는 것은 “문제가 발생한 이유”를 정확히 파악할 수 있는 능력, 즉 Observability(관찰 가능성) 이다.
(마이크로 서비스 규칙 중에 관찰 가능한 서비스를 개발하라는 규칙이 있는데 이런 이유 때문이지 않을까 싶다.)
- 모놀리식 아키텍처
- 한 애플리케이션 안에서 모든 기능이 돌아가므로 내부 상태 추적과 문제 원인 파악이 비교적 쉽다.
- MSA(마이크로서비스 아키텍처)
- 수십~수백 개의 마이크로서비스가 서로 다른 환경에서 동작
- 서비스 간 통신 방식도 다양(HTTP, 메시지 큐 등)
- 단순히 “에러가 났다”는 것만으로는 어디서, 왜 문제가 생겼는지 알기 어렵다.
MSA 환경에서는 단일 서비스의 장애가 전체 시스템에 연쇄적으로 영향을 미칠 가능성이 크다. 예를 들어, 주문 서비스가 결제 서비스와 배송 서비스에 의존하고 있다면, 결제 서비스가 느려지는 것만으로도 주문이 지연되고, 결국 고객 경험이 악화될 수 있다.
관측성이 없으면 이런 문제를 파악하는 데 오랜 시간이 걸린다. 하지만 올바른 관측성시스템이 구축되어 있다면, 서비스 간 호출 관계를 빠르게 분석하고, 병목이 발생한 지점을 즉시 찾아낼 수 있다. 이를 통해 장애를 신속히 해결하고, 사전에 성능 저하를 감지하여 대응할 수 있다.
MSA 환경에서 관측성 확보를 위한 핵심 요소
MSA 환경에서 관측성을 확보하는 데 필수적인 다음 세 가지 핵심 요소에 대해 자세히 살펴보자.
1. Distributed Tracing
MSA 환경에서 여러 서비스에 걸쳐 발생하는 요청의 흐름을 추적하고 시각화하는 시스템. 분산 추적 시스템은 각 서비스 간의 상호작용을 명확하게 보여주며, 병목 지점이나 오류 발생 위치를 파악하는 데 매우 유용하다. 이를 통해 성능 문제나 오류의 원인을 빠르게 찾아 해결할 수 있다.
대표적인 도구
- Jaeger
- Zipkin
- OpenTelemetry
Spring Cloud Sleuth: Spring 환경에서는 Spring Cloud Sleuth를 사용하면 자동으로 Trace ID와 Span ID가 생성되고, HTTP 헤더를 통해 전파된다. Zipkin과 통합하면 수집된 추적 데이터를 시각화할 수 있다.
2. Log Aggregation(Centralized Logging)
여러 서비스에서 발생하는 로그를 한 곳에 모아 관리하고 분석하는 방식. 중앙 집중식 로깅 시스템은 모든 로그를 한눈에 볼 수 있게 해주며, 로그 분석 도구와 연동하여 복잡한 패턴이나 오류를 효율적으로 분석할 수 있다. 이를 통해 시스템의 전체적인 동작을 이해하고 문제 발생 시 신속하게 대처할 수 있다.
대표적인 도구
- ELK Stack
- Grafana Loki
- Fluentd
3. Application Performance Monitoring(APM)
애플리케이션의 성능을 실시간으로 모니터링하고 성능 저하의 원인을 분석하는 시스템. APM은 메트릭을 수집하여 시스템의 성능을 시각화하고, 비정상적인 동작을 탐지하여 성능 문제를 개선하는 데 도움을 준다. 또한 사용자 경험을 개선하고, 시스템의 안정성을 확보하는 데 중요한 역할을 한다.
대표적인 도구
- OPENMARU APM
- Prometheus
- Datadog
- New Relic
- AppDynamics
참고 출처
- https://www.msap.ai/docs/msa-expert-from-concepts-to-practice/part-1-msa-fundamentals/msa-design-principles/msa-monitoring-logging-observability/
- https://microservices.io/tags/observability
- https://sundaland.tistory.com/660
