分散システムにおける通信

２章後半

2

プロセス間通信

プロセス間通信：分散システムの中核

メッセージパッシングに基づくネットワークの下位層で提供される低位のサービス

大規模分散システムの構築 高位の通信手段が必要

4つの（高位の）通信モデルを解説

遠隔手続き呼び出し (RPC)遠隔メソッド起動(RMI)メッセージ指向ミドルウェア(Message-Oriented Middleware,MOM)ストリーム型通信(Stream-based Communication)

3

メッセージ指向通信RPCやRMI：　分散システムにおいて通信を隠蔽

全ての場合で適切なわけではないRPCやRMIは同期的な通信機構 （クライアントはリクエスト送信後に処理が終わるまで待つ）

リクエストの送信時に、受信側プロセスが稼動中であるとは限らない場合に不向き

メッセージング(messaging)送信時に受信相手が実行中である必要が無い通信

送信メッセージは受信されるまでどこかに蓄積される

cf. 電子メール

非同期通信

メッセージングに基づいた通信: メッセージ指向通信(Message-Oriented Communication)

4

メッセージ通信のアーキテクチャ

ホスト(計算機)：　通信サーバに接続

通信サーバ：　メッセージをネットワークを通じて宛先ホストに配送

仮定：　各ホストはそれぞれ1台の通信サーバと接続

5

永続通信

電子メールシステムにおける通信

ホスト：ユーザエージェント(MUA)を実行

通信サーバ=メールサーバ(MTA)

永続通信(Persistent Communication)メッセージが受信側に届くまで通信システムが保持しつづける通信

6

一時通信

一時通信（Transient Communication）永続通信の逆

メッセージは送信側・受信側双方のプロセスが稼動中の場合にのみ送信される

もし受信プロセスが稼動していなければメッセージは破棄

任意のトランスポートレベルのサービスは一時通信のみ提供

例） ストア＆フォワード型ルータ

パケットを配送先に配送できなければ破棄

7

同期/非同期通信

通信の同期/非同期による分類

非同期通信（ Asynchronous Communication ）送信側アプリケーションはメッセージ送信後、すぐ他の仕事ができる

送信メッセージはバッファに蓄えられ、いずれは送信側ホストまたは通信サーバによって宛先に送信される

同期通信（ Synchronous Communication ）送信側アプリケーションはメッセージ送信後、受信側のバッファに蓄積されるか、実際に受信者が受信するまで待つ

8

メッセージ指向通信の分類(1/4)永続非同期通信(Persistent Asynchronous communication)

メッセージ送信後、すぐ別の仕事ができる（送信バッファに蓄積） 非同期的

送信時に受信プロセスが止まっていても良い（起動したときに受信。）永続

受信時に送信側プロセスが止まっていても良い 永続

例）　電子メール

9

メッセージ指向通信の分類(2/4)永続同期通信(Persistent Synchronous communication)

送信プロセスはメッセージが受信ホストのバッファに蓄積されるまで待つ

同期

受信プロセスは起動したときにバッファに溜まったメッセージを受信（送信プロセスは止まっていても良い） 永続

10

メッセージ指向通信の分類(3/4)一時非同期通信(Transient Asynchronous communication)

送信メッセージは、送信バッファに一時的に蓄積され、送信プロセスは送信後、すぐ別の仕事ができる 非同期

並行して通信システムはメッセージを受信ホストに配送

もし受信プロセスが稼動していなければメッセージは破棄 一時

例） UDP

11

メッセージ指向通信の分類(4/4)

一時同期通信(Transient Synchronous communication)送信プロセスはメッセージが受信側に届くまで待つ 同期

受信プロセスが稼動していなければメッセージは破棄 一時

メッセージがどこまで届くまで待つかによって、さらに3種類に分類

受け取りに基づく一時同期通信(Receipt-based transient synchronous communication)配送に基づく一時同期通信(Delivery-based transient synchronous communication)応答に基づく一時同期通信(Response-based transient synchronous communication)

12

一時同期通信(1/3)

受け取りに基づく一時同期通信(Receipt-based transient synchronous communication)

送信プロセスは受信ホストのバッファに蓄積されるまで待つ

受信プロセスはその時別の仕事をしていても良い

13

一時同期通信(2/3)

配送に基づく一時同期通信(Delivery-based transient synchronous communication)

送信プロセスは受信プロセスが受信処理を開始するまで待つ

受信プロセスからのメッセージ受理通知を受け取ると送信プロセスは処理を続行

例) 非同期RPC

14

一時同期通信(3/3)

応答に基づく一時同期通信(Response-based transient synchronous communication)

送信プロセスは受信プロセスが受信処理を終えるまで待つ例） (同期)RPC, RMI

15

分散システムでのメッセージ指向通信の歴史

従来の分散システム応答に基づく一時同期通信のみサポート(RPC,RMI)後に、より弱い形の一時同期通信をサポート(非同期RPC, 保留同期RPC)

メッセージパッシングシステム

初に一時非同期通信をサポート

後に、同期通信を行うための機能を追加

まだ、通信は一時的であると仮定 同時に稼動しているプロセス群でのみ用いられる

地理的なスケーラビリティを達成するためには不十分

16

メッセージ型一時通信の例

Berkeleyソケット

メッセージパッシングインタフェース(Message Passing Interface, MPI)

17

Berkeleyソケット

TCP/IPにおけるトランスポート層のインタフェース

ソケット(socket)と呼ばれる通信のエンドポイントを介して通信

18

メッセージパッシングインタフェース(MPI) (1/4)

高性能並列計算アプリケーション開発

効率の良いメッセージ指向通信プリミティブが必要

通信ハードウェアに依存しない標準インタフェース規格の必要　 メッセージパッシングインタフェース(Message-Passing Interface ,MPI)として標準化

並列計算アプリケーション開発用に設計される

一時通信に基づく

ネットワークを直接用いる 通信サーバという概念は無い

プロセスのクラッシュやネットワーク分断などの深刻な障害からの回復は考慮しない（効率を重視）

19

メッセージパッシングインタフェース(MPI) (2/4)

MPIではプロセスをグループ化：　グループIDトランスポートアドレス：　(グループID,プロセスID)

MPIの通信プリミティブ一時通信のほとんどの形態を提供

「受け取りに基づく一時同期通信」のみ非対応

20

メッセージパッシングインタフェース(MPI) (3/4)

MPI_bsendメッセージを送信するとすぐ処理を継続 一時非同期通信

MPI_ssend送信メッセージが受信側で受理されるまで待つ 配送に基づく一時同期通信

MPI_sendMPI_bsendまたはMPI_ssendと同じ(実装依存)

MPI_sendrecv送信メッセージに対する返事を受信するまで待つ 応答に基づく一時同期通信

MPI_isend,MPI_issendそれぞれMPI_send,MPI_ssendの別バージョン

メッセージのバッファへのコピーを行わなわず、メッセージの格納場所へのポインタのみを渡す点が異なる

21

メッセージパッシングインタフェース

(MPI) (4/4)

MPIでさまざまな形の通信がサポートされる理由

プログラム 適化の自由度を増すため

プログラムの意味を変えずにプリミティブを別のものに置き換えることが可能

22

永続通信の必要性

永続通信：　

大規模・広域分散ネットワーク上にミドルウェアを構築するために必要

ネットワークが異なる部署、管轄に分散 全てがすぐにアクセス可能

とは限らない

ベンダー独自の永続通信手法 相互接続性、移植性に問題

障害発生時に、障害回復処理を後回しにできるメッセージを送信してから受信するまでの期間が長くなっても良い

一時通信だと、障害発生時すぐに障害の隠蔽と回復を行う必要

永続通信のみでも不十分分散システムの用途に依存して、どのタイプの通信が必要かが決まる

23

メッセージ型永続通信

メッセージキューイングシステム（Message-Queuing System)

メッセージ指向ミドルウェアサービスの重要なクラス

永続非同期通信をサポート

メッセージをしばらく蓄えておく機能を提供

メッセージ送受信時に、送信者と受信者のどちらかが動作している必要がない

24

メッセージキューイングモデル

基本アイデアアプリケーションは特定の待ち行列(キュー,queue)にメッセージを入れることによって通信を行う

キューに入れられたメッセージは通信サーバの中継によって、いつかは必ず受信プロセスのキューに配送される

送信時に受信プロセスがダウンしていても構わない

受信時に送信プロセスがダウンしていても構わない

疎結合通信(loosely-coupled communication)

25

メッセージキューイングシステムのインタフェース

４つのプリミティブから構成

put : メッセージを指定したキューに追加

get : 指定されたキューが空でなくなるまではブロックし、 初のメッセージを取り出す

poll : 指定されたキューにメッセージがあるかチェック（ブロックはされない）

notify : メッセージが指定されたキューに投入されたときに呼ばれる割り込みハンドラを登録

26

メッセージキューイングシステムのアーキテクチャ

メッセージ送信の流れ送信者 発信元キュー(source queue) トランスポート層 宛先キュー(destination queue) 受信者

発信元キューと宛先キュー：　キューイング層を構成

宛先キューの(キューレベル)アドレスからトランスポートアドレスを検索

キューの管理 キューイングマネージャが行うアプリケーションと直接やり取り

ルータのように中継(relay)を行うものもある

27

ルータを用いたメッセージキューイングシステム (1/2)

ルータを用いたメッセージの中継(relay)キューレベルアドレスからネットワークアドレスへの動的変換のための汎用のサービスがない

そのかわり、キューイングシステムのネットワークトポロジーは静的

トポロジーを知っている(キューイング層の)ルータにメッセージを渡す

ルータはメッセージのアドレスを見て、どのルータに渡せばよいか判断

もしルータ自身がアドレスを知っているメッセージならば、宛先キューに直接配送

28

ルータを用いたメッセージキューイングシステム (2/2)

ルータでメッセージを中継する利点各ルータが管理すべき情報は小さい スケーラブル

ルータに以下の機能を持たせることも可能

メッセージ配送の記録を残す

セキュリティ、耐障害性の理由

メッセージ形式の変換

異なるプロトコル間のゲートウェイの役割

マルチキャスト　各ルータにおいてメッセージを複数の宛先キューに送信するだけで実現

29

電子メールシステムとの比較

電子メールシステム(E-mail System)メールサーバがユーザからのメッセージを蓄積、配送

（現在では）ルーティングは行っていないメールアドレスのドメイン名から宛先のメールサーバのアドレス(DNSのMXレコード)を検索し、直接TCP接続を行う

メッセージキューイングシステムとの違い電子メールシステムはエンドユーザを直接サポート

メッセージキューイングシステムはプロセス間の永続通信をサポート

電子メールシステムには特に必要でないが、メッセージキューイングシステムでは必要なもの

メッセージ配送の保証、配送優先度、ログ機能、マルチキャスト、負荷分散、耐故障性など

30

例： Java Messaging System

メッセージ指向ミドルウェア(MOM)をJavaで利用するための標準インタフェース

J2EE(Java 2 Platform, Enterprise Edition)に付属

２種類のメッセージングモデルPTP(Peer-to-Peer)メッセージングモデル

１対１通信：　宛先を指定して送信

Pub/Sub(Publisher-Subscriber)メッセージングモデル

１対多通信（マルチキャスト型）： 受信者(subscriber)はメッセージを受け取りたい送信者(publisher)に購読登録 送信者は登録された受信

者全員にメッセージを配送

詳細は下記のサイトを参照http://www.atmarkit.co.jp/fjava/keyword/jkey/jkey06.htmlhttp://java.sun.com/products/jms/

31

プロセス間通信

プロセス間通信：分散システムの中核

メッセージパッシングに基づくネットワークの下位層で提供される低位のサービス

大規模分散システムの構築 高位の通信手段が必要

4つの（高位の）通信モデルを解説

遠隔手続き呼び出し (RPC)遠隔メソッド起動(RMI)メッセージ指向ミドルウェア(Message-Oriented Middleware,MOM)ストリーム型通信(Stream-based Communication)

32

ストリーム型通信

これまでの通信が扱う対象

独立した単位の情報の交換 通信が起こるタイミングに依存しない

タイミングが重要な通信

動画や音声ストリーム

正確なレートで転送される必要 時間依存

時間依存のストリームをサポートするために、分散システムで提供されるべき機能は何か？

33

連続/離散メディア

連続メディア(Continuous Media)各データ要素の時間的な関係が本質的

例）　動画(Motion)画像の時間的な系列

次の画像は一定時間後に表示

正しい再生のためには、画像の表示順序が正しいだけでなく、一定のレートで表示される必要がある

離散メディア(Discrete Media)各データ要素に時間的な関係がない

例）　テキスト、静止画、実行可能ファイルなど

34

データストリーム

時間依存の情報交換

分散システムでは一般にデータストリーム(data stream)をサポート

データストリーム

単なるデータ単位の系列

離散/連続メディアいずれにも適用可能

連続メディアでは時間情報が重要

異なる転送モードで時間情報の扱いに対応

35

ストリームの分類

単純なストリーム(Simple Stream)一本のデータ系列から成る

複雑なストリーム(Complex Stream)サブストリーム(substream)と呼ばれる複数の単純なストリームの組から成る

サブストリーム間にも時間依存関係がある例)

ステレオ音声(2ch音声): ２つのサブストリーム お互いに同期している必要あり

映画: 動画とステレオ音声 1本の動画ストリーム, 2本の音声ストリーム, 字幕ストリーム, 他言語吹き替え音声ストリーム 全てが同期する必要

36

ストリームとサービス品質(QoS)

時間依存の要求(あるいは機能面を除く他の要求) サービス品質(Quality of Service,QoS)と呼ばれる

基盤となる分散システムやネットワークに対して、ストリームの時間制約などを保証するためには何が必要かを記述

連続データストリームに対するQoS時間の正確性（timeliness）、データ量(volume)、信頼性(reliability)

37

QoSの指定

QoS要求の表現の一例：

フロー仕様(flow specification) [Partridge 1992]

入力特性、および、サービス要求の記述から構成入力特性：　トークンバケットアルゴリズムにより定式化

38

トークンバケットアルゴリズム(1/3)

トークンバケットアルゴリズム（Token Bucket Algorithm）

ストリームのトラフィック特性の指定に利用

基本アイデア

トークン(token)：固定サイズのデータ量を表す

トークンはバケット(bucket)と呼ばれる一定容量のバッファに蓄積

バケットが一杯になると溢れたトークンは破棄される

バケットに溜まっているトークン数×トークンサイズ分だけのデータをアプリケーションはネットワークに送出可能

39

トークンバケットアルゴリズム(2/3)

アプリケーションがNバイトのデータ単位を送出したいとき

少なくともNバイト分のトークンをバケットから取り除く必要あり

もしトークンサイズがkならば、N/k個のトークンを取り除く必要

もしバケット中のトークンがN/k個未満であれば送出できない

40

トークンバケットアルゴリズム(3/3)

トークンバケットアルゴリズムによって

データが比較的一定のレートでネットワークに転送される

転送レートはトークンを生成するレート(token bucket rate)によって決定

バースト的な転送も許される連続でバケット一杯分(token bucket size)のデータを転送することも許される

過度なバースト転送を避けるため、転送レートをある大値までに制限可能

41

サービス要求

サービス要求を構成する項目[Partridge 1992]損失感受性（loss sensitivity） (bytes)

どれだけデータが損失しても許せるか

損失間隔（loss interval） (μsec)どのくらいの間隔でデータが損失しても許せるか

バースト損失感受性（burst loss sensitivity） (bytes)連続でどれだけデータが損失しても許せるか

小検知遅延（minimum delay noticed） (μsec）受信者がデータ遅延に気が付く、ネットワーク遅延の 小値

この値より遅延が小さければ受信者は遅延を検知できない

大遅延変動（maximum delay variation） (μsec)許容できる遅延のばらつきの 大値

保証品質（quality of guarantee）このサービス要求がどれくらい強い要求かを示す数

42

ストリームの確立

QoS要求を満たすストリームの確立

リソースの割り当て(resource allocation)ストリーム管理のためのリソース

通信帯域(bandwidth)バッファ

処理能力(processing capacity)帯域予約(bandwidth reservation)

（パケットの）スケジューリング優先度を設定することにより行う

（ルータやOSに対する）バッファ割り当て(buffer allocation)スケジューラ、エンコーダ、デコーダ、フィルタなどのタスクスケジューリング（CPU時間のスケジューリング）

データ単位が時間通りに処理されることを保証

43

リソース割り当て問題

問題点：各QoS要求と確保すべきリソースとの対応に一般的な決まりがない

例）連続でk個のデータ単位が損失しないことの保証

送信元から送信先までに通るルータに対して静的なバッファを予約

以下の全てが可能な 善のモデルは存在しない(1) QoSパラメタの記述

(2) あらゆる通信システムに適用可能なリソース記述

(3) QoSパラメタからのリソース利用方法への変換

QoSの表現は困難であり、システムによって異なるアプローチが採られている　

44

Resource reSerVation Protocol(RSVP)Resource reSerVation Protocol(RSVP)

トランスポートレベルのプロトコル

QoS保証のためにルータに対するリソース予約を行う

receiver-initiated QoS protocol受信者が送信者に対してリソース予約要求を行う

45

RSVPの動作(1/3)

１．　送信者は、送信側マシンで稼動するRSVPプロセスに対してフロー仕様を与える

２．　送信側RSVPプロセスは、受信者への経路（パス）を設定し、フロー仕様の情報を中間ノードに対して提供

（図は日本IBM:「TCP/IPチュートリアルおよび技術解説書」より引用）

46

RSVPの動作(2/3)

３．　受信者は、リソース予約要求を送信者への経路に向かって送信

リソース予約要求：フロー仕様とほぼ同じだが、パラメタ値は送信者の指定より低いQoS（受信者のうち も高い要求を満たすのに必要な値）

（図は日本IBM:「TCP/IPチュートリアルおよび技術解説書」より引用）

47

RSVPの動作(3/3)４．　RSVPプロセスがリソース予約要求を受信すると、それを許可制御モジュール

(admission control module)に渡し、十分なリソースがあるか否かをチェック

５．　同時に、ポリシー制御モジュール(policy control module)は受信者がリソース予約を行う権限があるか否かをチェック

６．　上記2つのチェックをパスするとリソースが予約される

（図は日本IBM:「TCP/IPチュートリアルおよび技術解説書」より引用）

Filterspec:ストリームに属するパケットの識別ルール(通常は送信元IPアドレスおよびポート番号)

Flowspec=フロー仕様

Filterspec

Flowspec Packet Classifier:ストリームに属するパケットを分類

Packet Scheduler:ストリームパケットが適切なレートで送出されるようにパケットをスケジューリング

48

ストリーム同期

マルチメディアシステムにおいて重要な点

異なる複数のストリームが互いに同期

2種類の同期

離散データストリームと連続データストリームの同期例） 音声と同期したスライドショー

連続データストリーム同士の同期例）

音声と動画の同期(唇同期(lip synchronization)など)ステレオ音声の右chと左chの同期

49

ストリーム同期の粒度

同期はストリームを構成するデータ単位毎に行う必要同期するデータ単位をどう選ぶか？ ストリームがどのように再生されるかに依存

例1） CD品質ステレオ音声ストリーム (16ビットPCM、サンプリングレート44.1kHz)

高音質ステレオ再生のためには、１サンプル毎（約20μ秒毎）の同期が必要

例2) 音声と動画の唇同期（lip synchronization）動画のフレームレートが30Hzなら、30msec毎に同期すればよい

実際にはもっと粗い単位(40～80msec)の同期で十分[Steinmetz 1996]

50

同期メカニズム

ストリームの同期をどのように実現するか？

以下の2点に分けて解説

1. ２つのストリームを同期させる幾つかの基本的なメカニズム

2. それらをネットワーク環境でどのように分散させるか？

51

ストリーム同期の基本メカニズム

同期メカニズム

異なる抽象レベルで考えることができる

下層レベル：ストリームのデータ単位を直接操作して同期プロセスが複数のストリームのデータ単位に対して読み書き操作を行い、指定された時間制約や同期に関する制約を満たすことを保証

欠点：データの読み書きという低レベルの操作のみを用いて、同期メカニズムを完全にアプリケーション側に実装する必要がある

52

マルチメディアミドルウェアシステム

より良い（抽象度の高い）同期メカニズムアプリケーションがストリームとデバイスをより容易に操作できるインタフェースを提供　 マルチメディアミドルウェア（Multimedia Middleware）

音声/動画ストリームのレート制御、モニタ・カメラ・マイクなどのデバイス制御などの高位のインタフェースを提供

イベントの生起をアプリケーションに知らせるインタフェースを提供

イベントの例： k枚の画像を表示する毎に生起、mサンプル分の音声を再生する毎に生起、など 唇同期などの実装を容易化

53

同期メカニズムの分散化

同期メカニズムの分散化

受信側プロセス何をどのように同期させればよいか知る必要

完全な同期仕様(synchronization specification)が必要

一般的な実現方法

複数の異なるストリームを一つのストリームに多重化

多重化されたストリームは各ストリームの全てのデータ単位を含み、かつ、それらの同期情報も含む

後にMPEGストリームとして実現

54

MPEG規格

MPEG(Motion Picture Experts Group)標準

動画と音声の圧縮アルゴリズムの集合

MPEG-2：テレビ放送品質の動画像を4～6Mbpsに圧縮複数のストリームを1つにまとめることが可能

各入力ストリームからタイムスタンプ付きパケットのストリームを構成

それらはさらに多重化され、さまざまな長さのパケットから成る1本のストリーム(プログラムストリーム)に変換

受信側は多重化されたストリームからそれぞれのストリームのパケットを取り出し、パケットのタイムスタンプを用いて同期させる

55

同期メカニズムの分散化（続き）

同期は送信側・受信側いずれで行うべきか？

送信側で行うと...複数のストリームを、別のデータ単位を持つ1本のストリームにまとめることが可能

ステレオ音声ストリームの例もし送信側が2ch音声を別々に送信し、受信側で同期すると...

それぞれのストリームの遅延は一般に異なるので、同期が極めて困難

送信側で同期させて1つのストリームにしたほうがよい

送信するストリームのデータ単位は2ch音声それぞれのサンプル値の組から構成

受信側は１つのデータ単位を受け取ると、単にそれを左右chに分ければよい

56

2章のまとめ

分散システムにおける通信

従来はトランスポート層のサービスを利用

ミドルウェア層: トランスポート層のサービスを用いて、より高位の通信手段を提供

主な高位の通信手段

RPC(リモート手続き呼び出し）

アクセス透過性を実現

参照渡し(call-by-reference)の実現が困難

RMI(リモートメソッド起動）

遠隔オブジェクトと大域的オブジェクトレファレンスにより参照渡しを容易に達成

57

2章のまとめ（続き）

メッセージ指向通信

RPCやRMIと異なり、非同期の通信手段を提供

永続/一時, 非同期/同期で分類可能

メッセージ指向ミドルウェア (MOM): 一般に永続非同期通信を提供 大規模広域分散システムの構築に役立つ

ストリーム指向通信

連続した２つのメッセージ間に時間制約がある通信（動画ストリーム・音声ストリームなど）

ストリームに対するQoSの定義およびQoS保証メカニズムの実装 一般には困難

58

演習問題

1. 一時非同期受信プリミティブを含む一時非同期通信プリミティブのみ利用可能と仮定する。一時同期通信プリミティブを実現できるか？

2. 逆に一時同期通信プリミティブのみ利用可能な場合、一時非同期通信を実現できるか？[ヒント：複数のプロセスを用いてよい]

3. メッセージ指向ミドルウェアの実装および応用アプリケーションにはどのようなものがあるか調査せよ。

4. 大データ単位長＝1000バイト、トークンバケットレート＝10,000,000バイト／秒、トークンバケットサイズ＝1,000,000バイト、 大転送レート＝30,000,000バイト／秒とする。このときトークンバケットアルゴリズムによって、 大転送レートでのバースト転送は何秒間継続できるか？