分散システムにおけるプロセス - 東野研究室nakata/mobile-cp/chap-03j.pdf2...

1

分散システムにおけるプロセス

3章

2

分散システムにおけるプロセス

通信：プロセスの間で行われる

プロセス(Process)：実行中のプログラム

分散システムからの観点：

マルチスレッド技術

効率の良いクライアント・サーバシステムの構築に有用

クライアント・サーバのさまざまな構成法

クライアント・サーバそれぞれにおける典型的な構成法

プロセスを異なるマシン間で移動させる技術（Process Migration）スケーラビリティの達成やクライアント／サーバの動的構成に有用

ソフトウェアエージェント（Software Agents）マルチエージェントシステム(Multiagent system)

対称な複数のエージェント(Agent)で構成し、クライアント・サーバシステムと同じ目標の達成を目指す

3

スレッド

分散システムの構成要素

一般的にはプロセス(Process)OSから提供されるプロセスの粒度では不十分

プロセスより細かい単位の構成要素=スレッド(Thread)の利用

性能の良い分散アプリケーションの構築が容易に

4

マルチスレッドクライアント

クライアントのマルチスレッド化

分散透過性の達成のため、通信遅延を隠蔽する必要

一つの方法：通信待ちの間、他の処理を別スレッドにて実行

webブラウザの例複数のTCPコネクションを同時に張り、文書の複数パート（画像など）を同時に受信

サーバが負荷分散のために複数のレプリカで構成されている場合、複数のコネクションはそれぞれ異なるサーバに繋がる(ことが多い)ので，性能が向上

5

マルチスレッドサーバ(1/3)

サーバのマルチスレッド化

ファイルサーバの例構成

ディスパッチャ: リクエストを受け付け、ワーカスレッドに渡すスレッド

ワーカスレッド: リクエストの処理を行うスレッド

ワーカスレッドが入出力待ち状態になっても、他のスレッドは動作を継続可能

6


マルチスレッドを使わないサーバ構築アプローチ有限状態機械(Finite-state machine,FSM)モデルの

利用サーバを一つの大きなFSMとして構成

ファイルサーバの場合リクエストを受理し、非同期のファイルアクセス要求を行い、現在の状態をテーブルに記憶して、次のリクエストの受理処理に移る

待ち状態にならない(non-blocking)send,receiveシステムコールの利用

並列処理の状態を一つのテーブルに記憶することにより、一つのFSM (積オートマトン)でシミュレート

7


マルチスレッドの利用により、待ち状態になる（blocking）システムコールを利用しても、システムの並列度を上げることが可能

blockingシステムコールを利用する方がプログラミングが容易

8

分散システムのためのクライアント構成法

サーバクライアントモデルにおけるクライアント主な役割：ユーザインタフェース

X Window Systemの例

構成

Xカーネル：ディスプレイへの表示、キーボード・マウス操作、異なるアプリケーション間のカット＆ペースト処理などのユーザインタフェースを提供

Xアプリケーション： Xカーネルを用いるアプリケーション

XカーネルとXアプリケーションは異なるマシンで動作していても良い

Xプロトコルによって通信

9

分散システムの透過性実現のためのクライアント構成法(1/3)

クライアントはユーザインタフェース以上の役割を果たすことが可能

処理レベル、データレベル（1章参照）をクライアント側に置くことが可能

各種透過性実現のためのクライアント構成法アクセス透過性

クライアントスタブによって実現

位置・移動・再配置透過性名前付け(naming)システム（詳細は4章）の利用が重要だが、クライアント側ソフトウェアも重要

サーバの移動をクライアントに通知　クライアント側のミドルウェアでサーバの移動をユーザから隠蔽

10


複製透過性：サーバスタブ(スケルトン)の替わりにクライアントスタブ(プロキシ)が複数のレプリカにリクエストを送信し、返り値の一つをクライアントアプリケーションに返すことにより達成

11


障害透過性：

通信障害の隠蔽はクライアント側ミドルウェアで達成可能

接続を何回も試みたり、替わりに別のサーバに接続を試みるなどし、もし失敗すればクライアント側で前回キャッシュしておいた値を返すことで、障害を隠蔽

並行透過性、永続透過性など：ほとんどサーバ側で行われるため、クライアント側の役割は小さい

12

分散システムのためのサーバ構築法(1/4)

一般的なサーバ設計法

サーバ構成法イテラティブサーバ(iterative server)

サーバ自身がリクエストを処理し、必要なら返答をクライアントに返すことを繰り返す

並行サーバ(concurrent server)サーバ自身はリクエストの受付のみ行い、リクエストの処理は別のスレッドまたはプロセスに任せて、次のリクエストの待ち状態に入る

前述のマルチスレッドサーバは並行の一例

UNIXシステムでの一般的なアプローチ --- プロセスをforkして新しいプロセスを生成し，リクエストの実際の処理を任せる

13


サーバに状態を持たせるか否かの問題状態不保持サーバ(stateless server)

接続中のクライアントの状態を保持しない

サーバ側の状態変化をクライアントに通知しない

例）　Webサーバ

クライアントのリクエストに対してただ応答するのみ（応答が終了するとクライアントのことは全て忘れる）

クライアントが前回どんなリクエストを行ったかなどの情報はサーバ側は記憶しない

サーバのコンテンツが変化してもクライアントには通知しない

14


状態保持サーバ(stateful server)状態不保持サーバの逆

例）(ある種の)ファイルサーバ

サーバはどのクライアントがどのファイルを操作しているかを管理

もしサーバがクラッシュすると、再起動時に（ファイルの整合性を保つために）以前の状態を復元する必要あり

状態不保持サーバではクラッシュ後に再起動した際、状態の復元は必要ない

SVR5 (UNIX SystemV Release5)のRFS(Remote File System)は状態保持型

NFS(Network File System)は状態不保持型

現在はRFSは廃れてNFSが主流

15


状態不保持サーバでクライアントの状態を記憶しておきたい場合

Webサーバの例

クライアント(ユーザ)が前回訪れたページを記憶しておき、次回のアクセスではそれが表示されるようにしたい

cookieを使用cookie=クライアント側に保存され、サーバから参照可能な小さなデータ

クライアントの初のアクセス時に、サーバはcookieを送信し、クライアント側に保存

次回のアクセス時に、サーバはクライアントのcookieを読み出し、前回のアクセス情報を知る

16

コード移動

今までの議論では通信はデータの受け渡しに限定

プログラムを通信で受け渡すことによって、分散システムの設計が容易になる場合がある

コード移動(Code Migration) ＝プログラムコードが通信によって移動すること

コード移動のさまざまなアプローチを紹介

特に困難な、異なるマシン間のコード移動に関する議論も紹介

モバイルエージェントシステム D’Agentを紹介

17

コードを移動する理由(1/5)

分散システムにおけるコード移動: プロセス移動(process migration)の形態が多い

プロセスがあるマシンから別のマシンに移動すること

動作中のプロセスの移動一般にコストが掛かる

コストをかけて割に合う理由は？

移動させたい理由の１つ --- 性能の向上

高負荷のマシンから低負荷のマシンにプロセスを移動

負荷分散アルゴリズム：高性能計算システムなどでは重要

しかし、分散システムでは…CPU負荷の分散よりも、通信の適化の方が重要度が高い

異なった計算機群で動作性能の問題は定性的に扱われることが多

い（性能の数学的モデル化は困難）

18


クライアントのコードの一部をサーバへ送った方がよい場合

サーバは非常に大きなデータベースを扱うと仮定

クライアントが大量のデータに関して多くの操作を行いたい時

クライアントアプリケーションのコードの一部をサーバに転送して、サーバ上で実行し、結果のみを通信によってクライアントが受け取る通信量・通信時間が小さい

一般に、データが存在する場所に近いところでデータを処理

19


サーバのコードの一部をクライアントへ送った方がよい場合

多くの対話的データベースアプリケーション

クライアントは決まったフォームを埋めるデータベース操作(SQLなどのクエリ命令)の系列に変換

フォーム入力をクライアント側で処理し、完全に埋められたフォームのみをサーバに送信クライアント/サーバ間の断片的な通信を削減性能向上

20

コードを移動する理由(4/5)処理の並列度を上げるコード移動

Web検索プログラムの例小さなプログラムがサイトからサイトへ移動しながらwebを検索

そのようなプログラムのコピーを異なるサイトに送信一つのプログラ

ムで行うより性能が線形オーダーで向上

複雑な並列プログラミングを避けて、並列処理による性能向上を達成可能

システムの柔軟性向上のためのコード移動

分散アプリケーションを幾つかの部分に分け，各部分をどのマシンで実行するかを動的に決定

事前に静的に配置を決めるより柔軟性が高い

21

コードを移動する理由(5/5)分散システムの動的構成

ファイルサーバの例

サーバがファイル操作に関する決まったプロトコルしかサポートしていないと、クライアントもそのプロトコルを実装する必要があるクライアントの開発時にプロトコルの実装が利用可能である必要

別のアプローチ：クライアントはサーバと通信するときに、動的にサーバと通信するプロトコルを実装

クライアントはプロトコルの実装をダウンロードして、それを用いてサーバを起動

22

コード移動のモデル(1/7)

コード移動

単にコードのみを移動させるだけでなく、一般に複数のモデルが考えられる

[Fugetta et.al. 1998]のフレームワーク:プロセス：３つのセグメントから構成

コードセグメント(code segment): プログラムの実行コード

リソースセグメント(resource segment): プロセスが必要とする外部リソース（ファイル、プリンタ、デバイス、他のプロセスなど）への参照

実行セグメント(execution segment): プロセスの現在の実行状態（内部データ、スタック、プログラムカウンタなど）

どのセグメントを移動させるかにより分類

23


移動させるセグメントによる分類

弱移動性(weak mobility)コードセグメントのみ移動

移動したプログラムは必ず初期状態から起動

例）　Javaアプレット、Macromedia Flashなど

強移動性(strong mobility)実行セグメントも移動

移動したプロセスは、移動先で続きを実行

実装はより困難

例）　D’Agent (後述)

24


送信側･受信側どちらが移動を引き起こすかによる分類

送信者起動の移動(sender-initiated migration)コードを送信する側のマシンによって移動が引き起こされる

例）計算サーバへのバッチ処理プログラムのアップロード、web検索プログラムをサーチエンジンのあるサイトに送信して検索を実行、など

受信者起動の移動(receiver-initiated migration)コードを受信する側のマシンによって移動が引き起こされる

例） Javaアプレット、Flashなど

25


受信者起動の方が送信者起動よりも実現が楽コード移動はクライアント・サーバ間で起こることが多く、引き起こすのはクライアント側

クライアントからサーバにコードを安全(secure)にアップロードするためには、クライアントがサーバに認証されている必要サーバが全てのクライアントの情報を把握する必要がある

逆にクライアントがサーバからコードをダウンロードする場合、サーバはクライアントを知っている必要がない（匿名で行える）

26


弱移動性の更なる分類移動したコードを、コードを受け取ったプロセス(target process)自身で実行

例）Javaアプレットwebブラウザ自身のアドレス空間で実行される

利点：別のプロセスを起動する必要がないそのプロセスとのプロセス間通信が発生しない効率が良い

欠点：移動したコードが悪意あるコードである場合に、不正なアクセスからプロセスを守る必要がある

移動したコードを、コードを受け取ったプロセスとは別のプロセス(separate process)で実行

27


強移動性の更なる分類

プロセスを（本当に）移動させる（移動元のプロセスは削除）

プロセスのコピー(クローン）を別のマシンで走らせる（移動元のプロセスは実行を継続）

UNIXのfork()システムコールに類似

利点：このモデルは多くの非分散アプリケーションで既に使われているモデルに近い（リモートかローカルかの差だけ）

透過性が向上

28


29

移動とローカルリソース(1/9)

今までの議論ではコード/実行セグメントのみ考慮

リソースセグメントの移動：一般に困難

単純に他の場所に転送できない場合例）プロセスが通信に使用中のTCPポートへの参照（ソケット）

接続を中止して、移動先のマシンで新たに再接続する必要

移動しても問題ない場合例）URLのような大域的な参照移動先でも有効

30

移動とローカルリソース(2/9)プロセス対リソース結合度(process-to-resource binding)による分類

識別子による結合(binding by identifier)プロセスはリソースそのものと結合（他のもので代替不可）

も強い結合

例） URL, ftpサーバのアドレス, ソケットなど

値による結合(binding by value)リソースの値（内容）が同じなら良い（場所は変わってもよい）

例） CやJavaなどの標準ライブラリ

型による結合(binding by type)リソースの型（種類）が同じなら良い

移動先に同じ機能を提供するものが存在すれば、それを替わりに使用可能

例）プリンタ、ディスプレイなど

31

移動とローカルリソース(3/9)リソース対マシン結合度(resource-to-machine binding) による分類

非アタッチリソース(Unattached resources)簡単に移動可能なリソース

例）プロセスが専有する(小さな)ファイルなど

拘束リソース(Fastened resources)移動可能だが移動にコストが掛かるリソース

例）データベース全体、webサイト全体など(巨大なファイル)

固定リソース(Fixed resources)移動不可能なリソース

例）ローカルなデバイス（プリンタ、ディスプレイなど）、ソケットなどの通信のエンドポイント

32


プロセス対リソース、リソース対マシンの結合度の組み合わせ --- 全部で9通り

非アタッチリソース

33


非アタッチリソースの場合

一般にMV(move)がもよい

リソースが共有されている場合大域的参照(GR:global reference)を用いるのが良い

大域的参照(GR)の例：ドメインネーム,IPアドレス,URLなど


34

移動とローカルリソース(6/9)大域的参照(GR)が高コストになる例

マルチメディアワークステーションのための実時間高品質画像生成プログラム

画像生成は高性能計算が必要なので、より高性能な計算サーバにコードを移動させて実行したい

計算サーバからマルチメディアワークステーションへの大域的参照

通信経路の設定が必要

画像転送のために広帯域を要求(厳しいQoS要求)このような大域的参照はコストが掛かる


35

移動とローカルリソース(7/9)大域的参照(GR)が困難な例

ソケットなどの通信エンドポイントIDによってプロセスと結合(固定リソース)

2つの解決法移動元から通信を転送してもらう

ただし、移動元マシンがクラッシュしたときには通信が中断

移動するプロセスと通信中の全てのプロセスの（移動元マシンへの）参照を（移動先に）変更してもらい、以降の通信メッセージは移動先マシンに送信してもらう


36

値による結合の場合固定リソースの場合

例）プロセス間の共有メモリ大域的参照(GR)の利用分散共有メモリの実装が必要

拘束リソースの場合例）ランタイムライブラリなど

通常は移動先に同じものが存在

無い場合は移動先にコピー(CP:copy)大域的参照(GR)を用いれば、大量のデータをコピーする必要が無い

非アタッチリソースの場合CP(またはMV)がもよい

もしリソースが共有されているならばGRしかない

移動とローカルリソース(8/9)非アタッチリソース

37


型による結合の場合

RB（rebind:移動先にある同じタイプのリソースで代替）がも良い解決法

無理にリソースを移動させる必要が無い

もし移動先に欲しいタイプのリソースが無ければCPまたはMVで移動先に持ってくるか、GRを利用


38

異種システム間の移動(1/4)

移動先マシンが移動元と異なるアーキテクチャ

移動したコードをそのまま実行できない

分散システムはさまざまなアーキテクチャのマシンで構成移動したコードを異なるアーキテクチャで実行可能にする必要

弱移動性の場合

コードセグメントの移動のみ

ソースコードを再コンパイルすることで対応可能

39


強移動性の場合

実行セグメントを移動する必要

プロセスを実行するプラットフォームに強く依存

プロセスのローカルデータ（変数）、スタック、プログラムカウンタの他に、レジスタ値などプラットフォーム依存の情報を一般に含む

同一アーキテクチャ、同一OSのマシン間でのみ、実行セグメントを無変更で移動させることが可能

もしプロセスの実行をプラットフォーム依存データと独立に出来れば、実行セグメントを移動させることが容易になる

40

異種システム間の移動(3/4)Cなどの手続き型言語に有効な解決法

手続き(関数、メソッド)呼び出し時にのみコード移動を許す

プログラムスタックのコピーをマシンに依存しない形式(移動スタック(migration stack))で管理

41


一般的な解決法

ソースコードを直接解釈実行(インタプリタ)例）スクリプト言語(perl,tclなど)

仮想マシンで共通の中間コードを実行例）Java

これらのアプローチの欠点

特定の言語に縛られる

既存の言語とのインタフェースを提供することが重要

42

例: D’Agents

D’Agentsコード移動をサポートするミドルウェア

D’Agentにおけるエージェント(agent) ＝異なるマシン間を移動するプログラム(ソフトウェアエージェント(後述))プログラムはインタプリタ言語(Tcl, Java, Scheme)で記述異種システムのサポートが容易

対応するインタプリタのプロセスにより実行

移動性を3種類の方法でサポート

送信者起動弱移動性

プロセスの移動による強移動性

プロセスのクローンによる強移動性

43

D’Agentsにおけるコード移動(1/3)

送信者起動弱移動性agent_submitコマンド：　エージェントを移動先マシンに送信してそこで実行し、結果を受け取る

44


プロセスの移動による強移動性

agent_jumpコマンド：現在実行中のエージェントを

移動先マシンに移動し、そこで実行を継続

45


プロセスのクローンによる強移動性

agent_forkコマンド： agent_jumpとほぼ同じだが、移動元マシンでもagentの実行は継続(UNIXのfork()システムコールと同様）

46

D’Agentsのアーキテクチャ

5階層で構成下位層：TCP/IPおよび電子メールを使用

第2層：各マシンで動作するサーバ

エージェントの管理・認証・エージェント間通信を担当

第3層：D’Agentsシステムの言語非依存のコア

エージェントの開始・終了、移動処理、通信処理を担当

第4層：各言語のインタプリタ

第5層：各言語で記述されたエージェント

47

ソフトウェアエージェント

ソフトウェアエージェント(Software Agents)まだ正確な定義は定まっていない

ここでの定義：ユーザ及び他の（遠隔）エージェントと協調して、変化を引き起こすことができる、自律的(autonomous)なプロセス

単なるプロセスとは異なり、自分で判断して行動する

分散システムで重要な役割

48

ソフトウェアエージェントの分類(1/2)

エージェントシステムの特性による分類協調エージェント（collaborative agent）

複数のエージェントと協調して共通の目標を達成例）会議のアレンジを行うエージェント

各エージェントは参加者の予定（スケジュール、場所などの制約）を考慮して、複数のエージェント間で協調して会議の日時・場所などを設定

移動エージェント（mobile agent）複数のマシン間を移動できるエージェント

強移動性のサポートが必要（自律的な動作のため）例）インターネット上を渡り歩いて情報を収集するエージェント

49

ソフトウェアエージェントの分類(2/2)

エージェントが提供する機能による分類

インタフェースエージェント(interface agent)エンドユーザの要求を学習し、ユーザに適したインタフェースを提供するエージェント

例）オークションにおいて売り手と買い手のマッチングを行うエージェント

エージェントのオーナの要求を学習して、適切な相手を選択

情報エージェント(information agent)多くの異なる情報源からの情報を管理するエージェント

例）電子メールエージェントオーナのメールボックスから不要なメールを取り除いたり（スパムフィルタなど）、主題毎に適したフォルダに分類

50

エージェントのさまざまな特性

一般に、エージェントはさまざまな特性により特徴付けられる

51

エージェント技術分散システムにおけるエージェントのサポート

エージェントのうち共通に用いられる構成要素をミドルウェアに取り込むことが重要

FIPA(Foundation for Intelligent Physical Agents)ソフトウェアエージェントの一般的なモデルを開発中

http://www.fipa.org/specs/fipa00001/

52

エージェントプラットフォームの一般的モデル(1/4)

エージェントプラットフォームマルチエージェントシステムで必要な基本的なサービス（エージェントの生成/削除、エージェントの位置同定、エージェント間通信）を提供

53


エージェント管理要素(agent management component)プラットフォームに関連するエージェント群を管理

エージェントの生成・削除、特定エージェントの通信エンドポイントの検索の機能を提供

エージェントの大域的IDからローカルな通信エンドポイントへの変換サービス(naming service)の提供（詳細は4章）

54


ディレクトリサービス

他のエージェントが提供している特定のサービスを検索大域的に一意のサービス名、サービスの型、サービスを提供している場所の3つ組のリスト

遠隔エージェントからアクセス可能

55


エージェント通信チャネル(agent communication channel,ACC)他のプラットフォームとの高信頼かつ順序を保証する2点間通信路を提供

ACCの実装：特定のポートでメッセージを待ち受け、プラットフォーム内の他のサーバやエージェントにメッセージを転送するサーバ

D’agentsにおけるサーバに対応

ACC間通信：相互運用性保証のため、標準的なプロトコル（Internet Inter-ORB Protocol(IIOP))を使用

56

エージェント通信言語(1/3)エージェント間通信

エージェント通信言語(agent communication language,ACL)にて行われる

アプリケーションレベルの通信プロトコル

メッセージの目的(purpose)と内容(content)を厳密に分離

メッセージは特定種類の目的しか持ち得ない

57

エージェント通信言語(2/3)ACLの本質

送信側と受信側のエージェントはメッセージの目的に関して合意

メッセージの目的によって受信者の反応が決定される通信プロトコルを定義

例） CFPを受信するとPROPOSEを返すなど

58

エージェント通信言語(3/3)ACLメッセージの構成

ヘッダと内容から成る

ヘッダ：メッセージの目的、送信者・受信者のIDを含む

内容：通信相手によって異なる（ACLでは内容のフォーマットを規定しない）

受信者が内容を正しく解釈するためには

ヘッダに内容が記述された言語やエンコード方法などの情報も含める

送信者･受信者間に内容の解釈に合意が無い場合

標準的な解釈方法をオントロジ（ontology）フィールドに記述

59

関連情報源

D’Agentsおよび移動エージェントに関して

D’Agents開発元:　http://agent.cs.dartmouth.edu/

コード移動一般に関して

W3C Architecture Domain: http://www.w3.org/MobileCode/Overview.html

ソフトウェアエージェントに関して

FIPA公式ページ: http://www.fipa.org/

60

3章のまとめ分散システムにおけるプロセスの構成法

マルチスレッド

通信待ちの間に他の仕事をすることが可能性能向上

クライアント

主にユーザインタフェースを提供

透過性向上のためにクライアント側に実装できる機能が幾つか存在

サーバ

一般的なサーバ設計法：さまざまな設計課題が存在

コード移動

性能や柔軟性を向上するために有用

リソース移動の問題に対してさまざまな解決法が存在

異なる機種間のコード移動の実現に関する問題現時点では仮想マシンによる解決法が有効

ソフトウェアエージェント

特別な種類のプロセス：自律的に動作し、他と協調動作

ACLによって通信

61

演習問題

1. 分散システムをスレッドを用いて構築する利点を複数挙げよ。

2. クライアント側の工夫で分散システムのどのような透過性が実現可能か？理由も説明せよ。

3. 状態不保持サーバと状態保持サーバを比較し、それぞれの利点･欠点を考察せよ。

4. 分散システムにおけるコード移動の有用性に関して、具体例を交えて考察せよ。

5. 異なるアーキテクチャ・OSのマシン間でコード移動を実現する方法として、仮想マシンを用いるよりも良い解決法はあるか考察せよ。

6. 教科書（またはこの資料）で挙げた例以外で、コード移動を実現している処理系にどのようなものがあるか調査せよ。

7. 教科書（またはこの資料）で挙げた例以外で、ソフトウェアエージェントを用いた有用なアプリケーションとしてどのようなものが考えられるか？

分散システムにおけるプロセス - 東野研究室nakata/mobile-cp/chap-03j.pdf2...

Documents

Transcript of 分散システムにおけるプロセス - 東野研究室nakata/mobile-cp/chap-03j.pdf2...