(아래 자료는 팀 내 세션 진행을 위해 제작한 글입니다)
관측 가능성 (Observabliity)
💡
“시스템의 내부 상태를, 외부에서 관측 가능한 데이터만으로 얼마나 잘 이해할 수 있는가”를 의미한다
시스템 안에서 무슨 일이 벌어지고있는지
문제가 생겼을 때 왜 그런 일이 발생했는지
지금 상태가 정상인지 / 비정상인지
위와 같이 로그 메트릭, 트레이스 같은 신호(signal)를 통해 추론할 수 있는가를 말한다.
(≠ 모니터링한다와는 다름. 관측 가능성은 한단계 더 높은 개념임)
모니터링 ≠ 관측 가능성
모니터링(Monitoring)
관측 가능성(Observability)
사전에 예상하지 못한 문제도
데이터를 통해 원인을 탐색하고 설명 가능
“이 장애는 왜 발생했나요?”
“어떤 요청 경로에서 문제가 시작된건가요?”
⇒ 모니터링은 알려진 문제를 감지 , 관측가능성은 알려지지 않은 문제를 이해 에 집중하는것임.
관측가능성의 중요성
현재 KOS 시스템은 MSA / MFA로 많은 서비스를 운영중임
단일 서비스로 운영하고있지않기때문에, 어디서 문제가 시작됐는지 감으로는 파악이 아예 불가능함
또한 시스템 장애는 예상치못하게 언젠가는 발생함
이 때, 얼마나 빨리 원인을 파악하고
얼마나 정확하게 복구하느냐
관측가능성의 3대 핵심 요소(Three Pillars)
메트릭 (Metrics)
수치 기반의 시계열 데이터
상태 변화 감지에 최적임
로그 (Logs)
트레이스 (Traces)
그래서 관측가능성은 보통 어떻게 관리함?
계측(instrumentation)
- Application과 Infra에 메트릭 수집 / 로그 표준화 / 트레이싱 심기 를 함
중앙 수집 & 저장 (Collector)
시각화 & 탐색
알림 & 대응
우리 팀은 어떻게 관측 가능성을 관리중임?
데이터독?
데이터독 핵심 Features
Infrastructure Monitoring
요청 단위 트레이싱을 통해 서비스 간 호출 흐름 추적 가능
병목 구간, 지연 원인, 에러 발생 지점 파악
어디서 문제가 시작됐는지 확인 가눙
Log Management
RUM (Real User Monitoring)
실제 사용자의 요청 흐름과 성능을 브라우저 단에서 관측함
사용자 경험 관점에서의 지연, 에러, 이탈 지점 파악 가능
서버 관점 아닌, 사용자 관점의 관측 가능성을 제공함
대시보드 & 알림
메트릭, 로그, 트레이스를 하나의 화면에서 시각화해줌
임계치 기반 알림을 넘어, 이상 징후(anomaly) 감지
SLO 기반 운영 지표 구성 가능
데이터독은 어떻게 수집 / 저장을 할까?
애플리케이션에서 메트릭 발생
Datadog Agent가 메트릭을 수집
- Datadog Agent: 메트릭, 로그, 트레이스를 수집하는 경량 데몬 프로세스임
Datadog 플랫폼으로 전송 및 저장
그 뒤 대시보드, 알림, 분석에 활용
Service Map을 보면
데이터독이 인프라에 어떻게 세팅되어있을까?
Datadog Agent
Datadog Cluster Agent
Pod 생성
Replicas 수, Ready 여부
이벤트(Failed, CrashLoopBackOff 등)
각 컴포넌트를 통합해서 보면
Datadog Cluster Agent는 Pod 생성 시 Pod Spec을 mutate하여
APM tracer(dd-java-agent, dd-trace 등)를 주입하고
애플리케이션 Pod에서 발생한 stdout/stderr 로그는 컨테이너 런타임(eg. containerd, docker)에 의해 노드의 로그 파일로 기록된다
(Span은 데이터독 에이전트로 바로 로컬 통신으로 전달함)
Datadog Agent는 각 노드에서 이 로그 파일을 비동기적으로 tailing하고
Span/Metric은 애플리케이션으로부터 네트워크로 직접 수신하여
내부 버퍼링·샘플링 후 HTTPS를 통해 Datadog SaaS로 전송한다
(제일 얘기하고싶었던) 데이터독 Monitors 소개
Application / Infra에서 데이터가 발생하고
Datadog Agent가 이를 수집해서
Datadog SaaS에 저장하는것까지 이해함
우린 이제 저장된 데이터를 잘 활용해서 관측가능성을 올려야한다
Datadog Monitors
[관측 데이터]
↓
[조건(Condition)]
↓
[임계치 / 패턴]
↓
[상태 판단]
↓
[알림(Notification)]
만약 모니터가 없었다면?
위와 같은 OOM Killed Event를 감지 못했을것임
HPA 등을 걸어놓아 리소스가 부족했을 때 스케일링도 중요하겠지만 OOM 발생이 정말 처리량이 많아져서 리소스가 부족해졌을 수 있지만
- 메모리 릭이나 예상하지못한 처리로 인해 문제가 발생할 수 있다
그렇기떄문에 우리는 이런 비정상 사건(events)에 대해 꼭 인지할 수 있도록 관측 가능성을 올려야함
이제 각자 모니터 만들어봐요. (15분동안)
끝.
