先日の発表で、Amazonは、Aurora Multi-Masterの一般供与を開始すると公表した。これにより、複数のアベイラビリティーゾーンにわたる、複数のデータベースインスタンスを対象とした読み取りと書き込みが可能になる。結果として、データベースインスタンス障害時にプラットフォームがフェールオーバを起動する必要がなくなるため、高可用性機能が実現することになる。
Amazon Auroraはリレーショナルデータベースである。オープンソースデータベースのMySQLやPostgreSQLと互換性を持ち、複数の計算ノードとマルチアベイラビリティゾーン・ストレージレイヤによって支援され、Amazon Relational Database Service(RDS)によって完全に管理されている。要するに、MicrosoftのAzure Database ServicesやGoogleのCloud SQLなど、他の大規模なクラウドプロバイダのサービスと類似したサービスである。新機能であるMulti-Masterに関しては、現状はMySQL互換エディションでのみ使用可能であること、リージョンが限定されていること、サポートする書き込みノードが最大２つであることなどに注意が必要だ。
従来はシングルマスターモードのみが使用可能であったため、Auroraデータベースインスタンスの障害によって別のインスタンスへのフェールオーバーが発生していた。このフェールオーバに伴う書き込み操作のダウンタイムは、データベースに依存するが、CNAMEレコードの調整の場合で30秒、データベースの再起動を伴うには60秒にまで達する可能性がある。しかしながら、Multi-Masterが導入されたことで、現在はフェールオーバの必要性を排除する手段が存在することになる。フェールオーバに代えて、アプリケーションが読み取りや書き込み操作を、すでに起動して動作中で、他のデータベース操作を処理している別のインスタンスにリダイレクトすることができるのだ。さらに望ましいのは、接続やデータベースの正常性を追跡監視し、データベース呼び出しの論理的分配を行うような、シングルトンを実装した専用のコネクションマネージャがこれを行うことだ。
Aurora Multi-Masterを使用する場合、クラスタ内の各ノードはリーダ(reader)とライタ(writer)の両方として振る舞う。従ってアプリケーションは、すべてのノードを使用してワークロードを処理することが可能になる。このことは、データベースの高可用性を実現する一方で、レプリケーションと一貫性に関わる問題を引き起こす可能性もあるが、幸いなことにプラットフォームが、マスタノードの提示する変更を承認または拒否するストレージノードのクォーラムを使ってこれを処理してくれる。最適なパフォーマンスを得るために、コネクションマネージャは、同じページができるだけヒットしないようにコネクションを分散することによって、書き込みの競合を可能な限り回避する必要がある。このテーマに関しては、Amazon Web ServicesのソリューションアーキテクトであるMukund Sundararajan氏が、アプリケーションの設計時のベストプラクティスをいくつか提供している。
- 並行動作するライタによるページ更新の重複実行を回避すること。データベースがシャーディングされている場合は、ライタをひとつのシャードに割り当てて、割り当てられたライタを通じてシャードを更新することが望ましい。マッピングが論理的なのはアプリケーション層のみである。物理的には、ストレージボリューム内のデータは、すべてのライタノードから見えているので、シャードにまたがるトランザクションであっても、単一のライターから実行することができる。
- データベースノードによってアプリケーション層の競合が発生した場合は、トランザクションを再試行すること。指数関数的バックオフなどの手法によってバッファープールがレプリケーションに追いつき、トランザクションが更新したページの最新の変更を反映するための時間が与えられることで、成功の可能性が高くなる。
- 独自のアプリケーションの設計とニーズに基づいて、許容可能な書き込み競合率、ライタ使用率の同等化、最高の可用性を実現する方法で、クエリをライタにルーティングすること。
デフォルトでは、Auroraは書き込み後の読み込み一貫性(read-after-write consistency)を使用する。書き込みと読み込みが同じノードで実行された場合、読み込んだデータには一貫性があるが、他のノードで一貫性に達するまでには数ミリ秒を要する場合がある。これに加えて、Multi-Masterクラスタでは、グローバルリードアフターライト(global read-after-write、GRAW)と呼ばれる別のオプションをセッションレベルで提供する。GRAWでは、どのノードが更新を行っても、一貫性のあるデータのみを提示することが可能である。このような処理の実装にはパフォーマンスの低下が伴うため、Amazonでは、この動作が必要な特定のクエリにのみ適用することを推奨している。