관찰가능성이란
시스템의 내부 상태를 외부에서 이해하고 추론할 수 있는 척도를 얘기한다. 예를 들어 대표적으로 Log를 통해 텍스트를 통한 에러나 상태 변경을 기록할 수도 있고, Metrics로 시스템의 성능을 측정하는 방식도 있다.
시스템은 본래 관찰 가능하게 설계됨으로써 시스템에서 발생하는 문제의 근본 원인을 파악할 수 있고 이를 통해 예상치 못한 문제를 사전에 탐지하고자 한다.
관찰가능성의 구성요소
로그
로그는 시스템 내에서 발생한 이벤트의 상세 기록이다. 사용차 요청이라든지, 에러 메시지라든지. 보통 아래와 같이 시간대 별로 Error가 났니, Debug 메시지니 하는 것들을 다 포함한다.
[2024-11-20 10:23:45] ERROR - OrderService - Order ID: 12345 failed due to insufficient stock.
[2024-11-20 10:24:00] INFO - GET /api/v1/users/123 - 200 OK - Response Time: 120ms
메트릭(Metrics)
숫자로 표현되는 정량적 데이터인데 예를 들어 CPU 사용률이나 메모리 소비량이 그 예다
시스템 성능 관련:
- CPU 사용률: 85%
- 메모리 사용량: 1.2GB / 2GB
애플리케이션 성능 관련:
- 초당 요청 수 (Requests Per Second, RPS): 120 req/s
- 평균 응답 시간 (Average Response Time): 200ms
- 에러율 (Error Rate): 0.5%
사용자 행동 관련:
- 활성 사용자 수: 500명
트레이스(Traces)
분산 시스템에서 요청이 처리되는 전체 경로를 추적하는 것이다. 예를들어 A 서비스 -> B서비스 -> C 서비스로 이어지는 호출 흐름이 그 예다.
// 어~ 로그인 요청 시작했네
[Start Trace] User Login - Trace ID: abc123
// 인증 서비스 호출하네~
AuthenticationService - /authenticate - 50ms
// DB 조회하네~
UserDB - SELECT * FROM users WHERE id=123 - 15ms
// 응답 반환하네~
[End Trace] User Login - Total Time: 75ms
// 각 서비스 호출 시간이 이렇네~
API Gateway: 10ms
Order Service: 20ms
Payment Service: 35ms
Shipping Service: 50ms
Total Trace Time: 115ms사실 트레이스는 보이는 것과 같이 로그의 하위 집합으로 볼 수 있다. 다만, 트레이스는 단일 요청이 여러 서비스/컴포넌트를 거치는 전체 흐름을 추적하는 점에서 특징을 갖는다. 이를 통해 분산된 서비스 간 관계 및 성능 문제를 파악하는 데 중점을 두고 있다.
모니터링이란
시스템의 현재상태를 지속적으로 관찰하고 경고를 제공하는 활동이다. 특정 사전에 정의된 기준으로 시스템을 추적하며 이상 징후를 감지하게끔 되어있다. 즉, 이를 통해 사전에 설정된 지표를 기반으로 신속히 대응할 수 있도록 알림을 설정하는 게 그 예다.
모니터링의 구성요소
알림 시스템
기준을 초과하거나 조건을 만족하면 알림을 생성한다
대시보드
실시간 시스템 상태를 시각적으로 표현한다
수집 및 집계 도구
Prometheus, Grafana, Elastic Stack.. 등등 데이터를 수집하고 분석하는 시스템이 갖춰져있다
이렇듯 관찰가능성과 모니터링은 유사한 개념이나 그 목적과 특징이 달리 되어있다.
따라서 관찰가능성은 그 추적이라는 의미에서 복잡한 마이크로서비스 아키텍처에 문제 진단에 강력하며, 이를 시스템 설계 초기부터 고려하는 게 유의미하다. 이와 비교하면 모니터링은 전통적인 서버 관리 및 단일 애플리케이션 환경에서도 유용한데 이는 이미 운영중인 시스템을 안정적으로 운영하고 효율적으로 관리하기 위해 이를 감시하고자 사용된다.