Cloud Composer 1 | Cloud Composer 2
このページでは、環境を更新する方法について説明します。
更新オペレーションについて
新しいスケーリング パラメータやパフォーマンス パラメータの指定、カスタム PyPI パッケージのインストールを行うなど、環境のパラメータを変更すると、環境が更新されます。
このオペレーションが完了すると、環境で変更が使用できるようになります。
単一の Cloud Composer 環境の場合、一度に開始できる更新オペレーションは 1 つのみです。更新オペレーションが完了するまで待ってから、別の環境オペレーションを開始する必要があります。
トリガーの CPU 上限
バージョン 2.4.4 の Cloud Composer では、すべての Cloud Composer 2 バージョンに適用される Airflow トリガー コンポーネントに異なるパフォーマンス スケーリング アプローチが導入されます。
バージョン 2.4.4 より前の Cloud Composer 環境では、最大 1 つまたは 2 つのトリガーを使用していました。 変更後、環境ごとに最大 10 個のトリガーを設定できますが、各トリガーは最大 1 個の vCPU に制限されます。
環境がトリガーごとに 1 つ以上の vCPU で構成されている場合、環境更新オペレーションは失敗します。他のコンポーネントで更新を実行するには、1 vCPU の上限を満たすように構成を調整する必要があります。
詳しくは以下をご覧ください。
更新による Airflow タスクの実行への影響
カスタム PyPI パッケージのインストールなどの更新オペレーションを実行すると、環境内のすべての Airflow スケジューラとワーカーが再起動し、現在実行中のすべてのタスクが終了します。更新オペレーションが完了すると、DAG の再試行の構成方法に応じて、Airflow によってこれらのタスクの再試行がスケジュールされます。
Terraform を使用した更新
terraform apply の前に terraform plan を実行して、Terraform が環境を更新せずに新しい環境を作成するかどうかを確認します。
始める前に
ご使用のアカウント、環境のサービス アカウント、およびプロジェクトの Cloud Composer サービス エージェント アカウントに必要な権限があることを確認します。
アカウントには、環境の更新オペレーションをトリガーできるロールが必要です。
環境のサービス アカウントには、更新オペレーションの実行に十分な権限を持つロールが必要です。
Cloud Composer のサービス エージェント アカウントには、環境のサービス アカウントと環境のクラスタの Kubernetes サービス アカウントの間のバインディングを作成する権限が必要です。
オペレーションが完了すると、
gcloud composer environments updateコマンドは終了します。--asyncフラグを使用すると、オペレーションの完了を待機しないようにできます。
環境を更新する
環境の更新の詳細については、特定の更新オペレーションに関する他のドキュメント ページをご覧ください。例:
環境の詳細を表示する
Console
Google Cloud Console で [環境] ページに移動します。
環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。
gcloud
次の gcloud コマンドを実行します。
gcloud composer environments describe ENVIRONMENT_NAME \
--location LOCATION
次のように置き換えます。
ENVIRONMENT_NAMEを環境の名前にする。LOCATIONは、環境が配置されているリージョン。
API
environments.get API リクエストを作成します。
例:
GET https://composer.googleapis.com/v1/projects/example-project/
locations/us-central1/environments/example-environment
Terraform
環境のリソースに対して terraform state show コマンドを実行します。
環境の Terraform リソースの名前は、環境の名前と異なる場合があります。
terraform state show google_composer_environment.RESOURCE_NAME
次のように置き換えます。
RESOURCE_NAMEは、環境のリソースの名前に置き換えます。
更新の変更のロールバック
まれに、（タイムアウトなどの理由で）更新オペレーションが中断され、リクエストされた変更がすべての環境コンポーネント（Airflow ウェブサーバーなど）でロールバックされないことがあります。
たとえば、更新オペレーションでは、追加の PyPI モジュールのインストールまたは削除、新しい Airflow 環境変数や Cloud Composer 環境変数の再定義や定義、Airflow 関連のパラメータの変更などが考えられます。
このような状況は、Cloud Composer クラスタの自動スケーリングやメンテナンス オペレーションなど、他のオペレーションの進行中に更新オペレーションがトリガーされた場合に発生することがあります。
このような場合は、オペレーションを繰り返すことをおすすめします。
更新またはアップグレード オペレーションの期間
ほとんどの更新またはアップグレード オペレーションでは、Airflow スケジューラ、ワーカー、ウェブサーバーなどの Airflow コンポーネントを再起動する必要があります。
コンポーネントを再起動したら、初期化する必要があります。初期化中に、Airflow スケジューラとワーカーは環境のバケットから /dags フォルダと /plugins フォルダの内容をダウンロードします。ファイルを Airflow スケジューラやワーカーに同期するプロセスは即時ではなく、これらのフォルダ内のすべてのオブジェクトの合計サイズと数によって異なります。
DAG ファイルとプラグイン ファイルのみを /dags フォルダと /plugins フォルダにそれぞれ保持し、他のファイルはすべて削除することをおすすめします。/dags フォルダと /plugins フォルダのデータが多すぎると Airflow コンポーネントの初期化が遅くなり、場合によっては初期化ができなくなる可能性があります。
/dags フォルダと /plugins フォルダに保持するデータは 30 MB 未満にし、100 MB を超えないようにすることをおすすめします。
詳細については、次の情報もご覧ください。