Home Assistantの更新動作：スキーマとキャッシュの変更が起動に及ぼす影響

エヴァ・ウォン

IceWhale author

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

Home Assistant Update Behavior: Why Schema and Cache Changes Affect Startup

Home Assistantは、スキーマの移行、キャッシュの再構築、統合の再初期化によって通常動作の前に一度限りの処理が追加されるため、アップデート後に起動が遅くなることがあります。

通常の再起動では、使い慣れた設定をほぼ再読み込みし、既存のデータを開くだけです。しかし、バージョンが変わると、それらの前提が変わる場合があります。CoreはRecorderのスキーマを更新したり、生成済みアーティファクトを無効化したり、変更された依存関係を読み込んだり、統合機能に内部状態を再構築させたりすることがあります。遅延は一時的なことが多いものの、移行の停止、低速なディスク、互換性のない統合機能によって、想定された初回起動処理が実際の障害に発展する可能性があります。

アップデートによって永続データの仕様が変わることがある

Home Assistantの各バージョンが、保存されたデータを常に同じように解釈するとは限りません。Recorderのテーブル、インデックス、レジストリ、または統合機能の保存形式が変わると、すべての利用側が新しい形式を安全に使えるようになる前に、起動時に古い表現を変換する必要があります。

アップグレード後、データベースの変換が長時間続いた事例が利用者によって報告されています。これは、スキーマ変換処理が無関係なバックグラウンドタスクではなく、起動処理の一部である理由を示しています。

影響を受けるデータ量と書き換えられるインデックスの数が多いほど、処理コストは増大します。バージョン変更を伴わない再起動ではこの変換が行われないため、それとアップデート後の初回起動を比較すると、変化した処理量が見えなくなります。

キャッシュの無効化により、通常の再起動では再利用される処理が繰り返される

キャッシュには、コード、フロントエンドのバンドル、依存関係、以前に取得したデータに関する前提が記録されています。アップデートによってこれらのアーティファクトが意図的に無効化されると、サーバー、ブラウザー、プロキシ、または統合機能がそれらを再度ダウンロード、解析、コンパイル、デコードしなければならない場合があります。

データの読み込み中に停止したように見えたアップデート後の事例は、アップデート後の初期化が統合機能の初期化と重なり、プロセスの起動から最初に操作できる画面が表示されるまでの時間を長引かせる可能性を示しています。

再構築されたアーティファクトやファイルシステムのページがキャッシュに載るため、その後の起動は速く見えることがあります。この改善から分かるのは、繰り返し発生する処理が回避されたということだけであり、新しいバージョンが定常的な負荷の下で必要とするリソースが少ないことを示すものではありません。

ストレージの遅延によって移行と再構築の時間が増幅される

スキーマの変更やキャッシュの作成では、多数の読み取り、書き込み、同期、メタデータ操作が行われます。正常なSSDなら短時間で完了する処理でも、SDカード、空き容量がほとんどないディスク、負荷の高い仮想ボリューム、リモートデータベースでは、同じ論理処理に何分もかかることがあります。

あるアップグレード失敗の報告では、表示上の起動問題の原因がデータベース移行にあることが判明しました。これは、移行失敗の証拠をスプラッシュ画面だけで判断せず、データベースやストレージのログと照合する必要があることを示しています。

CPU使用率が低いまま、ストレージのキュー深度だけが上昇することもあります。データベースで移行が報告されず、ディスクも応答し続けている場合、ストレージ処理の増幅では説明できません。その場合は、統合機能のセットアップやネットワークのタイムアウトが有力な候補になります。

-15% OFF

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

Single board computer zimaboard2

進行が止まったり、データが安全でなくなったりした時点で、想定内の遅延ではなくなる

ログに名前付きの移行処理が進行していることが示され、空き容量も安定しているなら、初回起動に長時間かかるのは正当な場合があります。一方、クラッシュの繰り返し、変化しない移行ステップ、データベース破損のメッセージ、ボリュームの容量不足は別の状態です。待ち続けても不確実性が減らないためです。

Recorderの移行に失敗した事例は、移行の繰り返し失敗が、破損したストレージへの書き込みをさらに増やす再起動の反復ではなく、有効なバックアップからの復旧を必要とする場合があることを示しています。

ここが失敗と判断する境界です。測定可能な前進がある間は監視しますが、エラーが繰り返される、容量を使い切る、または文書化されたアップグレード手順が失敗した場合は、処理を停止してください。修復を試みる前に、データベースとログを保存します。

初回起動と定常状態を分けて測定する

アップデート前のデータベースサイズ、空き容量、バージョン、シャットダウン時間、通常の再起動時間を記録します。アップデート中は、プロセスの開始、移行メッセージ、統合機能の完了、最初のダッシュボード応答、安定した操作が可能になった時点のタイムスタンプを取得します。

関連するアップデート後の再処理では、既存データが再び処理されることがある理由を説明しており、全区間を単なる起動時間として扱うのではなく、それぞれの時刻に具体的な仕組みを対応付けられます。

一度限りの処理が完了し、2回目の再起動が通常に近い時間へ戻り、履歴が読み取れ、無害なローカル操作が機能するなら、アップデートを受け入れて構いません。進行が止まった場合や整合性チェックに失敗した場合にのみ、ロールバックまたは復元を行います。進行中ではあるものの遅い初回起動だけを、ロールバックの唯一の判断材料にしないでください。