Amazon RDS と Aurora

このページで押さえる論点

• RDS の基本（DB インスタンス・エンドポイント・AWS と利用者の役割分担）
• 高可用性: マルチ AZ DB インスタンスとマルチ AZ DB クラスターの違い、フェイルオーバー
• 読み取りの拡張: リードレプリカ（マルチ AZ との使い分け・昇格）
• Aurora のしくみ（6 つのコピー・Aurora レプリカ・エンドポイント）
• リージョン障害への備え: クロスリージョンリードレプリカと Aurora Global Database（RPO・RTO）
• 容量の変動への対応: Aurora Serverless v2 とストレージの自動スケーリング
• 接続の管理: RDS Proxy
• セキュリティ: 暗号化（作成時のみ）と IAM データベース認証
• バックアップと復元: 自動バックアップ・ポイントインタイムリカバリ・スナップショット
• データベースの選び方（RDS・Aurora・DynamoDB）

RDS の基本

RDS では、データベースを動かすサーバーを DB インスタンスと呼びます。OS やデータベースソフトの更新、自動バックアップなどを AWS が行うので、利用者はテーブル設計やクエリ（問い合わせ）に集中できます。一方で、データベースの中のデータ、DB ユーザーの権限、クエリのチューニングは利用者の責任です。

アプリは、DB インスタンスの IP アドレスではなくエンドポイント（接続先の DNS 名。例: mydb.xxxx.ap-northeast-1.rds.amazonaws.com）に接続します。障害で裏側の DB が入れ替わっても、エンドポイントの名前は変わりません。

高可用性: マルチ AZ 配置

マルチ AZ 配置は、別の AZ（独立したデータセンター群）に控えの DB を置き、障害時に自動で切り替える（フェイルオーバーする）構成です。RDS には次の 2 種類があり、スタンバイを読み取りに使えるかどうかが違います。試験では「マルチ AZ」とだけ書かれていることも多いので、どちらの話かを見分けます。

同期レプリケーションとは、書き込みのたびにプライマリとスタンバイの両方へ書いてから完了とする方式です。切り替えてもデータが失われません。フェイルオーバーでは、エンドポイントの DNS レコードが新しいプライマリを指すように切り替わるので、アプリは接続先の設定を変えずに再接続するだけで済みます。

下の図は、試験でよく出るマルチ AZ DB インスタンス配置の動きです。

読み取りの拡張: リードレプリカ

リードレプリカは、プライマリのデータを非同期レプリケーション（書き込み完了を待たず、少し遅れてコピーする方式）で受け取る読み取り専用のコピーです。読み取りの多いアプリや、集計・レポート用のクエリを本番から切り離したいときに使います。アプリ側で、読み取りのクエリをリードレプリカのエンドポイントに向ける必要があります。

リードレプリカは別の AZ や別のリージョンにも作れます。プライマリに障害が起きても自動では昇格しませんが、手動で昇格させると独立した DB インスタンスになり、書き込みもできるようになります。マルチ AZ 配置の DB インスタンスにリードレプリカを追加することもできるので、「可用性」と「読み取り性能」の両方が必要なら両方を組み合わせます。

非同期なので、リードレプリカのデータはプライマリより少し遅れることがあります（レプリカラグ）。書き込んだ直後の値を必ず読みたい処理はプライマリから読みます。

Aurora のしくみ

Aurora は MySQL・PostgreSQL と互換性のあるデータベースで、計算（DB インスタンス）とストレージ（データの保存先）が分かれているのが特徴です。データは 1 つのクラスターボリュームに保存され、書き込みのたびに 3 つの AZ にまたがる 6 つのストレージノードへ同期でコピーされます。DB インスタンスが何台でも、このコピーの数は変わりません。クラスターボリュームはデータ量が増えると自動で拡張されるので、容量を前もって確保しておく必要はありません。

書き込み用のプライマリに加えて、読み取り用の Aurora レプリカを最大 15 台置けます。レプリカは同じクラスターボリュームを読むので、データを丸ごとコピーせずに追加できます。プライマリに障害が起きるとレプリカの 1 台が自動で昇格し、通常 60 秒未満（多くは 30 秒未満）で復旧します。レプリカがない場合はプライマリを作り直すため、通常 10 分未満かかります。

リージョン障害への備え

マルチ AZ はリージョン内の AZ 障害への備えで、リージョン全体が使えなくなる災害には対応できません。別リージョンにデータを置くには次の方法があります。災害対策（DR）の設計では、RPO（目標復旧時点。何秒・何分前までのデータを取り戻せればよいか）と RTO（目標復旧時間。どれくらいで復旧すればよいか）で方式を選びます。

Aurora Global Database のセカンダリリージョンは読み取り専用なので、世界各地のユーザーに近い場所で読み取りを速くする目的にも使えます。

容量の変動への対応

Aurora Serverless v2 は、アプリの負荷に合わせて Aurora の DB インスタンスの容量を自動で増減する設定です。容量は ACU（Aurora キャパシティーユニット。1 ACU は約 2 GiB のメモリと、それに見合う CPU・ネットワーク）で表し、0.5 ACU 単位の細かさで調整されます。エンジンのバージョンによっては最小を 0 ACU にでき、使われていない間は自動で一時停止します。アクセス量の予測がつかない、急に増えることがある、夜間はほとんど使わない、といったワークロードに向きます。同じクラスターの中で、通常の（プロビジョンド）インスタンスと Serverless v2 のインスタンスを混ぜることもできます。

RDS のストレージの自動スケーリングを有効にすると、空き容量が少なくなったときに自動でストレージを増やします。空き容量が割り当て容量の 10% 未満の状態が 5 分以上続く、などの条件を満たすと拡張され、上限は利用者が決める「最大ストレージしきい値」までです。容量不足で DB が止まるのを防ぎたいが、手作業の監視はしたくない、という要件で選びます。

接続の管理: RDS Proxy

RDS Proxy は、アプリと DB の間に置く接続の中継役です。DB への接続をプール（あらかじめ用意した接続を使い回すこと）して共有するので、毎回接続を作り直す負荷を減らせます。Lambda のように短時間で大量の接続を作るアプリや、予測できない急なアクセス増で DB の接続数があふれそうな場合に使います。

フェイルオーバーのときも、RDS Proxy がアプリからの接続を保ったまま新しい DB に接続し直すので、アプリへの影響が小さくなります。DB のユーザー名とパスワードは AWS Secrets Manager（認証情報を安全に保管するサービス）に置き、アプリは IAM 認証で RDS Proxy に接続する、という構成にもできます。

セキュリティ: 暗号化と IAM データベース認証

RDS の保管時の暗号化は AWS KMS（暗号化キーを管理するサービス）のキーで行い、DB のストレージだけでなく自動バックアップ・リードレプリカ・スナップショットもまとめて暗号化されます。

• 暗号化を有効にできるのは DB インスタンスの作成時だけです。あとから同じ DB を暗号化することはできません。
• 暗号化されていない DB を暗号化したいときは、① スナップショットを取る → ② スナップショットを暗号化を有効にしてコピーする → ③ 暗号化されたスナップショットから新しい DB インスタンスを復元する、という手順になります。
• 暗号化されていない DB から暗号化されたリードレプリカは作れません（逆も同じ）。

IAM データベース認証を使うと、DB 接続にパスワードではなく、IAM の権限で発行される認証トークン（有効期限 15 分）を使えます。DB ユーザーのパスワードを DB やアプリに保存しなくて済みます。対応エンジンは MariaDB・MySQL・PostgreSQL です。

バックアップと復元

RDS の自動バックアップは、毎日の DB のバックアップに加えて、トランザクションログ（変更の記録）を 5 分ごとに S3 へ保存します。これにより、保持期間内の好きな時点に戻すポイントインタイムリカバリができます。

復元すると、元の DB を上書きするのではなく新しい DB インスタンスが作られます。アプリの接続先を新しいエンドポイントに切り替える必要がある点に注意します。「35 日より長く保管したい」という要件は、自動バックアップではなく手動スナップショットで満たします。

データベースの選び方

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「マルチ AZ にすれば読み取り性能が上がる」→ ✕（マルチ AZ DB インスタンスの場合）。スタンバイは読み取りに使えない。ただしマルチ AZ DB クラスターならスタンバイで読み取りできる
• 「リードレプリカがあれば、プライマリ障害時に自動で切り替わる」→ ✕（RDS の場合）。リードレプリカは手動で昇格する。自動で昇格するのは Aurora レプリカ
• 「マルチ AZ でリージョン障害にも備えられる」→ ✕。マルチ AZ は同じリージョンの中だけ。リージョン障害にはクロスリージョンリードレプリカや Aurora Global Database
• 「既存の DB の設定を変えて暗号化を有効にする」→ ✕。暗号化は作成時のみ。スナップショットのコピーで暗号化して復元する
• 「自動バックアップで 1 年間保管する」→ ✕。自動バックアップの保持は最大 35 日。長期保管は手動スナップショット
• 「ポイントインタイムリカバリで元の DB が巻き戻る」→ ✕。新しい DB インスタンスが作られるので、接続先を切り替える

まとめ: SAA 試験で押さえるポイント

• 「AZ 障害に備えて自動で切り替えたい」→ マルチ AZ。マルチ AZ DB インスタンスのスタンバイは読み取りに使えないので、性能向上の手段にはならない
• 「読み取りが多くてプライマリが重い」「集計・レポート用のクエリを本番から切り離したい」→ リードレプリカ（非同期コピー。読み取り専用）
• フェイルオーバー時はエンドポイントの DNS レコードが新しいプライマリを指すので、アプリの接続先の設定は変えなくてよい（再接続は必要）
• リードレプリカは別リージョンにも作れ、災害対策として手動で昇格（独立した DB に切り替え）できる。自動では昇格しない
• Aurora: データを 3 つの AZ にまたがる 6 つのストレージノードに書き込む。Aurora レプリカ（読み取り用）は最大 15 台で、プライマリ障害時はレプリカが自動で昇格する
• Aurora の接続先は、書き込み用のクラスターエンドポイントと、読み取りをレプリカに分散するリーダーエンドポイントを使い分ける
• リージョンをまたぐ DR で RPO 秒単位・RTO 分単位なら Aurora Global Database、接続数の問題なら RDS Proxy、負荷の変動には Aurora Serverless v2
• 暗号化は作成時のみ。自動バックアップの保持は最大 35 日で、復元は新しい DB インスタンスとして作られる