장애를 감지하는 기술 - 모니터링과 로깅 전략 (Observability)
“바닐라 아이스크림만 사면 차가 멈춰요.”
GM(제너럴 모터스)에 접수되었던 전설적인 컴플레인입니다. 황당하게 들리지만, 엔지니어가 확인해 보니 사실이었습니다. 바닐라 아이스크림은 인기가 많아 매장 앞쪽에 배치되어 있어 구매 시간이 짧았고, 이 짧은 시간 동안에는 자동차 엔진의 ‘베이퍼 락(Vapor Lock)’ 현상이 해소되지 않아 시동이 걸리지 않았던 것입니다 [file:1].
이처럼 소프트웨어의 장애는 우리가 예측하지 못한 곳, 아주 사소한 변경사항(의자 교체, 아이스크림 맛 등)에서 언제든 발생할 수 있습니다. 따라서 백엔드 엔지니어에게 필요한 것은 ‘장애가 절대 나지 않는 시스템’이 아니라, ‘장애를 즉시 감지하고 원인을 찾을 수 있는 눈(Observability)’입니다.
이번 포스트에서는 복잡한 분산 환경(MSA)에서 장애를 감지하기 위한 모니터링과 로깅 전략을 다룹니다.
1. 무엇을 모니터링해야 하는가?
현업에서는 다양한 지표를 통해 서버의 건강 상태를 확인합니다. 강의 자료를 기반으로 반드시 챙겨야 할 핵심 지표들을 정리해 보았습니다 [file:2].
1) 서버 리소스 (Infrastructure Metrics)
가장 기본이 되는 지표입니다.
- CPU / Memory Usage: 메모리 누수(Memory Leak)나 무한 루프로 인한 자원 고갈을 감시합니다.
- Disk Usage: 특히 로깅을 파일로 남길 경우, 디스크가 가득 차서 서버가 멈추는 경우가 빈번하므로 주의 깊게 봐야 합니다.
2) 애플리케이션 성능 지표 (APM)
사용자가 체감하는 서비스 품질과 직결됩니다.
- Latency (응답 지연): 특정 API의 응답 속도가 느려지면, 의존성 있는 다른 서비스로 장애가 전파(Cascading Failure)될 수 있습니다.
- Throughput (처리량): 시간당 처리 가능한 요청 수입니다.
- Error Rate (에러율): 전체 요청 대비 5xx 에러의 비율입니다.
3) Health Checker
서버가 살았는지 죽었는지 확인하는 가장 기초적인 수단입니다. 단순히 프로세스가 떠 있는지를 넘어, DB 등 주요 의존성 연결이 유효한지까지 체크하는 것이 좋습니다.
2. MSA 환경에서의 로깅과 추적 (Tracing)
모놀리식(Monolithic) 아키텍처와 달리, 마이크로서비스 아키텍처(MSA)에서는 요청 하나가 여러 서비스를 거쳐갑니다.
Request Flow: Service A → Service B → Database
이 과정에서 중간에 에러가 발생했을 때, 단순히 각 서버의 로그만 봐서는 전체 흐름을 파악하기 어렵습니다. 이를 해결하기 위해 Distributed Tracing(분산 추적)이 필수적입니다 [file:2].
Trace ID의 도입
모든 요청의 시작점에 고유한 ID(Trace ID)를 발급하고, 이 ID를 서비스 간 통신(HTTP Header 등)에 포함시켜 전파해야 합니다. 로그를 검색할 때 이 Trace ID 하나만으로 여러 서버에 흩어진 로그를 한 번에 모아볼 수 있습니다.
1
2
3
4
5
6
7
8
// Log Example
{
"timestamp": "2025-12-07T10:00:00",
"level": "ERROR",
"service": "payment-service",
"trace_id": "a1b2c3d4e5", // 이 ID로 전체 흐름 추적 가능
"message": "Connection timeout while calling bank-api"
}
3. 모니터링 도구 생태계 (Tool Stack)
현업에서 자주 사용되는 모니터링 도구들을 소개합니다 [file:2].
| 도구 | 용도 및 특징 |
|---|---|
| Datadog | All-in-One. APM, 로그, 인프라 모니터링을 통합 제공합니다. 사용하기 매우 편리하지만 비용이 비싼 편입니다. |
| ElasticSearch (ELK) | 로그 검색 엔진. 방대한 양의 로그를 빠르게 검색하고 분석하는 데 표준처럼 쓰입니다. (Logstash/Fluentd → ElasticSearch → Kibana) |
| Grafana | 시각화 대시보드. Prometheus 등의 데이터 소스와 연결하여 CPU, 메모리, API 요청 수 등을 그래프로 시각화합니다. |
| Slack Alert | 실시간 알림. 장애 발생 시 엔지니어가 가장 먼저 인지할 수 있도록 메신저와 연동합니다. |
4. 효과적인 알람(Alert) 전략
“알람이 너무 많이 오면, 아무도 알람을 보지 않게 된다(Alert Fatigue).” 중요한 장애를 놓치지 않기 위해 알람 설정을 정교하게 해야 합니다.
- 50X Resolver: 500번대 에러가 발생하거나, 특정 API의 실패율이 임계치를 넘을 때 즉시 알람을 보냅니다 [file:2].
- Latency Warning: 에러는 아니지만 평소 100ms 걸리던 API가 3초 이상 걸린다면? 이는 장애의 전조 증상일 수 있으므로 알람 대상입니다.
- 비즈니스 로직 모니터링: 데이터 파싱 실패나, 결제 시도 횟수 급증 등 비즈니스적으로 이상 징후가 보일 때도 로깅 및 알림이 필요합니다.
결론
장애를 예방하는 것도 중요하지만, ‘장애는 언제든 발생할 수 있다’는 사실을 인정하고 이를 빠르게 감지(Detection)하는 체계를 갖추는 것이 더 현실적이고 중요합니다.
제대로 된 모니터링 환경이 구축되었다면, 이제 우리는 자신 있게 시스템에 부하를 걸어볼 수 있습니다. 우리 시스템이 과연 어느 정도의 트래픽까지 버틸 수 있을까요?
다음 포스트에서는 시스템의 한계를 시험하는 ‘고가용성과 부하 테스트(Load Testing)’에 대해 알아보겠습니다.