Amazon RDS設計ガイド：Cloud SQL、AzureのマネージドDBと比較する選び方

greeden

11か月前

Amazon RDSを選ぶときは、機能数や知名度から比較を始めるより、現在のデータベースエンジン、許容できる停止時間とデータ損失、読み書きの負荷、運用体制を先に整理したほうが判断しやすくなります。

この記事では、RDSの責任分界と構成の違いを押さえたうえで、Google Cloud SQLとAzureのマネージドデータベースを同じ選定軸で比較します。

高可用性と災害対策を区別できる
Multi-AZ、リードレプリカ、バックアップの役割を整理できる
三つのクラウドを製品名ではなく要件で比べられる
設計レビューと復旧訓練に使える確認項目を持ち帰れる

RDS選定の結論

特定のクラウドが常に優れているわけではなく、既存システムとの整合性と障害時の目標を満たし、チームが継続運用できるサービスを選ぶのが現実的です。

比較は次の順序で進めます。

移行元または新規採用するデータベースエンジンを決める
RPOとRTOを障害の種類ごとに定める
書き込み、読み取り、接続数、データ量の変化を見積もる
ネットワーク、認証、監視、保守の標準と照らす
本番相当の負荷試験と復旧試験で確かめる

料金表だけで先に決めると、レプリカ、バックアップ、データ転送、監視、運用作業を含めた総費用を見落としやすくなります。

Amazon RDSと責任分界

マネージドRDBとは、データベースを動かす基盤の調達や交換、サービス側で提供されるバックアップ機能、監視機能などをクラウド事業者が管理し、利用者がスキーマ、SQL、権限、データ、アプリケーション接続を管理する形態です。

Amazon RDSは複数のリレーショナルデータベースエンジンを扱い、Amazon AuroraはMySQLまたはPostgreSQLとの互換性を持つ別のアーキテクチャとして提供されます。

RDS運用で確認する主な責任分界
領域	サービス側が担う範囲	利用者が担う範囲
基盤	物理設備、基盤ソフトウェア、管理サービス	リージョン、構成、インスタンス、ストレージの選択
可用性	選択した構成に応じた複製とフェイルオーバー機能	必要な構成の有効化、接続再試行、障害訓練
データ保護	自動バックアップ、スナップショット、復元機能	保持期間、暗号化、復元先、整合性確認、復旧手順
データベース	提供範囲内のエンジン保守と監視機能	スキーマ、索引、SQL、権限、データ品質、性能改善
セキュリティ	クラウド基盤の保護	ネットワーク公開範囲、認証、秘密情報、監査設定

「マネージドだから運用不要」を意味するわけではありません。

OSへ直接ログインする作業は減りますが、容量不足、接続枯渇、遅いSQL、権限過多、復元未検証といった問題は利用者が管理します。

比較前にそろえるサービスの単位

サービス名だけを横に並べると、異なるデータベースエンジンや可用性構成を比べてしまいます。

クラウドごとの比較単位
クラウド	主な比較対象	比較時の注意
AWS	Amazon RDSの各エンジン、Amazon Aurora	RDSのMulti-AZ DBインスタンス、Multi-AZ DBクラスター、Aurora DBクラスターは別の構成として扱う
Google Cloud	Cloud SQLの同じエンジン	高可用性構成、リードレプリカ、クロスリージョン対策を分けて確認する
Azure	Azure SQL Database、Azure Database for PostgreSQLなど	SQL Server系とPostgreSQL系を一つの製品として比べず、サービスと階層ごとの機能を確認する

たとえばPostgreSQLの移行なら、RDS for PostgreSQL、Cloud SQL for PostgreSQL、Azure Database for PostgreSQLを先に比べ、Aurora PostgreSQL互換を採用候補に加えるかは互換性検証の結果で判断します。

RPO、RTO、HA、DRの意味

RPO：障害発生時に、どの時点までのデータ損失を許容するかを表す目標です。
RTO：障害発生後、業務を再開するまでに許容する時間を表す目標です。
HA：High Availabilityの略で、主に同一リージョン内の機器障害やゾーン障害からサービスを継続または早期復旧させる設計です。
DR：Disaster Recoveryの略で、リージョン規模の障害や大きな災害を想定した復旧設計です。
PITR：Point-in-Time Recoveryの略で、バックアップ保持期間内の指定時点へデータベースを復元する方法です。
SLO：サービス提供側が運用目標として定める、可用性や応答時間などの水準です。

一つのRPOとRTOを決めるだけでは足りません。

インスタンス障害、ゾーン障害、リージョン障害、誤削除、破損といった原因ごとに、使える復旧手段と必要時間が変わるからです。

Multi-AZとリードレプリカの違い

Amazon RDSのMulti-AZには複数の配置方式があり、従来型のMulti-AZ DBインスタンスとMulti-AZ DBクラスターでは読み取りの扱いが異なります。

RDSの配置方式と主な役割
方式	主な目的	読み取り分散
Single-AZ DBインスタンス	検証環境や停止を許容できる用途	別途リードレプリカを検討
Multi-AZ DBインスタンス	スタンバイへの自動フェイルオーバー	スタンバイは通常の読み取り先にしない
Multi-AZ DBクラスター	高可用性と読み取り容量	対応するエンジン、バージョン、リージョンで読み取り可能なDBインスタンスを利用
Aurora DBクラスター	Aurora固有の分散ストレージとクラスター運用	Aurora Replicaを読み取り先にできる

構成の違いは、Amazon RDSのSingle-AZ、Multi-AZ DBインスタンス、Multi-AZ DBクラスターの比較でも詳しく整理しています。

高可用性はバックアップの代わりになりません。

誤った更新や削除はスタンバイやレプリカにも反映されるため、論理障害に備えるには自動バックアップ、PITR、手動スナップショット、復元試験が必要です。

バックアップは復元まで設計する

RDSの自動バックアップは、設定した保持期間に基づいてPITRを可能にし、手動スナップショットは利用者が削除するまで保持する用途に使えます。

PITRでは通常、新しいDBインスタンスへ復元してからデータの整合性を確認し、アプリケーションの接続先を切り替えます。

業務要件から保持期間と復旧対象を決める
バックアップの成否と最新復元可能時刻を監視する
別の環境へ復元する手順を文書化する
件数、金額、参照整合性、主要画面を検証する
接続先の切り替えと切り戻しを訓練する

バックアップジョブの成功だけを確認しても、必要な時間内に業務を再開できる保証にはなりません。

性能改善は原因に合わせる

データベースが遅いときに、すぐインスタンスを大きくするとは限りません。

負荷の種類と主な対策
観測した状態	先に確認すること	主な対策候補
読み取りが多い	クエリ別の負荷、レプリカラグ、整合性要件	索引改善、キャッシュ、リードレプリカ、読み書き分離
書き込みが多い	ロック、トランザクション時間、IO待ち	SQL改善、バッチ分割、インスタンスやストレージの見直し
接続数が多い	接続の寿命、同時実行数、待機接続	接続プール、上限設定、アプリケーションの再試行制御
特定SQLだけ遅い	実行計画、索引、統計、取得行数	SQLと索引の改善、統計更新、不要な取得の削減
一時的なピーク	発生時間、バッチ、外部イベント	処理時間の分散、キュー、事前の容量調整

リードレプリカは一般に非同期で更新されるため、更新直後の値を必ず読みたい処理や、遅延を許容できない判定にはそのまま使えません。

アプリケーション側で読み取り先を分ける場合は、どの画面や処理が多少古いデータを許容できるかまで決めます。

セキュリティの設計項目

ネットワーク：DBを外部へ直接公開せず、必要なアプリケーションと運用経路だけから到達できるようにします。
通信：TLSを使い、証明書の検証方法と更新手順をアプリケーション側にも実装します。
認証：アプリケーション用、移行用、運用用のアカウントを分け、共有アカウントを避けます。
権限：読み取り、書き込み、DDL、管理操作を役割ごとに分け、不要な権限を定期的に外します。
秘密情報：パスワードやトークンをソースコードへ置かず、秘密情報管理サービスとローテーション手順を使います。
監査：管理操作とデータベース監査ログの目的、保存先、閲覧権限、保持期間を定めます。

RDSのIAMデータベース認証は対応エンジンが限られ、バージョンやリージョンによって利用可否が異なるため、採用前に公式資料を確認します。

プライベート接続の考え方は、Amazon VPC、Google Cloud VPC、Azure VNetの設計比較も参照してください。

監視で原因を切り分ける

監視項目は、異常を知らせるだけでなく、次の調査先を決められる粒度で設計します。

データベース監視の基本項目
項目	分かること	次に確認する対象
CPUとDB負荷	計算資源やSQL実行の集中	負荷の高いSQL、同時実行数、直近の変更
接続数	上限接近や接続リーク	接続プール、待機接続、アプリケーション別の利用数
ストレージ遅延とIO	読み書き待ち	クエリ、バッチ、索引、ストレージ設定
空き容量	容量枯渇の予兆	増加率、ログ、不要データ、拡張手順
レプリカラグ	読み取りの鮮度とDRへの影響	書き込み量、長いトランザクション、ネットワーク
スロークエリとエラー	利用者影響の直接原因	実行計画、タイムアウト、ロック、デプロイ履歴

AWSの監視サービスとの組み合わせは、Amazon CloudWatch、Cloud Monitoring、Azure Monitorの比較で確認できます。

三つのクラウドを同じ軸で比較する

Amazon RDS、Cloud SQL、Azureの比較観点
選定軸	Amazon RDSとAurora	Cloud SQL	AzureのマネージドDB
エンジンと互換性	RDSの各エンジンとAuroraを分けて検証	同じエンジンでも拡張、フラグ、保守条件を確認	Azure SQL DatabaseとPostgreSQL系などを別サービスとして確認
同一リージョンの可用性	Multi-AZの方式とAuroraの構成を選ぶ	高可用性構成のゾーン配置とフェイルオーバーを確認	サービス、階層、リージョンごとのゾーン冗長やHAを確認
読み取り分散	リードレプリカ、Multi-AZ DBクラスター、Aurora Replicaを使い分ける	リードレプリカの遅延と接続先を設計	サービスごとのリードスケールまたはリードレプリカを確認
リージョン障害への備え	クロスリージョンの複製やバックアップを要件に合わせる	クロスリージョンレプリカや復元手順を設計	サービスごとの地理冗長、レプリカ、復元方法を選ぶ
ネットワークと認証	VPC、セキュリティグループ、秘密情報、対応エンジンのIAM認証	プライベートIP、接続経路、IAMとの連携	Private EndpointまたはVNet統合、Microsoft Entra IDとの連携条件
監視	CloudWatchとエンジン固有のログ	Cloud MonitoringとCloud Logging	Azure Monitorとサービス固有の診断

機能はエンジン、エディション、サービス階層、バージョン、リージョンで変わるため、「Aが常にB以上」という順位は設計根拠に使えません。

選定を進める六つの手順

1. 互換性の条件を一覧にする

エンジン名が同じでも、利用できる拡張、照合順序、文字コード、認証方式、管理権限、パラメータ変更範囲が同じとは限りません。

既存DBを移行する場合は、SQL、データ型、シーケンス、ストアド処理、ジョブ、監視方法を棚卸しします。

2. 障害シナリオごとに目標を置く

インスタンス障害にはMulti-AZ、誤削除にはPITR、リージョン障害には別リージョンの複製や復元計画というように、原因と手段を対応させます。

3. 負荷の形を測る

平均値だけでなく、ピーク時の接続数、読み書き比率、遅いSQL、IO、データ増加率、バッチ時間を測ります。

4. 運用経路を確認する

監視、ログ保管、秘密情報管理、構成管理、問い合わせ体制が既存のクラウド標準に沿うかを確認します。

5. 総費用を比べる

計算資源とストレージに加え、HA、レプリカ、バックアップ超過分、IO、データ転送、監視、ライセンス、運用作業を含めます。

6. 本番相当で試す

代表クエリの負荷試験、フェイルオーバー時の再接続、PITR、権限変更、証明書更新、容量アラートを実行し、結果をRunbookへ反映します。

移行で見落としやすい点

日時型とタイムゾーンの扱い
文字コード、照合順序、大文字と小文字の比較
自動採番、シーケンス、既定値
ストアド処理、トリガー、イベントスケジューラ
ユーザー、ロール、権限の対応
長時間トランザクションと差分同期
切り替え中に発生する書き込みの扱い
切り戻し条件と旧環境の保持期間

異なるエンジン間の移行は、転送方法だけでなくアプリケーションの互換性確認が必要です。

具体例は、PostgreSQLからMySQLへ移行する実務手順も参考になります。

復旧Runbookのひな型

データベース障害時の確認手順
段階	実施内容	完了条件
検知	症状、開始時刻、影響機能、変更履歴を確認する	影響範囲と連絡先が共有されている
保全	必要に応じて書き込みやバッチを止め、ログと証跡を保存する	障害の拡大と証跡消失を抑えている
判断	基盤障害、性能障害、論理障害を切り分ける	フェイルオーバー、スケール、復元のどれを使うか決まっている
回復	選んだ手段をRunbookに沿って実行する	新しい接続先と復旧時点が記録されている
検証	データ整合性、主要な読み書き、遅延、エラーを確認する	業務再開の承認条件を満たしている
切り替え	接続先を変更し、段階的にトラフィックを戻す	監視値が安定し、切り戻し可否を判断できる
再発防止	原因、検知、手順、権限、テストを見直す	担当者と期限を含む改善項目が登録されている

誤削除のような論理障害でレプリカを昇格しても、削除がすでに反映されていれば元のデータは戻りません。

障害の種類を確認してから復旧手段を選ぶ必要があります。

コストを抑える確認順

使われていない検証環境、スナップショット、レプリカを確認する
CPUだけでなく、メモリ、接続数、IO、待機時間を見てサイズを調整する
負荷の高いSQLと索引を改善する
読み取り分散が必要な処理と、キャッシュで足りる処理を分ける
常時稼働する構成に適用できる予約料金やコミットメントをサービス別に確認する
バックアップ保持、リージョン間転送、監視ログの保存量を見直す

小さいインスタンスへ変更する前に本番相当の負荷試験を行い、性能低下による業務損失を含めて判断します。

設計レビューのチェックリスト

採用するエンジンと必要なバージョン、拡張、ライセンスを確認した
障害シナリオ別のRPOとRTOを定めた
Multi-AZとリードレプリカの目的を混同していない
自動バックアップの保持期間と手動スナップショットの用途を決めた
PITR後の検証と接続先切り替えを試した
DBを外部へ直接公開せず、必要な経路だけを許可した
TLS、認証、最小権限、秘密情報の更新手順を整えた
接続数、IO、容量、レプリカラグ、遅いSQLを監視している
読み書き分離で許容できるデータの遅延を定めた
総費用にHA、レプリカ、バックアップ、転送、監視、運用を含めた
フェイルオーバー、復元、切り戻しを定期的に訓練する

よくある質問

Multi-AZにすれば読み取りも速くなりますか

構成によります。

従来型のMulti-AZ DBインスタンスのスタンバイは通常の読み取り先ではなく、Multi-AZ DBクラスターやAurora DBクラスターは読み取り可能なインスタンスを持てます。

自動バックアップを有効にすれば復旧対策は完了ですか

完了ではありません。

必要な時点へ復元できるか、整合性をどう確認するか、どの接続先へ切り替えるかまで試して、初めて業務の復旧手順になります。

プライベートネットワークなら安全ですか

公開範囲を狭められますが、それだけで十分ではありません。

TLS、認証、最小権限、秘密情報管理、監査ログ、アプリケーションの脆弱性対策も必要です。

どのクラウドが最も安いですか

構成、リージョン、契約、IO、レプリカ、バックアップ、転送量で変わります。

同じRPO、RTO、性能条件を満たす構成を作り、運用工数を含む総費用で比較します。

確認に使える公式資料

まとめ

マネージドデータベースの選定では、製品の順位より、エンジン互換性、障害シナリオ別のRPOとRTO、負荷の形、セキュリティ、監視、復旧訓練を一つの設計としてつなぐことが大切です。

Amazon RDSを採用する場合も、Multi-AZ、リードレプリカ、自動バックアップを目的別に使い分け、復元後の検証と接続切り替えまで確認します。

この記事に関連する株式会社greedenの取り組み

データベース選定は、機能比較だけでなく、復旧目標や運用手順を要件へ落とし込む作業です。株式会社greedenは、ヒアリングから要件定義、設計、実装、テスト、リリース、保守運用までWebシステム開発を一気通貫で支援します。