小型ホームサーバーでHome Assistantを利用できるユーザー数は？

エヴァ・ウォン

IceWhale author

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

How Many Users Can Home Assistant Support on a Small Home Server?

Home Assistantには普遍的なユーザー上限はありません。小規模なサーバーがサポートできるのは、実際のワークロードが定めた遅延および復旧目標の範囲内に収まる同時セッション数だけです。

多くのユーザーが非アクティブであれば、登録アカウント数が多くても負荷は小さい一方、少数の負荷の高いダッシュボードでは、履歴の取得、カメラ映像のストリーミング、カスタムカードのレンダリング、高頻度のWebSocket更新が発生することがあります。リモートアクセスでは、ローカルテストでは見落としがちなプロキシやアップロードの制約も加わります。したがって、容量はユーザーレジストリに保存されている人数ではなく、許容できるサービスレベルで処理できる同時ワークロードとして表す必要があります。

登録アカウント数は同時ワークロードではない

アカウントは、誰かが接続するまでは主に識別情報と権限を追加するだけです。バックグラウンド接続中のログイン済みスマートフォンは、休眠中のアカウントより大きな負荷を発生させます。また、カメラを多用する壁面パネルは、単純な操作画面を開く複数のユーザーより大きな負荷になることがあります。

同時ユーザー数に関するコミュニティの質問からも分かるように、同時ユーザーのワークロードをCPUやメモリに単純換算する、文書化された方法はありません。クライアントの動作が大きく異なるためです。

同じ時間帯におけるアクティブなWebSocketセッション数、ダッシュボードビュー数、履歴クエリ、ストリーム、サービス呼び出しを数えてください。登録ユーザー数は管理には役立ちますが、性能予測には適していません。

ダッシュボードの設計によってユーザーあたりの負荷は変わる

シンプルなダッシュボードは限られたエンティティセットを購読します。一方、グラフ、地図、カメラ、カスタムカード、広範なテンプレートは、サーバークエリ、ネットワーク転送、クライアント側のレンダリングを増加させます。エンティティの更新頻度が高いと、購読しているすべてのセッションに負荷が積み重なります。

複数ユニット・複数ユーザーの設計に関する議論では、単なる接続数ではなく、マルチユーザーインスタンスの設計に伴う分離や整理の問題が明らかになります。

世帯の分離と性能を分けて考えてください。1つのインスタンスで複数のグループに技術的には対応できても、プライバシーや管理上の境界として不適切な場合があります。ハードウェアを増強しても、この設計上の制約は解決できません。

サーバーより先にクライアントやネットワークが問題になることがある

モバイルプロセッサ、ブラウザーのメモリ、Wi-Fiの品質、VPNの遅延、プロキシ設定、自宅のアップロード帯域幅が、体感速度を大きく左右することがあります。サーバーが迅速に応答していても、複雑なビューのレンダリングに数秒かかるデバイスは存在します。

モバイルではダッシュボードが遅いのに、コンピューターでは速いという事例は、クライアント側のダッシュボード遅延をサーバーの応答時間とは分けて計測すべき理由を示しています。

同じビューを使って、ローカルのクライアントとリモートのクライアントを比較してください。サーバーのタイムスタンプが安定しているのにレンダリング時間が異なる場合、そのクライアント経路で実用的なユーザー数を増やすことは、サーバーの容量を増やしてもできません。

-15% OFF

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

Single board computer zimaboard2

イベントのファンアウトが飽和点を生み出す

新しい状態が発生するたびに、多数の接続済みクライアントへ配信される可能性があります。また、各ビューが追加のテンプレート処理や履歴処理を引き起こすこともあります。そのため、負荷の高いセッションが重なると、CPU、メモリ、データベースの遅延、外向き帯域幅が非線形に増加することがあります。

WebSocketイベントのスパムに関する調査では、更新量とダッシュボードの遅延の関連が示されており、WebSocket更新のファンアウトが、人数が少なくても支配的な要因になり得ることが分かります。

ここが障害の境界です。同一のセッションを繰り返し追加したときに、関連するリソース使用量とサービス遅延が一貫して増加する場合を除き、ユーザー数そのものが原因ではありません。サーバーが限界に達したと判断する前に、インテグレーションの集中処理、問題のあるカード、ネットワーク障害を解決する必要があります。

2・4・8セッションテストで容量を確認する

代表的なテストプロファイルを1つ作成し、同時セッション数を2、4、8と段階的に増やします。各段階で、ダッシュボードの読み込み、固定した履歴クエリ、影響のないサービス呼び出し、カメラビューを繰り返し実行し、p95遅延、CPU、メモリ、ストレージキュー、外向き帯域幅を記録します。

同時ユーザーテストのフレームワークは、同時ユーザーの診断フレームワークを提供し、小規模なHome Assistantサーバーの指標と停止条件を定義するのに役立ちます。

世帯で設定した遅延目標を初めて満たせなくなった段階、または飽和状態が継続した段階でテストを停止します。直前に合格した段階が、そのワークロードに対してテストで確認された容量であり、普遍的な保証ではありません。リモート環境や通常の自動化処理中にもテストを繰り返し、バックアップ、アップデート、再接続の集中に備えて余裕を確保してください。