下図のようなスタンドアロンモードを冗長化した運用環境を想定した際に、発生しうる事象と回避策を明文化する。
0.5.0 を前提とする
分散モードでは、MIX によりノード間のモデル情報がゆるやかに共有されるが、Jubatus をスタンドアロンモードで起動する場合は、構築されたモデル情報をオンラインで他の Jubatus へ共有・レプリケーションするようなことはできない。 そのため、全 Jubatus で学習モデル状態を同一とするためには、現状では、学習リクエストをブロードキャストし、稼働する Jubatus それぞれでモデル情報を構築する方法をとる必要がある。
| # | 分類 | 事象 | 観点 | 関連仕様 |
| P1 | 通常時 | ブロードキャストした学習リクエストの到達順序がプロセス間で異なる場合、プロセス間の学習モデルが同一とならない。そのため、振り分けられた解析リクエストに対する応答が異なる状況となる | 学習モデルの一貫性 | S1 |
| P2 | 高負荷時 | クライアントでタイムアウトが発生した場合、学習リクエストの欠損によりプロセス間の学習モデルが同一とならない。そのため、振り分けられた解析リクエストに対する応答が異なる状況となる | 学習モデルの一貫性 | S2, S3, S4, S5 |
| P3 | 縮退/復旧時 | 一時的なNW障害による縮退運用から復旧した場合、障害中の学習リクエストの欠損により、振り分けられた解析リクエストに対する応答が異なる状況となる | 学習モデルの一貫性 | S2, S3, S5 |
| P4 | 縮退/復旧時 | HW障害などの機器入れ替えが必要な障害による縮退運用から復旧する場合、現用系からもモデル情報をコピーして復旧するが、復旧完了までの間、学習モデルの一貫性を維持するため、学習リクエストを受け付けることができない | 学習モデルの一貫性, 可用性 | S2, S3, S5 |
Jubatus はオンライン学習アルゴリズムであるため、学習リクエストの到達順序が、学習モデル(解析結果)に影響を与える。(A → B の順序で学習する場合と、B → A の順番で学習する場合に結果が異なる)
Jubatus では学習したリクエストを取り消すことはできない。
つまり、JubatusサーバーA は学習が成功したが、JubatusサーバーB で学習が失敗した場合、JubatusサーバーA の学習内容を取り消し、全Jubatuサーバー で学習が成功するまで再学習を行わせるということはできない。
同一の学習リクエストを2回通知した場合、Jubatus のアルゴリズムによっては、同じデータでの学習を2回行ったこととなる。
つまり、JubatusサーバーA は学習が成功したが、JubatusサーバーB で学習が失敗した場合、JubatusサーバーA には学習リクエストを再送せず、学習が失敗した JubatuサーバーB のみに学習を行わせる必要がある。
モデル情報をファイル出力した場合に、同じデータ状態であっても出力ファイルが同じとは限らない。
モデル情報を比較するためには、ファイルにモデルを出力した上でセマンティックな比較が必要となり、比較にコストがかかる。
Jubatus は機械学習であるため、学習リクエストの成否を分析リクエストにより確認することができない。また、リクエストごとにログを出力をしていないため、ログからもリクエスト到達を確認できない。
