リソース分離によってマルチアプリ対応ホームサーバー上のHome Assistantの結果がどう変わるか

複数のアプリを稼働させるホームサーバーでは、Home Assistant自体を変更しなくても、Home Assistantの動作が速くなったり遅くなったりすることがあります。コンテナはプロセスとファイルシステムを分離しますが、ホストがリソース制御を適用しない限り、ホストのCPU時間、メモリ、ページキャッシュ、ストレージキュー、ネットワーク帯域を互いに奪い合います。

リソース分離によって結果が変わるのは、処理が重なる際に、共有リソースの余力をどのワークロードが利用できるかが変わるためです。重要なのは、Home Assistantに「専用マシンが必要か」ではありません。測定可能なノイジーネイバーのワークロードを、より厳しいレイテンシー目標を持つサービスを壊すことなく制限できるかどうかです。

コンテナはデフォルトではリソースを予約しない

Dockerコンテナは、制限や重み付けが設定されていない限り、ホストの余っているリソースを自由に使用できます。これにより、ワークロードのピーク時間が異なる場合、共有サーバーを効率的に利用できます。しかしその一方で、AIジョブ、メディアスキャン、データベースのコンパクション、バックアップによって、Home Assistantのレイテンシーが突然変化することもあります。

Dockerの現行のリソース制御ドキュメントでは、コンテナにはデフォルトでリソース制約がなく、メモリ、CPU、その他の関連する制御によって上限を設定できると説明されています。したがって、分離はコンテナ化に自動的に備わる性質ではなく、明示的なポリシーです。

最初から根拠のないハードリミットを設定するのは避けましょう。まず共有環境でピーク時の状態を再現し、Home Assistantに症状が現れたとき、どのリソースが制約されているのかを特定してください。

CPUの重み付けと制限は、バースト時に誰が待つかを変える

CPUシェアまたはcgroupの重み付けは、ホストがビジーなときに競合するグループがCPUをどのように分け合うかに影響し、ハードクォータは上限を設けます。これらの制御により、他のサービスがすべてのコアを使い切ってしまう場合でも、レイテンシーに敏感な制御プレーンを保護できます。

Linuxのcgroup v2では、重み付け、制限、保護、割り当てが、それぞれ異なるリソース分配モデルとして定義されています。重み付けを設定すると、ワークロードはアイドル状態のCPUを借りられますが、競合時の取り分が変わります。制限を設定すると、構成した上限を超えられなくなります。

この違いはHome Assistantにとって重要です。優先度の低いバッチサービスには、サーバーが空いているときに不必要なスロットリングを発生させず、より低いCPUの重み付けを設定できます。同じサービスが繰り返し利用可能な計算能力をすべて消費し、制御レイテンシーを発生させる場合は、ハードリミットのほうが適しています。

メモリ分離はキャッシュと回収の動作を変える

メモリの逼迫は、CPUクォータよりも複雑です。ホストは匿名アプリケーションメモリとファイルシステムキャッシュの両方にRAMを使用するため、どちらのプロセスもクラッシュしていなくても、一方のコンテナが別のワークロードが再利用していたページを間接的に追い出すことがあります。

cgroup v2には、memory.lowのようなソフト保護や、memory.maxのようなハード上限など、メモリ保護と制限の仕組みがあります。リクレーム、スワップ、OOMの動作を観察してから使用してください。継続的なリクレームを強いるメモリ上限は、保護するどころかレイテンシーを増加させる可能性があります。

Home Assistantでは、通常のCore、Recorder、フロントエンドの動作に必要なワーキングセットとキャッシュの余裕を確保し、オプションの隣接ワークロードにより厳しい制限を適用することが目標です。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

すべてのアプリが同じSSDやHDDを使用する場合、I/O分離が重要になる

バックアップ、トレントの移動、VM、NVR、データベースジョブによって、Home Assistantのアプリデータを保存している同じストレージデバイスが飽和することがあります。CPUがほとんどアイドル状態でも、Recorderのコミットや履歴の読み取りが、無関係な書き込みの後ろで待たされる場合があります。

Dockerランタイムのメトリクスでは、コンテナごとのCPU、メモリ、ネットワーク、ブロックI/Oのカウンターを確認でき、制限を適用する前に負荷の原因を特定するのに役立ちます。インタラクティブな遅延はデータ量だけでは表せないため、これらの測定値をデバイスのレイテンシーやキュー深度と合わせて使用してください。

書き込み負荷の高いコンテナを一時停止するとHome Assistantのレイテンシーがすぐに回復する場合、CPUコアを追加するよりも、ストレージの分離やスケジューリングを検討するほうが合理的です。

分離は、アプリ間で実際に共有されているリソースに従って行う

ZimaSpaceによるAIと家庭向けデータワークロードの混在に関する解説は、ホームサーバー上で、レイテンシーとリソース要件が大きく異なるジョブを扱う機会が増えている理由を示しています。制御プレーンは予測可能な応答性から恩恵を受け、AIやインデックス作成はスループットからより大きな恩恵を受けることが多くあります。

すべてのサービスを、あらゆる面で分離する必要はありません。測定された競合がストレージにあるなら、ストレージのスケジューリングや配置を見直してください。CPUが原因なら、CPU制御を使用します。問題が夜間の重複に限られるなら、恒久的なリソース予約よりもスケジュール変更のほうが簡単かもしれません。

分離をA/Bテストとして使用する

リソース分離は、1つの制御された変更によって、同じHome Assistantのワークロードが繰り返し改善される場合に有効です。結果が変わらないなら、制限した共有リソースはおそらく容量のボトルネックではありません。