cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。
今回発表になった Amazon RDS for Aurora。最大の特徴はストレージが従来のRDS(Multi-AZ)における「完全同期なミラーディスク型のレプリケーション」方式でなく、「Quorumベースの非同期レプリケーション」方式が採用された点です。
Quorumの概念
Quorum自体の概念の説明はWikiなどを参照してください。ノード間で投票を行い、定足数が揃った処理を実行／破棄するという考え方です。
Quorum - Wikipedia
同期型のミラーディスク型から非同期のQuorum型へ
Aurora以外のRDSのMulti-AZ配備は、マスターノードのディスクへの書き込みをブロックレベルでスタンバイ側に適用する完全同期なフィジカルレプリケーションを行っています。これにはいくつかの課題が考えられると思います。
1-wayの課題
マスターからスタンバイへの通信が1-wayなので、ここに特定の遅延原因が発生した場合に同期コミットの完了が待たされる「可能性」が考えられます。
透過的なメンテナンスができない課題
マスターとスタンバイしかディスクがないので、ディスクをメンテナンスする（サイズ変更など）場合に、それそのものをメンテナンスする必要があり、変更時間内は整合性を保つために書き込みを受け付けることができないという課題があります。
ミラーの片方が破損している間はSPoFになる課題
可能性はごくごく小さくなりますが、マスターとスタンバイのディスクのいずれかに障害が発生している場合（マスター障害の場合はスタンバイにフェイルオーバーしますが）復旧までの間に片肺運転状態になりうります。
データベースのスケーラビリティは難しい課題
そもそもWebアプリケーションシステムにおけるリバースプロキシやキャッシュサーバーやWebサーバーは、台数をスケールアウトしてCPUやメモリのスケールアウトが可能です。それに比べてマスターデータベースのCPU、メモリ、ストレージをリニアに拡張するのは非常に難しい課題です。
マスターをシャーディングしてShared Nothig型に分割する方法も考えられますが、クライアント側の対応やデータの適切なリバランス、シャーディングをまたぐデータ走査などの課題もあるため、銀の弾丸とは言えません。
Amazon RDS for Auroraのディスク方式
そこでAuroraが提示した一つの回答がQuorum型のストレージです。
P12の説明
ここでは以下のように記載されています。
- 6-way replication across 3 AZs
- 4 of 6 write quorum
- Automatic failback to 3 of 4 if an AZ is unavailable
- 3 of 6 read quorum
この原理を図示してみましょう。
以降はあくまで原理の説明です、実装がどうなっているか私は知りませんのでご了承ください。
3つの AZ の場合の動作原理
4本の書込みQuorum
4本に(B)を書込めた時点で書込みが「正常完了」になり、残りは非同期でデータの整合が取られる動作ということです。図は正常完了となった瞬間を示しています。Auroraのレプリカラグは10ms以内と言われているのでこの状態が長く維持されるわけではありません。
3本の読込みQuorum
書込みが完了した「瞬間」にデータを読込む場合、最低3本から同一データ(B)が揃った段階で「読み取り完了」になるため、書き込まれたデータより前のバージョンのデータ(A)がDB側に読み込まれることは理論上ありえません。
2つの AZ の場合の動作原理
3本の書込みQuorum
3本に(B)を書込めた時点で書込みが「正常完了」になり、残りは非同期でデータの整合が取られる動作ということです。図は正常完了となった瞬間の状態です。再度念押しですがAuroraのレプリカラグは10ms以内と言われているのでこの状態が長く維持されるわけではありません。
3本の読込みQuorum
書込みが完了した「瞬間」にデータを読込む場合、最低3本から同一データ(B)が揃った段階で「読み取り完了」になるため、書き込まれたデータより前のバージョンのデータ(A)がDB側に読み込まれることはこちらも理論上ありえません。
まとめ
以上のようなAuroraのディスクの特徴が「64TBまで自動リサイズ」「リサイズ時の性能劣化なし」「最大2つのディスクがクラッシュしても自動リカバリ」という機能性を実現する鍵だと言えます。フルサービスのローンチは2015年の早い時期ということなのですが、一刻も早く利用してみたいですね。
またこの「Quorum 的な処理方法」はS3やDynamoDBでも実装されている原理ですので、このあたり押さえておくと、AWSの各サービスの可用性やスケーラビリティの一端が理解しやすいものと思われます。
