「★」はやること。
- standalone で利用するユースケースはそもそも無いかもしれなが、プロセスの配置パターンは以下の通り。
| client | keeper | server | zookeeper |
|---|---|---|---|
| A : 1 | - | A : 1 | - |
| A : N | - | A : 1 | - |
| A : 1 | - | B : 1 | - |
| A : N | - | B : 1 | - |
- serverプロセス を act /standby で冗長化する場合、適切なタイミングでのモデルの永続化が必要。
- serverプロセス を act / act で冗長化する場合も、永続化が必要か。
-
zookeeper
-
冗長モードで利用する。
-
zookeeper と 各プロセス との同居ポリシーは? -> HBase等を確認★
-
server
-
keeper, zookeeper が所在を知ることになるので、同一筐体に複数プロセスなどでも自由でOK。
-
I/O や NW がボトルネックになるので、1サーバー1プロセスで、複数サーバーに分散させるのが一般的ですかね。
-
そもそも keeper がボトルネックだと、server はスッカスカになるんではなかろうか。
-
keeper がボトルネックではないと仮定すると、server をどんどんスケールアウトしていくような運用が想定される。
-
keeper ... 要検討/調査
-
client からのリクエストを server に必ず届けることを保証するか否か。
-
ユースケースを考えて、client からどのようにリクエストを受け付けるパターンがあるかを抽出すると、システム構成も検討しやすいかも★
-
client ... 要検討/調査
-
利用シーンは大きく分けると以下。analyze と update の違いでもケースが違う。
-
stream的にリクエストからの一連の流れで、Jubatusへリクエストする。
-
Jubatusへのリクエストをキューイング。Jubatusへの処理は非同期で行う。
-
バッチ処理。ある特定の時間単位で大量にJubatusへリクエストする。
-
利用シーンによって構成は変わる。-> ★ケースを洗い出す。
-
client と keeper の同居について ... 要検討/調査
-
client が zk を覗いてから keeper へリクエストを投げる場合は、別筐体・プロセス数不一致でも良い。
-
client は keeper の所在を知らなくても良いが、これだと、client の処理がネックになりそう。
-
jubatus(keeper)にアプリケーションの動作が引きずられないという意味では、こっちが健全なのかも。
-
ここを見ると、client から複数 keeper とあるが、あったっけか? -> 解決
-
client で keeper の所在を知る必要があるアプリであれば、keeper が増減するごとにアプリで何かしらする必要がある。