本ページは、AWS に関する個人の勉強および勉強会で使用することを目的に、AWS ドキュメントなどを参照し作成しておりますが、記載の誤り等が含まれる場合がございます。
最新の情報については、AWS 公式ドキュメントをご参照ください。
【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)
【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 と互換性のあるクラウド向けのリレーショナルデータベースを提供するフルマネージドサービスです。
マネジメントコンソールからわずか数クリックで冗長化、バックアップなどが設定されたデータベースを作成できます。
- PostgreSQL(互換)
- MySQL(互換)
RDS とは異なり、Aurora では DB インスタンスとストレージが分離されています。これにより、RDS の 2 倍の性能を発揮すると言われています。
Aurora を構成する要素は次の通りです。
- Aurora DB クラスター
- DB インスタンスとクラスタボリューム
- DB インスタンス
- クラスタボリューム
データベースを作成すると、Writer と Reader のエンドポイントと呼ばれる専用の DNS 名が発行されます。
アプリケーションは、エンドポイントに接続して、データベースへの操作を行います。
このエンドポイントは、各データベースエンジンの接続ポートのみ接続することができます。
単一構成
１つの AZ に プライマリインスタンスを構築した最小構成です。 AZ 障害時にはインスタンスが利用できなくなります。
開発環境や、可用性を求められない場合にコストを低く抑えることが出来る構成です。インスタンスの障害であれば、同じ AZ 内に新規インスタンスが作成され、10 分以内に復旧します。AZ 障害時にはフェールオーバーが失敗する可能性があります。
エンドポイントは Writer と Reader のエンドポイントが自動的に作成されますが、レプリカがない場合は、Reader エンドポイントは プライマリインスタンスに接続します。
読み取りスループットを向上させたい場合は、レプリカを追加します。
レプリカ構成
読み取り頻度の高いデータベースのワークロードに対して、スケールアウトすることにより、パフォーマンスを向上させます。また、プライマリインスタンスに障害が発生した場合は、レプリカにフェールオーバーすることで自動的に復旧します。
レプリカは最大で 15 台まで追加することが可能です。
レプリカへのレプリケーションは非同期で行われます。
エンドポイントは Writer と Reader のエンドポイントが自動的に作成され、Reader エンドポイントは レプリカに負荷分散します。
レプリカのインスタンスタイプがプライマリインスタンスよりも小さい場合、負荷に耐えられないことがあります。ベストプラクティスはクラスター内のすべてのインスタンスを同じサイズにすることです。
リードレプリカは一部のデータベースエンジンを除いて、別リージョンでも作成することができます。（クロスリージョンレプリカ：CRR）
DB エンジン | レプリカ作成可？ | CRR 可能？ | |
PostgreSQL | ○ | ||
MySQL | ○ | ○ | |
レプリカを手動でフェールオーバーさせることで、プライマリインスタンスに昇格させることができます。
RDS のインスタンスタイプは、「db.m6g.large」のように db から始まります。それ以降は、EC2 のインスタンスタイプと同じ構成となっています。
DB インスタンスはインスタンスタイプを変更することができます。インスタンスタイプの変更ではダウンタイムが発生します。
インスタンスタイプの変更は、マネジメントコンソールや AWS CLI を使って手動で追加することができます。変更を適用するには、「すぐに適用」か「次に予定されるメンテナンスウィンドウ中」を選択できます。
クラスタボリュームはデータベースのデータ量が増えるにつれて自動的に増加します。データが削除された場合は、データに割り当てられていた領域が解放され、ストレージ料金を最小限に抑えることができます。
オンプレミスのデータベースでは、データベースのログはファイルシステムに存在します。ログが必要であれば、サーバーにログインすることでログを取得することができました。
Aurora でも、データベースのログは Aurora のサーバー内のファイルにシステムに存在します。ただし、Aurora ではデータベースサーバに SSH などで直接ログインできないため、取得できません。
そのため、Aurora では CloudWatch Logs にログをエクスポートする機能をもっています。
CloudWatch Logs にエクスポートすることで、ログの検索やサブスクリプションフィルターによる検知を行うことが可能になります。
データベースエンジンごとの保存できるログファイルの種類は次の通りです。
DB エンジン | ログファイル |
PostgreSQL | Postgresql ログ、アップグレードログ |
MySQL | 監査ログ、全般ログ、スロークエリログ |
Aurora Serverless は現在 v1 と v2 が存在します。それぞれのユースケースは次の通りです。安定したトラフィックが予想できる場合は Provisioned インスタンス（通常の Aurora）を利用するほうが良いです。
- v1
- 頻度が低く、断続的、または予測が困難なワークロード
- v2
- データベースの使用負荷が短時間の間だけ増大し、その後に軽いアクティビティが長時間続く
基本的にどちらも、開発とテストを主なユースケースとしつつ、一部本番アプリケーションも想定されています。
項目 | Serverless v1 | Serverless v2 | |
GA | 2018 年 10 月 | 2022 年 4 月 | |
サポートエンジン | Aurora MySQL 5.6 or 5.7 互換バージョン、Aurora PostgreSQL 10 or 11 互換バージョン | Aurora MySQL バージョン 3、Aurora PostgreSQL 13 or 14 | |
ACU | 1 ～ 128 ACU | 0.5 ～ 256 ACU（Performance Insights を使用した場合最低でも 2ACU 必要 ） | |
料金 | 0.10 USD/ACU | 0.20 USD/ACU | |
マルチ AZ | ○ | ||
一時停止 | ○ | ||
Data API | ○ | ||
クエリエディタ | ○ | ||
Global Database | ○ | ||
Performance Insights | ○ | ||
RDS Proxy | ○ | ||
New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS
Using Amazon RDS Blue/Green Deployments for database updates
データベースの切り替えを安全に行えるようになるマネージドサービスです。
以下のような機能が提供されています。ステージング環境（Green）でテストを行い、適切なタイミングで本番環境（Blue）と切り替えを行った後で、万が一新しい環境で問題が発生してもすぐに切り戻しが可能になります。
- 本番環境をコピーしたステージング環境
- 本番環境とステージング環境のレプリケーション
- 本番環境に影響を与えず、ステージング環境に変更を加えることが可能
- データベースのメジャーバージョンのアップグレード
- データベースパラメータ変更
- スキーマ変更 など。
- 切り替えは 1 分以内
- デーア損失なし
- アプリケーションの変更不要
