Amazon Aurora Under the Hood: クオーラムの読み取りと状態の遷移

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。

前回の投稿では、クォーラムモデルの利点をお話しました。レイテンシーの異常値や短期間のダウンタイム、ディスクとノードの長期的な喪失に直面して、このようなシステムがいかに耐久性があるかについて説明しました。この投稿は、1つの疑問を提起します – もし、クオーラムがとても素晴らしいのであれば、なぜ皆使わないのでしょうか？

クォーラムシステムにおける読み取りの性能劣化
1つの問題は、クォーラムシステムでは読み取りが遅くなることです。クォーラムモデルでは、読み込みクォーラム、書き込みクォーラムともに、少なくとも1つのメンバーが必要です。 Amazon Aurora のような6つのメンバーを持つクォーラムシステムでは、書き込みクォーラムの 4 つメンバーを持ちながら、3つのデータのコピーを読み込む必要があります。これは不運です。データベースのページを読み取る場合、通常、バッファキャッシュにヒットしなかったことを意味し、次の処理に進む前に、I/O 処理を待って、SQL 文がブロックされます。3つのデータのコピーを読むには、およそ5回アクセスすることで、異常値を含むレイテンシーや一時的に発生する可用性の問題に対処するのが良いでしょう。そのようにすることは、ネットワークに大きな負荷をかけることになります。データベースページは、かなり大きく、読み取りによる増幅は容易に想像できます。クォーラムシステムの読み取りパフォーマンスは、従来のレプリケーションシステムと十分に比較されているとは言えません。従来のレプリケーションシステムでは、データがすべてのコピーに書き込まれますが、読み取りは、そのうちのどれか1つへアクセスします。

しかしながら、Aurora は、書き込み中、クォーラムによる増幅を避けています。Aurora では、6つのコピーに対して書き込みを行いますが、ログレコードしか書き込みません。データページの全領域を書き込むわけではありません。データページは、以前のバージョンのデータページと送られてくるログを元にストレージノードで組み立てられます。また、非同期に書き込むことができます。これらは読み取りには対応できません。

読み込みクォーラムのオーバーヘッドを避ける方法
読み込みクォーラムのオーバーヘッドは、クォーラムシステムにとって明らかに不利な点です。どのように避けることができるでしょうか？鍵となるポイントは、状態(state)を使うことです。

ノードをスケールさせるに伴い、一貫した状態を管理し、調整するのが難しいため、分散システムにおいて、状態という単語はしばしばよくないワードとして考えられ、不具合を引き起こします。もちろん、データベースシステムの全目的は状態を管理し、原子性、一貫性、独立性、永続性(ACID)を提供することです。Aurora は、これら二つの技術領域が交わる点に位置します。我々のイノベーションの大部分は、1つの領域のコンセプトを適用し、もう1つのドメインの進化を推し進めることから生まれています。

もっとも、通信なしに分散されたそれぞれの状態を一致させることは困難ですが、一致、調整、またはロックの必要性を避けるために利用できる一貫性のローカル領域があります。ここで紹介できる例としては、リードビューがあげられます。多くのデータベースシステムでも同様のコンセプトを持っていますが、ここでは MySQL にフォーカスします。

全てのリレーショナルデータベースと同様に、MySQL は ACID をサポートします。リードビューは論理的な時点を確立します。SQL 文は、その時点より前にコミットされた全ての変更を参照可能となり、まだコミットされていない変更は参照できないようにならなければいけません。MySQL では、直近のコミットのログシーケンス番号(LSN)を確立することで、これを実現しています。このアプローチにより、既にコミットされているすべての変更が参照可能となることが保証され、アクティブなトランザクションの一覧を利用することで、参照されてはならない変更の一覧を作成します。特定のリードビューに対するSQL 文がデーターページをチェックする際、その SQL 文がリードビューを確立した時点でアクティブだったトランザクションに対するいかなる変更も見えなくする必要があります。たとえ、これらの変更が現在コミットされたものであったとしてもこれは同様であり、リードポイントコミット LSN の後に開始された全てのトランザクションについても同様です。トランザクションがリードビューを確立した際に、一貫性のある時点に適切に戻すことができるのであれば、システムで実行されるいかなる変更からも、そのトランザクションから分離できます。

読み込みクォーラムにおいて、これをどう実現すれば良いでしょうか？全てです。データベースは、ストレージノードに対して継続的に書き込みを行います。ACK を受け取るたびに、データベースは各変更が堅牢なものであるとマークします。それ以前の全ての変更がそれぞれ堅牢であると登録されると、ボリュームポイントが堅牢であると更新されます。参照リクエストが来ると、そのリクエストは、データベースが参照しなければならない リードポイントコミット LSN を持ちます。 そのリクエストは、データベースによって、リードポイントコミットLSN を処理可能なことが分かっているストレージノードへと単に転送されます。

このアプローチでは、簿記のように状態管理を行うことによって、クォーラムの読み取りを回避します。その代わり、必要とするデータバージョンを把握しているノードから読み取りを行います。このアプローチにより、ネットワーク、ストレージノード、データベースノードで行われる通信を大幅に抑えられます。

レイテンシーを避ける方法
しかしながら、読み込みクォーラムを避けることによって、単一のストレージノードのレイテンシーに左右されることになります。これについては、ストレージノードに対する読み取りリクエストのレスポンスタイムをトラックすることにより対応してます。通常、読み取りリクエストは最もレイテンシーの低いノードに対して行われます。レイテンシーの情報を最新に保つため、時折、その他のノードに対してもクエリされます。

これは、1つのデータベースノードに対しては非常に分かりやすい作業です。なぜなら、全ての書き込みを認識し、全ての読み込みを調整することができるからです。リードレプリカのことを検討する場合、より複雑です。 Aurora では、リードレプリカは同じストレージボリュームを共有します。同時にマスターデータベースノードから、非同期にマスターの redo ログストリームを受け取り、キャッシュ上のデータページを更新します。このアプローチは、コストの観点で最も安いというだけではなく、データロストや同期レプリケーションによる書き込みレイテンシーなしに、レプリカのマスターノードへの昇格を可能にします。マスターノードへの ACK によりコミットされたとマークされた変更は、たとえレプリカにまだ伝播していなかったとしても、すべて堅牢です。これらのレプリカノードは、それぞれで読み込みを行い、書き込みとその ACK を見ることはできず、それにより何を読み込むべきか把握することはできません。

そのため、redo レコードがマスターからレプリカへ送られる際に、概念的にリードビューと同等のものが送られます。このビューにより、コミットLSNとLSNが堅牢であると示すセグメントの情報が更新されます。通常、コミットLSN を約 10ミリ秒ごとに更新することができます。それにより、レプリカをマスターノードとの差分を最小限に保ちます。

破壊的な書き込みの回避
このアプローチの鍵は、破壊的な書き込みの回避です。リードレプリカとマスター間の通信を調整しなければいけない理由の大部分は、読み取るデータが確実に表示されるようにすることです。以前のページイメージに戻すことができる限りは、リードビューにより、その調整負荷は大幅に減少されます。Aurora では、データページを別の場所に書き込みます。古いバージョンは、バックアップされ、すべてのリーダーがリードポイントをそのバージョン以上に更新した際に、ガベージ・コレクションされます。このアプローチにより、マスターノードより数ミリ秒遅れているレプリカノードでも一貫したビューを持つことができます。

トランザクションをロールバックすることがあったとしても、リレーショナルデータベースは、その根底において、常に更新される redo ログです。データベースを構成するデータページは、実のところ、アプリケーションの redo ログを一時的にキャッシュして具現化したものに過ぎません。多くのデータベースが破壊的にデータページを書き込むという事実は、実際、リレーショナルデータベースが最初に作成された際の高コストなディスクに基づく歴史的な好奇心です。

Aurora では、上記で説明したアプローチを用いるため、読み込みクォーラムを利用しません。その代わり、修復クォーラムを利用します。読み込みクォーラムにクエリする必要があるのは、書き込みマスターデータベースノードにおいてキャッシュの状態を失う時だけです。もし、マスターインスタンスを再起動、もしくはレプリカをマスターに昇格させなければいけない場合、ローカルの状態を再構築するため、少なくとも1度、読み込みクォーラムにクエリする必要があります。いずれにしても、どのようなトランザクションがコミットされているか把握するためにそうしなければならないことは明らかでしょう。これについては、いつか別のブログでお話しすることになるかもしれません。データベースのクラッシュが、読み取りに比べて発生頻度が少ないことを考えると、このトレードオフをとる価値があります。

まとめ
この投稿と前回の投稿で、可用性を提供するためにどのようにクォーラムを使用するか、どのように従来の読み込みクォーラムのオーバーヘッドを回避するかについて確認しました。次回の投稿では、クォーラムシステムをコストの観点でどのように利用しやすくするかについてお話します。もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。

次回: Amazon Aurora Under the Hood: クオーラムセットを使ったコスト削減

翻訳は江川が担当しました(原文はこちら)