Home Assistantとインターネット障害に備えたホームサーバーの適切なサイズの選び方

Home Assistantのプロセスだけでなく、保護対象となるローカル制御経路全体を、家庭で乗り切る必要のあるインターネット障害と停電の条件に合わせて設計してください。

停電時にも照明、空調、漏水対応、入退室の自動化が重要な家庭では、サーバーが担う役割はその一つにすぎません。ローカルスイッチ、Wi-Fiまたは無線コーディネーター、永続ストレージ、バッテリー電源、復旧可能な設定を連携させて維持する必要があります。必要なクラウドAPI、保護されていないルーター、予測できない再起動動作などが、コンピューティング能力より先にワークフローを妨げるなら、その設計は停電への備えができているとは言えません。

停電時の合格基準を定める

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

停電への備えについてのコミュニティでの議論では、デバイスのローカル制御と、何に電力が供給され続けるかという、より広い問題が区別されています。その不確実性こそが、検討を始めるべき点です。重要なアクションと、それらが依存するネットワークやクラウド、手動での代替手段を洗い出してください。「Home Assistantをオンラインに保つ」という一般的な要件だけでは、トポロジーを決めるには不十分です。

各ワークフローを「継続必須」「性能低下を許容」「安全に停止可能」に分類します。漏水バルブや暖房の安全装置は、履歴グラフ、リモート通知、音声クエリより優先される場合があります。保護対象の構成に必要なのは、「継続必須」のセットと復旧用の余裕分だけです。任意の処理は一時停止するか、重要なホストの外に移せます。

重要なワークロードからコンピューティング能力を決める

WANを切断し、最も負荷の高いローカルイベントシーケンスを実行して、コア自動化ワークロードを測定します。CPUの継続負荷とピーク負荷、メモリプレッシャー、ストレージの待ち時間、応答レイテンシを記録してください。データベースと、保護対象のアクションに必要なアドオンだけを含めます。これにより、デバイス数ではなくサービスに基づくサーバーのベースラインが得られます。

停電要件に明示的に含まれていない限り、ローカル音声モデル、カメラ推論、メディア処理、バックアップの圧縮は、保護対象の経路から外してください。同じホストを共有する場合は、リソース制限やスケジューリングを使い、最悪の重なりが起きる状況を再現します。ピーク負荷によって重要なアクションが合格基準を満たせない場合に限り、サービスを分離してください。

アップデート、レコーダーのメンテナンス、拡張に備えて余裕を持たせますが、根拠なくプロセッサーのグレードを上げて余裕を確保してはいけません。実測した重要な処理シーケンスが応答性を保ち、再起動の動作が予測可能であれば、そのホストの性能は十分です。未使用の処理能力によってアイドル時の消費電力やUPSの負荷が増えても、具体的な障害への対策にならないなら、現在の役割に対して過剰な性能です。

保護対象の電源・ネットワーク経路を1本構築する

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

ある利用者はネットワーク機器、ストレージ、Home Assistantサーバーを小型UPSで保護し、数分以内にサーバーをシャットダウンする一方、ネットワーク機器はより長く使えるようにしていると説明しています。時間は設置環境によって異なりますが、役割分担は参考になります。コンピューティング機器は安全にシャットダウンしつつ、ローカル通信経路は引き続き利用できる状態に保てます。

コンセントにつながる機器全体の負荷を測定し、目標稼働時間を設定して、通常のピーク稼働時にテストします。ホストが停電中も稼働し続けるのか、安全にシャットダウンするのか、電力復旧後に再起動するのかを定めます。UPSにまだ電力が残っている間に電力が復旧しても復旧できない設計は避けてください。このケースでは、バッテリーに余力があるのにサービスがオフラインのままになることがあります。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

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

構成と稼働中のレコーダーデータベースは、保護対象のホストとともに起動する、監視対象の永続ストレージに置きます。復旧用コピーは、そこに障害が起きてもローカル自動化の起動を妨げない別の保存先に置きます。NASは有効なバックアップ先になり得ますが、コアサービスの意図しない必須要件にしてはいけません。

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

許容できるデータ損失量に基づいてバックアップ頻度を決め、最近のバックアップを別のメディアまたは予備のマシンに復元してください。別の家庭管理者もアクセスできる場所に、認証情報と手順を保管します。RAID、ミラーリングされたストレージ、または2つ目のパーティションは、同じ運用者とシステムの障害ドメインを共有するため、ホスト外のコピーの代わりにはなりません。

トポロジーを検証し、拡張の判断基準を設定する

WANを切断する、バックアップ先を利用できなくする、UPSの低バッテリー時の動作をシミュレートする、別のハードウェアに復元する、という4つの受け入れテストを実行してください。重要なオートメーション、シャットダウン、再起動、復元にかかる時間を測定します。グラフのエッジごとに障害を記録し、あらゆる箇所の容量を増やすのではなく、失敗した役割を改善するアップグレードを行いましょう。

ZimaSpaceのガイドウォームキャッシュ以外でHome Assistantのパフォーマンスを測定するでは、ウォーム状態でのテストを繰り返すと、コールドスタート時やピーク時の限界が隠れてしまう理由を解説しています。その方法を保護対象のワークロードに適用し、余裕のあるキャッシュ状態での実行結果だけを根拠にホストを拡張するのではなく、UPSの消費電力と復旧動作も比較しましょう。

他のボトルネックを除外した後も、実測した重要な処理の遅延が基準を満たさない場合は、計算能力を強化してください。経路全体の稼働時間が目標に届かない場合は、バッテリー容量を増やします。分離によって障害が解消する場合は、高負荷のサービスを分割してください。クラウド専用のデバイス、保護されていないネットワーク機器、または未検証の復元が最初の障害点として残っているなら、サーバーハードウェアの購入はやめましょう。

最終的な構成ルール

停電に備えた構成とは、家庭のWAN切断、バッテリー稼働時間、再起動、復元の各テストに合格する、保護された最小限のトポロジーです。実測でボトルネックとなった場合にのみ、計算能力、バッテリー容量、または分離を強化してください。クラウドへの依存や手動操作の不足が依然として支配的な場合は、Home Assistantサーバーを拡張する前にそちらを解消しましょう。