インターネット障害中にHome Assistantの自動化処理の同時実行数が増加するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Can Home Assistant Automation Concurrency Rise During Internet Outages? - Zima Store Online

インターネット障害が発生すると、クラウド依存のアクションが長時間実行されたままになる一方で、新しいローカルトリガーが継続して到着するため、Home Assistant のオートメーションの同時実行数が増加することがあります。

障害が発生したからといって、Home Assistant 自体が余分な処理を生成するわけではありません。通常は短時間で終わるアクションが DNS、TCP、API、再試行、再接続のタイムアウトを待つようになり、その間もセンサーやローカル統合がイベントを生成し続けることで変化が生じます。結果として、アクションの実行時間は長くなり、トリガーの発生率はほぼ変わらず、新しい実行を破棄、再起動、キューへの追加、並列実行のいずれにするかを、選択したオートメーションモードが決定するという重複問題が起こります。

アクションの実行時間が長くなると同時実行数が増加する

オートメーションの重複には、混同してはならない2つの形態があります。並列同時実行数は同時に実行されている実行の数であり、キューに入ったバックログは、順番を待っている後続実行の数です。どちらも実行時間が長くなると増加する可能性があります。5秒ごとに1回トリガーが発生し、アクションが通常1秒で完了するなら、重複は起こりにくいでしょう。しかし、同じアクションが到達不能なクラウドエンドポイントで30秒待機すると、最初の実行がスロットを解放する前に後続トリガーが蓄積する可能性があります。

Home Assistant のユーザーは、リモートサービスの応答が悪いとクラウド統合によってシステムが遅く感じられると説明しており、これは遅いクラウド統合の呼び出しによって、通常のローカル処理よりはるかに長く処理が継続する可能性を示しています。重要な仕組みはイベント生成数の増加ではなく、すでにトリガーされた処理が滞留する時間が長くなることです。

そのため、インターネット障害によって、正常な WAN では現れなかった同時実行の問題が表面化することがあります。1秒で終わるアクションは次のトリガーと重複する機会がほとんどありませんが、タイムアウト待ちのアクションは多数のセンサー更新が発生しても完了しないまま残る可能性があります。したがって、家庭内の活動に変化がなくても、同じオートメーション定義が、ほぼ逐次的な動作からバックログ状態や並列実行状態へ移行することがあります。

新しいトリガーへの対応を決めるのはオートメーションモード

Home Assistant は、2回目以降のトリガーをすべて同じように扱うわけではありません。シングルモードでは、現在の実行中に新しい実行を拒否します。再起動モードでは、古い実行を停止して最初から再開します。キューモードでは、後続の実行を順番どおりに保持します。並列モードでは、独立したコピーを開始します。これらの動作により、同じ障害による遅延でも、リソース使用量や正確性への影響は大きく異なります。

オートメーションモードとそのユースケースをめぐるコミュニティの議論は、モードが速度設定ではなく、ワークロードに関する契約である理由を示しています。キューモードでは、長時間のリモート待機がバックログに変わります。一方、並列モードでは、同時に実行されるネットワーク処理、テンプレート処理、サービス処理に変わる可能性があります。

したがって、同時実行数が多いことが必ずしも悪いわけではなく、少ないことが必ずしも安全なわけでもありません。通知処理では並列送信が許容される場合がありますが、ロック処理やブラインド操作のシーケンスでは直列化が必要になることがあります。問題となる境界は、障害の発生中に、下流のデバイス、API、ホストが予測可能な形で完了できる量を超えて重複処理を許す場合です。

クラウドのタイムアウトは長時間実行される処理を生む

障害は、即座に検出されるのではなく、検出に時間がかかる場合に特に大きな影響を及ぼします。接続が明確に拒否されれば数ミリ秒で失敗することもありますが、IPv6 の経路障害、DNS フォールバック、TLS の再試行、あるいは接続を受け付けたまま応答しない API によって、コルーチンがはるかに長いタイムアウトの期限まで保持されることがあります。この長い遅延が、重複可能な時間帯を広げます。

2026年の Home Assistant コミュニティの報告では、IPv6 経路に問題があるとクラウド取得処理が最大105秒間ブロックされる可能性が記録されており、これは長時間に及ぶ統合のタイムアウトの具体例です。このような停止したアクションが1つあるだけでも、通常ならすぐに消えるはずの処理と後続トリガーが同時に存在する状態になります。

境界はアーキテクチャにもあります。重要なローカルオートメーションが、デバイス操作を完了する前に天気情報、クラウド通知、ベンダーの状態などを同期的に待機する場合、WAN が制御経路の一部になっています。任意のクラウド処理をローカルアクションの後に移動し、明示的なタイムアウト処理を追加するか、別のオートメーションに切り離すことで、インターネット向けの処理が不調でもローカル実行を短時間に保てます。

-15% OFF

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

Single board computer zimaboard2

max を増やす前に重複を測定する

障害中に警告が表示されたからといって、同時実行数の上限を引き上げるのが正しい対応とは限りません。オートメーションのトレースタイムラインを使って、トリガーの発生時刻、時間がかかっているステップ、アクションが実際に送信した内容を記録し、その周囲にキューの深さと実行完了時刻の記録を追加します。同じオートメーションを WAN が正常な場合と利用できない場合の両方で実行し、変化した変数を明確にします。

ZimaSpace は、イベント駆動型ワークロードのスケーリングで同様の関係を説明しています。実際に有効な並列処理能力を決めるのは、アイドル状態の CPU 使用率だけではなく、保留中の処理量と処理時間です。Home Assistant のオートメーションキューはオートスケーラーではありませんが、基本的には同じ計算に従います。

バックログが次の通常のトリガー集中より前に解消され、制御アクションが期限に間に合わないことがないなら、現在の同時実行数を維持します。障害の継続中にキュー内の経過時間や並列実行数が際限なく増加するなら、オートメーションを変更します。通常はまず、クラウド依存のステップを短縮するか分離するのが有効です。そのうえで、本当に重複実行しても安全な処理に対してのみ、同時実行数の上限引き上げを検討します。