Datadog로 보는 관측 가능성

흩어진 메트릭·로그·트레이스를 태그 하나로 연결해, 장애의 원인을 한 화면에서 좁혀 들어가는 방식을 다룹니다.

관측 가능성과 모니터링의 차이

관측 가능성(Observability)은 로그·메트릭·트레이스 같은 외부 출력만으로 시스템 내부 상태를 추론하는 능력입니다. 전통적 모니터링이 미리 정의한 문제를 감시하는 일이라면, 관측 가능성은 예상하지 못한 문제를 사후에 탐색하는 일에 가깝습니다.

이 차이가 중요한 이유는 마이크로서비스 때문입니다. 사용자의 클릭 한 번이 수십 개 백엔드 서비스와 외부 API(Application Programming Interface)를 거칩니다. 이렇게 경로가 파편화되면 어디서 느려졌는지를 미리 정의해 둘 수 없습니다. 그래서 데이터를 먼저 모아 두고 사후에 질문하는 구조가 필요합니다.

관측 가능성은 세 종류의 데이터를 기둥으로 삼습니다. 각각이 답하는 질문이 다르므로, 셋을 따로 보면 원인을 좁히기 어렵습니다.

기둥	답하는 질문	Datadog 모듈
메트릭(Metrics)	무엇이 얼마나 변했나 (수치 추세)	인프라 모니터링
로그(Logs)	그 순간 무슨 일이 있었나 (이벤트)	로그 관리
트레이스(Traces)	어느 구간에서 느려졌나 (요청 경로)	APM

Datadog은 이 세 기둥에 실사용자 모니터링(Real User Monitoring, RUM)과 보안, 비용 관리를 더합니다. 이들을 하나의 SaaS(Software as a Service) 플랫폼으로 묶어 제공합니다. 자체 백엔드를 운영하는 대신 에이전트로 데이터를 Datadog 클라우드에 보내고, 분석 기능은 빌려 쓰는 모델입니다.

데이터를 모으는 세 갈래

Datadog은 수집 경로를 한 가지로 강제하지 않습니다. 모니터링 대상의 성격에 따라 세 갈래로 데이터를 끌어옵니다. 호스트 안에서 도는 것, 클라우드 바깥에서 도는 것, 애플리케이션 코드 안에서 도는 것이 각각 다른 경로를 씁니다.

첫째는 에이전트 기반 연동입니다. 호스트에 설치된 경량 에이전트가 시스템 메트릭과 로그를 수집합니다. 둘째는 크롤러 기반 연동입니다. 에이전트를 설치할 수 없는 매니지드 클라우드나 Slack, PagerDuty 같은 SaaS 도구에서 자격 증명으로 API를 주기적으로 호출해 가져옵니다.

셋째는 라이브러리 연동입니다. Node.js·Python·Java 같은 런타임에 직접 삽입되어 코드 수준의 APM 트레이스를 얻습니다.

이 세 경로의 공통점은 무거운 연산을 호스트에서 하지 않는다는 점입니다. 에이전트는 데이터를 모아 전송만 하고, 집계·파싱·인덱싱·트레이스 샘플링 같은 부하는 모두 Datadog 클라우드에서 처리합니다. 호스트 자원을 아끼는 이 오프로딩(off-loading) 구조 덕분에 에이전트는 가볍게 유지됩니다. Datadog이 공개한 연동 목록 기준으로 공식 플러그인은 750개를 넘습니다(2024-10 시점, Datadog Integrations 페이지).

태깅이 데이터를 연결한다

수집 구조보다 중요한 것은 모인 데이터를 어떻게 잇느냐입니다. Datadog의 연결 고리는 태그입니다. 에이전트가 데이터를 보내기 전, 모든 메트릭·로그·트레이스에 host, env, service, version, team 같은 메타데이터가 태그로 붙습니다.

백엔드는 이 태그를 관계형 데이터베이스의 외래 키처럼 씁니다. 서로 다른 출처의 데이터라도 태그가 같으면 한 맥락으로 묶입니다. 그래서 env:production의 service:payment에서 CPU가 튀면, 같은 시점의 트레이스 병목과 에러 로그를 한 번에 매칭할 수 있습니다.

태그가 제 역할을 하려면 서비스마다 이름이 일관돼야 합니다. Datadog은 이를 통합 서비스 태깅(Unified Service Tagging)이라 부르며, 세 환경 변수로 표준을 맞춥니다. 이 값을 정확히 넣으면 언어 레벨 로그 프로세서가 모든 로그에 트레이스 ID를 자동으로 주입합니다.

bash

# 통합 서비스 태깅 - 세 변수로 트레이스·로그·메트릭을 한 서비스로 묶는다
export DD_ENV=production
export DD_SERVICE=payment
export DD_VERSION=2.4.1

여기서 DD_ENV는 환경(운영·스테이징), DD_SERVICE는 서비스 이름, DD_VERSION은 배포 버전을 가리킵니다. 세 값이 메트릭·로그·트레이스에 공통으로 붙으면, 특정 버전 배포 직후 에러율이 오른 상황을 버전 태그로 곧바로 좁힐 수 있습니다.

APM과 분산 트레이싱

애플리케이션 성능 모니터링(Application Performance Monitoring, APM)은 요청이 서비스 사이를 지나는 경로를 추적합니다. 이 경로를 분산 트레이싱(Distributed Tracing)으로 시각화합니다. 하나의 요청에 트레이스 ID를 붙이고, 각 서비스 구간을 스팬(span)으로 쪼개 어느 구간이 지연을 만들었는지 드러냅니다.

트레이스가 태깅·로그와 엮이면 디버깅 동선이 짧아집니다. 인프라 대시보드에서 CPU 병목을 발견하면, 그 원인이 된 데이터베이스 쿼리의 실행 계획과 당시 예외 로그까지 연결해 볼 수 있습니다. 메트릭에서 시작해 로그와 트레이스로 내려가는 흐름이 한 화면에서 끊기지 않습니다.

Datadog은 여기에 연속 프로파일러(Continuous Profiler)를 더합니다. 코드 변경이나 재시작 없이 운영 중인 애플리케이션의 메모리 힙과 CPU 점유율을 메서드·코드 라인 단위로 분석합니다. 장애 해결을 넘어 리소스 낭비를 찾아 비용을 줄이는 쪽으로도 쓰입니다.

모니터와 SLO

수집과 상관 분석이 사후 탐색이라면, 모니터는 사전 감시입니다. 모니터는 메트릭·로그·트레이스에 임계값을 걸어 조건을 넘으면 알림을 보냅니다. 메트릭 모니터의 질의는 태그로 대상을 좁히는 형태입니다.

text

avg(last_5m):avg:system.cpu.user{env:production,service:payment} > 80

이 질의는 운영 환경 payment 서비스의 최근 5분 평균 CPU 사용률이 80을 넘으면 발동합니다. {env:production,service:payment}는 앞서 정의한 태그를 그대로 재사용합니다. 태그 체계가 일관되면 모니터·대시보드·상관 분석이 같은 언어를 씁니다.

임계값을 어디에 둘지는 서비스 수준 목표로 정합니다. 세 약어를 구분하면 기준이 분명해집니다.

지표	의미	예시
SLA (Service Level Agreement)	고객과의 외부 약속	99.9% 미달 시 크레딧 지급
SLO (Service Level Objective)	팀 내부 목표	99.95% 가용성 유지
SLI (Service Level Indicator)	실제 측정값	현재 가용성 99.97%

SLO를 정하면 그 여집합이 에러 버짓(Error Budget), 곧 허용 가능한 장애량이 됩니다. 계산은 산술로 끝납니다.

text

SLO = 99.95% (월간)
에러 버짓 = 100% - 99.95% = 0.05%
허용 다운타임 = 30일 x 24시간 x 60분 x 0.05% = 약 21.6분

버짓이 남아 있으면 새 기능을 배포하고, 소진되면 배포를 멈추고 안정성 작업으로 돌립니다. 소진 속도가 빠른지를 감시하는 번 레이트(burn rate) 알림을 함께 걸면, 버짓이 다 닳기 전에 미리 대응할 수 있습니다.

비용이라는 구조적 함정

Datadog의 강점인 통합은 비용 구조에서는 함정이 되기도 합니다. 제품군마다 과금 단위가 다르고, 같은 호스트라도 모듈을 켤수록 비용이 누적됩니다.

제품군	과금 단위 (on-demand 정가)
인프라 모니터링	호스트당 월 15달러
APM	호스트당 월 31달러 (인프라와 별도)
로그 관리	수집 GB당 0.10달러 + 인덱싱 별도

위 수치는 Datadog 공식 요금 페이지 기준이며, 약정·플랜·시점에 따라 달라지므로 도입 시점의 공식 가격을 확인해야 합니다. 표에서 읽을 점은 정확한 금액이 아니라, APM이 인프라와 별도로 호스트마다 붙고 로그는 인덱싱에서 비용이 불어난다는 구조입니다.

비용이 통제를 벗어나는 가장 흔한 원인은 카디널리티(cardinality)입니다. 태그 값으로 version:2.5.7234-alpha 같은 고유 식별자를 쓰면 조합 수가 폭발해 백엔드가 처리할 시계열이 급증합니다. 그래서 메이저 버전 단위의 유한한 태그 풀을 강제하는 거버넌스가 필요합니다.

수집 단계에서 줄이는 방법도 분명합니다. 운영 환경의 DEBUG 로그나 상태 확인(2xx) 로그는 에이전트나 파이프라인에서 드롭합니다. 정상 트랜잭션은 일부만 샘플링하되, 에러나 지연 초과 트레이스는 100% 남깁니다.

이런 필터링·샘플링만으로도 데이터 볼륨을 상당히 줄일 수 있습니다(추정). 보존 주기를 짧게 두고, 장기 보관 로그는 저렴한 버킷으로 아카이빙하는 전략을 함께 둡니다.

정리

Datadog을 떠받치는 것은 수집 경로보다 연결 방식입니다. 세 갈래로 모은 메트릭·로그·트레이스를 태그 하나로 잇는 구조가 중심입니다. 통합 서비스 태깅으로 env·service·version을 일관되게 붙이면, 모니터 질의부터 APM 트레이스, 상관 분석까지 같은 태그 체계를 공유합니다.

SLO와 에러 버짓은 그 위에서 어디에 알림을 걸고 언제 배포를 멈출지를 정합니다. 다만 통합이 깊어질수록 카디널리티와 인덱싱 비용도 함께 자라므로, 태그 거버넌스와 샘플링·보존 전략을 설계 단계부터 함께 세워야 합니다.