Auroraの非機能要件面での優位性
AuroraにはRDBMSで重要な非機能要件である可用性、パフォーマンス、拡張性、耐久・耐障害性、運用・保守性の5つの優位性を有している。これらは分離されたコンピュート、ストレージレイヤーからもたらされ、通常のRDSと大きく違うところだ。異なるAZを用い分散型の共有ストレージに冗長化してデータコピーを保持、データコピーのサブセットに読み込み・書き込みを行う“クォーラムモデル”で高耐久なストレージを実現しているという。
クォーラムモデルでは、6分の3の読み込みクォーラム、6分の4の書き込みクォーラムを採用している。 そのため、AZの障害に加えて、別のAZのデータ破損が起きてもリード処理を継続でき、 ライト処理ではAZに障害が発生し冗長化された2つのデータにアクセスできなくてもトランザクションを継続可能だ。 加えて、データのリード/ライト処理で一部のストレージレイヤーに遅延が発生してもI/O性能は失われない。
なお、Auroraでは通常のRDSよりも多くのデータコピーを持つため、I/Oオーバーヘッドが大きくなる懸念もあるかもしれないが、それにも工夫がなされている。一般的にRDBMSでは、メモリ上のダーティバッファをディスクに書き出すためのチェックポイントがボトルネックとなりやすい。しかし「Auroraは、そもそもこのチェックポイントの概念が存在しません」と神山氏。
PostgreSQLでは、共有バッファがチェックポイントでストレージに書き出され、これがI/Oの負荷となる。一方AuroraではWALのみを非同期かつ並列に書き込み、スループットの向上を図っているという。「WALを使い常にストレージレイヤーでデータは更新されます。これにより、6つのデータコピーを保持していても通常のRDSと比べI/Oが過多になるなど、パフォーマンスが悪化することはありません」と神山氏は説明する。
Auroraでは、Protection Groupと呼ばれる10GB単位の論理ブロックでストレージノードにデータを格納する。この区分けされた10GBの論理ブロックの中で、3つのAZに冗長化し複数ストレージノードでデータを管理する。Protection Groupは最大12,800個まで持つことができ、多数のストレージノードでストライピングしてデータを管理できる。また、データの欠損、破損はP2P（Peer to Peer）のゴシッププロトコルにより各ストレージノード間で自動修復され、ノード障害にも新たなストレージノードがアサインされてデータが同期されるため、管理者がリカバリをする必要はない。
AWSが公開しているベンチマークテストでは、OSS（オープンソースソフトウェア）のPostgreSQLと比較して、Auroraは同時接続数が増加するにしたがってリニアにスループットが向上し、2,048の同時接続数ではOSSに比べ約3倍のスループットとなる。
「RDS for PostgreSQL」のリードレプリカは、WALを用いた論理レプリケーションのため、マスターのワークロードによってはラグが大きくなることも懸念される。しかしながらAuroraはページキャッシュ更新リクエストによるレプリケーションで、かつレプリカ側で一切の書き込みを行わないため、遅延範囲も20～100ミリ秒と少なく収まる。加えて、共有ディスクのため、フェイルオーバー時にコミットしたデータの消失もない。
また、ページキャッシュをデータベース機能と分離して管理することで、インスタンス障害やインスタンスの再起動時などにもページキャッシュ情報がクリアされず、迅速な再開が期待できるという。さらにチェックポイントの概念がなく、常にストレージノードでロールフォワードが行われるため、リカバリ時にも更新ログは最小となり、多くの場合60秒以内という高速クラッシュリカバリも可能となっている。
なお、Auroraではデータ量が増加すると128TBまでProtection Groupが自動増加する。そのため、Auroraの設定画面にはストレージサイズの項目がないのだ。
