Amazon Auroraをオススメする3つの理由 ~Amazon RDS for PostgreSQL との違いや選定ポイントも解説~
2022.11.11
![]() |
---|
<執筆者> 神山 太一 Koyama Taichi
クラウド技術本部 クラウド技術統括部
クラウド技術部 主査
2008年に新卒入社後、データベースエンジニアとして、教育 / 技術支援 / サポート / セミナー登壇など幅広く対応。
2020年頃からクラウド技術部へ異動し、業種 / 分野を問わず、AWSサービスを利用したお客様のシステム構築に従事。
現在は、仕事と育児に奔走中。スノボやサーフィンなど、何かに乗ることが好きなようで、今は時短&1人で遊べる
ピストバイクに乗ってリフレッシュしています。
はじめに
クラウドサービスの登場により、データベースの移行先に多様な選択肢が生まれました。
アマゾン ウェブ サービス(以降、AWS)、Microsoft Azure、Google Cloud Platformをはじめとする様々なクラウドプラットフォームに、RDBMS/NoSQLエンジンを構築する IaaSや、マネージドサービスを利用するPaaSが存在します。
その中でも、近年注目を集めているのが
AWSのPaaSの一つである「Amazon Aurora」
です。
そこで、本コラムでは、Amazon Auroraが注目を集めている背景、特徴、選定ポイントなどを説明したいと思います。
※Amazon EC2(IaaS) / Amazon RDS(PaaS) に関して詳しく知りたい方は
コラム「AWSにOracle Databaseを移行する理由と注意点
」をご覧ください。
Amazon Aurora とは
Amazon Auroraは、AWSのみで利用することができるマネージド・データベースサービスの一つです。
AWSで提供されているマネージド・データベースサービスは「Amazon Relational Database Service(以降、Amazon RDS)」と呼ばれ、以下の6つのデータベースエンジンが選択できます。
Amazon RDS で選択可能なデータベースエンジン
□ Amazon Aurora
□ MySQL
□ PostgreSQL
□ MariaDB
□ SQL Server
□ Oracle Database
中でもAmazon Auroraは独特で、
AWSがRDBMSをクラウドに最適化し、再設計したエンジン
です。
商用データベースの性能と可用性をそのままに、10分の1のコストで提供することをコンセプトとして掲げています。
また、Amazon Auroraは、
MySQLとPostgreSQLの互換性がある
エンジンから選択できます。
SQLコード、アプリケーション、ドライバー、ツールの移植性に優れている点などから、オンプレミス環境でオープンソース・データベースを利用している場合のクラウド移行先としても注目を集めています。
まずは、そんなAmazon Auroraの独自のアーキテクチャを見てみましょう。
Amazon Aurora のアーキテクチャ
|
Amazon Aurora DBクラスター
Amazon Auroraのサービスを提供/管理する単位
DBインスタンス、クラスタボリューム、Auroraエンドポイントで構成される
DBインスタンス(図内①)
アプリケーションからの処理を受け取り、変更を伴うような処理を実行する
・プライマリインスタンス:読み書き可能DBインスタンス
・Auroraレプリカ(Reader):読み取り専用DBインスタンス
クラスタボリューム(図内②)
DBインスタンスで扱うデータを管理するAmazon Aurora独自の仮想ストレージ
Auroraエンドポイント(図内③)
Amazon Auroraを利用する際の接続URLを提供
特筆すべきは、
SQL処理を行うDBインスタンスと、データを保存するストレージ(クラスタボリューム)が分離している
点です。
この独自の構成が、
可用性
と
信頼性
を高めています。
Amazon Aurora をオススメする3つの理由
Amazon Auroraには、ユニークな機能がたくさん盛り込まれています。
その中でも、特にオススメしたい機能を3つご紹介します。
①「Auroraレプリカ(Reader)」で拡張性と可用性を実現できる
Auroraレプリカは、読み取り専用のDBインスタンスです。
Auroraレプリカは、以下の点で優位性があります。
●Amazon Aurora DBクラスター内に、最大15個も作成できる上、複数のエンドポイントと組み合わせることができる
⇒ 用途を分けて、柔軟に、効率が良い実行処理が実現できる
例)データ登録業務とデータ参照業務でエンドポイントを分けて分散処理をする
●プライマリインスタンスの障害時に、即時フェイルオーバーができる(30秒~120秒以内)
⇒ 障害発生時のダウンタイムを最小限に抑えられる
さらに、Amazon RDS for PostgreSQLとAmazon Auroraを比較してみます。
Amazon RDS for PostgreSQL と Amazon Aurora の「レプリカ」を比較
Amazon RDS for PostgreSQL | Amazon Aurora | |
---|---|---|
仕様 | ![]() WAL(Write Ahead Logging)を用いた レプリケーション |
![]() キャッシュ更新リクエストを用いた レプリケーション |
レプリカ数 | 独立したストレージのため レプリカ数が増えると管理対象/コストが増える |
共有ストレージのため レプリカ数が増えても管理対象/コストは増えない |
読み取りに使える リソース |
レプリカにマスターと同等の書き込みが発生するため 読み取りに使えるリソースが少ない |
レプリカに書き込みが発生しないため リソースを100%読み取りに使える |
ラグ | ワークロードによってはラグが大きい | 20秒~100ミリ秒程度ですむ |
フェイルオーバー時の データ消失 |
ラグ分のデータが消失する | データは消失しない |
Amazon Auroraの方が、レプリカ数に依存することなく、ラグを最小限に抑え、効率よくリソースを使えることが分かります。
このように、Amazon AuroraのAuroraレプリカを使えば、
「拡張性(ワークロードの増加に応じてシステムを拡張可能)」
「可用性(システムやサービスを継続的に利用可能)」
に優れた構成が可能です。
②「クラスタボリューム」で高耐久・耐障害性を実現できる
Amazon Auroraのクラスタボリューム(ストレージ)は、分散型の共有ストレージアーキテクチャを採用しています。
Amazon Auroraのクラスタボリュームは、以下の点に優位性があります。
●3つのアベイラビリティゾーン(以降、AZ)に2つずつデータをコピーし、合計6つのデータコピーを保持する
⇒ AZ+1の障害(二重障害)にも対応できる
●クォーラムモデルを採用している
⇒ データの読み書きの一部に遅延や故障が発生した場合でも、I/O性能が失われない
クォーラムモデルは、以下のような仕様です。
Amazon Aurora のクォーラムモデル
一定数に書き込み/読み込みができれば、一旦その処理を完了とし、残りは後から同期をとる方法
<Amazon Auroraの場合>
・書き込み:6個中4個成功すれば「成功」、最大2個失敗しても影響なし
・読み込み:6個中3個成功すれば「成功」、最大3個失敗しても影響なし
|
このように、Amazon Auroraのクラスタボリュームであれば、
「耐久・耐障害性(データ消失や障害点を排除し、自動復旧可能)」
に優れた構成が可能です。
③安定した「高パフォーマンス」を実現できる
Amazon Auroraは、最大限のパフォーマンスを発揮できる以下の仕様を採用しています。
●更新ログの書き込みを非同期、並列で実施
⇒ 効率よく高速に処理できる
●チェックポイント※の概念がない
⇒ I/O負荷を軽減できる
※チェックポイント
データベースインスタンスへの変更内容をストレージに反映(同期)する処理
これらの点を、Amazon RDS for PostgreSQLとAmazon Auroraを比較して確認してみます。
Amazon RDS for PostgreSQL と Amazon Aurora の「更新ログの書き込み処理」を比較
Amazon RDS for PostgreSQL | Amazon Aurora | |
---|---|---|
仕様 | ![]() |
![]() |
書き込み | シーケンシャルなログの書き込みのため 処理速度は遅い |
非同期、並列の書き込みのため 処理速度は速い |
チェックポイント | チェックポイントによる 多数のI/Oの負荷がかかる |
チェックポイントという概念が存在せず I/Oの負荷を軽減する |
Amazon Auroraの方が、効率よく処理できる上、ディスクI/Oによるボトルネックも発生しにくいことが分かります。
ここで紹介した仕様が全てではありませんが、AWS社のベンチマーク結果を見ると、
●同時接続数が多くなればリニアにパフォーマンスが向上する
●高負荷であってもパフォーマンスが安定している
ことが確認できます。
Amazon RDS for PostgreSQL と Amazon Aurora の「TPS」を比較
PostgreSQLは同時接続数(横軸)が増えるにつれTPS※(縦軸)は低下したが、Amazon Auroraは同時接続数が増えるにつれTPSが向上した
・最大TPS :Amazon Aurora は PostgreSQL の
1.6倍
・同時接続数が多い場合のTPS:Amazon Aurora は PostgreSQL の
2.9倍
※TPS
Transactions Per Second、1秒あたりのトランザクション数
|
出典:Amazon Aurora アーキテクチャ概要「Aurora PostgreSQL: 3倍のスループット」 (2022年11月11日時点の情報)
Amazon RDS for PostgreSQL と Amazon Aurora の「安定性」を比較
Amazon Auroraのレスポンスは安定しており、PostgreSQLと比較して最大10倍のレスポンスを実現している
|
出典:Amazon Aurora アーキテクチャ概要「⾼負荷な状況でのパフォーマンスの安定性」 (2022年11月11日時点の情報)
このように、Amazon Auroraは、
「パフォーマンス」
に関しても優れていると言えます。
以上の3つのポイントから、Amazon Auroraは
「拡張性」「可用性」「耐久・耐障害性」「パフォーマンス」
に優れていることが分かりました。
Amazon Aurora と Amazon RDS for PostgreSQL のどちらを選ぶべきか?
ここまでAmazon Auroraの優位性を紹介してきましたが、問答無用にAmazon Auroraを選ぶべきではありません。
Amazon AuroraとAmazon RDS for PostgreSQLのどちらを選ぶべきか、「コンセプト」「バージョン」「コスト」の3つの観点から検討してみましょう。
①コンセプト
Amazon AuroraとAmazon RDS for PostgreSQLは、コンセプトが異なります。
Amazon RDS for PostgreSQL
OSS PostgreSQLをマネージドサービスで提供
Amazon Aurora
商用データベースの性能と可用性をマネージドサービスで提供
コンセプトを参考にすると、
●商用データベースからの移行を検討している
●OSS PostgreSQLを利用しており、非機能要件に課題がある
という場合は、Amazon Auroraがオススメです。
反対に、Amazon Auroraほどの機能や性能を求めないのであれば、Amazon RDS for PostgreSQLを選択すると良いでしょう。
②バージョン対応
PostgreSQLは、
OSS PostgreSQL ⇒ Amazon RDS for PostgreSQL ⇒ Amazon Aurora の順にリリース
します。
PostgreSQLの新バージョン対応実績
|
直近のバージョン14を見ると、OSS PostgreSQLのリリース(2021年9月)から4ヵ月ほどでAmazon RDS for PostgreSQLがリリース(2022年1月)しているのに対し、9ヵ月経ってからAmazon Auroraがリリース(2022年6月)しています。
積極的に新バージョンを使いたい場合は、Amazon RDS for PostgreSQLの方が良い
と言えるでしょう。
③コスト
コストに関しては、「インスタンス利用費用」「ストレージ費用」「I/Oリクエスト費用」の3つを考える必要があります。
コスト(一部抜粋)
Amazon RDS for PostgreSQL | Amazon Aurora | ||
---|---|---|---|
インスタンス利用費用 | 考え方 | インスタンスの稼働時間に対して課金 | |
料金 ※1 | 1.20 USD/h (db.r5.2xlarge の場合) |
1.40 USD/h (db.r5.2xlarge の場合) |
|
ストレージ費用 | 考え方 | 容量に対して課金 | |
料金 ※1 | 0.13 USD/GB(汎用) または 0.15 USD/GB (プロビションドIOPS) |
0.12 USD/GB | |
I/Oリクエスト費用 | 考え方 | 予め確保したIOPS(I/O毎秒) に対して課金 ※2 |
実際に消費したI/O に対して課金 |
料金 ※1 | 0.12 USD/IOPS | 0.24 USD/100万リクエスト (1リクエストあたり 0.00000024 USD) |
※1 料金は東京リージョンを前提とする
※2 ストレージ種別にプロビションドIOPSを選択した場合のみ必要
単純に料金を比較すると、高機能であるAmazon Auroraの方が高価です。
しかし、以下のようなパターンもあります。
<例:Multi-AZ構成の場合>
Amazon RDS for PostgreSQL
スタンバイリソースを活用できないにも関わらず、
インスタンス、ストレージ、I/Oリクエスト費用は、プライマリ同様に課金される
Amazon Aurora
インスタンスをAuroraレプリカとして活用可能
Auroraレプリカで利用するストレージは共有ストレージのため、
ストレージ費は不要、Auroraレプリカから実行した追加のI/Oリクエスト費のみ課金される
他にも、Auroraレプリカを即時フェイルオーバー先としてのみ利用する場合はストレージのI/Oリクエスト費用が不要だったり、データ保護という観点のみであれば、クラスタボリューム(ストレージ)に計6つのデータコピーがあるためレプリカインスタンス自体を作らず、障害時には手動または自動でプライマリインスタンスを作成する方針という選択も可能です。
このように、Amazon Auroraは、
標準で備わっている優れた機能を活用することで、Amazon RDS for PostgreSQLとのコスト差異を小さくする
ことができます。
Amazon Aurora と Amazon RDS for PostgreSQLのどちらを選ぶべきか、自社の要件と「コンセプト」「バージョン」「コスト」を照らし合わせて検討してみてください。
さいごに
アシストは、1987年にOracle Databaseの販売を開始してから、PostgreSQLをエンジンとしたEDBや、AWSの販売やサポートを行っており、多くの実績とノウハウを持っています。
「Amazon Auroraへの移行」をご検討の際は、現行環境の調査から、設計・導入・移行後の運用まで、お客様に寄り添ってご支援いたします。
ぜひお気軽にご相談ください。
※全て2022年11月11日時点の情報です。
参考
本ページの内容やアシスト西日本について何かございましたら、お気軽にお問い合わせください。