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

gistfile1.txt

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

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

- 検討事項
    - モデルの永続化をサポートするか否か
    - 将来的にサポートする可能性はあるか？：スナップショット、設定の動的更新・リビジョン管理
    - → とりあえずはjubavisor/jubactlによってsave/loadする案

【やりたいこと】
- 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したときどうするべきか】
- keeper利用時の振る舞いは、プロセス／マシンの配置構成に依存している

- 自殺するべきである。
    - プロセスの配置構成：「1マシンにJubatus clientとkeeperをセットで構成」し、これを並列に並べた裏にJubatus serverの配置を想定している
    - メリット
        - ZKの管理と整合性が取れるため、全体としては問題ない
        - クライアント側は、Keeperが死んだことを検知できれば別のサーバに振り返るなどが出来る
    - デメリット
        - クライアント側は、次のような手段と、Keeperを冗長化させない限りサービスを利用できない
            - Keeper一覧情報の動的な取得・Keeperが死んだことを知る手段(ZKクライアントになるか障害検出器を持つ必要性がある)
            - もしくは一部のKeeperと接続不能になっても別のKeeperに繋ぎ変えるような構成を取る

- リトライすべき
    - プロセスの配置構成：Jubatus clientとkeeperは別のマシンに配置することを想定している
    - メリット
    - デメリット
        - リトライしている最中にクライアントからリクエストが来た時に、どうするべきか不定。
        - リトライしていると、クライアントはZKから見放されたKeeperに聞きにいき続けることになってしまう。

【jubavisorがEXPIREしたときどうするべきか】
- 自殺すべき
    - デメリット
        - 自殺すると、再度別の方法でjubavisor及び管理している子プロセスを立ち上げ直す必要がある。

- リトライすべき
    -メリット
        - 一時的な故障の場合、すぐに復活することができる。
        - クライアント（jubactl）からのリクエスト時にはZKからは消えて見えるので整合性が取れる。
    - デメリット
        - 自殺していると、再度別の方法でプロセスを立ち上げ直す必要がある。

【EXPIRE時の振る舞いとして全体として】
- ZKがダウンする可能性もある
    - ZK巻き込んでサービス停止することを許容するか、しないか

    - 復旧（リカバリ）の手順はどうするか
        - インスタンスのクラスタでの、モデル永続化についてはまだ検討段階
        - save/load RPCの利用
            - 出力先が/tmp(server_argv.tmpdir以下のため)だと、OS再起動時に消去される可能性がある
            - 出力したモデルデータに設定を含めていない問題（設定が一致しないと落ちる可能性）

- EXPIRE(ZKダウン)時：可用性／一貫性のどちらを優先するか整理する
ZKが落ちた（EXPIRE）時点で、可用性と一貫性の両方を保ったまま運用継続は困難。
TODO：アルゴリズムごとにどこまで可用性が保てるか（どこまで一貫性を要求しているのか）、整理しておく

    - 可用性をとるとき（一貫性をすてる）
        - キャッシュしているサーバ一覧をクリアしない
        - 通信可能なサーバとのみ通信を行う

    - 一貫性をとるとき（可用性をすてる）
        - update(train)を禁止をさせるような制約を加えて、運用を続ける
        - Jubatusサーバをすべて終了させる（or Jubatusサーバの機能を一時停止し、リクエストを受け付けなくさせる）

    - 上記をとりつつ、障害の発生したサーバ（もしくはZK）を復旧させる
        - 復旧手順については前述（別途検討）