Home Assistantに専用のコンピューティング、ストレージ、ネットワークが必要になるのはどんなとき？

制御レイテンシ、容量、復旧時間、依存関係による障害が明確なサービス目標の範囲内にある間は、Home Assistantを1台のホストで運用しましょう。

特定のワークロードが制御処理の余力を奪う場合はコンピューティングを、稼働中のデータと大容量データで必要なレイテンシや復旧方針が異なる場合はストレージを、共有ネットワーク経路が実証済みの障害ドメインを生む場合はネットワークを分離しましょう。分離するたびにマシン、接続、認証情報、起動順序、バックアップ対象が増えるため、ほかのものを移す前に新たな境界を検証してください。

測定可能な限界が現れるまでは役割をまとめておく

単一のホストなら、Home Assistant Core、データベース、無線機器、アドオン、バックアップ、監視をまとめて、既知の1つのシステムとして起動・復旧できるほど近くに保てます。統合したワークロードが、アクションレイテンシのp95、再起動時間、バックアップ時間枠、ストレージの予備容量、復元目標を満たしている間は、このシンプルさが大きな価値を持ちます。

高可用性に関する議論では、ノードを増やしてもアプリケーションレベルの可用性が自動的に実現するわけではないことが繰り返し示されています。コミュニティによるHome Assistantの障害ドメインの限界に関する分析は、単に別のマシンを稼働させることと、サービスの状態や無線デバイスの管理主体を区別している点で参考になります。

平均使用率が低いから、あるいは将来への一般的な備えとして、分離してはいけません。監視によって、特定のリソース、容量、メンテナンス時間、または障害がサービス目標の未達につながっていると確認できた場合にのみ、構成変更を検討しましょう。

1つのワークロードが制御処理の余力を奪う場合はコンピューティングを分離する

動画解析、ローカル音声処理、モデル推論、コンパイル、負荷の高いデータベース処理など、分離可能な補助サービスがCPU、メモリ、または熱容量を飽和させ、同時に重要なオートメーションが遅延または失敗する場合は、専用のコンピューティング環境が妥当です。

Home Assistantを反射的に移すのではなく、まず負荷の大きいサービスを移しましょう。APIエンドポイント、認証情報、タイムアウト、フォールバック動作を維持してから、同じ混合ワークロードを再度実行します。イベント発生から動作までのレイテンシと復旧余力が改善すれば、測定された競合の境界を分離できたということです。

リソースのピークと遅延が連動しない場合や、遅い経路の原因が無線、クラウド、DNS、クライアント、ストレージのレイテンシにある場合は、コンピューティングをまとめておきましょう。新しいホストを導入しても、自分が管理していない依存関係は解決できません。

容量や復旧のライフサイクルが異なる場合はストレージを分離する

アクティブな設定とRecorderの状態に低レイテンシと整合性のあるスナップショットが必要で、メディア、テレメトリーのエクスポート、バックアップ世代には低コストの容量と異なる保持期間が必要な場合は、ストレージを分離してください。デバイスやプールを変更してもアプリケーションのパスが維持されるよう、安定した論理マウントを使用してください。

Docker Composeの設計レビューでは、永続ボリューム、ネットワークモード、バックアップ境界を明確にすることが重視されます。その永続ストレージ設計のトレードオフは、分離する際には単にデータを移動するだけでなく、権限と復元順序も維持する必要があることを示しています。

NASへの依存関係を作る前に、内部のメタデータ増加の境界を使って、容量の問題の原因がアクティブな状態、履歴、一括データのどれなのかを特定してください。

Featured

ZimaCube 2 パーソナルクラウド ホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

実証済みの共有障害を取り除く場合に限ってネットワークを分割する

ブロードキャスト負荷、アドレス枯渇、スイッチ障害、RF干渉、デバイスの信頼性の低さ、または必須のメンテナンス時間によって、現在の設計では許容できない停止が発生する場合は、ネットワークに専用のハードウェアまたはセグメントを割り当てる価値があります。セグメンテーションによって、ルーティング、ファイアウォール、マルチキャスト、DNS、検出への依存関係も増えます。

セキュリティ境界を維持できる最小限の経路で、Home Assistant、無線機器、重要なローカルデバイスに引き続きアクセスできるようにしてください。VLANや専用スイッチを導入する場合は、必要な検出および制御トラフィックを明示的に許可し、ルーティング、インターネット、またはDNSが利用できない場合に何が動作するかを文書化してください。

必須ではないネットワーク依存関係を1つずつ取り除いた状態で、ローカル操作、再起動、検出、通知、復旧の各テストに合格するまでは、セグメンテーションを信頼できるとは見なさないでください。

別の役割を移動する前に、新しい境界を検証する

最新のバックアップとロールバック手段を用意し、分割は一度に1つずつ段階的に実施してください。移行の前後で、ソースのバージョン、サービスの識別情報、エンドポイント、マウントの所有権、ファイアウォールのルール、起動順序、レイテンシ、リソース負荷、バックアップ所要時間、復元所要時間を記録してください。

1. 混雑する時間帯のワークロードを再現してください。
2. 依存関係を1つ取り除き、低下した動作を記録してください。
3. 影響を受ける各サービスを、依存関係の順序に従って再起動してください。
4. クリーンなターゲット上に、変更した役割を復元してください。
5. 文書化されたメンテナンス時間内にロールバックしてください。

専用の境界を設けるのは、ネットワークとライフサイクルのリスク増加を上回るほど、明示した目標の改善につながる場合に限ってください。次の変更を開始できる独立した測定結果が得られるまでは、残りの役割をまとめておいてください。