Data Lab

Game Data Project #23 - Discord 패치 알림 구조 재설계와 기존 시스템 분석

1. 기존 Discord 알림 구조를 다시 검토한 이유이전 #22에서는 Discord Bot에 게임 구독 기능을 추가하고, Transactional Outbox와 Worker를 이용해 신규 패치 알림을 자동으로 전송하는 기능까지 구현했다.당시 구조는 다음과 같았다.신규 패치 수집 ↓game_patches INSERT ↓PostgreSQL Trigger ↓patch_notification_outbox ↓Discord Worker ↓구독자 개인 DM실제로 Outbox 작업 선점, 재시도, Lease, Discord DM 전송까지 검증했다.기술적으로는 정상 동작했지만, 구현 결과를 처음 구상했던 서비스와 비교하면서 한 가지 문제를 발견했다.패치노트와 가격 알림의 제공 방식이 서로 달..

Game Data Project #22-4 - Transactional Outbox와 Discord 자동 패치 알림 시스템 구현

1. 게임 구독에서 실제 알림 시스템으로이전 #22-3에서는 Discord에서 게임을 구독하고 관리하는 기능을 구현했다.사용자가 /subscribe 명령어로 게임을 등록하면 PostgreSQL에 구독 정보가 저장되고, /subscriptions와 /unsubscribe를 통해 조회하거나 해제할 수 있게 됐다.Discord 사용자 ↓/subscribe game:Overwatch ↓구독 서비스 ↓PostgreSQL ↓discord_game_subscriptions하지만 아직 구독 정보만 저장할 뿐, 새로운 패치가 발생했을 때 자동으로 알림을 보내는 기능은 없었다.이번 #22-4에서는 기존 Airflow 패치 수집 파이프라인과 Discord Bot을 연결하기로 했다.초기 구현의 목표는 다..

1. Discord에서 게임 구독 관리하기이전 #22-2에서는 Discord Bot을 PostgreSQL과 연결하고 /game 명령어로 게임을 검색하는 기능을 구현했다.Discord 사용자 ↓/game name:Overwatch ↓Discord Bot ↓PostgreSQL ↓게임 검색 결과 반환이제 Discord에서 게임을 조회할 수 있게 되었으므로, 사용자가 관심 있는 게임을 구독하고 관리하는 기능을 추가하려고 한다.이번 단계에서는 다음 세 가지 기능을 구현했다./subscribe — 게임 구독 등록/unsubscribe — 게임 구독 해제/subscriptions — 현재 구독한 게임 목록 조회단순히 명령어만 추가하는 것이 아니라, 구독 정보를 PostgreSQL에 저장하고 중복..

1. Discord Bot에 데이터베이스 연결하기이전 #22-1에서는 Discord Bot을 생성하고 /ping 명령어를 구현했다.Discord 사용자 ↓/ping ↓Game Data Bot ↓Pong! 🏓이 단계에서는 Discord 연결과 Slash Command의 기본 동작을 확인하는 것이 목적이었다.하지만 실제로 만들고 싶은 기능은 단순히 정해진 문자열을 반환하는 Bot이 아니다.기존 Game Data Project에서 수집한 데이터를 Discord에서도 조회하고, 이후에는 게임별 알림 설정까지 관리할 수 있도록 확장하려고 한다.따라서 이번에는 PostgreSQL과 Discord Bot을 연결해 /game 명령어로 게임을 검색하는 기능을 구현했다.동시에 Discord Bot을 기존..

1. Discord Bot을 추가하려는 이유이전 #21에서는 Airflow를 이용해 게임 패치노트를 정기적으로 수집하는 파이프라인을 구성했다.현재 데이터 흐름은 다음과 같다.Airflow ↓Steam / PUBG / Overwatch 패치 수집 ↓패치 감지 및 공통 데이터 동기화 ↓LLM 기반 번역 및 요약 ↓PostgreSQL이제 패치 데이터를 수집하고 저장하는 단계에서 한 걸음 더 나아가, 사용자에게 정보를 전달하는 기능이 필요해졌다.이를 위해 Discord Bot을 추가하기로 했다.처음부터 알림 시스템 전체를 구현하기보다는 다음 순서로 진행하기로 했다.Discord Bot 생성 ↓Bot 연결 확인 ↓Slash Command 구현 ↓데이터베이스 연결 ↓게임 ..

1. 왜 멱등성과 트랜잭션을 공부하게 되었는가?Game Data Project #21에서는 Steam News, PUBG, Overwatch 패치노트 수집을 Airflow에 연결했다.그리고 정기 실행과 부분 실패 감지까지 구현했다.이 과정에서 한 가지 고민이 생겼다."데이터 수집이 중간에 실패해서 다시 실행되면 이미 저장한 데이터는 어떻게 될까?"예를 들어 다음 상황을 생각해 볼 수 있다.1. Steam News 수집 성공2. PostgreSQL에 신규 뉴스 저장 성공3. PUBG 수집 도중 Timeout 발생4. Airflow Task FAILED5. Airflow에서 Task 재실행6. Steam News를 다시 수집이때 이미 저장한 Steam News가 또 저장된다면 중복 데이터가 발생한다.또 다른..

#21-1에서는 기존 패치 수집 파이프라인을 Airflow에 연결했다.Steam News, PUBG, Overwatch의 패치노트를 수집하고, 새로운 패치를 감지한 뒤 LLM으로 번역·요약하는 기존 로직을 하나의 Airflow Task에서 실행하도록 구성했다.실제 airflow dags test 명령으로 수집이 정상적으로 실행되는 것까지 확인했다.하지만 아직 정기 실행을 활성화하지는 않았다.기존 Collector가 일부 오류를 내부에서 처리하는 구조였기 때문에, 실제 수집에 문제가 발생했는데도 Airflow에는 SUCCESS로 표시될 가능성이 있었기 때문이다.이번 #21-2에서는 이 문제를 해결하고, LLM 처리량과 Retry 정책을 정리한 뒤 실제 정기 실행까지 활성화했다.1. Airflow의 SUCC..

#20에서는 기존 Player Count와 Price Collector를 Airflow에 연결하고, 실패 상황에 따른 Skip과 Retry 정책까지 구성했다.이제 사용자가 게임을 등록하면 Airflow가 정해진 시간에 데이터를 수집하고, 일부 게임에서 오류가 발생하더라도 가능한 범위에서 수집을 계속할 수 있다.하지만 아직 자동화되지 않은 수집 파이프라인이 하나 남아 있었다.바로 패치노트 수집 파이프라인이다.패치노트는 이미 Steam News, PUBG, Overwatch를 대상으로 수집하고 있었고, 새로운 패치를 감지하면 LLM을 통해 한국어 번역과 요약까지 수행할 수 있었다.문제는 실행 방식이었다.기존에는 Docker Compose를 시작할 때 별도의 초기화 컨테이너를 통해 패치 수집을 실행하는 구조였..

#20-1에서는 기존 Player Count와 Price Collector를 Airflow와 연결했다.수집 주기는 다음과 같이 구성했다.Player Count→ 매시간Price→ 6시간마다그리고 모든 Collector가 games 테이블을 기준으로 수집 대상을 가져오기 때문에 Web에서 새로운 게임을 등록하면 별도의 코드 수정 없이 다음 Airflow 실행부터 자동으로 수집 대상에 포함된다.하지만 자동으로 실행된다고 해서 바로 안정적인 데이터 파이프라인이 되는 것은 아니다.실제 운영에서는 외부 API 요청이 항상 성공하지 않는다.API 404TimeoutHTTP 5xxNetwork ErrorDB Error잘못된 응답 데이터같은 상황이 계속 발생할 수 있다.이번 작업에서는 이런 오류들을 모두 똑같이 처리하..

백엔드 시스템을 만들다 보면 비슷해 보이는 용어들이 계속 등장한다. SchedulerWorkerQueueOrchestrator 처음 보면 모두: “작업을 자동으로 실행해주는 것” 처럼 느껴진다.하지만 실제 역할은 꽤 다르다.이번에 Game Data Project에서 Airflow로 Player Count와 Price Collector를 자동 실행하면서 이 차이를 이해하기 좋은 시점이 되었다.현재 프로젝트를 단순화하면: Airflow ↓Collector ↓Steam API ↓PostgreSQL 구조다.여기서 질문이 생긴다. Airflow는 Scheduler인가?Worker인가?Queue인가?Orchestrator인가?Collector는 Worker인가?나중에 Discord 알림을 만들 때..