데이터 관측성(Observability) 어떻게 확보해?

람다(Lambda)나 카파(Kappa) 같은 복잡한 설계를 마친 뒤 가장 두려운 순간은 바로 "지금 이 데이터가 맞는 데이터인가?"라는 의구심이 들 때입니다.

특히 람다 아키텍처처럼 두 개의 경로(Batch & Speed)에서 나온 데이터가 서빙 레이어에서 합쳐질 때, 두 데이터가 서로 다르면 사용자는 시스템을 불신하게 되죠. 이를 방지하기 위한 기술적 장치가 바로 '데이터 관측성(Data Observability)'입니다.

---

👁️ 데이터 관측성(Data Observability): "데이터의 족보와 건강을 추적하라"

전통적인 시스템 모니터링이 CPU와 메모리를 본다면, 데이터 관측성은 데이터의 품질, 흐름, 변화를 관찰합니다. 이를 위해 아래의 5가지 핵심 기둥(Pillars)이 필요합니다.

1. 데이터 리니지(Data Lineage): "데이터의 족보 파악"

데이터가 어디서(S3) 시작해서, 어떤 Spark 잡을 거쳐, 어떤 카프카 토픽을 지나 DW에 안착했는지 그 이동 경로를 시각화하는 것입니다.

• 왜 필요한가: 람다 아키텍처에서 특정 지표가 이상하게 나올 때, 이것이 실시간 경로(Speed Layer)의 문제인지 배치 경로(Batch Layer)의 문제인지 즉시 파악하기 위해서입니다.
• 도구: OpenLineage, DataHub, 혹은 Apache Atlas 등을 사용해 데이터의 흐름도를 자동으로 그립니다.

---

2. 데이터 프로파일링 & 품질 체크 (Freshness & Distribution)

데이터가 "제시간에", "정확한 형태"로 들어오고 있는지 실시간으로 검사합니다.

• 신선도(Freshness): "실시간 데이터가 10초 이상 지연되고 있는가?"를 체크합니다. 카파 아키텍처에서 특히 중요합니다.
• 분포(Distribution): "오늘 들어온 주식 체결가 데이터가 평소 범위를 벗어나 0원이거나 10억 원인가?" 같은 이상치(Outlier)를 감지합니다.
• 도구: Great Expectations나 Deequ 같은 라이브러리를 Spark 파이프라인 중간에 심어, 데이터가 기준을 통과하지 못하면 즉시 알람을 보냅니다.

---

3. 배치-스트림 정합성 검사 (Reconciliation)

람다 아키텍처의 최대 숙제입니다. 똑같은 이벤트에 대해 배치 처리 결과와 실시간 처리 결과가 일치하는지 대조하는 공정입니다.

• 전략: 1시간마다 배치 레이어가 계산한 '누적 거래액'과 스피드 레이어가 계산한 '누적 거래액'을 비교하는 체크섬(Checksum) 작업을 수행합니다.
• 차이 발생 시: 만약 오차가 일정 수준(Threshold)을 넘으면, 시스템은 자동으로 "실시간 데이터를 무시하고 배치 데이터로 서빙 레이어를 덮어쓰기(Overwrite)" 하거나 관리자에게 긴급 알람을 쏩니다.

---

4. 추적(Tracing)과 로그(Logging)

분산 시스템에서는 하나의 데이터 패킷이 수많은 서버를 통과합니다.

• OpenTelemetry 활용: 데이터가 카프카를 통과할 때 고유한 Trace ID를 심어둡니다. 이 ID를 추적하면 데이터가 지연된 정확한 구간(예: Spark의 특정 스테이지, 혹은 카프카의 특정 브로커)을 짚어낼 수 있습니다.
• 메타데이터 로깅: "이 데이터는 Airflow 123번 작업에 의해 생성됨" 같은 꼬리표를 데이터 자체나 메타데이터 저장소에 기록합니다.

---

5. 가용성 및 스키마 변화 감지 (Volume & Schema)

• 볼륨(Volume) 체크: "평소보다 데이터 유입량이 50% 급감했는가?" 이는 소스 시스템(증권사 API 등)의 장애를 암시합니다.
• 스키마 드리프트(Schema Drift): 갑자기 새로운 컬럼이 추가되거나 기존 컬럼의 타입이 바뀌어 파이프라인이 터지는 것을 방지하기 위해, Schema Registry를 통해 데이터 구조를 엄격히 관리합니다.

---

💡 실전 비유: "스마트 팜(Smart Farm) 관리"

주식 종목들이 자라나는 '데이터 농장'이라고 비유해 보겠습니다.

• 모니터링: "농장에 물이 잘 나오고 있는가? (서버가 켜져 있는가?)"
• 관측성: "물이 나오고 있는데, 그 물이 오염되지는 않았는가? (데이터 품질), 물이 식물까지 도달하는 파이프 어디가 새고 있지는 않은가? (리니지), 오늘 수확한 사과의 크기가 어제보다 갑자기 작아졌는데 왜 그런가? (프로파일링)"

관측성이 확보된 농장은 사과가 썩기 전에 미리 원인을 찾아 해결할 수 있습니다. 사용자의 주식 데이터가 '상폐'라는 썩은 사과가 되기 전에 잡아내는 것과 같죠! ㅎㅎㅎㅎ

---

📊 요약: 데이터 관측성 구축 체크리스트

기둥 (Pillar)	핵심 질문	추천 도구
Lineage	"이 데이터 어디서 왔어?"	DataHub, Amundsen
Quality	"이 데이터 믿을만해?"	Great Expectations, Deequ
Freshness	"데이터가 밀리고 있나?"	Prometheus, Grafana (Lag 모니터링)
Volume	"데이터가 왜 이것뿐이야?"	Anomaly Detection 알고리즘
Schema	"데이터 형식이 변했나?"	Confluent Schema Registry

---