Distribution Strategies
- 分散コンピューティング
- オブジェクトを分散させるな
The Allure of Distributed Objects
- 分散オブジェクトの誘惑
- 「1ノード1オブジェクト」をしたくなる
-
なぜしてしまうのか
-
パフォーマンス目的
- ロードバランシング
-
-
「その設計はクソだよ」と言って追い出されてしまうか
-
原文: sucks like an inverted hurricane
- ハリケーンは普通、遠心力で外側に流れる
- その逆なので、内側に吸い込むハリケーン
- それくらいめっちゃsuckだ、ということ
-
- 正道を時間をかけて示すか
-
後者のほうが儲かるが骨が折れる
- オブジェクト分散デザインが大好きな人たちを説得するのは大変
- なぜオブジェクト分散デザインはクソなのか
-
分散オブジェクトのツール(ミドルウェアとか)のベンダの甘言
-
透過性
- 「プロセス内だろうがプロセス間だろうが変わらず呼び出せます」
-
-
でもパフォーマンスは透過的じゃない
- ノードをまたぐと遅くなる
- パフォーマンスのために分散システムにしたのに
- ビルドとデプロイも容易でなくなる
Remote and Local Interfaces
- クラス単位での分散がうまくいかない主たる理由
-
コンピューターの基本的な事実
- プロセス内でのプロシージャコールはめっちゃ速い
- プロセス間でのプロシージャコールは桁違いに遅い
-
別マシンのプロシージャコールはさらに1-2桁遅くなる
- ネットワーク依存
- リモートコールされるオブジェクトと、同一プロセス内で呼び出されるオブジェクトとではインタフェース設計が変わってくる
-
同一プロセス内
- 古典的なデザインパターンがそのまま適用される
-
細かい粒度のインタフェースが正義
- fine-grained interface
-
例: 住所クラス
- getCity()
- getState()
- setCity()
- setState()
-
リモート
- プロシージャコールが遅いので、なるべく回数を少なくしたい
-
パフォーマンスのためにcoarse-grained interfaceが必要になる
- 例: city,state,zipをまとめて取得/更新
- 柔軟性や拡張性は犠牲
-
ツールベンダは「オーバヘッドはありません」と言う
- ローカル呼び出しはローカル呼び出し相応の速さが得られる
- リモートプロシージャコールがローカル呼び出しほど速くなるという意味ではない
- だからリモート呼び出しだけパフォーマンス面をケアすればよい?
- しかしそれではfine-grained interfaceとcoarse-grained interfaceが混ざってしまう
-
2つのオブジェクトが連絡するたびにいずれかのインタフェースの選択を強いられる
- プロセス間通信ならcoarse-grained
- 柔軟性・拡張性を欠くためプログラムが大変になる
- First Law of Distributed Object Design: オブジェクトを分散させるな
- じゃあどうするか
-
アプリケーションをクラスタリングせよ
- すべてのクラスを1つのプロセスに入れてプロセスのコピーを複数ノードに複製する
-
プロシージャコールはプロセス内ローカルで行われる
- 速い
-
普段通りfine-grained interfaceで設計できる
- 保守性よい
Where You Have to Distribute
-
プロセスを分けねばならないケースがある
- Client-Server構成
- Server-DBMS
- Webサーバ-アプリケーションサーバ
-
有り物のソフトウェアパッケージを使う場合
- 別プロセスで動くことしばしば
-
本当に必要なケース
-
必要性を祖父母を納得させてからやれ
- やるな、ってこと
- どうしてもやることになったら、鼻をつまみながら、coarse-grainedでリモートに配置
-
Working with the Distribution Boundary
- 分散システムの境界はなるべく制限する必要がある
-
Remote Facade
- 分散システムの境界にcoarse-grainedなオブジェクトを据える
- プロセス内部のfine-grainedなオブジェクトに処理を委譲するだけのオブジェクト
-
coarse-grainedなインタフェースがリモート呼び出しを明示してくれる
- 透過性には反する
- が、潜在的なリモートコール(によるパフォーマンス低下)は隠蔽してほしくない
-
DTO: Data Transfer Object
- an objct that carries data between processes in order to reduce the number of method calls.
-
coarse-grainedなオブジェクトをリモート間で伝送する
- Addressならcity,state,zipをまとめて1かたまりで伝送
- リモートコールの回数を少なくする
- リモートの彼岸・此岸両方で使う
-
ので、プロセス内部のオブジェクトへの参照をもたぬこと
- 彼岸で使えなくなるから
-
例外
- 他のDTO
- スカラ型
-
Lazy Load
- An object that doesn’t contain all of the data you need but knows how to get it.
- GoFのVirtual Proxy的な
- プロセス間のオブジェクト伝送を仲介
Interfaces for Distribution
-
リモートプロシージャコール
- 広域のプロシージャ
- オブジェクトのメソッド
-
XML over HTTP <- new!
-
SOAP: Simple Objct Access Protocol
- メッセージ記述: XML
- 伝送: HTTP
-
-
XML over HTTPの利点
-
XML
-
構造化フォーマットである
-
リモートコールを減らす上で好適
- 【補】DTOの(デ)シリアライズが容易ということか
-
-
一般的なフォーマットである
- さまざまなプラットフォームでパーササポート
-
テキストであること
- 彼岸/此岸でワイヤーをまたいで何が起きているか理解しやすい
-
-
HTTP
- 政治的な理由でポートを開けづらくてもHTTPは開けて貰えやすい
-
-
オブジェクトのメソッドコールの利点
- XMLのパースとか無い
- 通信する2つのシステムが同一のプラットフォームでビルドされたものならば、
ビルトインのリモートコールの仕組みを使うのが良い - cf. 異なるプラットフォーム間ならXML over HTTP
-
OOのインタフェースをHTTPのインタフェースでラップすれば両対応できる
- 【補】今日「Web API」と呼ばれているヤツか
-
ただし複雑性を生む
- Webサーバが新たに必要
- 同期RPCを前提に話をしてきた
-
非同期のメッセージベース通信使え
- メッセージベース設計は大きなトピックなので避ける
英語
- ple in general.
-
cozy
- こぢんまりとした
-
brochures
- A small book or magazine containing pictures and information about a product or service.
- パンフレット
-
allure
- The quality of being powerfully and mysteriously attractive or fascinating.
-
recur
- Occur again periodically or repeatedly.
-
out and out
- 徹底的に
-
show the door
- 出ていかせる
-
get shown the door
- 追い出される
-
remunerative
- Financially rewarding; lucrative.
-
lucrative
- Producing a great deal of profit.
-
cripple
- Cause (someone) to become unable to walk or move properly.
-
the rub
- The central problem or difficulty in a situation.
-
like a cornered rat
- 窮鼠のごとく
-
genuine
- Truly what something is said to be; authentic.
-
parsimonious
- Very unwilling to spend money or use resources.
-
duck out of
- [informal] [with object] Evade or avoid (an unwelcome duty or undertaking)
-
urge
- [with object and usually infinitive] Try earnestly or persistently to persuade (someone) to do something.