# クォーラムベースレプリケーション ## 定義 クォーラムベースレプリケーション（Quorum-Based Replication）は、レプリケートされたデータシステムにおいて、読み込み・書き込み操作のそれぞれに一定数以上のレプリカからの承認（クォーラム）を要求することで、整合性と可用性のトレードオフを制御する手法である。データの V コピーが存在する場合、書き込みクォーラム Vw 票と読み込みクォーラム Vr 票を設定し、(1) Vr + Vw > V（読み込みが最新書き込みを必ずカバー）、(2) Vw > V/2（書き込み間の競合を防止）の 2 条件を満たす組み合わせを選ぶ。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) 一般的な 3 コピー構成（V=3, Vw=2, Vr=2）は単一ノード障害に耐えるが、クラウド規模の相関障害（AZ 全体の喪失）には不十分。Aurora は V=6, Vw=4, Vr=3 の設計で AZ+1 障害耐性を実現する（各 AZ に 2 コピーずつ配置）。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) ## 横断的知見 - **AZ 障害は相関障害であり非相関の個別ノード障害とは本質的に異なる扱いが必要**: 個別ノード障害は独立だが、AZ 障害は同一 AZ 内の全ディスク・ノードを同時に失う。したがって「3 コピー 2/3 クォーラム」は AZ 障害 + 別 AZ の独立障害が同時発生した場合にクォーラムを失う。Aurora の 6 コピー 4/6 設計はこの組み合わせを明示的に考慮した設計であり、セグメント修復 MTTR（10 秒）と組み合わせることで実用的な耐久性を実現する。クォーラム設計の前提をクラウド環境の障害モデルに合わせることが重要。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **クォーラムセット（Boolean 論理の重複クォーラム）によりメンバーシップ変更を非ブロッキック・リバーシブルに実現できる**: 従来の単一クォーラムセットでは、F を G で置き換える場合に ABCDEF→ABCDEG の直接遷移（Paxos Membership Change 等）が必要で I/O ストールが生じる。Aurora 2018([[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]])はクォーラムセットを Boolean 論理で組み合わせ、中間状態（ABCDEF と ABCDEG の両方が有効）を経由する。ABCD への書き込みが両方のセットを満たすため I/O が止まらず、F が復帰すれば ABCDEF に戻れる。エポックインクリメント 1 回で移行・フェンシング・再受け入れを処理できる。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) - **フルセグメント 3 本 + テールセグメント 3 本の非対称設計でコスト増幅を 6× から約 3× に削減できる**: 6 ウェイレプリケーションではデータブロックを 6 コピー保持することになるが、Aurora 2018 は各 PG をデータブロックを持つ「フルセグメント」3 本と Redo のみの「テールセグメント」3 本に分ける。書き込みクォーラムは 4/6 の任意セグメントで、読み込みはフルセグメントから直接行う。Redo ログの増幅は 6× だが、データブロックの増幅は約 3× に抑えられる。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) ## 未解決の問い - 書き込みクォーラム Vw=4/6 はレイテンシジッターにどの程度影響するか？最速の 4 台から ACK が返れば完了するため、残り 2 台の遅延は無視できる。クラウドの「背景ノイズ」ノードに対してこの設計がどの程度有効かの実測データは本論文では限定的。 - セグメントサイズ（10GB）の最適値はネットワーク帯域・MTTR・クォーラム設計の組み合わせで決まるが、どのようなトレードオフ空間があるか？ - Bigtable（[[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]）や分散 PostgreSQL など他の分散ストレージがどのようなクォーラム設計を採用し、Aurora と比較してどのようなトレードオフを選んでいるか？ - クォーラムセットの非ブロッキング性は Boolean 論理で証明されているが、64TB（38,400 セグメント）スケールで多数のメンバーシップ変更が同時発生するとき（AZ 全体の障害等）の実運用挙動は？ ## 関連 - [[分散ストレージ]] — クォーラムが解決する可用性・整合性問題の文脈 - [[コンピュートストレージ分離]] — Aurora でクォーラムが適用されるストレージ層の設計 - [[クラッシュリカバリ]] — クォーラム設計がリカバリ高速化にどう寄与するか - [[分散コンセンサス回避]] — Aurora がクォーラムを活用しつつ 2PC/Paxos を不要にする設計原則 - [[Amazon Aurora (Database)]] — クォーラムベースレプリケーションの実装例 ## 出典 - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]（V=6, Vw=4, Vr=3 クォーラム設計の詳細・AZ 障害モデル・セグメント化 MTTR との組み合わせ） - [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]（クォーラムセット + エポックによる非ブロッキックメンバーシップ変更・フル/テールセグメント非対称設計）