Zenn
🐇

Cloud Composer V1 → V2 アップグレードハマりどころ

2022/03/18に公開
GCP
Airflow
Cloud Composer
tech

はじめに

マネージド Airflow こと Cloud Composer を v1 → v2 にアップグレードする際にハマったことを書いていく。

マイグレーションガイド → https://cloud.google.com/composer/docs/migrate-composer-2-af-1

まずは v1 と v2 比較

詳細はこれを見て欲しいのですがざっくり下記。

v1 v2
GKE 普通のGKE（VPCネイティブ） AutopilotモードのGKE
Airflow のバージョン v1.10.* と v2.*.* v2.*.*
水平スケーリング ノード数を自分で調節 自動スケール
垂直スケーリング マシンタイプを指定 vCPU数、メモリ、ストレージを指定
料金モデル v1 v2
terraform v1のリソース定義じゃないとダメ v2のリソース定義じゃないとダメ
メンテナンスウィンドウ 全タスクに影響あり 実行時間が25分未満であれば影響なし

v2 良いところ

  • Airflow 2系がデフォルト
  • GKEがAutopilotなのでよりマネージドなインフラ
  • 自動で水平スケーリングできる
  • コンピューティングリソースを細かい粒度で指定できる
  • メンテナンスウィンドウの影響が小さい

ここから移行でハマったところ

Terraform の Google Provider のバージョンは 4系から Composer v2をサポート

バージョンを上げておこう。

Terraform の引数体系が異なる

v1 と v2 で引数の体系変わってる。
https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/composer_environment

terraform plan ではエラーにならず terraform apply して初めて怒られるのでビックリ。
裏でAPI叩いてないんだろうな。

メンテナンスウィンドウのスロットは最低4時間を指定しなければならない

DAGが3時~21時(JST)と比較的常時稼働しているのに対し、DAGの稼働時間を避けつつ、1週間あたり最低12時間のウィンドウ確保のため日、火、木、土で3時間ずつ確保する形にしていた。

maintenance_window {
  start_time = "2022-01-01T14:00:00Z"
  end_time   = "2022-01-01T17:00:00Z"
  recurrence = "FREQ=WEEKLY;BYDAY=SU,TU,TH,SA"
}

こちらも terraform apply でエラー。

Error: googleapi: Error 400: Found 1 problem:
1) Maintenance window slot duration must be at least 4 hours., badRequest

メンテナンスウィンドウのスロットは最低4時間を指定しなければならないので、 日、金、土で4時間ずつ確保 22:00 ~ 2:00(JST) の4時間ずつ確保する形に修正した。

maintenance_window {
  start_time = "2022-01-01T13:00:00Z"
  end_time   = "2022-01-01T17:00:00Z"
  recurrence = "FREQ=WEEKLY;BYDAY=SU,FR,SA"
}

2022/03/24時点でドキュメントに記載の無い隠れ仕様なので注意。
https://cloud.google.com/composer/docs/composer-2/specify-maintenance-windows

ドキュメント記載のComposerのService AccountへService Agent ExtensionをバインドするTerraform定義がリスキー 既に解決済!!!

Composer v2を作成するにあたり Composer の Service Agent Account に Composer v2 API Service Agent Extension ロールのバインドが必要。

  • Composer の GKE のポッドがGCPリソースにアクセスできるようにするために必要（らしい
  • ↑をするために Service Agent Account と GKE の Service Account 間にバインドを作成する必要があり、そのためにこの拡張ロールが必要（らしい

Terraform で管理する場合は ドキュメント にある通りgoogle_projecft_iam_member を定義すればOK。

以前ははちょっと微妙だった。詳細は下記の通り。

読みたい人だけ読んで

このあたりTerraformでコード管理してやろうとしたがドキュメントに記載されている方法がプロジェクトのIAM Policyを丸ごと上書きする書き方になっており踏みとどまった。

Warning: Make sure to include all existing bindings for your project, in addition to the one in the following example. Existing IAM policy in your project is overwritten with the values that you specify.

  resource "google_project_iam_policy" "example-project" {
    project = "PROJECT_ID"
    policy_data = data.google_iam_policy.composer2.policy_data
  }

  data "google_iam_policy" "composer2" {

    # IMPORTANT: Include all other IAM bindings for your project.
    # Existing IAM policy in your project is overwritten with parameters
    # specified here.

    binding {
      role = "roles/composer.ServiceAgentV2Ext"

      members = [
        "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com",
      ]
    }

    # Edit the section below along with the example binding to match your
    # project's IAM policy.
    binding {
      role = 'roles/owner',
      members = ['example-user']
    }
  }

結局、この作業はプロジェクトで一度やれば良いものなので割り切ってのコンソールからポチッとやることにした。

  1. Composerの管理画面から作成ボタン押した後、Composer2をクリック

  2. チェックボックスを選択状態にして、付与 ボタンをクリック

  3. ここまでやったらブラウザ閉じてOK

2系のデフォルトのワークロード構成がミニマム過ぎる（かも

v1と比べるとデフォルトのスペックがかなり小さいので既存のワークフローの内容次第では調整が必要かもしれない。

v1 デフォルト

↓ワーカーノード数が3になってるけどデフォルトは1かも。

v2 デフォルト

ある程度の移行期間を設けて既存のワークフローに耐えられるか経過観察するのがオススメ。

おわり

Discussion