✅ Apache Airflow
-> airflow의 아키텍처를 간단히 표현한 그림
컴포넌트별로 살펴보면 다음과 같다.
- User Interface : 사용자의 웹 환경 또는 터미널의 CLI가 될 수 있다
- Webserver : 사용자 요청을 처리하는 웹서버
- Scheduler : dag 디렉토리에 존재하는 python 파일을 파싱해 dag 추출하여 dag 실행을 위한 일련의 절차 진행
- executor : worker에게 task를 전달하는 전달자 역할 (어떤 종류의 executor를 사용하느냐에 따라 task 전달 방법 결정)
- workers : 실제 task 수행하는 주체, 동시에 많은 task 실행가능하도록 다수로 존재
- metadata database : scheduler가 파싱한 dag, task 인스턴스 정보, worker가 실행하면서 발생한 이력들이 airflow_db라는 이름으로 존재.
-> Airflow는 1, 5를 제외하면 각 컴포넌트는 기본적으로 단일 구성. worker의 경우 동시성를 위해 분산 구조로 만들어져 있으며 그 외에는 HA 구성이 되어있지 않다. 따라서 하나의 컴포넌트라도 장애가 존재하는 경우 Airflow는 정상 작동 X
🎈 < 데이터 엔지니어로서 반드시 숙지해야 할 task 인스턴스 >
✅ 멀티 클라우드 도입
기존 AWS에 지속적인 에러가 발생해 GCP 도입 결정
지난 프로젝트에 이어 이번에도 GCP 설계를 맡아 진행하고자 한다.
지난번엔 GCS, BigQuery를 활용하여 Airflow dag를 작성하여 workflow를 진행했다면 이번 프로젝트에는 Cloud Composer를 적용하려 한다.
🎈 Cloud Composer란?
클라우드 및 온프레미스 데이터 센터 전체의 워크플로 파이프라인을 생성, 예약, 모니터링 등을 관리할 수 있는 완전 관리형 워크플로 조정 서비스이다.
즉, 다음 3가지 키워드로 정리할 수 있다.
1. 작업의 흐름도
2. 작업 절차
3. 업무의 이동성cc는 airflow기반 파이썬으로 작동하며 airflow를 local에서 해결하는 것이 아닌 cloud를 활용하기에 서버, 자원관리, 오버헤드 등을 고려할 필요 없이 Dag 작성에만 집중하면 된다.
CC는 실제 업무 환경에 따라 공개IP, 비공개IP, 도메인 제한 공유(DRS) 3가지 구성으로 제작할 수 있다. 각 구성은 프로젝트 리소스의 아키텍처에 따라 약간 다르다.
공개IP : Airflow scheduler, webserver, worker는 cloud sql proxy 프로세스 사용해 Airflow_db에 연결
비공개IP : 공개IP와 동일하지만, HAProxy를 사용하여 확장성 고려.
-> 주의할 점. dag 내 retries argument값을 반드시 지정하여 tenent project에서 관리되는 리소스에 대해 관리 必
💡 CC 환경 구축
