開発者はデータベースをコンピュートノードとストレージノードのどちらに置くべきか？

基本的には、稼働中のデータベースファイルをコンピュートノードの近くにある低レイテンシストレージに置き、ストレージノードはバックアップ、ダンプ、レプリカ、アーカイブに使いましょう。

ただし、ストレージノードが、意図的に設計されたブロックストレージ経路、実測済みのレイテンシ、適切な耐久性の保証を提供し、増える依存関係に見合う復旧上のメリットがある場合は、基本方針が変わります。判断基準は単にローカルかネットワーク経由か、あるいは容量だけではありません。トランザクションログ、データファイル、バックアップ、アプリケーションのアップロードデータ、破棄可能なテストデータベースでは、書き込みパターンも障害時の影響も異なります。

データベースの状態とダンプ・バックアップを分ける

ノードを選ぶ前に、データベース関連のパスをすべて洗い出しましょう。プライマリデータディレクトリとトランザクションログは稼働中の状態を保持するため、書き込み順序の一貫性と予測可能なレイテンシが必要です。論理ダンプ、ベースバックアップ、アーカイブログ、エクスポート、アプリケーションにアップロードされたファイルはアクセスパターンが異なるため、多くの場合、安全にネットワーク経由で扱えます。

NAS共有を1つマウントして、その中にすべてを置くのはやめましょう。稼働中のデータベースボリュームは、バックアップ先や大容量のアプリケーションデータと分けてください。そうすれば、永続化するデータすべてに同じストレージが必要だと決めつけずに、それぞれの用途に合わせて調整、監視、容量管理、スナップショット作成、復元、移行ができます。

短期間だけ使うブランチデータベースやCIテストでは、耐久性より再構築にかかる時間が重要な場合があります。こうしたデータは高速なローカルの一時ストレージに置き、マイグレーションやサニタイズ済みのシードデータから再作成しましょう。開発者が日常的に使うサービスのデータベースでは、ローカルSSDの故障を復旧イベントとして扱い、定めた目標復旧時点を満たせるよう、リモートコピーを最新の状態に保ちましょう。

ノードを選ぶ前に書き込み経路を測定する

データベースのパフォーマンスは、シーケンシャルスループットだけで決まるわけではありません。同期コミットのレイテンシ、ランダム読み取りと書き込み、バックアップトラフィック発生時のキュー深度、ネットワーク経路が停止したときの挙動を測定しましょう。10GbEリンクでは大容量ファイルをすばやく転送できても、すべてのトランザクションにレイテンシと新たな障害要因が加わることがあります。

公開されたPostgreSQLの比較では、テスト対象のネットワーク接続型クラウドサービスよりもローカルNVMeのほうがレイテンシが低く、予測しやすいという結果が示されました。また、ネットワークストレージの柔軟な拡張性と耐久性の利点にも触れています。これらのローカルとネットワーク接続型PostgreSQLのベンチマークはホームラボでの性能を保証するものではありませんが、データベースの配置場所をインターフェースの速度だけでなく、ワークロードの測定に基づいて決めるべき理由を示しています。

サービスで予定しているものと同じファイルシステム、同期設定、データベースのバージョン、データセット、同時実行数で、代表的なテストを実施してください。テスト中に、ストレージネットワーク上で大規模なバックアップやメディア転送を開始します。テールレイテンシやコミット時間が不安定になる場合、集中型ストレージでは共有パスの問題を補えません。

デフォルトではプライマリデータベースファイルをコンピュートの近くに配置する

開発者1人、コンピュートノード1台、小規模なデータベースという構成では、ローカルのミラーリングSSDまたは復旧可能なローカルボリュームを使うと、管理責任が最も明確になります。データベースプロセス、データファイル、先行書き込みログが同時に障害を受ける一方、ストレージノードには、常時接続のリモートファイルシステムとしてホストさせるのではなく、データベースを考慮したプロセスを通じてバックアップを保存します。

ローカルに配置することは、保護されていない起動ドライブを1台だけ使うという意味ではありません。可能であればデータベースのボリュームをOSから分離し、空き容量とドライブの状態を監視し、メンテナンス作業用の容量を確保して、アップグレード前にバックアップをエクスポートしてください。スケジューラーが状態データのない別のノードでデータベースを起動しないよう、コンテナやVMの配置先を固定してください。

リカバリ手段が実際に機能する場合に限り、ローカルストレージを使います。コンピュートノードの交換時に古いコピーを頼りにするしかないなら、集中型ストレージは新たな問題を生むのではなく、既存のバックアップ障害を露呈させる可能性があります。データパスを最適化する前に、バックアップと復元のワークフローを修正してください。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

バックアップ、レプリカ、アーカイブにはストレージノードを使う

ストレージノードが役立つのは、アプリケーション整合性のあるダンプ、ベースバックアップ、アーカイブ済みトランザクションログ、不変スナップショット、または独自のリカバリ目的を持つデータベースレプリカを受け取る場合です。レイテンシに敏感なデータベースカタログやログをローカルに置いたまま、大容量の添付ファイルや分析用エクスポートを保存することもできます。

ストレージサーバー上のNFS経由のPostgreSQLに関するコミュニティテストでは、普遍的な答えではなく、意外な結果や設定に関する疑問が浮かび上がりました。だからこそ、リモートをプライマリストレージにするのは、設計と検証が必要な例外として扱います。正確な構成で、同期動作、障害処理、マウントオプション、キャッシュの意味論、復旧を検証してください。

障害復旧と移行の判断基準を検証する

4つの事象をテストします。データベースを正常に再起動する、書き込み中にコンピュートノードをクラッシュさせる、バックアップ中にストレージリンクを切断する、そして空のホストに復元する、の4つです。復旧時点、復旧時間、データベースの整合性チェック、アプリケーションの再接続動作を確認してください。通常時のベンチマークが高速でも、中断時の安全な書き込み経路が証明されるわけではありません。

アクティブデータのレイテンシが予測可能で、バックアップがプライマリを上書きしたりデッドロックさせたりせず、交換用コンピュートノードが文書化されていないストレージの前提条件なしで復元できれば、セットアップは合格です。測定した復旧性や可搬性の利点がネットワーク依存のデメリットを上回る場合に限り、プライマリファイルを設計されたストレージサービスに移してください。テールレイテンシやリンク障害が主なインシデント要因になった場合は、ローカルに戻してください。

より大きなアーキテクチャの選択では、ZimaSpaceによるストレージ優先のNASとコンピュート優先のホームサーバーの比較が、開発者のワークロードが変化してもどちらの役割を安定させるべきかを判断する助けになります。

最終セットアップのルール

アクティブなデータベースファイルは、デフォルトでローカルの保護されたSSDストレージに保存し、ストレージノードは検証済みのバックアップ、アーカイブ、選択したレプリカに使用します。書き込み時の動作、テールレイテンシ、障害時の挙動、復旧面での優位性を測定してから、リモートをプライマリストレージに選んでください。