Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
このページでは、環境を更新する方法について説明します。
更新オペレーションについて
新しいスケーリング パラメータやパフォーマンス パラメータの指定、カスタム PyPI パッケージのインストールを行うなど、環境のパラメータを変更すると、環境が更新されます。
このオペレーションが完了すると、環境で変更が使用可能になります。
1 つの Cloud Composer 環境で一度に開始できる更新オペレーションは 1 つだけです。別の環境オペレーションを開始する前に、更新オペレーションが完了するまで待つ必要があります。
トリガラーの CPU 上限
Cloud Composer のバージョン 2.4.4 では、Cloud Composer 2 のすべてのバージョンに適用される Airflow トリガー コンポーネント向けに、別のパフォーマンス スケーリング アプローチが導入されています。
バージョン 2.4.4 より前の Cloud Composer 環境では、最大 1 つまたは 2 つのトリガーを使用していました。 変更後、環境ごとに最大 10 個のトリガーを設定できますが、各トリガーは最大 1 つの vCPU に制限されます。
環境が triggerer ごとに複数の vCPU で構成されている場合、環境の更新オペレーションは失敗します。他のコンポーネントの更新を行うには、1 vCPU の上限を満たすように構成を調整する必要があります。
詳しくは以下をご覧ください。
更新が実行中の Airflow タスクに与える影響
更新オペレーションを実行すると、環境内の Airflow スケジューラとワーカーの再起動が必要になる場合があります。この場合、現在実行中のタスクはすべて終了します。更新オペレーションが完了すると、DAG の再試行の構成方法に応じて、Airflow によってこれらのタスクの再試行がスケジュールされます。
次の変更により、Airflow タスクが終了します。
- 環境を新しいバージョンにアップグレードする。
- カスタム PyPI パッケージの追加、変更、削除。
- Cloud Composer 環境変数を変更します。
- Airflow 構成オプションのオーバーライドの追加、削除、値の変更。
- Airflow ワーカーの CPU、メモリ、ストレージの変更。
- 新しい値が現在実行中のワーカー数より小さい場合、Airflow ワーカーの最大数を減らします。たとえば、環境で現在 3 つのワーカーが実行されていて、最大数が 2 に減らされている場合。
- 環境の復元性モードの変更。
次の変更は、Airflow タスクの終了を引き起こしません。
- DAG の作成、更新、削除（更新オペレーションではない）。
- DAG の一時停止または一時停止解除（更新オペレーションではありません）。
- Airflow 変数の変更（更新オペレーションではありません）。
- Airflow 接続の変更（更新オペレーションではありません）。
- Dataplex データリネージ統合の有効化または無効化。
- 環境のサイズの変更。
- スケジューラの数の変更。
- Airflow スケジューラの CPU、メモリ、ストレージの変更。
- triggerer の数の変更。
- Airflow triggerer の CPU、メモリ、ストレージの変更。
- Airflow ウェブサーバーの CPU、メモリ、ストレージの変更。
- ワーカーの最小数の増減。
- Airflow ワーカーの最大数を指定します。たとえば、環境で現在 2 つのワーカーが実行されていて、最大数が 3 に減らされている場合。
- メンテナンスの時間枠の変更。
- スケジュールされたスナップショットの設定の変更。
- 環境ラベルの変更。
Terraform を使用した更新
terraform apply の前に terraform plan を実行して、Terraform が環境を更新するのではなく新しい環境を作成するかどうかを確認します。
始める前に
アカウント、環境のサービス アカウント、プロジェクト内の Cloud Composer サービス エージェント アカウントに必要な権限があることを確認します。
アカウントには、環境の更新オペレーションをトリガーできるロールが必要です。
環境のサービス アカウントには、更新オペレーションの実行に十分な権限を持つロールが必要です。
Cloud Composer サービス エージェント アカウントには、環境のサービス アカウントと環境のクラスタの Kubernetes サービス アカウントとの間のバインディングを作成するための権限が必要です。
オペレーションが完了すると、
gcloud composer environments updateコマンドは終了します。--asyncフラグを使用すると、オペレーションの完了を待機しないようにできます。
環境を更新する
環境の更新の詳細については、特定の更新オペレーションに関するほかのドキュメント ページをご覧ください。次に例を示します。
環境の詳細を表示する
コンソール
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 を超えないようにすることをおすすめします。
詳細については、次の情報もご覧ください。