Power Unit Inc. | 想像力のない者に翼はない | Amazon Aurora
17330
page-template,page-template-full_width,page-template-full_width-php,page,page-id-17330,qode-quick-links-1.0,woocommerce-no-js,ajax_fade,page_not_loaded,,side_area_uncovered_from_content,columns-4,qode-theme-ver-16.8,qode-theme-bridge,qode_header_in_grid,wpb-js-composer js-comp-ver-5.5.2,vc_responsive
 

Amazon Aurora

Amazon Aurora

パフォーマンスが数倍向上した MySQL および PostgreSQL 互換のリレーショナルデータベース。
商業用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで提供します。

Amazon Aurora の特徴

Amazon Aurora は、MySQL および PostgreSQL と互換性のあるリレーショナルデータベースエンジンで、高性能の商業用データベースの可用性とスピード、およびオープンソースデータベースのシンプルさとコスト効果性を併せ持っています。Amazon Aurora は、MySQL および PostgreSQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商業用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。

Amazon Aurora は、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを完全に統合することで、パフォーマンスおよび可用性を向上します。Amazon Aurora のストレージは耐障害性と自己修復機能を備えています。ディスクの障害はバックグラウンドでリペアされ、データベースの可用性が損なわれることはありません。Amazon Aurora は自動的にデータベースのクラッシュを検出して再起動するように設計されています。クラッシュのリカバリやデータベースキャッシュの再構築は不要です。インスタンス全体に障害が発生した場合、Amazon Aurora は最大 15 個のリードレプリカの 1 つに自動的にフェイルオーバーします。

Amazon RDS はデータベースの運用に関する一般的な管理タスクのほとんどを自動化し、Amazon Aurora データベースの管理を容易にします。AWS マネジメントコンソールで数回クリックするだけで、Amazon Aurora データベースインスタンスをすばやく起動できます。Amazon Aurora はストレージを自動でスケールし、ストレージの拡張および I/O の再分散を実行して一貫性のあるパフォーマンスを提供します。オーバープロビジョニングは必要ありません。たとえば、10 GB のデータベースを起動し、データのリサイズまたはリストライプによって可用性を損なうことなく 64 TB まで自動的に拡張できます。

高性能

Amazon Aurora は、同じハードウェア上で実行される標準 MySQL の 5 倍、標準 PostgreSQL の 2 倍のスループットを実現します。この一貫性のあるパフォーマンスは商業用データベースのパフォーマンスと同等であり、しかも、コストが 10 分の 1 です。最大規模の Amazon Aurora インスタンスでは、秒あたり最大 500,000 回の読み込みと最大 100,000 回の書き込みを達成できます。さらに、きわめて小さい 10 ms のレイテンシーを実現するリードレプリカを使用することによって、読み込みオペレーションをさらにスケールすることもできます。

高い安全性

Amazon Aurora では、データベースのために複数のレベルのセキュリティが用意されています。これらの機能には、Amazon VPC によるネットワーク分離、AWS Key Management Service (KMS) を介して作成および制御されるキーによる保管時の暗号化、移動中データの SSL による暗号化が含まれます。暗号化された Amazon Aurora インスタンスでは、基盤となるストレージが暗号化されます。さらに、同じクラスター内にある自動化バックアップ、スナップショット、およびレプリカも暗号化されます。

MySQL および PostgreSQL との互換性

Amazon Aurora データベースエンジンは InnoDB ストレージエンジンを使用することで MySQL 5.6 と完全な互換性があります。これは、お客様が MySQL データベースですでに使用しているコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Amazon Aurora で使用できることを意味します。このことはまた、MySQL の標準のインポートおよびエクスポートのツールや MySQL binlog レプリケーションを使用して、既存の MySQL データベースを容易に移行できることも意味します。現在、PostgreSQL 9.6 の SQL 方言および機能をサポートする、PostgreSQL 互換の Amazon Aurora データベースインスタンスをプレビューしています。

高いスケーラビリティ

Amazon Aurora データベースは、2 vCPU と 4 GiB のメモリを備えたインスタンスから、最大で 32 vCPU と 244 GiB のメモリを備えたインスタンスまでスケールできます。また、3 つのアベイラビリティーゾーンにかけて最大 15 個の低レイテンシーリードレプリカを追加することでさらに読み込み容量をスケールできます。Amazon Aurora は 10 GB から 64 TB まで、必要に応じて自動でストレージを拡張します。

高可用性と耐久性

Amazon Aurora は、99.99% の可能性を提供するように設計されています。物理ストレージの障害は透過的に復旧され、インスタンスのフェイルオーバーは、通常、30 秒未満で完了します。Amazon Aurora のストレージは耐障害性と自己修復機能を備えています。データについては、6 つのコピーが 3 つのアベイラビリティーゾーンにわたってレプリケートされ、連続的に Amazon S3 にバックアップされます。

完全マネージド型

Amazon Aurora は完全マネージド型のデータベースサービスです。つまり、ハードウェアプロビジョニング、ソフトウェアパッチ適用、セットアップ、構成、モニタリング、またはバックアップなどのデータベース管理タスクについて頭を悩ます必要はありません。Amazon Aurora では、自動的にデータベースがモニタリングされ、Amazon S3 にバックアップされるので、きめ細かいポイントインタイムリカバリが可能です。

Amazon Aurora について知らなくてもいいこと

オープンソースのデータベースも商用のデータベースもある中、そもそも、なぜ、Amazon がまた 1 つ新しいデータベースを開発したのか?疑問に思う人もいるでしょう。

まず、Amazon は考えました。リレーショナルデータベース管理システム(RDBMS)が登場したのは、そもそも 1970 年代まで遡ります。今日のデータベースの多くは、当時のコンピューティング環境の基盤を前提に設計されていました。もちろん、新しいバージョンがリリースされるごとに、モダンな設計思想を取り入れてきましたが、根本となるアーキテクチャーに手が入れられていたとは必ずしも言えません。つまり、Amazon は、クラウド全盛の時代に RDBMS を再設計するとしたらどうなるのか取り組んだ結果が Amazon Aurora の誕生につながりました。

そこには、数々の技術的チャレンジも含まれています。最新のデータベーステクノロジーだけではありません。サービス志向アーキテクチャ(SOA)やマイクロサービスアーキテクチャーといったソフトウェアに関するコンピューターサイエンスの視点から。最新のハードウェアテクノロジーの進化、例えば HDD から SSD へ、さらにインメモリへの進化。そして何よりも他の AWS サービスとのオーケストラレーション(統合)が挙げられます。

モノリシックな RDBMS

従来の RDBMS と Amazon Aurora の最大の違いは、モノリシックかサービス志向(もしくはマイクロサービス)かというデータベースのアーキテクチャーでしょう。従来の RDBMS は、常にモノリシックなアーキテクチャーを採用してきました。つまり、SQL のレイヤー、トランザクションのレイヤー、キャッシュのレイヤー、ロギングのレイヤーが一枚岩のような構造で密接に結合しています。

つまり、マルチスレッドといった並列処理はあっても、基本的には複数の機能レイヤーが 1 つのアプリケーションになっていたのです。

モノリシックな RDBMS の最大の問題は、データベースの処理能力(ワークロード)に基づく柔軟でコストのかからないスケールアウトが難しいことです。

多くのアプリケーションワークロードは時間の経過と共に変化するリソースの使用によって特徴付けられます。使用率のピーク時は、日、週、月、および外部のイベントによって異なる場合があります。大規模なスポーツイベントやオンライン販売でも使用率が急増する場合があります。従来のオンプレミステクノロジを使用して、IT 部門では通常、最悪のシナリオを管理するために十分な容量をプロビジョニング(事前準備)しています。このスケーラビリティへのアプローチでは、ほとんどの場合、データセンターに使用率の低い大量のリソースが残る可能性があり、この非効率性が全体的なコストに影響する可能性があります。

クラウドコンピューティングはこのような非効率性に確実に対処します。クラウドでは、必要に応じて新しいリソースをデプロイし、余裕期間にリソースを縮小することで、コストとパフォーマンスのバランスをとることができます。この柔軟なアプローチでは需要と容量が一致します。

RDBMS のスケールアウト(シャーディング)

アプリケーションがリレーショナルデータベース管理システム (RDBMS) で永続化された記憶域を処理する際に、アプリケーションの柔軟的なスケーリングが複雑になる場合があります。これまでのソリューションは垂直スケーラビリティ (「より大きなものを購入する」) でした。一般に、これをスケールアウトではなくスケールアップとして区別します。このオプションの場合、アプリケーションの開発と管理はより大規模なハードウェア投資の価格については依然として比較的簡単ですが、実際に柔軟なアプローチとコンピューティングリソースを効率的に使用する際に余分なコストがかかります。

1 つのデータベースサーバを一定のサイズよりスケールアップできない場合はどうすればよいでしょうか。また、スケーラビリティを向上させる際に、システムにおける特定のリソース競合のため、特定のしきい値を超えられない場合はどうすればよいでしょうか。このような場合は、シャーディングなどの、水平パーティション分割とスケールアウトアプローチが役立ちます。フロントエンドからアプリケーションサーバまでのすべての層でスケールアウト手法を適用することができます。ただし、データ層の場合、垂直スケーラビリティでは十分に対処できない問題の解決にスケールアウトアプローチが重要になります。

シャーディングはデータ層をスケールアウトするために確立された手法です。この手法では、あらゆる種類のデータストア内の 1 つ以上のノードでホスティング可能な、シャードという多くのパーティションにわたる大規模なデータセットを保存して照会します。リレーショナルと非リレーショナルの両方のデータストアでは、シャーディングを使用して、単一サーバの容量とリソースを超えるスループットの高いワークロードの大規模なデータセットをサポートできます。

シャーディングの一般的なアプリケーションパターン

一般的なアプリケーションでは、多くの場合、セキュリティや管理の容易性上の理由から、データベース層を分離します。たとえば、データベースを分離して、特定の顧客のデータをバックアップして復元する機能や特定のテナントに対してより高いスループットを提供する機能をサポートできます。次の図は、SaaS ソリューションと顧客ごとに分離された単一のテナントを示しています。

これに対し、マルチテナントソリューションでは、データベースを多数のテナントで共有することができます。このアプローチでは、より高いリソース使用率の密度を最大化し、コストとパフォーマンスのバランスを公平に保ちます。次の図は、マルチテナント SaaS ソリューションを示しています。

3 番目のケースはハイブリッドアプローチです。このアプローチでは、重要なパフォーマンスまたはセキュリティの要件に応じて重要なテナントがデータベースを分離し、他のテナントはリソースを共有します。たとえば、ある会社(顧客 Z)に量が多いため、1 つのデータベースでは小さすぎるかまたは処理に時間がかかりすぎるデータがあるとします。次の図はこのハイブリッド モデルを示しています。

マルチテナントかどうかに関係なく、データベースシャーディングを使用することで、アプリケーションは利点を得られます。シャーディングを使用すれば、さまざまなデータベースにアプリケーションデータをパーティション分割したり、より大容量のデータセットでいっそう高いデータベーススループットを実現したりすることができます。情報は、時間などの属性、または部門、生産プラント、地理などの別のデータセット特性に基づいてパーティション分割することができます。

次の図は、非マルチテナントアプリケーションの場合の時間に基づくデータベースシャーディングを示しています。

アプリケーションパターンには、通常、各データベースのパーティション (シャード) を追跡するための集中管理された場所が存在します。シャードは、特定のレコードセットが存在する場所です。たとえば、以下の図には、この情報を含むルートデータベースである、ディレクトリに接続する (1) アプリケーションログオン手順が示されています。次に、アプリケーションは、ユーザーパーティションを検索して、関連するパーティションデータを含むデータベースに接続します (2)。その特定のデータベース (3) のコンテキストではアプリケーションのすべての操作が実行されますが、一部の操作はファンアウトします。つまり、操作はアプリケーションデータベースのすべてまたは一部で実行されます。

このアプリケーションパターンでの目的は、中央ディレクトリが繰り返し照会されないようにすることです。代わりに、共通情報がアプリケーションノードまたは分散型キャッシュレイヤーにキャッシュされるため、要求ごとにルートデータベースを照会しなくてもパーティションが解決されます。

RDBMS の水平スケーラビリティ

水平スケーラビリティは、複数のデータベースにわたるデータをホストすることで変動するワークロードに対応します。垂直スケーラビリティとは異なり、スケールアウトアプローチはあまり高度(であるがゆえに高価)ではないハードウェアコンポーネントを利用し、さらなるアプリケーション内開発やデータとシステム メンテナンスのためのリソースを解放することによるコストの削減に役立ちます。

データ層のスケールアウトには複数のよく知られているアプローチのうちのいずれかを使用することができます。どれを選択するかは、ワークロードと、データストアでサポートされているアプリケーションによって決まります。ほとんどのユーザーは、データセットがビジネスまたは組織の機能に分割される機能パーティション分割を選択します。2 つの一般的なスケールアウト手法は次のとおりです。

  • データはすべてのノードで完全にレプリケートされます。1 つのプライマリコピーでは変更が受け入れられ、複数のアクティブレプリカは通常、読み取り専用(リードレプリカ)となります。このような構成は、読み取りが任意のサーバに接続してクエリを実行する可能性のある、レポート作成などの読み取りが集中するワークロードに適している場合があります。これに対し、書き込みが集中するワークロードのボトルネックが原因で、書き込みはプライマリコピーにしか接続できません。
  • 読み取り操作と書き込み操作は複数のノードに分散されます。ある種の分散ロジックを適用することにより、特定のトランザクションは単一ノードに存在するエンティティによって完全に満たされます。通常、すべてのノードで一部のデータがレプリケートされます (たとえば、次のセクションで説明されている参照データなどです。ただし、アクティビティまたはトランザクションデータは、同じ論理グループに属しているすべてのエンティティに適用される、キー、単純または複合要素に基づいてパーティション分割されます)。 シャーディングはこのアプローチを指します。

シャードレットとシャーディングキー

シャーディングでは、同じシャーディングキーを共有する一連のレコードをシャードレットといいます。シャードレットの機能を理解するには、シャードがシャードされた参照テーブルの論理コレクションであることを認識することが役立ちます。シャードされたテーブルでは、テーブル内のレコードはシャーディング キーに関連付けられているため、シャード間でパーティション分割することができます。参照テーブルはシャードできません。すべてのシャードにすべてのレコードが存在する必要があります。

シャードレットは、シャードされたテーブルと参照テーブルの両方を含むシャードでホストされます。各シャードには、データ管理とコンテナーの分離アプローチに応じて、1 つまたは複数のシャードレットを含めることができます。シャードレットは、物理計算ノード間でのワークロードの再バランス時に移動されるデータの単位です。

一般に、1 つのシャードは、リソースとセキュリティ管理のための物理コンテナーを表す 1 つのデータベースにマップされます。ただし、複数のシャードは、特定のデータ分散要件に応じて単一のデータベースに一時的または永続的に格納できます。その後、これらのデータベースは複数のサーバ間でホストされます。その数は変動する柔軟なワークロードに合わせて増減する可能性があります。

各シャードはより大きな論理データベースの一部を表します。シャードとシャードレットをホストする各物理データベースはアプリケーション全体のスループットの一部を処理します。したがって、特定のデータベースに関連する挿入などの操作はシステム内の他のデータベースに影響しません。

シャード間のデータ分散は、シャーディングキーの値とパーティション分割オプション (連続するシャーディングキー値の範囲または特定のシャードレットにマップされる不連続値のリストに基づいている可能性がある) に基づいています。順序付けられていないデータセットと、特定の順序やグループ化ロジックをシャーディングキー値に適用できない他のケースでは、ハッシュシャーディングと呼ばれる 3 番目のパーティション分割オプションが適用されます。

人為的なグループ化属性は、指定された数のバケットに特定のデータセット内のすべてのエンティティをパーティション分割する、ハッシュまたは剰余などの関数を適用して計算できます。ハッシュシャーディングは、複数のコンテナーに連続するシャーディングキー値を分散するため、データ挿入のパフォーマンスを最大限に高めるためにも便利です。

リストシャーディング

範囲シャーディング

ハッシュシャーディング

Amazon Aurora : クラウド時代の RDBMS

モノリシックな RDBMS は、スケールアウトするのが難しいことは紹介してきた通りです。銀行の基幹システムのようにお金に物を言わせてスケールアップする方法が選択できなければ、アプリケーションレベルでスケールアウトを制御する必要があります。

今、RDBMS を設計するとしたら、少なくとも 1970 年代と同じ方法では実装しないはず(と仮定します)です。AWS の他のサービスと親和性があり、簡単にスケールアウトが可能で、セルフヒーリングができるデータベースが作りたいのです。

Amazon Aurora は、従来までのモノリシックな RDBMS とは異なりサービス志向アーキテクチャー(SOA)で構成されます。Amazon Aurora は、データベースの基盤となるデータプレーンと管理のためのコントロールプレーンに大別され、それぞれ、Amazon EC2、Amazon S3、Amazon VPC、Amazon DynamoDB、Amazon SWF、Amazon Route 53 などによって機能します。

従来のモノリシックな RDBMS の機能レイヤーのうちロギング層とストレージ層をシームレスにスケールするストレージサービスに移動します。データは、透過的に Amazon S3 に分散してストリーミングバックアップされているため耐久性、耐障害性を備えています。

Amazon Aurora は、従来のモノリシックな RDBMS の機能レイヤーのうちキャッシュ層をデータベースプロセス(SQL とトランザクションの実行)から分離したプロセスに移動します。これによって、データベースが障害を受けてデータベースプロセスの再起動が発生したとしてもデータベースのパフォーマンスに大きく影響するキャッシュの内容は維持したまま処理を再開することができます。

高速なクラッシュリカバリー + サバイバルキャッシュによって、データベースの障害から高速に復帰することで、他のサービスにすぐデータベースを戻すことが可能になります。

Amazon Aurora のストレージ

Amazon Aurora のストレージは、高速な SSD ドライブに最適化されたログストラクチャードストレージによる高速なロギング機能と、Amazon S3 のストリーミングバックアップ機能によって実現されています。

SSD を利用した Amazon Aurora のストレージは 10 GB から 64 TB までシームレスにスケールアウトします。データは Peer-to-Peer Gossip Replication によってレプリカが作成されます。ログストラクチャードストレージ(LFS)は、非常に高速で大容量のデータを柔軟に保存できるので、Google の検索エンジンデータや Facebook の SNS データの保存に利用されています。ここでは、その詳細には踏み込みません。

データベースのデータは、Amazon S3 のストリーミングバックアップ機能を利用して、3 つの異なる AZ に合計 6 つのコピーが作成されます。これによって、任意の 2 つのディスクが障害を起こしたり、任意の 1 つの AZ が障害を起こしても、読み書きが保証されます。さらに、任意の 3 つのディスクが同時に障害を起こしたとしても読み込みだけは保証します。Amazon S3 は障害を検知すると自動で修復可能です。

Amazon Aurora のストレージノードのトラフィックフローは下の図のようになります。

ここで、重要なのは、すべてのステップは非同期のため、ステップ 1 と ステップ 2 だけがデータベースのプライマリーインスタンスのフォアグラウンドのレイテンシー(遅延)に影響を与えます。こうすることで、レイテンシーにセンシティブで高速なデータベースが実現可能になっています。

Amazon Aurora と CAP 定理およびクォーラム(Quorum)による分散レプリケーション

Amazon Aurora の分散データベースは、クォーラム(Quorum)ベースの投票アルゴリズムを、データベースレプリケーション(複製)の制御手法として採用しています。また、ネットワークパーティショニング下でのデータベーストランザクションのアトミック性を保証するコミット手法としても使用しています。

分散システム(クラスター構成のデータベース)は、データをレプリケーション(複製)をすることによってクライアントに対する読込スループットを上げることができるだけではなく、分散システムの持つ特徴である「耐障害性」の観点から言うところの、他のノードが停止していてもデータの読込・書込ができる、つまり、データの可用性 Availability が高まりします。しかし、データの可用性はある種のトレードオフを生み出します。複製が増えると、データの変更時に複製の一貫性 Consistency を管理する必要があります。複製の内容にばらつきが出ると、クライアントに対して、読込データの一貫性を提供するのが難しくなるからです。さらに、分散システムにおいては、複数のプロセス群はネットワークによって隔てられている可能性が高く、ネットワークが分断した場合でも正常に動いて欲しい Network Partition-Tolerant という要求も出てきます。

この C, A, P という 3 つの性質は、どのようにしても 3 つ同時に満たすことが出来ず、2 つしか同時に満たすことが出来ないというのが 2000 年代はじめに証明された、有名 なCAP 定理です。近年、従来の RDBMS の ACID と対比して NoSQL データベースの基本原理として用いられるようになっています。

CAP 定理について補足すると、従来の RDBMS は、C(一貫性)と A(可用性)を保証することに焦点が置かれてきました。Amazon Aurora は、C(一貫性)と P(ネットワーク分断耐性)に焦点を置いています。その上で、データベースをクラスター構成で構築することによって A(可用性)を可能な限り確保しています。

こうした分散システム(クラスター構成のデータベース)のレプリケーション・トランザクションに関する洞察から注目を浴びているのがクォーラム(Quorum)ベースの投票アルゴリズムを使った「結果整合性」という方法です。詳細についてはこれ以上踏み込みませんが以下の図を参照してください。(ちなみに、その他に、ROWA – Read One Write All、Primary Copy ROWA といった方法があります。)

ログストラクチャードストレージ

Amazon Aurora のストレージの特徴として、ストレージ層にログストラクチャードストレージと呼ばれる技術を採用していることが挙げられます。これは、Linux などで実用化されているログストラクチャードファイルシステムからインスパイアーされたもので、追記型のストレージシステムのことです。

非常にシンプルなストレージシステムで、ログデータのように順番に末尾へとデータをひたすら追加していくだけのものです。これによってデータが書き込まれた時に既にデータが書き込まれているブロックに上書きするようなケースはありません。データの書き込みが追記型のため、逆にシーケンシャルに読み出すことができます。常に最新のデータが末尾に存在しているので、最も利用頻度の高いデータは末尾付近に存在する可能性が高くなります。ストレージは定期的に GC で余白部分が圧縮されますが、非常にシンプルな GC のアルゴリズムのため、高速で、かつ、ストレージのパフォーマンスインパクトを最小限に抑えることができます。

こうした特徴を持ったストレージのため、 Amazon S3 へのストリーミングバックアップ(継続的バックアップ)や高速なリカバリ、書き込み性能の向上を実現しています。

Amazon Aurora のストレージの特徴をまとめると以下のようになります。

  • リードレプリカもマスタと同じストレージを参照している
  • ログストラクチャードストレージ
  • 継続的な Amazon S3 への 6 つのストリーミングバックアップ(差分バックアップ) … 処理は非同期のためマスタインスタンスに対するパフォーマンスに影響しない。
  • 高速な SSD に最大で 64 TB まで 10 GB 単位で分散して自動でストレージがシームレスにスケールアップ(スケールアウトではない) … パフォーマンスや可用性に影響しない・利用したぶんだけ課金され開始前のプロブジョニング不要
  • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化をサポート

Amazon Aurora のレプリケーション

Amazon Aurora のレプリケーションは、1 つ前の Amazon Aurora のストレージのセクションでわかるように従来のモノリシックな RDBMS とはアーキテクチャーが大きく違います。

従来の RDBMS では、耐障害性を備えたデータベースのインスタンスには「マスタ」と「スレーブ」という主従関係があります。データベースのエンドポイントはマスタのデータベースを指していて、データの読み取りや書き込みのワークロードは、まずマスタのデータベースに対して実行され、最後にプロセス全体のレプリケーションがスレーブのデータベースへと反映されます。マスタとスレーブのインスタンスは、データベースがアタッチしているストレージ EBS に保存され、そのミラー EBS がバックアップとして機能します。データベース内部の I/O トラフィックフローは以下のようになります。

一方、Amazon Aurora では、データベースのインスタンスには「プライマリ」と「Aurora レプリカ(リードレプリカ)」という関係があります。プライマリとリードレプリカには、厳密に従属関係のようなものはなく、プライマリのデータベースで仮に障害が発生すると、他のリードレプリカのどれかがプライマリに昇格する関係になります。Amazon Aurora のストレージで紹介したように、Aurora では、3 つの異なる AZ に合計 6 つのデータのコピーが存在し、プライマリへの書き込みはプライマリのみに、読み込みはプライマリだけではなくリードレプリカに対しても分散して実行されます。データはデータベースにアタッチした EBS に存在しているのではなく、Amazon S3 に保存されています。データベース内部の I/O トラフィックフローは以下のようになります。

従来のモノリシックな RDBMS のレプリケーションは、マスタと完全に同じスレーブをレプリケーションすることでしたが、Amazon Aurora では、リードレプリカは書き込みではなく読み込みに 100% 集中できます。そのため、レイテンシーが非常に短く、フェイルオーバーでデータロスする心配はありません。

Amazon Aurora レプリカはプライマリと同じデータボリュームを共有しているため、実質的にレプリケーションラグはありません。ラグは通常数十ミリ秒です。MySQL リードレプリカの場合、レプリケーションラグは変更率または適用率、およびネットワーク通信の遅延に応じて無制限に増大する可能性があります。ただし、通常の状況では数分のレプリケーションラグが一般的です。

Amazon Aurora のデータベースクラスターとクラスターボリューム

Amazon Aurora 特性のデータベースの特徴を端的に示す用語として、Amazon Aurora にはデータベースクラスターという概念があります。データベースインスタンスを作成すると、DB クラスターが作成されます。DB クラスターは、1 つ以上のインスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターボリュームで構成されます。Aurora クラスターボリュームは、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリュームです。各アベイラビリティーゾーンにはクラスターデータのコピーが格納されます。Aurora DB クラスターには、最大 15 個のリードレプリカを持つことができ、別の AZ のリードレプリカを検索することでデータベースの可用性を高めることができます。

各 Aurora DB クラスターには、ユーザーが接続できるクラスターエンドポイントがあります。クラスターエンドポイントは DB クラスターのプライマリインスタンスに接続します。このクラスターエンドポイントを使用して、読み取りと書き込みの両方のオペレーションを実行できます。可用性の高いシナリオでは、クラスターエンドポイントに接続することで、フェイルオーバーが完了するとアプリケーションは新しいプライマリインスタンスに再接続します。

各 Aurora DB クラスターには読み込みエンドポイントがあり、これを使用して DB クラスターの Aurora レプリカの 1 つに接続できます。DB クラスターの読み込みエンドポイントは、DB クラスター内で使用できる Aurora レプリカ間で接続を負荷分散します。クライアントが読み込みエンドポイントへの新規接続をリクエストすると、Aurora によって接続リクエストが DB クラスターの Aurora レプリカ間で配分されます。この機能は、DB クラスターの複数の Aurora レプリカ間の読み取りワークロードを分散させる役に立ちます。

Amazon Aurora の耐障害性

Amazon Aurora の耐障害性(障害時のフェイルオーバー)は、一般的なマスター・スレーブ方式の RDBMS のリカバリー方式とは大きく異なります。

一般的なマスタースレーブ方式の RDBMS では、マスターデータベースに障害が発生すると、データベースのエンドポイントがスレーブデータベースに自動的に切り替えられ、障害のあったマスターデータベースは切り離され、新たなスレーブデータベースのインスタンスが起動されます。よって、データベース層の内部では、あたかもマスターとスレーブが入れ替わったかのようになります。

マスタースレーブ方式のデータベースは、より可用性、耐障害性を高めるために、マスターデータベースとスレーブデータベースを異なるアベイラビリティゾーン AZ に配置します。

一方で、Amazon Aurora はクラスターという特徴から、1 つのマスター(書き込み用のためライターとも呼びます)に対して、3 つの異なる AZ に最大 15 のリードレプリカ(マスターの代わりになるのでセカンダリーとも呼びます)を配置することができます。マスターに障害が発生すると、残りの 15 のリードレプリカのうちの 1 つがマスターに昇格します。どのリードレプリカが昇格するか制御することもできます。データベースの書き込み処理は新しいマスターに対して実行されるように切り替わります。読み込み処理には何の影響もありません。障害の起きた古いマスターは切り離され、新しいリードレプリカのインスタンスが起動されます。

Amazon Aurora のセキュリティー

ネットワークの隔離

Amazon Aurora は Amazon VPC で実行されます。これによりデータベースを独自の仮想ネットワークに隔離し、業界標準の暗号化 IPsec VPN を使用してオンプレミスの IT インフラストラクチャに接続できます。さらに、Amazon RDS を使用すると、ファイアウォールを設定して DB インスタンスへのネットワークアクセスを制限することもできます。

リソースレベルのアクセス許可

Amazon Aurora は AWS Identity and Access Management (IAM) と統合されており、お客様の AWS IAM ユーザーおよびグループが特定の Amazon Aurora リソース(DB インスタンス、DB スナップショット、DB パラメータグループ、DB イベントサブスクリプション、DB オプショングループなど)で実行可能なアクションを制限できます。さらに、Amazon Aurora リソースにはタグを付けることができ、同じタグ(およびタグの値)を持つリソースグループで IAM ユーザーおよびグループが実行可能なアクションを制限できます。たとえば、開発者が「Development」DB インスタンスを変更できるものの、「Production」DB インスタンスを変更および削除できるのは管理者のみにするように IAM 規則を設定できます。

暗号化

Amazon Aurora では、AWS Key Management Service (KMS) で作成および管理するキーを使用して、データベースを暗号化できます。Amazon Aurora 暗号化を使って実行するデータベースインスタンスでは、基盤となるストレージに保存される保管中のデータが、同じクラスター内の自動バックアップ、スナップショット、レプリカと同様に暗号化されます。Amazon Aurora では SSL (AES-256) を使用して移動中のデータが保護されます。

Amazon Aurora へのデータベースの移行

Amazon RDS for MySQL または Amazon RDS for PostgreSQL を現在使用している場合、Aurora に移行する作業はきわめて簡単で、スナップショットを作成し、そのスナップショットから Aurora インスタンスを起動するだけで完了します。

ユーザーガイドに記載されている簡単な手順にステップごとに従うだけで、Amazon RDS for MySQL または Amazon RDS for PostgreSQL からの移行を実行できます。Amazon Aurora は MySQL および PostgreSQL と完全に互換であるので、アプリケーションは変更する必要なく、簡単に新しい Amazon Aurora インスタンスに再接続されます。

Amazon EC2 またはオンプレミスで実行されている MySQL データベースから Amazon Aurora への移行も簡単に実行できます。既存のデータベースのスナップショットバックアップを作成し、それを Amazon S3 にアップロードし、それを使用して Amazon Aurora クラスターを直接作成できます。

標準の MySQL のインポートおよびエクスポートのツールや mysql binlog レプリケーションの使用もサポートされています。Amazon EC2 またはオンプレミスで実行されている PostgeSQL データベースから Amazon Aurora EC2 への移行は、AWS Database Migration Service を使用して実行できます。