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

エヴァ・ウォン

IceWhale author

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

Should a Developer Keep Databases on the Compute Node or the Storage Node? - Zima Store Online

アクティブなデータベースファイルは、原則としてコンピュートのそばにある低レイテンシストレージに置き、ストレージノードはバックアップ、ダンプ、レプリカ、アーカイブに使用します。

ただし、ストレージノードが意図的に設計されたブロックストレージの経路、測定済みのレイテンシ、適切な耐久性セマンティクス、そして追加の依存関係に見合う復旧上のメリットを提供する場合は、この原則が変わります。判断すべきなのは単純なローカル容量とネットワーク容量の比較ではありません。トランザクションログ、データファイル、バックアップ、アプリケーションのアップロード、使い捨てのテストデータベースでは、書き込みパターンと障害時の影響がそれぞれ異なります。

データベースの状態をダンプやバックアップから分離する

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

1つのNAS共有をマウントして、その中にすべてを置かないでください。アクティブなデータベースボリュームを、バックアップ先やアプリケーションの大容量データから分離します。これにより、すべての永続データが同じ媒体を必要とするかのように扱わず、それぞれの役割を個別に調整、監視、容量管理、スナップショット取得、復元、移行できるようになります。

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

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

データベースの性能は、シーケンシャルスループットだけでは決まりません。同期コミットのレイテンシ、ランダム読み書き、バックアップ処理中のキュー深度、ネットワーク経路が停止した際の挙動を測定します。10GbEリンクは大容量ファイルを高速に転送できても、すべてのトランザクションにレイテンシと別の障害点を追加する可能性があります。

公開されているPostgreSQLの比較では、テストしたネットワーク接続型クラウドサービスよりも、ローカルNVMeのほうが低く予測しやすいレイテンシを実現しました。一方で、ネットワークストレージの伸縮性と耐久性の利点にも触れています。このローカルとネットワーク接続型のPostgreSQLベンチマークはホームラボでの結果を保証するものではありませんが、データベースの配置にはインターフェース速度だけでなく、ワークロードの測定が必要である理由を示しています。

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

原則としてプライマリのデータベースファイルをコンピュートの近くに置く

開発者が1人、コンピュートノードが1台で、データベースが中小規模の場合は、ローカルのミラーリングSSDまたは復旧可能なローカルボリュームによって、責任範囲を明確にしやすくなります。データベースプロセス、データファイル、先行書き込みログは一緒に障害が発生し、ストレージノードは常時オープンのリモートファイルシステムをホストするのではなく、データベースを認識したプロセスを通じてバックアップを受け取ります。

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

復旧経路が実際に機能する場合にのみ、ローカルストレージを使用します。コンピュートノードの交換時に、古いコピーを推測しながら復旧しなければならないのであれば、中央集約型ストレージは障害を生むのではなく、既存のバックアップ失敗を明らかにしているだけかもしれません。データ経路を最適化する前に、バックアップと復元のワークフローを修正してください。

-15% OFF

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

Single board computer zimaboard2

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

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

データの役割	デフォルトの場所	理由	必要なテスト
プライマリデータとトランザクションログ	コンピュートノードのSSD	最も低く、予測しやすい書き込み経路	コミットレイテンシとクラッシュリカバリ
論理ダンプ	ストレージノード	移植性があり、バージョンを考慮した復元元	空のデータベースへの復元
ベースバックアップとアーカイブ済みログ	ストレージノード	ポイントインタイムリカバリ	指定したタイムスタンプへの復旧
リードレプリカ	独自のボリュームを持ついずれかのノード	読み取りのスケーリングまたは復旧手段	遅延と昇格手順
アップロード、エクスポート、コールド分析データ	ストレージノード	トランザクションレイテンシより容量が重要	同時転送による影響

ストレージサーバー上のNFS経由のPostgreSQLに関するコミュニティテストでは、普遍的な答えではなく、直感に反する結果と設定上の疑問が示されました。だからこそ、リモートのプライマリストレージは、設計された例外として扱う必要があります。実際のスタック上で、同期の挙動、障害処理、マウントオプション、キャッシュのセマンティクス、復旧を検証してください。

障害復旧と移行のトリガーを検証する

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

アクティブなデータのレイテンシが予測可能で、バックアップがプライマリを上書きしたりデッドロックさせたりせず、交換したコンピュートノードが文書化されていないストレージの前提なしに復元できる場合、その構成は合格です。測定された復旧性や移動性のメリットがネットワーク依存のデメリットを上回る場合にのみ、プライマリファイルを設計済みのストレージサービスへ移します。テールレイテンシやリンク停止が主要なインシデント原因になった場合は、ローカルへ戻します。

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

最終的な構成ルール

アクティブなデータベースファイルには、保護されたローカルSSDストレージをデフォルトとして使用し、ストレージノードは検証済みのバックアップ、アーカイブ、選択したレプリカに使用します。リモートのプライマリストレージを選ぶのは、その書き込みセマンティクス、テールレイテンシ、停止時の挙動、復旧上のメリットを測定してからにしてください。