既知の問題

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

このページには、Cloud Composer の既知の問題が記載されています。これらの問題に対する修正のいくつかは現在対応中であり、今後のバージョンで実装されます。

古いバージョンに影響するいくつかの問題は、環境のアップグレードによって解決できます。

RFC 1918 以外のアドレス範囲は Pod とサービスで部分的にサポートされています

Cloud Composer は、Pod とサービスの RFC 1918 以外のアドレスのサポートの提供を GKE に依存しています。現在、Cloud Composer では、次にあげる RFC 1918 以外の範囲のみがサポートされています。

  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

Composer 1.10.2 と Composer 1.10.3 で DAG のシリアル化がオンの場合、Airflow UI はタスクログを表示しません。

Composer のバージョン 1.10.2 と 1.10.3 を使用する環境で DAG のシリアル化を有効にすると、Airflow ウェブサーバーにログが表示されなくなります。この問題を解決するには、バージョン 1.10.4 以降にアップグレードしてください。

Cloud Composer のスケジューリング中にタスクが断続的に失敗する

この問題は、タスクの実行中にタスク インスタンスの Airflow スケジューラで発生します。ただし、ログではタスクの失敗の原因が示されず、Airflow ワーカーと Airflow スケジューラは比較的正常だったように見えます。

Airflow スケジューラのエラー メッセージは、次のエラーのようになります。

Executor reports task instance <TaskInstance: xx.xxxx scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the task says its queued. (Info: None) Was the task killed externally?

または、Airflow ワーカーに次のようなエラーがある場合があります。

Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have finished abnormally (e.g. was evicted).

Airflow の長年の問題に起因するこのようなエラーに対して堅牢性を確保するため、タスクレベルと DAG レベルの両方で適切な再試行戦略を事前に実装することを強くおすすめします。これらの対策を組み込むことで、システムはこれらのエラーの影響を効果的に軽減し、ワークフローの全体的な信頼性と復元力を高めることができます。

GKE Workload Identity はサポートされていません

この問題は、Cloud Composer 1 環境についてのみ該当します。Cloud Composer 2 環境では Workload Identity を使用します。

Cloud Composer 環境のクラスタに対して Workload Identity を有効にはできません。その結果、Security Command Center に WORKLOAD_IDENTITY_DISABLED が表示される場合があります。

更新中に追加された環境ラベルが完全には反映されていません

更新された環境ラベルは、Compute Engine VM には適用されません。回避策として、これらのラベルは手動で適用できます。

CVE-2020-14386 の問題に関連した GKE のアップグレード

Google は、すべての Cloud Composer 環境で CVE-2020-14386 の脆弱性の解決に取り組んでいます。この修正の一環として、既存の Cloud Composer の GKE クラスタはすべて新しいバージョンに更新されます。

この脆弱性に直ちに対処することを決定したお客様は、次の点を考慮しながら、これらの手順に従って Composer GKE クラスタをアップグレードできます。

ステップ 1. 1.7.2 より前のバージョンの Cloud Composer を実行している場合は、Cloud Composer の新しいバージョンにアップグレードします。バージョン 1.7.2 以降をご利用の場合は、次の手順に進みます。

ステップ 2. この脆弱性の修正を含む最新の 1.15 パッチ バージョンに GKE クラスタ（マスターとノード）をアップグレードしてください。

Airflow 1.9.0 から Airflow 1.10.x へのアップグレード後、Airflow ウェブサーバーで Airflow タスクログが利用できなくなります

Airflow 1.10.x では、ログファイルの命名規則に関する下位互換性のない変更が導入されています。Airflow タスクのログ名にゾーン情報が追加されました。

Airflow 1.9.0 では、次の形式でのログ名が保存、想定されます。BUCKET/logs/DAG/2020-03-30T10:29:06/1.log Airflow 1.10.x では、次の形式でのログ名が保存、想定されます。BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

そのため、Airflow 1.9.0 から Airflow 1.10.x にアップグレードする際に Airflow 1.9.0 で実行されるタスクのログを読み取ると、Airflow ウェブサーバーに次のエラー メッセージが表示されます。Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

回避策: Cloud Storage バケットで Airflow 1.9.0 によって生成されたログの名前を、次の形式を使用して変更します。BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

constraints/compute.disableSerialPortLogging の組織のポリシーを有する Cloud Composer 環境が作成できません

constraints/compute.disableSerialPortLogging がターゲット プロジェクトに適用されている場合、Cloud Composer 環境の作成は失敗します。

診断

この問題の影響を受けたかどうかを判断するには、次の手順に従います。

Google Cloud コンソールの GKE メニューに移動します。GKE メニューに移動

次に、新しく作成したクラスタを選択します。次のエラーを確認します。

Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:

Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

回避策:

  1. Cloud Composer 環境を作成するプロジェクトで組織のポリシーを無効にします。

    親リソース（組織またはフォルダ）で有効にされていても、プロジェクト レベルで組織のポリシーをいつでも無効にできます。詳細については、ブール型制約のポリシーのカスタマイズ ページをご覧ください。

  2. 除外フィルタを使用する

    シリアルポート ログに除外フィルタを使用すると、ログにシリアル コンソール ログが記録されるため、組織ポリシーを無効にする場合と同じ目標が達成されます。詳しくは、除外フィルタのページをご覧ください。

VPC Service Controls で保護されている Google Cloud リソースを管理することを目的とした Deployment Manager の使用

Composer では、Deployment Manager を使用して Cloud Composer 環境のコンポーネントを作成します。

2020 年 12 月に、Deployment Manager で VPC Service Controls で保護されているリソースを管理できるようにするために、追加の VPC Service Controls の構成を実施することが必要になるという内容の情報を受信されている可能性があります。

Composer を使用しており、Deployment Manager を直接 Google Cloud リソースの管理に使用しない場合は、Deployment Manager のお知らせでお伝えしているとおり、お客様側で何も操作していただく必要がないことを明記します。

GKE クラスタが削除された後は環境を削除できません

お使いの環境そのものを削除する前にその環境のクラスタを削除する場合、お使いの環境を削除しようとしたときに次のエラーが発生します。

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

GKE クラスタがすでに削除されている場合に環境を削除するには:

  1. Google Cloud Console で [Deployment Manager] ページを開きます。

    Deployment Manager ページを開く

  2. ラベルが付いているすべてのデプロイを検索します。

    • goog-composer-environment:<environment-name>
    • goog-composer-location:<environment-location>。

    以下のラベルが付けられた 2 つのデプロイが表示されます。

    • <environment-location>-<environment-name-prefix>-<hash>-sd という名前のデプロイ
    • addons-<uuid> という名前のデプロイ

  3. これら 2 つのデプロイにまだリストされ、プロジェクト（Pub/Sub のトピックとサブスクリプションなど）に存在しているリソースを、手動で削除します。手順は次のとおりです。

    1. デプロイを選択します。

    2. [削除] をクリックします。

    3. [2 つのデプロイと、それらによって作成されたすべてのリソース（VM、ロードバランサ、ディスクなど）の削除] オプションを選択し、[すべて削除] をクリックします。

    削除操作は失敗しますが、残りのリソースは削除されます。

  4. 次のいずれかの方法でデプロイを削除します。

    • Google Cloud Console で、もう一度両方のデプロイを選択します。[削除] をクリックし、[2 つのデプロイを削除しますが、作成されたリソースを保持します] オプションを選択します。

    • gcloud コマンドを実行して、ABANDON ポリシーを持つデプロイを削除します。

      gcloud deployment-manager deployments delete addons-<uuid> \
    --delete-policy=ABANDON

gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \
    --delete-policy=ABANDON

  5. Cloud Composer 環境を削除します。

Deployment Manager で、サポートされていない機能に関する情報が表示されます

Deployment Manager のタブに次のような警告が表示されることがあります。

The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.

Cloud Composer が所有する Deployment Manager のデプロイの場合は、この警告を無視してください。

「echo-airflow_monitoring」DAG に属する「echo」タスクの重複エントリに関する警告

Airflow ログに次のエントリが表示される場合があります。

in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")

このエラーは Airflow DAG とタスク処理に影響しないため、これらのログエントリは無視できます。

Google は、こうした警告を Airflow ログから取り除くように Cloud Composer サービスを改善しています。

Identity-Aware Proxy API が VPC Service Controls の境界に追加されたプロジェクトで環境の作成が失敗する

VPC Service Controls が有効になっているプロジェクトでは、環境を作成するために、cloud-airflow-prod@system.gserviceaccount.com アカウントはセキュリティ境界で明示的なアクセス権が必要です。

環境を作成するには、次のいずれかの方法を使用します。

  • Cloud Identity-Aware Proxy API と Identity-Aware Proxy TCP API をセキュリティ境界に追加しないでください。

  • YAML 条件ファイルで次の構成を使用して、cloud-airflow-prod@system.gserviceaccount.com サービス アカウントをセキュリティ境界のメンバーとして追加します。

     - members:
    - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com

compute.requireOsLogin ポリシーが有効な場合、Cloud Composer 1 環境の作成が失敗します

プロジェクトで compute.requireOsLogin ポリシーが true に設定されている場合、Cloud Composer 1 v1 環境の作成オペレーションは失敗します。

Cloud Composer 1 環境を作成するには、プロジェクトでこのポリシーを無効にします。

この組織のポリシーの詳細については、組織のポリシーの制約をご覧ください。

compute.vmExternalIpAccess が無効な場合、Cloud Composer 環境の作成またはアップグレードが失敗する

パブリック IP モードで構成された Cloud Composer 所有の GKE クラスタでは、VM に外部接続が必要です。このため、compute.vmExternalIpAccess ポリシーでは外部 IP アドレスを持つ VM の作成を禁止できません。この組織のポリシーの詳細については、組織のポリシーの制約をご覧ください。

compute.vmCanIpForward ポリシーが無効な場合、Cloud Composer 環境の作成が失敗します。

VPC ネイティブ以外のモード（エイリアス IP を使用）で作成された Cloud Composer 1 環境では、有効な「IP 転送」機能を使用して VM を作成できるようにするために、このポリシーが必要となります。この組織のポリシーの詳細については、組織のポリシーの制約をご覧ください。

アップロードした DAG ファイルに対する初回の DAG 実行に、失敗したタスクがいくつかある

DAG ファイルをアップロードするとき、そのファイルに対する初回の DAG 実行時に、最初のいくつかのタスクが Unable to read remote log... エラーで失敗します。この問題が発生するのは、DAG ファイルが環境のバケット、Airflow ワーカー、環境内の Airflow スケジューラの間で同期されているためです。これらの同期は独立して行われます。スケジューラが DAG ファイルを取得し、ワーカーが実行するようにスケジュールした場合、ワーカーに DAG ファイルがまだない場合は、タスクの実行が失敗します。

回避策として、Cloud Composer 1.17.0-preview.9 以降のバージョンの Airflow 2 環境は、失敗したタスクに対して 2 回の再試行を行うようにデフォルトで構成されています。タスクが異常終了した場合、5 分間隔で 2 回再試行されます。

Airflow 1 でこの問題の回避策を使用するには、core-default_task_retries Airflow 構成オプションを 2 以上の数値に設定してオーバーライドします。

Airflow 1.10.15 以前のバージョンで「OSError: [Errno 5] Input / output error」でタスクが失敗する

まれに、Airflow 1 バージョンのバグが原因でタスクが Redis キューに 2 回挿入される場合があります。

それによってログファイルで競合状態が発生し、後続のタスクが失敗することがあります。タスクの失敗により、Cloud Logging には「OSError: [Errno 5] Input/output error」、タスク試行ログには「Task is in the 'running' state which is not a valid state for execution.」が残されます。

このバグは、Airflow 2 で修正されています。長時間実行タスクの Airflow 1 でこの問題が発生した場合は、[celery_broker_transport_options]visibility_timeout Airflow 構成オプションの値を増やします（デフォルト値は Composer 1.17.0 では 604800、古い環境では 21600 です）。短時間のタスクの場合は、影響を受けるタスクの再試行回数を増やすか、環境を Airflow 2 に移行することを検討してください。

Dataproc / Dataflow 演算子が Negsignal.SIGSEGV で失敗する

これは Celery ワーカーから使用した場合に grcpio ライブラリで断続的に発生する問題です。この問題は、Airflow 1.10.14 以降のバージョンに影響を与えます。

回避策として、環境 GRPC_POLL_STRATEGY=epoll1 に以下の環境変数を追加して、grpcio のポーリング方法を変更します。この回避策は、Cloud Composer 1.17.1 以降のバージョンではすでに適用できるようになっています。

GKE バージョンからサポートが終了したベータ版 API を削除することについて

Cloud Composer は、基盤となる Cloud Composer が所有する GKE クラスタを管理します。DAG とコードでこのような API を明示的に使用しない限り、GKE API のサポート終了に関する通知は無視できます。必要に応じて、Cloud Composer により移行処理が行われます。

CVE-2021-25741 のセキュリティの問題に関連した GKE のアップグレード

既存の Cloud Composer の GKE クラスタはすべて、新しい GKE バージョンに自動アップグレードされ、CVE-2021-25741 に記載された問題が修正されます。

この脆弱性に直ちに対処する場合は、クラスタのアップグレードの手順に沿って、環境の GKE クラスタをアップグレードしてください。

  • Cloud Composer 1 の環境と GKE バージョン 1.18.x 以前を使用している場合は、1.18.20-gke.4501 にアップグレードします。

  • Cloud Composer 1 の環境と GKE バージョン 1.19.x がある場合は、1.19.14-gke.301 にアップグレードします。

  • Cloud Composer 2 の環境と GKE バージョン 1.21.x がある場合は、1.21.4-gke.301 にアップグレードします。

Cloud Composer には Apache Log4j 2 の脆弱性（CVE-2021-44228）の影響なし

Apache Log4j 2 脆弱性（CVE-2021-44228）が発見されたことを受けて、Cloud Composer の詳細な調査を行ったところ、Cloud Composer にはこの脆弱性の悪用に対する脆弱性はないものと思われます。

環境の Cloud Storage バケットへのアクセス時、Airflow ワーカーや Airflow スケジューラに問題が発生する可能性あり

Cloud Composer は gcsfuse を使用して、環境のバケット内の /data フォルダにアクセスし、Airflow タスクログを /logs ディレクトリに保存します（有効な場合）。gcsfuse が過負荷状態の場合や、環境のバケットを使用できない場合、Airflow タスク インスタンスで障害が発生し、Airflow ログに Transport endpoint is not connected エラーが表示されることがあります。

解決策:

  • 環境のバケットへのログの保存を無効にします。 Cloud Composer 2.8.0 以降のバージョンを使用して環境を作成する場合は、このオプションはデフォルトで無効になっています。
  • Cloud Composer 2.8.0 以降のバージョンにアップグレードします。
  • [celery]worker_concurrency を減らし、代わりに Airflow ワーカーの数を増やします。
  • DAG のコードで生成されるログの量を減らします。
  • DAG を実装するための推奨事項とベスト プラクティスに従い、タスクの再試行を有効にします。

プラグインを変更すると、Airflow UI でそのプラグインが再読み込みされないことがある

プラグインが他のモジュールをインポートする多数のファイルで構成されている場合、Airflow UI はプラグインを再読み込みする必要があることを認識できない可能性があります。このような場合は、Airflow ウェブサーバーの再起動をトリガーする必要があります。これを行うには、環境変数を追加するか、PYPI 依存関係のインストールまたはアンインストールを行います。Airflow ウェブサーバーを再起動することもできます。

Airflow Metedata データベースとの通信時の断続的な問題

この既知の問題は Cloud Composer 1 についてのみ該当します。

2021 年 8 月 12 日より前に作成された古い Cloud Composer 1 環境（1.16.3 以前）では、Airflow メタデータ DB との通信に関連する一時的な問題が発生することがあります。

この問題が発生した場合は、Airflow タスクログに次のエラー メッセージが表示されます。

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

Cloud Composer チームがこの問題の解決に取り組んでいます。その期間内に、この問題の影響が発生していると疑われる場合には、次の手順で問題を解決できます。

  1. Google Cloud コンソールで、影響を受ける Cloud Composer 環境の [環境の構成] ページに移動します。
  2. [クラスタの詳細を表示] リンクから、環境の基盤となる GKE クラスタに移動します。

  3. [ノード] タブに移動し、[ノードプール] セクションに表示されている [default-pool] をクリックします。

    ノードプールのリスト内の default-pool
    図 1. ノードプールのリスト内の default-pool（クリックして拡大）

  4. ページ上部の [編集] をクリックします。

  5. イメージタイプを [containerd を含む Container-Optimized OS]　に変更し、次のように構成を保存します。

    ノードプールのイメージタイプを Docker から containerd に変更する
    図 2.ノードプールのイメージタイプを Docker から containerd に変更する（クリックして拡大）

  6. 変更が送信されると、default-pool のノードプールが再構成され、containerd がコンテナ ランタイムとして使用されます。ノードプールの再構成中に、一部の Airflow タスクが失敗する可能性があります。これらのタスクの再試行が構成されている場合、ノードプールでのオペレーションが完了すると、Airflow によって再度実行されます。

環境のクラスタでワークロードがスケジュール不可の状態になっています

この既知の問題は Cloud Composer 2 についてのみ該当します。

Cloud Composerr 2 では、環境が作成されると、環境のクラスタ内のいくつかのワークロードがスケジュール不可の状態のままになります。

環境がスケールアップされると、新しいワーカー Pod が作成され、Kubernetes がそれらを実行しようとします。実行できる空きリソースがない場合、ワーカー Pod はスケジュール不可とマークされます。

この場合、クラスタ オートスケーラーがノードを追加します（数分かかる場合があります）。完了するまで、Pod はスケジュール不可能の状態のままで、タスクは実行されません。

composer-gcsfuse と composer-fluentd という名前のスケジュール不可能な DaemonSet ワークロードは、Airflow コンポーネントが存在しないノードで起動できないため、環境には影響しません。

この問題が長時間（1 時間以上）続く場合は、Cluster Autoscaler のログを調べることができます。ログビューアで次のフィルタを使用して確認できます。

resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"

クラスタ オートスケーラーによる決定に関する情報が含まれます。noDecisionStatus を展開して、クラスタをスケールアップまたはスケールダウンできない理由を確認します。

Airflow UI へのアクセス時の 504 エラー

Airflow UI にアクセスすると、504 Gateway Timeout エラーが発生することがあります。このエラーは、次に挙げる複数の原因が考えられます。

  • 一時的な通信の問題。この場合は、しばらくしてから Airflow UI にアクセスしてみてください。Airflow ウェブサーバーを再起動することもできます。
  • （Cloud Composer 2 のみ）接続に関する問題。Airflow UI が完全に利用できず、タイムアウトや 504 エラーが生成された場合は、環境で *.composer.cloud.google.com にアクセスできることを確認してください。限定公開の Google アクセスを使用して、private.googleapis.com 仮想 IP または VPC Service Controls でトラフィックを送信し、restricted.googleapis.com 仮想 IP でトラフィックを送信する場合は、Cloud DNS を *.composer.cloud.google.com ドメイン名にも構成します。
  • Airflow ウェブサーバーが応答しない。エラー 504 が発生しても、特定の時点で Airflow UI にアクセスできる場合は、負荷が大きいために Airflow ウェブサーバーが応答しなかった可能性があります。ウェブサーバーのスケールとパフォーマンスのパラメータを増やします。

Airflow UI へのアクセス時の 502 エラー

エラー 502 Internal server exception は、Airflow UI が受信リクエストを処理できないことを示しています。このエラーは、次に挙げる複数の原因が考えられます。

  • 一時的な通信の問題。しばらくしてから Airflow UI にアクセスしてみてください。

  • ウェブサーバーを起動できない。ウェブサーバーを開始するには、最初に構成ファイルを同期する必要があります。ウェブ サーバーログで、GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp や GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp のようなログエントリを確認します。 これらのエラーが表示された場合は、エラー メッセージに記載されているファイルが環境のバケットに存在するかどうかを確認します。

    誤って削除された場合（たとえば、保持ポリシーが構成されたため）は、次の方法で復元できます。

    1. 環境に新しい環境変数を設定します。任意の変数名と値を使用できます。

    2. Airflow 構成オプションをオーバーライドします。存在しない Airflow 構成オプションを使用できます。

ツリービューでタスク インスタンスにカーソルを合わせると、捕捉されていない TypeError がスローされる

Airflow 2 では、デフォルト以外のタイムゾーンを使用すると、Airflow UI のツリービューが正しく機能しない場合があります。この問題の回避策としては、Airflow UI でタイムゾーンを明示的に構成してください。

Airflow 2.2.3 以前のバージョンの Airflow UI は CVE-2021-45229 に対して脆弱

CVE-2021-45229 で示されているように、[Trigger DAG with config] 画面は origin クエリ引数による XSS 攻撃の影響を受けやすくなっています。

推奨事項: Airflow 2.2.5 をサポートする最新の Cloud Composer バージョンにアップグレードします。

ワーカーは以前の Airflow バージョンよりも多くのメモリを必要とします

症状

  • Cloud Composer 2 環境で、Airflow ワーカーのすべての環境のクラスタ ワークロードが CrashLoopBackOff ステータスになり、タスクを実行しない。この問題の影響を受けると、OOMKilling 警告が生成されて表示されることもあります。

  • この問題により、環境アップグレードが妨げられる可能性があります。

原因:

  • [celery]worker_concurrency Airflow 構成オプションでカスタム値を使用し、Airflow ワーカーでカスタムメモリ設定を使用すると、リソース使用量が上限に近づいたときにこの問題が発生する可能性があります。
  • Python 3.11 を使用した Airflow 2.6.3 の Airflow ワーカーのメモリ要件は、以前のバージョンのワーカーと比較して 10% 高くなっています。
  • Airflow 2.3 以降のバージョンの Airflow ワーカーのメモリ要件は、Airflow 2.2 または Airflow 2.1 のワーカーと比較して 30% 高くなっています。

解決策:

  • worker_concurrency のオーバーライドを削除して、Cloud Composer がこの値を自動的に計算するようにします。
  • worker_concurrency にカスタム値を使用する場合は、より小さな値に設定します。 自動的に計算された値を出発点として使用できます。
  • それ以外の方法としては、Airflow ワーカーが使用できるメモリの量を増やすこともできます。
  • この問題が原因で環境を新しいバージョンにアップグレードできない場合は、アップグレード前に提案された解決策のいずれかを適用します。

Cloud Run functions を使用したプライベート ネットワーク経由の DAG トリガー

Cloud Composer では、VPC コネクタを使用してプライベート ネットワーク経由で Cloud Run functions で DAG をトリガーすることはサポートされていません。

推奨: Cloud Run functions を使用して Pub/Sub にメッセージをパブリッシュします。このようなイベントによって Pub/Sub センサーを起動し、Airflow DAG をトリガーしたり、遅延可能な演算子に基づいてアプローチを実装したりできます。

410.0.0 バージョンでの gcloud composer コマンドに関する問題

410.0.0 バージョンの gcloud では、次の Cloud Composer コマンドに問題があります。

  • gcloud composer environments run
  • gcloud composer environments list-packages

これらのコマンドはゼロ以外のエラーコードを返し、次のエラー メッセージを表示します。

  (ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)

この動作は gcloud コマンドによって生成される通常の出力に加えて発生し、機能には影響しません。

この問題がオペレーションに影響しない場合は、410.0.0 バージョンを引き続き使用できます。また、誤ったエラー メッセージは無視できます。バージョン 410.0.0 を使用する必要があり、gcloud コマンドをプログラムで使用する場合は、ゼロ以外のエラーコードと出力内のエラーのスタックトレースに関する情報を無視するロジックを追加で実装してください。その他の回避策については、解決策のセクションをご覧ください。

解決策

  • 410.0.0 バージョンにアップグレードしないでください。409.0.0 バージョン以前を使用してください。
  • すでにアップグレードされている場合は、以前のバージョン（409.0.0 など）にダウングレードしてください。詳細については、バージョニングされたアーカイブの使用をご覧ください。

スケジューラとワーカーの空のフォルダ

Cloud Composer では、Airflow ワーカーとスケジューラから空のフォルダを積極的に削除しません。このようなフォルダがバケットに存在し、最終的に削除された場合に、環境バケット同期プロセスの結果として、そのようなエンティティが作成される可能性があります。

推奨事項: このような空のフォルダをスキップするように DAG を調整します。

こうしたエンティティは、このようなコンポーネントの再起動時に Airflow スケジューラとワーカーのローカル ストレージから最終的に削除されます（Cloud Composer クラスタでのスケールダウンやメンテナンス オペレーションの結果として）。

Kerberos のサポート

Cloud Composer では、Airflow Kerberos の構成はまだサポートされていません。

Cloud Composer 2 でのコンピューティング クラスのサポート

Cloud Composer 2 は、汎用のコンピューティング クラスのみをサポートしています。つまり、他のコンピューティング クラス（バランスやスケールアウトなど）をリクエストする Pod は実行できません。

汎用クラスでは、最大 110 GB のメモリと最大 30 個の CPU をリクエストする Pod を実行できます（コンピューティング クラスの最大リクエストを参照）。

ARM ベースのアーキテクチャを使用する場合や、CPU とメモリを増やす必要がある場合は、別のコンピューティング クラスを使用する必要があります。これは、Cloud Composer 2 クラスタではサポートされていません。

推奨事項: GKEStartPodOperator を使用して、選択したコンピューティング クラスをサポートする別のクラスタで Kubernetes Pod を実行します。別のコンピューティング クラスを必要とするカスタム Pod を実行する場合は、Cloud Composer 2 以外のクラスタで実行する必要があります。

Google キャンペーン マネージャー 360 の演算子のサポート

2.1.13 より前のバージョンの Cloud Composer の Google キャンペーン マネージャーの演算子は、サポートが終了したキャンペーン マネージャー 360の v3.5 API に基づいており、廃止日は 2023 年 5 月 1 日です。

Google キャンペーン マネージャーの演算子を使用する場合は、環境を Cloud Composer バージョン 2.1.13 以降にアップグレードします。

Google ディスプレイ＆ビデオ 360 の演算子のサポート

2.1.13 より前のバージョンの Cloud Composer の Google ディスプレイ＆ビデオ 360 の演算子は、サポートが終了したディスプレイとビデオ 360 v1.1 API をベースに基づいており、廃止日は 2023 年 4 月 27 日です。

Google ディスプレイ＆ビデオ 360 の演算子を使用している場合は、環境を Cloud Composer バージョン 2.1.13 以降にアップグレードします。加えて、一部の Google ディスプレイ＆ビデオ 360 の演算子はサポートが終了し、新しいものに置き換えられるため、DAG の変更が必要になることがあります。

  • GoogleDisplayVideo360CreateReportOperator のサポートは終了しました。代わりに GoogleDisplayVideo360CreateQueryOperator を使用します。この演算子は report_id ではなく query_id を返します。
  • GoogleDisplayVideo360RunReportOperator のサポートは終了しました。代わりに GoogleDisplayVideo360RunQueryOperator を使用します。この演算子は report_id のみではなく query_id と report_id を返し、パラメータとして report_id ではなく query_id を必要とします。
  • レポートの準備ができているかどうかを確認するには、query_id パラメータと report_id パラメータを使用する新しい GoogleDisplayVideo360RunQuerySensor センサーを使用します。非推奨の GoogleDisplayVideo360ReportSensor センサーに必要なのは report_id のみでした。
  • GoogleDisplayVideo360DownloadReportV2Operator には query_id パラメータと report_id パラメータの両方が必要になりました。
  • GoogleDisplayVideo360DeleteReportOperator には、DAG に影響する変更はありません。

セカンダリ範囲名の制限事項

CVE-2023-29247（保存された XSS に対して　UI のタスク インスタンスの詳細ページが脆弱）

Airflow バージョン 2.0.x～2.5.x の Airflow UI には CVE-2023-29247 の脆弱性があります。

2.4.2 より前のバージョンの Cloud Composer を使用していて、環境がセキュリティ上の脆弱性を利用した不正プログラムに対して脆弱であると思われる場合は、以下の説明と考えられる解決策をご覧ください。

Cloud Composer では、Airflow UI へのアクセスは IAM と Airflow UI アクセス制御によって保護されます。

つまり、Airflow UI の脆弱性を悪用するには、攻撃者はまず必要な IAM 権限とロールとともにプロジェクトへのアクセス権を取得する必要があります。

解決方法:

  • プロジェクトの IAM 権限とロール（個々のユーザーに割り当てられた Cloud Composer ロールなど）を確認します。承認されたユーザーのみが Airflow UI にアクセスできるようにします。

  • Airflow UI アクセス制御メカニズム（これは、Airflow UI へのよりきめ細かいアクセスを提供する別のメカニズムです）を使用して、ユーザーに割り当てられたロールを確認します。承認されたユーザーのみが Airflow UI にアクセスできることと、すべての新規ユーザーが適切なロールに登録されていることを確認してください。

  • VPC Service Controls による追加の強化を検討してください。

削除後に Cloud Composer 2 の Composer 環境の Airflow モニタリング DAG が再作成されない

ユーザーが削除したり、composer-2.1.4-airflow-2.4.3 の Composer 環境のバケットから移動したりしても、Airflow モニタリング DAG は自動的に再作成されません。

解決方法:

  • これは、composer-2.4.2-airflow-2.5.3 などの新しいバージョンで修正されています。環境を新しいバージョンにアップグレードすることをおすすめします。
  • 環境のアップグレードの代替手段または一時的な回避策として、同じバージョンの別の環境から airflow_monitoring DAG をコピーすることもできます。

Sentry が有効になっている場合、アップグレード オペレーションが失敗することがある

環境で Sentry を構成し、[sentry]sentry_on 設定を true に設定すると、Cloud Composer 環境のアップグレード オペレーションが失敗する場合があります。

解決方法:

  • 環境で Sentry をオフにしてアップグレードを実行し、Sentry を再度構成します。

Cloud SQL のストレージを削減できない

Cloud Composer は Cloud SQL を使用して Airflow データベースを実行します。Cloud SQL インスタンスのディスク ストレージは時間の経過とともに増加する場合があります。これは、Airflow データベースの拡大時に Cloud SQL オペレーションによって保存されたデータに合わせてディスクがスケールアップされるためです。

Cloud SQL ディスクのサイズをスケールダウンすることはできません。

回避策として、最小の Cloud SQL ディスクサイズを使用したい場合は、スナップショットによって Cloud Composer 環境を再作成できます。

Cloud SQL からレコードを削除した後も、データベースのディスク使用量の指標が縮小しない

Postgres や MySQL などのリレーショナル データベースでは、削除や更新時に行が物理的に削除されることはありません。代わりに、「デッドタプル」としてマークされ、データの整合性を維持して同時実行トランザクションがブロックされないようになります。

MySQL と Postgres の両方で、削除されたレコードの後に領域を再利用するメカニズムを実装しています。

データベースに未使用のディスク容量の再利用を強制することはできますが、これはリソースを大量に消費するオペレーションになり、データベースがさらにロックされ、Cloud Composer を使用できなくなります。したがって、未使用の容量を再利用するための構築メカニズムを使用することをおすすめします。

アクセスをブロック: 認証エラーです

この問題がユーザーに影響する場合、[アクセスをブロック: 認証エラーです] ダイアログに Error 400: admin_policy_enforced メッセージが含まれます。

[API の制御] > [未設定のサードパーティ製アプリ] > [ユーザーにサードパーティ製アプリへのアクセスを許可しない] オプションが Google Workspace で有効になっており、Cloud Composer アプリの Apache Airflow が明示的に許可されていない場合、アプリケーションを明示的に許可しない限り、ユーザーは Airflow UI にアクセスできません。

アクセスを許可するには、Google Workspace で Airflow UI へのアクセスを許可するの手順を実施します。

過去に成功したタスク インスタンスが [FAILED] とマークされています

特定の状況やまれなシナリオでは、過去に成功した Airflow タスク インスタンスが FAILED とマークされる可能性があります。

このエラーが発生した場合、通常は環境の更新またはアップグレード オペレーション、あるいは GKE のメンテナンスによってトリガーされます。

注: この問題自体は環境に問題があることを示しているわけではなく、タスクの実行で実際に失敗することはありません。

この問題は、Cloud Composer バージョン 2.6.5 以降で修正されています。

Airflow コンポーネントで Cloud Composer 構成の他の部分と通信する際に問題が発生する

ごくまれに、Compute Engine メタデータ サーバーとの通信速度が遅いために、Airflow コンポーネントが最適に機能しない場合があります。たとえば、Airflow スケジューラが再起動される場合、Airflow タスクの再試行が必要になる場合、また、タスクの起動時間が長くなる場合があります。

症状:

Airflow コンポーネントのログ（Airflow スケジューラ、ワーカー、ウェブサーバーなど）に次のエラーが表示されます。

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

解決策:

環境変数 GCE_METADATA_TIMEOUT=30 を設定します。

/data フォルダが Airflow ウェブサーバーで使用できない

Cloud Composer 2 では、Airflow ウェブサーバーはほとんどの場合、読み取り専用のコンポーネントであると想定されており、Cloud Composer は data/ フォルダをこのコンポーネントと同期しません。

Airflow ウェブサーバーを含めて、すべての Airflow コンポーネント間で共通のファイルを共有する場合もあります。

解決策:

  • ウェブサーバーと共有するファイルを PYPI モジュールにラップし、通常の PYPI パッケージとしてインストールします。PYPI モジュールが環境にインストールされると、ファイルは Airflow コンポーネントの画像に追加され、使用できるようになります。

  • plugins/ フォルダにファイルを追加します。このフォルダは Airflow ウェブサーバーと同期されます。

モニタリングでの DAG の非連続的な解析時間と DAG バッグサイズの図

Monitoring ダッシュボードの DAG 解析時間と DAG バッグサイズの図が連続していない場合は、DAG 解析時間が長い（5 分を超える）問題が発生しています。

一連の連続していない間隔を示す Airflow DAG の解析時間と DAG バッグサイズのグラフ
図 3.連続していない DAG 解析時間と DAG バッグサイズのグラフ（クリックして拡大）

解決策: DAG の合計解析時間を 5 分未満にすることをおすすめします。DAG の解析時間を短縮するには、DAG の作成ガイドラインに沿って作成してください。

タスクログの表示に遅延が生じる

この既知の問題は Cloud Composer 3 に該当します。

症状:

  • Cloud Composer 3 では、Airflow タスクログはすぐに表示されず、数分遅れます。

原因 :

環境で多数のタスクが同時に実行されている場合、環境のインフラストラクチャのサイズがすべてのログを十分な速さで処理するのに十分でないため、タスクログが遅れる可能性があります。

解決策:

  • パフォーマンスを向上させるために、環境のインフラストラクチャのサイズを増やすことを検討してください。
  • DAG の実行を時間の経過とともに分散して、タスクが同時に実行されないようにします。

次のステップ