에어플로우 모니터링과 알림 노하우안녕하세요, 베이글코드 데이터팀의 데이터 엔지니어 하석윤 그리고 김경훈 입니다. 저희는 Airflow 2nd 밋업에서 “Airflow DAG 좀 살려주세요!”라는 주제로 발표를 진행하였는데요. 이번 포스트에서는 발표 내용을 글로 정리해 전달 드리고자 합니다!데이터팀은 Airflow를 통해 모든 데이터 파이프라인을 자동화 하여 운영하고 있습니다. 원천 데이터 수집과 적재, Spark ETL, 그리고 각종 지표 Alert 그리고 ML/DL 모델 학습까지 Airflow가 모든 것을 관리해주고 있습니다. 그러나 작업을 Airflow에서 DAG를 자동화 하였다고 해서 끝나는게 아닙니다. 아주 여러 이유로 Airflow에 스케쥴링 한 작업이 실패합니다.스케쥴링 했던 작업이 데이터가 늘어나면서 Timeout을 겪을 수도 있고, API 호출을 하는 벤더 사에 장애가 발생하거나, DAG 로직 자체에 오류가 있었을 수 있습니다 데이터 엔지니어의 유지보수 작업은 Airflow 작업 실패에서 시작합니다. 기존에 자동화 해두었던 작업이 실패하게 되면 데이터 엔지니어가 살펴봐야 하죠.Airflow Document: CallbacksAirflow는 Task가 실행되는 과정에서 발생하는 각종 이벤트에 특정 동작을 실행할 수 있도록 callback 인터페이스를 지원 합니다. 성공, 실패, SLA miss, 재실행와 실행, 스킵될 때 특정 행동이 트리거 되도록 지정할 수 있습니다. 이번 글에서는on_failure_callback과 on_retry_callback을 어떻게 커스텀 했는지를 중점적으로 소개 드리고자 합니다.Airflow Document: CallbacksAirflow 공식 문서에 있는 예제 코드인데요. Task에 대한 callback을 DAG 레벨에서도 정의할 수 있고, Task 레벨에서도 정의할 수 있습니다. Airflow 2.6.0 버전부터는 여러 개의 콜백을 정의하는 것도 가능하다고 합니다!Airflow Alert 메시지 개선의 여정Airflow Callback 기능에 대해 간단하게 소개드렸고, 지금부터는 베이글코드가 어떻게 얼럿을 개선했는지 스토리를 소개 해보겠습니다!평소처럼 한명의 데이터 엔지니어가 slack 채널에서 장애 메시지를 발견 합니다.아, 오늘은 어떤 작업이 터졌을까~~위의 캡쳐는 베이글코드에서 몇년 동안 사용하던 에러 메시지인데요. 저도 회사에 입사한 이후로 3년 넘게 저 메시지를 보면서 작업을 디버그 했습니다. 그런데, 어느 순간 이런 생각이 들었습니다.이게 최선일까?Task는 얼마나 실행된건지, 어떤 Operator가 실패한건지, 디버그 해야 하는데 어디를 들어가야 하는지도 안 나와 있었습니다. 저희는 기존 메시지를 더 개선할 수 있다고 생각했고, 작업을 시작 했습니다!Raw URL 대신 링크에 Alias를 사용일단 첫번째 개선에서는 기존에 지저분하게 있던 Raw URL에 Alias를 부여 했습니다. DAG 웹페이지에도 바로 접속할 수 있도록 링크도 추가하였습니다.DAG 페이지에 대한 링크를 추가한

안녕하세요. Azar Matching Dev Team 의 Zeze 입니다. Flink 는 대다수의 백엔드 엔지니어들에게 친숙한 기술은 아니지만, 이벤트 스트리밍 처리를 위한 대표적인 기술 중 하나입니다. 대규모 실시간 데이터 스트리밍 처리를 위해 분산 환경에서 빠르고 유연하게 동작하는 오픈소스 데이터 처리 엔진이며, 팀 내에서는 Azar 의 핵심 로직인 매칭 서버를 구현하는 데에 사용되고 있고, 사내에서는 보통 Kafka 를 source 및 sink 로 사용하는 애플리케이션 코드를 직접 작성하는 방식으로 많이 사용하고 있습니다. 오늘 소개할 Flink SQL 은 애플리케이션 코드를 직접 작성하지 않고도 SQL 을 통해 이벤트 스트리밍 처리 앱을 구현할 수 있도록 해주는 기능입니다. 이번 글에서는 이벤트 스트리밍 처리를 위해 Flink SQL 을 채택한 이유와 클러스터 환경 구축 및 운영 경험을 공유하려고 합니다.Azar Matching Dev Team 에서 관리하던 여러 Flink 기반 앱들 중, CPU 를 무려 96개나 사용하던 매우 무거운 레거시 앱이 있었습니다. 이 앱은 여러 매치 이벤트를 조인하고, 로직에 따라 조건부로 새로운 이벤트 발행하거나 Redis에 플래그를 저장하는 등 다양한 기능을 한 곳에 몰아넣은 모놀리식 구조였습니다. 유지보수가 어려운 상태에서 전사 인프라 작업으로 인해 해당 앱의 실행 노드를 변경하자, 앱이 정상적으로 동작하지 않는 문제가 발생했고, 몇 차례 단순 튜닝을 시도해 보았지만 빠르게 해결하기 어려웠습니다. 그 결과, 높은 운영 피로도를 감수하며 이 앱을 계속 유지보수 할지 아니면 다른 방법으로 대체할지를 결정해야 했습니다.다행히 기존 앱의 로직 중 중요한 이벤트들을 조인하는 기능은 (아래 그림에서 에 해당하는 부분) 별도의 프로젝트를 진행해 이미 새로운 Flink 앱으로 구현해 놓은 상태였기 때문에 이를 레버리지하는게 유리한 상황이었습니다. 그렇다면 위 그림처럼 이벤트 조인 이후 수행하는 조건부 이벤트 발행 또는 로직 수행 부분을 어떤 방식으로 대체할지를 고민해야 했는데요, 다음과 같은 선택지 및 장단점이 있었습니다.• 하나의 Flink App 으로 구현• 장점 - 하나의 앱만 관리하면 되므로 운영이 간편합니다.• 단점 - 또 다시 거대한 앱이 될 가능성이 크며, 앱의 한 부분이 실패할 경우 다른 기능도 영향받기 쉽습니다.• 여러 Flink App 으로 구현• 장점 - 각 앱을 독립적으로 관리할 수 있어 유연합니다.• 단점 - 앱의 개수가 늘어나면, 클러스터/리소스/배포 관점에서 부담이 증가할 수 있습니다.• Flink SQL 을 사용• 장점 - 쿼리를 통해 로직을 정의하므로 빠른 개발이 가능하며, 하나의 클러스터만 관리하면 됩니다.• 단점 - SQL 만으로는 복잡한 로직을 표현하기 어렵고, 팀이 클러스터 관리에 익숙하지 않다면 어려울 수 있습니다.팀에서는 Flink 의 내부 구현에 대해 꽤나 이해도가 높아져 있는 상태였기 때문에, Flink SQL 을 사용하면 생산성 및 운영 효율성에서 이점이 있

Unity Catalog로 전환 하면서 겪은 모든 것안녕하세요, 베이글코드 데이터 엔지니어 하석윤 입니다. 베이글코드 데이터팀의 메타스토어를 Hive Metastore에서 Unity Catalog로 전환한 여정을 소개드리고자 합니다.왜 Unity Catalog를 도입하게 되었나요?베이글코드의 DATA&AI 팀은 2018년부터 Databricks를 활용하여 데이터 웨어하우스의 기반을 구축하고, 사내의 데이터 기반 의사결정을 지원해 왔습니다. 현재 약 10,000여 개의 테이블을 ETL, 데이터 분석 및 활용에 사용하고 있습니다. 그동안 이 모든 테이블은 Databricks의 Hive Metastore에서 관리되었습니다.2021년, Databricks는 새로운 Metastore 솔루션인 Unity Catalog를 발표합니다. 하지만 데이터 엔지니어로서 실무에서 Unity Catalog의 임팩트를 체감하기까지는 여러 장애물이 있어 시간이 걸렸습니다. 그래도 DAIS(Databricks AI Summit) 컨퍼런스에 다녀온 팀원들이 테이블 계보(Table Lineage)나 Serverless Compute와 같은 기능들을 정리해 공유해 주셨고, 팀에서는 “이 기능을 언제쯤 써볼 수 있을까?”, “UC가 있다면 작업에 정말 도움이 될 것 같다”는 기대를 하였습니다.Databricks는 매력적인 신기능들을 지속적으로 출시했지만, Unity Catalog 환경에서만 지원 하는 경우가 종종 있었고, Hive Metastore를 사용하는 저희는 기능들을 도입하고 싶어도 도입하지 못하는 상황이었습니다. 제약 사항을 더 이상 방치할 수 없다고 생각하게 된 저희는 2024년 상반기 프로젝트로 ‘Unity Catalog 마이그레이션’을 계획하였고, 약 5개월간의 과정 끝에 데이터 팀의 Metastore를 Unity Catalog로 성공적으로 이전하였습니다!왜 Databricks는 Unity Catalog를 출시하였는가?Overview of Unity CatalogDatabricks의 테크 블로그에 기고된 “Understanding Unity Catalog”라는 아티클을 읽어보면, Unity Catalog를 개발하게 된 이유와 히스토리를 엿볼 수 있습니다. 아티클의 내용을 정리하면 아래와 같습니다.Databricks 사용자 중에 Multi-Workspace를 사용하는 경우가 종종 있었다고 합니다. 이 Workspace들은 하나의 데이터 소스에서 데이터를 읽고 사용했는데, 같은 Access Control을 Workspace 마다 반복 진행하는 게 번거로웠다고 합니다. 이것은 Hive Metastore가 Workspace 레벨로 존재하기 때문입니다.Hive Metastore의 경우, Schema 전체를 허용해 주거나 개별 Table을 일일이 허용해 주어야 했습니다. 이것은 새로운 테이블이 추가될 때마다 접근 정책을 변경해야 하는 번거로움이 있었습니다.S3와 같이 External Location에 접근하는 경우, 그 접근 권한이 Cluster의 Instance Pro

안녕하세요. 데브시스터즈 데이터플랫폼그룹의 박기범, 서혜인입니다.여러분은 사업 지표를 얼마나 신속하고 정확하게 확인하고 싶으신가요? 아마 대부분 가능한 빠른 시점에 정확한 지표를 확인하고 싶어 하실 겁니다. 하지만, 데이터팀 입장에서는 사용자가 원하는 수준으로 정확하고 신속한 지표 서비스를 제공하기 위해 기술적으로 해결해야 하는 많은 문제들에 직면하게 됩니다. 이번 글에서는 데브시스터즈가 지난 수개월간 준실시간 지표 서비스를 도입하는 과정에서 마주하게 된 여러 기술적 도전 과제들과 해결 과정에 대해 소개해드리고자 합니다.게임 런칭 당일에 어떤 지표를 볼 수 있나요?신규 게임이 출시되는 날, 모든 구성원의 관심은 게임 지표에 집중됩니다.출시 직후 촌각을 다투는 상황에서는, 게임팀에서 유저의 접속 현황과 매출 성과에 따라 빠르게 의사결정을 내릴 수 있도록 “정확하고 신속하게” 지표를 확인할 수 있어야 합니다. 정확하지 않은 지표는 자칫하면 잘못된 의사결정을 초래할 수 있으며, 지표 조회가 지연되면 중요한 순간에 빠른 결정을 내리기 어려워지기 때문입니다.이런 이유로 대부분의 데이터 조직은 짧은 지연 시간으로 주요 지표를 확인할 수 있는 준실시간(near real-time) 지표 서비스 도입을 고려하게 됩니다. 하지만, 왜 많은 회 사들이 준실시간 지표 서비스 도입에 어려움을 겪고 있을까요?각 회사마다 마주한 상황은 다르겠지만, 데브시스터즈에서 그동안 준실시간 지표 서비스를 도입하지 못한 데는 다양한 이유들이 있었습니다.데브시스터즈에서는 2015년부터 Spark 과 Elastic Stack 기반의 빅데이터 플랫폼을 운영해 왔습니다.2021년에는 Databricks를 도입하여 Lakehouse Architecture와 Medallion Architecture 기반의 데이터 환경을 구축했습니다. 이를 통해, DB와 로그 등 게임 서비스와 여러 플랫폼에서 발생하는 다양한 데이터를 가공 및 집계하여 지표 서비스에 활용 중이었습니다.해당 환경에서 지표를 서비스하는 방법은 크게 세 가지로 구성되어 있었습니다.• 게임 서버에 연결된 세션 수를 기반으로 동시 접속자 (이하 '동접') 지표를 집계합니다.• 시간별 배치로 운영계 DB 테이블을, 일별 배치로 로그를 ETL하여 Data Warehouse와 Data Mart에 적재합니다.• Elasticsearch 에 적재된 로그 원장을 기반으로 Kibana 에서 준실시간으로 갱신과 조회가 가능한 대시보드를 구성하여 활용합니다.이처럼 기존 지표 환경에서도 게임 런칭 당일 제공할 수 있는 지표들이 존재하였지만, 사용자 요구를 완전히 충족시키기엔 한계가 있었습니다.기존 동접 지표는 서버 입장에서의 세션 수만 수집했기 때문에 국가별, 스토어별 세부 동접 지표는 확인할 수 없었습니다. 특히 게임 런칭 초기에는 특정 국가의 반응, 스토어 및 OS별 접속 현황, 10분 단위의 접속자 추이를 빠르게 파악할 필요가 있었지만, 이를 확인할 수 있는 방법이 없어 불편했습니다. 반면 DB 기반의 시간별 지표에서는 여러 차원에서 지표를