|
20
|
1 \documentclass[twocolumn, a4j, twoside]{jarticle}
|
|
|
2 \usepackage{master_proc}
|
|
|
3 %\usepackage[dvips]{graphicx}
|
|
|
4 \usepackage[dvipdfm]{graphicx}
|
|
|
5
|
|
|
6 % dvipdfm を使って PDF ファイルに日本語の栞をつける
|
|
|
7 % \usepackage[dvipdfm]{color}
|
|
|
8 % \usepackage[dvipdfm,bookmarks=true,bookmarksnumbered=true,%
|
|
|
9 % bookmarkstype=toc]{hyperref}
|
|
|
10
|
|
|
11 \jtitle{分散プログラミングモデル Federated Linda と 分散デバッグ} %和文タイトル
|
|
|
12 \etitle{Distributed Programming Model : Federated Linda and Distributed debugging}%英文タイトル
|
|
|
13 \author{渕田 良彦} %著者名
|
|
|
14 \studentid{068514D} %学籍番号
|
|
|
15 \teacher{河野 真治} %指導教官
|
|
|
16
|
|
|
17 \begin{document}
|
|
|
18 \maketitle
|
|
|
19 \section{はじめに}
|
|
|
20 並列・分散環境におけるプログラミングは、今後ますますその重要性が高まっていくと考えられる。
|
|
|
21 しかし、分散プログラム開発において、スケーラビリティを確保することは難しい。
|
|
|
22 スケーラビリティとは、参加ノードの数が小規模から大規模に変化しても性能が劣化しない
|
|
|
23 という性能基準のことを示す。
|
|
|
24 %スケーラビリティ等を確保したまま、分散プログラムを正しく記述することやデバッグ
|
|
|
25 %を行う為に、これまで多くの分散プログラミングモデルが開発されてきたが、それらは
|
|
|
26 %遂次プログラミングモデルの延長であったり、アプリケーション開発者が複雑で理解しにくい
|
|
|
27 %記述を熟知しなければならなかった。
|
|
|
28 そこで本研究室では、自然にスケールする分散プログラミン
|
|
|
29 グモデルを提供することを目的として Federated Linda を開発した。
|
|
|
30 Federated Lindaは実験的に分散アルゴリズムを実装し、そのスケーラビリティを測る
|
|
|
31 ことができる分散プログラミングモデルである。
|
|
|
32
|
|
|
33 本研究では、本研究室で開発した分散プログラミングモデル Federated Linda を用いた
|
|
|
34 分散アルゴリズムの記述事例として、Compact Routing の実装を行い、
|
|
|
35 その開発によって得られた知見から本モデルに必要な機能の拡張を提案する。
|
|
|
36 本モデルへの機能拡張としてまず最初の段階で、Federated Linda の実装をC言語から
|
|
|
37 Java言語へと移行した。その上で、分散デバッグ機能について検討を行い、
|
|
|
38 実際に分散デバッグ機能を実装する。
|
|
|
39 実装した分散デバッグ機能の評価として、Federated Linda での
|
|
|
40 分散アルゴリズムにおけるバグの特定を行い、その有用性を示す。
|
|
|
41 \section{Federated Linda}
|
|
|
42 Federated Lindaは本研究室で開発された非同期型Lindaで構築される。
|
|
|
43 非同期型Lindaは、タプルというデータ単位をネットワーク上の「タプル空間」に
|
|
|
44 出し入れする事で通信を行うLindaという通信モデルを用い、その通信を、明確な
|
|
|
45 待ちを行わない非同期的な通信によって行う。しかし、集中型の通信を行う
|
|
|
46 非同期型Lindaはスケーラビリティをもたない。そこで、複数のタプル空間を接続し、
|
|
|
47 ノード間にてタプルを中継させる分散モデルとしてFederated Lindaを提案する。
|
|
|
48 これによって、通信の集中型モデルから脱し、スケーラビリティを得る。
|
|
|
49 また、分散プログラムにおける構成要素を、３つに分離することで、各要素毎に
|
|
|
50 切り替えが可能となり、ポータビリティが向上する。
|
|
|
51
|
|
|
52 ３つに分離されるFederated Lindaの構成要素には以下の３つがある。
|
|
|
53 {\small
|
|
|
54 \begin{verbatim}
|
|
|
55 Local Access Protocol
|
|
|
56 ・'in','read','out'といったLindaのAPI、ユーザープログラ
|
|
|
57 ムからの通信、プロトコルへのアクセス
|
|
|
58 Protocol Engine
|
|
|
59 ・分散アルゴリズムを内包するエージェントプログラム、タプル
|
|
|
60 空間から別ノードのタプル空間へとタプルを転送する
|
|
|
61 Link Configuration
|
|
|
62 ・タプル空間やProtocol Engineの接続をXMLで表し、そのXML
|
|
|
63 に沿ったコネクション確立処理を行う
|
|
|
64 \end{verbatim}
|
|
|
65 }
|
|
|
66 Federated Lindaでは、玩具的に分散アルゴリズムを実装し、実験する事が可能であり、
|
|
|
67 その教育的な利用も考えられる。
|
|
|
68
|
|
|
69 \section{Compact Routingの実装と評価}
|
|
|
70 Federated Lindaにおける分散アルゴリズム、つまりProtocol Engineの実装として
|
|
|
71 Distance Vector Routingの実装が先行研究[1]によって行われた。これは、自ノードから
|
|
|
72 宛先ノードまで、距離が最短のルーティングを行う分散アルゴリズムであるが、ネットワーク
|
|
|
73 が複雑になるほど経路の情報量が増え、スケーラビリティに劣ると考えられた。よって
|
|
|
74 今回、階層型ルーティングを用いた、ルーティングテーブル収束速度や、ネットワーク
|
|
|
75 のスケーラビリティに対して優位な分散アルゴリズムである'Compact Routing'[3]の実装を
|
|
|
76 行った。
|
|
|
77
|
|
|
78 評価としてDistance Vector RoutingとCompact Routingそれぞれにおけるルーティングテーブル構築
|
|
|
79 時間の比較を行い、表\ref{routingtime}に示す結果となった。
|
|
|
80 \vspace{-7mm}
|
|
|
81 \begin{table}[htbp]
|
|
|
82 \begin{center}
|
|
|
83 \caption{ルーティングテーブル構築にかかる時間}
|
|
|
84 \label{routingtime}
|
|
|
85 {\small
|
|
|
86 \begin{tabular}{|c|c|c|}
|
|
|
87 \hline \hline
|
|
|
88 \multicolumn{3}{|c|}{Compact Routing} \\
|
|
|
89 \hline
|
|
|
90 トポロジ & ノード数 & かかった時間(sec)\\
|
|
|
91 \hline
|
|
|
92 Line & 10 & 1.19 \\
|
|
|
93 \hline
|
|
|
94 Tree & 10 & 2.40 \\
|
|
|
95 \hline
|
|
|
96 Line & 20 & 5.18 \\
|
|
|
97 \hline
|
|
|
98 Tree & 20 & 6.95 \\
|
|
|
99 \hline
|
|
|
100 Line & 30 & 7.56 \\
|
|
|
101 \hline
|
|
|
102 Tree & 30 & 26.26 \\
|
|
|
103 \hline \hline
|
|
|
104 \multicolumn{3}{|c|}{Distance Vector Routing} \\
|
|
|
105 \hline
|
|
|
106 トポロジ & ノード数 & かかった時間(sec)\\
|
|
|
107 \hline
|
|
|
108 Line & 10 & 2.66 \\
|
|
|
109 \hline
|
|
|
110 Tree & 10 & 4.54 \\
|
|
|
111 \hline
|
|
|
112 Line & 20 & 89.66 \\
|
|
|
113 \hline
|
|
|
114 Tree & 20 & 29.91 \\
|
|
|
115 \hline
|
|
|
116 Line & 30 & 8634.50 \\
|
|
|
117 \hline
|
|
|
118 Tree & 30 & 127.55 \\
|
|
|
119 \hline
|
|
|
120 \end{tabular}
|
|
|
121 }
|
|
|
122 \end{center}
|
|
|
123 \end{table}
|
|
|
124 \vspace{-8mm}
|
|
|
125
|
|
|
126 比較の結果、Distance Vector Routingではルーティングテーブル構築時間が、ノード
|
|
|
127 数の増加に対して大幅に増加する結果となったのに対し、Compact Routingでは、
|
|
|
128 階層型ルーティングを用い、ノード数の増加に対するルーティングテーブルのサイズや、
|
|
|
129 更新量を抑えることによってルーティングテーブルの構築時間が短くなる事を確認できた。
|
|
|
130 以上の結果より、Compact RoutingはDistance Vector Routingよりもスケーラビリティに
|
|
|
131 優れる分散アルゴリズムであると言える。
|
|
|
132 \vspace{-6mm}
|
|
|
133 \subsection{問題点}
|
|
|
134 今回の評価実験において、Distance Vector RoutingとCompact Routingの両実装を
|
|
|
135 格子状のメッシュ型トポロジにおいて用いた所、何らかのバグが原因と考えられる
|
|
|
136 問題点が明らかとなった。しかし、当時のFederated Lindaにおける開発環境が、多数の
|
|
|
137 ターミナルによって全プロセスを起動するテスト駆動開発であり、それらに対して逐次的
|
|
|
138 デバッグを行うことではバグ要因を特定する事は困難であった。
|
|
|
139
|
|
|
140 よって、Federated Lindaの機能を拡張し、分散プログラム開発に適した'分散デバッグ機能'を
|
|
|
141 実装することを提案し、その機能の検討と実装を行った。
|
|
|
142
|
|
|
143
|
|
|
144 \section{Java言語への移行と分散デバッグ機能の実装}
|
|
|
145 \subsection{Java言語への移行}
|
|
|
146 Federated Lindaへ分散デバッグ機能を実装する為に、これまでのC言語によるLindaサーバーや
|
|
|
147 Linda APIの実装を、Java言語での実装へ移行した。そのことにおける利点を以下に示す。
|
|
|
148 {\small
|
|
|
149 \begin{verbatim}
|
|
|
150 1. Java言語への移行において設計や仕様の見直しを行い、機能拡
|
|
|
151 張を行いやすい実装とする
|
|
|
152 2. オブジェクト指向、自動化されたリファクタリングを用いること
|
|
|
153 による開発の効率化
|
|
|
154 3. マルチプラットホームへの対応
|
|
|
155 4. デュアルスタック化によるIPv4/IPv6の同時接続に対応
|
|
|
156 \end{verbatim}
|
|
|
157 }
|
|
|
158 %\vspace{-3mm}
|
|
|
159 \subsection{分散デバッグ機能の検討}
|
|
|
160 分散環境におけるプログラムのデバッグでは、多くの場合、逐次デバッガ(gdb等)を用いた
|
|
|
161 二分法でデバッグ可能である。しかし、通信の状態が全体に依存する場合では、単体のデバッグ
|
|
|
162 では全体の正しさをデバッグできないという状況が存在する。その状況を示した図を以下に示す。
|
|
|
163 \vspace{-2mm}
|
|
|
164 \begin{figure}[htbp]
|
|
|
165 \begin{center}
|
|
|
166 \includegraphics[width=5.5cm]{fig/nonseqdeb.pdf}
|
|
|
167 \vspace{-5mm}
|
|
|
168 \caption{逐次デバッグが困難な通信の例}
|
|
|
169 \label{nonseqdeb}
|
|
|
170 \end{center}
|
|
|
171 \end{figure}
|
|
|
172 \vspace{-8mm}
|
|
|
173
|
|
|
174 図\ref{nonseqdeb}に示す様に、通信が全体に影響し、その順序に任意性が存在する場合
|
|
|
175 （分散プログラムの非決定性）、逐次型デバッガによるデバッグを用いることは出来ない。
|
|
|
176 よって、全体の通信を止めずにデバッグが行える仕組みが必要であると考える。
|
|
|
177
|
|
|
178 \subsection{通信状態のデバッグ機能}
|
|
|
179 Federated Lindaの分散デバッグ機能として、Java版Lindaサーバーの機能を拡張し、
|
|
|
180 通信状態のデバッグを、全体の通信を止める事無く行う機能を実装した。
|
|
|
181 この機能は以下の２点からなる。
|
|
|
182 \vspace{-3mm}
|
|
|
183 {\small
|
|
|
184 \begin{verbatim}
|
|
|
185 1. Federated Lindaにおける全体の通信を止める事無く、通信状
|
|
|
186 態のログを取得する機能
|
|
|
187 2. 取得したログを用いて通信状態を視覚的に表示し、ステップ実行
|
|
|
188 によって通信の状態を確認できるモニターツール
|
|
|
189 \end{verbatim}
|
|
|
190 }
|
|
|
191 \vspace{-3mm}
|
|
|
192
|
|
|
193 \section{評価}
|
|
|
194 実装した分散デバッグ機能の評価として、以前デバッグが困難であった、格子状メッシュ型トポロジ
|
|
|
195 におけるルーティングアルゴリズムのデバッグを行った。用いた実験は以下の２つである。
|
|
|
196 \vspace{-3mm}
|
|
|
197 {\small
|
|
|
198 \begin{verbatim}
|
|
|
199 ・6ノードの格子状メッシュ型トポロジにおけるDistance Vector
|
|
|
200 Routingのルーティングテーブル構築
|
|
|
201 ・6ノードの格子状メッシュ型トポロジにおけるCompact Routing
|
|
|
202 のルーティングテーブル構築
|
|
|
203 \end{verbatim}
|
|
|
204 }
|
|
|
205 \vspace{-3mm}
|
|
|
206 上記２点のFederated Lindaにおけるルーティングテーブル構築を行い、
|
|
|
207 その通信状態のログを取得した。その取得したログに対して、モニターツールを
|
|
|
208 用いた通信状態の確認よるデバッグを行い、バグ要因の特定を行う。その様子を
|
|
|
209 図\ref{exec1},図\ref{exec2}に示す。
|
|
|
210
|
|
|
211 \begin{figure}[htbp]
|
|
|
212 \begin{tabular}{cc}
|
|
|
213 \begin{minipage}{0.5\hsize}
|
|
|
214 \begin{center}
|
|
|
215 \includegraphics[width=4.25cm]{fig/debug1.pdf}
|
|
|
216 \vspace{-5mm}
|
|
|
217 \caption{トポロジ及び通信イベントの表示}
|
|
|
218 \label{exec1}
|
|
|
219 \end{center}
|
|
|
220 \end{minipage}
|
|
|
221 \begin{minipage}{0.5\hsize}
|
|
|
222 \begin{center}
|
|
|
223 \includegraphics[width=4.25cm]{fig/debug2.pdf}
|
|
|
224 \vspace{-5mm}
|
|
|
225 \caption{実行シーケンスでの転送タプル内容を表示}
|
|
|
226 \label{exec2}
|
|
|
227 \end{center}
|
|
|
228 \end{minipage}
|
|
|
229 \end{tabular}
|
|
|
230 \end{figure}
|
|
|
231
|
|
|
232 \subsection{バグ要因の発見}
|
|
|
233 通信状態ログのモニターツールを用いてデバッグを行った結果、Link Configuratetionが
|
|
|
234 正常終了していない為に、ルーティングテーブル構築時の通信量が増えているというバグ要因を特定した。
|
|
|
235
|
|
|
236 \newpage
|
|
|
237 このバグは、Distance Vector RoutingとCompact Routingの両実装に見られ、格子状のメッシュ型トポロジに
|
|
|
238 おける問題の原因となっていた。図\ref{bug}にその状況を示す。
|
|
|
239
|
|
|
240 \vspace{-2mm}
|
|
|
241 \begin{figure}[htbp]
|
|
|
242 \begin{center}
|
|
|
243 \includegraphics[width=8.5cm]{fig/bug.pdf}
|
|
|
244 \vspace{-5mm}
|
|
|
245 \caption{別経路からのLink Configuration}
|
|
|
246 \label{bug}
|
|
|
247 \end{center}
|
|
|
248 \end{figure}
|
|
|
249 \vspace{-8mm}
|
|
|
250
|
|
|
251 以上のことより、以前のFederated Linda における開発環境ではデバッグが困難な状況を、
|
|
|
252 通信状態のデバッグ機能を実装することによって解消したと評価する。
|
|
|
253
|
|
|
254 \section{他の分散プログラミングモデルとの比較}
|
|
|
255 Federated Lindaと他の分散プログラミングモデルとの比較を、Overlay Weaver, StarBEDを対象に行う、
|
|
|
256 以下にその結果を示す。
|
|
|
257 \vspace{-2mm}
|
|
|
258 \begin{figure}[htbp]
|
|
|
259 \begin{center}
|
|
21
|
260 \includegraphics[width=9cm]{fig/table2.pdf}
|
|
20
|
261 \vspace{-5mm}
|
|
|
262 \caption{他の分散プログラミングモデルとの比較}
|
|
|
263 \label{table}
|
|
|
264 \end{center}
|
|
|
265 \end{figure}
|
|
|
266 \vspace{-8mm}
|
|
|
267
|
|
|
268 \section{まとめと今後の課題}
|
|
|
269 本研究では、自然にスケールする分散プログラミングモデルを実現する為、
|
|
|
270 実験的に分散アルゴリズムを実装し、スケーラビリティを測ること
|
|
|
271 ができる分散モデルとしてFederated Lindaを提案した。
|
|
|
272 Federated Lindaにおける分散アルゴリズムの実装としてCompat Routingを実装し、評価した。
|
|
|
273 また、その実装の経験から必要と分かった分散デバッグ機能について検討し、実装と評価を行った。
|
|
|
274 本研究における今後の課題としては、スナップショットを用いた分散デバッグ機能の実装が挙げられる
|
|
|
275
|
|
|
276 {\small
|
|
|
277 \begin{thebibliography}{9}
|
|
|
278 \bibitem{dinamicrouting}安村 恭一, 河野 真治,
|
|
|
279 動的ルーティングによりタプル配信を行なう分散タプルスペース Federated Linda,
|
|
|
280 日本ソフトウェア科学会第22回大会, 2005.
|
|
|
281
|
|
|
282 \bibitem{dinamicrouting_compact}渕田 良彦, 河野 真治,
|
|
|
283 連邦型タプルスペースを使ったコンパクトルーティングの実験,
|
|
|
284 情報処理学会プログラミング研究会, 2007.
|
|
|
285
|
|
|
286 \bibitem{compactrouting}L. J . Cowen,
|
|
|
287 Compact Routing with Minimum Stretch, Proc. SODA’99, pp.255-260 (1999).
|
|
|
288
|
|
|
289 \end{thebibliography}
|
|
|
290 }
|
|
|
291
|
|
|
292 \end{document}
|
