アップロードしたら見事にデザインが崩れました。 http://www.amazon.co.jp/gp/product/0132392275/ref=as_li_ss_tl?ie=UTF8&camp=247&creative=7399&creativeASIN=0132392275&linkCode=as2&tag=mezurashinews-22

1. 第二回 Distibuted Systems 読書
会
2013/03/01
資料作成 : 大塚健司
kok.fdcm@gmail.com

2. 今日の目標
• distributed system 上での いろんな
process を見てみましょう。
– thread, process で high-performance を出す仕
組み。
• C/S system でのサーバの問題点に注目
Chapter 3 の冒頭部分
03/04/13

3. 3.1 THREADS
• OS から標準で提供されている Process よりも高
い performance を得るための区分。
• Program を実行するために、 OS は virtual
processor を作る。
• Process table
– OS が Virtual processors を管理するためのもの
– CPU register value, memory maps, etc を格納

4. • Process
– 実行中 Program
– Process 同士は互いに依存することはなく、また干渉
しない。
•Transparent( 高コスト ) - 実現するには多くの場合 H/W のサ
ポートが必要。
• CPU の切り替え、 MMU(memory management unit) の変更、 アドレス
変換テーブルの変更が必要
• Thread
– 他の thread に依存しないように program を実行す
る。
– 互いの干渉を回避するような機構はない。
•Thread-safe はプログラマの配慮
•干渉しない program は作り手にすべて委ねられる。

5. • Multithreaded process in Non-distributed
system
– Ex. Spread Sheet
• バックアップ、描画、計算、入力受付を別スレッ
ドにするとよい。
– もしも Single-Thread の Spread Sheet があったら・・・
» ひとつのセルの値が変わったら、すべてのセルの再
計算が行われるが、その処理が終わるまで描画・入
力ができない。
– Ex. Word Processor
• スペルチェック、入力待ちうけ、ドキュメントレ
イアウトの処理を別スレッドにするとよい。

6. • Ex. Multiprocess
– Process の切替では、一度カーネルモードに
なった後にユーザモードになる必要がある。
• 共有メモリ、メモリマップなどをごっそり書き換
える
thread の切り替えは user mode
のまま行えるため、 multithread
なら performance が向上する。

7. • Thread Implementation (2 approaches)
– User mode で実行される thread library を作る
• Thread の作成・削除は user mode で行われる。
– thread のコントロールに必要な部分だけを扱えばよいの
で低コスト ( メモリ全体の書き換えなどは不要 )
• Thread の切替も簡単
– メモリマップの変更などは不要
• 欠点 : Process が止まったらすべてが止まる
– Light-Weight Processes
• Kernel space で thread をコントロールする process
– Kernel mode になっても プロセス全体は止まらない
• LWP そのものの生成・削除が高コスト、 kernel で
行う

8. 3.1.2 Threads in Distributed Systems
• Thread を使うと、 process 全体をとめな
くても System call できるようになる。
• Multithreaded Clients
– Transparency を高くするためには、 message
の送受信にかかる時間を減らす必要がある。
– http get request
• TCP 接続をした後でデータを一気に読み込み、表
示する。
• 読み込みながら表示している。
• Server も レプリカを同一アドレスで複数設置して
並列処理。

9. • Multithreaded Servers
– multithreading は主に server side で用いられ
る。
– File server
• Dispatcher + worker thread
• Dispatcher が待ち状態の worker thread に処理を
振り分ける。

10. • もしも single thread の file server があったら…
– メインループは Request を受け取ったら、 response
を完遂するまでなにも受け付けない。
– 結果、限られた request しか処理されない。
• Single thread の解決策 : Finite-state machine
• message を処理する server を起動する。
– Server は request を受け取り、キャッシュで処理でき
ればキャッシュを利用し、ディスクを読む必要があれ
ばディスクへメッセージを送る。
– Server はそれぞれの request について状態を保存して
おき、 request が到着したら状態に応じて処理を変え
る。
• 新しい request なら処理開始、 disk からの message なら
response 返却。

11. 3.2 VIRTUALIZATION
• Virtualization
– もともとは、 legacy system を新しい machine の上で
動かすことを想定。 (1970 年代 )
• メインフレームの時代からあった手法。
– 現代では、次々と新しくなる H/W でも動かすために
virtualization 利用できる。
• H/W, low-level software の interface 変更にも対応できる。
– 複数の server を動かす場合 : H/W などに違いがあっ
ても virtualization によって、同じ手順で管理ができ
る。
– 簡単にコピーできる。

12. コンピュータの提供する 4 types of interfaces
•どの PG からも実行できる H/W S/W 間の Machine Instructions
•Kernel 等の特別な PG から実行できる H/W S/W 間の Machine
Instructions
•OS の System Call
•API (System Call を隠蔽する )
Virtualization は、これらの interface を真似ることで実現される。

13. 3.2.2 VM Architecture
Virtualization は 2 つの方法で実装される。
•Run time application – Windows application を
Unix で動かす
– Process virtual machine
•H/W の偽物 interface (convert instruction set)
– この interface は同時に別の PG にも提供され
る
– 複数の異なる OS が、同一 platform で独立し
て同時に動作する。
– Virtual Machine Monitor (VMM)

14. Fig 3-7

15. • VMM
• 信頼性 (reliability) と安全性 (security) の点で重
要度が増してくる。
• 完全なアプリケーションとその環境の分離が
できれば、セキュリティアタック含むエラー
によって、ベースの OS が影響を受けること
はなくなる。
• H/W と S/W の分離、別マシンへの環境の完全
な移行が可能。 (portability)

16. 3.3 CLIENTS
• C/S System における CLIENT について詳し
く見てみる。

17. 3.3.1 Network User Interfaces
• Client の Major Task
– Remote Server との通信方法の提供
• サーバとの通信方法は 2 種類
– Client Service が Server Service と通信
• Remote Server と同期する PDA
– Client が Server Service を利用する (Client は
何も持たない )
• Thin Client
• X Window ( 今はあまり使われない ?)

18. Fig 3-8
PDA 等 THINC 等
注 ) 各レイヤははっきり
と
分けられるものではない
。

19. Ex. X Window System
• X system
– X kernel (X system の core part)
• Capture mouse and keyboard events
– Xlib for application
– Xlib and X kernel communicate in X protocol

20. Ex. X Window System
• Xlib
– Send request to the X kernel for creating or killing a
window, setting colors, cursor, … 表示系の指示
• X kernel
– Keyboard, mouse のイベント ( 入力 ) を Xlib に送信
– Serve display commands to Xlib.
• Xlib uses X kernel’s displaying service
– Server is X kernel, Client is Xlib.
• Problem
– Application と X system の通信が絡み合っている ( 完
全に分離されていない ) ことが多い
• WAN を通した長期間のオペレーションでパフォーマンス低
下

21. Fig 3-9

22. • THINC
– Application からの表示リクエストは、低レベ
ルのコマンドに変換される。
– THINC 自身が常に update コマンドを送信し
続けることで、 Application の Display 処理を
なくした。 (Xlib のように application 側で実
装する必要がない。 )

23. • Compound Documents
– ファイル ( テキスト、画像、 ...) の取り扱い
– UI: 別の Application が Compound Document
の別の部分を使用しているという事実を隠す
• ユーザには、一つの File として問題なく扱えてい
るように見せる。
• 別 Application の変更によって不整合が起こる場合
は適切な対応をする (Application にメッセージを出
すなど ) 。
• PG は複雑になる。
• Ex. あるエディタで変更 -> 使用中の別のエディタ
でも表示が変更される。

24. 3.3.2 Client-Side Software for
Distribution Transparency
• Client Software は distribution の透過性を実
現するようにできている。
• 理想的には、透過的にアプリケーション
が作られるべきだが、多くの場合透過的
ではなくなる。 => Chapter 6 で例を見る。
• Server と通信中なら ...
– server の場所が変わったら、 server から
client に通知する。 client の S/W は server の
場所が変わったことを user に悟られないよう
に振舞う。

25. Fig 3-10
• Repliation Transparency
• 透過性は Client-Side で実装
• Replication request を各 Server に送信するが
、 User には request が 1 つのように見せる

26. • Failure Transparency
– Client Middleware によって Client Server 間の
通信エラーは隠蔽される。
• 1 度失敗したらももう一度 Server に Access する
。
• 何度か失敗したら別の Server に Access する。
• Web Browser で、 Server に繋がらない場合に、前
回の Cached Data を表示する。

27. • Concurrency Transparency
– 特別な中間サーバによってコントロール
• トランザクションモニタ
– Client S/W のサポートはあまり必要としない
• Persistency Transparency
– Server で実装されることが多い。

28. 3.4 Servers
• A Server is a Process
– 複数の Client に代わって処理をする。
– 各 Server は同じやり方で構成される。
• Client からの request を待ち受ける。
• Request を処理する。
• 次の request を待ち受ける。

29. 3.4.1 General Design Issues
• Iterative Server
– Server 自身が request を処理し、 response
を返す。
• Concurrent Server
– Request の処理は別の Thread/Process が行う
。
– Multi Threaded Server
• Request 毎に process を作成して処理する。 ( 多
くの UNIX でのパターン。 )

30. • Where clients contact a server?
– Client sends request to an end point (specific port).
– Well-known port は Internet Assigned Numbers
Authority によって決定されている。
• Ex. Service without preassigned end point
– Time-of-day Service
• Server Process の End Point は同的に決定されるため一定で
ない。
• 待ち受け専用の daemon を特定の port で起動。
• Request があったら、 Server Process へ Access
– Inetd

31. • Whether and how a server can be interrupted?
– Uploading a big file to FPT server
• User が不正ファイルだと気付いた場合、 User は Client Soft
を Close -> Server は connection の切断を検知して操作を中
断 ( なかったことにする ) 。
– Out-of-band data ( 帯域外データ ): Client から送られて
きた data よりも優先して Server で処理されるデー
タ
• Server で Client から送信される out-of-band data を別 port
で監視する。
• 通常 data と out-of-bound data を同じ port で一緒に扱う。
• 使われ方 : out-of-band data として Urgent data/signal が
送信されたらその後の通信を abort する。

32. • Is whether or not the server stateless?
• Stateless server
– not keep information of the state of the clients
– Can change own state without informing any client
– Ex. Webserver
• Request の処理が終わると、 server は client との一切の関係を捨
てる。
• Server 内の files は client に通知することなく変更可能。
– 多くの場合、 Web Server の Log のように Clients’ information
を保持するが、そういったものは仮に消失しても Service には
影響がない。
• Soft-state approach
– Server maintains behalf of the client for limited time
– Ex. Update server

33. • Stateful server
– Maintains persistent information on its clients
– Ex. File Server allowing clients to keep a local copy
• Needs to recover entire state after crashing
• session state と permanent state の区別
– Session state
• single user による処理結果であり、 しばらくの間保持されるもの。
• よく変更される。
• 消失した場合は、 Client から再接続。
– Permanent state
• database の顧客データなど。
• Issue: durability of the server
• 他の方法
• Cookie
• Server では保存しない。 Client は保存するだけでそれ自体使わない
。

34. 3.4.2 Server Clusters (LAN with high
bandwidth and low latency)
• General organization
– server cluster
• network で結合された machine の集合体
• 各 machine が 1 つ以上の Server を実行している
。
• General pattern

35. • 構成
– 2-tier, 3-tier などさまざま。
– それぞれの machine が local storage を持つ場
合もある。
• Cluster 内のある machine が idle 状態で
、別の machine が busy 状態のとき
– switch が動的に Migration を行って資産を活
用
• Fig 3.4: Example of Access Transparency
– Switch は request を server に渡す
が、 header 情報は Switch のままにして、再
び Client が Switch に access するようにし
ている。

36. • Distributed Servers
– Use several access points
• DNS: DNS を探しまわればいい。ただし ある access point に
access できなくなることがある。 (not static)
• MIPv6
– A mobile’s home network address: HoA
» 通信時に使用する。
– 特殊 router: Home Agent
» Mobile node が遠くに行った場合に、 mobile node への
access を処理する。
– Temporary Care of Address: CoA
» Mobile node が外の network に入った時に通知される
address
» Home agent に通知される。
» 通信時には使用しない。
– A single unique contact address
» Server Cluster の address( 不変 )
» 外部との通信に使用する。
36

37. • ルート最適化 (route optimization)
– 異なる clients が一つの server を介して通信
をしているように見せかける。

38. 3.4.3 Managing Server Clusters
• Common Approach
– 1 つの computer に対して行っていたことを
複数の computer に対して行う。
– 管理用の interface を通して管理を行う。
– ただし computer 1000 台それぞれが 0.1% の
確率で故障すると仮定すると、すべての
computer が正常に動く確率は 36% 。
• Massive system を扱う系統的な方法はない
。
• Cluster management はまだ始まったばか
り。

39. • Ex. PlanetLab
– 複数の企業がお金を出して Cluster を構築する
。
– 1-tier server cluster
– 1 つの node はそれ自体 cluster になれる。
– それぞれの vserver は独立して動く。
VMM

40. • Slice
– A set of vservers (virtual server cluster)
• PlanetLab の問題点
– 各 Node は異なる組織に所属する。各組織がそれぞ
れどの node のどの application の実行権限、 access 権
限を持つのか適切に設定する必要がある。
– 様々な monitoring tool があるが、どれも特定の
H/W, S/W の組み合わせでしか動作が保障されていな
い、また 1 つの組織で使うことが前提になっている
。
– 同じ node の異なる slice 上で動く application が干
渉してはならない。

41. 3.5 Code Migration
• 概要
– Process が、読み込みの多い machine から読
み込みの少ない machine に移れば system 全
体の performance が向上する。
– Flexibility( 柔軟性 )
Client は最初の時点で program
を setup しておく必要はない。
必要になった時にある場所から
download して server と通信を
行う。
必要がなくなったら program
を捨てるようにしておけば、 通
信プロトコルの変更なども柔軟
に行える。

43. • Process
– Code segment
• 実行されているプログラムの命令セット
– Resource segment
• ファイル、プリンタなど外部リソースへの参照
– Execution segment
• プロセスの状態、変数の値、スタックなど
• Weak mobility
– Code segment だけを移す。
– Java applet はブラウザで読み込まれブラウザのアドレ
ス空間内で完結。ただし実行環境の resource を守る
ための security が必要。
• Strong mobility
– Code segment, execution segment を移す。
– 一旦止めて別環境へコピーした後再開する。
– 実装は難しい。

44. • Sender-initiated
– Upload のように、送信側から開始。
– Sender を登録しておくなど、 security 対策が
必要
• 変なものを upload されると困る。
• Receiver-initiated
– Java Applet のように、受信側から要求を出し
て開始する。
– Sender-initialized migration より簡単。
• Clone process
– Remote machine が元の process を copy して
実行。

45. 3.5.2 Migration and Local Resources
• Resource segment は特別に注意が必要
– 変更されないままの状態で移して動かすのが難しい。
• 参照している TCP port は別 machine で同じように参照しても通信
を継続できない。
• URL 指定でファイルを参照している場合は弊害なし。そのまま移し
ても問題ない。
• 3 types of process-to-resource binding
– Binding by identifier
• URL など絶対固定のものを PG で使用。
– Binding by value
• ライブラリなどの内部は多少違っても、同じ値さえ出せれば同じよ
うに動く。
– Binding by type
• モニタ、プリンタといった、型で指定して PG 内で使っている。

46. • Migration では、 resource への参照を変える必要が
出てくるが、 binding に影響を与えてはならない。
• リソースの種類
– Unattached resources
• 簡単に移せる
• 移される data は、 PG からしか使われていない。
– Fastened resources
• 移すのは高コスト
• Local DB や Web Site 。ただ移すだけでは実行不可能かもしれない。
– Fixed resources
• 移せない
• ポートなど

47. 3.5.3 Migration in Heterogeneous
Systems
• VM の migration
– 問題
• 完全な memory の migration
• Local resources への参照
– 3 つの方法
• メモリページを新しいマシンに写し、 migration 中
が終わった後でもう一度新しいマシンに移す。
• VM を停止して移し、再開する。
– ダウンタイムに注意。
• 新しいリクエストがきたら新しいマシンで対応す
る。
– 時間がかかる。