分散環境におけるjubatusの設定情報の与え方とモデルについて

gistfile1.txt

【やりたいこと】
- 分散環境で、同じnameを持つサーバは同じconfigを持つ。
- サーバは途中から参加することがある。
- クライアントからconfigを変えることが出来る。

【configの与え方をどうするか？】
- RPCで与える
	- 設定を変える場合は、set_config
	- 途中から参加する場合もset_config
	- すべての設定が同じ事は、ユーザの責任にする。
- 起動時に引数で与える
	- 設定を変えるときは、jubactlなどでサーバを立て直す。
	- 途中から参加する場合も、ユーザが引数を指定する。
	- すべての設定が同じ事は、ユーザの責任にする。
-  ZKにファイルとして設定を置く
	- 設定を変えるときは、ZKのファイルを反映させて再開
	- 途中から参加する場合は、ZKに聞きに行く
	- 更新時は全体をロックして確実に反映される。

【課題】
設定情報が途中で変わることで、
- 機械学習としての問題（そのモデルはそもそも何を表したもの？）
- 分散システムとしての問題（途中書き換えの整合性など）
が起きうる。

【configを変更した時にモデルをどうするか？】
- クリアする
	- メリット
		- 機械学習的には正しい。
	- デメリット
		- サーバの追加時などconfigをするときに、config済みと未configを分けて制御する必要がある。
		- （現状のrecommenderは出来ていないためkeeperが使えない）
- 残す
	- メリット
		- ユーザ側の判断に委ねることが出来る。
		- クリアしたい場合は別途clearを呼ぶ。
	- デメリット
		- 機械学習的に何をやっているのかよく分からない。
		- 変更したconfigによってはサーバが落ちることも想定される。
- 変更するconfigに対してモデルが流用可能な場合のみ残す
	- メリット
		- 運用環境での微調整などが出来るかもしれない。
	- デメリット
		- 流用可能かどうかを判断することが難しい。
		- フレームワークではなくアルゴリズム側で判断する必要がある。