Data Mesh at Grab Part III - Operationalizing Data Reliability with Automated DPIs
15 min read
Data Mesh at Grab (Part III): Operationalizing data reliability with automated DPIs
Author: Harvey Li (Grab) | Source: engineering.grab.com | Published: 2026-08-28
한 줄 요약
인증(certification)은 런타임 실패를 제거하지 않으므로, contract 위반을 구조화된 Data Production Issue(DPI) 로 전환해 triage → RCA → 오너 할당 → 자동 복구로 이어지는 운영 워크플로를 만들었고, 그 결과 DPI의 95% 이상이 자동 생성되고 86.9%가 자동 해결된다.
핵심 주장/내용
왜 인증만으로 부족한가: Part I·II에서 Signals Marketplace(발행·발견·재사용)와 인증의 기반 도구 — Hubble(메타데이터·오너십), Genchi(데이터 품질 관측성), Data Contract Registry(명시적 producer-consumer 보증) — 를 다뤘다
인증은 신뢰할 수 있는 데이터 마켓플레이스의 출발점이고 자산의 오너십·문서·리니지·품질 통제에 대한 신뢰를 준다. 하지만 인증이 런타임 실패를 제거하지는 않는다. 인증된 테이블도 늦게 도착할 수 있고, 인증된 지표도 깨진 의존성에 영향받을 수 있고, 인증된 Kafka 스트림도 freshness 기대를 위반할 수 있다
프로덕션에서 인증된 데이터 제품을 신뢰할 수 있게 유지하려면 사전에 표준을 정의하는 것 이상이 필요하다 — 실패를 탐지하고, 근본 원인을 진단하고, 고치고, 복구를 검증하는 일관된 방법. 그것이 DPI다
DPI 라이프사이클 — 처음부터 최소한의 human-in-the-loop으로 자동화 설계: 좋은 DPI는 행동할 수 있을 만큼 명확해야 하고, 기저 조건이 회복되면 자동으로 닫혀야 한다
라이프사이클은 Grab의 인시던트 오케스트레이터 Kinabalu가 데이터 자산이 더 이상 contract를 만족하지 않을 수 있음을 관찰할 때 시작된다. contract는 그 자산에 중요한 신뢰성 기대와, 그 기대를 평가하는 Test Health API로 노출된 health check를 담는다
오케스트레이터는 플랫폼 내부와 분리되어 있다. 각 플랫폼이 freshness·completeness 등을 어떻게 계산하는지 알 필요 없이 관련 contract test가 healthy한지만 물으면 된다. 하나 이상이 unhealthy면 contract breach로 간주하고 DPI 라이프사이클이 시작된다
Triage — 알림에서 확인된 contract breach로: 데이터 플랫폼은 알림을 많이 낸다(Airflow 스케줄 지연, DQ 테스트 실패, 파이프라인 잡 비정상 종료). 이 알림들은 유용하지만 자동으로 DPI가 되지는 않는다. Triage가 알림이 데이터 자산에 대한 진짜 contract breach를 나타내는지 결정한다
개별 test run 결과와 test의 전체 health를 구분한다. test run은 특정 시점에 통과/실패할 수 있지만 test 자체는 기저 문제가 완전히 해결된 뒤에야 healthy로 간주될 수 있다. 예: T-1 일별 파티션의 completeness test가 이틀 전 실패했고 어제·오늘 통과했다면, 이틀 전 파티션이 백필되어 완전함이 검증될 때까지 test는 여전히 unhealthy로 간주될 수 있다
active unhealthy 조건 기준 중복 제거 — 자산에 같은 breach로 열린 DPI가 이미 있으면 새 신호는 병렬 이슈를 만들지 않고 기존 DPI에 컨텍스트를 추가한다. 같은 근본 원인을 공유하는 DPI들은 그룹화할 수도 있다. 이것이 대응자를 반복적 알림의 흐름을 쫓는 대신 기저 문제 해결에 집중하게 한다
triage 중에 컨텍스트도 모은다 — 영향받은 자산, 위반된 contract, unhealthy test, 데이터 interval, 상·하류 의존성. 모든 알림이 DPI가 되지는 않는다. Triage는 의미 있는 contract breach만 프로덕션 이슈로 승격시켜 운영 워크플로를 노이즈에서 보호한다
Diagnosis — RCA로 오너 할당하기: 모든 데이터 이슈가 데이터 자산 오너에게 할당되어서는 안 된다. 데이터 제품이 unhealthy한 것은 플랫폼 인시던트, 실패한 생산 잡, 지연된 상류 의존성 때문일 수 있다. 모든 이슈를 자산 오너에게 할당하면 불필요한 handoff가 생기고 해결이 느려진다
Data Health API가 “어떤 종류의 실패가 이 자산을 unhealthy하게 만들었나?” 에 답한다. 에러 택소노미를 작게 유지한다:
카테고리
의미
UPSTREAM_ERROR
상류 의존성이 늦거나 실패했거나 가용하지 않음
PLATFORM_ERROR
기저 플랫폼·인프라가 손상됨
JOB_ERROR
생산 잡·파이프라인이 실패함
DATA_ERROR
생산된 데이터가 품질 기대를 위반함
이 택소노미는 플랫폼별 진단을 대체하려는 것이 아니다. 고수준 Data Health API는 오케스트레이터에게 DPI를 일관되게 할당하고 라이프사이클을 관리할 만큼의 구조만 준다. 인제스션·스트리밍·지표·ML 플랫폼은 여전히 상세한 내부 에러 카탈로그·로그·재시도 상태·디버깅 도구를 유지한다. 플랫폼은 내부를 자유롭게 진화시키고, 오케스트레이터는 안정적인 API contract를 소비해 이기종 시스템 간 DPI 워크플로가 상호운용된다
응답 예시:
{ "assetId": "urn:li:dataset:(urn:li:dataPlatform:hive,schema.table_A,PROD)", "healthStatus": "UNHEALTHY", "errorCategory": "UPSTREAM_ERROR", "context": { "upstreamAsset": "urn:li:dataset:(...,schema.table_B,PROD)", "reason": "upstream data has not arrived for the expected data interval." }, "lastCheckedAt": "2026-06-15T08:30:00Z"}
→ 오케스트레이터는 table_A가 자기 문제가 아니라 상류 때문임을 보고 상류 자산의 active DPI를 추적해 table_A DPI를 그것에 링크한다. 하류 DPI가 상류 DPI와 같은 오너를 상속해 관련 실패들이 근본 원인을 해결할 최적 위치의 팀 아래 묶인다
DPI 프로세스는 제기된 이슈가 할당되고 고쳐질 수 있을 때만 작동한다. DPI가 자주 시끄럽거나 중복되거나 행동하기 어려우면 사용자는 결국 무시하는 법을 배운다. 진단 정확도가 중요한 이유이고, 이것이 각 데이터 생산 플랫폼이 자기 진단을 개선하도록 강제하는 forcing function이 된다. 정확한 RCA를 내려면 플랫폼은 자기 로컬 실패 상태뿐 아니라 의존성과 주변 시스템의 신호를 통합해야 한다
Hugo — 인제스션 플랫폼의 3단 진단 아키텍처: 현대 데이터 플랫폼은 여러 독립 시스템에서 알림을 만들고 개별적으로는 데이터셋의 부분적 view만 보여준다. Hugo는 플랫폼별 신호를 통합 진단 워크플로로 합쳐 근본 원인을 짚고 파이프라인 개선책을 추천한다
Signal collection — 여러 신호 소스에서 이벤트를 모아 데이터셋·파이프라인 health의 전체 view 구성
Alert diagnosis — 구조화된 alert context 생성, 알림 분류, 적절한 diagnoser로 라우팅, 특화된 진단 로직으로 근본 원인 식별
Diagnosis result — 식별된 근본 원인·영향받은 데이터셋·권장 수정/조치를 포함한 구조화된 진단 출력 영속화
예: 데이터셋 실패 시 워크플로 오케스트레이터가 잡 실패 이벤트로 Hugo에 알리고, Hugo가 내부 진단 레이어로 라우팅해 상류 DB replica lag 같은 조건을 확인하고, 진단과 권장 수정을 영향받은 데이터셋과 함께 저장
신호 인제스션·진단·결과 관리를 분리한 것이 새 신호 소스와 특화 diagnoser 추가를 간단하게 만든다. 즉각 RCA가 수동 로그 검사의 필요를 없애 remediation을 단축하고 자동 해결 워크플로로 직접 이어진다
Resolution — auto-healing 우선, 필요할 때 인간 판단: DPI의 수명이 data downtime의 프록시다 — contract breach가 탐지될 때 시작해 영향받은 데이터셋이 다시 healthy해질 때 끝난다
많은 인시던트가 routine하고 복구 가능하다 — 일시적 컴퓨트 중단, DB 커넥션 타임아웃, S3 throttling, 영구히 깨진 게 아니라 지연된 상류 파이프라인. Hugo는 이 잘 이해된 실패 패턴에 대해 복구를 자동화한다
Resolution execution — 권장 전략 적용(실패 잡 재시도, 상류 의존성 대기, 커스텀 resolver 실행). 조치 후 파이프라인 health와 데이터 정확성을 모두 검증해 완전 해결을 확인. 데이터 손상·유효하지 않은 레코드·애플리케이션 코드 결함처럼 자동화로 안전하게 해결할 수 없으면 인간 개입으로 에스컬레이션
Notification and audit — 모든 해결 시도와 결과를 기록하고 적절한 엔지니어링 팀에 통지. 그 기록이 운영 분석·감사·해결 정책 개선을 뒷받침
예: 워크플로 오케스트레이터가 일시적으로 무응답이 되어 예약된 인제스션 잡을 제출하지 못해 freshness SLA를 놓친 경우 → 진단 워크플로가 파이프라인 실행 실패로 식별하고 재시도 전략 권장 → Hugo가 자동 재시도, 파이프라인 완료와 데이터 health 회복을 검증, 복구를 로깅하고 담당 팀에 통지. 탐지에서 해결까지 수동 개입 없이 자동 실행
진단과 실행을 분리한 것이 새 진단 능력과 해결 전략이 전체 아키텍처 변경 없이 독립적으로 진화하게 한다
주요 수치 / 사실
DPI 인시던트의 86.9%가 자동 해결됨
DPI의 95% 이상이 사람이 아니라 자동으로 제기됨
자동 DPI의 MTTR이 수동 제기 DPI보다 6배 빠름
가장 중요한 결과는 이슈가 더 빨리 탐지되는 것 자체가 아니라 data downtime이 가시적·측정 가능·감소 가능해지는 것이다. 모든 DPI를 탐지에서 복구까지 추적하면 시간이 어디에 쓰이는지, 어떤 실패 모드가 반복되는지, 자동화가 안전하게 운영 toil을 줄일 수 있는 곳이 어디인지 이해할 수 있다
3부작 전체의 서사: Part I 인증으로 신뢰 구축(중앙 DE 팀 의존 모델이 더 이상 따라갈 수 없어짐) → Part II 인증을 뒷받침하는 플랫폼(Hubble·Genchi·Data Contract Registry로 인증을 정적 라벨이 아니라 능동적으로 유지되는 표준으로) → Part III DPI로 프로덕션에서 그 신뢰를 참으로 유지
Grab의 데이터 moat는 데이터의 양이 아니라 데이터를 신뢰할 수 있고 발견 가능하고 재사용 가능하고 지속적으로 신뢰성 있게 만드는 시스템이다. 이 기반이 agentic 세계를 받아들이게 한다 — AI 에이전트가 인증된 자산을 검색하고, contract와 리니지 위에서 추론하고, 품질 신호를 신뢰하고, 프로덕션 이슈를 탐지하고, RCA 초안을 쓰고, 결국 안전한 remediation을 제안하거나 실행할 수 있다. 그 세계에서 데이터 신뢰성은 복리로 쌓이는 이점이 된다