AWS RDS（Relational Database Service）

RDSとは

Amazon RDSは、クラウド上でリレーショナルデータベースを簡単にセットアップ、運用、スケーリングできるマネージドサービス。ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなどの煩雑な管理作業をAWSが代行してくれる。

RDSを使うメリット

対応データベースエンジン

RDSは6つのデータベースエンジンに対応している。

エンジン一覧

エンジン選定の指針

RDSの基本アーキテクチャ

コンポーネント

DBインスタンスクラス

RDSのインスタンスクラスはEC2のインスタンスタイプに類似しており、CPU・メモリの組み合わせで選択する。

DBサブネットグループ

RDSインスタンスを配置するサブネットの集合。少なくとも2つ以上のAZにまたがるサブネットが必要。

DBサブネットグループ
├── サブネット: subnet-aaa (AZ: ap-northeast-1a) - 10.0.10.0/24
├── サブネット: subnet-bbb (AZ: ap-northeast-1c) - 10.0.11.0/24
└── サブネット: subnet-ccc (AZ: ap-northeast-1d) - 10.0.12.0/24

Multi-AZ（高可用性）

Multi-AZデプロイメント

Multi-AZを有効にすると、プライマリインスタンスとは異なるAZにスタンバイインスタンスが自動的に作成される。プライマリに障害が発生した場合、自動的にスタンバイへフェイルオーバーする。

Multi-AZの動作

通常時:
  アプリ → RDSエンドポイント → プライマリ(AZ-a) ←同期→ スタンバイ(AZ-c)

障害発生時:
  1. プライマリ(AZ-a)に障害検知
  2. スタンバイ(AZ-c)をプライマリに昇格
  3. DNSレコードを新プライマリに自動変更
  4. アプリは同じエンドポイントで接続継続

Multi-AZクラスター（新機能）

MySQL/PostgreSQLで利用可能な新しいMulti-AZデプロイメントオプション。1つのプライマリと2つのリーダーインスタンスで構成され、リーダーインスタンスへの読み取りが可能。

リードレプリカ

リードレプリカとは

プライマリインスタンスの読み取り専用コピー。非同期レプリケーションで、読み取りトラフィックをスケールアウトできる。

リードレプリカの使い方

書き込み（INSERT/UPDATE/DELETE）:
  アプリ → プライマリエンドポイント → プライマリDB

読み取り（SELECT）:
  アプリ → リーダーエンドポイント → リードレプリカ1
                                  → リードレプリカ2
                                  → リードレプリカ3

リードレプリカのユースケース

• 読み取り負荷の分散: レポーティングやBI用のクエリをレプリカに振り分け
• DRサイト: クロスリージョンレプリカをDR用に活用
• マイグレーション: レプリカを昇格させてエンジンアップグレード

Amazon Aurora

Auroraとは

AWSが独自に開発したクラウドネイティブなリレーショナルデータベース。MySQL及びPostgreSQLと互換性があり、標準的なRDSと比較して最大5倍（MySQL）/ 3倍（PostgreSQL）のスループットを実現する。

Auroraのアーキテクチャ

Auroraは従来のRDSとは根本的に異なるストレージアーキテクチャを持つ。

Auroraの特徴的な機能

Aurora Serverless v2:

• 需要に応じてコンピュートキャパシティが自動スケーリング
• ACU（Aurora Capacity Unit）単位でのスケーリング（0.5 ACU〜128 ACU）
• 開発/テスト環境や変動するワークロードに最適
• プロビジョンドインスタンスとServerlessの混在が可能

Aurora Global Database:

• 最大5つのリージョンにまたがるレプリケーション
• リージョン間レプリケーション遅延は通常1秒未満
• DRシナリオで別リージョンへ1分以内にフェイルオーバー可能

Aurora Cloning:

• プロダクションデータベースのクローンを数分で作成
• Copy-on-Write方式で追加のストレージコストを抑制
• テスト環境やデバッグ用に活用

RDS Proxy

RDS Proxyとは

RDSのためのフルマネージドデータベースプロキシ。データベース接続のプーリングと共有を行い、アプリケーションのスケーラビリティと可用性を向上させる。

RDS Proxyが解決する問題

RDS Proxyのアーキテクチャ

RDS Proxyの設定ポイント

• 対応エンジン: MySQL、PostgreSQL、MariaDB、SQL Server（Aurora含む）
• 接続プーリング: MaxConnectionsPercentでプール可能な接続数の割合を設定（デフォルト100%）
• IAM認証: RDS ProxyへのアクセスにIAM認証が利用可能
• Secrets Manager統合: DB認証情報をSecrets Managerで安全に管理
• ピン留め（Pinning）: セッション固有の状態を使う接続はプーリングから除外される

バックアップとリストア

自動バックアップ

RDSはデフォルトで自動バックアップが有効。

手動スナップショット

ユーザーが任意のタイミングで作成するスナップショット。自動バックアップと異なり、明示的に削除するまで保持される。

ユースケース:

• メジャーバージョンアップグレード前
• 大規模なデータマイグレーション前
• 本番環境のスナップショットを別アカウントに共有

ポイントインタイムリカバリ（PITR）

自動バックアップの保持期間内の任意の時点にデータベースを復元できる機能。5分前までの復元が可能。

バックアップの仕組み:
  日次スナップショット + 5分ごとのトランザクションログ → 任意時点に復元可能

リストア時の注意:
  - 復元先は新しいDBインスタンスとして作成される
  - 既存のインスタンスに上書き復元はできない
  - 復元後にエンドポイントが変わるため、アプリケーション側の設定変更が必要

パラメータグループとオプショングループ

パラメータグループ

データベースエンジンの設定パラメータを管理するコンテナ。

よく変更するパラメータ例（MySQL）:

適用タイミング

セキュリティ

ネットワークセキュリティ

インターネット
    ↓ ×（プライベートサブネットなのでアクセス不可）
VPC
├── パブリックサブネット
│   └── EC2（アプリケーション）
│       ↓ ポート3306許可（セキュリティグループ）
├── プライベートサブネット
│   └── RDSインスタンス（パブリックアクセス: 無効）
└── セキュリティグループ: アプリのSGからのみ3306許可

ベストプラクティス:

• RDSはプライベートサブネットに配置する
• パブリックアクセスは原則無効にする
• セキュリティグループでアプリケーションのSGからのみポート許可
• NACLで追加のネットワーク制御

暗号化

注意点:

• 暗号化は作成時にのみ設定可能。既存の非暗号化インスタンスを暗号化するには、スナップショットを取得→暗号化コピー→復元が必要
• リードレプリカはプライマリと同じ暗号化設定を継承する

IAM認証

RDSはIAM認証もサポートしている。パスワードの代わりにIAMの認証トークンを使用してデータベースに接続できる。

• MySQL、PostgreSQL、MariaDBで対応
• トークンの有効期限は15分
• パスワード管理が不要になりセキュリティが向上
• Secrets Managerとの併用も推奨

監視とメンテナンス

CloudWatch メトリクス

Enhanced Monitoring

• OS レベルのメトリクス（プロセス、メモリ、ファイルシステム等）を1秒間隔で取得
• CloudWatch Logsに送信
• 標準のCloudWatchメトリクスでは見えないOS内部の情報を確認可能

Performance Insights

• SQLクエリレベルのパフォーマンス分析ツール
• 「データベースの負荷（DB Load）」を時系列で可視化
• Top SQLでボトルネックとなっているクエリを特定
• 待機イベント分析で何がパフォーマンスを制限しているか把握

メンテナンスウィンドウ

• AWSによるパッチ適用やマイナーバージョンアップグレードの時間帯
• 週次で30分のウィンドウを指定
• Multi-AZの場合、スタンバイ→プライマリの順で適用しダウンタイムを最小化

料金

課金の構成要素

コスト最適化のポイント

無料利用枠（12か月）

• db.t2.micro / db.t3.micro / db.t4g.micro: 月750時間
• ストレージ: 20GB（gp2）
• バックアップストレージ: 20GB

実務でのRDS設計パターン

パターン1: Webアプリケーション標準構成

ALB → EC2(Auto Scaling) → RDS(Multi-AZ) + リードレプリカ
                                ↓
                         Secrets Manager（認証情報管理）

• Multi-AZで高可用性を確保
• リードレプリカで読み取り負荷を分散
• Secrets Managerでパスワードのローテーション自動化

パターン2: サーバーレス構成

API Gateway → Lambda → RDS Proxy → Aurora Serverless v2
                           ↓
                     Secrets Manager

• Lambda同時実行による接続数爆発をRDS Proxyで解決
• Aurora Serverless v2でコスト最適化
• Secrets Manager統合でセキュアな認証

パターン3: マルチリージョンDR構成

東京リージョン:
  Aurora MySQL（プライマリクラスター）
    ├── ライターインスタンス
    └── リーダーインスタンス x 2
        ↓ グローバルデータベース（<1秒遅延）
大阪リージョン:
  Aurora MySQL（セカンダリクラスター）
    └── リーダーインスタンス x 1

• Aurora Global Databaseでクロスリージョンレプリケーション
• 大阪リージョンで読み取りリクエストを処理（レイテンシ低減）
• 東京リージョン障害時に大阪へフェイルオーバー

マイグレーション

AWS Database Migration Service（DMS）

既存のデータベースをRDSに移行するためのサービス。

移行のステップ

1. AWS Schema Conversion Tool（SCT） でスキーマを変換（異種移行の場合）
2. DMS レプリケーションインスタンス を作成
3. ソースエンドポイント（移行元DB）とターゲットエンドポイント（RDS）を設定
4. タスク を作成して移行を実行
5. 全データ移行完了後、CDC（差分同期）で同期を継続
6. アプリケーションの接続先をRDSに切り替え

トラブルシューティング

よくある問題と対処法

参考文献

• Amazon RDS 公式ドキュメント
• Amazon Aurora 公式ドキュメント
• RDS Proxy 公式ドキュメント
• RDS の料金
• Aurora の料金
• AWS Database Migration Service
• RDS ベストプラクティス
• Performance Insights
• AWS Well-Architected Framework - Reliability Pillar