Home Assistantとインターネット障害に適したホームサーバーのサイズ選び

エヴァ・ウォン

IceWhale author

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

How to Size a Home Server for Home Assistant and Internet Outages - Zima Store Online

家庭が耐える必要のある、具体的なインターネット障害と停電に対して、Home Assistantのプロセスだけでなく、保護されたローカル制御経路全体の規模を決めます。

照明、空調、漏水対応、アクセス自動化などが障害時にも重要な家庭では、サーバーは役割の一つにすぎません。ローカルスイッチング、Wi-Fiまたは無線コーディネーター、永続ストレージ、バッテリー電源、復旧可能な設定を連携させておく必要があります。必要なクラウドAPI、保護されていないルーター、または不明確な再起動動作によって、コンピュート容量より先にワークフローが停止するなら、その設計は障害対応可能とはいえません。

障害受容目標を定義する

ISP障害と電力障害を分けて考えます。ISPが停止しても、LANは正常なままで、ローカルデバイス同士の通信を継続できる場合があります。停電では、ホスト、ルーター、スイッチ、アクセスポイント、コーディネーター、NAS、アクチュエーターが一斉に停止する可能性があります。それぞれの障害に対して、継続時間と許容できる機能低下を個別に設定します。

停電対策に関するコミュニティでの議論では、ローカルデバイスの制御と、何に電力を供給し続けるかという広い問題が区別されています。この不確実性を出発点にするのが適切です。重要な操作、そのネットワークおよびクラウド依存関係、手動での代替手段を洗い出します。「Home Assistantをオンラインに保つ」という一般的な要件だけでは、トポロジーの規模を決めるには不十分です。

各ワークフローを「継続必須」「機能低下可」「安全に停止可」に分類します。漏水バルブや暖房の安全制御は、履歴グラフ、リモート通知、音声クエリより優先される場合があります。保護対象の構成に必要なのは、継続必須の処理と復旧マージンだけです。オプションの処理は停止するか、クリティカルなホストの外へ移せます。

重要なワークロードからコンピュートを規模決定する

WANを切断し、最も負荷の高いローカルイベントシーケンスを実行した状態で、主要な自動化ワークロードを測定します。CPU使用率の継続値とピーク値、メモリ圧迫、ストレージ待ち時間、応答遅延を記録します。データベースと、保護対象の操作に必要なアドオンだけを含めます。これにより、デバイス数ではなくサービスに紐づいたサーバー基準値を得られます。

障害要件に明示的に含めない限り、ローカル音声モデル、カメラ推論、メディア処理、バックアップの圧縮は保護経路から外します。同じホストで実行する場合は、リソース制限やスケジューリングを設定し、最悪の重複負荷を再現します。ピーク負荷によって重要な操作が受容目標に間に合わなくなる場合に限り、サービスを分離します。

更新、レコーダーのメンテナンス、将来の増加に備えて余裕を加えますが、余裕を根拠のないプロセッサー上位モデルの選択理由にしてはいけません。測定した重要なシーケンスが応答性を保ち、再起動動作が予測可能であれば、ホストの規模は十分です。未使用の容量がアイドル時の消費電力やUPS負荷を増やすだけで、具体的な障害を減らさないなら、現在の役割に対して過大です。

保護された電源とネットワークの経路を一つ構築する

センサーまたはダッシュボードから、無線またはWi-Fi、ローカルスイッチング、Home Assistant、アクチュエーターまでの経路を一つ描きます。必要なすべてのネットワーク機器とホストを、測定済みのUPS接続回路に配置します。サーバーだけにバッテリーを接続しても、ルーター、スイッチ、アクセスポイント、コーディネーターが停止すれば制御は維持できません。

ある運用者は、小型UPSでネットワーク機器、ストレージ、Home Assistantサーバーを保護し、数分以内にサーバーをシャットダウンして、ネットワーク機器をより長く稼働させる方法を説明しています。時間は設置環境によって異なりますが、役割分担は有用です。コンピュートは安全に停止しながら、ローカル通信経路は引き続き利用できる可能性があります。

コンセント全体の負荷を測定し、目標ランタイムを選び、通常のピーク動作時にテストします。ホストを稼働させ続けるのか、安全にシャットダウンするのか、復電後に再起動するのかを定義します。UPSにまだ充電が残っている状態で復電した場合に復旧できない設計は採用しないでください。このケースでは、健全なバッテリーがオフラインのサービスを保護し続けることになるためです。

イベント	保護する役割	受容テスト
ISP障害	ホスト、LAN、無線、ローカルデバイス	WAN切断ワークフローに合格
短時間の停電	重要な経路とUPS	測定ランタイムが目標を上回る
長時間の停電	安全なシャットダウンと手動操作	シャットダウンおよび再起動シーケンスに合格

-15% OFF

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

Single board computer zimaboard2

稼働中の状態と復旧用コピーを分離する

設定と稼働中のレコーダーデータベースは、監視対象の永続ストレージに保存し、保護されたホストと同時に起動するようにします。復旧用コピーは、そこが失われてもローカル自動化の起動を妨げない別の保存先に置きます。NASは有効なバックアップ先になり得ますが、コアサービスにとって意図せぬ必須要件にならないようにします。

報告されたHome AssistantとSynologyの障害シーケンスでは、両システムがUPSイベント時にシャットダウンしたものの、UPSが完全に放電する前に復電しても自動的には起動しませんでした。この事例は、ストレージ、ホスト、電源の復旧を一つのシーケンスとしてテストする必要性を示しています。各コンポーネントが個別には正しくても、サービスが利用できない結果になる可能性があります。

許容できるデータ損失量からバックアップ頻度を決め、最近のコピーを別のメディアまたは予備マシンに復元します。認証情報と手順は、別の家庭内管理者も確認できる場所に保管します。RAID、ミラーリングストレージ、別パーティションは、同じ運用者およびシステム障害ドメインを維持するため、ホスト外のコピーの代わりにはなりません。

トポロジーを検証し、拡張の条件を設定する

4つの受容テストを実行します。WANを切断する、バックアップ先を利用不能にする、UPSの低バッテリー動作をシミュレートする、別のハードウェアに復元する、の4つです。重要な自動化、シャットダウン、再起動、復元にかかる時間を測定します。障害をグラフのエッジごとに記録し、容量を全体的に追加するのではなく、アップグレードによって障害が発生した役割を変更できるようにします。

ZimaSpaceのウォームキャッシュを超えてHome Assistantの性能を測定する方法に関するガイドでは、ウォーム状態でのテストを繰り返すと、コールドスタートやピーク時の限界が隠れる理由を説明しています。その方法を保護対象のワークロードに適用し、快適なキャッシュ状態での結果だけを基にホストを大型化するのではなく、UPSの消費電力と復旧動作も比較します。

他のボトルネックを除外した後も、測定した重要な遅延が基準を満たさない場合は、コンピュートを拡張します。経路全体のランタイムが目標に届かない場合は、バッテリー容量を増やします。分離によって障害が解消する場合は、負荷の高いサービスを分割します。クラウド専用デバイス、保護されていないネットワーク機器、テストされていない復元が最初の障害点として残っているなら、サーバーハードウェアの購入を止めます。

最終的な構成ルール

障害対応可能な規模とは、家庭のWAN喪失、電源ランタイム、再起動、復元の各テストに合格する、最小限の保護トポロジーです。コンピュート、バッテリー、分離は、測定によって該当するエッジの障害が確認された場合にのみ増強します。クラウド依存や手動操作の不足が依然として主要な問題なら、Home Assistantサーバーを拡張する前に、まずそれらを解決します。