Cloud Composer 1 | Cloud Composer 2
このページでは、環境を更新する方法について説明します。
更新オペレーションについて
新しいスケーリング パラメータやパフォーマンス パラメータの指定、カスタム PyPI パッケージのインストールを行うなど、環境のパラメータを変更すると、環境が更新されます。
このオペレーションが完了すると、環境で変更が使用できるようになります。
単一の Cloud Composer 環境の場合、一度に開始できる更新オペレーションは 1 つのみです。更新オペレーションが完了するまで待ってから、別の環境オペレーションを開始する必要があります。
更新による Airflow タスクの実行への影響
カスタム PyPI パッケージのインストールなどの更新オペレーションを実行すると、環境内のすべての Airflow スケジューラとワーカーが再起動し、現在実行中のすべてのタスクが終了します。更新オペレーションが完了すると、DAG の再試行の構成方法に応じて、Airflow によってこれらのタスクの再試行がスケジュールされます。
Terraform を使用した更新
terraform apply の前に terraform plan を実行して、Terraform が環境を更新せずに新しい環境を作成するかどうかを確認します。
始める前に
ご使用のアカウント、環境のサービス アカウント、およびプロジェクトの Cloud Composer サービス エージェント アカウントに必要な権限があることを確認します。
アカウントには、環境の更新オペレーションをトリガーできるロールが必要です。
環境のサービス アカウントには、更新オペレーションの実行に十分な権限を持つロールが必要です。
オペレーションが完了すると、
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 を超えないようにすることをおすすめします。
詳細については、次の情報もご覧ください。
GKE ノードのマシンタイプのアップグレード
既存の default-pool を削除し、必要なマシンタイプで新しい default-pool を作成することで、環境の GKE クラスタのマシンタイプを手動でアップグレードできます。
環境の作成時に、Cloud Composer 環境で発生するコンピューティングの種類に適したマシンタイプを指定することをおすすめします。
リソースを大量に消費する計算を実行するジョブを実行する場合は、GKE Operators を使用することをおすすめします。
アップグレード後も、以前のマシンタイプは環境の詳細に引き続き表示されます。たとえば、[環境の詳細] ページには新しいマシンタイプが反映されていません。
Console
マシンタイプをアップグレードするには、次の手順を行います。
Google Cloud Console で [環境] ページに移動します。
環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。
デフォルトのノードプールに関する情報を取得します。
[環境の設定] タブに移動します。
[クラスタの詳細を表示] リンクをクリックします。
[クラスタ] ページの [ノード] セクションで、[default-pool] をクリックします。
ノードプールの詳細ページの [default-pool] のすべての情報を確認します。この情報を使用して、環境用の新しいデフォルトのノードプールを作成します。
default-pool を削除するには:
[ノードプールの詳細] ページで、戻る矢印をクリックして環境の [クラスタ] ページに戻ります。
[ノードプール] セクションで、[default-pool] のゴミ箱アイコンをクリックします。次に、[Delete] をクリックして操作を確定します。
新しい default-pool を作成するには:
[クラスタ] ページで、[ノードプールを追加] をクリックします。
[名前] にと
default-pool入力します。環境内のワークフローがこのプールで実行できるように、default-pool名を使用する必要があります。サイズとノードの設定を入力します。
（デフォルトの Compute Engine サービス アカウントのみ）アクセス スコープには、[すべての Cloud API に完全アクセス権を許可] を選択します。
[保存] をクリックします。
ワークロードが均等に分散されていない場合は、Airflow ワーカー デプロイメントをゼロまでスケールダウンしてから、もう一度スケールアップします。