Data Lab

Game Data Project #22-3 - PostgreSQL 기반 게임 구독 관리와 멱등성 구현

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

Game Data Project #22-2 - Docker와 PostgreSQL을 연결해 Discord 게임 검색 구현하기

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을 기존..

Game Data Project #22-1 - Discord Bot 만들고 Slash Command 연결하기

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 알림을 만들 때..

#19에서는 사용자가 Steam Store URL을 입력하면 게임이 games 테이블에 등록되고, 기존 Collector가 해당 게임을 자동으로 인식하도록 만들었다.하지만 한 가지는 여전히 수동이었다.게임을 등록한 뒤 실제 데이터를 수집하려면 직접 다음 명령을 실행해야 했다.game-data-platformgame-data-price즉 구조상으로는 새로운 게임이 Collector 대상에 자동으로 포함됐지만, Collector 자체를 실행하는 것은 여전히 사람이 해야 했다.이번 작업에서는 이 부분을 Airflow와 연결했다.최종적으로 만들고자 한 흐름은 다음과 같다.사용자가 게임 등록 ↓games ↓Airflow Scheduler ↓Player Count Collect..

#18까지 Game Dashboard에서 동접자, 가격, 가격 이력, 최근 패치를 확인할 수 있게 되었다.하지만 한 가지 큰 제약이 있었다.지금까지 Dashboard에서 볼 수 있는 게임은 모두 미리 games 테이블에 등록해둔 게임이었다.즉 새로운 게임을 추가하려면 DB에 직접 데이터를 넣어야 했다.이번 작업에서는 이 구조를 바꿨다.사용자가 Web에서 Steam Store URL 전체를 입력하면:Steam Store URL 입력 ↓Steam App ID 추출 ↓Steam 게임 정보 확인 ↓게임 미리보기 ↓게임 등록 ↓games 테이블 ↓기존 Collector 자동 포함 ↓Game Dashboard까지 이어지는 흐름을..