最初に決めるべき判断基準

選択肢は3つあります。アプリと同じVPSにDBを入れる「同居型」、DB専用のVPSを別に立てる「専用VPS型」、クラウド事業者が運用するDBを借りる「マネージドDB」です。マネージドDBの例には Amazon RDS、Google Cloud SQL、Azure Database for PostgreSQL/MySQL、DigitalOcean Managed Databases があります。

判断の軸は2つに絞れます。1つ目は、DBが止まったりデータが消えたりしたときの損失がどれだけ大きいかです。2つ目は、障害対応やバックアップの検証に人手と時間を割けるかです。損失が大きく、運用に人手を割けないならマネージドDBが有力です。損失が小さく、費用を抑えたい、またはDBの設定を細かく調整したいなら自前運用が合います。

5つの観点での比較

観点同居型専用VPS型マネージドDB
運用負荷中(全部自分で行う)大(管理するサーバーが増える)小(パッチ適用・バックアップは事業者側)
可用性・バックアップVPSの障害でアプリごと停止冗長化は自分で構築自動バックアップあり。冗長構成はオプション
レイテンシ最小(ローカル接続)小(プライベートネットワーク経由)配置次第(同じリージョン・同じネットワーク内なら小)
コスト構造VPS料金のみの固定費VPS料金×台数の固定費インスタンス・ストレージ・バックアップ・転送量の従量課金が中心
ロックイン弱い弱い独自機能を使うほど強くなる

運用負荷

自前運用では、OSとDBのアップデート、ディスク残量の監視、バックアップの取得と復元テストをすべて自分で行います。特に負担が大きいのは復元テストです。バックアップを取っていても、戻せることを確かめていなければ障害時に役に立ちません。マネージドDBではこれらの大半を事業者が担います。ただし、スロークエリの調査やインデックス設計は利用者の仕事として残ります。

可用性とバックアップ

マネージドDBの多くは自動バックアップと、ポイントインタイムリカバリ(指定した時刻の状態に戻す機能)を備えています。プライマリとスタンバイを別の設備に置く冗長構成も、設定の切り替えで使えます。自前で同じことをするには、PostgreSQLならストリーミングレプリケーションや pgBackRest などのツールを組み合わせて構築する必要があります。同居型は構成が単純な反面、VPSが1台止まるとアプリとDBが同時に止まります。

性能とレイテンシ

同居型はローカル接続なので通信の遅延がほぼありません。ただし、アプリとDBがCPUとメモリを奪い合います。専用VPS型とマネージドDBではリソースを分けられますが、クエリ1回ごとにネットワークの往復時間が加わります。1リクエストで何十回もクエリを発行する処理(N+1問題)があると、この遅延が積み上がります。アプリを置くVPSとマネージドDBが別の事業者や別のリージョンにある場合は、特に影響が大きくなります。

コスト構造

VPSは月額固定が基本なので、費用を予測しやすい点が利点です。マネージドDBは、同程度の性能なら同じスペックのVPSより割高になるのが一般的です。冗長構成を有効にすると、スタンバイの分もほぼ同じだけ課金されます。バックアップの保存量やデータ転送量に別料金がかかることもあります。一方で自前運用には、構築と保守にかかる人件費という見えにくいコストがあります。料金体系は変わることがあるため、各事業者の公式料金ページで課金項目を確認してください。

ロックイン

マネージドDBでも、中身がPostgreSQLやMySQLであれば標準的なツールでデータを取り出せます。ただし、Amazon Auroraのような独自エンジン、事業者独自の認証連携、その事業者でしか使えない拡張機能に依存すると、移行の難しさが増します。データを外部へ持ち出す際に転送料金がかかる事業者もあります。

用途・規模・体制ごとの向き不向き

同居型は、個人開発の試作品、検証環境、多少止まっても困らない小規模サイトに向いています。弱点は、1台の障害がサービス全体の停止に直結することです。また、アクセスが増えたときにアプリとDBを別々に増強できません。

専用VPS型は、Linuxの運用に慣れた人がいて、費用を固定したいチームに向いています。DBの設定ファイルを自由に調整できる点や、使いたい拡張機能を入れられる点も利点です。弱点は、冗長化と監視を自前で用意しない限り、可用性が同居型とあまり変わらないことです。

マネージドDBは、売上や顧客データを扱う事業用サービスや、専任の運用担当がいない小規模チームに向いています。弱点は、費用が高くなりやすいことと、スーパーユーザー権限が使えないなど設定の自由度に制約があることです。

あとから移行するときの注意点

最初にバージョンをそろえます。移行先のDBのメジャーバージョン、使っている拡張機能、文字コードと照合順序(文字列の並び順のルール)、タイムゾーン設定が一致しているかを確認してください。マネージドDBではスーパーユーザーが使えないため、自前環境で作ったロールや権限の定義はそのまま復元できないことがあります。

小さなDBなら、ダンプして復元する方法で十分です。PostgreSQLの例を示します。

pg_dump -Fc -d appdb -f appdb.dump
pg_restore -d appdb_new appdb.dump

DBが大きく、ダンプと復元の間サービスを止められない場合は、レプリケーションで差分を同期しながら切り替えます。PostgreSQLの論理レプリケーションや、MySQLのバイナリログを使ったレプリケーションが使えます。どちらの方法でも、本番前に一度リハーサルをして所要時間を測ってください。切り替え当日は、アプリを書き込み停止にする手順、接続先の変更方法、元のDBへ戻す手順を事前に決めておきます。

決め方の手順

まず、DBが1日止まった場合と、直近1日分のデータを失った場合の損失を見積もります。どちらかが許容できないなら、マネージドDBか、冗長化した専用VPS型を選びます。次に、その冗長構成を自分たちで構築し、復元テストまで続けられるかを考えます。続けられないならマネージドDBを選びます。損失を許容できるなら、同居型から始めても問題ありません。その場合も、外部ストレージへの定期バックアップと復元手順だけは最初に用意してください。