Home Assistantのキャッシュと一時ストレージの設定方法

Home Assistantのキャッシュを設定する際は、まずどのデータが破棄可能かを特定してください。永続的な設定パス全体を一時ストレージに移動してはいけません。

「キャッシュ」は、ブラウザーフロントエンドのアセット、TTSの出力、インテグレーション固有の一時ファイル、コンテナの/tmp、オペレーティングシステムのページキャッシュ、データベースの作業領域などを指す場合があります。これらの層は、所有者も復旧時の動作も異なります。ユーザー、レジストリ、設定、Recorderの状態など、権威あるファイルは耐久性のあるストレージに保管してください。tmpfsやRAMベースのストレージは、消失の影響とメモリ使用量を再起動を通じてテスト済みの、仕様が明確な破棄可能パスに限って使用してください。

パスを移動する前にキャッシュを分類する

まず、データの所有者、パス、想定される最大サイズ、再構築方法、データが消えた場合の影響を明確にしましょう。ブラウザーのキャッシュはクライアント上にあります。Home Assistantの永続的なアプリケーション状態は、設定されたデータパスの下にあります。インテグレーションのキャッシュはそれぞれ異なり、一時的なコンテナファイルは再起動時に消えることがあります。これらを単一のグローバルな「キャッシュディレクトリ」設定で解決しようとしてはいけません。

Home AssistantのTTSの事例では、特定のキャッシュパスにある生成済み音声を、意図的にRAMベースの場所へリダイレクトした限定的な例が示されています。破棄可能なTTSキャッシュの移動で重要なのは、ユーザーが再生成可能なディレクトリだけを対象にし、設定ツリー全体は移動していない点です。

ファイルが消えても、識別情報、履歴、設定、ダッシュボード、インテグレーションの登録情報が失われないと証明できない場合は、永続データとして分類してください。最も安全なデフォルトは耐久性のあるストレージです。最適化は、復旧の責任範囲が明確になってから行いましょう。

永続的なHome Assistantの状態とRecorderは耐久性のあるストレージに保管する

設定のマウント先は、生成ファイルが含まれているからといってキャッシュになるわけではありません。認証情報、エンティティとデバイスのレジストリ、自動化の状態、設定、カスタムコンポーネント、デフォルトのRecorderデータベースなどが含まれる場合があります。そのパス全体をtmpfsに置くと、再起動時にデータが失われ、権威あるデータとして扱う想定のないメモリ上の内容にバックアップが依存することになります。

ZimaSpaceによるHome Assistantの永続データの役割の説明は、最初の判断基準として適切です。ストレージ階層を割り当てる前に、権威ある状態データと、再生成可能なキャッシュや一時作業データを分けましょう。

アプリケーションの状態にはSSDなどの信頼性の高い永続ファイルシステムを使用し、データベースの拡大、アップグレード、メンテナンスに十分な空き容量を確保してください。小さな破棄可能キャッシュをRAMに移しても、永続ボリュームの容量不足や故障を補うことはできません。

明示的に破棄可能なパスに限り、メモリ上限を設けてtmpfsを使用する

tmpfsは書き込みを減らし、非常に低いレイテンシを実現できますが、ホストのRAMを消費し、コンテナまたはホストの停止時に消失します。そのため、容量を制限したスクラッチデータには適していますが、再起動後に必要なデータには適していません。また、一時的な処理によってHome Assistant Coreや隣接するサービスに必要なメモリが使い果たされないよう、マウントのサイズを調整する必要があります。

最新のDocker Composeガイドでは、tmpfsの使用量はメモリ容量に算入されると説明されています。コンテナのメモリ予算に対してサイズが大きすぎる、または上限がない場合、容量不足やOOMが発生することがあります。

サイズの上限を設定し、ピーク使用量を監視して、意図的にコンテナを再起動してください。ユーザー、設定、履歴、インテグレーションに変更がないまま、パスの内容が自動的に再生成されるはずです。アプリケーションがディレクトリを再構築できない場合や、その不在を破損として扱う場合は、永続ストレージに戻してください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

フロントエンドキャッシュはサーバーストレージではなく、クライアント側の問題として扱う

サーバーが正常でも、フロントエンドのリソースがブラウザーやアプリにキャッシュされているため、1つのブラウザーで古いHome Assistantのページが表示され続けることがあります。サーバー側の一時ファイルを消去しても、そのクライアントの状態は修正されません。逆に、ブラウザーのキャッシュを消去しても、RecorderのディスクI/Oは減らず、Home Assistantのデータベースも小さくなりません。

Home Assistantのユーザーはフロントエンドキャッシュをブラウザーキャッシュとして明確に区別しています。そのため、キャッシュのトラブルシューティングでは、症状が1台のクライアントだけにあるのか、サーバー全体にあるのかを特定することから始めるべきです。

検証用の環境として、クリーンなブラウザーまたはプライベートプロファイルを使用してください。新しいクライアントが正常なら、フロントエンド側で修正してください。すべてのクライアントで同じデータ欠落やサーバー側エラーが発生する場合は、ローカルキャッシュの消去を繰り返さず、Home Assistantのログ、ストレージ、インテグレーション、またはデータベースのトラブルシューティングに戻ってください。

再起動、メモリ負荷、空き容量のテストで一時ストレージを検証する

キャッシュまたはtmpfsのパスを変更した後は、通常時とピーク時のサイズ、ホストで利用可能なメモリ、コンテナのメモリ負荷、永続ボリュームの空き容量、再起動時の動作を測定してください。その後、キャッシュを生成する処理（TTS、メディア、カスタムインテグレーションの処理、またはその他の既知の生成元）を実行し、想定どおりにクリーンアップされることを確認してください。

日々のデータベース容量に十分な余裕があっても、一時的な作業領域を必要とする処理に備え、永続ストレージに余裕を残してください。RAMキャッシュによって通常の書き込み量が少なく見えるからといって、永続ボリュームをいっぱいにしないでください。アップグレード、データベースのメンテナンス、バックアップ、ログの急増では、一時領域の必要量が大きく異なることがあります。

すべての使い捨てパスが消えても再構築でき、永続データがコンテナとホストの再起動後も保持され、tmpfsのピーク使用量がメモリ予算内に収まり、Home Assistantに十分な永続ストレージの空き容量がある場合に合格です。テスト後に必須の設定や履歴が消えていた場合は、そのパスの分類が誤っているため、調整を続ける前に永続ストレージへ戻してください。