分散環境における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)を介して機械学習を利用する


【想定シナリオ】
絶え間なく流れてくるセンサーデータを、まず線形分類器で分類して概要のタグ付けをし、
その後異常検知のためにLOFを計算し、しきい値を超えたセンサーデータをストレージに格納していくというシステムを考える。

・試行錯誤
利用者は、特徴抽出をしながらパラメータ調整を試行錯誤している。
最初の分類のパラメタ設定によって、まったく異なる異常が検知される。
そのため、狙ったものが異常と検出されるように、なんども分類パラメータを変えて学習させることにした。

・日々の増加
実サービスに導入、冗長化（２）させるために、分類２台、LOF２台の四台構成でサーバを動作させている。
しかし、扱うデータ量が増えるに従って、LOFサーバ側がメモリ上に載せきれなくなってきた。
それぞれを増やすことにした。しかし、しばらく運用していると分類サーバは性能的にも容量的にも２台で十分な
流量が続くことが分かった。そのため、一台分縮退させそれをLOFに回すことにした。
(分類, LOF) : (2, 2) -> (3, 4) -> (2, 5)

・障害とリカバリ
ある日突然、LOFサーバが故障した。一時的に性能は劣化したが元通り復元された。
(分類, LOF) : (2, 5) -> (2, 4) -> (2, 5)

・Jubatus as a Service
 Jubatusとサービスとして利用できるようにするWebサービスを始めた。
一つのサーバを建てるのに1＄かかるが、それ以降、月間10000リクエストまでならば無料で利用できる。
利用者がサーバのTypeを指定するとクラウド上で適切に設定されたjubahogeserverが立ち上がる。
そこに対して、利用者は必要なだけクエリーを投げることが出来る。