Hadoop の次に考える     分散システム技術日本マイクロソフト株式会社萩原 正義@masayh
次の課題とは• Hadoop、NoSQL を使った大規模データ分析  – Hadoop のパフォーマンスチューニング、キャパシティプ    ランニング  – MapReduce アルゴリズム  – NoSQL の選択、ZooKeeper の利用...
目的• クラウドの分散システムの基礎 – CAP 定理の制約をどのように克服しているか – 可用性技術がどのように保証されているか – Hadoop の次の基盤の重要な要素技術は何か       •   分散ストレージ/ファイルシステム    ...
CAP 定理 Revisited• Consistency: すべてのクライアントは変更があっても同一の  ビューを見る• Availability: すべてのクライアントは障害が発生しても、データ  のいくつかの複製を発見することができる• ...
CAP の2特性を選択C       A    •   Consistency + Availability                  • 単一サイト / クラスタデータベース    P             • 通常の RDB など...
可用性 vs. 一貫性      CAP 定理   (C) 2013 Microsoft Corporation   6
Lease        CAP 定理の AP の基本技術                                        クライアント(キャッシュ、複製)                                     ...
クォーラムシステム         CAP 定理の CP の基本技術W=N R=1    読み取りに最適化した強い一貫性 (ROWA)W=1 R=N    書き込みに最適化した強い一貫性W+R<=N     eventual consisten...
多数決の原理           primary-backup の場合                                                            現在の primary• 現在の primary  –...
CAP 定理の制約を超える• レイヤリング – CP (クォーラム) を AP (期限付きキャッシュ) に載せる• トランザクションの時間分割から一貫性モデルの時間  調整 (CA の 2PC の制約) – メッセージ安定化のフェーズ – We...
CAP 定理を克服する                                    スキーマ定義                                    CP                               ...
次世代アーキテクチャー                                                •   Soft State                                                 ...
混沌と秩序A         C          A                 C          A         CBASE     ACID       BASE              ACID        BASE  ...
まとめ• リアルタイム、アドホック、双方向性、スケールする更新• スケーラビリティは可用性、耐障害性(リシリエント)の前  提で考える – 制御可能性の前提: ビジネス指向で – 障害モデルの前提: SPOF の想定 – 各種のトレードオフに対...
参考文献「分散システム ~ アーキテクチャーと概念」(仮称) –   CAP 定理 –   合意問題 –   アトミックブロードキャスト –   ZooKeeper –   クォーラムシステム –   複製でのトランザクション(OLTP とメッ...
Upcoming SlideShare
Loading in...5
×

Hadoop

2,713

Published on

Hadoop

  1. 1. Hadoop の次に考える 分散システム技術日本マイクロソフト株式会社萩原 正義@masayh
  2. 2. 次の課題とは• Hadoop、NoSQL を使った大規模データ分析 – Hadoop のパフォーマンスチューニング、キャパシティプ ランニング – MapReduce アルゴリズム – NoSQL の選択、ZooKeeper の利用• OLTP アプリケーション – OLTP は 2PC で連携 – 一貫性保証は ACID か BASE(eventual consistency?) – 耐障害性は永続化• 可用性と一貫性のトレードオフ – レイテンシー、スケーラビリティとのトレードオフは?• Elastic や 障害による再構成 (C) 2013 Microsoft Corporation 2
  3. 3. 目的• クラウドの分散システムの基礎 – CAP 定理の制約をどのように克服しているか – 可用性技術がどのように保証されているか – Hadoop の次の基盤の重要な要素技術は何か • 分散ストレージ/ファイルシステム • トランザクショナルアプリケーション • トランザクション連携 • 高信頼グループコミュニケーション (C) 2013 Microsoft Corporation 3
  4. 4. CAP 定理 Revisited• Consistency: すべてのクライアントは変更があっても同一の ビューを見る• Availability: すべてのクライアントは障害が発生しても、データ のいくつかの複製を発見することができる• Partition-tolerance: (分散)システムはネットワークが切断さ れても、その特性を維持する• 制約: – Partition-tolerance に着目しているサービス提供者向け – レイテンシーの考慮がない – 障害モードでの補償処理をどう考えるか – 必要に応じて ACID、合意プロトコルにより一貫性を取る考え方へ (C) 2013 Microsoft Corporation 4
  5. 5. CAP の2特性を選択C A • Consistency + Availability • 単一サイト / クラスタデータベース P • 通常の RDB など • Consistency + Partition-toleranceC A • 分散データベース / 分散ロック P • HBase、Paxos • Availability + Partition-toleranceC A • 分散キャッシュ / DNS P • Cassandra, eventual consistency (C) 2013 Microsoft Corporation 5
  6. 6. 可用性 vs. 一貫性 CAP 定理 (C) 2013 Microsoft Corporation 6
  7. 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. 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. 9. 多数決の原理 primary-backup の場合 現在の primary• 現在の primary – コミット済みの更新の永 続化と一貫性 Backup 過半数 – primary のサブネッ トの可用性 Backup Primary Backup• 新しい primary(新し いビュー) Backup – primary の選出: 新し いビューのサブネットの 可用性 新しい primary – 新しいビューでのコミッ ト済みの更新の引き継ぎ (C) 2013 Microsoft Corporation 9
  10. 10. CAP 定理の制約を超える• レイヤリング – CP (クォーラム) を AP (期限付きキャッシュ) に載せる• トランザクションの時間分割から一貫性モデルの時間 調整 (CA の 2PC の制約) – メッセージ安定化のフェーズ – Weak consistency 多数のプロセスですべてのプロセスが更新結果をみなくてもいい状況 異なるプロセスでまだ同期化が実行され ていないので観測結果が異なってよい 同期化しているので P2は最新の x の b が見えないといけない 許容 許容されない (C) 2013 Microsoft Corporation 10
  11. 11. CAP 定理を克服する スキーマ定義 CP AP ネットワーク 非同期特性 (C) 2013 Microsoft Corporation 11
  12. 12. 次世代アーキテクチャー • Soft State – Weak Consistency Model – Timeline consistency – Read-your-Writes consistency – Eventual consistency • NoSQL C,AP (BASE), 非同期 Stateless, ElasticCA (C) 2013 Microsoft Corporation 12
  13. 13. 混沌と秩序A C A C A CBASE ACID BASE ACID BASE ACIDSuperstep Sync Superstep Sync Superstep Sync非同期 同期 非同期 同期 非同期 同期混沌 秩序 混沌 秩序 混沌 秩序 (C) 2013 Microsoft Corporation 13
  14. 14. まとめ• リアルタイム、アドホック、双方向性、スケールする更新• スケーラビリティは可用性、耐障害性(リシリエント)の前 提で考える – 制御可能性の前提: ビジネス指向で – 障害モデルの前提: SPOF の想定 – 各種のトレードオフに対する方針と意思決定: • 一貫性と可用性 • 一貫性とレイテンシー • スケーラビリティ、スループット、レイテンシー – 種々の要求: NoSQL、レプリケーション方式、コンピューティ ングスタイル• サイエンスとエンジニアリング – 分散システム、データベース技術、ソフトウェア工学… (C) 2013 Microsoft Corporation 14
  15. 15. 参考文献「分散システム ~ アーキテクチャーと概念」(仮称) – CAP 定理 – 合意問題 – アトミックブロードキャスト – ZooKeeper – クォーラムシステム – 複製でのトランザクション(OLTP とメッセージングの融合) – Snapshot isolation による複製の問題 RM0 Commit Acceptors Leader 0…2F RM0…N – レプリケーションシステムの実装法 – Paxos – Byzantine 障害対応合意プロトコル – 複製を隠ぺいする仮想リソース管理 – レプリケーションの安全性評価方法 – システム設計の原則 (C) 2013 Microsoft Corporation 15
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×