Hadoop

Hadoop の次に考える分散システム技術

日本マイクロソフト株式会社萩原正義@masayh

次の課題とは

• Hadoop、NoSQL を使った大規模データ分析

– Hadoop のパフォーマンスチューニング、キャパシティプランニング

– MapReduce アルゴリズム

– NoSQL の選択、ZooKeeper の利用

• OLTP アプリケーション

– OLTP は 2PC で連携

– 一貫性保証は ACID か BASE（eventual consistency？）

– 耐障害性は永続化

• 可用性と一貫性のトレードオフ

– レイテンシー、スケーラビリティとのトレードオフは？

• Elastic や障害による再構成2(C) 2013 Microsoft Corporation

目的

• クラウドの分散システムの基礎

– CAP 定理の制約をどのように克服しているか

–可用性技術がどのように保証されているか

– Hadoop の次の基盤の重要な要素技術は何か

3

• 分散ストレージ/ファイルシステム• トランザクショナルアプリケーション• トランザクション連携• 高信頼グループコミュニケーション

(C) 2013 Microsoft Corporation

CAP 定理 Revisited

• Consistency: すべてのクライアントは変更があっても同一のビューを見る

• Availability: すべてのクライアントは障害が発生しても、データのいくつかの複製を発見することができる

• Partition-tolerance: （分散）システムはネットワークが切断されても、その特性を維持する

• 制約：

– Partition-tolerance に着目しているサービス提供者向け

– レイテンシーの考慮がない

– 障害モードでの補償処理をどう考えるか

– 必要に応じて ACID、合意プロトコルにより一貫性を取る考え方へ

4(C) 2013 Microsoft Corporation

CAP の2特性を選択

5

C A

P

• Consistency + Availability

• 単一サイト / クラスタデータベース

• 通常の RDB など

C A

P

• Consistency + Partition-tolerance

• 分散データベース / 分散ロック

• HBase、Paxos

C A

P

• Availability + Partition-tolerance

• 分散キャッシュ / DNS

• Cassandra, eventual consistency


可用性 vs. 一貫性CAP 定理


LeaseCAP 定理の AP の基本技術

7

A.TTL=10

B.TTL=20

C.TTL=10

D.TTL=15

A.TTL=10B.TTL=20C.TTL=10D.TTL=15

サーバ（データソース）

クライアント（キャッシュ、複製）


クォーラムシステムCAP 定理の CP の基本技術

8

W=N R=1 読み取りに最適化した強い一貫性 (ROWA)

W=1 R=N 書き込みに最適化した強い一貫性

W+R<=N eventual consistency 古いデータの読み取りがありえる

W+R>N, W>N/2

クォーラムによる強い一貫性。読み取りには少なくとも1つの最新データの複製を含む

Client

ReplicaManger

ReplicaManger

FrontEnd

Client

ReplicaManger

FrontEnd

ReplicaManger

ReplicaManger

ReplicaManger

ReplicaManger

ReplicaManger

Read quorum

Write quorum


Primary

Backup

Backup

Backup

Backup

多数決の原理primary-backup の場合

9

• 現在の primary

– コミット済みの更新の永続化と一貫性

– primary のサブネットの可用性

• 新しい primary（新しいビュー）

– primary の選出：新しいビューのサブネットの可用性

– 新しいビューでのコミット済みの更新の引き継ぎ

過半数

現在の primary

新しい primary


CAP 定理の制約を超える

10

許容されない許容

異なるプロセスでまだ同期化が実行されていないので観測結果が異なってよい

同期化しているのでP2は最新の x の bが見えないといけない

多数のプロセスですべてのプロセスが更新結果をみなくてもいい状況

• レイヤリング

– CP (クォーラム) を AP (期限付きキャッシュ) に載せる

• トランザクションの時間分割から一貫性モデルの時間調整 (CA の 2PC の制約)

– メッセージ安定化のフェーズ

– Weak consistency


CAP 定理を克服する

11

スキーマ定義

CP

AP

非同期特性

ネットワーク


12

次世代アーキテクチャー

AP (BASE), Stateless,

Elastic

C,非同期

CA

• Soft State

– Weak Consistency Model

– Timeline consistency

– Read-your-Writesconsistency

– Eventual consistency

• NoSQL


混沌と秩序

13

A A AC C C

BASE BASE BASEACID ACID ACID

Superstep Superstep SuperstepSync Sync Sync

非同期非同期非同期同期同期同期

混沌混沌混沌秩序秩序秩序


まとめ

• リアルタイム、アドホック、双方向性、スケールする更新

• スケーラビリティは可用性、耐障害性（リシリエント）の前提で考える

– 制御可能性の前提：ビジネス指向で

– 障害モデルの前提： SPOF の想定

– 各種のトレードオフに対する方針と意思決定：

• 一貫性と可用性

• 一貫性とレイテンシー

• スケーラビリティ、スループット、レイテンシー

– 種々の要求： NoSQL、レプリケーション方式、コンピューティングスタイル

• サイエンスとエンジニアリング

– 分散システム、データベース技術、ソフトウェア工学…


参考文献「分散システム～アーキテクチャーと概念」（仮称）

– CAP 定理

– 合意問題

– アトミックブロードキャスト

– ZooKeeper

– クォーラムシステム

– 複製でのトランザクション（OLTP とメッセージングの融合）

– Snapshot isolation による複製の問題

– レプリケーションシステムの実装法

– Paxos

– Byzantine 障害対応合意プロトコル

– 複製を隠ぺいする仮想リソース管理

– レプリケーションの安全性評価方法

– システム設計の原則

15

RM0

Commit

LeaderRM0…N

Acceptors

0…2F


Hadoop

Documents