옵저버빌리티 및 모니터링 아키텍처

옵저버빌리티(Observability)는 시스템의 내부 상태를 외부 신호(메트릭, 로그, 추적)로부터 추론하는 능력이다. 모니터링이 “시스템이 건강한가?”에 답한다면, 옵저버빌리티는 “이 특정 실패가 왜 발생했는가?”에 답한다.

설명

현대적 데이터 파이프라인(Airflow DAG, ETL 잡, 데이터 품질 프로세스)은 실패의 많은 지점을 가진 분산 시스템이다. 전통적 모니터링은 진단 속도가 느리고, 부분적인 신호(task success/fail)만 제공한다. 옵저버빌리티는 완전한 신호 가시성을 통해 Mean Time To Resolution(MTTR)을 단축한다.

5단계 옵저버빌리티 성숙도

1단계: 기본 모니터링 (Built-in UI)

대상: Airflow UI, Jenkins 웹 인터페이스 등 플랫폼 자체 제공 대시보드

제공 신호:

작업 상태 (성공/실패/재시도/대기)
실행 시간 및 로그
의존성 그래프

제약:

수평적 확장 불가능 (thousands of DAG runs에서 UI 응답 지연)
스텐 분석 미지원 (historical trends)
데이터 품질 신호 부재

누구를 위한: 초기 단계 프로젝트, 소규모 팀

2단계: 기본 알림 (Native Notifications)

대상: 플랫폼 자체 제공 알림 기능 (Airflow callbacks, email, Slack webhooks)

구현:

# Airflow DAG-level callbacks
def on_failure_callback(context):
    send_slack_message(f"DAG {context['dag'].dag_id} failed")
 
dag = DAG(
    'my_dag',
    on_failure_callback=on_failure_callback,
    sla=timedelta(hours=2)
)

제공 신호:

Task 성공/실패 이벤트
SLA 위반 알림
재시도 기록

장점: 배포 즉시, 추가 인프라 불필요

제약: 복잡한 상관관계 탐지 불가 (예: “이 task 실패가 다운스트림 DAG 3개에 영향”)

3단계: 커스텀 BI 대시보드 (Custom BI Dashboards)

아키텍처:

Airflow Metadata DB (PostgreSQL)
    ↓ REST API
BI Tool (Looker, Superset, Tableau)
    ↓ SQL Queries
Custom Dashboards
    ↓ Alerts via Email/Slack

모니터링 대상:

DAG 실행 시간 분포 (p50, p95, p99)
Task 실패율 추이
SLA 위반 빈도 및 패턴
Executor 리소스 활용도
태스크 큐 깊이 (bottleneck detection)

예제 쿼리:

-- SLA violations by DAG over time
SELECT
    dag_id,
    DATE(execution_date) AS day,
    COUNT(*) FILTER (WHERE sla_miss = true) / COUNT(*) AS violation_rate
FROM airflow.dag_run
GROUP BY dag_id, DATE(execution_date)
ORDER BY day DESC

장점:

역사적 분석 (trend detection)
팀별 가시성 (self-service BI)
DB 성능 영향 최소화 (REST API 활용)

제약:

BI 도구 운영 비용
대시보드 설계 전문성 필요
실시간성 부족 (시간 단위 갱신)

4단계: 외부 옵저버빌리티 스택 (Prometheus + Grafana)

아키텍처:

Airflow StatsD Metrics
    ↓
Prometheus (스크레이핑, 보유)
    ↓
Grafana (시각화, alerting rules)
    ↓ Webhook
PagerDuty / Slack (알림)

주요 메트릭:

airflow_dag_run_duration_seconds — DAG 실행 시간
airflow_task_duration_seconds — Task 실행 시간
airflow_task_fail — Task 실패 횟수
airflow_celery_task_timeout — Timeout 발생 건수
airflow_scheduler_critical_section_duration — Scheduler 처리 지연

구성 예:

# Prometheus scrape config
scrape_configs:
  - job_name: 'airflow'
    static_configs:
      - targets: ['localhost:8888']  # Airflow StatsD exporter
    scrape_interval: 15s

장점:

아초 단위 해상도 (sub-second granularity)
시계열 분석 가능 (trend, forecast)
Threshold 기반 alerting rules
장기 메트릭 보유 (historical queries)

단점:

Prometheus 운영 복잡도 (retention, sharding)
Grafana 대시보드 설계 시간
팀의 운영 역량 필요

5단계: 관리형 솔루션 (Astronomer Astro, Datadog, New Relic)

Astronomer Astro:

DAG, task, 인프라 메트릭 자동 수집
SLA 위반 자동 감지 (trigger type 무관)
Alert 대시보드 및 Slack 통합
로그 aggregation 및 검색
DAG별 비용 추적

장점: 프로덕션 옵저버빌리티 Zero-to-One (인프라 운영 부담 제거)

단점: 관리형 플랫폼 비용, 데이터 거주 제약

Alerting 설계 원칙

신호 선택 (Signal Selection)

좋은 알림:

SLA 위반 (명확한 임계값)
Repeated task failures (패턴)
Data freshness violation (비즈니스 영향)

나쁜 알림 (Alert fatigue 유발):

모든 task 성공 (noise)
일시적 네트워크 재시도 (자동 복구)
임계값 미설정 알림

에스컬레이션 정책 (Escalation Policy)

Task Failure
    ↓ (first alert)
Slack #data-team (5분)
    ↓ (no ack)
Email to on-call engineer (15분)
    ↓ (no ack)
PagerDuty page + SMS (20분)

Alert Grouping

관련 알림들을 Single Incident로 통합:

Same DAG의 여러 task failures → 1개 incident
Cascading failures (A fail → B fail → C fail) → 1개 grouped incident
Reduces response fragmentation

데이터 품질 모니터링 통합

중요 원칙: Workflow 모니터링 ≠ Data Quality

포괄적 옵저버빌리티:

Airflow Task Success ✅
    ↓
Data Quality Check (Soda, DataHub)
    - Freshness check (데이터 최신성)
    - Schema validation (컬럼 구조)
    - Volume anomaly (행 개수 급변)
    ↓
Data Output Alert (품질 위반 시)

예: Task 성공했지만 데이터 volume이 기대의 50% → Downstream 시스템 데이터 기근 발생

조직 확장시 옵저버빌리티

조직 크기	권장 스택	이유
Solo / 1인	Airflow native + Slack	간단함, 운영 부담 최소
팀 (3-10인)	Custom BI dashboard (Superset)	팀별 자체 대시보드, 운영 가능
스케일업 (10-50인)	Prometheus + Grafana + DataHub	실시간성 + 데이터 계보
엔터프라이즈 (50인+)	Managed 솔루션 (Astronomer, Datadog)	운영 부담 제거, 통합 지원

오류 사례 (Anti-patterns)

UI만 모니터링: 수동 점검은 지속 불가능
알림 없는 대시보드: 대시보드를 정기적으로 보지 않으면 의미 없음
과다 alerting: 100개 알림 중 95개가 거짓 양성 → 피로도로 진정한 신호 놓침
알림 runbook 부재: “Alert X 발생했는데, 뭐 하지?” 상황
데이터 품질 신호 무시: Task 성공 != Data 품질

JYP Garden

탐색기

옵저버빌리티 및 모니터링 아키텍처

옵저버빌리티 및 모니터링 아키텍처

설명

5단계 옵저버빌리티 성숙도

1단계: 기본 모니터링 (Built-in UI)

2단계: 기본 알림 (Native Notifications)

3단계: 커스텀 BI 대시보드 (Custom BI Dashboards)

4단계: 외부 옵저버빌리티 스택 (Prometheus + Grafana)

5단계: 관리형 솔루션 (Astronomer Astro, Datadog, New Relic)

Alerting 설계 원칙

신호 선택 (Signal Selection)

에스컬레이션 정책 (Escalation Policy)

Alert Grouping

데이터 품질 모니터링 통합

조직 확장시 옵저버빌리티

오류 사례 (Anti-patterns)

관련 개념

그래프 뷰

목차