Jubatus ZK Session expired時にどう振る舞うと良いか

gistfile1.txt

【Jubatus ZKとの接続でSESSION_EXPIREDしたときどうするか問題】
- ZKを利用しているOSSの実装
    - EXPIREしたらexit（自殺）する
    - EXPIREしてもZKと繋がるまで再接続し続ける
        - 無限ループ・回数制限を設ける
        - 接続が切れている間は、ZK関連のサービスを提供できない（キャッシュ保持してるかもしれない。もしくは、キャッシュはクリアする実装）

- Jubatusにおける選択肢
    - EXPIREしたらプロセスを終了する
    - EXPIREしてもZKへ接続リトライする（リトライし続ける、回数制限等つけてリトライする）

【やりたいこと】
- ZK SESSION_EXPIREしてもJubatusのシステム全体としてMLが動き続ける
- 停止したサーバのアラート通知（監視）の仕組みがある

【EXPIREしたらどうなるのか】
- MLサーバ
    - モデルを共有できなくなる
        - Jubatusは緩いモデル共有なので問題ない（アルゴリズムもある）
        - アルゴリズムによっては正しい動作を保証できない：recommenderでしたっけ
    - RPCが実行されない限りモデルは永続化されない
    - keeper経由でアクセスされなくなる
    - ZKのメンバシップ管理から外れる
- keeper
    - サーバ一覧の取得ができなくなる（キャッシュ保持していれば、現状維持でクライアントからのProxyは継続可能）
    - ZKのメンバシップ管理から外れる
- jubavisor
    - サーバ一覧の取得ができなくなる
    - ZKのメンバシップ管理から外れる
- jubactl:
    - コマンド実行中にEXPIREすると、jubavisorが管理しているサーバの状態の一貫性が無くなる可能性がある（停止/稼働状態が混ざる、とか）
    - EXPIREしたサーバ(MLだけでなくkeeper, jubavisor含む)が取得ができなくなる状態になる可能性がある
    - EXPIREしたサーバの操作がjubavisor経由で実行できなくなる

【MLサーバがEXPIREしたとき終了する】
- メリット
    - 動作中のシステムに対して、古いモデルによるMIX等の影響を与えなくなる
- デメリット
    - 機械学習の機能を提供できなくなる
    - モデルを共有できなくなる → ZK生きているときに定期的もしくはサーバ終了前に永続化する仕組みを用意する案
    - モデルが共有できなくなるとアルゴリズムによっては正しい動作を保証できない → TODO: どのアルゴリズムがダメか洗い出して整理

【EXPIREしてもMLサーバはZK接続リトライする】
- メリット
    - ZKでメンバシップ管理（クラスタ管理など）することが可能になる
    - MLサーバを復旧させることができる（やりたければ）
    - 学習・MIX済みのモデルは失われない
- デメリット
    - 自律動作されると、リカバリ等の影響範囲が予測できない→サービスを一時停止状態にすることも可能では
    - 何もサービスを提供していないのに、コンピュータのリソースを占有し続ける
    - モデルが共有できなくなると、自動復旧しない限りアルゴリズムによっては正しい動作を保証できない → TODO: どのアルゴリズムがダメか洗い出して整理


【keeperがEXPIREしたときどうするべきか】
自殺するべきである。

-メリット
-- ZKの管理と整合性が取れるため、全体としては問題ない
-- クライアント側は、Keeperが死んだことを検知できれば別のサーバに振り返るなどが出来る

リトライしている最中にクライアントからリクエストが来た時に、どうするべきか不定。
リトライしていると、クライアントはZKから見放されたKeeperに聞きにいき続けることになってしまう。

【jubavisorがEXPIREしたときどうするべきか】
リトライし続けるべきである。

-メリット
一時的な故障の場合、すぐに復活することができる。

クライアント（jubactl）からのリクエスト時にはZKからは消えて見えるので整合性が取れる。
自殺していると、再度別の方法でプロセスを立ち上げ直す必要がある。