• 1. Amazon Auroraとは
• 2. Amazon Auroraの特徴
• 　2-1. 高可用性と信頼性を実現する独自アーキテクチャ
• 　2-2．最大15個作成可能なリードレプリカ
• 　2-3．災害対策
• 　2-4．PostgreSQL、MySQLとの互換性
• 　2-5．その他の特徴
• 3. Amazon AuroraとRDSの違い
• 4. Amazon Auroraの料金
• 5. まとめ

Amazon Auroraは、AWSのみで利用することができるマネージド・データベースサービスです。

データベースの実行環境はオンプレミスからクラウドへと変わりつつあります。運用面からみてもマネージドサービスを利用することで、本当に必要なタスクに比重を置く考えが強くなってきています。

しかしデータベースの変更には、接続方法の見直しやSQL改修などのリスクがあり、移行工数が膨大になった例も少なくありません。アプリケーションやソフトウェア担当からすると、データベースに対して実行する処理は変えたくないという思いがあるのではないでしょうか。

Amazon Auroraは、データベースの観点からクラウド上で最適に稼働するように再設計されたサービスです。エンジンは、PostgreSQL・MySQLと互換性があるエンジンから選択できるため、これらのデータベースからの移行時にアプリケーションへの影響が少なく済みます。

またAmazon Auroraは、「まずは利用できるデータベースが欲しい！」という新システム用データベースとしても有能です。なぜなら、柔軟性・拡張性に優れたサービスのため、利用開始前に細かな設計をしていなくても、耐障害性があり、高いパフォーマンスを発揮するデータベースを手に入れることができるからです。詳細はこの後の章でご紹介します。

Amazon Auroraは、AWSで提供されているデータベースサービス“Amazon RDS”の中の1つで、Amazon RDS for Oracleなどと同列に位置付けられています。

Amazon RDSはマネージドサービスとして様々なデータベースエンジンに対応しています。その中で “クラウドのために再設計されたデータベース” が Amazon Aurora です。

構成やコスト、パフォーマンスなど様々な独特な特徴があるので、“RDS” ではなく “Aurora” と区別して呼ばれることが多いです。
では、その特徴をいくつかピックアップしてみていきましょう。

高可用性・信頼性を実現するAmazon Aurora独自のアーキテクチャを紹介します。

Amazon Auroraは、Amazon Aurora DBクラスターという単位でサービスが提供されています。DBクラスターは主に、DBインスタンス(図内①)とクラスタボリューム(図内②)、エンドポイント(図内③) の3つで構成されます。この独自の構成が、高可用性と信頼性を支えています。

1つ目のDBインスタンス(図内①)は、アプリケーションからの処理を受け取り、変更を伴うような処理を実行します。DBインスタンスには2つの種類があります。

2つ目のクラスタボリューム(図内②)は、DBインスタンスで扱うデータを管理します。このボリュームは、Amazon Aurora独自のストレージです。 他のAmazon RDSで利用されるAmazon EBSの場合、IOPSを考えてサイズを選定したり、SSD等のタイプを検討する必要がありますが、Amazon Auroraの場合はストレージタイプやサイズの検討は不要です。


最後にAuroraエンドポイントです(図内③)。これはAmazon Auroraを利用する際に接続するためのURLを提供します。エンドポイントは4種類提供されていて、用途に応じて使い分けが可能です。

Amazon Auroraの構成や特徴を理解するうえで、ここまでの要素は重要になりますので覚えておきましょう。

Amazon RDSのその他のデータベースでは、処理を行うインスタンスとデータを格納するストレージは１対１です。処理が発生するとインスタンスはストレージと通信して処理を行います。
読み込み専用のインスタンスを持つ場合も、多くの場合スタンバイ側のインスタンスとストレージのセットをもう一つ構築します。

また、一対のインスタンスとストレージは同じ1つのAZ内に存在します。

Amazon Auroraは、ストレージがアベイラビリティゾーン(以降、AZ)をまたいで存在します。AZをまたぐので、通常の同一AZ内で構築するよりも可用性が高そう！とイメージできるのではないでしょうか。（Amazon Aurora以外のAmazon RDSにもMulti-AZという構成もありますが、ストレージは同一AZ内に存在します。）

Amazon Auroraのストレージは、AZをまたいで存在するだけでなく、そのストレージの中で1AZ当たり2か所、3AZに渡りデータをコピーするため、計6か所のストレージにコピーされています。

このように、AZをまたいでかつインスタンスと分離されたストレージを利用することで、1つのAZで障害が発生した場合も残りのAZで保持する情報を利用できます。

データをただ複数保存しているだけではありません。データの破損状況も常にチェックされており、障害を検知した場合は自動で復旧を行います。ユーザ側での障害検知や復旧の操作は不要です。

障害に強く、事故復旧も可能という面で利用にあたっての安心感、信頼性も高いサービスです。

Amazon Auroraでは、プライマリインスタンスに加えてAuroraレプリカを作成するケースが多くあります。 通常レプリカは、読み込み専用となっていますが、プライマリへ昇格することもできます。

プライマリのインスタンスに障害が発生した場合、他のAZにあるインスタンスをプライマリへ昇格させて処理を継続することができるのです。切り替えは手動でも自動でも実装できるため、事前に障害テストを実施するなども可能です。

インスタンスがプライマリに昇格してもアプリケーションは、クラスタエンドポイントへ接続することで処理が継続できます。内部的にはインスタンスが変わっていますが、アプリケーション側の変更は不要です。

「2-1-3．インスタンスの可用性」でもお伝えしたように、Amazon Auroraでは読み込み専用のAuroraレプリカ（Reader）を作成することができます。 その数は、最大15個。複数のエンドポイントと組み合わせることで作成することが可能なため、用途を分けてレプリカを活用することができます。

例えば、読み書きが必要な登録業務のアプリケーションは、クラスターエンドポイントを利用し、プライマリDBインスタンスへ接続させます。 一方で情報参照のみのアプリケーションは、リーダーエンドポイントを利用してAuroraレプリカへ接続させます。このような使いわけが可能なため、インスタンスの役割に応じて効率的に処理を分散し利用することができます。

Amazon RDSはリード可能なレプリカは最大5つとなるため、Amazon Auroraの方がより柔軟に幅広く、利用用途を分けることが可能です。

Amazon Auroraは、地域災害を考慮した構築も可能です。

一般的な災害対策は、まず遠隔地にサーバを用意し、インスタンスに対して実行された処理を遠隔地のサーバに伝搬して実行します。

もちろんこの方式は、災害発生用の環境として有効です。 しかし、距離が離れれば離れるほど同期の差分も大きくなってしまいます。

Amazon Auroraの場合は、サーバではなくストレージのレプリケーションとなります。 （この遠隔地でのストレージレプリケーション環境を、グローバルデータベースといいます。）
主に利用しているリージョンのストレージを、遠隔地のストレージと常に同期するイメージです。このため、大量の処理が実行された場合でも同期の差分はほとんど発生しません。

Amazon Auroraは、PostgreSQLとMySQLと互換性があります。
ここでの互換性というのは、SQLレベルでの互換性を示します。つまり、現在PostgreSQLやMySQLを利用し、実行している処理をそのままAmazon Auroraに対して実行可能ということです。

また、Amazon Auroraはスループットの観点で高いパフォーマンスを発揮します。
Amazon Auroraならでは処理動作やデータの格納方法により、MySQLの最大5倍、PostgreSQLの最大3倍高速な処理を実現することができるのです。

PostgreSQLとMySQLの互換性という点でAmazon Auroraを利用する注意点として、対応バージョンがあります。

Amazon AuroraはPostgreSQLやMySQLのエンジンをベースにアップデートされます。

PostgreSQLやMySQLの最新バージョンや修正がリリースされた後に、そのバージョンに対して互換性のあるアップデートが行われるため、タイムラグが発生します。
常に最新のPostgreSQLやMySQLを利用したい場合には、Amazon Auroraは要望を満たせないのです。

その他にもAmazon Auroraには多くの特徴があります。

・データ用ストレージのサイジング不要
　10GB単位で利用に応じて自動でスケールアップするので、事前の設計は不要です。
　”自動”でスケールアップするので、監視して対応する運用も不要です。

・キャッシュの保持
　Amazon Auroraでは、DBプロセスとキャッシュが別に管理されているため、DBを再起動した場合
　でもすぐにキャッシュの情報を利用した高速処理が可能です。

・自動スケーリング可能
　負荷状況に応じてAuroraレプリカを自動増減することも可能です

・Amazon Aurora Serverlessの提供
　サーバレスのAmazon Auroraも提供されています。

Amazon AuroraもAmazon RDSのサービスの1つです。ただ、同じエンジンを持つAmazon RDS for PostgreSQLやAmazon RDS for My SQLとAmazon Auroraの利用を検討する場合、どのサービスを選択するべきか悩むこともあると思います。

Amazon RDSとAuroraの違いは以下のとおりです。

では、どのような基準で選定すればいいのでしょうか？
一例ではありますが、以下のようなことが考えられます。

[Amazon Auroraを選ぶ場合]
　・Amazon Aurora独自の機能を利用したい
　・クラウド環境下で運用面・性能面において最適化されたサービスを利用したい
　・高可用性・信頼性のあるサービスを簡単に利用したい

[Amazon RDSを選ぶ場合]
　・最新のバージョンを利用したい
　・Amazon Auroraで利用できないサービスを利用したい

Amazon Auroraの費用は3つの要素を考える必要があります。

③については、処理の種類や量に大きく影響されるため、試算することが難しいです。（$0.34/100万リクエスト）
そのため、試算の際はまずは①＋②で試算をし、I/Oリクエスト分のバッファを考慮いただくことをお勧めします。

Amazon AuroraとAmazon RDSは費用の考え方が異なります。
以下の例で、簡単なコストの比較をしてみます。




Amazon RDSの場合、Multi-AZ構成でインスタンスが2つ必要になります。
しかしインスタンスは、読み書き不可のスタンバイです。要件を満たすためには、読み込み可能なインスタンスが別に2つ必要なので、合計4つのインスタンスを構成します。
また、Amazon RDSはインスタンスとストレージが1対1になるため、Amazon EBSの費用も4インスタンス分必要となります。

Amazon Auroraの場合、Multi-AZ構成とした場合に作成されるインスタンスは読み込み可能なインスタンスとなります。読み込み可能なインスタンスが2つ必要な場合は、合計3つのインスタンスを作成することとなります。

構成や求める性能、利用するインスタンスタイプによって費用は変わるため単純に比較することは難しいですが、Auroraは独自の構成で運用を含めたトータルコストを下げることも可能です。

今回のコラムでは、Amazon Auroraの入門としてその特徴やRDSとの違いなど解説しました。
アシストでは、既存のデータベースからAmazon Auroraへの移行をご支援しています。お気軽にこちらからご相談ください。

関連ページ：AWSデータベース構築・移行サービス

※本コラムの内容は、記載製品に関して一般的な概要を説明するものです。情報提供を唯一の目的とするものであり、記載情報はいかなる契約にも組み込むことはできません。
※記載されている製品規定、機能の開発、リリースおよび時期については、製品提供企業の裁量により決定されます。記載情報は執筆時点での内容であり、将来予告なしに変更されることがあります。