https://jingi723.github.io/백엔드/데이터 파이프라인 개발 기록과 학습 노트. 2026-10-12T00:20:53+09:00 jingi723 https://jingi723.github.io/ Jekyll © 2026 jingi723 /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 2026-10-11T21:09:42+09:00 2026-10-12T00:20:33+09:00 https://jingi723.github.io/posts/edge-llm-db-connections/ jingi723

EDGE의 ETF 분석은 원천 자료를 읽고 LLM을 호출한 뒤, 분석 결과와 그 근거를 PostgreSQL에 저장한다. 전망 결과를 오전 8시까지 준비하려고 병렬 실행을 검토하던 중, 분석 한 건이 LLM 응답을 기다리는 동안에도 쓰기용 DB 연결 세 개를 유지한다는 제약이 드러났다. SQL을 실행하지 않는 동안 연결을 반환하면 더 많은 분석을 실행할 여지가 생긴다. 하지만 당시 연결은 데이터 저장뿐 아니라 같은 분석이 겹치지 않도록 잡아 둔 세션 락도 유지했다. 연결을 닫으려면 그 락이 맡던 역할을 다른 곳으로 옮겨야 했다. 내가 제기한 문제는 LLM 대기와 DB 연결의 수명을 분리할 수 있느냐는 것이었다. 처음에는 만료 시간이 있는 DB lease를 제안했지만, 대안을 검토한 뒤 기존 Step ...

2026-10-11T21:09:42+09:00 2026-10-12T00:20:33+09:00 https://jingi723.github.io/posts/coupon-kafka-recovery/ jingi723

선착순 쿠폰 발급 프로젝트에서 요청이 순간적으로 몰리자 DB 연결을 기다리는 요청이 쌓였다. 발급 수량의 정합성을 지키더라도, 사용자가 응답을 기다리는 시간까지 짧아지는 것은 아니었다. 폭주가 끝난 뒤 들어온 요청도 앞선 작업이 빠져나가기를 기다렸다. Kafka를 붙인 첫 경로에서는 신청 접수와 실제 발급을 나눴다. API는 신청을 Kafka에 기록한 뒤 접수를 알리고, Consumer가 DB에서 발급 여부를 판단했다. 접수 이후 중단된 신청이 복구되는지, 최종 발급까지 얼마나 기다리는지를 각각 확인해야 했다. 당시에는 Redis 예약 없이 Kafka로 신청을 직접 접수했다. 이후 추가한 Redis 예약 구조는 이 글의 복구·성능 측정에 포함하지 않았다. 접수 성공과 쿠폰 발급 성공을 다른 응답으...

2026-10-11T21:09:42+09:00 2026-10-12T00:20:33+09:00 https://jingi723.github.io/posts/airflow-ecs-reexecution/ jingi723

EDGE에서는 수집·정제·적재로 끝나는 배치의 오케스트레이션을 작업군별로 Airflow로 옮기기 시작했다. 첫 전환 대상은 AWS 개발 환경의 장중 수급 배치였다. 업무 코드는 기존 ECS 컨테이너를 사용하고, 그 작업의 실행 순서와 결과를 관리하는 주체를 바꿨다. 전환 과정에서 중요한 문제는 Airflow가 실패를 표시한 뒤 ECS 작업이 어떻게 되는지였다. Airflow 워커가 중단되거나 응답을 잃더라도, 이미 제출한 ECS 컨테이너는 계속 실행될 수 있다. Airflow의 재시도를 곧바로 새 ECS 작업의 실행으로 연결하면 같은 일을 겹쳐 수행할 수 있었다. 나는 실행 중인 작업에는 재접속하고, 상태를 확인하지 못한 작업은 자동으로 다시 시작하지 않는 정책을 택했다. 이관 구현과 실험에는 AI...

2026-09-12T09:00:00+09:00 2026-09-12T09:00:00+09:00 https://jingi723.github.io/posts/airflow-aws-deployment/ jingi723

Apache Airflow는 여러 작업을 정해진 순서와 조건에 따라 실행하고, 실행 상태를 기록하는 도구다. 데이터를 수집한 뒤 정제하고, 정제가 끝나면 집계하는 흐름을 DAG로 정의한다. 실행 중 실패한 작업을 확인하거나 과거 데이터를 다시 처리하는 것도 이 흐름 안에서 관리한다. AWS에서는 EC2에 직접 설치하거나, ECS·EKS에서 컨테이너로 운영하거나, 관리형 서비스인 MWAA를 사용할 수 있다. 선택에 따라 서버 관리, 장애 대응, 비용 구조가 달라진다. 비교할 때 먼저 구분할 것은 Airflow 자체를 운영하는 일과 실제 데이터를 처리하는 일이다. 두 부분을 같은 서버에서 실행할 수도, 서로 다른 서비스에 맡길 수도 있다. 이 구분부터 이해하면 여러 배포 방식이 어떤 문제를 해결하는지 ...

2026-09-03T12:00:00+09:00 2026-09-03T12:00:00+09:00 https://jingi723.github.io/posts/airflow-dag-concepts/ jingi723

Airflow는 여러 작업으로 이뤄진 워크플로를 코드로 정의하고 실행을 관리하는 플랫폼이다. 데이터 수집·가공·저장처럼 여러 단계가 이어지는 파이프라인에서 각 작업을 언제, 어떤 조건으로 실행할지 조정한다. 정해진 시각에 시작하는 것만으로는 이런 흐름을 운영하기 어렵다. 앞 단계가 끝나야 다음 단계를 진행할 수 있고, 실패하면 다시 실행할 대상을 찾아야 한다. 매일 반복하는 작업이라면 어느 날짜의 처리가 끝났는지도 구분해야 한다. Airflow는 작업 사이의 관계를 정의한 DAG와 그 정의에서 만들어진 개별 실행을 나눠 관리한다. 여기에 각 실행이 처리할 데이터 구간을 연결하면, 작업의 순서와 실패 상태뿐 아니라 무엇을 다시 처리해야 하는지도 설명할 수 있다. DAG는 작업이 실행되기 위한 조건을...