Cloud Composer 1 | Cloud Composer 2
이 페이지에서는 Cloud Composer 1 환경의 아키텍처를 설명합니다.
환경 아키텍처 구성
Cloud Composer 1 환경에서 가능한 아키텍처 구성은 다음과 같습니다.
각 구성은 환경 리소스의 아키텍처를 약간 변경합니다.
고객 및 테넌트 프로젝트
환경을 만들 때 Cloud Composer는 테넌트와 고객 프로젝트 사이에 환경 리소스를 배포합니다.
고객 프로젝트는 환경을 만드는 Google Cloud 프로젝트입니다. 단일 고객 프로젝트에서 2개 이상의 환경을 만들 수 있습니다.
테넌트 프로젝트는 Google에서 관리되는 테넌트 프로젝트입니다. 테넌트 프로젝트는 해당 환경에 대해 통합된 액세스 제어 및 추가적인 데이터 보안 레이어를 제공합니다. 각 Cloud Composer 환경에는 고유 테넌트 프로젝트가 포함됩니다.
환경 구성요소
Cloud Composer 환경은 환경 구성요소로 구성됩니다.
환경 구성요소는 환경의 일부로 Google Cloud에서 실행되는 관리형 Airflow 인프라의 요소입니다.
환경 구성요소는 해당 환경의 테넌트 고객 프로젝트에서 실행됩니다.
해당 환경의 일부 구성요소는 독립형 Google Cloud 제품을 기반으로 합니다. 이러한 제품의 할당량 및 한도가 해당 환경에 적용됩니다. 예를 들어 Cloud Composer 환경에는 VPC 피어링이 사용됩니다. 최대 VPC 피어링 수에 대한 할당량이 고객 프로젝트에 적용되므로, 프로젝트가 최대 피어링 수에 도달한 다음에는 환경을 추가로 만들 수 없습니다.
환경 클러스터
환경 클러스터가 사용자 환경의 표준 모드 VPC 기반이거나 경로 기반 Google Kubernetes Engine 클러스터인 경우:
환경 노드는 환경 클러스터의 VM입니다.
환경 클러스터의 포드는 Airflow 작업자 및 스케줄러와 같은 다른 환경 구성요소와 함께 컨테이너를 실행합니다. 포드는 환경 노드에서 실행됩니다.
해당 환경의 클러스터에 대한 워크로드 리소스가 환경 클러스터에 있는 포드 집합을 관리합니다. 환경의 많은 구성요소는 여러 유형의 워크로드 리소스로 구현됩니다. 예를 들어 Airflow 작업자는 배포로 실행됩니다. 배포 외에도 환경에는 StatefulSets, DaemonSets, Jobs 워크로드 유형이 포함됩니다.
기본적으로 Cloud Composer는 보안 취약점으로로부터 환경 클러스터를 보호하기 위해 노드 자동 업그레이드 및 노드 자동 복구를 사용 설정합니다. 이러한 작업은 환경에 대해 지정한 유지보수 기간에 수행됩니다.
Airflow 스케줄러, 작업자 및 Redis 큐
Airflow 스케줄러는 DAG 실행 및 DAG의 개별 태스크 일정을 제어합니다. 스케줄러는 환경 클러스터에서 애플리케이션으로 실행되는 Redis 큐를 사용하여 Airflow 작업자에게 태스크를 배포합니다. Airflow 스케줄러는 환경 클러스터에서 배포로 실행됩니다.
Airflow 작업자는 DAG의 개별 태스크를 Redis 큐에서 가져와서 실행합니다. Airflow 작업자는 환경 클러스터에서 배포로 실행됩니다.
Redis 큐에는 DAG의 개별 태스크에 대한 큐가 포함됩니다. Airflow 스케줄러가 이 큐를 채우고, Airflow 작업자가 여기에서 해당 태스크를 가져옵니다. Redis 큐는 해당 환경의 클러스터에서 StatefulSet 애플리케이션으로 실행되므로,컨테이너가 다시 시작되어도 메시지가 보존됩니다.
Airflow 웹 서버
Airflow 웹 서버는 환경의 Airflow UI를 실행합니다.
Cloud Composer 1에서 Airflow 웹 서버는 해당 환경의 테넌트 프로젝트에서 실행되는 App Engine Flex 인스턴스입니다.
Airflow 웹 서버는 IAP(Identity-Aware Proxy)와 통합되어 있습니다. Cloud Composer는 IAP 통합 세부정보를 숨기고, 사용자 ID와 사용자에게 정의된 IAM 정책 binding을 기반으로 웹 서버에 대한 액세스를 제공합니다.
Airflow 웹 서버는 Airflow 작업자 및 Airflow 일정과 다른 서비스 계정으로 실행됩니다. 웹 서버의 서비스 계정은 환경을 만들 때 자동으로 생성되고, 웹 서버 도메인에서 파생됩니다. 예를 들어 도메인이 example.appspot.com이면 서비스 계정은 example@appspot.gserviceaccount.com입니다.
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_monitoringDAG를 트리거합니다.airflow_monitoringDAG는 해당 환경의 모니터링 대시보드와 같이, 나중에 사용되는 환경 상태 데이터를 보고합니다. 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개까지 지원합니다.버킷 동기화. 이 프로세스는 고객 및 테넌트 프로젝트에서 환경 버킷을 동기화합니다. 이 구성요소는 DRS 환경 아키텍처와 함께 비공개 IP에 사용됩니다. 이 구성요소는 환경 버킷을 사용하는 다른 구성요소의 포드에서 컨테이너로 실행됩니다.
공개 IP 환경 아키텍처
그림 1. 공개 IP 환경 아키텍처(확대하려면 클릭) Cloud Composer 1의 공개 IP 환경 아키텍처에서 다음 안내를 따르세요.
- 테넌트 프로젝트는 Cloud SQL 인스턴스, Cloud SQL 스토리지, Airflow 웹 서버를 실행하는 App Engine Flex 인스턴스를 호스팅합니다.
- 고객 프로젝트는 해당 환경의 다른 모든 구성요소를 호스팅합니다.
- 고객 프로젝트의 Airflow 스케줄러 및 작업자는 고객 프로젝트에 있는 Cloud SQL 프록시 인스턴스를 통해 Airflow 데이터베이스와 통신합니다.
- 테넌트 프로젝트의 Airflow 웹 서버는 테넌트 프로젝트에 있는 Cloud SQL 프록시 인스턴스를 통해 Airflow 데이터베이스와 통신합니다.
비공개 IP 환경 아키텍처
그림 2. 비공개 IP 환경 아키텍처(확대하려면 클릭) 비공개 IP 환경 아키텍처에서 다음이 수행됩니다.
- 테넌트 프로젝트는 Cloud SQL 인스턴스, Cloud SQL 스토리지, Airflow 웹 서버를 실행하는 두 개의 App Engine 인스턴스를 호스팅합니다.
- 고객 프로젝트는 해당 환경의 다른 모든 구성요소를 호스팅합니다.
- Airflow 스케줄러와 작업자는 환경 클러스터의 HAProxy 프로세스를 통해 Airflow 데이터베이스에 연결합니다.
- HAProxy 프로세스는 테넌트 프로젝트에 있는 두 Cloud SQL 프록시 인스턴스 간의 Cloud SQL 인스턴스에 트래픽을 부하 분산합니다. 고객 프로젝트가 네트워크 제한으로 인해 데이터베이스에 직접 액세스하지 않으므로 비공개 IP 환경은 2개의 Cloud SQL 프록시 인스턴스를 사용합니다. 환경 구성요소가 데이터베이스에 항상 액세스할 수 있도록 하려면 두 개의 인스턴스가 필요합니다.
DRS를 사용하는 비공개 IP
그림 3. 비공개 IP 환경 아키텍처(확대하려면 클릭) 프로젝트에서 도메인 제한 공유(DRS) 조직 정책이 사용 설정된 경우 Cloud Composer는 DRS 환경 아키텍처에서 비공개 IP를 사용합니다.
DRS를 사용하는 비공개 IP 환경 아키텍처에서 다음을 수행합니다.
테넌트 프로젝트는 Cloud SQL 인스턴스, Cloud SQL 스토리지, Airflow 웹 서버를 실행하는 두 개의 App Engine 인스턴스를 호스팅합니다.
이 테넌트 프로젝트는 추가 환경의 버킷을 호스팅합니다. Airflow 웹 서버는 이 버킷에 직접 액세스합니다.
고객 프로젝트는 해당 환경의 다른 모든 구성요소를 호스팅합니다.
고객 프로젝트는 해당 환경의 클러스터에서 버킷 동기화 프로세스를 호스팅합니다. 이 프로세스는 2개의 환경 버킷을 동기화합니다.
Airflow 스케줄러와 작업자는 환경 클러스터의 HAProxy 프로세스를 통해 Airflow 데이터베이스에 연결합니다.
HAProxy 프로세스는 테넌트 프로젝트에 있는 두 Cloud SQL 프록시 인스턴스 간의 Cloud SQL 인스턴스에 트래픽을 부하 분산합니다. 고객 프로젝트가 네트워크 제한으로 인해 데이터베이스에 직접 액세스하지 않으므로 비공개 IP 환경은 2개의 Cloud SQL 프록시 인스턴스를 사용합니다. 환경 구성요소가 데이터베이스에 항상 액세스할 수 있도록 하려면 두 개의 인스턴스가 필요합니다.
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을 중지하지 마세요.
다음 단계