環境を更新する

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

このページでは、環境を更新する方法について説明します。

更新オペレーションについて

新しいスケーリング パラメータやパフォーマンス パラメータの指定、カスタム PyPI パッケージのインストールを行うなど、環境のパラメータを変更すると、環境が更新されます。

このオペレーションが完了すると、環境で変更が使用可能になります。

1 つの Cloud Composer 環境で一度に開始できる更新オペレーションは 1 つだけです。別の環境オペレーションを開始する前に、更新オペレーションが完了するまで待つ必要があります。

更新が実行中の 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 サービス エージェント アカウントに必要な権限があることを確認します。

  • オペレーションが完了すると、gcloud composer environments update コマンドは終了します。--async フラグを使用すると、オペレーションの完了を待機しないようにできます。

環境を更新する

環境の更新の詳細については、特定の更新オペレーションに関するほかのドキュメント ページをご覧ください。次に例を示します。

環境の詳細を表示する

コンソール

  1. Google Cloud Console で [環境] ページに移動します。

    [環境] に移動

  2. 環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。

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 を超えないようにすることをおすすめします。

詳細については、次の情報もご覧ください。

GKE ノードのマシンタイプのアップグレード

既存の default-pool を削除し、必要なマシンタイプで新しい default-pool を作成することで、環境の GKE クラスタのマシンタイプを手動でアップグレードできます。

環境を作成するときに、Cloud Composer 環境で発生するコンピューティングの種類に適したマシンタイプを指定することをおすすめします。

リソースを大量に消費する計算を実行するジョブを実行する場合は、GKE Operators を使用することをおすすめします。

アップグレード後も、以前のマシンタイプは環境の詳細に表示されます。たとえば、[環境の詳細] ページに新しいマシンタイプが反映されません。

コンソール

マシンタイプをアップグレードするには、次の手順を行います。

  1. Google Cloud Console で [環境] ページに移動します。

    [環境] に移動

  2. 環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。

  3. デフォルトのノードプールに関する情報を取得します。

    1. [環境の設定] タブに移動します。

    2. [クラスタの詳細を表示] リンクをクリックします。

    3. [クラスタ] ページの [ノード] セクションで、[default-pool] をクリックします。

    4. ノードプールの詳細ページの [default-pool] のすべての情報を確認します。この情報を使用して、環境用の新しいデフォルトのノードプールを作成します。

  4. default-pool を削除するには:

    1. [ノードプールの詳細] ページで、戻る矢印をクリックして環境の [クラスタ] ページに戻ります。

    2. [ノードプール] セクションで、[default-pool] のゴミ箱アイコンをクリックします。次に、[Delete] をクリックして操作を確定します。

  5. 新しい default-pool を作成するには:

    1. [クラスタ] ページで、[ノードプールを追加] をクリックします。

    2. [名前] にとdefault-pool入力します。環境内のワークフローをこのプールで実行できるようにするには、default-pool 名を使用する必要があります。

    3. サイズとノードの設定を入力します。

    4. （デフォルトの Compute Engine サービス アカウントのみ）アクセス スコープには、[すべての Cloud API に完全アクセス権を許可] を選択します。

    5. [保存] をクリックします。

  6. ワークロードが均等に分散されていない場合は、Airflow ワーカー デプロイメントをゼロまでスケールダウンしてから、もう一度スケールアップします。

次のステップ