本ページは、AWS に関する個人の勉強および勉強会で使用することを目的に、AWS ドキュメントなどを参照し作成しておりますが、記載の誤り等が含まれる場合がございます。

最新の情報については、AWS 公式ドキュメントをご参照ください。

• RDS について知るには
• Aurora について知るには
• RDS / Aurora について知るには(その他)
• RDS と Aurora の比較サマリ
• 比較ポイント１：データベースエンジン
• 比較ポイント２：ストレージアーキテクチャと耐久性
• 比較ポイント３：ストレージの容量拡張
• 比較ポイント４：可用性
• 比較ポイント５：読み取りスループット向上
• 比較ポイント６：自動バックアップの保持期間
• 比較ポイント７：データの復元
• 比較ポイント８：キャッシュ
• 比較ポイント９：価格
• 📖 RDS と Aurora どっちを使うかフロー

【AWS Black Belt Online Seminar】Amazon Relational Database Service (Amazon RDS)(YouTube)(52:48)

Amazon RDS サービス概要

Amazon RDS ドキュメント

Amazon RDS よくある質問

【AWS Black Belt Online Seminar】Amazon Aurora MySQL(YouTube)(55:41)

【AWS Black Belt Online Seminar】Amazon Aurora MySQL Compatible Edition ユースケース毎のスケーリング手法(55:41)

【AWS Black Belt Online Seminar】Amazon Aurora with PostgreSQL Compatibility(YouTube)(1:03:46)

RDS/Aurora Update | 2.5 時間で学ぶ！ Amazon Aurora のいま(YouTube)(27:33)

Amazon Aurora サービス概要

Amazon Aurora ドキュメント

Amazon Aurora よくある質問

【AWS Summit Tokyo 2019】AWS におけるデータベースの選択指針(39:25)

【AWS Summit Tokyo 2019】Amazon RDS におけるパフォーマンス最適化とパフォーマンス管理(41:33)

【AWS Summit Tokyo 2019】Amazon Aurora with PostgreSQL Compatibility における運用設計のファーストステップ(39:53)

【AWS Summit Tokyo 2019】Amazon Aurora storage demystified: How it all works (DAT309-R)(1:04:45)

比較のサマリは以下の通りです。

MySQL や PostgreSQL を選択する場合で、Aurora 制約事項（*1、*2）を許容できる場合は、Aurora が最適となるケースが多いです。

Aurora がサポートしないデータベースエンジンを使用したい場合は、RDS が最適となるケースが多いです。ただし、RDS にも制約事項(*3)があるため、EC2 でインスタンスを構築するケースもあります。

*1 Aurora では、MySQL も PostgreSQL も互換であり、AWS によって Aurora のアーキテクチャに合うように改修を加えたものです。

*2 上記*1 の影響もあり、最新バージョンへの対応は RDS より遅い傾向にあります。

*3 RDS では Oracle RAC がサポートされていません。SQL Server では、sysadmin などのサーバーレベルロールが使用できません。詳細は、「よくある質問」やドキュメントを参照してください。

RDS と Aurora の大きく異なる点といえば、ストレージのアーキテクチャです。

RDS の方は EC2 に MySQL や PostgreSQL をインストールする場合と同じように、インスタンスに EBS が紐づいており、マルチ AZ の場合もそれぞれに EBS を持っています。 ミラーリング用の EBS で耐久性を高めています。

https://www.youtube.com/watch?v=oJqIzHIMh7Q&t=24m24s

Aurora の方は、インスタンスとストレージが分離しています。さらに、3 AZ に 6 つのデータのコピーが作成され、耐久性が高められています。

https://www.youtube.com/watch?v=oJqIzHIMh7Q&t=25m49s

RDS でストレージの自動スケーリングがサポート（Jun 20, 2019 - Amazon RDS で Storage Auto Scaling のサポートを開始）されましたので、RDS も Aurora もストレージの自動拡張が可能ですが、RDS の自動スケーリングにはデメリットもあります。

*1 Amazon Aurora サイズ制限

*2 Amazon RDS ストレージの自動スケーリングによる容量の自動管理

• ストレージの自動スケーリングの発動条件
  • 空き容量が割り当てられたサイズの 10 % 未満
  • 低ストレージ状態が 5 分以上継続
  • 最後のストレージ変更後から 6 時間経過
    • この制約があるため、RDS の自動スケーリングはストレージ不足状態を完全に防ぐことはできません。
    • 自動スケーリング後に大量のデータロードが発生した場合に数時間ストレージ容量不足状態になる可能性があります。
• 追加ストレージは以下のうち大きい方
  • 5 GiB
  • 割り当てられているサイズの 10 %
  • 直近 1 時間の FreeStorageSpace メトリクスの変動に基づいて予測される 7 時間のストレージの増分

*3 Aurora ストレージのサイズを自動的に変更する方法

*4 ストレージのスケーリング

• Aurora のストレージは 1 時間ごとに評価されます。

*5 ストレージの自動スケーリングをオンにした後に、Amazon RDS の DB インスタンスの空きストレージ容量が少ない状態になったり、storage-full 状態になったりするのはなぜですか?

• RDS のストレージの自動スケーリングは有効にする前に、ドキュメントやよくある質問などをよく読み、利用するかどうかを慎重に検討する必要があります。

RDS は マルチ AZ の場合のみ、スタンバイにフェールオーバーし、60 秒で自動的に復旧します。 シングル AZ の場合、自動的に復旧できないので、スナップショットから手動復旧が必要になります。 マルチ AZ は、プライマリインスタンスとスタンバイインスタンスで構成されます。プライマリインスタンスからスタンバイインスタンスには、同期的にレプリケーションされます。 通常、スタンバイインスタンスにはアクセスできません。

Aurora はレプリカが存在する場合は、レプリカにフェールオーバーし、60 秒から 120 秒で復旧します。 レプリカが存在しない場合、同じ AZ 内に新規インスタンスが作成され、10 分以内に復旧します。AZ 障害時にはフェールオーバーが失敗する可能性があります。

Aurora レプリカのフェールオーバーは優先順位を設定することが可能です。

たとえば、バッチ処理やデータのエクスポートなど負荷の高い処理に使用しているレプリカの優先順位を下げておくといったことが可能です。

Aurora DB クラスターの耐障害性

RDS / Aurora ともに、AWS マネジメントコンソール、AWS CLI から手動でフェールオーバーすることができます。

プライマリインスタンスへの読み取りアクセスを分散することで、スループットを向上できます。

RDS ではリードレプリカを追加することができます。リードレプリカは、「インスタンス + EBS + ミラーリング EBS 」のセットが増えていきます。

Aurora ではレプリカを追加すると、「インスタンス」のみが増えていきます。

Aurora のレプリカは、オートスケーリングによってスケールアップ／ダウンが可能です。

Aurora レプリカでの Amazon Aurora Auto Scaling の使用

RDS は 0 ～ 35 日(デフォルトは 7 日)で、0 日にすることでバックアップを無効化できます。

Aurora は 1 ～ 35 日(デフォルトは 1 日)となっており、0 日に設定できないため、バックアップを無効にすることは出来ません。

自動バックアップは、インスタンスが起動している間のみ取得されます。ドキュメントには以下の記述があります。

自動バックアップを行うには、DB インスタンスが AVAILABLE 状態になっている必要があります。
DB インスタンスが AVAILABLEなどの STORAGE_FULL 以外の状態にある間は、自動バックアップは行われません。

バックアップの使用

また、よくある質問には以下の記述があります。

>自動化された DB スナップショットの数が、DB インスタンスに対するリテンション期間の日数よりも多いのはなぜですか?

リテンション期間の日数よりも 1 日か 2 日自動化 DB のスナップショットの日数が多いのは正常です。
自動化スナップショットは 1 日余計にとられていて、リテンション期間中のいつにでも復帰できる時点を設けています。

例えば、バックアップウィンドウが 1 日に設定されている場合、自動化スナップショットは 2 つ必要で、
これで過去 24 時間中の任意の時点への復帰をサポートしています。
また、さらに多くの自動化スナップショットがある場合もありますが、これは新たな自動化スナップショットが、
最も古い自動化スナップショットを削除する前に常に生成されるためです。。

よくある質問

RDS / Aurora を停止している時間は保持期間の計算に含まれないので、保持期間より多い日数のスナップショットが存在している場合もあります。

ドキュメントには以下の記述があります。

7 日分保持する設定にしていた場合、24 時間 × 7 日 = 168 時間になりますが、RDS を夜間に 12 時間停止していた場合、168 / 12 = 14 日となるということでしょうか。

DB インスタンスが停止している場合、バックアップ保持期間より長くバックアップを保持できます。
RDSには、バックアップ保存期間の計算時にstopped状態にあった時間は含まれません。

RDS バックアップの保存期間

また、手動で取得したバックアップ（スナップショット）は保持期間の影響を受けないため、手動で削除する必要があります。

RDS と Aurora のともにポイントインタイムリカバリとして、5 分前まで秒単位で復元が可能です。

復元といっても「特定地点のデータ状態のデータベースクラスタを再作成する機能」ですので注意が必要です。

データベースクラスタ内でデータのみをリカバリするわけではありません。

RDS ではデータベースインスタンス内にキャッシュを持つが、Aurora では、データベースとは分離して管理しています。

Aurora PostgreSQL は、クラスタキャッシュ管理という仕組みで、プライマリインスタンスが持っているキャシュを特定のレプリカと共有することで、フェールオーバー時にキャッシュが失われて、処理性能が低下することを抑えることが可能になっています。

Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ

RDS では、リードレプリカもプライマリインスタンス同様に、ストレージ料金も必要になります。 Aurora は、ストレージ I/O の料金が追加で必要になります。ただし、Aurora のレプリカはストレージ料金がかかりません。

東京リージョンで、データベースエンジンが「MySQL」、インスタンスタイプ「db.r6g.large」、データベース容量が「1,000 GB」 、1 秒当たり 100 ページを読み取る I/O （1 か月辺り 3 億 I/O）が発生する場合、次のようになります。

RDS（マルチ AZ）は月額「748.30USD」、Aurora（+レプリカ）は月額「720.98USD」となり、今回のケースでは、Aurora のほうがコスト面で割安となりました。 ただし、Aurora はデータ I/O 次第で RDS を上回る可能性もあります。

レプリカが必要になった場合でも、Aurora のほうが割安となりました。