Azure Managed Airflowでスケジューラのハートビートが止まる原因と復旧手順【Alembic不整合対策】

Azure Managed Airflow を使っていると、ある日突然スケジューラのハートビートが止まり、DAG が一切動かなくなることがあります。本記事では、2025/08/09 を最後にハートビートが途切れた実際の障害事例をベースに、根本原因となった Alembic（メタデータDBマイグレーション）の不整合と、その復旧プロセス、再発防止のポイントを Azure / Airflow 運用者向けに詳しく解説します。

Azure Managed Airflow でスケジューラのハートビートが止まるとは？

Azure Managed Airflow（以下、Managed Airflow）の UI には、スケジューラ（scheduler）の状態を示す「Heartbeat」情報が表示されます。通常は数秒〜数十秒おきに更新され、Airflow 全体の「心臓の鼓動」のような役割を担っています。

ところが、ある日を境にこの Heartbeat が更新されなくなり、最終ハートビート時刻が固定されたままになってしまうことがあります。今回の実例では、最終ハートビートが 2025/08/09 のまま一切更新されず、次のような状況に陥りました。

UI 上の「Scheduler」欄に最終ハートビートが 2025/08/09 のまま表示され続ける
DAG が一切スケジュール実行されない（手動トリガは動く場合もある）
インスタンスを再起動しても改善しない
変数変更やストレージからの DAG 再取り込みなど UI からの操作では変化がない
ログにも決定的なエラーメッセージが見当たらない
新規に作り直した Managed Airflow インスタンスでも類似の失敗が発生する

一見すると「スケジューラのプロセスが死んでいるだけ」にも見えますが、裏ではもっと深刻な問題が起きていました。

今回の事例の全体像

項目	内容
症状	Managed Airflow の UI 上でスケジューラの最終ハートビートが 2025/08/09 から更新されない
試したこと	インスタンス再起動、変数変更、DAG 再取り込み、設定見直しなど
ログ	スケジューラ・Web サーバログに決定打となるエラーは見つからず
影響	DAG の自動スケジュール実行が停止、新規インスタンスでも同様の事象
最終的な原因	Alembic の「未知リビジョン」がメタデータ DB に混入し、スケジューラが起動できない状態になっていた
復旧方法	プラットフォーム側で Alembic の `alembic_version` テーブルから未認識リビジョンを削除し整合性を回復

ポイントは、ユーザー側の UI 操作や通常の再起動では一切改善せず、メタデータ DB の内部状態をプラットフォーム側で修正する必要があったという点です。

根本原因：不適合な Python パッケージと Alembic の未知リビジョン

Managed Airflow とメタデータ DB / Alembic の関係

Airflow は、DAG 実行履歴やタスクの状態、接続情報など、さまざまなメタデータを RDB（PostgreSQL など）に保存しています。このメタデータ DB のスキーマ変更を管理するのが Alembic です。

Airflow のアップグレードやプロバイダの更新に伴い、DB スキーマも進化する
その差分（マイグレーション）を alembic_version テーブルで管理する
Airflow 起動時には、現在の DB スキーマが想定どおりかを Alembic を通してチェックする

Managed Airflow は、このメタデータ DB をマネージドで提供しており、ユーザーは直接 DB にログインして変更することは前提になっていません。ここに「マネージドならでは」の注意点があります。

不適合な Airflow プロバイダが招いた DB マイグレーションの不整合

今回の事例では、Managed Airflow 上に導入した 不適合な Python パッケージ / Airflow プロバイダ がトリガとなっていました。

Airflow 本体のバージョンと整合しない apache-airflow-providers-* を導入
そのプロバイダが内部的に持っている Alembic マイグレーションが、Managed Airflow の想定と合わない形で適用される
結果として、メタデータ DB の alembic_version テーブルに「プラットフォームが知らないリビジョン」が記録される

これがいわゆる「未知のマイグレーションリビジョンが混入した状態」です。Managed Airflow プラットフォーム側の Airflow / Alembic から見ると、「自分が知らないリビジョンが DB にある。どの状態として扱えばよいか分からない」という状況に陥ります。

なぜスケジューラのハートビートが止まるのか

Airflow スケジューラは起動時に、メタデータ DB のマイグレーション状態をチェックします。このとき Alembic で不整合が起きると、以下のような流れになります。

スケジューラプロセス起動
DB に接続し、マイグレーション状態を確認
未知リビジョンがあるため、内部で例外（エラー）が発生
スケジューラプロセスが起動直後に終了してしまう
結果として Heartbeat（定期更新）が打てない

UI（ウェブサーバ）は動き続けていても、スケジューラが内部でクラッシュしているため、最終ハートビート時刻が更新されず、「ある日を最後に時間が止まって見える」状態になります。

復旧方法：プラットフォーム側で Alembic テーブルを是正

今回の事例では、ユーザー側の操作だけでは復旧できず、最終的には Azure プラットフォーム側で次の作業を行うことで解決しました。

メタデータ DB 内の alembic_version テーブル を調査
Managed Airflow の想定バージョンセットに含まれない「未知のリビジョン」を特定
その未知リビジョンを alembic_version から削除（または正しいリビジョンに戻す）
DB のマイグレーション整合性が取れた状態に修復
スケジューラを再起動し、正常起動と Heartbeat 再開を確認

この修正後、

既存の Managed Airflow インスタンスのスケジューラ Heartbeat が再開
新規に作り直したインスタンスでも正常動作するようになった

重要なのは、この操作はあくまでプラットフォーム側が行うべきものであり、Managed 環境の利用者が直接 DB に手を入れるべきではないという点です。ユーザーが勝手に DB を触ると、サポート対象外になる可能性もあります。

ユーザー側でできる一次切り分けと安全な対処

実運用の現場では、サポートに投げる前にある程度は自分たちで状況を整理し、影響範囲を抑えたいところです。ただし Managed Airflow では、DB への直接変更は NG です。ここでは、安全にできる範囲に絞って一次切り分け手順を整理します。

1. 直近の変更点を棚卸しする

まずは「いつからおかしくなったか」と「その直前に何を変えたか」を洗い出します。

requirements.txt の変更履歴
Airflow UI の「Python パッケージ」設定で追加・更新したライブラリ
特に apache-airflow-providers-* 系とその依存関係の追加・更新
Airflow 本体のアップグレード有無（Managed 側のメンテナンスやバージョン変更）

タイムラインを整理するため、簡単な表にまとめておくと、後のサポート起票時にも役に立ちます。

日時（UTC）	操作内容	担当者	備考
2025-08-08 10:00	`apache-airflow-providers-xyz` 追加	operatorA	requirements.txt 更新
2025-08-09 01:30	DAG デプロイ	operatorB	新規ワークフロー追加
2025-08-09 02:05	スケジューラ最終 Heartbeat	自動	ここを境に停止

2. 直近追加パッケージの一時切り戻し

「このパッケージを入れてからおかしくなった」という候補がある場合、いったん 安全な組み合わせに戻す ことを検討します。Managed Airflow が公式にサポートしている Python パッケージ / プロバイダの組み合わせに合わせるイメージです。

具体的には、次のような対応が考えられます。

直近で追加したパッケージを requirements.txt でコメントアウト
バージョン指定を行わず「最新」を引いていた箇所を、安定版にピン留め
Airflow 本体とプロバイダを同系列で固定する（例：Airflow 2.8 系ならプロバイダも 2.8 系の推奨版）

# NG 例（毎回最新を取りに行く）
apache-airflow-providers-google

# 推奨（運用中バージョンに合わせてピン留め）
apache-airflow==2.8.1
apache-airflow-providers-google==10.15.0

ただし、既に Alembic の未知リビジョンが DB に混入してしまっている場合、この切り戻しだけではスケジューラが復旧しない 可能性が高い点に注意が必要です。あくまで「これ以上悪化させないための防御」と捉えましょう。

3. スケジューラ Heartbeat の再確認

設定やパッケージを変更したら、Managed Airflow インスタンスを再起動し、数分〜十数分ほど待って以下を確認します。

UI 上の「Scheduler」欄に表示される最終 Heartbeat が更新されるか
新規 DAG あるいは単純なサンプル DAG をスケジュール実行してみて動作するか
タスクのキューイングや実行履歴が更新されているか

それでも Heartbeat が 2025/08/09 など特定日時から動かない場合は、アプリケーション側（DAG や設定）ではなく、メタデータ DB の問題である可能性が高いと判断できます。

4. ログの観点：Alembic / migration / revision というキーワード

Managed Airflow のログ（スケジューラ、ウェブサーバ）を確認する際は、以下のキーワードを中心に検索します。

alembic
migration
revision
upgrade / downgrade

ログが豊富な環境では、例えば次のようなメッセージがヒントになります（あくまでイメージ）。

ERROR [alembic.runtime.migration] Can't locate revision identified by 'xxxxxxxxxxxx'

しかし、今回の事例では ログがほとんど出ていない ケースでも問題が発生していました。したがって、

ログに明確な Alembic エラーが出るとは限らない
それでも「パッケージ更新直後に Heartbeat が止まった」なら、マイグレーション不整合を第一候補に疑う価値がある

という心構えが重要です。

5. やっていいこと・いけないこと

Managed 環境ならではの線引きを、表にまとめると次のとおりです。

カテゴリ	やってよいこと	やってはいけないこと
設定変更	UI / 構成ファイルから DAG や変数、接続設定を変更	Airflow コア設定を勝手に書き換え、サポート対象外の構成にする
パッケージ	サポート対象の Python パッケージ／プロバイダの導入・バージョン固定	互換性検証のないプロバイダを大量に導入し、頻繁に最新化する
DB 操作	サポートへ状態確認を依頼し、バックエンドでの修正を任せる	ユーザーが直接メタデータ DB にログインし、`alembic_version` を書き換える
障害対応	ログ収集・変更履歴整理・影響範囲の把握	原因不明のままインスタンスを乱立させ、問題を拡散させる

特に、DB に直接手を入れる対応は、Managed 環境では行わないことをチーム内で共通認識にしておくと安全です。

再発防止のベストプラクティス

同じような「スケジューラのハートビート断」を繰り返さないために、Managed Airflow 運用で意識しておきたいポイントを整理します。

Airflow 本体とプロバイダのバージョン整合性を保つ

Airflow 本体のバージョンと主要プロバイダを同一系列でピン留めする
「とりあえず最新にしておこう」という運用をやめ、安定版のみを採用する
プロバイダのリリースノートを確認し、サポートしている Airflow バージョンをチェックする

実務上は、次のような方針が分かりやすいです。

本番で使うバージョンセットを 1 セット決めておく（Airflow 本体 + 主要プロバイダ）
そのセットは半年〜1 年程度変えない（セキュリティ修正などは別途検討）
バージョンアップは検証環境で十分に試してから本番へ適用

requirements.txt を Git 管理し、変更履歴を明確にする

障害時に必ず話題になるのが、「誰がいつ何を入れたのか？」という点です。これを曖昧にしないためにも、

requirements.txt を Git リポジトリで管理する
Pull Request ベースで変更をレビューする
コミットメッセージに「変更理由」や「関連チケット番号」を明記する

こうしておけば、「このコミットで apache-airflow-providers-xyz を上げたら Heartbeat が止まった」という因果関係を素早く検証できます。

段階的リリース：検証→ステージング→本番

Managed Airflow インスタンスを複数用意できる環境であれば、

検証用（dev）インスタンス
ステージング（stg）インスタンス
本番（prod）インスタンス

のような段階的リリースフローを構築しておくと安心です。

dev に新しい DAG・パッケージを適用して動作確認
stg で prod に近いデータ量・スケジュールで負荷検証
問題ないことを確認してから prod へ反映

もし Alembic 関連の不具合が dev で起きれば、本番に飛び火する前にサポートへ相談できます。

監視：スケジューラ Heartbeat の遅延でアラート

「気づいたら 3 日間止まっていた」という事態を避けるには、監視が欠かせません。

スケジューラ Heartbeat が一定時間（例：5〜10分以上）更新されない場合にアラート
実行中の DAG が一定時間以上キューイングのまま変化しない場合にアラート
Airflow の全体ヘルスチェックが NG になった場合にアラート

Managed Airflow が提供するメトリクスやログを Azure Monitor / アラートルールと連携しておくと、運用の「見える化」が進みます。

「パッケージ更新＋ハートビート断」がセットなら、早期に DB マイグレーション不整合を疑う

今回の事例で重要なのは、

Airflow プロバイダ等のパッケージを更新した直後に
スケジューラ Heartbeat が途絶えた

というタイミングの一致です。このような場合、

単なる一時的なスケジューラのクラッシュではなく
Alembic など DB マイグレーションの不整合が起きている可能性

を早期に疑い、「DB 状態の確認・修正が必要かもしれない」とサポートへ伝えることで、調査がスムーズになります。

Azure サポートへエスカレーションする際のチェックリスト

Managed Airflow では、最終的な DB 是正はプラットフォーム側の対応が必要です。そのため、スムーズに調査・復旧してもらうには、初回のサポートチケットに必要な情報をできるだけ揃えておくことが重要です。

項目	内容の例
サブスクリプション情報	サブスクリプション ID、サブスクリプション名
リージョン	Managed Airflow をデプロイしているリージョン（例：Japan East）
インスタンス名	問題が発生している Managed Airflow 環境の名前
Airflow バージョン	Managed Airflow が提供している Airflow 本体のバージョン
主要プロバイダ一覧	`apache-airflow-providers-*` の名称とバージョン一覧
直近のパッケージ変更	いつ、誰が、どのパッケージを追加・更新したか（UTC 時刻）
初回発生日	スケジューラ Heartbeat が最後に更新された日時（例：2025/08/09）
現在の症状	UI 上の最終 Heartbeat 時刻、DAG の実行状況、再起動有無など
ログ断片	可能であれば alembic / migration / revision 関連のログを抜粋
影響範囲	停止中の重要ジョブ、新規インスタンスでの再現有無など

チケットには、次のような文言を添えると意図が伝わりやすくなります。

Airflow スケジューラの最終ハートビートが 2025/08/09 から更新されず、インスタンス再起動や設定変更では改善しません。直前に Airflow プロバイダの更新を行っており、Alembic の未知リビジョンがメタデータ DB に混入している可能性があります。
メタデータ DB（alembic_version テーブル）を含めたバックエンド側の調査・是正をご支援いただけないでしょうか。

ここまで書いておくと、「ユーザーに追加で何度も質問してから調査開始」という手戻りを減らせます。

似た症状との切り分け：本当に Alembic が原因か？

スケジューラ Heartbeat が止まったからといって、必ずしも Alembic 不整合とは限りません。他にも考えられる原因がいくつかあります。

症状	よくある原因	Alembic との違い
DAG のパースエラーでスケジューラが落ちる	バグのある DAG コード、巨大な DAG ファイル	ログに DAG パースエラーが明確に出ることが多い
リソース不足によるスケジューラの不安定化	大量の DAG/タスク、DB 接続数不足	スケジューラは動いたり止まったりを繰り返すことが多い
Airflow アップグレード直後の不具合	設定の互換性問題、既知バグ	特定バージョンでのみ再現、バージョンロールバックで治ることも
Alembic 未知リビジョン	不適合なプロバイダ導入、DB マイグレーションの不整合	パッケージ更新と同タイミングで発生、DB の是正が必要になる

今回のように、

パッケージ更新直後に Heartbeat が完全に止まる
新規インスタンスでも同様の症状が出る
DAG をすべて退避しても改善しない

といった条件が揃うと、Alembic の可能性がかなり高くなります。逆に、DAG をシンプルにしていくと復活する場合は、DAG 側の問題を疑った方がよいでしょう。

Azure Managed Airflow の運用指針として押さえておきたいポイント

最後に、本記事の内容を踏まえて、Managed Airflow を安全に運用するための指針を整理します。

サポート対象の Python パッケージ / Airflow プロバイダの組み合わせだけを使う
Airflow 本体とプロバイダを同系列でバージョン固定し、むやみに最新へ上げない
requirements.txt を Git 管理し、誰が何を変えたかを明確にする
検証 → ステージング → 本番の段階的リリースを徹底する
スケジューラ Heartbeat 遅延（5〜10 分以上）を監視・アラートする
パッケージ更新と同時期の Heartbeat 断は、DB マイグレーション不整合を第一候補として疑う
DB の直接操作は行わず、サポートへ早期にエスカレーションする

まとめ：ハートビート断の裏側には Alembic の不整合が潜んでいる

Azure Managed Airflow でスケジューラのハートビートが 2025/08/09 を最後に止まった今回の事例では、

不整合な Airflow プロバイダ（Python パッケージ）の導入により
Airflow メタデータ DB の Alembic に「プラットフォームが認識しないマイグレーションリビジョン」が混入し
スケジューラ起動時にエラーとなって Heartbeat が打てなくなっていた

というのが本質でした。復旧には、プラットフォーム側で alembic_version テーブルの状態を是正し、DB の整合性を回復する作業が必要でした。

ユーザー側では、

バージョン整合性の取れたパッケージのみを使用する
変更履歴を明確にし、問題発生時にすぐ原因候補を絞り込めるようにする
Heartbea t 遅延を監視し、早期に異常を検知する
DB に関わる問題が疑われる場合は、速やかにサポートへエスカレーションする

といった運用を徹底することが、同様のインシデントを防ぐ最善策になります。

もしあなたの環境でも、「スケジューラの最終ハートビートがある日を境にピタっと止まった」「インスタンス再起動や DAG の整理をしても復活しない」という状況に陥った場合、本記事で紹介した観点から状況を整理し、Alembic の未知リビジョン混入を疑いながら、Azure サポートと連携して復旧を進めてみてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。