Home Assistantのリソーススケジューリング：インターネット障害でローカル制御の動作が変わる理由

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Home Assistant Resource Scheduling: Why Internet Outages Change Local-Control Behavior

インターネットが停止しても、Home Assistantのローカルオートメーションが自動的に失敗するわけではありません。ローカルのZigbee、Z-Wave、Matter、ESPHome、MQTT、LAN統合は、WANが停止している間も動作を継続できます。変化するのは、それらを取り巻く処理です。クラウドリクエストはタイムアウトし、統合は再試行し、DNSルックアップは失敗し、リモート接続は切断され、接続が復旧すると復旧処理が一気に発生することがあります。

そのため、ローカルの制御経路が維持されていても、障害中のリソーススケジューリングは重要です。問題は「Home Assistantにインターネットが必要か」ではありません。失敗したリモート処理が分離されたままになるのか、それともイベントループの処理時間、エグゼキュータースレッド、DNS容量、ログのI/O、統合の再読み込みを消費し始め、ローカル制御と重なるのかという点です。

失敗したクラウドリクエストは、高速な成功経路をタイムアウト経路に変える

WANが正常なとき、クラウドリクエストはすぐに完了することがあります。しかし障害中は、同じ呼び出しがタイムアウト時間いっぱいまで処理を占有し、再試行し、エラーを記録してから戻ることがあります。数回の呼び出しなら問題ありませんが、多数の統合が同時にこれを行うと、通常とは異なるスケジューリング状況になります。

Home Assistantの設定エントリーのライフサイクルには、準備が整っていない依存関係向けの明示的なsetup retry状態があり、自動試行の間隔は時間の経過とともに長くなります。正確な失敗モードは各統合に依存しますが、再試行処理は例外的なケースではなく、機能低下時の動作として定義されています。

重要なオートメーションでは、ローカルアクションを実行する前にリモートAPIの応答を待たないようにしてください。家の動作を決めるうえでリモート結果が不要なら、物理的なアクションを実行した後に、通知、クラウド更新、外部Webhookを送信します。

ネットワークタイムアウトは、高いCPU使用率がなくてもリソースを占有する

停止したネットワーク処理は、CPUをほとんど使わない一方で、タスク、接続、スレッド、タイムアウトの予算を占有することがあります。そのため、「CPU使用率はわずか10%」だからといって、障害の影響がないとは限りません。

2026年のHome Assistantの事例では、統合のタイムアウトが繰り返され、再読み込みが連鎖した原因として、接続が速やかに失敗せず、待機し続ける状態を引き起こした壊れたIPv6経路が特定されました。症状はネットワーク呼び出し周辺のスケジューリング遅延であり、計算リソースの枯渇そのものではありませんでした。

保留中のネットワークタスク、統合の警告、DNSの失敗、トリガーからローカルサービス呼び出しまでの時間を確認してください。クラウドエンティティが利用不能になってもローカルアクションが高速なままなら、障害は適切に分離されています。失敗したリモート呼び出しに伴ってローカルの遅延が増えるなら、共有ランタイムを占有している統合またはカスタムコードを特定してください。

ブロッキング処理は、非同期の待機より危険

Home Assistantのコアは非同期で動作するため、適切に実装された統合はI/Oを待つ間に処理を中断し、他のタスクを実行できるようにします。危険なのは、イベントループ自体を占有するブロッキング処理や、誤った場所で同期ネットワーク処理を実行するカスタムコードです。

Home Assistantの開発者向けガイダンスでは、イベントループ内のブロッキング処理は、完了するまで他の処理の実行を妨げると説明されています。インターネット障害が起きると、通常はすぐに戻る呼び出しが突然長いタイムアウトまで待機するため、この弱点が表面化することがあります。

そのため、ネイティブのローカル統合が適切に設計されていても、カスタム統合によって障害時にプラットフォーム全体が遅くなったように感じられることがあります。ハードウェアを疑う前に、カスタムコンポーネントを無効にした状態で挙動を比較してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

復旧時には、2回目の負荷急増が発生することがある

インターネット接続が復旧すると、複数の統合がほぼ同時に再接続し、状態を更新し、再認証し、エンティティを更新し、新しい履歴を書き込むことがあります。そのため、復旧中は障害の真っ最中よりも処理が忙しくなる場合があります。

WANの復旧直後にCPU、ネットワーク、Recorderへの書き込みが急増しても、それだけで通常時の定常的な処理能力が不足していると判断しないでください。急増がどのくらい続くか、またその後にローカル制御の遅延が通常値に戻るかを測定してください。

ZimaSpaceの記事「再接続後の保持メッセージ、キューに入ったメッセージ、ディスカバリーメッセージ、可用性メッセージ」にも同じ復旧の原則が示されています。分散したコンポーネントが再接続すると、接続が安定していた間には存在しなかった処理が、状態の再生によって発生することがあります。

通常モードだけでなく、機能低下モードも想定してスケジュールする

WANが停止している間も、ローカルの人感センサーから照明を制御する経路は、リモートの前提条件なしで動作し続けるべきです。クラウドポーリングは上限付きの再試行に移行し、リモート通知は失敗またはキューに入り、DNS依存サービスは予測可能な形で失敗し、接続が戻ると短時間の更新処理が発生する可能性があります。

目標とすべき設計は、選択的な機能低下です。不要なリモート処理は遅くなるか停止する一方で、ローカル制御は通常の応答時間の範囲内に維持します。最も有効な障害テストは、家庭内の通常の負荷がかかっている状態でWANを切断し、いくつかの重要なローカルオートメーションを測定したうえで、再接続後に復旧時の急増と通常値へ戻るまでの時間を測定することです。