분산 시스템 장애의 본질: Fault → Error → Failure 흐름과 Observability 기반 원인 추론

🧐 들어가기전

https://www.researchgate.net/figure/Relationship-Fault-Error-and-Failure_fig2_335569150

"서비스 응답이 느려졌다." "간헐적으로 504 Gateway Timeout이 발생한다." "Pod가 재시작을 반복한다."

분산 환경에서 이런 증상을 마주했을 때, 원인을 얼마나 빠르게 특정할 수 있는가? 증상은 하나지만 원인은 네트워크 지연, 메모리 부족, 외부 API 장애, 잘못된 설정 등 수십 가지가 될 수 있다. Prometheus 대시보드에서 CPU 사용률이 정상이고, Pod 상태도 Running이라면 어디서부터 추적을 시작해야 하는가?

 

이 질문에 체계적으로 답하려면 두 가지가 필요하다.

첫째, 장애가 어떻게 발생하고 전파되는지에 대한 개념적 이해.

둘째, 그 흐름을 실시간으로 관측할 수 있는 데이터 수집 체계.

전자는 분산 시스템 이론에서 다루는 Fault/Error/Failure 모델이고, 후자는 Observability의 세 축인 Metrics, Logs, Traces다.

 

이 글에서는 장애의 본질적 구조를 먼저 정리한 뒤, 각 단계에서 어떤 Observability 데이터가 탐지 역할을 하는지 매핑하고자한다. Prometheus, Loki, Tempo, OpenTelemetry로 구성된 스택을 기준으로, 장애 발생 시 "무엇이 → 왜 → 어디서" 순으로 원인을 추론하는 흐름을 다루고자 한다.

---

🔸 1. Fault, Error, Failure의 구분

1.1 용어 정의와 인과 관계

분산 시스템에서 장애를 논할 때 Fault, Error, Failure라는 세 용어가 혼용되는 경우가 많다. 이 셋은 동의어가 아니라 인과 관계로 연결된 서로 다른 개념이다.

Fault	장애를 유발하는 근본 원인	잘못된 설정, 버그가 있는 코드, 하드웨어 결함
Error	Fault로 인해 시스템 내부에서 발생한 비정상 상태	Null pointer exception, 메모리 누수, 잘못된 연산 결과
Failure	Error가 외부로 드러나 시스템이 명세대로 동작하지 않는 상태	서비스 응답 불가, 잘못된 데이터 반환, 프로세스 크래시

이 세 단계의 핵심은 시간적 순서와 가시성의 차이다.

Fault는 시스템 내부에 잠복해 있을 수 있고, 특정 조건이 충족될 때 Error로 발현된다. Error 역시 내부 상태에 머물 수 있지만, 복구되지 않으면 결국 Failure로 이어져 사용자나 다른 컴포넌트가 인지하게 된다.

Fault (원인) → Error (내부 이상 상태) → Failure (외부 관측 가능한 장애)

실제 운영 환경에서 이 구분이 중요한 이유는 탐지 시점과 대응 방식이 달라지기 때문이다. Failure가 발생한 후에 대응하면 이미 사용자에게 영향이 간 상태다. Error 단계에서 탐지하면 Failure를 막을 수 있고, Fault를 사전에 제거하면 Error 자체가 발생하지 않는다.

---

1.2 장애 유형별 분류

장애는 시스템이 어떤 방식으로 비정상 동작하는지에 따라 분류할 수 있다. 이 분류는 장애 탐지 난이도와 복구 전략을 결정하는 기준이 된다.

Crash Failure	프로세스가 중단되고 더 이상 동작하지 않음	낮음
Omission Failure	요청을 수신하거나 응답을 전송하지 못함	중간
Timing Failure	응답이 지정된 시간 범위를 벗어남	중간
Response Failure	응답 값이 잘못되었거나 상태 전이가 비정상	높음
Arbitrary (Byzantine) Failure	임의의 시점에 임의의 잘못된 동작 수행	매우 높음

• Crash Failure:
  프로세스가 완전히 중단되므로 Health Check나 프로세스 모니터링으로 비교적 쉽게 탐지된다. Kubernetes 환경에서 Pod가 CrashLoopBackOff 상태에 빠지는 것이 대표적이다.
• Omission Failure:
  요청이 유실되거나 응답이 전송되지 않는 경우다. 네트워크 패킷 손실, 버퍼 오버플로우, 또는 수신 측 큐가 가득 찬 상황에서 발생한다. 요청을 보낸 측에서는 타임아웃으로 인지하지만, 실제 원인이 송신 실패인지 수신 실패인지 구분하기 어렵다.
• Timing Failure:
  시스템이 동작은 하지만 지정된 시간 내에 응답하지 못하는 경우다. SLA 위반, 사용자 경험 저하로 이어지며, 간헐적으로 발생할 경우 재현과 원인 분석이 까다롭다.
• Response Failure:
  응답이 돌아오지만 그 내용이 잘못된 경우다. 값이 틀리거나(Value Failure), 상태 전이가 비정상적으로 수행된(State-transition Failure) 경우를 포함한다. 이 유형은 시스템이 정상 동작하는 것처럼 보이므로 탐지가 어렵고, 잘못된 데이터가 하위 시스템으로 전파될 위험이 있다.
• Arbitrary Failure(Byzantine Failure):
  가장 심각한 유형으로, 시스템이 예측 불가능한 방식으로 동작한다. 악의적인 공격, 하드웨어 결함, 또는 복잡한 버그 조합으로 발생할 수 있다. 일반적인 모니터링으로는 탐지가 거의 불가능하며, 합의 알고리즘이나 다중 검증 로직이 필요하다.

---

1.3 Halting 유형과 탐지 가능성

장애가 발생했을 때 외부에서 이를 얼마나 확실하게 인지할 수 있는지도 중요한 분류 기준이다.

 

[Halting 유형]

Fail-stop	크래시 발생 시 즉시 탐지 가능
Fail-noisy	크래시 발생, 일정 시간 후 탐지 가능
Fail-silent	크래시 또는 Omission 발생, 원인 구분 불가
Fail-safe	임의 동작이나 해를 끼치지 않음
Fail-arbitrary	임의 동작, 악의적 결과 가능

• Fail-stop:
  가장 다루기 쉬운 모델이다. 프로세스가 중단되면 즉시 알 수 있고, 중단 전까지는 정상 동작했다고 가정할 수 있다. Kubernetes의 Liveness Probe가 이 모델을 전제로 설계되어 있다
• Fail-noisy:
  Fail-stop과 유사하게 크래시가 발생하지만, 탐지까지 일정 시간이 소요된다. 장애 발생 사실은 결국 알 수 있으나 즉각적이지 않다. 클러스터 멤버십 프로토콜을 통해 노드 장애를 전파하는 경우가 이에 해당한다.
• Fail-silent:
  분산 시스템에서 자주 마주하는 현실적인 상황이다. 네트워크 파티션이 발생했을 때, 상대방 노드가 실제로 죽은 것인지 단순히 네트워크가 끊긴 것인지 구분할 수 없다. 이 경우 타임아웃 기반 탐지에 의존하게 되며, 잘못된 판단으로 Split-brain 문제가 발생할 수 있다.
• Fail-safe:
  프로세스가 임의의 동작을 하지만, 그 결과가 시스템에 해를 끼치지 않는 경우다. 잘못된 값을 반환하더라도 명확히 잘못된 값임을 알 수 있거나, 안전한 기본값으로 fallback하는 경우가 이에 해당한다.
• Fail-arbitrary(Byzantine Failure):
  가장 다루기 어려운 모델이다. 프로세스가 예측 불가능한 방식으로 동작하며, 악의적인 결과를 초래할 수 있다. 일반적인 모니터링으로는 탐지가 거의 불가능하며, 합의 알고리즘이나 다중 검증 로직이 필요하다.

하지만, 비동기 분산 시스템에서는 프로세스 실행 속도와 메시지 전달 시간에 대한 보장이 없으므로 Crash Failure조차 완벽하게 탐지할 수 없다. 실무에서는 타임아웃 값을 적절히 설정하고 오탐을 감수하는 방식으로 대응한다.

---

🔸 2. Observability의 세 축과 역할 분담

Observability: 시스템의 외부 출력을 통해 내부 상태를 추론할 수 있는 정도

모니터링이 "문제가 발생했는가?"라는 질문에 답한다면, Observability는 "왜 문제가 발생했는가?"라는 질문에 답할 수 있는 능력이다.

이를 위해 세 가지 유형의 데이터가 필요하다.

2.1 Metrics: "무엇이" 발생했는가

Metrics: 시간에 따라 변화하는 수치 데이터.

Metrics에는 CPU 사용률, 메모리 사용량, 요청 수, 에러율, 응답 시간 등이 해당한다. 대표적으로 Prometheus는 이러한 시계열 데이터를 수집하고 저장하는 대표적인 도구다.

# prometheus.yml 설정 예시
scrape_configs:
  - job_name: 'my-service'
    scrape_interval: 15s
    static_configs:
      - targets: ['my-service:8080']

Prometheus의 핵심 동작 방식은 Pull 모델이다. 모니터링 대상이 /metrics 엔드포인트를 노출하면, Prometheus가 주기적으로 해당 엔드포인트를 호출하여 데이터를 수집한다.

 

Metrics의 강점은 집계와 경향 파악이다. 특정 시점의 CPU 사용률보다 "지난 1시간 동안 CPU 사용률이 점진적으로 상승했다"는 정보가 더 유용하다. 이를 통해 Failure가 발생하기 전에 Error 징후를 포착할 수 있다.

 

Prometheus에서 자주 사용하는 메트릭 유형은 다음과 같다.

Counter	누적 증가 값	총 요청 수, 총 에러 수
Gauge	현재 상태 값	현재 메모리 사용량, 활성 연결 수
Histogram	분포 측정	요청 응답 시간 분포
Summary	분위수 계산	p99 응답 시간

 

하지만 Metrics의 한계는 원인 파악이 어렵다는 점이다. 에러율이 높아졌다는 사실은 알 수 있지만, 어떤 요청이 왜 실패했는지는 알 수 없다. 이 지점에서 Logs가 필요해진다.

---

2.2 Logs: "왜" 발생했는가

Logs: 특정 시점에 발생한 이벤트를 텍스트로 기록한 데이터.

Logs에는 에러 메시지, 스택 트레이스, 상태 변경 이력 등이 포함된다.

 

대표적으로 Loki는 Prometheus와 유사한 방식으로 로그를 수집하고 쿼리할 수 있는 로그 집계 시스템이다.

# 특정 서비스의 에러 로그 조회
{app="my-service"} |= "error" | json | level="error"

# 최근 5분간 에러 로그 수 집계
count_over_time({app="my-service"} |= "error"[5m])

Loki에서 로그를 조회할 때는 위와 같은 LogQL을 사용한다.

 

Logs의 강점은 맥락 정보다. Metrics가 "에러가 발생했다"는 사실만 알려준다면, Logs는 "사용자 ID 12345의 결제 요청에서 외부 API 호출 시 connection refused가 발생했다"는 구체적 정보를 제공한다.

 

Logs의 한계는 분산 환경에서 요청 흐름을 따라가기 어렵다는 점이다. 하나의 사용자 요청이 API Gateway → Service A → Service B → Database로 이어질 때, 각 서비스의 로그를 수동으로 연결해야 한다. 이 문제를 해결하는 것이 Traces다.

---

2.3 Traces: "어디서" 발생했는가

Traces: 단일 요청이 여러 서비스를 거치며 처리되는 전체 경로를 기록한 데이터.

Traces를 통해 각 서비스에서의 처리 시간, 호출 순서, 성공/실패 여부를 시각적으로 파악할 수 있다.

 

Documentation

OpenTelemetry는 Traces, Metrics, Logs를 수집하기 위한 벤더 중립적 표준이다. 애플리케이션에 OpenTelemetry SDK를 통합하면, 코드 변경 없이 또는 최소한의 변경으로 텔레메트리 데이터를 수집할 수 있다.

 

Trace의 기본 구조는 다음과 같다.

Trace	하나의 요청에 대한 전체 처리 흐름
Span	Trace를 구성하는 개별 작업 단위
Trace ID	전체 요청을 식별하는 고유 ID
Span ID	개별 Span을 식별하는 ID
Parent Span ID	상위 Span과의 관계를 나타내는 ID

 

Grafana Tempo | Grafana Tempo documentation

Tempo는 Grafana Labs에서 개발한 분산 트레이싱 백엔드다. Trace ID만으로 인덱싱하여 저장 비용을 낮추면서도, Grafana와의 통합을 통해 Metrics, Logs와 연계 분석이 가능하다.

 

OpenTelemetry Collector를 사용하면 여러 소스에서 텔레메트리 데이터를 수집하고, 다양한 백엔드로 전송할 수 있다.

 

Kubernetes 환경에서 OpenTelemetry를 적용하는 방식은 크게 두 가지다.

• 첫째, 애플리케이션에 SDK를 직접 통합하는 방식이다. 언어별 SDK를 사용하여 Span을 생성하고 전송한다.
• 둘째, OpenTelemetry Operator를 사용한 Auto-instrumentation이다. Kubernetes CRD를 통해 Pod에 자동으로 Instrumentation을 주입할 수 있다.

---

2.4 세 축의 상관관계와 한계

Metrics, Logs, Traces는 각각의 강점이 있지만, 단독으로는 완전한 Observability를 제공하지 못한다.

Metrics	집계, 경향 파악, 알림	원인 파악 불가
Logs	상세 맥락, 에러 메시지	분산 요청 추적 어려움
Traces	요청 흐름 시각화, 병목 식별	저장 비용, 샘플링 필요

세 데이터를 연계하는 핵심은 Trace ID다. 로그에 Trace ID를 포함시키면, Grafana에서 특정 Trace를 조회한 뒤 해당 Trace ID로 Loki 로그를 검색할 수 있다. 이를 통해 "어디서 → 왜"의 흐름을 자연스럽게 따라갈 수 있다.

---

🔸 3. 장애 흐름과 Observability 매핑

3.1 Fault → Error → Failure 단계별 탐지 지점

앞서 정의한 Fault → Error → Failure 흐름을 Observability 데이터와 매핑하면 다음과 같다.

Fault	잘못된 DB 커넥션 풀 설정	설정 파일, 코드 리뷰	(사전 예방)
Error (잠복)	커넥션 풀 고갈 시작	활성 커넥션 수 증가	Prometheus Gauge
Error (발현)	커넥션 획득 실패	에러 로그 발생	Loki
Failure	API 응답 실패	에러율 증가, Trace 실패	Prometheus Counter, Tempo

이 매핑에서 중요한 점은 Error 단계를 세분화하는 것이다. Error가 "잠복" 상태일 때 탐지하면 Failure를 예방할 수 있다. 커넥션 풀 예시에서, 풀 사용률이 80%를 넘으면 알림을 발송하도록 설정하면 고갈 전에 대응할 수 있다.

3.2 Kubernetes 환경에서의 장애 시나리오 예시

Kubernetes 환경에서 자주 발생하는 장애 시나리오를 Fault → Error → Failure 흐름으로 분석해보면 다음과 같다.

 

시나리오: 마이크로서비스 간 호출에서 간헐적 타임아웃 발생

[Fault]
Service B의 메모리 설정이 실제 사용량 대비 부족하게 설정됨

[Error - 잠복]
트래픽 증가 시 Service B의 메모리 사용량이 limit에 근접
GC 빈도 증가, 응답 지연 시작

[Error - 발현]
Service B가 OOMKilled 또는 GC pause로 인해 응답 지연
Service A에서 타임아웃 발생

[Failure]
사용자 요청 실패, 504 Gateway Timeout 반환

 

이 시나리오에서 각 단계별 탐지 방법은 다음과 같다.

• Error (잠복) 탐지 - Prometheus
• Error (발현) 탐지 - Loki
• Failure 탐지 - Tempo

3.3 TraceID 기반 로그-트레이스 연계

정리하자면, 장애 발생 시 실제 분석 흐름은 다음과 같다.

 

1. Prometheus 알림 수신: 에러율 증가 또는 응답 시간 증가 알림
2. Grafana 대시보드 확인: 어떤 서비스에서 문제가 발생했는지 Metrics로 범위 좁히기
3. Tempo에서 실패한 Trace 조회: 해당 시간대의 에러 Trace를 검색하여 어느 Span에서 실패했는지 확인
4. Trace ID로 Loki 로그 검색: 실패한 Span의 상세 에러 메시지와 스택 트레이스 확인
5. 원인 파악 및 대응: 로그에서 확인된 구체적 에러를 기반으로 수정 또는 롤백

---

🪄 정리

분산 시스템에서 장애는 Fault → Error → Failure의 인과 관계를 따라 전파된다. Fault가 시스템 내부에 잠복해 있다가 특정 조건에서 Error로 발현되고, 복구되지 않으면 Failure로 이어져 사용자에게 영향을 미친다.
Observability의 세 축은 이 흐름의 각 단계를 탐지하는 역할을 분담한다. Metrics는 "무엇이" 발생했는지 수치로 보여주고, Logs는 "왜" 발생했는지 맥락을 제공하며, Traces는 "어디서" 발생했는지 요청 흐름을 시각화한다.
Prometheus/Loki/Tempo와 OpenTelemetry로 구성된 스택에서 핵심은 Trace ID를 매개로 세 데이터를 연결하는 것이다. 알림 → 대시보드 → Trace → 로그로 이어지는 분석 흐름이 끊기지 않아야 "왜 장애가 발생했는가"라는 질문에 답할 수 있다.
Failure가 발생한 후에 대응하면 이미 늦다. Error 단계, 나아가 Error가 잠복해 있는 단계에서 탐지할 수 있도록 Observability 체계를 설계해야 한다. 이것이 모니터링과 Observability의 본질적 차이다.

---

📙 출처

• OpenTelemetry 공식 문서: https://opentelemetry.io/docs/
• Grafana Tempo 공식 문서: https://grafana.com/docs/tempo/latest/
• Grafana Loki 공식 문서: https://grafana.com/docs/loki/latest/
• Prometheus 공식 문서: https://prometheus.io/docs/