# HG changeset patch # User Nozomi Teruya # Date 1517810381 -32400 # Node ID 52a43c1336d96998cd23848b5670019c22627535 # Parent 34383a096d7530cc3fc3d6d2b99ebf3c2afe1d90# Parent d28d691e33eda1d16eb2b1d4193482e1e7ed79c6 merge diff -r 34383a096d75 -r 52a43c1336d9 paper/nozomi-master.pdf diff -r 34383a096d75 -r 52a43c1336d9 paper/nozomi-master.tex --- a/paper/nozomi-master.tex Mon Feb 05 14:55:44 2018 +0900 +++ b/paper/nozomi-master.tex Mon Feb 05 14:59:41 2018 +0900 @@ -155,9 +155,10 @@ Data Segmentは対になるkeyが存在し、Data Segment Managerというノードごとに存在する独自のデータベースによって管理されている。 各ノードにはラベル付きのプロキシであるRemote Data Segment Managerを立て、ラベルとkeyを指定してデータをtake/putするプロトコルとなっている。 +%Topologymanagerもここにかく？ \newpage - +%問題といったら参考文献が必要,わかりづらいとハッキリ書かない 記述の面において、Akkaではメッセージが集中した場合にそれを処理するパターンマッチが増えてしまう問題や、複数のインプットを待ち合わせる際に記述が煩雑になる問題があった。 しかしAliceはインプットを明確に記述でき、複数のインプットを持てる。 @@ -891,29 +892,40 @@ REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。 \chapter{再設計への考察} +InputDGの指定において、CGにDGを宣言するというのは、DGをそのままflipできるようにするためであった。 +逆に言えばそれ以外でDataGear型でプログラマが利用することは少ない。 +そのため、DGをアノテーションから生成し完全にメタレイヤーに移すことで、DGの宣言のないより分かりやすい記述が可能だと考える。 +flipする場合は、keyを指定するだけにしたほうが良い。 +また、put/flipする際にDGM名を直接指定する書き方も、まだひと目でアウトプットしている部分が分かるようなシンタックスではないため、改善の余地がある。 -\chapter{まとめ} +DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。 +当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。 +そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くできるようにしたほうが望ましい。 + +現在はノードごとにDGMとDGのkeyが与えられているが、URLのような大域で使えるkeyを用意することで -%設計しなおしでNAT越えなどの機能拡張が期待できる -%スケーラブルになった -%テストしやすくなった -%また、アノテーションを用いたことでよりユーザーフレンドリーなAPIを実現した。 -%型を気にしなくて良くなった -%信頼性を高めた +\chapter{結論} +\section{まとめ} +本研究では、まず分散フレームワークに必要な要件を洗い出し、Akka、Hazelcastと比較しながら分散フレームワークAliceが分散性を意識して記述できる特徴をもつことを示した。 +また、Aliceの持つCode Segment/Data Segmentの計算モデルや記述方法、Meta Computationについてを説明し、AliceでNAT越えを実現するための手法を示した。 +さらに現状のAliceの問題点として、NAT越えをするために必要なLocal Data Gear Managerの複数立ち上げができないこと、分散プログラムのテストがしづらいこと、APIシンタックスの分離により信頼性が損なわれていること、型の整合性がとれていないことなどを示し、再設計の必要性を述べた。 +そして、分散フレームワークChristieの設計を示し、Code Gear ManagerというCode Gear/Data Gearの管理機構を挟むことでNAT越えやテスト解決することを述べた。 +また、アノテーションを用いることでシンタックスの分離問題を解決し、さらに型整合のとれたより信頼性の高い記述が可能になったことを示した。 +そして、これら実装したChristieに対しても更に改善すべき点を考察した。 -\chapter{今後の課題} -\section{TopologyManagerの実装} +\section{今後の課題} +\subsection*{TopologyManagerの実装} Aliceと同じく、静的・動的なトポロジー管理のできるTopologyManagerの実装が必要である。 Christieでは複数のLocalDSMが立ち上げ可能なため、TopologyManagerでのNAT超えも実装し実用性があるかを検証する -また、通信の信頼性を保証するために、TopologyManagerがダウンした際に新たなTopologyManagerを立ち上げる機能もあるべきだと考える。 +また、通信の信頼性を保証するために、TopologyManagerがダウンした際に新たなTopologyManagerを立ち上げるMeta Computationも必要だと考える。 -\section{実用性の検証} +\subsection*{実用性の検証} 本論文ではChristieの設計と基本実装までを行ったが、それがどれほどの分散性能を持っているのかはまだ計測していない。 CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。 そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。 -\section{GearsOSへの移行} +\subsection*{GearsOSへの移行} GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。 GearsOSではモデル検査機構akasha\cite{}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。 GearsOS上で分散プログラミングができればより信頼性の高いプログラミングが期待できるため、将来的にはChristieをGearsOSの分散機構として取り込みたい。