에어플로우 모니터링과 알림 노하우안녕하세요, 베이글코드 데이터팀의 데이터 엔지니어 하석윤 그리고 김경훈 입니다. 저희는 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 페이지에 대한 링크를 추가한

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

안녕하세요. 카카오페이증권 DevOps 팀의 테라입니다.본 글은 사내 지식저장소를 구축하기 위해 Amazon Bedrock과 슬랙봇을 통합하고 고도화한 경험을 공유하기 위해 작성되었습니다.본 프로젝트는 ‘siri’ 라는 이름으로 (Apple의 siri가 모티브인 것 맞습니다.), 카카오페이증권의 산재된 내부 정보들을 검색증강생성(RAG)으로 구현하여 LLM을 통해 쉽게 조회하고자 기획되었습니다. 또한 보안상 ChatGPT 등의 외부 AI 도구들을 사내에서 사용할 수 없었는데요, 그 대체를 만들고 싶기도 했습니다.그러다가 좀 더 카카오스럽고 귀엽게, 춘식이를 곁들여 ‘춘시리’ 라는 이름으로 발전하게 되었습니다.춘시리에게 원하는 것초기 목표는 다음과 같았습니다.• AI 봇에게 내부 문서(Confluence)를 학습시킨다.• AI 봇은 학습된 내부 정보를 바탕으로 내 질문에 대답해 준다.• 필요한 경우, AI 봇은 내부 정보가 아닌 일반 LLM 답변도 제공한다. (ChatGPT 대체)추가로 다음 기능까지 구현하고자 하였습니다.• 수동으로 추가 정보를 학습시키기• 지라 티켓을 분석하고 요약해 주간 리포트, 장애 리포트 등을 자동으로 작성해 주기또한 카카오 사내 커뮤니케이션 툴인 아지트(Agit)에 저장된 내용들도 학습하고 취합할 수 있기를 기대하였습니다.저희는 그전까지 AI를 활용한 개발 경험이 없기에, LLM, RAG, Embedding 개념 등을 처음으로 공부해 가며 시작하였습니다. 따라서 본격적으로 춘시리 아키텍처를 설명하기 전에, 춘시리를 구성하는 AI 관련 컴포넌트들에 대해 가볍게 설명하고 넘어가도록 하겠습니다.먼저 LM(Language Model, 언어 모델) 이란, 인간의 언어를 이해하고 생성하도록 훈련된 인공지능 모델입니다. 그리고 LLM(Large Language Model, 거대 언어 모델) 은 방대한 양의 데이터로 사전 학습된 초대형 딥러닝 언어 모델입니다.설명만 들어도 느끼셨겠지만, LLM을 직접 개발하기 위해서는 상당히 많은 자원(인적 자원, 컴퓨팅 자원 등)과 전문 지식이 필요합니다. 저희는 데이터 사이언티스트가 아니고, AI 관련 지식이 부족하기 때문에 외부 상용 LLM 모델을 사용해야 합니다. 상용 LLM 모델의 대표적인 예로는 OpenAI의 GPT 시리즈와 Meta의 Llama 시리즈가 있습니다.Amazon Bedrock(이하 베드락) 은 다양한 LLM 모델을 호스팅해주고, 쉽게 다른 서비스와 연동할 수 있는 API를 지원하는 AWS의 매니지드 서비스입니다. 즉, 베드락을 사용하는 경우 AWS API를 사용해 다양한 외부 LLM을 사용할 수 있으며, 모델을 직접 호스팅하고 관리할 필요가 없습니다. 게다가 AWS를 이미 사용하고 있는 경우, AWS 비용으로 같이 청구되므로 추가적인 빌링 프로세스가 생길 필요 또한 없습니다.저희는 내부적으로 이미 AWS를 사용하고 있고, AI관련 지식도 부족하므로 매니지드 서비스인 베드락을 통해 다양한 LLM 모델을 사용해 보기로 결정하였습니다. 다만 아직 서울 리전에서는 베드락으로

안녕하세요! 당근 알림 경험팀에서 백엔드 엔지니어로 일하고 있는 데이(Daey)라고 해요. 알림 경험팀은 일반적인 플랫폼 조직이 아닌, 모든 유저의 알림 경험을 고민하는 서비스 조직이기도 해요. 알림 기능을 개발하다 보면 아래와 같은 말을 자주 듣곤 하는데요.“알림은 그냥 보내달라는 대로 보내면 되는 거 아닌가요?”네, 그냥 보내달라는 대로 보내면 되는 게 아니에요. 알림은 먼저 사용자에게 접근할 수 있는 강력한 수단이지만, 사용하기에 따라 긍정적 경험뿐만 아니라 부정적 경험도 줄 수 있는 양날의 검이에요. 따라서 알림 경험팀은 단순히 알림을 잘 보내기 위한 플랫폼만 만드는 게 아니라, 유저가 알림을 통해 어떤 경험을 얻어갈지도 치밀하게 고민하고 있어요.그런데 알림 경험팀에서 생각하는 모든 유저에는 단순히 당근 앱 사용자만 포함되지 않아요. 알림을 발송하는 당근의 구성원들까지도 포함하죠. 이는 알림을 발송하는 당근 구성원들의 긍정적 알림 경험이 장기적으로 당근 앱 사용자들의 긍정적 알림 경험에 기여한다고 믿기 때문이에요.이번 글에서는 알림을 받는 사용자뿐만 아니라 알림을 발송하는 당근 구성원들의 경험도 효과적으로 개선한 ‘알림 신호등 프로젝트’를 소개하려 해요. 사용자의 알림 경험을 개선하기 위한 모니터링 기준을 마련하고, 챙겨야 하는 알림들이 모니터링 결과와 함께 담당자를 직접 찾아가는 시스템을 개발한 프로젝트죠. 사용자의 경험을 개선하기 위한 알림 경험팀의 치열한 고민과 해결 방법을 공유해 드릴게요.알림 경험팀이 발견한 문제 상황저희 팀에서는 먼저 당근 앱 사용자들과 당근 구성원들의 알림 경험에 부정적인 영향을 주는 요소들을 면밀히 파악했어요. 크게 세 가지 문제점을 도출했는데요. 각 문제점이 당근 앱 사용자와 당근 구성원 각자에게 어떤 영향을 미치는지 구체적으로 설명해 드릴게요.1. 방치된 알림더 이상 발송하지 않는 알림이 발송 가능한 상태로 남아있는 경우를 생각해 보세요. 이렇게 방치된 알림들은 당근 사용자들의 알림 경험에 어떤 영향을 미칠까요? 예를 들어 22대 국회의원 선거 알림이 지금 발송된다면 어떨까요? 왜 이 알림이 지금 발송됐는지 의아해하며 부정적인 알림 경험이 쌓일 거예요.이런 경우도 한번 생각해 봅시다. 최근 당근 알림함은 스레드 알림 형태로 변경되었는데요.예 - 스레드 알림함스레드 알림에는 알림들을 스레드의 형태로 묶어줄 스레드 제목이 필요해요. 예를 들어 사진 속 알림의 스레드 제목은 ‘동네생활’이고, 알림 내용은 ‘구미동 인기글 확인하실 daeung님 구해요’인 것처럼 말이에요. 그런데 만약 스레드 설정이 되어 있지 않은 알림이 스레드 알림함에 노출된다면 어떨까요? 일반 알림에는 이런 정보들이 입력되어 있지 않기 때문에, 이런 알림이 스레드 알림함에 노출된다면 알림 내용이나 제목이 누락될 수 있어요.이런 상황을 방지하기 위해서는 당근 구성원들이 기존에 설정해 둔 알림들을 주기적으로 살펴봐야 해요. 불필요해진 알림을 제거하거나 내용 업데이트가 필요한 알림들을 수정해야 하죠. 그런데 현실적으로 다른 업무들을 살피다