Downloaded 35 times
![Chord [Stoica et al., 2003]
• succ(k)は最小のノード
id≧k
• LOOKUP(k)でsucc(k)を
返す
• メンバシップ管理
– 前後のノードに知らせ
る
2013/1/25 分散システム本読書会 19](https://image.slidesharecdn.com/2-130127175239-phpapp01/75/2-19-2048.jpg)
![CAN [Ratnasamy et al., 2001]
• 空間としてN次元トーラスを使用
2013/1/25 分散システム本読書会 20](https://image.slidesharecdn.com/2-130127175239-phpapp01/75/2-20-2048.jpg)
More Related Content
第2章アーキテクチャ
- 1. 第2章 アーキテクチャ 分散システム本読書会 2013年1月25日（金）
- 2. はじめに • ソフトウェアアーキテクチャ – 論理的な構成 – どのようにソフトウェアコンポーネントを構成す るか – どのように相互作用すべきか • システムアーキテクチャ – 物理的な実現 – 実際にどのように実現するか – 実際のマシン上へのSWコンポーネントの配置 • 自律システム – フィードバック制御ループ 2013/1/25 分散システム本読書会 2
- 3. 2.1 アーキテクチャスタイル • アーキテクチャスタイルはコンポーネントの観点から定式化される – コンポーネント間の接続方法 – コンポーネント間で交換されるデータ – これらの要素がどのように共同して１つのシステムを構成するか • コンポーネント – 明確に定義されたインタフェースを持つ交換可能なソフトウェア（構 成単位） • コネクタ – コンポーネント間の通信、調整、協力を伝えるメカニズム – 遠隔手続き呼出し（RPC）、メッセージパッシング、ストリーミング データ • 分散システムにおいて重要なアーキテクチャスタイル – 階層型アーキテクチャ – オブジェクトベースアーキテクチャ – データ中心型アーキテクチャ – イベントベースアーキテクチャ 2013/1/25 分散システム本読書会 3
- 4. 階層型アーキテクチャ • コンポーネントは階層 N層 的に構成される • Li層のコンポーネントが N-1層 下位のLi-1層のコンポー ネントを呼び出すこと 要求フロー↓ ↑応答フロー ができる • 反対は許されない 2層 • ネットワークのコン ポーネントで広く採用 1層 されている • 要求は階層を下方に、 結果は上方に流れる分散システム本読書会 2013/1/25 4
- 5. オブジェクトベースアーキテク チャ • 階層型より緩やかな オブジェク オブジェク 構成 ト ト • 各オブジェクトはコ ンポーネントに対応 オブジェク メソッド ト 呼出し • 各コンポーネントは オブジェク （遠隔）オブジェク ト ト呼出しを通じて接 オブジェク 続される ト 2013/1/25 分散システム本読書会 5
- 6. データ中心型アーキテクチャ • プロセスが共有リポジトリを通して通信 する • 多くのネットワークアプリケーションは、 共有分散ファイルシステムのファイルを 利用して通信を行う • Webベースのアプリケーションは、Web ベースの共有データサービスを利用する 2013/1/25 分散システム本読書会 6
- 7. イベントベースアーキテクチャ • プロセスはイベントの コンポーネン コンポーネン 伝播を通して通信 ト ト • 出版・購読システム イベント配送 – プロセスがイベントを出 版 イベントバス – ミドルウェアは、それら 出版 イベントを購読したプロ コンポーネン セスだけが受信すること ト を保証 • プロセスが疎結合にな るという利点がある – 互いに明示的に参照する 2013/1/25 必要が無い 分散システム本読書会 7
- 8. 共有データ空間 • イベントベースアー コンポーネン コンポーネン ト ト キテクチャ＋データ 中心型アーキテク データ配送 出版 チャ • プロセスは時間的に 共有（永続）データ空 も分離される 間 – 通信中にアクティブで なくてもよい 2013/1/25 分散システム本読書会 8
- 9. 2.2 システムアーキテクチャ • コンポーネントの相互作用と配置の方法 •集中型アーキテクチャ • 非集中型アーキテクチャ • ハイブリッドアーキテクチャ 2013/1/25 分散システム本読書会 9
- 10. 2.2.1 集中型アーキテクチャ • サーバ： – ファイルサービスやデータベースサービスのよう に特定のサービスを実装しているプロセス • クライアント： – サーバに要求を送信することでサーバからのサー ビスを要求し，サーバの応答を待つプロセス 結果を待つ クライアント 要求応答 動作 要求 応答 サーバ サービス提供 時間 2013/1/25 分散システム本読書会 10
- 11. クライアントーサーバ間の通信 • コネクションレス型プロトコル（例：UDP） –利点：LANなど高信頼な環境では効率的である – 欠点：伝送障害に耐えうるプロトコルを作るのが困 難 • 返答メッセージが来ない場合，クライアントに要求を再送信 させる • ただし，要求メッセージと応答メッセージのどちらが失われ たのかクライアント側では判別できないので繰り返し等価 （idempotent）でない要求には対応できない • 高信頼コネクション型プロトコル（例：TCP） – 利点：通信の信頼性があまり高くない広域システム では良く動作する – 欠点：要求と応答メッセージが小さい場合はコネク 2013/1/25 ションの接続・切断のコストがかかる 分散システム本読書会 11
- 12. アプリケーションの階層化 • 多くの人々は以下の3つの論理レベルに区 別することを提唱 1. ユーザインタフェース層 • ユーザとの対話を取り扱う部分 2. プロセッシング層 • アプリケーションの中核機能を含む真ん中の部分 3. データ層 • データベースやファイルシステム上で動作する部 分 • 永続性を持つ 2013/1/25 分散システム本読書会 12
- 13. インターネット検索エンジンの 例 ユーザインタフェー ユーザインタ ス フェースレベル キーワード表現 リストを含むHTML HTML生成器 ランキングされた クエリ生成器 プロセスレベル ページタイトルの ランキング リスト アルゴリズム データベースクエリ メタ情報を持つ Webページを持つ Webページのタイトル データレベル データベース 2013/1/25 分散システム本読書会 13
- 14. 2層アーキテクチャ 3層レイヤをクライアントとサーバに分ける シンクライアント ファットライアント ユーザ ユーザ ユーザ ユーザ ユーザ インタフェー インタフェー インタフェー インタフェー インタフェー ス ス ス ス ス アプリケー アプリケー アプリケー ション ション ション サーバマシン ス インタフェー データベース ユーザ クライアントマシン アプリケー アプリケー ション ション ション アプリケー データベース データベース データベース データベース データベース (a) (b) (c) (d) (e) 2013/1/25 分散システム本読書会 14
- 15. 多層アーキテクチャ • 3層アーキテクチャの例 ユーザインタフェース Webクライアント アプリケーション アプリケーションサーバ データベース データベースサーバ 2013/1/25 分散システム本読書会 15
- 16. 3層アーキテクチャ • １つのサーバが複数のサーバに置き換えら れ，異なるマシン上で実行される • サーバがときにはクライアントとしての役割 を果たす 結果待ち ユーザ インタフェース 処理要求 応答結果 データ待ち アプリケーション サーバ データ要求 応答データ データベース サーバ サービス提供 時間 2013/1/25 分散システム本読書会 16
- 17. 2.2.2 非集中型アーキテクチャ • 垂直分散 – 機能単位を複数マシンで分散 • 水平分散 – 同一機能を複数マシンで分散 – 複数マシンで負荷を分散 – Cf. P2P（ピアツーピア）システム • P2Pシステム – P2Pを構成するプロセスはすべて同じ – プロセス間の相互作用は対称的 • クライアントでもありサーバでもある（サーバント、servent） – オーバーレイネットワーク • プロセス間のネットワーク • ルーティングしてプロセス間でメッセージ通信 2013/1/25 分散システム本読書会 17
- 18. 構造化P2Pアーキテクチャ • オーバレイネットワークを決定的手続きで構成 • 分散ハッシュテーブル – ハッシュキーは128ビット、または、160ビットなど の広いID空間 – 複数ノードでハッシュテーブルを分割 • ノードのハッシュ値によりID空間を分割 – ある距離メトリックにもとづいてデータアイテムの キーをノード識別子にマップするスキームを実装 • データをLOOKUPするとき、そのデータが割り当て られているノードを返す – データが割り当てられているノードにルーティング する 2013/1/25 分散システム本読書会 18
- 19. Chord [Stoica etal., 2003] • succ(k)は最小のノード id≧k • LOOKUP(k)でsucc(k)を 返す • メンバシップ管理 – 前後のノードに知らせ る 2013/1/25 分散システム本読書会 19
- 20. CAN [Ratnasamy etal., 2001] • 空間としてN次元トーラスを使用 2013/1/25 分散システム本読書会 20
- 21. 非構造化P2Pアーキテクチャ • ランダムグラフに似たオーバレイネット ワークを構築することがもくひょう • 各ノードは近隣ノードのリストを保持す る – リストはランダムに構築される – 近隣ノードはライブノードを表す – 近隣ノードのリストは部分ビューとも呼ばれ る • データもノード上にランダムに配置 – 特定のデータの位置を特定するために検索ク 2013/1/25 エリをフラッディング（ブロードキャスト） 21 分散システム本読書会
- 22. オーバレイネットワークのトポロ ジ管理 • 部分ビューから注意深くエントリを選択し、 交換することで、特定のオーバレイネット ワークのトポロジを構築しを維持することが 可能 2013/1/25 分散システム本読書会 22
- 23. 2階層非構造化P2Pシステムによる 特定のオーバレイネットワークの 生成 • サイズN×Nの論理的なグリッドを考える • 各ノードはc個の最寄りの近隣リストを維持する – 2つのノード(a1, a2), (b1, b2)の距離はｄ１＋ｄ２と定義 – ただし、di = min(N-|ai-bi|, |ai-bi|) 2013/1/25 分散システム本読書会 23
- 24. スーパーピア • 非構造化P2Pでは，探索要求がフラッディングなので，ネット ワークが拡大すると問題が生じる • CDN（コンテンツ配送ネットワーク）等の応用ではコンテン ツを高速に発見したいという要求がある • インデックスを維持し たりブローカとして動作 するスーパーピアと呼ば れるノードを導入 2013/1/25 分散システム本読書会 24
- 25. 2.2.3 ハイブリッドアーキテク チャ • エッジサーバシステム – サーバがネットワークのエッジに置かれる 2013/1/25 分散システム本読書会 25
- 26. 協力的(collaborative)分散システム • BitTorrentの例： – 協力的なP2Pファイルダウンロード • ファイルのダウンロードは，コンテンツを提供するノードだけが可能 – .torrentファイルはトラッカ（tracker）を示す。トラッカはファイルの チャンクを保有するアクティブなノードを保持 – アクティブノードは現在ほかのファイルをダウンロードしているノー ド • 分かりやすい説明はここ：http://jp.bitcomet.com/doc/principles.htm 2013/1/25 分散システム本読書会 26
- 27. 2.3 アーキテクチャ vsミドル ウェア • 実際のミドルウェアは特定のアーキテクチャに 従っている – オブジェクト指向アーキテクチャ：CORBAなど – イベントベースアーキテクチャ：TIB/Rendevous • アプリケーションの設計が簡単になるという利点 • しかし、アプリ開発者が想い描いていたものに対 して、そのミドルウェアが最適でなくなるという 欠点 • ミドルウェアは特定のアプリケーション要件に適 応しやすくするべき – 複数バージョンのミドルを作る – より良い方法は、カスタマイズ容易にすること 2013/1/25 分散システム本読書会 27
- 28. 2.3.1 インタセプタ • 通常の制御フローを中断 し、他の（アプリ固有） コードを実行するもの • 遠隔オブジェクト呼び出 しの例⇒ – オブジェクトBが複製され ている場合でも、要求レ ベルインタセプタがそれ ぞれにinvokeを呼び出すこ とで、アプリ側は気にし なくて済む – パラメータが巨大な配列 データの場合でもメッ セージレベルインタセプ タが分割してsendすれば 良い 2013/1/25 分散システム本読書会 28
- 29. 2.3.2 適応型ソフトウェアへの一般 的なアプローチ • ３つの基本的なアプローチ – 関心の分離 • 信頼性、パフォーマンス、セキュリティといった機能 外の部分を機能を実装したパーツから切り離す • アスペクト指向ソフトウェア開発 – 自己反映計算（リフレクション） • 自分自身を調べ、必要に応じてその動作を適応させる プログラムの能力 – コンポーネントベース設計 • 合成によって適応をサポートする • システムは静的（設計時）、あるいは動的（実行時） に設定される 2013/1/25 分散システム本読書会 29
- 30. 2.3.3 議論 • 分散システムのためのソフトウェアアーキテクチャは大きくて複雑 – 分散透過性を提供する必要性からくる – 同時にアプリケーションは分散透過性と相反するような非機能要件を 持つ – 一般化と特殊化の相反する要求が、結果として高い柔軟性を持つミド ルウェアをもたらす • もっと単純なやり方に焦点をあてるべきではないか？ • 環境の変化に応じて、適応するようなソフトウェアはどこまで必要 なのだろうか？ – 適応的ソフトウェアを支持する強力な根拠は、多くの分散システムは シャットダウンできないということ • 残る課題は、例えば、リソース割り当てポリシーの切替などによっ て、環境の変化に対応できるかどうか – 設定を変える動作を指示するアルゴリズムが各コンポーネントに含ま れる – 人間の介在なしに可能か？ 2013/1/25 分散システム本読書会 30
- 31. 2.4 分散システムにおける自己管理 • 自律コンピューティング – 自動的に変化に適応できる高レベルのフィー ドバック制御システムとしての分散システム を構成すること – 自己管理、自己治癒、自己設定、自己最適化 など 2013/1/25 分散システム本読書会 31
- 32. 2.4.1 フィードバック制御モデル • 論理的構成： 2013/1/25 分散システム本読書会 32
- 33. 2.4.2 例：Astrolabeによるシステム モニタリング • 非常に大規模な分散システムの汎用的なモニタリング をサポートする – システムの動作を観測する一般的なツールとして位置づけ られる ・全てのホストはエージェントを実行 ・エージェントはそのホストが含ま れるゾーンで情報を収集 ・ゾーン情報は全てのノードに 伝播する 2013/1/25 分散システム本読書会 33
- 34. 2.4.3 例：Globuleにおける複製戦略 の差別化 • 協調コンテンツ配信ネットワーク – インターネット上に配置されたエンドユーザーサーバが協調し て、パフォーマンスを最適化するようにWebページの複製を配 置する – オリジンサーバは十分な要求が集まるとWhat-If分析を行う • 複製ポリシーのコストを評価し、最善のものを実施する 2013/1/25 分散システム本読書会 34
- 35. 予測精度とトレースの長さの依存 関係 • ポリシーを評価する前に、どれくらい要求を 収集する必要があるか 2013/1/25 分散システム本読書会 35
- 36. 2.4.4 例：Jadeにおける自動コン ポーネント修復管理 • 修復管理ドメイン – 多くのノードから構成される • 各ノードは複数のコンポーネントを伴うサーバに相当する – ドメインにノードを追加したり切り離したりする責任を持つ ノードマネージャが別に存在する – 各ノードは故障検出器を備えていて、不具合が見つかるとノー ドマネージャに報告する • 修復手順の例： – 障害のないノードと障害の発生したノードのコンポーネント間 でのバインドを終了する – ノードマネージャはドメインに新規ノードを起動して追加する ように要求する – クラッシュしたノードと同じコンポーネントを持つ新規ノード を構成する – さきに終了した全てのバインドを再確立する 2013/1/25 分散システム本読書会 36
- 37. 2.5 まとめ • ソフトウェアアーキテクチャ＝ソフトウェアの論理的な構成 •システムアーキテクチャ＝コンポーネントがどのように異なるマシ ンに配置されるか • アーキテクチャのスタイル – レイヤ、オブジェクト指向、イベント指向、データスペース指向アー キテクチャ • クライアント－サーバモデル – 集中アーキテクチャとなりやすい • P2Pシステム – プロセスは等しく振る舞う – オーバレイネットワーク＝ほかのピアの局所リストを持つ論理的な ネットワーク – 構造化P2Pと非構造化P2P • 自己管理分散システム – 一般的にフィードバック制御ループで構成 2013/1/25 分散システム本読書会 37