전체 글

개요현재 회사에서 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에 대해..

BigQuery는 쿼리를 통해 스키마를 수정할 수 있다. 다만 제한적으로 수정할 수 있는데 Field 추가와 삭제는 가능하지만 특정 Nested Field의 내부에서 Field 추가는 불가능하다. 다행히 공식적으로 bq CLI 명령을 통해 수행이 가능하게 되어 있다. 이번 포스팅에서는 bq 명령을 통해 BigQuery 스키마를 수정하는 방법에 대해 설명하도록 하겠다. 0. bq? bq 는 BigQuery용 Python 기반의 CLI 이다. 여기서는 bq를 어떻게 사용하고 설치하는 지에 대해서는 설명하지 않겠다. 아래 공식 문서를 참조하길 바란다. gcloud CLI 설치 | Google Cloud CLI 문서 의견 보내기 gcloud CLI 설치 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 ..

개요 Airflow 의 성능을 높이기 위해서 설정 해야 하는 여러 가지 옵션들이 있다. airflow.cfg 파일에서 사용할 수 있는 해당 옵션들에 대해서 알아보고 정리하는 시간을 가져보려고 한다. Airflow 환경 Level [core] parallelism Airflow 환경 내에서 동시에 실행할 수 있는 최대 Task의 수 이다. 예를 들어 32로 설정되어 있다면 Airflow 환경 내에서 동시에 실행될 수 있는 Task의 수는 최대 32개라는 뜻이다. (default : 32) max_active_tasks_per_dag DAG당 한 번에 스케줄링되는 최대 Task의 수를 결정한다. 즉, 하나의 DAG에서 동시에 실행될 수 있는 Task의 수를 말한다. (default :16) Airflow에 ..