Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
이 페이지에서는 Cloud Composer 2 환경의 아키텍처를 설명합니다.
환경 아키텍처 구성
Cloud Composer 2 환경에서 가능한 아키텍처 구성은 다음과 같습니다.
각 구성은 환경 리소스의 아키텍처를 약간 변경합니다.
고객 및 테넌트 프로젝트
환경을 만들 때 Cloud Composer는 테넌트와 고객 프로젝트 사이에 환경 리소스를 배포합니다.
고객 프로젝트는 환경을 만드는 Google Cloud 프로젝트입니다. 단일 고객 프로젝트에서 2개 이상의 환경을 만들 수 있습니다.
테넌트 프로젝트는 Google에서 관리되는 테넌트 프로젝트입니다. 테넌트 프로젝트는 해당 환경에 대해 통합된 액세스 제어 및 추가적인 데이터 보안 레이어를 제공합니다. 각 Cloud Composer 환경에는 고유 테넌트 프로젝트가 포함됩니다.
환경 구성요소
Cloud Composer 환경은 환경 구성요소로 구성됩니다.
환경 구성요소는 환경의 일부로 Google Cloud에서 실행되는 관리형 Airflow 인프라의 요소입니다.
환경 구성요소는 해당 환경의 테넌트 고객 프로젝트에서 실행됩니다.
해당 환경의 일부 구성요소는 독립형 Google Cloud 제품을 기반으로 합니다. 이러한 제품의 할당량 및 한도가 해당 환경에 적용됩니다. 예를 들어 Cloud Composer 환경에는 VPC 피어링이 사용됩니다. 최대 VPC 피어링 수에 대한 할당량이 고객 프로젝트에 적용되므로, 프로젝트가 최대 피어링 수에 도달한 다음에는 환경을 추가로 만들 수 없습니다.
환경 클러스터
환경 클러스터는 해당 환경에 대한 Autopilot 모드의 VPC 기반 Google Kubernetes Engine 클러스터입니다.
환경 노드는 환경 클러스터의 VM입니다.
환경 클러스터의 포드는 Airflow 작업자 및 스케줄러와 같은 다른 환경 구성요소와 함께 컨테이너를 실행합니다. 포드는 환경 노드에서 실행됩니다.
해당 환경의 클러스터에 대한 워크로드 리소스가 환경 클러스터에 있는 포드 집합을 관리합니다. 환경의 많은 구성요소는 여러 유형의 워크로드 리소스로 구현됩니다. 예를 들어 Airflow 작업자는 배포로 실행됩니다. 배포 외에도 환경에는 StatefulSets, DaemonSets, Jobs 워크로드 유형이 포함됩니다.
기본적으로 Cloud Composer는 보안 취약점으로로부터 환경 클러스터를 보호하기 위해 노드 자동 업그레이드 및 노드 자동 복구를 사용 설정합니다. 이러한 작업은 환경에 대해 지정한 유지보수 기간에 수행됩니다.
Airflow 스케줄러, 트리거, 작업자, Redis 큐
Airflow 스케줄러는 DAG 실행 및 DAG의 개별 태스크 일정을 제어합니다. 스케줄러는 환경 클러스터에서 애플리케이션으로 실행되는 Redis 큐를 사용하여 Airflow 작업자에게 태스크를 배포합니다. Airflow 스케줄러는 환경 클러스터에서 배포로 실행됩니다.
Airflow 작업자는 DAG의 개별 태스크를 Redis 큐에서 가져와서 실행합니다. Airflow 작업자는 환경 클러스터에서 커스텀 리소스로 실행됩니다.
Airflow 트리거는 환경에서 모든 지연된 태스크를 비동기식으로 모니터링합니다. Cloud Composer 환경을 만들거나 업데이트할 때 트리거 인스턴스 수를 구성할 수 있습니다. Cloud Composer는 다음 트리거 구성을 지원합니다.
트리거 수:
- 표준 복원력: 최대 10개의 트리거를 실행할 수 있음
- 높은 복원력: 트리거 최소 2개, 최대 10개
트리거 수를 0으로 설정할 수 있지만 환경에는 트리거 인스턴스가 1개 이상(또는 복원력이 우수한 환경에서는 2개 이상)이 있어야 DAG에서 지연 가능한 연산자를 사용할 수 있습니다. 트리거 수를 0으로 설정한 경우 환경 클러스터는 워크로드를 계속 실행하지만 포드가 0개이므로 비용이 발생하지 않습니다.
트리거 리소스 할당:
- 트리거당 최대
1 vCPU - 트리거 CPU 개수에
6.5를 곱한 값과 같은 최대 메모리
- 트리거당 최대
Redis 큐에는 DAG의 개별 태스크에 대한 큐가 포함됩니다. Airflow 스케줄러가 이 큐를 채우고, Airflow 작업자가 여기에서 해당 태스크를 가져옵니다. Redis 큐는 해당 환경의 클러스터에서 StatefulSet 애플리케이션으로 실행되므로,컨테이너가 다시 시작되어도 메시지가 보존됩니다.
Airflow 웹 서버
Airflow 웹 서버는 환경의 Airflow UI를 실행합니다.
Cloud Composer 2에서 Airflow 웹 서버는 사용자 환경의 클러스터에서 배포로 실행됩니다.
Cloud Composer 2는 사용자에 대해 정의된 사용자 ID 및 IAM 정책 바인딩을 기반으로 인터페이스에 대해 액세스 권한을 제공합니다. Cloud Composer 1과 비교해서 Cloud Composer 2는 IAP(Identity-Aware Proxy)에 의존하지 않는 다른 메커니즘을 사용합니다.
Airflow 데이터베이스
Airflow 데이터베이스는 해당 환경의 테넌트 프로젝트에서 실행되는 Cloud SQL 인스턴스입니다. 이 데이터베이스는 Airflow 메타데이터 데이터베이스를 호스팅합니다.
Cloud Composer는 환경의 서비스 계정에만 데이터베이스 액세스를 허용하여 민감한 연결 및 워크플로 정보를 보호합니다.
환경 버킷
환경 버킷은 DAG, 플러그인, 데이터 종속 항목 및 Airflow 로그를 저장하는 Cloud Storage 버킷입니다. 환경 버킷은 고객 프로젝트에 있습니다.
환경 버킷의 /dags 폴더에 DAG 파일을 업로드하면 Cloud Composer가 해당 환경의 작업자, 스케줄러, 웹 서버에 DAG를 동기화합니다. 크기 제한에 대한 염려 없이 data/ 폴더와 logs/ 폴더에 워크플로 아티팩트를 저장하고 데이터 액세스를 완벽하게 제어할 수 있습니다.
기타 환경 구성요소
Cloud Composer 환경에는 여러 개의 추가적인 환경 구성요소가 포함되어 있습니다.
Cloud SQL 스토리지. Airflow 데이터베이스 백업을 저장합니다. Cloud Composer는 데이터 손실 가능성을 최소화하기 위해 Airflow 메타데이터를 매일 백업합니다.
Cloud SQL 스토리지는 환경의 테넌트 프로젝트에서 실행됩니다. Cloud SQL 스토리지의 내용에는 액세스할 수 없습니다.
Cloud SQL 프록시. 해당 환경의 다른 구성요소를 Airflow 데이터베이스에 연결합니다.
Airflow 데이터베이스로 향하는 트래픽 볼륨에 따라 공개 IP 환경에 하나 이상의 Cloud SQL 프록시 인스턴스가 있을 수 있습니다.
공개 IP 환경에서는 Cloud SQL 프록시가 사용자 환경의 클러스터에서 배포로 실행됩니다.
또한 환경 클러스터에 배포될 때 Cloud SQL 프록시는 애플리케이션, 클라이언트 또는 기타 Google Cloud 서비스에서 Cloud SQL 인스턴스에 대한 액세스를 승인합니다.
Airflow 모니터링. Cloud Monitoring에 대해 환경 측정항목을 보고하고 airflow_monitoring DAG를 트리거합니다. airflow_monitoring DAG는 해당 환경의 모니터링 대시보드와 같이, 나중에 사용되는 환경 상태 데이터를 보고합니다. Airflow 모니터링은 해당 환경의 클러스터에서 배포로 실행됩니다.
Composer 에이전트는 환경 만들기, 업데이트, 업그레이드, 삭제와 같은 환경 작업을 수행합니다. 일반적으로 이 구성요소는 환경을 변경하는 데 사용됩니다. 환경의 클러스터에서 작업으로 실행됩니다.
Airflow InitDB는 Cloud SQL 인스턴스 및 초기 데이터베이스 스키마를 만듭니다. Airflow InitDB는 해당 환경의 클러스터에서 작업으로 실행됩니다.
FluentD. 모든 환경 구성요소에서 로그를 수집하고 해당 로그를 Cloud Logging에 업로드합니다. 환경의 클러스터에서 DaemonSet로 실행됩니다.
Pub/Sub 구독. 사용자 환경은 Pub/Sub 구독을 통해 GKE 서비스 에이전트와 통신합니다. 사용자 환경은 Pub/Sub의 기본 동작을 사용하여 메시지를 관리합니다. .*-composer-.* Pub/Sub 주제를 삭제하지 마세요. Pub/Sub는 프로젝트당 주제를 최대 10,000개까지 지원합니다.
PSC 엔드포인트는 Airflow 스케줄러와 작업자를 PSC를 사용하는 비공개 IP 아키텍처의 Airflow 데이터베이스에 연결합니다.
고객 측정항목 Stackdriver 어댑터는 자동 확장을 위해 환경 측정항목을 보고합니다. 이 구성요소는 환경 클러스터에서 배포로 실행됩니다.
Airflow 작업자 세트 컨트롤러는 고객 측정항목 Stackdriver 어댑터의 측정항목을 기반으로 환경을 자동으로 확장합니다. 이 구성요소는 환경 클러스터에서 배포로 실행됩니다.
Cloud Storage FUSE. Airflow 작업자, 스케줄러, 웹 서버가 버킷의 데이터에 액세스할 수 있도록 이러한 구성요소에 환경 버킷을 파일 시스템으로 마운트합니다. 환경의 클러스터에서 DaemonSet로 실행됩니다.
공개 IP 환경 아키텍처
Cloud Composer 2의 공개 IP 환경 아키텍처:
- 테넌트 프로젝트는 Cloud SQL 인스턴스 및 Cloud SQL 스토리지를 호스팅합니다.
- 고객 프로젝트는 해당 환경의 다른 모든 구성요소를 호스팅합니다.
- 고객 프로젝트의 Airflow 스케줄러 및 작업자는 고객 프로젝트에 있는 Cloud SQL 프록시 인스턴스를 통해 Airflow 데이터베이스와 통신합니다.
비공개 IP 환경 아키텍처
기본적으로 Cloud Composer 2는 Private Service Connect를 사용하므로 비공개 IP 환경은 VPC 피어링을 사용하지 않고도 내부적으로 통신합니다. 해당 환경에서 Private Service Connect 대신 VPC 피어링을 사용할 수도 있습니다. 이는 기본값이 아닌 옵션입니다.
비공개 IP 환경 아키텍처에서는 다음과 같습니다.
- 테넌트 프로젝트는 Cloud SQL 인스턴스 및 Cloud SQL 스토리지를 호스팅합니다.
- 고객 프로젝트는 해당 환경의 다른 모든 구성요소를 호스팅합니다.
- Airflow 스케줄러와 작업자는 구성된 PSC 엔드포인트를 통해 Airflow 데이터베이스에 연결합니다.
복원력이 우수한 비공개 IP 아키텍처
복원력이 우수한 Cloud Composer 환경은 기본 제공되는 중복성 및 장애 조치 메커니즘을 사용하여 영역 장애와 단일 장애점 서비스 중단에 대한 환경 민감성을 줄이는 Cloud Composer 2 환경입니다.
이 유형의 비공개 IP 환경에서는 다음을 수행합니다.
- 환경의 Cloud SQL 인스턴스는 고가용성으로 구성됩니다(리전 인스턴스). 리전 인스턴스 내에서의 구성은 기본 인스턴스와 대기 인스턴스로 이루어집니다.
- 환경은 2개의 Airflow 스케줄러, 2개의 웹 서버, 트리거를 사용하는 경우 최소 2개(최대 10개)의 트리거를 실행합니다. 이러한 구성요소 쌍은 두 개의 개별 영역에서 실행됩니다.
- 최소 작업자 수는 2로 설정되며 환경 클러스터에서 영역 간에 작업자 인스턴스를 분산합니다. 영역 서비스 중단이 발생하면 영향을 받는 작업자 인스턴스가 다른 영역에서 다시 예약됩니다.
Cloud Logging 및 Cloud Monitoring과의 통합
Cloud Composer는 Cloud Logging 및 Google Cloud 프로젝트의 Cloud Monitoring과 통합되어 있으므로 Airflow 서비스 및 워크플로 로그를 중앙에서 볼 수 있습니다.
Cloud Monitoring은 Cloud Composer에서 측정항목, 이벤트, 메타데이터를 수집하여 대시보드와 차트를 통해 통계를 생성합니다.
Cloud Logging의 스트리밍 특성으로 인해 환경의 Cloud Storage 버킷에 Airflow 로그가 나타날 때까지 기다리는 대신 Airflow 스케줄러와 작업자가 내보낸 로그를 즉시 볼 수 있습니다. Cloud Composer의 Cloud Logging 로그는 google-fluentd를 기반으로 하므로 Airflow 스케줄러와 작업자가 생성하는 모든 로그에 액세스할 수 있습니다.
Google Cloud 프로젝트의 로그 수를 제한하려면 모든 로그 수집을 중지하면 됩니다. Logging을 중지하지 마세요.