グローバル分散トランザクションの仕組みを理解する
はじめに
グローバル分散トランザクションの仕組みを理解することは、システムの可用性と整合性を設計する上で不可欠です。本記事では分散システムの課題を知り、時刻の同期について理解を深めることを目指します。
分散システムの課題
分散システムにおいて｢どのイベントが先に起きたか(順序性)｣を決定するのは極めて困難です。各サーバーの物理時計は必ずクロックドリフト(時刻のズレ) を起こすため、単純なシステム時計では正確な順序を保証できません。
これに対し、以下の3つのアプローチがあります。
| 手法 | 代表的なサービス | 特徴 |
|---|---|---|
| TrueTime(物理同期) | Google Spanner | GPSと原子時計を使用し、時刻の｢誤差｣を明示的に扱う |
| Hybrid Logical Clock (HLC) | CockroachDB, YugabyteDB | 物理時刻と論理カウンタを組み合わせ、時刻の逆転を防ぐ |
| Timestamp Oracle(TSO) | TiDB(TiKB) | 単一のマスターがタイムスタンプを発行する(中央集権型) |
TrueTime: 不確実性を｢待ち時間｣で解決する
TrueTimeはGoogle Cloud Spannerで採用されている手法です。
TrueTime APIは現在の時刻を単一の値ではなく｢誤差の範囲を含む時間区間｣として返します。
ここで、誤差を
｢コミット待機(Commit Wait)｣の仕組み
トランザクション
つまり、｢世界中どの時計が最も遅れていても既に
Global Clock(HLC): 物理時計と論理時計の融合
AWSのAurora Global DatabaseやCosmos DB(の一部機能)などで意識される概念です。
完全に同期した原子時計を持たない環境では、Hybrid Logical Clock(HLC) が使われます。
- 物理コンポーネント: NTP等で同期された壁時計(Wall Clock)
- 論理コンポーネント: 同じ物理時刻内でイベントが発生する度にインクリメントされるカウンタ
物理時計が多少ズレていてもメッセージのやり取り(因果関係）がある場合に論理カウンタを調整することで因果一貫性(Causal Consistency) を維持します。
Multi-region Write(マルチリージョン書き込み)
複数のリージョンで同時に書き込みを受け付ける構成です。
コンフリクト解消の戦略
地理的に離れた場所で同じデータが更新された場合、物理法則(光速の限界)により即時の同期は不可能です。そのため、以下のいずれかの戦略をとります。
1. LWW (Last Writer Wins)
タイムスタンプが最も新しいものを正とする。単純ですが、ミリ秒単位の競合で意図しないデータ消失が起きる可能性があります。
2. CRDT(Conflict-free Replicated Data Types)
｢集合への追加｣や｢カウンターの加算｣など、順序に依存せず最終的に同じ状態に収束するデータ構造を用います。
3. Quorum合意
PaxosやRaftアルゴリズムを用い、過半数のリージョンで合意が取れたら確定とする。整合性は高いが、リージョン間の往復遅延(RTT)が書き込みレイテンシに直結します。
設計ポイント
リージョン間レプリケーションを設計する際は、以下のトレードオフを検討する必要があります。
- 強い整合性が必要か
銀行決済などはSpannerのようなTrueTimeベース、またはリージョンを跨いだQuorum合意必要です - 書き込みレイテンシを優先するか
SNSの｢いいね｣などは、各リージョンで即時書き込みを行い、非同期でレプリケーションさせる(最終一貫性) - DR(災害復旧)要件
RPO(目標復旧時点)をゼロにするには同期レプリケーションが必要ですが、パフォーマンスとの兼ね合いになります
PACELC定理を理解していれば理解しやすいですね。
CAP定理、PACELC定理について解説しているので、私の過去の記事もぜひ読んでみてください
Discussion