Mercurial > hg > Papers > 2018 > nozomi-master

diff presen/sample.markdown @ 179:a3ee75a897f3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
cut slide
author Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
date Tue, 06 Feb 2018 13:46:47 +0900
parents 074eb76a9184
children 5a0a11b54ab4
line wrap: on
line diff
--- a/presen/sample.markdown	Tue Feb 06 12:19:12 2018 +0900
+++ b/presen/sample.markdown	Tue Feb 06 13:46:47 2018 +0900
@@ -2,9 +2,6 @@
 author: 照屋のぞみ  
 
 # 研究目的（1/2）
-* スケーラブルで信頼性の高い分散プログラムを書くのは容易ではない
-    * 並列で動く分散した資源を意識するのは難しい
-    * 分散したノードの選択方法が明確ではない􏱾􏱿􏰮􏳠􏲒􏰌􏰍􏰞􏰫􏷑􏷒􏱃􏱱􏲭􏰞􏰡􏰨􏰢􏱯􏱰􏰻􏰼􏰔􏰠􏳍􏳎􏰮􏰠􏰡􏲒􏰭􏲣 􏰫􏰭􏰘􏰔􏱑􏰥􏰹􏰌􏰍􏰞􏰫
 * 当研究室が開発している並列分散フレームワークAliceではスケーラブルな分散プログラムを信頼性高く記述できる環境を実現する
 * ここで言う信頼性とは定められた環境下で安定して仕様に従った動作を行うことを指す
     * 仕様の記述のしやすさ、可読性、拡張時に仕様変更を抑えられるかも含む
@@ -18,26 +15,10 @@
 
 # 目次
 * Aliceの概要
-	* Code Segment / Data Segment
-	* Data Segment Manager
-    * API
-	* Computation / Meta Computation
-	* Topology Manager
-    * 圧縮
-* Topology Managerの拡張設計
-	* 別トポロジー間の接続のための設計
-	* 別ネットワーク間の接続のための設計
+* AliceのNAT越え
 * Aliceの問題点
-    * LocalDSMの複数立ち上げができない
-    * 記述の煩雑さ
 * Christieの設計
-    * 基本設計
-    * 記述性の改善
 * 他フレームワークとの比較
-    * Akka, Hazelcast
-    * 設計思想の違い
-    * 記述性の違い
-    * 提供する機能 
 * まとめ
 * 今後の課題
 
@@ -74,12 +55,11 @@
 
 # Data Segment API 
 * DSの取得
-    * `void take(String managerKey, String key)`  
-    * `void peek(String managerKey, String key)`   
+    * take/peek  
 * DSの追加
-    * `void put(String managerKey, String key, Object val)`  
-    * `void update(String managerKey, String key, Object val)`  
-    * `void flip(String managerKey, String key, Receiver val)`  
+    * put/update
+* DSの転送
+    * flip
 
 # Code Segmentの記述例
 * take/peekをするにはcreate/setKeyメソッドを使わなければならない
@@ -127,43 +107,21 @@
 * Topology Node
 	* 各ノード側でTopology Managerとの通信を行うMeta Computation
 	* ノードアプリケーションを記述する際にTopology Nodeをnewしておけば以降のTopology Managerとの通信やノード間の接続を行う  
-* Topology Manager/NodeもCS/DSを用いて実装されている。
 
-# AliceのMeta Computation - Static Topology Manager
-* プログラマがdot形式のトポロジーファイルを用意し、Topology Managerに読み込ませる
-* トポロジーファイルにはノードの接続関係と接続する際に指定するRemote DSM名を記す
-* Graphvizを用いればトポロジーを描くだけでトポロジーファイルが自動出力されるため構成が容易
-
-```dot
-digraph test{
-	node0 −> node1[label=”right”]
-	node0 −> node2[label=”left”]
-	node1 −> node2[label=”right”]
-	node1 −> node0[label=”left”]
-	node2 −> node0[label=”right”]
-	node2 −> node1[label=”left”]
-}
-```
-
-# AliceのMeta Computation - Static Topology Manager
-* ファイルを読み込んだTopology Managerを立ち上げる
+# AliceのMeta Computation - Topology Manager/Topology Node
+* Topology Managerを立ち上げる
 * 各Topology NodeはTopology Managerに参加表明をし接続すべきノードの情報を要求する  
 ![opt](./pictures/tree1.svg){:width="60%"}
 
-# AliceのMeta Computation - Static Topology Manager
+# AliceのMeta Computation - Topology Manager/Topology Node
 * 参加表明があった順に各ノードにnodeNameを割り当て、接続するべきノードのIPアドレス/ポート番号を送る
 ![opt](./pictures/tree2.svg){:width="60%"}
 
-# AliceのMeta Computation - Static Topology Manager
+# AliceのMeta Computation - Topology Manager/Topology Node
 * Topology Nodeが受け取った情報をもとにRemote DSMを立ちあげ接続し合うことでオーバーレイネットワークが作られる  
 * Topology Managerは接続情報を管理し、実際の接続はTopology Nodeが行う
 ![opt](./pictures/tree3.svg){:width="60%"}
 
-# AliceのMeta Computation - Dynamic Topology Manager
-* 参加するノード数があらかじめ決まっているとは限らない
-* Dynamic Topology Managerがノードを参加表明順にトポロジーに組み込む
-* 現在はTree Topologyに対応
-
 # AliceのMeta Computation - 圧縮
 * DSは内部に圧縮・非圧縮の複数の形式を複数もつことができる
 * 圧縮したデータの伸長と圧縮したままの転送が同時に可能
@@ -175,27 +133,11 @@
 * 伸長も *asClass()* した際に自動でされる
 * コードの変更が抑えて圧縮・非圧縮が切り替えられる
 
-
+# AliceのNATを越え
+* NATを越えたノード間通信は分散処理の課題である
+* Aliceではトポロジー管理がアプリケーションから分離しているため、コードを大きく変更しなくともTopology Managerを増やすことでNAT越えが可能
 
-# Aliceに求められるMeta Computation - アプリケーションの接続
-* 別のトポロジーをもった既存のアプリケーション同士をコードの変更を抑えつつ接続させたい
-* AliceVNC
-	* Alice上に実装したツリートポロジーの画面配信システム
-* AliceChat
-	* Alice上に実装したスタートポロジーのチャット
-* 連携することで実現したい機能
-	* VNC画面のスナップショットをチャットに載せる
-	* チャットの内容をVNC画面にコメントとして流す
-
-# Aliceに求められるMeta Computation - アプリケーションの接続
-* それぞれのアプリケーションのトポロジーを構成するTopologyManagerを連携させることで可能
-![opt](./pictures/vncandchat.svg){:width="70%"}
-
-# Aliceに求められるMeta Computation - NATを越えた接続
-* NATを越えたノード間通信は分散処理の課題である
-* Aliceではトポロジー管理がアプリケーションから分離しているため、コードを大きく変更しなくともTopology Managerを増やすことでトポロジーの拡張が可能
-
-# Aliceに求められるMeta Computation - NATを越えた接続
+# AliceのNATを越え接続
 * 各プライベートネットワーク内を管理するPrivate Topology Manager
 * グローバルIPアドレスを持ったGlobal Topology Managerを１つ立てる
 * TopologyNodeが複数対応できるためPrivate/Global Topology Managerに接続  
@@ -218,12 +160,13 @@
 # Aliceの問題点 - LocalDSMを複数立ち上げられない
 * AliceではDSMを管理するクラスがstaticで書かれていたためLocal DSMを複数立ち上げることができない
 * このstaticを抜くにはAliceのコード全体を大きく変更しなければならない
-* アプリケーション接続やNAT越えのMeta Computationの追加が困難
+* 現状ではNAT越えのMeta Computationの追加が困難
 * 複数インスタンスを立ち上げての分散プログラムのテストが書けない
+* 再設計の必要がある
 
 # Aliceの問題点 - APIシンタックスの分離
-* setKeyは記述場所が決まっておらず、CSの外からも呼べる
-    * CSの再利用を可能にするが、どのkeyを待っているのか不明なCSが生まれてしまう
+* setKeyは記述場所が決まっておらず、待ち合わせを行っているCSの外からも呼べる
+    * どのkeyを待っているのか不明なCSが生まれてしまう
 * setKeyではkeyを動的に指定することができる
     * どんな処理を行っているかわかりづらい
     * 対応するput箇所も修正しなければならない
@@ -261,13 +204,12 @@
 * Input DSをReceiver型でcreateするため、どの型のデータを待っているのかわからない
 * しかしReceiverからデータを取り出すにはasClass()で型を指定する必要がある
 * 型をDSをputした箇所までコードをたどる必要がある
-    * flipでの転送もあるため、それを発見するのは容易ではない
 
 # Aliceの問題点 - まとめ
 * 以下の問題がAliceの信頼性・拡張性を下げている
     * Local DSMを複数立ち上げられないため、Topology Managerの拡張やテストが困難
     * インプットAPIが分離しているためCSでどんな処理が行われているかわかりづらい
-    * setKyeの記述順序や型を気にしてプログラミングをしなくてはならない
+    * setKeyの記述順序や型を気にしてプログラミングをしなくてはならない
 
 # 分散フレームワークChristieへの必要要件
 * Aliceの問題点を踏まえ、フレームワークをChristieを設計する
@@ -275,55 +217,31 @@
     * 煩雑なAPIをシンプルにし、記述性を高める
     * 型の整合性をとれるようにし、信頼性を向上させる
 
-# Christie - 基本設計
+# Christie - 基本設計(1)
 * Javaで実装される
+* CS/DSの依存関係や、DSMの構造、リモートノードへの接続方法はAliceと同様である
 * 将来的に当研究室で開発しているGearsOSに統合したい
     * GearsOSに倣い、Code Gear(CG)/ Data Gear(DG) という名称を用いる
-* CG/DGの依存関係や、DG Manager（DGM）の構造、Remote DGMへの接続方法はAliceと同様である
 
-# Christie - 基本設計
-* DGMはLocalもRemoteも全てCode Gear Manager(CGM)が管理する
+# Christie - 基本設計(2)
+* Code Gear Manager(CGM)という機構がData Gear Manager(DGM)を管理
 * 1つのCGMは1つのLocalDGMを持つ
 * CGM同士はThreadPoolとCGMのリストを共有している
     * メタ計算で全てのCGMにアクセス可能
 ![opt](./pictures/ChristieClass.svg){:width="60%"}
 
-# Christie - 基本設計
-* CG を記述する際は Alice同様CodeGear.classを継承
-* CGは　*void run(CodeGearManager cgm)* を持ち、run メソッド内に処理を記述
-    * このようにCGMを持ち運ぶ書き方はGearsOSに合わせてた書き方
-* CGを作るためのAPIにはCGM経由で呼び出す
-
-# Christie - DGMの複数立ち上げ
+# Christie -  基本設計(2) DGMの複数立ち上げ
 * ChristieではCGMを2つ生成すればLocalDGMも2つ作られる
+    * NAT越えなどの機能拡張に対応可能
 * 複数のLocalDGM同士のやりとりは、Remoteへの接続と同じようにRemoteDGMを介してアクセスする
-* 分散プログラムのローカルでのテストが可能になる
+    * 分散プログラムのローカルでのテストが可能になる
 ![opt](./pictures/DGM.svg){:width="50%"}
 
-# Christie - CGの生成方法
-1. StartCodeGear.classを継承しCGMを生成する
-2. CGをnewしたあと*setup*を用いる
-    * newが終わらないとアノテーションから待ち合わせを行う処理ができないため
-    * このときCGMがCGに渡されるため、プログラマが引数にCGMを渡す必要はない
-    
-```java
-public class StartTest extends StartCodeGear{//StartCG
-
-    public StartTest(CodeGearManager cgm) {
-        super(cgm);
-    }
-
-    public static void main(String args[]){
-        StartTest start = new StartTest(createCGM(10000));//CGMを生成
-    }
-
-    @Override
-    protected void run(CodeGearManager cgm) {
-        cgm.setup(new TestCodeGear());//CGの待ち合わせを開始
-        getLocalDGM().put("count", 1);
-    }
-}
-```
+# Christie - 基本設計(3)
+* CG を記述する際は Alice同様CodeGear.classを継承
+* CGは　*void run(CodeGearManager cgm)* を持ち、run メソッド内に処理を記述
+    * run内で新たなCGを作るためのAPIにはCGM経由で呼び出す
+    * このようにCGMを持ち運ぶ書き方はGearsOSに合わせてた書き方
 
 # Christie - アノテーションを用いたインプット記述
 * keyの指定にはJavaのアノテーションを用いる
@@ -374,13 +292,14 @@
 * 取得したDGが待ち合わせに指定した型と違う場合はエラーになる
 
 # Christie - まとめ
-* CodeGearManagerというDGMの管理機構を作ったことでLocalDGM複数立ち上げが可能になった
-    * テストや機能拡張がしやすくなった
+* CodeGearManagerというDGMの管理機構を作ったことでLocalDGM複数立ち上げが可能になり、NAT越えなどの機能拡張やテストをしやすくなった
 * アノテーションを用いたことでDG生成とkey指定の分離問題を解決し、処理の見通しを良くした
 * 型の整合性を保証することで信頼性が向上した
 
 # Christieと他フレームワークの比較
-* Christieの特徴を述べるために他の分散フレームワークとしてAkka、Hazelcastと比較を行う
+* Akka、Hazelcastと比較してChristieの特徴を述べる
+    * Akka ...Scala/Java向け分散フレームワーク
+    * Hazelcast ...Java向け分散フレームワーク
 
 # Christieと他フレームワークの比較 - Akka
 * アクターモデル
@@ -390,7 +309,7 @@
 * アクターはメールボックスというキューを持つ
     * 受け取ったメッセージをパターンマッチで順次処理
     * パターンマッチにはScalaのcase classを用いられる
-![opt](./pictures/Akka.svg){:width="50%"}
+![opt](./pictures/Akka.svg){:width="70%"}
 
 # Christieと他フレームワークの比較 - Hazelcast
 * キーと値の1対1でデータを管理するインメモリ・データグリッド
@@ -411,14 +330,14 @@
     * Christieでは複数のインプットを記述でき待ち合わせ処理が必要ない
 * データの圧縮通信を指定したい場合
     * Akka、Hazelcastでは圧縮メソッドが用意されているため、それを用いて記述する
-    * ChristieではDGMkeyの名前を変えるだけなのでメソッド呼び出しの記述が必要ない
+    * ChristieではDGMkeyの名前を変えるだけでメソッド呼び出しの記述が要らないため少ない変更で拡張が可能
 
 # まとめ
 * AliceのプロトコルやMeta Computationを説明し、TopologyManagerを用いたNAT越えの手法を示した
 * Aliceの問題点を整理し、再設計の必要性を述べた
 * LocalDGMの複数立ち上げを可能にし、テストや機能拡張がしやすい環境を整えた
 * Christieではアノテーションを用いたAPIで信頼性の高い記述を実現した
-* Christieを他のフレームワークと比較し、分散性を意識して記述できる特徴があることを述べた
+* Christieを他のフレームワークと比較し、分散性を意識して記述できる特徴があることを示した
 
 # 今後の課題
 * DataGearのメタレイヤーへの移行
@@ -427,6 +346,32 @@
 * Jungleとの統合
 * GearsOSへの移行
 
+# Christie - CGの生成方法
+1. StartCodeGear.classを継承しCGMを生成する
+2. CGをnewしたあと*setup*を用いる
+    * newが終わらないとアノテーションから待ち合わせを行う処理ができないため
+    * このときCGMがCGに渡されるため、プログラマが引数にCGMを渡す必要はない
+    
+```java
+public class StartTest extends StartCodeGear{//StartCG
+
+    public StartTest(CodeGearManager cgm) {
+        super(cgm);
+    }
+
+    public static void main(String args[]){
+        StartTest start = new StartTest(createCGM(10000));//CGMを生成
+    }
+
+    @Override
+    protected void run(CodeGearManager cgm) {
+        cgm.setup(new TestCodeGear());//CGの待ち合わせを開始
+        getLocalDGM().put("count", 1);
+    }
+}
+```
+
+
 <style type="text/css">
 <!--
 *{