Home Assistantは動作が遅くなる前に、同時に何人のユーザーに対応できますか?

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

Home Assistantには、「20ユーザー」や「100ユーザー」といった便利な一律の答えはありません。ログイン済みでアイドル状態のアカウントによる負荷は、複雑なダッシュボードを表示する壁掛けタブレット、履歴を開くスマートフォン、あるいは数千のエンティティが更新される中でカメラカードを複数のユーザーが見ている場合の負荷とは異なります。

接続クライアント数と、各クライアントが発生させる処理を測定して、同時利用の規模を決めてください。実用上の限界は、代表的なダッシュボード、WebSocket更新、サーバーアクション、ネットワーク経路が、許容できると考える応答目標を下回り始める時点です。

ユーザーアカウントではなく接続クライアント数を数える

100個のアカウントを作成しても、100個の同時セッションが存在するとは限りません。逆に、1人のユーザーがブラウザー、スマートフォン、タブレット、キオスクを同時に接続することもあります。

Home AssistantのWebSocket統合では、sensor.connected_clientsで現在接続されているWebSocketクライアント数を確認できます。ワークロードを再現する際は、この数値を同時接続数の指標として使用してください。

クライアント数を、サーバーのCPU使用率、メモリープレッシャー、ネットワークスループット、アクションのレイテンシと併せて記録します。その背後にあるワークロードを伴わない接続数だけでは、容量の結果とはいえません。

フロントエンドの負荷は状態更新とダッシュボード処理によって決まる

フロントエンドはWebSocket接続を確立し、Home Assistantの状態をブラウザーと同期し続けます。各クライアントは開いたダッシュボードも描画する必要があるため、サーバーより先にクライアントのハードウェアやカスタムカードが限界に達することがあります。

現在のフロントエンドアーキテクチャでは、フロントエンドがWebSocket APIを通じてコアの状態と追加のサブスクリプションを受信する仕組みが説明されています。そのため、負荷の高い環境では、初回ページ読み込み後も継続的な更新処理が発生します。

すべてのクライアントで空のテストページを開くのではなく、家庭内で実際に使用するダッシュボードの組み合わせをベンチマークしてください。

エンティティの更新頻度が高いと、ユーザー数が少なく見えてもクライアントに負荷がかかる

頻繁に変化するセンサーが数千個あるシステムでは、主に静的なエンティティを表示する、より大規模なユーザー環境よりもはるかに多くのフロントエンド処理が発生することがあります。これは、古いタブレットや低性能の壁掛けパネルで特に顕著です。

Home Assistantの課題では、表示されるダッシュボード自体は単純でも、大量のエンティティ更新によってダッシュボードクライアントが過負荷になった事例が報告されています。

これは一律のしきい値を定めるものではありませんが、「ユーザー数」だけを単一の単位として扱うのが適切でない理由を示しています。接続数と併せて、1秒あたりの更新数とクライアントの応答性を測定してください。

家庭規模でそのまま使える公表済みの最大値はない

大規模な導入に関するコミュニティの質問からも、不確実性が分かります。約200ユーザーについての議論では、明確なサポート上限は見つからず、その規模は一般的ではない用途として、想定するのではなくテストすべきものとされました

一般的な家庭では、ベンダーのような最大セッション数を追い求める必要はありません。コミュニティゲート、共有施設、ラボなど、多数のユーザーが利用する環境では、サーバーが技術的に接続を維持できたとしても、Home Assistantが認証・アクセス管理のプラットフォームとして適切でない可能性があります。

ZimaSpaceの同時ワークロードに基づくサイジング方法は、ここでも適用できます。容量は登録アカウントの総数ではなく、現実的に想定される最も忙しい時間帯の重なりに基づいて決めるべきです。

段階的なテストを行い、同じ指標で障害が再現するまで確認する

段階 測定項目 停止条件
アクティブなクライアントを少数ずつ追加する 接続クライアント数 想定する同時利用数に到達
実際のダッシュボードを開く 初期描画と操作の遅延 ユーザーが繰り返し体感できる遅延
通常のエンティティ通信を発生させる WebSocketおよび更新の負荷 クライアントが更新に追従できない
一般的なアクションを実行する サーバーのアクションからデバイスまでのレイテンシ 操作のレイテンシが大幅に上昇
ピーク時に再度実行する CPU、メモリー、ネットワーク、クライアントの負荷 同じ制約要因が再び現れる

最初に再現可能な障害が発生した段階の1つ手前を容量の目安とし、バックアップ、更新、カメラ通信、想定外の急増に備えた余裕を残してください。古いタブレット1台だけが遅くなり、サーバーアクションが高速なままであれば、サーバーを交換しても実用上の同時利用数は増えない可能性があります。

よくある質問

Home Assistantのユーザーアカウント20個は、同時利用ユーザー20人と同じですか?

いいえ。アカウントは識別情報であり、同時利用数はアクティブなクライアント接続と、それらのクライアントが発生させる処理によって決まります。1人のユーザーが複数のクライアントを使用することもあれば、多数のアカウントが完全にアイドル状態であることもあります。

ダッシュボードを簡素にすれば、常により多くのユーザーを接続できますか?

クライアント側の描画処理は軽減できますが、サーバーの容量はエンティティの更新頻度、WebSocket通信、履歴クエリ、カメラ、ネットワーク経路、バックグラウンドサービスにも左右されます。ワークロード全体を測定してください。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.