こんにちは。ソリューションアーキテクトの江川(@daiti0804)です。本日は、AWS のソリューションアーキテクトである Steve Abraham が、AWS Database Blogに投稿したIntroducing the Aurora Storage Engine をご紹介します。
Amazon Aurora とは?
Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、高性能な商用データベースの可用性とスピード、およびオープンソースデータベースのシンプルさとコスト効果性を併せ持っています。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースが持つようなセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。また、PostgreSQL と互換性のある Amazon Aurora PostgreSQL with Compatibiluty も現在 preview でご利用可能です。
この投稿では、Aurora がそのパフォーマンス、可用性、および信頼性を提供するイノベーションの1つであるストレージレイヤーを深く見ていきたいと思います。
データベースストレージの進化
多くのお客様が、データベースのデータを格納するためにダイレクトアタッチストレージ(DAS) を利用しています。エンタープライズ企業のお客様は、ストレージエリアネットワーク(SAN)を利用しています。これらのアプローチは多くの問題につながります。
- SAN は高価です。多くのお客様にとって、SAN を管理するために必要な物理的な SAN インフラストラクチャ、ストレージの専門知識を抱える余裕はありません。
- パフォーマンスのためにスケールアウトをするには、ディスクストレージは複雑です。うまくできたとしても、DAS, SAN がどれだけスケールできるかについては限界があります。
- DAS, SAN インフラストラクチャはどちらも物理的に単一のデータセンターに存在します。もし、データセンターが停電またはネットワーク障害により、利用できなくなった場合、データベースサーバを利用できなくなります。
- もし、洪水、地震、その他の自然災害によりデータセンターが破壊された場合、データは失われてしまうかもしれません。もし、データのバックアップが遠隔地に保管されている場合、データベースサーバを新しい場所で復旧するのに、数分から数日かかることになります。
Amazon Aurora ストレージエンジン のご紹介
Amazon Aurora は、クラウドの利点を活かすように設計されました。
概念的には、 Amazon Aurora ストレージエンジンは、リージョン内の複数のアベイラビリティーゾーン(AZ) にまたがる分散された SAN です。AZ は、物理的なデータセンター群によって構成される論理的なデータセンターです。各 AZ は、それぞれ独立していますが、同じリージョン内のアベイラビリティーゾーンどうしは低レイテンシーのリンクで接続されており、迅速な通信を行うことを可能にしています。Amazon Aurora の根幹である低レイテンシーな分散型ストレージエンジンは、AZ に依存しています。
ストレージ配置
Amazon Aurora は現在、protection groups と呼ばれる 10 GB の論理的なブロックにそのストレージボリュームを構築しています。各 protection group 内のデータは、6つのストレージノードにまたがってレプリケーションされています。これらのストレージノードは、Amazon Aurora クラスターが存在するリージョン内の3つの AZ にわたって配置されます。
クラスターが作成されたばかりの時は、ストレージ容量はほとんど消費されません。データ量が増え、現在割り当てられているストレージ容量を超えようとすると、Aurora はその要求に応じてシームレスにボリュームを拡張し、必要に応じて新しい protection group を追加します。Amazon Aurora は、64 TB の上限に達するまで、このように拡張し続けます。
Amazon Aurora の書き込み処理
Amazon Aurora にデータが書き込まれると、並列に 6つのストレージノードに送られます。これらのストレージノードは、3つの Availability Zones に配置されているので、堅牢性と可用性が大幅に向上されていると言えます。
(訳者注:以下の説明は、こちらのスライドを合わせてみていただくと理解しやすいかと思います。)
各ストレージノードでは、書き込まれたレコードはまずメモリ上のキューに入ります。 このキューに入ったログレコードは、重複排除されます。例えば、マスターノードが正常にストレージノードへの書き込みを行ったが、マスターノードとストレージノード間の接続が中断された場合、マスターノードは、ログレコードを再送信します。ですが、ログレコードが重複された場合は破棄されます。保持されるべきレコードは、ホットログとしてディスクに格納されます。
レコードが永続化されると、ログレコードは update queue と呼ばれるインメモリの機構に書き込まれます。update queue 内では、ログレコードはまず結合され、そして、データページの作成に利用されます。もし、1つまたは複数のログシーケンス番号(LSN)が欠落していると判断されると、ストレージノードは、欠落した LSN をボリューム内の他のノードから取得するためのプロトコルを使用します。データページが更新されると、ログレコードはバックアップされ、ガベージコレクションのためにマークされます。データページは、非同期に Amazon S3 へバックアップされます。
ホットログに書き込まれることで、書き込みの永続化がなされると、ストレージノードはデータの受信を確認します。6つのうち、少なくとも 4つのストレージノードが受信を確認すると、書き込みが成功したとみなされて、ACK がクライアントアプリケーションに返されます。
Amazon Aurora が他のエンジンと比べて、非常に高速に書き込みができる理由の 1つが、ログレコードをストレージノードに送信するだけであり、それらの書き込みが並列に行われるということです。実際、データが 6つの異なるノードに書き込まれているのにもかかわらず、同様のワークロードにおいて、MySQL と比較すると平均して、Amazon Aurora は約1/8 の IOPS しか必要ありません。
このプロセスの全てのステップが非同期に行われます。グループコミットを使用し、書き込みは並列に実施され、レイテンシーは低く、スループットが向上されます。
書き込みレイテンシーが低く、I/O フットプリントが小さくなっているため、Amazon Aurora は書き込みが集中するアプリケーションに最適です。
耐障害性
下記の図は、データが 3つの AZ に格納されていることを示しています。レプリケートされたデータは継続的に、99.999999999 % の堅牢性を持つように設計されている S3 へバックアップされます。
この設計により、Amazon Aurora は 1つの AZ 全体、もしくは 2 つのストレージノードに障害が起きたとしても、クライアントアプリケーションに影響なく稼動することができます。
リカバリ中、Aurora はデータを失うことなく、AZ および protection group 内のその他のストレージノードを維持するように設計されています。これは、protection group 内の 4つのストレージノードが存続する場合に、書き込みが堅牢に行えるようになっているためです。もし、書き込みが行われた3つのストレージノードがダウンした場合でも、Aurora は 4番目のストレージノードで書き込みを回復できます。リカバリ中、読み込みのクォーラムを確立するために、Auora は、3つのストレージノードが同じ LSN に追いついたかを確認します。しかしながら、書き込みを行うには、Aurora は、4つのストレージノードが復旧するのを待つ必要があります。それによって、書き込みクォーラムを確立することができます。
読み込みの場合、Aurora は最も近いストレージノードを見つけようとします。各読み込みのリクエストは、タイムスタンプ、つまり LSN に関連付けられています。ストレージノードは、LSN に追いついている(言い換えると、その LSN までの全ての更新を受信している)場合に読み込みを実行できます。
1つ、もしくは複数のストレージノードがダウン、もしくは他のストレージノードとの通信ができない場合、それらのノードはゴシッププロトコルを使い、オンラインになった際に再同期しようとします。
Amazon Aurora では、コンピュートとストレージが疎結合になっています。これにより、リードレプリカがレプリカ自身にデータを保持することなく、ストレージ層へのコンピュートインターフェースとして動作します。これは、リードレプリカにデータを同期させる必要がないため、リードレプリカがすぐにオンラインになるとすでにトラフィックを処理できることにつながります。同様に、リードレプリカの障害は、配下のデータに影響ありません。リードレプリカがマスタノードに昇格するときも、データロストは発生しません。Amazon Aurora は、最大 15 個のリードレプリカとリーダーエンドポイントがサポートされているので、高可用性が求められ、読み取りが集中するワークロードにも最適です。
バックアップとリカバリ
Amazon Aurora では、エンドユーザーへパフォーマンスの影響なく、データは継続的に S3 へリアルタイムにバックアップされます。このため、バックアップウィンドウや自動バックアップのためのスクリプトが不要になります。また、ユーザーが定義したバックアップ保持期間内の任意の時点にリストアすることも可能です。さらに、全てのバックアップは 複数のデータセンターにデータが複製され、99.9999999999% の耐久性が提供された非常に堅牢な S3 に格納されるため、データ損失のリスクが非常に低くなります。
ユーザーの任意の時点で、Aurora クラスタ内のデータのスナップショットを取得することもできます。この場合でも、パフォーマンスに影響なく実施可能です。
Amazon Aurora のバックアップからのリストアを行う場合、各 10 GB の protection group が並列にリストアされます。これは、64 TB のバックアップをリストアするのにかかる時間は、10 GB のバックアップを復元するのと同様だということを意味します。さらに、protection group がリストアされた後、ログを適用する必要はありません。これにより、Amazon Aurora は、protection group がリストアされるとすぐにピークパフォーマンスで動作することができます。
セキュリティ
Amazon Aurora では、 AES-256 で保管時のデータ暗号化を行うことが可能です。ユーザーは、AWS Key Management Service (AWS KMS) を利用して、暗号鍵の管理を行うことができます。通信中のデータは、Amazon Aurora クラスタへ TLS 接続を介して保護されます。これらの機能に加えて、Amazon Aurora は、SOC 1, SOC 2, SOC 3, ISO 27001/9001, ISO 27017/27018, PCI を含む複数の認証を取得しています。
まとめ
Amazon Aurora は、クラウドのために設計されました。複数のアベイラビリティーゾーンにわたってデータを分散することにより、Amazon Aurora は非常に堅牢で、高可用なデータベースエンジンとして提供されています。多くのイノベーションにより、他のリレーショナルデータベースエンジンよりも読み込み、書き込みのスループットは大きく向上しています。データベースのリストア操作も同様です。最後になりますが、Amazon Aurora がマネージドサービスのため、バックアップ、パッチ適用、ストレージ管理などの差別化に繋がらない重たい運用作業をすべて AWS に任せることができます。
ぜひ Amazon Aurora をご利用ください:https://console.aws.amazon.com/rds/home?region=ap-northeast-1#launch-dbinstance:ct=gettingStarted
Amazon Aurora の最新機能を含む、より深い内容については、Web Seminar の動画をごらんください:https://m.youtube.com/watch?v=VrWH518sObk(訳者注: 左記の内容と完全に同じものではございませんが、日本語での動画については、 https://connect.awswebcasts.com/p1fee0ktvlg をごらんください。その資料については、http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-aurora をごらんいただければと思います。)