既知の問題

Managed Airflow（Gen 3） | Managed Airflow（Gen 2） | Managed Airflow（レガシー Gen 1）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kerberos のサポート

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

マネージド Airflow（Gen 2）とマネージド Airflow（Gen 3）でのコンピューティング クラスのサポート

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

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

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

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

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

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

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

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

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

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

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

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

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

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

If the [API Controls] > [Unconfigured third-party apps] > [Don't allow users to access any third-party apps] オプションが Google Workspace で有効になっており、マネージド Airflow アプリの Apache Airflow が明示的に許可されていない場合、ユーザーは アプリケーションを明示的に許可しない限り、Airflow UI にアクセスできません。

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

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

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

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

マネージド Airflow（Gen 2）とマネージド Airflow（Gen 3）では、Airflow ウェブサーバーはほとんどの場合、読み取り専用のコンポーネントであると想定されており、Managed Airflow は 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 の解析時間を短縮することができます。

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

症状:

  • Managed Airflow（Gen 3）では、Airflow タスクログはすぐに表示されず、数分遅れます。
  • Airflow ログに Logs not found for Cloud Logging filter メッセージが表示されることがあります。

原因:

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

解決策:

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

KubernetesPodOperator と KubernetesExecutor の起動時間の増加

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

回避策

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

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

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

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

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

[core]execute_tasks_new_python_interpreter が True に設定されている場合、Airflow タスクのログが収集されない

[core]execute_tasks_new_python_interpreter Airflow 構成オプションが True に設定されている場合、Managed Airflow は Airflow タスクのログを収集しません。

解答例:

  • この構成オプションのオーバーライドを削除するか、 値をFalseに設定します。

環境の削除時にネットワーク アタッチメントの削除中にエラーが発生する

同じネットワーク アタッチメントを共有する複数の環境を同時に削除すると、一部の削除オペレーションがエラーで失敗します。

症状:

次のエラーが生成されます。

Got error while removing Network Attachment: <error code>

報告されるエラーコードは、Bad request: <resource> is not ready または Precondition failed: Invalid fingerprint です。

考えられる回避策:

次のステップ