Data Lab

Scheduler, Worker, Queue, Orchestrator는 각각 무엇을 하는가

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

Game Data Project #20-1 - Airflow로 게임 데이터 수집 자동화하기

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

Game Data Project #19 - Steam URL로 게임을 등록하고 기존 수집 파이프라인에 연결하기

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

FastAPI로 API를 만들기 시작하면 처음에는 구조가 단순하다.Route→ DB 조회→ Response예를 들어 특정 게임 정보를 조회하는 API라면 다음 정도로도 충분하다.@router.get("/games/{game_id}")def game_detail(game_id: int): game = get_game(game_id) if game is None: raise HTTPException(status_code=404,detail="Game not found",) return game여기서 get_game()은 DB를 조회하고, Route는 HTTP 요청을 처리한다.구조도 이해하기 쉽다.하지만 서비스가 커지면서 하나의 요청이 여러 작업을 수..

#17에서 Steam 가격 수집 파이프라인을 만들었다.Steam Store API에서 가격을 가져오고, 현재 가격과 가격 변경 이력을 PostgreSQL에 저장할 수 있게 되었지만 데이터가 DB에 쌓이는 것만으로는 사용자가 체감할 수 있는 기능이 되지는 않는다.이번 작업에서는 저장된 가격 데이터를 Game Dashboard에 연결했다.최종적으로 게임 상세 화면에서 다음 정보를 확인할 수 있게 되었다.현재 가격과 할인 여부무료 게임 여부가격을 조회할 수 없는 게임의 상태가격 변경 이력 차트이번 작업에서 특히 중요했던 부분은 단순히 숫자를 화면에 표시하는 것이 아니라 가격이라는 데이터를 어떤 상태로 해석해서 보여줄 것인가였다.1. 가격 데이터는 단순한 숫자가 아니다처음에는 현재 가격만 가져오면 다음처럼 표시..

지난 #17에서는 Steam 가격 데이터를 수집하고, 게임 목록을 코드에 하드코딩하지 않고 DB의 games 테이블을 기준으로 수집하는 구조로 확장했다.이번에는 새로운 데이터 종류를 추가하기보다 기존 패치 파이프라인을 실제로 운영하기 편한 형태로 다듬었다.기존 패치 시스템은 이미 다음 단계까지 구현되어 있었다.공식 패치 소스 수집→ 패치 감지→ game_patches 정규화→ LLM 기반 번역→ LLM 기반 요약→ Web Viewer각 단계는 동작하고 있었지만 중요한 문제가 하나 있었다.패치 수집과 번역·요약 처리가 서로 분리되어 있었다.새로운 패치가 들어오더라도 별도로 번역·요약 Processor를 실행해야 했다.이번 작업에서는 이 흐름을 하나로 연결하고, Web Viewer에서 특정 패치를 직접 다시..

이번 작업의 시작점은 단순했다.게임별 가격과 할인 정보를 수집해서 저장하고, 이후 대시보드와 가격 알림에서 사용할 수 있도록 만드는 것이 목표였다.하지만 실제로 가격 수집 기능을 추가하다 보니 한 가지 구조적인 문제가 드러났다.기존 프로젝트에서는 일부 수집기가 코드 안에 정의된 게임 목록을 기준으로 동작하고 있었다.GAMES = [ ...]초기에는 관리하는 게임 수가 적었기 때문에 큰 문제가 없었다.하지만 앞으로 Web에서 사용자가 원하는 게임을 직접 등록할 수 있게 만들려면 이야기가 달라진다.게임 하나를 추가할 때마다 다음을 수정해야 한다면 확장 가능한 구조라고 보기 어렵다.게임 등록→ 가격 수집 코드 수정→ 동접자 수집 코드 수정→ Airflow DAG 수정→ Steam News 수집 코드 수정..

패치노트 수집과 번역·요약 기능을 만들면서 프로젝트에는 점점 여러 종류의 데이터가 쌓이기 시작했다.지금까지 확보한 데이터는 크게 다음과 같았다.게임 기본 정보동접자 시계열공식 패치노트패치 번역패치 요약각 기능은 개별적으로 동작하고 있었지만, 데이터를 실제로 확인하려면 각각의 API나 DB를 따로 살펴봐야 했다.그래서 이번 단계에서는 새로운 수집 기능을 추가하기보다, 지금까지 쌓인 데이터를 게임 단위로 한 화면에서 확인할 수 있는 Web Dashboard를 만드는 데 집중했다.이번 작업의 목표는 공개 서비스 수준의 웹사이트를 만드는 것이 아니다.현재 프로젝트에서 필요한 것은 다음과 같은 운영용 Viewer에 가깝다.게임 선택 ↓게임 상세 ├─ 현재 동접자 ├─ 최근 동접자 추이 └─ ..

백엔드 코드를 처음 작성할 때는 요청을 받고, DB를 조회하고, 값을 수정하고, 결과를 반환하는 모든 과정을 하나의 함수 안에 작성하는 것이 가장 자연스럽다.예를 들어 내부 Admin에서 어떤 항목의 이름을 수정하는 기능을 만든다고 해보자.@app.post("/items/update")def update_item(): item_id = request.form["item_id"] item_name = request.form["item_name"] conn = get_connection() cursor = conn.cursor() cursor.execute( """ UPDATE items SET name = %s WHERE id =..

지난 #14에서는 game_patches에 모인 패치노트를 대상으로 LLM 기반 번역과 요약 파이프라인을 구축했다.데이터는 이미 다음 단계까지 준비되어 있었다. 패치 수집→ game_patches 정규화→ 번역→ 요약→ game_patch_processing 저장 하지만 결과를 확인하려면 여전히 DB를 직접 조회해야 했다.이번 단계의 첫 번째 목표는 이 데이터를 사람이 실제로 읽을 수 있는 패치노트 Web Viewer로 만드는 것이었다.개발 과정에서 PUBG의 Steam 패치 공지가 실제 본문이 아니라 공식 홈페이지 링크만 제공한다는 문제도 발견했다. 이를 해결하면서 게임별 패치 소스에 맞는 수집 구조를 추가했고, Patch Detector의 오탐 문제도 함께 수정했다.마지막에는 개발 환경을 실행할 때..