Home Assistantのスケーラビリティを決定する構成要因は何ですか？

Home Assistantのスケーラビリティは、主にイベント発生率、Recorderの対象範囲、自動化のファンアウト、統合の動作、ダッシュボードのサブスクリプション、ホストリソースの競合によって決まります。

エンティティ数が同じ2つのインストールでも、動作は大きく異なる場合があります。一方はほとんどアイドル状態のスイッチが中心で、もう一方は電力センサー、テンプレート、統計、カメライベントを毎秒ストリーミングしているかもしれません。設定によって、イベントのうちデータベースへの書き込み、リスナーの評価、クライアントの更新、外部呼び出しに至る数が決まります。ハードウェアは上限を決めますが、ワークロードがその上限に近づく速さを決めるのは設定です。

エンティティ数だけでなく、エンティティの変化量が重要

各エンティティはレジストリと状態のオーバーヘッドを多少増やしますが、変化の少ないエンティティが継続的な処理を生み出すことはほとんどありません。頻繁に変化するセンサーは、テンプレート、自動化、統計、Recorderへの書き込み、ダッシュボードメッセージを発生させる可能性があり、1つのソースによる影響を増幅します。

約15,000個のエンティティを扱う大規模インストールの議論は、容量を判断する前に、大量のエンティティと更新頻度、統合の品質を分けて考える必要がある理由を示しています。

レジストリエントリだけでなく、1分あたりの状態変化数と、1回の変化につき何個のリスナーが動くかを数えましょう。大規模で非アクティブなグループを無効にしてもCPU使用率、書き込み、レイテンシーが変わらないなら、そのシステムでは総エンティティ数は予測材料として弱かったということです。

Recorderの対象範囲と保持期間がイベントをストレージ処理に変える

Recorderは、どの状態遷移を永続的な行として保存するか、そしてそれらをどのくらい保持するかを決めます。対象範囲の広い記録、ノイズの多い属性、長い保持期間、統計処理、頻繁なパージ処理は、データベースサイズ、書き込み増幅、クエリコスト、バックアップ時間を増加させます。

実用的なデータベース管理ガイドでは、除外と保持期間の選択をデータベースの増加に結び付けて説明しており、Recorderの対象設定と保持期間が、Home Assistant固有の固定的な性質ではなく、直接調整できる設定項目であることが分かります。

記録するノイズを減らせば、リアルタイム制御を変えずに余裕を増やせます。ただし、履歴の可視性とのトレードオフがあります。詳細な履歴を失っても分析、トラブルシューティング、自動化の依存関係に支障がない場合に限り、エンティティを除外してください。

自動化と統合がファンアウトとブロッキングを決める

1つの状態イベントによって、複数の自動化が起動し、テンプレートがレンダリングされ、デバイスが呼び出され、サードパーティAPIの応答を待つことがあります。複雑なチェーン、範囲の広いテンプレート、過度なポーリング、ブロッキングする統合ライブラリは、他の制御処理にも必要なイベントループの時間を消費する可能性があります。

詳細な並行性の分析では、共有実行とリソース調整がどのように自動化の並行性を左右するかが説明されています。特に、複数のタスクが同じデバイスやデータ構造を対象とする場合に重要です。

自動化ルールが多いほど、必ずしも悪いわけではありません。重要なのは、トリガーの選択性とアクションのコストです。処理の範囲を限定し、遅いI/Oを非同期化し、関係のない状態更新のたびに同じ変換処理を繰り返し起動しないことで、スケーラビリティは向上します。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ダッシュボードと同居サービスは同じリソース枠を消費する

開いているダッシュボードはすべて状態を購読し、履歴、グラフ、カメラ、カスタムカードの計算を要求する場合があります。データベース、メディアサーバー、バックアップ、ローカルAI、その他のコンテナも同時にCPU、メモリ、ストレージレイテンシー、ネットワーク帯域幅を奪い合う可能性があります。

サーバー選定に関する議論では、マシンをワークロード全体に合わせることの重要性が強調されています。そのため、Core自体の負荷が低い場合でも、ホスト全体のワークロードは設定による容量の一部となります。

ハードウェア障害や壊れた統合がパフォーマンスを支配している場合、このモデルは機能しません。プロセスがメモリリークを起こしている、ディスクが故障しかけている、ネットワーク依存先がタイムアウトしているといった状況では、通常のファンアウトを調整しても予測可能なスケーリングは回復しません。

容量を増やす前にワークロードの予算を作る

代表的な繁忙時間帯に、1分あたりのイベント数、Recorderの書き込み数とサイズ、データベースクエリのレイテンシー、自動化の実行時間、接続クライアント数、CPU、メモリ、ストレージレイテンシー、再起動時間を測定します。一度に変更する設定項目は1つだけにしてください。

信頼性の高い制御の依存関係マップでは、信頼性の高い制御を維持または弱める可能性のあるコンポーネントを整理しており、単純な使用率を依存関係を踏まえた容量判断へと変換するのに役立ちます。

p95の制御レイテンシー、再起動時間、バックアップ時間、復旧テストが、十分な余裕を持って家庭内の目標値に収まっているなら、現在の設定を維持します。ある指標が特定の処理量とともに増加する場合は、記録するノイズやファンアウトを減らしてください。サービスの移設やハードウェアのアップグレードは、共有リソースのどれが制限要因なのかを特定してから行います。