Amazon RDS・AuroraとリレーショナルDBの違いと使い分け

RDSとAuroraを単純な上位・下位の関係で覚えず、既存エンジンの互換性、管理範囲、可用性、読取り負荷、計算容量の要件から比較します。必要な構成を揃えて費用を見積もることも重要です。

この単元で学ぶこと

互換性と管理範囲で方式を比較する
可用性・読取り・容量調整の違いを判断する
復旧と費用の条件を比較する

本文解説

1. エンジン互換性から絞る既存のOracle DatabaseやSQL Serverの機能を必要とするなら、RDSの対応エンジンを確認します。AuroraはMySQL互換またはPostgreSQL互換なので、どのRDSエンジンのアプリでも変更なしに移せるわけではありません。データ型、SQL、拡張、ライセンスを比較します。

2. 管理する範囲を比べる RDSとAuroraはどちらもDB基盤の管理負担を軽減しますが、SQLの改善やテーブル設計、業務権限は利用者に残ります。自社DBでOSへ任意のソフトを入れる必要があれば、標準マネージド方式の制約を確認します。運用を軽くする効果と必要な自由度を同じ表で比較します。

3. ストレージの構成を比べる通常のRDS DBインスタンスとAuroraのクラスタ構成ではデータを扱う基盤が異なります。Auroraはwriterとreaderが同じクラスタボリュームを使い、保存を複数AZへ分散します。計算用DBの台数と保存側の冗長性を別の条件として記載すると、構成の読み違いを減らせます。

4. 可用性方式を比べる従来のRDS Multi-AZ DBインスタンス配置はスタンバイへの切替えが中心です。RDS Multi-AZ DBクラスター配置は読取り可能な副系を持ちます。Auroraではreaderを読取りと昇格先として利用できます。Multi-AZという語だけで全て同じ動きとせず、どの配置方式かを明記します。

5. 読取りの増加に対応レポートなど読取り負荷が増えた場合、read replicaやAurora readerが候補です。アプリの接続先、複製の反映、必要な鮮度を確認します。通常RDSの非同期read replicaは、直前の更新がまだ反映されていないことがあります。writerへ集中する書込みを同じ方法で直接分散できるとは考えません。

6. 容量変化に対応固定したDBインスタンスのサイズ変更と、Aurora Serverlessの需要に応じた計算容量調整では運用の考え方が違います。ただしどちらも負荷や設定、上限を確認する必要があります。例えば夜間に負荷が下がる環境でも、データの保存量やバックアップの費用が同時に消えるわけではありません。

7. 復旧要件を揃えるマルチAZやreaderは障害への備えになりますが、誤操作前の状態を戻すにはバックアップの時点と保持を確認します。復元先を作り、ネットワークや設定を整え、アプリが正しく動くまでの時間を比較します。バックアップがあるという有無だけで復旧時間を0とみなしません。

8. 総費用と移行試験候補は計算、保存、I/O、複製・可用性構成、バックアップ等の適用料金を含めて比較します。ベンチマークは自社のクエリや負荷で行い、一般的な高速化の宣伝値を全アプリへ固定適用しません。移行後の接続、データ、負荷、切替え、復元まで確認して選定を説明します。

図解

DB候補を比較する順序 — サービスの名前や単価だけでは、必要な条件を満たすか判断できません。

重要ポイント

互換エンジンと必要機能を先に照合する。
Multi-AZの配置方式を明記する。
同じ保護要件を満たす構成で費用を比較する。

間違えやすい点

reader追加をwriterの水平分散と同一視する。
Serverlessで保存費も0になると考える。

用語解説

SQL方言: DBエンジンごとのSQL構文や機能の違い。
複製遅延: 元DBの変更が複製先へ届くまでの遅れ。
スケールアップ: 一つの計算資源の能力を増やすこと。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。