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

エヴァ・ウォン

IceWhale author

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

How to Configure Home Assistant Cache and Temporary Storage - Zima Store Online

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

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

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

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

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

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

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

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

サーバーが正常でも、ブラウザーやアプリがフロントエンドリソースをキャッシュしているため、Home Assistantの古いページが特定のブラウザーに残ることがあります。サーバー側の一時ファイルを削除しても、このクライアント側の状態は解決しません。逆に、ブラウザーキャッシュを削除しても、RecorderのディスクI/Oが減ったり、Home Assistantのデータベースが小さくなったりすることはありません。

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

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

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

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

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

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