전체 글

배경 및 목표매월 정산은 외부 결제 모듈인 Stripe의 결제 데이터와 내부 데이터를 결합해 수행한다. 문제는 정산 과정에서 데이터 정합성 불일치가 반복적으로 발생한다는 점이었다. 합이 맞지 않는 금액을 한 건씩 추적하는 일이 매달 반복됐다. 원인을 파고든 결과는 다소 허무했는데, 애초에 잘못된 결제 데이터를 호출하고 있었다. 우리가 필요로 하는 잔액 변동(balance change) 단위의 데이터가 아닌, 성격이 다른 리포트를 가져와 대사에 쓰고 있었던 것이다. 근본 원인이 "호출 대상 자체의 오류"였기 때문에, 단순히 쿼리를 고치는 것으로는 부족했다. 다음 세 가지를 목표로 파이프라인을 재구축하기로 했다.올바른 API 호출 보장: 호출하는 리포트와 응답 스키마를 코드 레벨에서 못 박는다.멱등성(ide..

안녕하세요. 오랜만에 글을 씁니다. 이번 포스팅은 2025년 9월부터 약 5개월간 구축했던 MySQL, PostgreSQL -> Databricks CDC 파이프라인 구축 경험에 대해 다루려고 합니다.배경현 회사에서는 기존에 CDC 파이프라인으로 Airbyte를 운영하고 있었습니다. Airbyte는 배치 기반 ELT 플랫폼으로, 다양한 Source의 데이터를 Destination으로 수집하는 파이프라인을 No Code 수준으로 구축할 수 있는 오픈소스 툴입니다. 저희는 MySQL과 PostgreSQL을 Service DB로 사용 중이었고, MySQL/PostgreSQL Connector로 CDC 방식의 수집을, Databricks Connector로 Delta Table 적재를 수행하는 파이프라인을 운영..

개요현재 회사에서 BI 툴로 Redash를 주로 사용하고 있습니다. 기존에는 Redash 서버가 EC2 인스턴스 하나에 docker-compose를 통하여 배포되었고 이로 인해 몇 가지 불편한 점들이 발생하였습니다. 그래서 이번에 EKS 클러스터가 구축되면서 해당 Redash 서버를 EKS 기반으로 마이그레이션 하기로 결정하였고 이를 진행하는 과정과 어떤 문제가 있었는지에 대해서 설명하겠습니다.기존 Redash 문제점먼저, Redash의 구성에 대해 간략히 설명해 보겠습니다.위 그림은 Redash의 아키텍처로 Nginx를 Webserver로 사용하고 Backend로 Redash Server 가 존재하며 대시보드나 쿼리, 유저 정보 등을 저장하는 DB로 PostgreSQL을 사용합니다. 그리고 Redash..

개요기존 AWS에서 CeleryExecutor 를 활용하여 EC2 기반으로 Airflow 를 운영하였고 이번에 DevOps 팀에서 EKS를 구축하게 되면서 이를 기회 삼아 KubernetesExecutor 를 활용하여 EKS 기반으로 Airflow 를 구축하고 기존 Airflow 의 DAG 들의 이관을 계획하게 되었습니다. 이번 포스팅에서 기존 방식은 어떤 문제가 있었고 어떻게 EKS에 Airflow 를 구축하였고 EKS 기반으로 옮기게 되면서 얻게 된 장단점에 대해 써보겠습니다.기존 방식과 문제점기존에는 Airflow 가 제공하는 CeleryExecutor 를 통해 여러 EC2 인스턴스를 활용하여 Master-Worker 구조의 클러스터를 구축했었습니다. 먼저, CeleryExecutor 의 방식에 대..

개요작년 8월쯤 DBT라는 Tool의 존재를 알게 되어 한 번 도입해볼까 했는데 DBT를 혼자 PoC 해보고 도입하기에는 무리가 있고 시기상조라고 파악되어 문서로 정리만 해놓고 Drop을 했었습니다. 당근에서도 DBT와 Airflow를 도입했다는 포스팅이 올라와서 순간 생각이 나서 제가 파악했었던 것을 정리하기 위해 포스트합니다.DBT 도입 준비 배경당시 회사에서는 Airflow 를 기반으로 하는 ELT 데이터 파이프라인을 구축하고 BigQuery 라는 플랫폼 내에서 SQL을 통해 데이터를 처리하는 구조를 가지고 있었는데 Raw 데이터를 거의 대부분 그대로 BigQuery로 올린 후 거기서 쿼리로 조작하는 경우가 많았기 때문에 ad-hoc한 쿼리도 많이 생기고 BigQuery 자체에 쿼리를 저장하는 경우..

개요회사에서 Redash를 Visualization Tool로 사용하고 있는데 특정 대시보드에 대해서 회사 외부에 공개할 일이 생겨 공개를 결정한 대시보드를 제외한 대시보드는 외부에는 노출되지 않도록 하고 싶다는 needs가 있었다. 하지만 Redash는 Web UI에서 권한 관리나 설정 등을 수행하는데 해당 UI를 통해서는 권한 관리에 취약점이 많았고 한계가 많아서 아예 Redash 서버 자체를 분리하여 둘의 서버를 sync 하는 방식으로 진행하자는 의견이 나왔었다. 그래서 나는 해당 Job을 받았고 그대로 수행하려고 했으나 Redash에 대해서 조사한 결과 서버를 분리하지 않아도 가능할 것 같다는 생각이 들었고 그 방안에 대해서 고민한 과정과 결과를 포스팅하려고 한다.해당 포스팅은 Redash에 대해..