第1回分散システム本読書会の発表資料

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 et al., 2003]
• succ(k)は最小のノード
id≧k
• LOOKUP(k)でsucc(k)を
返す
• メンバシップ管理
– 前後のノードに知らせ
る
2013/1/25 分散システム本読書会 19

20. CAN [Ratnasamy et al., 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