Papers/2018/nozomi-master: paper/nozomi-master.tex comparison

comparison paper/nozomi-master.tex @ 176:055266d62d84

add slide

author	Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
date	Tue, 06 Feb 2018 03:56:16 +0900
parents	7e7fe5e28ba4
children	b5ab0f9c07aa

comparison

equal deleted inserted replaced

-:7e7fe5e28ba4
+:055266d62d84
 ノード間通信でサービスに沿った柔軟な通信をするためには、送信するデータを圧縮する機能や、受け取ったデータをそのままほかノードへ転送する機能が求められることがある。
 データの圧縮を指定したい場合、Akka、Hazelcastはシリアライザが用意されているため、そのメソッドを呼び出すことで圧縮伸長を行う。
 また、転送を指定したい場合、Akkaにはforwardメソッドがあるためそれを呼び出すことで受け取ったデータの転送が可能だが、Hazelcastは一つのMapへのアクセスに見立てているため、転送にもputを用いる。
-一方でAliceは圧縮の展開と転送を同時に行うことを想定した圧縮・転送機能を持っている。
+一方でAliceは圧縮の伸長と転送を同時に行うことを想定した圧縮・転送機能を持っている。
-Data Segment内に圧縮と非圧縮の両形式を同時に持てるため、受け取った圧縮データを展開をしながら圧縮したまま別ノードに転送することができる。
+Data Segment内に圧縮と非圧縮の両形式を同時に持てるため、受け取った圧縮データを伸長をしながら圧縮したまま別ノードに転送することができる。
-また、圧縮するには送信する宛先ラベルに"compressed"とつけるだけでよく、データ取得時に自動で展開もされるため、プログラマがメソッドの呼び出しを追加する必要がなく圧縮・非圧縮を簡単に切り替えられる。
+また、圧縮するには送信する宛先ラベルに"compressed"とつけるだけでよく、データ取得時に自動で伸長もされるため、プログラマがメソッドの呼び出しを追加する必要がなく圧縮・非圧縮を簡単に切り替えられる。
 \newpage
 \subsection*{NAT越え}
 ネットワーク間通信の大きな問題の一つに、NATがある。
 \newpage
 \section{Data Segment API}
 DSの保存・取得にはAliceが提供するAPIを用いる。
-putとupdate、flipはOutput DS APIと呼ばれ、DSをDSMに保存する際に用いる。
-peekとtakeはInput DS APIと呼ばれ、DSをDSMから取得する際に使用する。
-\begin{itemize}
-\item {\ttfamily void put(String managerKey, String key, Object val)}
-\end{itemize}
 putとupdate、flipはOutput DS APIと呼ばれ、DSをDSMに保存する際に用いる。
 peekとtakeはInput DS APIと呼ばれ、DSをDSMから取得する際に使用する。
 \begin{itemize}
 \item {\ttfamily void put(String managerKey, String key, Object val)}
 \subsection{Aliceの圧縮機能}
 リモートノードに大きなデータを送るために、データを圧縮したい場合がある。
 そこで、Aliceは圧縮をサポートしている。
 しかし、単に圧縮のメソッドを用意したわけではない。
-圧縮データの展開と、圧縮したまま別ノードへの転送を同時に実現したい場合があるため、Meta CSを介すことでDSに圧縮と非圧縮のデータを同時に持てるようにしている(図\ref{fig:compress})。
+圧縮データの伸長と、圧縮したまま別ノードへの転送を同時に実現したい場合があるため、Meta CSを介すことでDSに圧縮と非圧縮のデータを同時に持てるようにしている(図\ref{fig:compress})。
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=160mm]{images/compress.pdf}
 \end{center}
 \lstinputlisting[label=src:before, caption=通常のDSを扱うCSの例]{source/beforeCompress.java}
 \lstinputlisting[label=src:after,caption=圧縮したDSを扱うCSの例]{source/afterCompress.java}
 このようにコードの変更を抑えて圧縮できるため、他の計算部分を変えずにデータ形式が指定できる。
-また、DSを取り出す際もasClass()内部で自動で展開が行われるため、コードの変更がなく、プログラマがデータの展開を考える必要がない。
+また、DSを取り出す際もasClass()内部で自動で伸長が行われるため、コードの変更がなく、プログラマがデータの伸長を考える必要がない。
 \subsection{TopologyManager}
 Aliceでは、ノード間の接続管理やトポロジーの構成管理を、Topology ManagerとTopology NodeというMeta Computationが提供している。
 プログラマはトポロジーファイルを用意し、Topology Managerに読み込ませるだけでトポロジーを構成することができる。
 \section{APIの記述の分離}
 2.4で示したように、InputDSを記述するには、一度フィールドでReceiverをcreateして、その後Reveiverに対してsetKeyで待ち合わせるkeyを指定しなければならない。
 このようにインプットの処理が分離されてしまっていては、記述が煩雑な上にコードを読んだ際にどのkeyに対して待ち合わせを行っているのか直感的に分からない。
-さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう(ソースコード\ref{src:StartSetKey)})。
+さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう(ソースコード\ref{src:StartSetKey})。
 \lstinputlisting[label=src:StartSetKey, caption=setKeyを外部から呼び出す例]{source/StartSetKey.java}
-\lstinputlisting[label=src:SetKey]{source/SetKey.java}
+\lstinputlisting[label=src:SetKey, caption=外部setKeyによりどのkeyを待っているかがわからないCSの例]{source/SetKey.java}
 このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。
 これでは見通しが悪いため、どこでkeyを指定するのか明確にすべきである。
 可読性の低いコードはプログラマの負担となるため、CSが何を待ち合わせているのかそのCSを見ただけで理解できるように記述の分離問題を改善しなくてはならない。
 もしDGがなければ、リモートから来たコマンドもローカルの場合と同様にLocalDGMのwaitListに入る。
 REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。
 \chapter{再設計への考察}
+Christieではアノテーションを用いることで分離問題を解決することができた。
+このようにアノテーションを用いたAPIはAkkaやHazelcastにはないため、より記述性が高いフレームワークとなったと言える。
+また、設計をし直したことでAliceより幅広いMeta Computationの実装が容易になった。
+これにより細かな分散プログラムの実装が可能になった。
+ロケーション透過性の高いAkkaやHazelcastではこのようなプログラミングは困難である。
+keyを用いたプロトコル
+また、現在はノードごとにDGMとDGのkeyが与えられているが、将来的にはURLのような大域で使えるkeyを用意することでより手軽なRemoteDGMへのアクセスを提供できると考えられる。
 InputDGの指定において、CGにDGを宣言するというのは、DGをそのままflipできるようにするためであった。
 逆に言えばそれ以外でDataGear型でプログラマが利用することは少ない。
 そのため、DGを宣言せずにアノテーションから生成し完全にメタレイヤーに移すことで、より分かりやすい記述が可能だと考える。
 flipする場合は、keyを指定するだけで良い。
 また、put/flipする際にDGM名を直接指定する書き方も、まだひと目でアウトプットしている部分が分かるようなシンタックスではないため、改善の余地がある。
-DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。
-当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。
-そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くすることが望ましい。
-また、現在はノードごとにDGMとDGのkeyが与えられているが、将来的にはURLのような大域で使えるkeyを用意することでより手軽なRemoteDGMへのアクセスを提供できると考えられる。
 \chapter{結論}
 \section{まとめ}
 本研究では、まず分散フレームワークに必要な要件を洗い出し、Akka、Hazelcastと比較しながら分散フレームワークAliceが分散性を意識して記述できる特徴をもつことを示した。
 また、Aliceの持つCode Segment/Data Segmentの計算モデルや記述方法、Meta Computationについてを説明し、AliceでNAT越えを実現するための手法を示した。
 \subsection*{実用性の検証}
 本論文ではChristieの設計と基本実装までを行ったが、それがどれほどの分散性能を持っているのかはまだ計測していない。
 CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。
 そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。
+\subsection*{Jungleとの統合}
+DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。
+当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。
+そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くすることが望ましい。
 \subsection*{GearsOSへの移行}
 GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。
 GearsOSではモデル検査機構akasya\cite{akasya}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。
 GearsOS上で分散プログラミングができればより信頼性の高いプログラミングが期待できるため、将来的にはChristieをGearsOSの分散機構として取り込みたい。

Mercurial > hg > Papers > 2018 > nozomi-master

comparison paper/nozomi-master.tex @ 176:055266d62d84