データベース構成の選定 — マネージドか自前構築かの判断

「どちらが安いか」という問いから始めるDB構成の選定は、構築後に高い確率で再検討を迫られる。正しい判断軸は月額費用ではなく、冗長化の実装コスト・フェイルオーバーの応答保証・バックアップ運用の継続負荷・将来の移行容易性だ。設計フェーズでこれらを整理せずに構築に入ると、規模拡大のたびに構造的な問題が顕在化する。本記事では、現場の構築担当者が押さえるべき判断材料と選定の考え方を整理する。

「自前のほうが安い」で失敗するDB構成の落とし穴

コスト試算から抜け落ちる「運用コスト」の重さ

自前構築のDB環境を選ぶ際、試算に使われるのは多くの場合サーバー費用とライセンス費用だけだ。しかし実際には、OSパッチ・DBエンジンのバージョンアップ・監視設定の維持・バックアップジョブの検証といった定常運用が積み上がる。中規模のWebサービスでPostgreSQLをEC2上に自前構築したケースでは、構築後1年以内に運用作業が月10時間を超えることが珍しくない。これは人件費に換算すると、一見「割高」に見えたマネージドDBの月額差分を容易に上回る。費用対効果の試算は「初期構築コスト＋定常運用工数×12か月」を最低ラインとして設定すべきだ。

「後からマネージドに移せばいい」という先送りのリスク

構築フェーズで「まず自前で動かして、後でマネージドに移行する」という判断は、現場でよく聞くパターンだ。しかし移行には、スキーマ互換性の確認・データ転送中のダウンタイム設計・アプリケーション側の接続先切替テストが伴い、本番稼働後の移行は想像以上に工数がかかる。データ量が数百GBを超えている場合、移行プロジェクトとして1〜2か月の期間と専任担当者を確保しなければ現実的に進まないケースも多い。「移行でリセットできる」という前提は計画に織り込まないほうが安全で、初期の設計判断が後工程を大きく左右する。

スケールアップ時に露わになる設計負債

トラフィックが増加した段階で、自前DB構成の設計負債が一気に表面化することがある。レプリケーション設定の不備・コネクションプール上限の設計の甘さ・フェイルオーバー時のアプリ再接続ロジックの欠落など、低負荷時には顕在化しなかった問題が、本番の高負荷下で障害として現れる。3〜5台規模の自前MySQL構成を運用しているチームが、月次のピーク時にスレーブラグが数分に達してサービスに影響が出たという話は、構築現場でよく聞く。設計フェーズで「スケール時の挙動」まで想定した構成になっているかを確認することが、後の選定やり直しを防ぐ第一歩だ。

マネージドが向く構築・自前が向く構築の違い

マネージドが力を発揮する構築の特徴

マネージドDBが適合しやすいのは、DBよりもアプリケーション側の開発・改善に集中したい構成だ。少人数チームが複数のレイヤーを同時に担う場面では、OS・DBエンジンのメンテナンス作業を外部サービスに委ねることで、開発サイクルを維持しやすくなる。また、高可用性要件（SLA 99.9%以上）を自前で満たすためにはMHA・Patroni・ProxySQLといった追加コンポーネントの構築が必要になり、それ自体が相当な実装負荷になる。マネージドはこの実装を省略し、設定操作でマルチAZ構成や自動フェイルオーバーを有効化できる点が強みだ。

自前構築が合理的な構築の特徴

自前構築が合理的なのは、マネージドサービスの制約がシステム要件と衝突する場合だ。特定のストレージエンジン変更・独自のレプリケーショントポロジー・OSカーネルチューニングが必要な高スループット要件、あるいはデータが物理的にクラウドから出てはいけないセキュリティポリシーなどが該当する。金融系・医療系のオンプレ要件や、特定のDBソフトウェアバージョンを長期間固定したいケースでは、自前構築の制御の自由度が決め手になる。ただし「制御したい」という感覚的な理由だけでは、自前を選ぶ根拠として不十分だ。

判断を左右するチームのDB運用スキル

構築だけでなく継続的な運用ができるスキルセットがチーム内にあるかどうかは、選定の現実的な制約になる。PostgreSQLやMySQLの自前構築は、バキューム設計・スロークエリの分析・レプリケーション遅延の対処・バックアップリストアテストを定期的に実施できるエンジニアが最低1人いることを前提とする。チームの人数が3人未満で、DBが専任担当なしの兼任運用になる場合、自前構築はインシデント対応が後手に回るリスクが高い。スキルのギャップは研修で埋まるものではなく、採用・外部委託・マネージドへの方針転換のいずれかで対処する必要がある。

比較表: 運用負荷・可用性・拡張性・制御の自由度

マネージドDBと自前構築DBの主要な設計判断軸を整理する。「どちらが優れているか」ではなく「どの軸を優先するか」で選択が変わる点に注意したい。

判断軸	マネージドDB（RDS / Cloud SQL 等）	自前構築DB（EC2 / ベアメタル 等）
運用負荷	パッチ・バックアップ・フェイルオーバーを自動化。定常運用の負荷は低い	OS・DBエンジン・監視まで自チームで担う。人的コストが継続的に発生する
可用性	マルチAZ・自動フェイルオーバーを標準提供。SLA 99.95%前後が一般的	設計次第で高可用性も実現可能だが、冗長化の実装を自前で行う必要がある
拡張性	スケールアップは設定変更で即時対応。一部スケールアウトに制約がある	シャーディング・カスタムレプリカ構成を自由に組める。設計コストは高い
制御の自由度	OSレベルのアクセス不可。変更できるパラメータの範囲に制限がある	ストレージエンジン・カーネル設定・独自レプリカ構成など完全に制御できる
移行・乗換え	ベンダー依存が発生する。クラウド間移行時に再設計が必要になる場合がある	構成の可搬性は高い。ただし移行作業の実装は自前負担になる
コスト構造	月額定額に近い。規模拡大時は段階的に費用が上昇する	初期投資型。運用工数を含めたTCO比較なしにコスト優位は主張できない

可用性（冗長化/フェイルオーバー）から見た選定

自前での冗長化に求められる実装量

自前でMySQLの高可用性構成を組む場合、最低限でもプライマリ1台＋スタンバイ1台のレプリケーションに加え、フェイルオーバー検知・自動昇格・VIPの切替機構が必要になる。MHAやOrchestrator、あるいはPatroni（PostgreSQL）を導入する場合、設定ファイルの記述・動作検証・フェイルオーバーシナリオのテストを含めると、経験のある担当者でも構築に3〜5日を要することが多い。さらに年1回程度は本番に近い環境でフェイルオーバーを実際に発生させて動作確認しなければ、本番障害時に「自動切替が動かなかった」という事態になりうる。手を動かす詳細な構築手順は別の専門資料に譲るが、設計判断の段階でこの実装規模を見積もりに織り込んでおくことが重要だ。

マネージドの可用性保証とその限界

マネージドDBのマルチAZ構成は、単一AZの障害に対して自動フェイルオーバーが動作し、RPO（目標復旧時点）はほぼゼロ、RTO（目標復旧時間）は数分以内に収まることが多い。ただしマネージドの可用性保証がカバーするのはインフラ層であり、アプリケーションの接続管理・再接続ロジック・コネクションプールの設定は自チームの責任範囲に残る。フェイルオーバー発生時にアプリが既存コネクションを張り続けて30秒以上応答しなかったケースでは、原因がマネージドDB側ではなくアプリの接続タイムアウト設定にあったという事例も報告されている。

RPO/RTOから逆算する選定ロジック

可用性要件は「SLAを何%にするか」よりも「障害発生時に何分で復旧できる必要があるか（RTO）」「どの時点のデータまで失ってよいか（RPO）」を先に数値で決めることが有効だ。RTO 1分・RPOゼロに近い要件を自前で満たすには、同期レプリケーション・自動フェイルオーバー・DNS切替を組み合わせた相当な設計工数がかかる。一方でRTO 30分・RPO 1時間で十分な内部系システムであれば、自前構築でも現実的な冗長化設計の範囲に収まる。可用性要件を数値で定義することで、選定の根拠を設計ドキュメントとして残すことができる。

バックアップ・移行のしやすさで分ける判断

バックアップ設計は「復元テスト」まで込みで考える

バックアップの設計で見落とされやすいのは、「取得できる」と「復元できる」は別の問題だという点だ。自前構築の場合、論理バックアップ・物理バックアップの設定は比較的容易だが、復元時の手順・所要時間・データ整合性の確認まで設計に含めているチームは少ない。100GBのDBを論理バックアップから復元すると数時間かかることもあり、RTO要件を満たせない可能性がある。マネージドDBでは自動スナップショットとポイントインタイムリカバリが組み込まれているが、復元テストを定期実施することは引き続き自チームの判断として必要だ。選定の段階で「復元まで込みのバックアップ設計」がどちらで実現しやすいかを評価に加えることが重要になる。

クラウド間・オンプレ間の移行コストの非対称性

移行コストには非対称性がある。オンプレから特定のマネージドDBに移行するよりも、マネージドDBからオンプレや別クラウドに移行するほうがコストと工数が大きくなるケースが多い。マネージドのスナップショット形式やレプリケーション機構がベンダー固有のため、データを汎用フォーマットに変換する作業が加わるためだ。将来的にクラウドベンダーを変更する可能性がある構成では、論理エクスポート相当のバックアップを別保管する設計を初期から入れておくことで、出口コストを下げることができる。これは「ロックインを避ける」という抽象的な方針ではなく、移行シナリオを具体的に想定した設計判断として扱うべきだ。

将来の変更容易性を織り込んだ選び方

ベンダーロックインの「程度」を見極める

マネージドDBを採用すること自体がベンダーロックインというわけではない。問題になるのは、特定ベンダーのみに存在するデータ型・専用関数・独自拡張機能に依存した設計になっているかどうかだ。標準SQLの範囲内でスキーマとクエリを書いていれば、マネージドDBを使っていてもエンジン移行のコストは大幅に下がる。構築フェーズでコード規約に「ベンダー固有機能を使う場合は設計書に理由を明記する」というルールを一行追加するだけでも、将来の選択肢を狭めるリスクを管理できる。ロックインの判断は「マネージドか否か」ではなく「何に依存しているか」の粒度で行うべきだ。

スキーマ変更・バージョンアップの自由度

自前構築はDBエンジンのバージョンを自分たちのタイミングで上げられる半面、適用しなければセキュリティリスクが自チームの責任として残る。マネージドは強制的なメジャーバージョンアップの時期が設定されており、アプリ側の互換性確認が必要になる。ある製造業向け社内システムの構築事例では、PostgreSQLのメジャーバージョン強制アップグレードに際してストアドプロシージャの挙動変化が発覚し、検証・修正に2週間を要したという話がある。どちらを選んでも「バージョンアップ対応コスト」は発生するため、判断の差は「いつ・誰がコントロールするか」にある。

マルチクラウド・ハイブリッド構成への対応

将来的にマルチクラウドや拠点間ハイブリッド構成を検討する可能性がある場合、DBの配置選択はネットワーク設計とセットで考える必要がある。マネージドDBをVPC外からアクセスするには、専用の接続機構が必要になり、レイテンシとコストが増加する。自前構築であれば物理的な配置とルーティングを自由に制御できるが、その分セキュリティ境界の設計責任が増す。「将来拡張する可能性がある」という漠然とした理由で自前を選ぶのではなく、具体的な拡張シナリオを2〜3個列挙した上でどちらの構成に乗せやすいかを検討することが、設計書の説得力を高める。

DB構成選定チェックフレーム

以下のチェック項目を設計フェーズで整理しておくことで、選定の根拠を構成メンバーと共有できる形に残すことができる。全項目に回答してから「マネージドか自前か」の結論を出す順序が重要だ。

1. 可用性要件を数値で定義できているか：RTOとRPOの目標値を記録し、自前実装で満たすコストと比較する。
2. DB専任（またはDB運用スキルを持つ）担当者がチームにいるか：兼任での自前運用は障害時の対応速度が下がるリスクを考慮する。
3. ストレージエンジン・OSレベルの制御が要件に含まれるか：含まれる場合は自前構築の根拠として設計書に明記する。
4. データの物理配置に法的・契約的制約があるか：特定のリージョン・データセンター指定がある場合、マネージドの選択肢が絞られる。
5. 将来のDBエンジン移行・クラウド移行の可能性を評価したか：ベンダー固有機能の利用範囲を明示し、移行コストを試算する。
6. バックアップの復元テストを定期実施する運用を組み込めるか：取得のみで復元未確認のバックアップは設計上のリスクとして扱う。
7. 初期構築コストだけでなく3年分の運用工数を試算に含めたか：工数ベースのTCO比較なしにコスト優位を主張しない。
8. スケールアップ時の構成変更手順を設計段階で検討したか：データ量・接続数の増加シナリオに対して対処方法が決まっているか確認する。

「マネージドか自前か」の問いに対して、最初から答えを決めてから選定作業を進めると、都合の悪い要素が見落とされやすい。上記の軸を並べて比較することで、選定の根拠が設計ドキュメントとして残り、後から構成を見直す際にも判断の経緯をたどることができる。構築フェーズで時間をかけるべき設計判断の一つとして、DB構成の選定を位置づけることが、安定した本番環境の土台になる。