[DRE] 데이터 파이프라인 장애 감지 자동화 — Airflow + Teams 연동
📌 이 글의 핵심 요약
- 무슨 문제인가: 기존 팀 단위의 단편적인 모니터링 방식으로는 본부 전체 사용자가 무작위로 생성하는 수많은 Databricks 워크플로우의 성공/실패/지연 상태를 체계적으로 관리하고 대응하기 어려웠음.
- 어떻게 해결했나: Databricks Job/Task API를 주기적으로 호출하는 자동 탐지 백엔드를 개발하고, 메타데이터 저장을 위한 RDS 구축 및 비공개 Teams 채널 연동을 아우르는 전사적 워크플로우 관측 가능성(Observability) 알림 아키텍처를 수립함.
- 무슨 효과를 얻었나: 본부 내 누구나 워크플로우를 생성해도 별도 설정 없이 실시간 장애 알림이 자동 적용(바이브코딩 배려)되었으며, 단순 감지를 넘어 장애 원인을 신속히 진단할 수 있는 데이터 신뢰성(DRE) 기반을 마련함.
이 글은 AI를 기반으로 작성하였으며 실제 제가 만든 Monitoring의 내용을 Gemini와 함께 작성하였습니다.
안녕하세요. 데이터 엔지니어로 일하며, 최근 DRE(Data Reliability Engineer)로의 도전을 시작한 주형권입니다. 그 첫 번째 발걸음으로, 제가 소속된 본부 전체가 함께 사용할 수 있는 'Databricks Job 자동 감지 및 알림 시스템'을 구축한 이야기를 공유해보려 합니다.
🚀 왜 이 시스템을 만들었나?
사실 기존에도 팀 내부적으로 쓰던 모니터링 방식은 있었습니다. 하지만 체계화보다는 '일단 돌아가게' 만드는 데 급급했죠. 이번에는 차원이 다릅니다. 본부 전체 인원이 스케일에 상관없이 안정적으로 사용할 수 있는 시스템을 목표로 했습니다. 제가 생각하는 데이터 신뢰성(Reliability)의 로드맵은 다음과 같습니다.
Monitoring -> Observability -> Reliability
결국 신뢰성 있는 데이터 파이프라인을 구축하려면, 가장 기초 단계인 **Monitoring(모니터링)**이 체계화되어야 하고, 이를 넘어 **Observability(관측 가능성)**가 확보되어야 합니다.
그래서 이번 프로젝트에서는 Databricks에서 발생하는 모든 워크플로우의 성공/실패/지연 상황을 체계적으로 감지하고, 조건에 따라 적절한 담당자에게 즉시 알림을 보내는 시스템을 한 땀 한 땀 만들어 보았습니다.
📋 4가지 핵심 구축 조건
시스템 개발에 앞서 본부 전체 사용자를 고려한 4가지 필수 조건을 정립했습니다.
- 불특정 다수 커버: 본부 누구나 Workflow를 만들어도 Teams 채널을 통해 알림을 받을 수 있어야 함.
- 비공개 Teams 채널 대응: 회사 Teams 채널은 비공개이므로, 알림을 받으려면 반드시 '초대' 프로세스가 선행되어야 함.
- 바이브코딩(비개발자) 배려: Databricks에 익숙하지 않은 사용자가 워크플로우를 만들어도 무조건 알림 대상에 포함되어야 함.
- 직관적인 알림: 누구나 메시지만 보고도 상황을 즉시 파악할 수 있어야 함.
이 조건들을 충족하기 위해 정책과 개발 방향을 꼼꼼히 설계했습니다.
⚙️ 개발 및 정책 핵심
복잡하지는 않지만, 안정성을 위해 여러 가지 고민을 담았습니다.
1. 알림 발송 개발 방식 (백엔드)
- API 기반 주기적 탐지: Databricks의 Workflow 리스트 API와 Task API를 주기적으로 호출하여 상태 변경(특히 실패)을 지속적으로 감지합니다.
- 상태 저장 및 중복 방지 (RDS): 추후 Observability 확장을 고려하여 데이터를 RDS(MySQL)에 저장합니다. ON DUPLICATE KEY UPDATE 구문을 활용해 리스트와 Task 테이블을 효율적으로 업데이트합니다.
- 알림 히스토리 관리: job_result_state 칼럼으로 실제 발송된 메시지 종류를 표시하고, updated_at으로 최종 발송 시점을 체크하여 중복 알림을 방지합니다.
2. 운영 정책 및 자동화 (Tagging)
- Teams 채널 자동 초대 (SMTP): Databricks 권한이 있는 사용자가 Workflow를 생성하는 순간을 API로 캐치합니다. 해당 사용자에게 자동으로 이메일(SMTP)을 발송하여 Teams 채널 가입을 유도합니다.
- Tag 정책 기반 자동 할당: Databricks는 태그에 콤마(,)를 지원하지 않아 슬래시(/)를 구분자로 사용했습니다.
- alert_type: S(공), F(실패), L(지연) 플래그 조합. (예: S/F/L)
- alert_user: 알림을 받을 사용자 ID(여러 명 가능).
- 자동 Tagging: 시스템이 주기적(10분마다)으로 탐지하여 Tag가 없는 워크플로우에는 정책에 따라 자동으로 Tag를 달아줍니다.
✨ Gemini와의 티키타카, 그리고 깨달음
이번 개발 과정에서 특별했던 점은 인공지능(Gemini)을 적극적으로 활용했다는 것입니다. 단순히 코드를 짜달라고 하는 것을 넘어, "내가 설계한 이론에 논리적 모순이 없는지", "코드의 리팩토링 방향은 맞는지", "비효율적인 쿼리나 프로세스는 없는지"를 Gemini와 계속 주고받으며 검증했습니다. 그 결과, 혼자 고민했을 때보다 개발 생산성이 비약적으로 향상되었고, 더 견고한 시스템을 만들 수 있었습니다.
🚩마치며
단순한 알림 발송처럼 보일 수 있지만, '본부 전체'라는 스케일과 '비개발자'라는 사용자 경험을 고려하니 많은 고민이 필요했던 프로젝트였습니다. 이 시스템이 본부 데이터 파이프라인의 신뢰성을 높이는 든든한 주춧돌이 되기를 기대합니다. 그리고 아직 데이터 환경을 갖추지 못한 여러 회사에게 도움이 되기를 기원합니다.