Cloud Composer 1 | Cloud Composer 2
このページでは、環境を更新する方法について説明します。
更新オペレーションについて
新しいスケーリング パラメータやパフォーマンス パラメータの指定、カスタム PyPI パッケージのインストールを行うなど、環境のパラメータを変更すると、環境が更新されます。
このオペレーションが完了すると、環境で変更が使用できるようになります。
単一の Cloud Composer 環境の場合、一度に開始できる更新オペレーションは 1 つのみです。更新オペレーションが完了するまで待ってから、別の環境オペレーションを開始する必要があります。
triggerer の CPU 上限
Cloud Composer のバージョン 2.4.4 では、Cloud Composer 2 のすべてのバージョンに適用される Airflow トリガー コンポーネント向けに、別のパフォーマンス スケーリング アプローチが導入されています。
バージョン 2.4.4 より前の Cloud Composer 環境では、最大 1 つまたは 2 つのトリガーを使用していました。 変更後、環境ごとに最大 10 個の triggerer を使用できますが、各 triggerer は最大 1 vCPU に制限されます。
triggerer あたり複数の 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 を超えないようにすることをおすすめします。
詳細については、次の情報もご覧ください。