AWSデータベースサービスの特徴と選び方

アプリケーションのデータ保存先を決めるときは、データの形だけでなく、更新方法、検索パターン、整合性、可用性、運用体制、コストを合わせて考えます。AWSには、SQLで扱うリレーショナルデータベースから、キー・値型、ドキュメント型、グラフ型、インメモリ型、分析用データウェアハウスまで、用途に応じたマネージドサービスがあります。

リレーショナルと非リレーショナル

リレーショナルデータベース

リレーショナルデータベースは、データを行と列からなるテーブルに格納します。各列のデータ型や制約などのスキーマを定義し、主キーや外部キーを使って複数のテーブル間の関係を表現できます。SQLによる検索・更新、複数テーブルを結合する問い合わせ、トランザクションが重要な業務で広く使われます。

たとえば、オンライン講座の受講情報を「受講者」「講座」「登録」のテーブルに分け、識別子で関連付ける設計では、登録の整合性を保ちながら検索しやすくできます。リレーショナル型は構造や関係を明確に扱える一方、テーブル間の結合や厳密なトランザクションが不要な大量アクセスでは、用途に合う別のデータモデルの方が適する場合があります。

非リレーショナルデータベース

非リレーショナルデータベース（NoSQL）は、単一の製品形式を指す言葉ではありません。キー・値、ドキュメント、グラフ、ワイドカラムなど、異なるデータモデルを含みます。製品ごとにデータの構造、問い合わせ方、整合性、トランザクション、スケールの方法が異なるため、「NoSQLならどのようなデータにも同じ方法で対応できる」と考えてはいけません。

多くのNoSQLサービスは、行の関係や固定的な表形式に依存しないデータ設計を選べます。ただし、スキーマ設計が不要になるわけではありません。アプリケーションが必要とする読み書きパターンに合わせて、キー、インデックス、パーティション、データ階層などを設計します。アクセスパターンを後から大きく変えると、データの持ち方やインデックスを見直す必要が生じます。

観点	リレーショナル	非リレーショナル
主なデータ表現	行と列からなるテーブル	キー・値、ドキュメント、グラフなど製品固有のモデル
問い合わせ	SQL、結合、集計など	サービスやデータモデルに応じたAPI・問い合わせ方法
強みになりやすい要件	関係性、制約、複数行にまたがる処理	大規模分散、特定アクセスパターンへの最適化、柔軟な属性
設計で確認すること	スキーマ、キー、結合、トランザクション、容量	パーティションやキー、インデックス、整合性、ホットスポット

この分類は選択の入口です。実際には、一つのサービスが複数の機能や互換性を持つ場合もあるため、SQLの有無だけでサービスを決めず、必要なデータ操作と運用特性を照らし合わせます。

AWSの代表的なデータベースサービス

AWSのデータベース群は、データ形式やワークロードに応じて選びます。以下は代表的なサービスと主な役割です。機能、エンジン、提供リージョンは更新されるため、設計時には各サービスの最新ドキュメントも確認します。

データベースの用途・モデル	AWSサービス	選択時に見るポイント
リレーショナルデータベース	Amazon RDS	複数の一般的なデータベースエンジンをマネージドで実行する。必要なエンジン、互換性、インスタンス運用を確認する
クラウド向けリレーショナルデータベース	Amazon Aurora	MySQL／PostgreSQL互換のエンジンを選べる。クラスター構成、ストレージ、リーダー、接続方法を要件に合わせる
キー・値／ドキュメントデータベース	Amazon DynamoDB	サーバーレスのNoSQLサービス。キー設計、アクセスパターン、容量モード、整合性、インデックスが重要
インメモリデータベース／キャッシュ	Amazon ElastiCache	対応エンジンを使った低レイテンシのキャッシュやデータ処理に向く。キャッシュの有効期限、失効、ノード構成を設計する
分析用データウェアハウス	Amazon Redshift	大量データの集計・分析など分析処理に使う。トランザクション中心のアプリケーションDBとは用途を分ける
ドキュメントデータベース	Amazon DocumentDB	MongoDB互換のAPIを必要とするワークロードで候補になる。互換性や実装差を検証する
Apache Cassandra互換のワイドカラムDB	Amazon Keyspaces	Cassandra互換アプリケーション向けのサーバーレスサービス。クエリとデータモデルの制約を確認する
グラフデータベース	Amazon Neptune	関係をたどるグラフ型の問い合わせに向く。対応するグラフモデルと問い合わせ言語を確認する
時系列データベース	Amazon Timestream	時刻に沿って増えるデータの取り込みや分析向け。対象ワークロードや現行の提供サービス・機能を確認する

同じアプリケーションでも、すべてのデータを一種類のデータベースに集約する必要はありません。たとえば受講者と契約の整合性を重視する領域にリレーショナルDBを使い、急増するセッション状態をキー・値ストアへ置き、利用ログの集計をデータウェアハウスで行うように、責務を分ける構成もあります。複数の保存先を採用する場合は、データの重複、同期方法、障害時の復旧順序、各データストアの権限を設計します。

マネージドデータベースへ移行する利点と責任

オンプレミス環境では、物理サーバー、ストレージ、ネットワーク、OS、データベースソフトウェアの導入や保守などを組織が広く担当します。AWSのマネージドデータベースを使うと、サービスが担う範囲のインフラ管理や、バックアップ、監視、メンテナンスなどの作業を自動化・委任し、アプリケーションとデータ設計に集中しやすくなります。

ただし、マネージドは「運用作業が一切不要」という意味ではありません。利用者は、エンジンとバージョン、容量、ネットワーク到達性、バックアップ保持、メンテナンス時間、暗号化、認証・認可、監視項目、復旧目標を選びます。サービスが自動で行う処理も、対象サービスや設定によって範囲が異なります。バックアップが有効であることを確認するだけでなく、復元手順と復旧時間を実際に検証することも必要です。

可用性、自動フェイルオーバー、読み取り拡張

単一のデータベースインスタンスだけで運用すると、インスタンスや配置先に障害が起きた際にアプリケーションがデータベースへ接続できなくなる可能性があります。対応する構成では、複数のアベイラビリティーゾーン（AZ）にデータベースの待機系や複製データを用意し、障害時に別の系へ切り替えることで可用性を高めます。

Multi-AZ構成は、主に可用性と障害時の切り替えを目的にします。Amazon RDSのMulti-AZ DBインスタンス配置では、プライマリとは別のAZにスタンバイを同期レプリケーションで用意します。このスタンバイはフェイルオーバー用で、通常の読み取り処理は受け付けません。障害時にはサービスが自動フェイルオーバーを行い、接続先エンドポイントは維持される設計ですが、切り替え中に短い接続断が起きる可能性があります。アプリケーション側も再接続やリトライを適切に扱う必要があります。

RDSにはMulti-AZ DBクラスター配置もあります。この構成は2台のスタンバイDBインスタンスを持ち、障害時の切り替えに加えて読み取りトラフィックも処理できます。「Multi-AZのスタンバイは読み取りに使えない」とすべての構成へ広げず、1台のスタンバイを持つDBインスタンス配置か、2台のスタンバイを持つDBクラスター配置かを区別してください。Auroraも独自のクラスターと分散ストレージの仕組みを使うため、すべてのAWSデータベースを同じ複製方式で説明できるわけではありません。

一方、リードレプリカは、プライマリからデータを複製した読み取り先を追加し、参照処理を分散するために使います。複製には遅延が生じる場合があるため、更新直後の読み取りに常に最新値が必要な処理を無条件にレプリカへ送ると、古い値を返すことがあります。リードレプリカをプライマリへ昇格して復旧に利用できる場合もありますが、通常のMulti-AZスタンバイと役割・切り替えの性質は同じではありません。

上図は構成の違いを並べたもので、単一のデータベース製品ですべてを常に同じ方法で組み合わせる意味ではありません。同期・非同期などの複製方式、レプリカ数、障害時の昇格動作、エンドポイントの仕組みはサービスとエンジンで異なります。設計・試験ではMulti-AZ構成の種類も確認したうえで、可用性と読み取り拡張のどちらを担う配置なのかを判断します。

リードレプリカやグローバル複製に対応するサービス・エンジンでは、別リージョンにもデータを複製できる場合があります。リージョンを越える構成は、リージョン障害への備え、利用者に近い場所での読み取り、災害復旧などに使えます。一方、複製遅延、データ転送コスト、昇格や書き込み先切り替えの手順が関係します。レプリカを作成しただけで、すべてのリージョン障害から自動復旧できるとは限りません。

監視、セキュリティ、コスト

監視と運用連携

マネージドデータベースは、Amazon CloudWatchなどの監視・ログ基盤と連携し、CPUや接続数、ストレージ、レイテンシなどサービスごとのメトリクスを確認できます。しきい値に応じたアラームや通知を構成し、通常時の傾向と障害時の変化を比較できるようにします。メトリクスの種類や詳細度はサービスによって異なり、ログの出力・保存にも別の設定や料金が関係することがあります。

監視は「サーバーが起動しているか」だけでは不十分です。アプリケーションの応答時間、接続エラー、クエリの遅延、複製遅延、容量の枯渇を合わせて観察し、必要に応じて通知先や運用ダッシュボードへつなぎます。

データ保護とアクセス制御

データベースに保存するデータと、クライアント・アプリケーションからデータベースまでの通信を暗号化できます。保存時の暗号化は、サービスが対応する暗号化キーやスナップショットなどへの適用範囲を確認します。転送時はTLSを使えるか、クライアントが証明書や接続設定を正しく検証しているかを確認します。サービス側で保存データが暗号化されていても、アプリケーションの認証・認可が自動的に適切になるわけではありません。

AWS IAMのポリシーは、サービス管理APIや、対応するデータベースの認証機能を通じたアクセス制御に使われます。データベース内のユーザー、ロール、テーブル権限などとIAM権限は役割が異なる場合があります。アプリケーションの実行ロールや接続ユーザーに必要な操作だけを許可し、ネットワーク制御、シークレット管理、暗号化設定も併用します。

従量課金と費用の見積もり

マネージドDBでは、物理機器を事前に購入する代わりに、選択した容量や実際の利用に応じて費用を支払う従量課金を利用できます。しかし、「使った分だけ」の内訳はサービスごとに異なります。代表的な課金要素には、DBインスタンスやキャパシティの稼働時間、ストレージ容量、I/Oやリクエスト、バックアップ、レプリカ、データ転送などがあります。選んだ料金モデルやリージョン、エンジンによっても異なるため、必要な可用性・性能を満たす構成全体で見積もります。

コストを比較するときは、単一インスタンスの料金だけでなく、Multi-AZ、読み取りレプリカ、バックアップ保持、監視ログ、リージョン間転送まで含めます。要求量に合わせて容量を調整できるモデルがあっても、設定した上限、スケール条件、最低利用量などの仕様を確認します。最新の課金単位と単価は各サービスの公式料金ページで確認してください。

要件から選択肢を絞る

候補を選ぶときは、まずアプリケーションのデータとアクセス方法を言語化します。

1. データの関係と操作: 関連テーブル間の結合やトランザクションが中心ならリレーショナルDBを検討します。キーから項目を取得する大量アクセスならDynamoDBなどのNoSQLを比較します。
2. アクセスパターンとレイテンシ: 参照頻度、書き込み量、データ量、応答時間、分析クエリの有無を見ます。頻繁に再利用するデータのキャッシュにはElastiCacheを候補にできます。
3. 可用性と復旧: AZ障害への継続性、読み取り拡張、リージョン障害への復旧目標を分けて定義します。Multi-AZ、レプリカ、バックアップは目的が異なります。
4. 運用とセキュリティ: エンジン互換性、保守作業、バックアップ・復元、監視、暗号化、IAMやデータベース内権限の要件を確認します。
5. 費用: 計算資源、容量、複製、バックアップ、リクエスト、I/O、転送の課金要素を含め、需要の変化や障害対応時の余力も見積もります。

設計例として、イベント予約サービスで予約確定時に複数データの整合性を保つ領域にはリレーショナルDBを使い、開催一覧の参照結果をキャッシュし、アクセス履歴を別の分析基盤へ渡す構成が考えられます。重要なのは製品名から出発するのではなく、必要な整合性・クエリ・性能・運用要件を整理し、それに合うサービスの現行機能を選ぶことです。

AWS公式ドキュメント

• AWSデータベースサービス
• Amazon RDSユーザーガイド: 高可用性（マルチAZ）
• Amazon RDSユーザーガイド: リードレプリカ
• Amazon Auroraユーザーガイド
• Amazon DynamoDB開発者ガイド
• Amazon RDSの料金