Home Assistantで別のデータベースまたはストレージ用ホストを使うべきタイミングとは？

Home Assistantで別のデータベースホストやストレージホストを使うのは、容量、保存期間、バックアップ、または障害ドメインに関する測定済みの問題が、その分離によって解決される場合に限るべきです。コントローラーからデータを移すことが、自動的にアップグレードになるわけではありません。

多くの家庭では、信頼性の高いSSDにローカルのSQLite Recorderデータベースを置くのが最も簡単です。ネットワーク、認証、DNS、データベースサーバーの起動への依存がなくなるためです。別のホストを用意する前に、実際の問題がRecorderの書き込み過多、長すぎる保存期間、遅い履歴クエリ、ローカル容量の不足、またはサービスを個別に復旧する必要性のどれなのかを特定してください。

データベースサーバーを追加する前にRecorderをチューニングする

Recorderの増加量は、保存するエンティティやイベント、その更新頻度、履歴の保存期間によって決まります。書き込みの大半をノイズの多いセンサーや不要なドメインが占めているなら、同じ負荷をより大きなデータベースサーバーに移しても、問題の解決ではなく移転にしかなりません。

最新のRecorderのチューニング手順では、データベースの移行を検討する前に、保存期間、対象に含めるルールと除外するルール、コミットの動作が書き込み負荷にどのように影響するかを確認できます。チューニング後に、データベースのサイズ、履歴のクエリ時間、ストレージのレイテンシ、書き込みの状況を測定してください。

チューニング後も負荷の高い処理に素早く応答でき、バックアップがメンテナンス時間内に完了し、SSDの空き容量にも余裕があるなら、データベースはローカルに置きましょう。分離するのは、クライアントサーバー型データベースのほうが常に高速だという一般論ではなく、要件を満たせない場合です。

運用上のメリットがある場合は外部データベースを使用する

Home Assistantがすでに適切に運用されているデータベースプラットフォームを共有する場合、長期保存によって継続的にクエリ負荷が高まる場合、コントローラーホストを軽量または交換可能な状態に保つ必要がある場合、あるいはデータベースのバックアップと監視を独立したライフサイクルで管理する必要がある場合は、MariaDB、MySQL、PostgreSQLの専用ホストを用意するのが適切なことがあります。

SQLiteからMariaDBへの移行例では、その選択によって新たに必要となる要素、すなわちデータベースサービス、認証情報、ネットワークアドレス、スキーマの初期化、移行手順、検証、ロールバックが示されています。より大規模な実例であるHome Assistantデータベース移行事例からは、長期間の履歴や大量のデータが、追加の管理作業に見合う理由がわかります。

ZimaSpaceの記事外部データベースのアップグレードの信頼性では、データベースは見えないインフラとして扱うのではなく、独立したサービスとしてバックアップ、アップグレード、復元する必要があるという、対応するメンテナンス上の境界について解説しています。

稼働中のSQLiteデータベースを、デフォルトでネットワーク共有に置かない

リモートデータベースサーバーと、SMBやNFSに保存されたデータベースファイルは、異なるアーキテクチャです。クライアントサーバー型データベースは、データベースサービス内でロックとトランザクションを実行し、ネットワーク経由でリクエストを送信します。SQLiteはファイルシステムを介してデータベースファイルをロックするため、ネットワークファイルシステムの動作、マウントの可用性、遅延、ロック動作がすべてのトランザクションに影響します。

より詳しいSQLiteのロックに関する分析では、ネットワークファイルシステムで、ローカルディスクとは異なるロック動作が発生する可能性がある理由を説明しています。Home Assistantのネットワーク共有での障害事例からは、稼働中のRecorderデータベースがリモートマウントに依存する場合の現実的なリスクがわかります。

バックアップ、エクスポート、メディアなど、ネットワークストレージ向けのデータにはNASを自由に活用できます。Recorderの稼働データを別のマシンに置く必要がある場合は、SQLiteファイルを共有ストレージに移すのではなく、サポートされているクライアントサーバー型データベースを選びましょう。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

大量ストレージは、Home Assistantの稼働状態データから分離する

増加しているHome Assistantのディレクトリを、すべて同じストレージ階層に置く必要はありません。設定、インテグレーションの状態、アクティブなRecorderデータベース、メディア、カメラのクリップ、エクスポート、バックアップでは、必要なレイテンシや復旧要件が異なります。別のサービスで意図的に管理していない限り、頻繁に更新される小さな状態データは低レイテンシのローカルストレージに置いてください。

大容量のメディアやバックアップ世代は、安定したマウントポイントを介してNASの容量に移します。マウントがなくてもHome Assistantを起動してよいかどうかを文書化してください。写真アーカイブが見つからなくても照明の自動化は起動できるべきです。一方、アクティブなデータベースが見つからない場合は、誰も気づかないままのフォールバックではなく、明示的な縮退状態にする必要があります。

分離を恒久化する前に、起動・障害・復元を実証する

新しいデータベースまたはストレージの役割を段階的に導入し、以前の復旧手段は削除しないでください。Home Assistantより先にデータベースホストを再起動する、データベースの準備が整う前にHome Assistantを再起動する、ネットワークを切断する、認証情報をローテーションする、対象ファイルシステムの空き容量を予約領域のしきい値近くまで使う、クリーンなインスタンスにデータベースを復元する、といったテストを行います。

履歴クエリ時間のp95、Recorderの負荷が高いときの自動化の遅延、再起動時間、バックアップ所要時間、データベースホスト停止後の復旧時間を測定します。分離によって一つの指標が改善しても、コントローラーの30秒での再起動が複数サービスにまたがる復旧手順になってしまうなら、その運用コストも判断に含めてください。

ローカルストレージで目標をすでに満たせているなら、そのまま使いましょう。クライアント・サーバー型データベースの処理や独立した復旧に明確な利点がある場合は、データベースホストを分けます。大容量データやバックアップには専用ストレージホストを使います。ただし、検証済みの理由がない限り、重要なローカル制御をリモートファイルシステムに依存させないでください。