クラウドを支える基盤技術の最新動向と今後の方向性

クラウドを支える基盤技術の

最新動向と今後の方向性日本マイクロソフト株式会社萩原正義@masayh

目的

• クラウドの分散システムや大規模データベー

ス技術の発展の歴史、現在の動向、将来の方

向性

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

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

– OLTP が分散システムでどう拡張されたか

– 開発手法として考えていくべき課題と対応は何か

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

(C) 2012 Microsoft Corporation 2

Agenda• 分散システムとは

– CAP 定理

• 可用性を支える複製

– P-B

– ROWA

– quorum

– RSM、Paxos

– A/E 分離

• スケーラビリティ OLTP プロトコルの発展

– Group safety

– 2PC に代わる atomic broadcast

– View synchronous

• 設計論

– 次世代アーキテクチャー

– CAP 定理の制約を超える

– 混沌と秩序

– 最適化の方法

– 抽象データ(型)の応用(C) 2012 Microsoft Corporation 3

分散システムとは

分散システム再評価の背景

• Hadoop で分散プログラミングモデルが普及

• クラウドの普及で可用性確保で fault-tolerance が必要

• ZooKeeper のような OSS のサービス部品の再利用可能性

• 1970年代のトランザクションが1980年代のグループコミュニケーションで進化

– さらに、HTTP/XML から WebSockets で分散が再興。双方向と提案型

– 特許有効期間は20年

• Big Data で、データ分析基盤のフロントの更新系サービスで分散システムの利用

– 分析対象の収集のためのサービス化を考える

– フロントでのソーシャルのタイムラインの一貫性など、可用性と応答時間のバランスを考えることが重要視される

• serializability による証明可能化、形式化


分散システムとは何か• 確実な障害検出ができない

– 単なるネットワークの遅延なのか、相手の障害なのか

• その前提で以下の機能が求められる

– 複製の一貫性のための合意

– リーダー障害時のリーダーの選出（合意）

– 参加メンバーのリストの合意

– 分散排他制御

– それらのリカバリー、再構成を含むアルゴリズム、プロトコル

• 原子的ブロードキャストプロトコル

• ベクタークロック

• 障害検出器

• 分散プロトコルの証明

– 障害モデルの前提（転送の信頼性、非同期性、Fail-stop/Byzantine、認証）

– Safety、liveness の証明

– 障害検出器とクロック


分散システムの難しさ• elastic なリソース管理、再構成定義

– 負荷に応じて

– 障害に応じて、リカバリー

• 構成変更中も動作を止めない

– 複数のラウンドに分割（ビュー/バロット/エポックの同期）

• 複合障害への対応

– SPOF の許容度

– 障害モデルごとの対応

• 各種要素のバランスでアルゴリズム、プロトコルを選択

– 可用性/信頼性の要求、スループット、応答時間、再構成可能とリカバリーの完了期間、一貫性の調整、リソースの消費量（ネットワーク帯域、ディスク帯域、ディスクI/O 回数など）= コスト

– 多様なアルゴリズム、プロトコルから選択、システム化

– テストなど、エンジニアリング的な解決が難しい

– 形式手法化： correctness criteria(C) 2012 Microsoft Corporation 7

分散システムの適用

• 複製への適用

– Group safety

• OLTP への適用

– 2PC に代わる atomic broadcast + ローカルトランザクション

– Paxos コミット

– Serializability の拡張

• スケジューリングやリソース管理

– HadoopDB


CAP 定理 Revisited

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

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

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

• 制約：

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

– Latency の考慮がない

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

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


CAP の2特性を選択


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 定理


可用性を支える複製

データベースの安全性基準


安全性の基準配送されるサーバ数

コミットされたサーバ数

説明

無処理ゼロゼロ0-safety 1 ゼロトランザクションは1つのサーバに配送され、実行され

たがまだコミットはされない。ストレージにトランザクションの結果が永続化される前にクラッシュすると、トランザクションは失われる

1-safety 1 1 トランザクションは1つのサーバに配送され、コミットされた。そのトランザクションが他のサーバに送信される前にクラッシュするとトランザクションは失われる可能性がある。他のサーバは先のトランザクションの存在を知らないので、そのトランザクションと衝突する新たな別トランザクションを受け付けられる場合にトランザクションは失われる

Group-safety すべてゼロトランザクションはすべてのサーバに配送されるがまだコミットはしていない。f（0<f<すべて）個以上のサーバがクラッシュすると、トランザクションは失われる

Group-safetyかつ1-safety（group-1-safety）

すべて 1 トランザクションはすべてのサーバに配送され、1つのサーバでコミットされた。f個のサーバかつトランザクションをコミットした1つのサーバがクラッシュすると、トランザクションは失われる可能性がある。データベースとグループ通信機構を組み合わせたレプリケーションの大部分はここに属する

2-safety すべてすべてトランザクションはすべてのサーバに配送され、コミットされた。トランザクションが失われることはない

現状の複製技術

• Primary-backup

• Update-anywhere

• Master-slave から cohort単位の複製へ


Node Ekey ranges[800,999][600,799][400,599]

Node Akey ranges

[0,199][800,999][600,799]

Node Bkey ranges[200,399][0,199]

[800,999]

Node Ckey ranges[400,599][200,399][0,199]

Node Dkey ranges[600,799][400,599][200,399]

Zookeeper

Primary-Backup プロトコルAlsberg-Day Protocol


全順序化• P-B の順序化の例

– viewstamped replication

• 順序化しないと合意が必要な例

– 楽観的レプリケーション


出典： Optimistic Replication (Shapiro, Saito)

ROWA (Read One Write All)


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

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

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

W+R>N quorum assembly による強い一貫性。読み取りには少なくとも1つの最新データの複製を含む

Client

ReplicaManger

ReplicaManger

FrontEnd

Client

ReplicaManger

FrontEnd

ReplicaManger

ReplicaManger

ReplicaManger

ReplicaManger

ReplicaManger

Read quorum

Write quorum

Quorum (定足数)

• Quorum consensus

• CC とは独立、回復プロトコル不要

• ROWA との比較

• P-B と ROWA の中間の特徴

• これからの位置づけ

– Byzantine 障害

– 負荷分散

– 契約の一種


• Read quorum(RQ) と Write quorum(WQ) の規則• |RQ|+|WQ|>N （Read と Write set は重なる）• |WQ|>N/2 （２つの Write set は重なる）

データ配置

• Rack aware

– HDFS, MapR

• Geo replication

– DHT

• いろいろな一貫性モデルがありえる

– ビジネスにどれが適切か？


出典： Geo-Replication in Large-Scale Cloud Computing Applications

Replicated State Machine

• 状態マシン

– 状態マシンを壊す要因

• Paxos

– Leader と primary の違い

– Learner は合意結果を知らない

– 複数の leader の実行と競合

– 1 leader による複数要求の同時実行

– Batching と Pipeline


Basic Paxos (1)


複製（状態マシン）

ReadフェーズWriteフェーズ

複製への反映

提案番号（バロット ID）

過半数

Basic Paxos (2)


複製は合意結果を知らない

障害が疑われると複数の Leader を立てられる（弱い障害検知）

提案番号を大きくする

Basic Paxos (3)


複数 Leader間の競合

Paxos の過半数

• propose/accept間の調整

• 提案番号の全順序化

• Ballot 間の合意の引き継ぎ


リーダー Apropose/accept

リーダー Bpropose/accept

Ballot n-1accept

Ballot npropose

Ballot n-1accept

Ballot naccept

時間推移

時間推移

replica の過半数

• Replica 一貫性モデル

– Spinnaker の例


Replica へのwrite

Replica へのread

Leader FollowersClient

Write

Ack XWrite X to WAL & Commit Queue Send Ack to Master Don’t apply to Memtables yet

Update Commit QueueApply X to MembtablesSend Ack to Client

Acquire LSN = XPropose X to FollowersWrite log record to WAL & Commit Queue

Asynchronous Commit Message for LSN = Y (Y>=X)

Process everything in the Commit Queue until Y and apply to Memtables.

Client can read the latest value at the LeaderX is not in the Memtable yet.Reads at Followers see an older value now

Tim

e

Reads now see every update up to LSN = Y

Paxos と ZooKeeper

• P-B と RSM の違い

• Primary order の問題

– メッセージ単位のトランザクションスコープ


メッセージの安定化

出典： Zab: High-performance broadcast for primary-backup systems

A/E 分離

• Byzantine 障害対応の複製数の削減

• privacy


出典： ZZ and the Art of Practical BFT Execution

Paxos コミット• TM が Paxos を使い RM の合意を取る

• 2F+1 個のアクセプター (~2F+1 個の TMs)

• 各 RM は prepare 要求に応答

• If F+1 個のアクセプターがすべての RMs が prepared 状態になったと確認するとトランザクションをコミット

• 2F(N+1) + 3N + 1 回のメッセージ

• 5 回のメッセージ遅延（1回余計の遅延）

2回の永続化

• F=0 なら 2PC と同じ


RM0CommitLeader RM0…N

Acceptors0…2F

Vertical Paxos


耐障害性、可用性、スケーラビリティ遅延、運用コストなどを基準に選択

分散システムプロセスメンバー

Paxos グループ Paxos グループ

構成要素2構成要素1

スケーラビリティOLTP プロトコルの発展

動的プロセスグループ


ビューの同期（１）


ビューの同期（２）


ビューの同期（３）


2PC に代わる atomic broadcast


read/write 毎

トランザクション毎

2PC に代わり分散システムのメッセージング受信と配送の分離ACID の一貫性と永続化が同時に実行される

トランザクションクライアント

リソースマネージャ(ROWA)

トランザクションデータ操作

commit/abort

ローカルトランザクションの serializability

Read-onlyトランザクションのアボート

• トランザクション送信中のクラッシュ– トランザクション送信中のビュー変更

• トランザクション受信中のクラッシュ

• 復旧中のクラッシュ


障害時の動作 (1) ROWA


commitV{Si} → V’{^Si}→ V’’{Si}

Si


commitV{Si} → V’{^Si}→ V’’{Si}

Si

View 変更あり

Si

①

②④

③

①

②

③

①

②③

障害時の動作 (2) P-B


出典： Dynamic Reconfiguration of Primary/Backup Clusters

運用中の構成変更古いビューの操作の片づけ

設計論


次世代アーキテクチャー

AP (BASE), Stateless,

Elastic

C,非同期

CA

• Soft State

– Weak Consistency Model

– Timeline consistency

– Read-your-Writesconsistency

– Eventual consistency

• NoSQL

CAP 定理の制約を超える


許容されない許容

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

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

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

• レイヤリング

– CP (Quorum) を AP (期限付きキャッシュ) に載せる

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

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

– Weak consistency

混沌と秩序


A A AC C C

BASE BASE BASEACID ACID ACID

Superstep Superstep SuperstepSync Sync Sync

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

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

最適化の方法

• スケーラブルアーキテクチャーの原則

• MapReduce の最適化

– Data Intensive Scalable Computing アーキテクチャースタイルの一例


スケーラブルアーキテクチャーの原則


データ分割による競合防止分類→分割→配置→集約ホットスポットの回避データ偏在の解決

メモリ上の効率利用index データ構造アクセス遅延永続化

転送効率化Co-location、転送プロトコル簡易検査、圧縮などデータ量の削減

並列可能箇所の並列実行時間順序保証の上

負荷分散非同期による時間差

MapReduce の物理最適化

• ジョブ段数を減らし shuffle 数を削減

• 前段に寄せることでデータ転送量を減らす

– push-down： join－select－projection を select－join－projection とする

• sum(2,3,1) = sum(sum(2,3),1)

• avg(2,3,1) != avg(avg(2,3),1)

• インクリメンタルな計算に置き換え

– semi-join(⋉) , bloom filter で転送量を減らす

– Combiner

• データ偏在の解決、分割法

• データ構造の最適化（カラム指向 DB など）

• コード/データの共有、キャッシュ

• 動的最適化


Row Group 1

c1 c2 c3 c4

11 12 13 14

21 22 23 24

31 32 33 34

並列の比較

• 分散並列 MapReduce vs. ローカル並列カラム指向

– Tuple のキー特性


c1 c2 c3 c4

11 12 13 14

21 22 23 24

31 32 33 34

41 42 43 44

51 52 53 54 Row Group 2

c1 c2 c3 c4

41 42 43 44

51 52 53 54

http://www.datasalt.es/wp-content/uploads/2012/02/aclaracion.png

抽象データ(型)の応用

• ZooKeeper の znode による分散合意

• Hive によるデータ分析

– RCFile（カラム指向）と SQL 類似のプログラミングモデル

• Apache Spark による各種並列計算（データフロー、BSP など）

– RDD (Resilient Distributed Dataset) と Scala のプログラミングモデル

• CRDT (Commutative Replicated Data Type)による共有データのスケーラビリティ、分散データの eventual consistency、グループウェア

– CRDT と各種プログラム言語


まとめ

• Big Data の次の基盤の重要な要素技術は何か？– CAP 定理

– 分散システム

– トランザクション、DB

– プログラミング言語やツール（抽象化、最適化、設計ガイド）

– H/W （SSD、ネットワーク）

– 特許、IP

– 皆さんの挑戦、知恵と協力


Technology

クラウドを支える基盤技術の最新動向と今後の方向性