1. Hadoop の次に考える
分散システム技術
日本マイクロソフト株式会社
萩原 正義
@masayh

2. 次の課題とは
• Hadoop、NoSQL を使った大規模データ分析
– Hadoop のパフォーマンスチューニング、キャパシティプ
ランニング
– MapReduce アルゴリズム
– NoSQL の選択、ZooKeeper の利用
• OLTP アプリケーション
– OLTP は 2PC で連携
– 一貫性保証は ACID か BASE（eventual consistency？）
– 耐障害性は永続化
• 可用性と一貫性のトレードオフ
– レイテンシー、スケーラビリティとのトレードオフは？
• Elastic や 障害による再構成
(C) 2013 Microsoft Corporation 2

3. 目的
• クラウドの分散システムの基礎
– CAP 定理の制約をどのように克服しているか
– 可用性技術がどのように保証されているか
– Hadoop の次の基盤の重要な要素技術は何か
• 分散ストレージ/ファイルシステム
• トランザクショナルアプリケーション
• トランザクション連携
• 高信頼グループコミュニケーション
(C) 2013 Microsoft Corporation 3

4. CAP 定理 Revisited
• Consistency: すべてのクライアントは変更があっても同一の
ビューを見る
• Availability: すべてのクライアントは障害が発生しても、データ
のいくつかの複製を発見することができる
• Partition-tolerance: （分散）システムはネットワークが切断さ
れても、その特性を維持する
• 制約：
– Partition-tolerance に着目しているサービス提供者向け
– レイテンシーの考慮がない
– 障害モードでの補償処理をどう考えるか
– 必要に応じて ACID、合意プロトコルにより一貫性を取る考え方へ
(C) 2013 Microsoft Corporation 4

5. CAP の2特性を選択
C A • Consistency + Availability
• 単一サイト / クラスタデータベース
P • 通常の RDB など
• Consistency + Partition-tolerance
C A • 分散データベース / 分散ロック
P • HBase、Paxos
• Availability + Partition-tolerance
C A • 分散キャッシュ / DNS
P • Cassandra, eventual consistency
(C) 2013 Microsoft Corporation 5

6. 可用性 vs. 一貫性
CAP 定理
(C) 2013 Microsoft Corporation 6

7. Lease
CAP 定理の AP の基本技術
クライアント（キャッシュ、複製）
A.TTL=10
サーバ（データソース）
B.TTL=20
A.TTL=10 C.TTL=10
B.TTL=20
C.TTL=10
D.TTL=15 D.TTL=15
(C) 2013 Microsoft Corporation 7

8. クォーラムシステム
CAP 定理の CP の基本技術
W=N R=1 読み取りに最適化した強い一貫性 (ROWA)
W=1 R=N 書き込みに最適化した強い一貫性
W+R<=N eventual consistency 古いデータの読み取りがありえる
W+R>N, クォーラムによる強い一貫性。読み取りには少なくとも1つ
W>N/2 の最新データの複製を含む
Read quorum
Replica Replica Replica
Manger Manger Manger
Client Front
End
Replica Replica Replica
Manger Manger Manger
Front
Client
End
Replica Replica
Manger Manger
Write quorum
(C) 2013 Microsoft Corporation 8

9. 多数決の原理
primary-backup の場合
現在の primary
• 現在の primary
– コミット済みの更新の永
続化と一貫性 Backup 過半数
– primary のサブネッ
トの可用性
Backup Primary Backup
• 新しい primary（新し
いビュー） Backup
– primary の選出： 新し
いビューのサブネットの
可用性 新しい primary
– 新しいビューでのコミッ
ト済みの更新の引き継ぎ
(C) 2013 Microsoft Corporation 9

10. CAP 定理の制約を超える
• レイヤリング
– CP (クォーラム) を AP (期限付きキャッシュ) に載せる
• トランザクションの時間分割から一貫性モデルの時間
調整 (CA の 2PC の制約)
– メッセージ安定化のフェーズ
– Weak consistency
多数のプロセスですべてのプロセスが更新結果をみなくてもいい状況
異なるプロセスでまだ同期化が実行され
ていないので観測結果が異なってよい
同期化しているので
P2は最新の x の b
が見えないといけない
許容 許容されない
(C) 2013 Microsoft Corporation 10

11. CAP 定理を克服する
スキーマ定義
CP
AP
ネットワーク
非同期特性
(C) 2013 Microsoft Corporation 11

12. 次世代アーキテクチャー
• Soft State
– Weak Consistency
Model
– Timeline consistency
– Read-your-Writes
consistency
– Eventual consistency
• NoSQL
C,
AP (BASE), 非同期
Stateless,
Elastic
CA
(C) 2013 Microsoft Corporation 12

13. 混沌と秩序
A C A C A C
BASE ACID BASE ACID BASE ACID
Superstep Sync Superstep Sync Superstep Sync
非同期 同期 非同期 同期 非同期 同期
混沌 秩序 混沌 秩序 混沌 秩序
(C) 2013 Microsoft Corporation 13

14. まとめ
• リアルタイム、アドホック、双方向性、スケールする更新
• スケーラビリティは可用性、耐障害性（リシリエント）の前
提で考える
– 制御可能性の前提： ビジネス指向で
– 障害モデルの前提： SPOF の想定
– 各種のトレードオフに対する方針と意思決定：
• 一貫性と可用性
• 一貫性とレイテンシー
• スケーラビリティ、スループット、レイテンシー
– 種々の要求： NoSQL、レプリケーション方式、コンピューティ
ングスタイル
• サイエンスとエンジニアリング
– 分散システム、データベース技術、ソフトウェア工学…
(C) 2013 Microsoft Corporation 14

15. 参考文献
「分散システム ～ アーキテクチャーと概念」（仮称）
– CAP 定理
– 合意問題
– アトミックブロードキャスト
– ZooKeeper
– クォーラムシステム
– 複製でのトランザクション（OLTP とメッセージングの融合）
– Snapshot isolation による複製の問題 RM0
Commit Acceptors
Leader 0…2F
RM0…N
– レプリケーションシステムの実装法
– Paxos
– Byzantine 障害対応合意プロトコル
– 複製を隠ぺいする仮想リソース管理
– レプリケーションの安全性評価方法
– システム設計の原則
(C) 2013 Microsoft Corporation 15