Home Assistantの実際のパフォーマンス上限を最も左右する依存関係は何ですか？

エヴァ・ウォン

IceWhale author

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

What Dependencies Most Often Set the Real Home Assistant Performance Ceiling? - Zima Store Online

Home Assistantの実際の性能上限は、平均的なホスト使用率ではなく、イベントから結果に至る経路で必要となる依存関係のうち、通常は最も遅いものによって決まります。

モーション自動化は、無線メッシュ、コーディネーター、ブローカー、統合、イベントループ、データベース、ネットワーク、対象デバイス、そして表示クライアントの更新に依存する場合があります。CPUの高速化やRAMの増設が効果を発揮するのは、計算能力またはメモリがボトルネックになっている場合だけです。上限を見つけるには、経路全体の時間を計測し、その後、同じ再現可能なワークロードと条件の下で各段階を分離して調べます。

上限を決めるのはクリティカルパス

Home Assistantの性能は、単一のサーバーメトリクスではなく、エンドツーエンドの挙動です。トリガーはすぐに到着しても、コマンドがブローカー、無線、クラウドAPI、または対象デバイスで待たされることがあります。必要な段階のうち最も遅いものが、目に見える結果を支配します。一方、そのトランザクションの外側にある段階は、忙しく動作していても上限を決めるとは限りません。

実際の自動化のタイミングに関する議論を見ると、ホストの仕様だけでは結論を出せない理由がわかります。あるHome Assistantの遅延調査では、参加者がブローカーやZigbeeの遅延とHome Assistantの処理を分けて考えており、アプリケーションの外部で費やされる時間はプロセッサーをアップグレードしても取り除けないことを示しています。

依存関係を順位付けする前に、何を測定するのかを定義してください。イベントから自動化開始まで、コマンドからデバイス状態の変化まで、ダッシュボードの読み込み時間、再起動から使用可能になるまででは、それぞれ通過する経路が異なります。履歴クエリの上限を決めるコンポーネントが、ローカルの照明制御の上限を決めるとは限りません。そのため、インストール全体に共通する単一の上限は存在しません。

データベースとストレージが状態依存の処理を制限する

Recorderへの書き込み、履歴クエリ、ログブック表示、統計、バックアップ、起動時の復旧は、すべてストレージに依存します。頻繁に状態が変化するエンティティが多いと、トランザクションとインデックス処理が増えます。また、低速または競合しているデバイスは、ストレージに依存するすべての処理の遅延を増加させます。読み取りの多いダッシュボードが継続的な書き込みやメンテナンスと重なると、上限が特に明確に現れます。

データベースのチューニングは、データベースファイル全体を不透明な負荷として扱うのではなく、どのエンティティがデータ量を生み出しているのかを測定することから始まります。Home Assistantデータベースの最適化ガイドでは、頻繁に状態が変化するエンティティと書き込み量、ストレージへの影響、そして削除や整理の前に測定する必要性との関係が説明されています。

キューの深さや遅延が遅い結果とともに増加し、同じI/O負荷を制御した後に結果が改善するなら、ストレージが上限を決めています。データベースのサイズだけでは証拠になりません。保持期間、インデックスの構造、クエリの範囲、ファイルシステムの挙動、ホスト上で競合するジョブによって、目に見える各操作に必要な処理量が決まります。

統合はアプリケーションの処理経路を占有することがある

統合は外部プロトコルを変換し、エンドポイントをポーリングし、コールバックを処理してエンティティを提供します。起動の遅い統合は使用可能になるまでの時間を延ばし、ブロッキング処理や過度に頻繁な処理は、アプリケーションのスケジューリング余力を減らします。カスタムコードは、Home Assistantのコアやホストとは独立して挙動が変わる可能性のある、別の依存関係を追加します。

起動時間を測定すれば、統合のコストを推測ではなく観測可能なものにできます。あるユーザーによるHome Assistantの統合の起動時間に関する調査では、統合ごとに大きな差が見つかり、使用していない検出済みコンポーネントを削除しています。これは、エンティティの総数よりも、特定の依存関係の挙動のほうが有力な予測材料であることを示しています。

コールバック、ポーリング、初期化の時間が遅延した結果と連動し、無効化すると同じ測定値が変化するなら、その統合が上限を決めています。起動時のエントリに時間がかかるからといって、実行時の制御遅延を自動的に説明できるわけではありません。観測された統合の段階を、テスト対象の性能経路に対応させてください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

ブローカー、無線、メッシュは独自のキューを追加する

多くのデバイスは、MQTTブローカー、ZigbeeまたはZ-Waveコーディネーター、Bluetoothプロキシ、Threadボーダールーター、またはベンダーゲートウェイを経由してHome Assistantに接続します。それぞれのブリッジには、バッファー、再試行ルール、通信容量の制限、設置場所による制約があります。イベントがこれらの段階を通過していなければ、アプリケーションは処理できません。

サーバーがアイドル状態でも、無線性能は干渉やトポロジーによって制限されます。詳細なZigbeeネットワーク最適化ガイドでは、コーディネーターの設置場所、USB干渉、ルーターデバイス、チャンネル計画が、Home AssistantのCPU性能ではなく、安定した通信にどう関係するかが説明されています。

タイムスタンプによって、イベントがHome Assistantに到達する前、またはコマンドがHome Assistantを離れた後に遅延していることが示されるなら、これらの依存関係が上限を決めています。ダッシュボードの滑らかさよりも、ブローカーのキューの深さ、無線の再試行、デバイスのリンク品質、コーディネーターのログのほうが重要です。ローカルの有線または仮想エンドポイントを1つ、比較対象としてテストし、アプリケーションと物理ネットワークを切り分けてください。

ネットワークとクラウドの依存関係は変動する遅延の末尾を生む

ローカル統合であっても、スイッチ、アクセスポイント、DNS、ルーティング、デバイスの応答に依存します。クラウド統合では、インターネット接続、リモートサービスの負荷、認証、レート制限、プロバイダーの障害も加わります。これらの段階では、変動するテールレイテンシーが生じることがよくあります。ほとんどのリクエストは高速でも、一部が十分に長く待たされ、ユーザー体験を左右することがあります。

経路を継続的に測定すると、平均値では隠れてしまう変動を明らかにできます。あるHome Assistant運用者による遅延とパケットロスの監視では、複数のエンドポイントを記録し、アプリケーションの実行とは独立してネットワークの健全性を測定できることを示しています。

ローカル制御が目標範囲内に収まっている一方で、同等のリモート依存アクションだけが遅いなら、ネットワークまたはクラウドサービスが上限を決めています。ただし、すべてのクラウド統合がイベントループを遅くすると考えてはいけません。ボトルネックを特定する前に、外部リクエスト、そのタイムアウトと再試行の挙動、ローカルのフォールバック経路を分離して調べてください。

クライアントまたは対象デバイスが最後の制限要因になることがある

Home Assistantのサービス呼び出しが成功したことと、目に見える操作が完了したことは同じではありません。対象デバイスの応答が遅い場合があり、フロントエンドは状態を受信し、カードを評価し、グラフを描画して画面を更新する必要があります。古い壁掛けタブレットや複雑なダッシュボードは、サーバー側の自動化がすぐに完了していても遅いままになることがあります。

同じダッシュボードの挙動がデバイスによって異なる場合、クライアント側の制限が現れています。ある遅いHome Assistantの壁掛けダッシュボードに関する報告では、古いタブレット上でカードやポップアップの処理負荷が増大していることが説明されており、サーバーの容量を増やしても改善しない上限の例を示しています。

この境界を理解すると、誤ったアップグレード判断を避けられます。イベントのタイムスタンプと対象デバイスの状態が適時に更新されているのに、画面表示だけが遅い場合は、ブラウザーのスクリプト実行、描画、メモリ、ネットワーク転送を測定してください。対象デバイスの状態自体が遅れて到着する場合は、コマンド経路を逆方向にたどります。サーバー処理の完了と、人間が目で確認できる完了を別々のしきい値として扱ってください。

依存関係の階段を作り、一段ずつ変更する

再現可能なトランザクションを1つ選び、トリガーの生成、Home Assistantでの受信、自動化の開始、コマンドの送信、依存関係からの確認応答、状態の確定、クライアントでの描画をタイムスタンプで記録します。ウォームアップ済みの試行を少なくとも5回、さらに疑わしい競合負荷の中で5回実行してください。間欠的なテール遅延は平均値より重要になることがあるため、中央値と最も遅い結果を使います。

性能上限は、活発な監視画面ではなく、制御された変更によって明らかになります。Googleによるサービスチェーンのテールレイテンシーに関する分析では、依存コンポーネントの一部で遅延が発生するわずかな確率が、システム全体のレベルで可視化される理由が説明されています。

測定された遅延が最も大きい段階だけを変更し、同じ試行を繰り返してください。ストレージをホスト間で分離する場合は、ネットワーク共有上のHome Assistantデータについて、ZimaSpaceの信頼性に関する指針を利用します。その段階とエンドツーエンドの結果がともに改善し、障害が許容できるしきい値を超えて別の場所へ移らない場合にのみ、その変更を維持してください。