既知の問題

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

このページには、Cloud Composer の既知の問題が記載されています。問題の修正については、リリースノートをご覧ください。

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

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

この問題を軽減するため、Airflow 2 を使用する環境は、失敗したタスクに対して 2 回の再試行を行うようにデフォルトで構成されています。タスクが異常終了した場合、5 分間隔で 2 回再試行されます。

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

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

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

プラグインが他のモジュールをインポートする多数のファイルで構成されている場合、Airflow UI はプラグインを再読み込みする必要があることを認識できない可能性があります。このような場合は、環境の Airflow ウェブサーバーを再起動します。

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

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

  • 一時的な通信の問題。この場合は、しばらくしてから Airflow UI にアクセスしてみてください。Airflow ウェブサーバーを再起動することもできます。

  • （Cloud Composer 3 のみ）接続性に関する問題。Airflow UI が完全に利用できず、タイムアウトや 504 エラーが生成された場合は、環境で *.composer.googleusercontent.com にアクセスできることを確認してください。

  • （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 でタイムゾーンを明示的に構成してください。

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

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

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

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

Kerberos のサポート

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

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

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

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

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

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

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 へのアクセスを許可するの手順を実施します。

Airflow UI へのアクセス時にログイン ループが発生する

この問題の原因として、次のことが考えられます。

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

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

解決策:

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

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

モニタリングでの DAG 解析時間と DAG バッグサイズの図が連続していない

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

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

解決策: DAG の合計解析時間を 5 分未満にすることをおすすめします。DAG の作成ガイドラインに従い、DAG の解析時間を短縮することができます。

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

症状:

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

原因:

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

解決策:

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

KubernetesPodOperator と KubernetesExecutor の起動時間の増加

KubernetesPodOperator で作成された Pod と KubernetesExecutor で実行されたタスクでは、起動時間が長くなります。Cloud Composer チームは解決に向けて取り組んでおり、問題が解決次第お知らせします。

回避策:

  • CPU を多く使用して Pod を起動します。
  • 可能であれば、イメージをを最適化します（レイヤを減らし、サイズを小さくします）。

プロジェクトの請求先アカウントが削除または無効にされた後、または Cloud Composer API が無効にされた後、環境が ERROR 状態になる

これらの問題の影響を受ける Cloud Composer 環境は復元できません。

  • プロジェクトの請求先アカウントが削除または無効化された後（後で別のアカウントがリンクされた場合でも）。
  • プロジェクトで Cloud Composer API が無効にされた後（後で有効にした場合でも）。

この問題に対処するには、次の操作を行います。

  • 環境のバケットに保存されているデータには引き続きアクセスできますが、環境自体はもう使用できなくなります。新しい Cloud Composer 環境を作成してから、DAG とデータを転送できます。

  • 環境を復元不能にするオペレーションを実行する場合は、環境のスナップショットを作成するなどの手段で、必ずデータをバックアップするようにしてください。この方法でこのスナップショットを読み込むことで、別の環境を作成してそのデータを転送できます。

次のステップ