|
0
|
1 \chapter{分散フレームワーク Alice の概要} \label{chapter:chapter1}
|
|
2
|
2 Aliceは、本研究室で開発を行っている分散タスク管理フレームワークである。Cell用のOpen CLに似たTask管理フレームワークCeriumとLindaを相互に接続した分散フレームワークであるFederated Lindaの開発を通して得られた知見が生かされている。
|
|
1
|
3
|
|
2
|
4 Ceriumでは、Taskを小さく分割して並列実行し、データ転送はパイプライン実行により隠される。Task間に依存関係があるが、実際にはデータの依存関係がそのままTaskの依存関係になることが多い。繰り返し使われるデータ構造の管理が重要であり、実行時にわかるデータ構造間の依存関係がTaskを複雑にしている。
|
|
|
5
|
|
|
6 Federated Lindaでは、Lindaサーバ内部にMeta Engineと呼ばれるLindaのタプル(データ構造)をやり取りする部分を作成した。Meta Engineでは、タプルのやり取りによって起動するcall backを使うが、call backによる記述が分散してしまい、可読性を落としてしまう。また、複数のタプルの待ち合わせが重要だが、その待ち合わせはsingle threadedなMeta Engine内部の状態に依存する。
|
|
|
7
|
|
|
8 これらが示しているのは、並列分散実行はコードの並列実行だけでなく、データの単位が重要だということである。そこで、AliceはData SegmentとCode Segmentという単位でデータと処理を細かく分割し、それぞれの依存関係を記述して分散プログラムを作成する。Code SegmentはContinuation based Cの実行単位であり、その双対がData Segmentである。
|
|
|
9
|
|
|
10 Data SegmentはCode Segmentと分離されたデータ構造であり、オブジェクトではない。オブジェクト指向プログラミングが状態を複雑に持ち、並列実行や分散実行に向かないことは徐々に理解されてきている。一方で、状態自体は有限状態遷移機械(Finite State Machine/FSM)で記述するのが自然である。Code Segmentは状態遷移記述そのものであり、その状態遷移はData Segmentの到着によってトリガーされる。
|
|
|
11
|
|
|
12 カプセル化されたデータをプロセスがやり取りするのは、DFD(Data Flow Diagram)の古典的な手法であり、それ自体は新しくはない。むしろ、メインフレーム上でのソフトウェア開発に良く使われてきた手法である。Alice では、それを再実装する。
|
|
|
13
|
|
|
14 AliceはCode SegmentとData SegmentをJavaとMessage Packで実装したフレームワークである。Topology Managerを持ち、Blade上での
|
|
|
15 分散プログラムの実験を容易に行うことができる。また、SEDA Architectureを採用しており、マルチコア上でのスループットの向上を期待している。
|
|
1
|
16
|
|
|
17 \section{Data Segment}
|
|
|
18 Data Segmentはデータを細かく分割したものであり、数値や文字列などのデータを構造的に保持する。AliceはData Segmentをデータベースとして扱っている。Data Segmentには必ず対になるKeyが存在する。つまりKey Value Storeとして考える事ができる。
|
|
|
19
|
|
|
20 Aliceのデータベースは通常のKVSとは異なっている点がある。通常のKVSはプログラミング言語の連想配列やMapと同様に 「Key（キー）」と「Value（値）」がペアとなっている。そのため1つのKeyに対して値は1つである。しかし、Aliceの場合は「Key」と「Queue」がペアとなっているため、Keyに対して複数回putできる。従って取得できるValueも複数存在できる。便宜上これをKey Value Queueと呼ぶものとする。Key毎の追加と取得はLindaに準じた設計になっている。
|
|
|
21
|
|
|
22 Data SegmentはData Segment Manager（以下DSM）によって管理されている。ノード毎にLocal DSMとRemote DSMが存在する。Local DSMは各ノード固有のKVSとなっている。従ってRemote DSMを指定するKeyはノード内部でuniqueなものである。Remote DSMは他のノードのLocal DSMのproxyと考えられる。つまりRemote DSMは複数存在し、それぞれに対応するノードは異なる。
|
|
|
23
|
|
2
|
24 \begin{figure}[htbp]
|
|
|
25 \begin{center}
|
|
|
26 \includegraphics{images/remote_datasegment.pdf}
|
|
|
27 \end{center}
|
|
|
28 \caption{Remote DSMは他のノードのLocal DSMのproxy }
|
|
|
29 \label{fig:RemoteDSM}
|
|
|
30 \end{figure}
|
|
|
31
|
|
1
|
32 KVQへのアクセスはqueueによって、ノード内部で逐次化される。それ以外は、すべてJavaのThread Poolにより並列実行される。
|
|
|
33 \subsection{Data Segment API}
|
|
|
34 以下が用意されているData Segment APIである。これらを用いてデータの送受信を行う。
|
|
|
35 \begin{itemize}
|
|
|
36 \item {\ttfamily void put(String key, Object val)}
|
|
|
37 \item {\ttfamily void update(String key, Object val)}
|
|
|
38 \item {\ttfamily void peek(Receiver receiver, String key)}
|
|
|
39 \item {\ttfamily void take(Receiver receiver, String key)}
|
|
|
40 \end{itemize}
|
|
|
41 \subsubsection{put}
|
|
2
|
42 putはデータをQueueに追加するためのAPIである。Lindaのout()に相当する。(図 \ref{fig:put})
|
|
|
43 \begin{figure}[htbp]
|
|
|
44 \begin{center}
|
|
|
45 \includegraphics[width=100mm]{images/put.pdf}
|
|
|
46 \end{center}
|
|
|
47 \caption{queueにデータを追加する}
|
|
|
48 \label{fig:put}
|
|
|
49 \end{figure}
|
|
|
50
|
|
1
|
51 \subsubsection{update}
|
|
2
|
52 updateはデータを置き換える特急メッセージのように動作する。Lindaのupdate()に相当する。(図 \ref{fig:update})
|
|
|
53 \begin{figure}[htbp]
|
|
|
54 \begin{center}
|
|
|
55 \includegraphics[width=100mm]{./images/update.pdf}
|
|
|
56 \end{center}
|
|
|
57 \caption{update"は先頭データを取り除き、queueにデータを追加する}
|
|
|
58 \label{fig:update}
|
|
|
59 \end{figure}
|
|
|
60
|
|
1
|
61 \subsubsection{peek}
|
|
|
62 peekはデータを読み込むAPIである。読み込まれたデータはQueueに残る。要求したデータが存在しなければ、Code Segmentの待ち合わせ （Blocking）が起こる。putやupdateによりデータに更新があった場合、peekが直ちに実行される。Lindaのread()に相当する。
|
|
|
63 \subsubsection{take}
|
|
|
64 takeもデータを読み込むためのAPIである。読み込まれたデータはQueueから削除される。Lindaのin()に相当する。
|
|
|
65 \subsection{Data Segment の表現}
|
|
2
|
66 Data Segmentの表現にはMessage Packを利用している。Message Packに関してJavaにおけるデータ表現は以下の3種類があり、制限を伴うが互いに変換可能である。
|
|
|
67 \begin{itemize}
|
|
|
68 \item {\ttfamily 一般的なJavaのクラスオブジェクト}
|
|
|
69 \item {\ttfamily MessagePack for JavaのValueオブジェクト}
|
|
|
70 \item {\ttfamily byte[]で表現されたbinary}
|
|
|
71 \end{itemize}
|
|
1
|
72
|
|
2
|
73 Data Segment APIの内部においてデータは、一般的なJavaのクラスオブジェクトまたはbyteArrayで表現されたbinaryで表現されている。
|
|
|
74 Localからデータがputされた場合は一般的なJavaのクラスオブジェクトの状態でenqueueされる。RemoteからデータがputされるとbyteArrayで表現されたbinaryの（シリアライズされた）状態でenqueueされる。
|
|
|
75
|
|
|
76 ユーザーが一般的なクラスをIDL(Interface Definition Language)のように用いてデータを表現することができる。
|
|
|
77 この場合、クラス宣言時に@Messageというアノテーションをつける必要がある。もちろん、MessagePackで扱うことのできるデータのみをフィールドに入れなければならない。
|
|
|
78
|
|
|
79 Remoteに対してputできるデータは、@MessageをもつクラスオブジェクトかMessage Packで扱える型に限られる。
|
|
|
80
|
|
1
|
81 \section{Code Segment}
|
|
|
82 Code SegmentとはAlice上で実行されるタスクの単位である。ユーザーはCode Segmentを組み合わせることでプログラミングを行う。Code Segmentをユーザーが記述する際に、内部で使用するData Segmentの作成を記述する。入力時のData SegmentをInput Data Segment、出力時をOutput Data Segmentと呼ぶ。Input Data SegmentとOutput Data SegmentによってCode Segmentの間の依存関係が自動的に記述される。
|
|
|
83
|
|
|
84 Input Data Segment と Output Data SegmentはCode Segmentに用意されているAPIを用いて作成する。
|
|
|
85 Input Data Segmentは、LocalかRemoteか、またkeyを指定する必要がある。Code Segmentは、記述したInput Data Segmentが全て揃うとThread poolに送られ、実行される。
|
|
|
86
|
|
|
87 Out Data SegmentもLocalかRemoteか、またkeyを指定する必要がある。
|
|
|
88
|
|
|
89 現在、Inputの場合はsetKeyを呼ぶ際、Outputはput(またはupdate)の際にノードとkeyの指定を行っている。
|
|
|
90 しかし、どの時点でノードとkeyの指定を行えばよいか、どのようなAPIを用意するべきかは、議論の余地がある。
|
|
2
|
91 \section{Meta Data Segment}
|
|
0
|
92 \section{Meta Code Segment}
|
|
1
|
93
|
|
|
94 \section{Topology Manager}
|
|
2
|
95 Aliceは複数のノードで構成され、相互に接続される。通信するノードはURLにより直接指定するのではなくTopology Managerで管理する。
|
|
|
96 Topology Managerはトポロジーダイルを読み込み、参加を表明したクライアント(以下、Topology Node)に接続するべきTopology NodeのIPアドレス、ポート番号、接続名を送りトポロジーファイルに記述されたとおりにトポロジーを作成する。(図\ref{fig:topologymanager})
|
|
|
97
|
|
|
98 \begin{figure}[htbp]
|
|
|
99 \begin{center}
|
|
|
100 \includegraphics{images/topologymanager.pdf}
|
|
|
101 \end{center}
|
|
|
102 \caption{Topology Manager はトポロジーファイルの記述に従ってトポロジーを生成する}
|
|
|
103 \label{fig:topologymanager}
|
|
|
104 \end{figure}
|
|
|
105
|
|
|
106 Code Segment内部でRemote DSMにアクセスする場合はToplogyManagerによって指定されたノード内部だけで有効なlabel(文字列)を使う。これにより特定のURLがCode Segment内部に記述されることを防いでいる。
|
|
|
107 \subsection{トポロジーファイルの記述方法}
|
|
|
108
|
|
|
109 Topology Managerが読み込むトポロジーファイルは Languageと呼ばれる言語で記述する。
|
|
|
110 DOT Languageはプレーンテキストを用いてデータ構造としてのグラフ構造を表現するデータ記述する言語の一種である。
|
|
|
111 このDOT Languageを用いてクライアント間の接続を表現する。
|
|
|
112
|
|
|
113 クライアント間の接続はlabelを用いて名前が割り振られている。この接続名を指定することでユーザーは他のノードのRemote Data Segmentにアクセスすることができる。ReceiverにsetKeyを行う際、odsでput、updateする際のmanagerKeyがlabelである。(図\ref{fig:ring})
|
|
|
114
|
|
|
115 \begin{table}[htbp]
|
|
|
116 \lstinputlisting[label=ring, caption=3台でリングを組んだ時の例]{source/ring.dot}
|
|
|
117 \end{table}
|
|
|
118
|
|
|
119 テキストのみではユーザーが望む形のトポロジーかどうかを判断しにくい。ノードの数が少なければ、可能であるがノードの数が増加するに連れて困難になるが、dotコマンドを用いることでその問題を解決することができる。
|
|
|
120 dotコマンドでトポロジーファイルを画像として出力することができるので、記述したトポロジーが正しいことを可視化して判断することができる。
|
|
|
121
|
|
|
122 \begin{figure}[htbp]
|
|
|
123 \begin{itemize}
|
|
|
124 \item {\ttfamily dot -T png ring.dot -o ring.png}
|
|
|
125 \end{itemize}
|
|
|
126
|
|
|
127 \begin{center}
|
|
|
128 \includegraphics{images/ring.pdf}
|
|
|
129 \end{center}
|
|
|
130 \caption{dotコマンドで作成された3台で構成されたリングのグラフ}
|
|
|
131 \label{fig:ring}
|
|
|
132 \end{figure}
|
|
1
|
133
|
|
|
134 \section{Aliceによるプログラミング手法} |
