Data Lab

Airflow vs cron - 언제 Airflow까지 써야 할까?

데이터 수집 프로그램을 만들다 보면 자연스럽게 이런 문제가 생긴다. "이 Python 파일을 매시간 자동으로 실행하고 싶은데, cron이면 충분한 걸까? 아니면 Airflow까지 써야 할까?" 처음에는 두 도구가 비슷해 보인다.둘 다 결국 정해진 시간에 프로그램을 실행할 수 있기 때문이다.하지만 프로젝트가 커지기 시작하면 두 도구의 역할은 꽤 달라진다.이번 Game Data Project에서도 처음에는 Python Collector 하나만 실행하면 됐지만, 게임별 실패와 Retry를 다루기 시작하면서 Airflow를 사용하는 이유가 조금씩 명확해졌다. 1. cron은 무엇인가?cron은 Linux에서 정해진 시간에 명령어를 실행할 수 있도록 해주는 스케줄러다.예를 들어 매시간 Python Collect..

Game Data Project #10 - Airflow로 데이터 수집 파이프라인 자동화하기

1. 이번 단계의 목표지금까지 Game Data Project에서는 Steam API에서 게임의 현재 동접자 수를 가져와 PostgreSQL에 저장하고, FastAPI를 통해 저장된 데이터를 조회할 수 있도록 만들었다.하지만 데이터 수집 자체는 여전히 사람이 직접 실행해야 했다.기존 구조는 대략 다음과 같았다.사람 ↓Python Collector 실행 ↓Steam API ↓PostgreSQL이번 단계의 목표는 이 수집 작업을 사람이 직접 실행하는 대신 Airflow가 정해진 시간마다 자동으로 실행하도록 만드는 것이었다.최종적으로 만들고 싶은 구조는 다음과 같다.Airflow Scheduler ↓Player Count DAG ↓게임별 Task ↓Steam API ..

Day 9에서는 FastAPI에 Redis를 붙이고, 최신 플레이어 수 조회 API에 캐시를 적용했다.이번 목표는 단순히 Redis를 실행하는 것이 아니라 다음 흐름을 직접 구현해보는 것이었다.Client ↓FastAPI ↓Redis ├─ HIT → 바로 응답 └─ MISS ↓ PostgreSQL ↓ Redis 저장 ↓ 응답Redis가 왜 필요한지, Cache Hit/Miss가 무엇인지, TTL은 왜 필요한지, 그리고 Redis 장애가 발생했을 때 API는 어떻게 동작해야 하는지까지 확인했다.Redis를 Docker Compose에 추가기존 Docker Compose 환경에는 FastAPI와 PostgreSQL이 있었고, 여기에 Redis 서비스를 추가했다.servi..

Day 8에서는 지금까지 만든 FastAPI 애플리케이션을 Docker로 실행하고, PostgreSQL까지 Docker Compose로 묶어 하나의 개발 환경으로 구성했다.지금까지 프로젝트는 WSL 환경에서 직접 실행하고 있었다.WSL├── Python├── uv├── FastAPI├── SQLAlchemy├── Alembic├── pytest└── PostgreSQL내 컴퓨터에서는 잘 실행되지만 다른 PC나 서버에서 같은 프로젝트를 실행하려면 Python 버전부터 각종 패키지와 DB 환경까지 다시 맞춰야 한다.Docker를 사용하면 애플리케이션의 실행 환경을 코드로 정의하고, 비교적 동일한 환경을 반복해서 만들어낼 수 있다.이번 Day 8에서는 단순히 Docker 명령어를 사용하는 데 그치지 않고 다음..

Day 7에서는 지금까지 만든 FastAPI API를 사람이 직접 호출해서 확인하는 방식에서 벗어나, pytest를 이용해 자동으로 검증하는 테스트 코드를 작성했다.이번 단계의 목표는 단순히 테스트 몇 개를 만드는 것이 아니라 다음 개념을 직접 사용해보는 것이었다.pytest 기본 사용법assert를 이용한 결과 검증FastAPI TestClientpytest fixturemonkeypatch와 fake datavalidation 테스트Unit Test와 Integration Test의 차이pytest marker를 이용한 테스트 분리1. pytest 설치pytest는 개발 환경에서만 필요한 패키지이기 때문에 dev dependency로 추가했다.uv add --dev pytest가장 먼저 pytest ..

오늘 한 일지난 작업에서는 FastAPI를 사용해 PostgreSQL에 저장된 게임 데이터를 REST API로 조회할 수 있도록 만들었다.당시 DB 접근은 psycopg를 사용해 SQL을 직접 작성하는 방식이었다.FastAPI ↓storage.py ↓직접 작성한 SQL ↓psycopg ↓PostgreSQL이번에는 여기에 SQLAlchemy ORM을 적용해 DB 테이블을 Python 모델로 표현하고, 기존 조회 로직을 ORM 방식으로 변경했다.또한 Alembic을 추가해 DB 스키마 변경 이력을 코드로 관리할 수 있도록 구성했다.최종적으로 구조는 다음과 같이 바뀌었다.FastAPI ↓SQLAlchemy ORM ↓Session ↓Engine ↓psycopg ↓PostgreSQ..

오늘 한 일지난 글에서는 REST API를 어떻게 설계할지 정리했다.이번에는 그때 문서로 설계했던 API를 실제 FastAPI 코드로 구현했다.기존 프로젝트는 Steam API에서 데이터를 가져와 PostgreSQL에 저장하는 흐름까지 만들어둔 상태였다.Steam API ↓Python 수집 코드 ↓PostgreSQL이번 작업을 통해 반대 방향의 흐름도 추가했다.PostgreSQL ↓FastAPI ↓Client즉, 지금까지는 데이터를 수집해서 저장하는 것에 집중했다면 이번에는 저장된 데이터를 외부에서 조회할 수 있도록 API로 제공하는 단계까지 확장했다.FastAPI와 Uvicorn 설치먼저 FastAPI와 Uvicorn을 프로젝트 의존성으로 추가했다.uv add fastapi "uv..

오늘 한 일오늘은 실제 API를 구현하기 전에, 먼저 REST API를 어떤 구조로 설계할지 정리했다.Day 1~3까지는 Steam API에서 데이터를 가져와 PostgreSQL에 저장하는 흐름을 만드는 데 집중했다면, 오늘부터는 저장된 데이터를 다른 프로그램이나 사용자가 조회할 수 있도록 API를 설계하는 단계로 넘어갔다.지금까지의 흐름은 대략 다음과 같다.Steam API ↓Python 수집 코드 ↓예외처리 / logging ↓PostgreSQL이제 여기에 API 계층을 추가하면 다음과 같은 구조가 된다.Client ↓REST API ↓PostgreSQL오늘은 FastAPI를 바로 작성하지 않고, 그 전에 어떤 endpoint가 필요한지 먼저 정의했다.REST API 기본 개념 정리..

Day 2까지는 Steam API에서 가져온 동접자 데이터를 JSONL 파일에 저장했다.JSONL은 간단한 수집 결과를 확인하거나 로그 형태로 데이터를 쌓기에는 편했지만, 앞으로 게임별 시계열 조회, 패치 전후 비교, 가격 데이터와의 JOIN 같은 분석을 하려면 관계형 데이터베이스가 필요했다.그래서 이번에는 PostgreSQL을 설치하고, 기존 수집 데이터를 PostgreSQL에 저장하도록 구조를 변경했다.1. PostgreSQL 설치와 기본 구조 이해WSL Ubuntu 환경에 PostgreSQL을 설치하고 먼저 서버 상태를 확인했다.PostgreSQL을 처음 사용할 때 가장 헷갈렸던 부분은 psql과 PostgreSQL 서버의 차이였다.PostgreSQL Server→ 실제 데이터베이스가 실행되는 서버..

오늘 한 것Day 1에서는 Steam API를 호출해 여러 게임의 현재 동접자 수를 출력하는 것까지 진행했다.Day 2에서는 단순한 API 호출 코드를 조금 더 실제 데이터 수집 프로그램에 가까운 형태로 개선했다.오늘 진행한 내용은 다음과 같다.HTTP 요청/응답 구조 정리HTTP Status Code와 raise_for_status() 이해try / except를 이용한 예외처리Python logging 적용로그 파일 저장Linux에서 tail, grep을 이용한 로그 확인JSONL 형식으로 실제 수집 데이터 저장jq 설치 및 JSON 데이터 확인VSCode와 WSL 연동Git rebase와 conflict 경험conflict marker가 남은 코드 수정불필요하게 생성된 빈 .py 파일 삭제작업 브랜..