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

gistfile1.txt

【configを動的に再変更できたほうがいいか否か】
- できたほうがいい
	- メリット
		- 設定変更の自由度があがる
		- 設定調整、実験、評価がやりやすくなる
		- プロセス再起動なしで状態を初期化できる
	- デメリット
		- 同一インスタンスのサーバで設定の一貫性を保証、もしくは一貫性がないことに対処できる仕組みが必要になる
		- それに伴い、正常なサービスを提供できなくなる可能性がある 例：サーバが停止する、サーバが誤った結果を返す
		- 以下の【課題】の部分に相当
		- オペレーションの複雑さが上がる
- できないほうがよい
	- メリット
		- 以下の【課題】の負担が少なくなる
		- オペレーションミスを減らせる
	- デメリット
		- 同一インスタンスのサーバで設定の一貫性を保証、もしくは一貫性がないことに対処できる仕組みが必要になる（サーバ起動後には設定変更させないようにする、サーバ起動中には設定を変更できないようにさせる）
		- プロセス再起動をしないと設定が変更できない
		- プロセス再起動のために、そのための仕組み・ツールが無いと分散環境で使いづらい（困る）

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

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

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

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


【考えるときに留意すること】
- 外部可変性と内部可変性
-- 外から見たとき（ブラックボックス）の変更可能な箇所のこと、内側の実装内での変更可能な箇所のこと。
- 可変点: 変更可能な箇所のことを呼ぶ
-- 例：設定変更の手段は幾つかある（RPCでpull/push, ZK pull）
-- 設定を永続化する場所・責任者とは：ユーザ（のファイル）、インメモリ（各サーバのみ）、ZKとそのストレージ
- 排他性の有無（可変点において）
-- 排他性有り：選択肢の中から単体のみ選択可能な場合などがある（1つのサーバプロセスで複数アルゴリズムを選択可能だが、1度に1アルゴリズムのみ扱えるとか）
-- 排他性無し：例えば、ファイル・DBMS・RPCといった複数のインタフェースを利用して設定変更が可能な場合が考えられる。複雑さは増えるかもしれない。

- 内部の仕様の影響を受けて外部インタフェースに制限が加わることがあるかもしれない。が、外から見て基本的な利用方針はあまり変化しないこともあったりなかったり
-- set_configのRPCはクライアントが実行しているが、ZK使ってもほぼ同じ（orより良い）インタフェースを提供できるかもしれない
- 考えてみたら、そもそもその要望（機能）は必要ないのでは疑惑
- よく考えなくても、どちらのインタフェースも提供できる疑惑（もしかして：複雑性とメンテしづらさの向上）

【Jubatusの各プロセスの役割】
- ZooKeeper
-- 神
-- メンバシップ管理、keeper用CHT情報も格納
-- （メンバの障害検知器）
-- MIX用グローバルロック調停
- keeper
-- client-server間のプロキシ、CHT対応
- server
-- 機械学習アルゴリズムの提供（学習と、問い合わせのクエリが基本かな）
-- MIXを能動的に実行する with ZK
- client
-- server(keeper)を介して機械学習を利用する