ZooKeeper入門を読んだ
ZooKeeperによる分散システム管理を読んだ。 ZooKeeperはコーディネーションサービスに位置づけられている。詳細は以下を読むと良さそう。
読んで感じたZooKeeperの不便な点
- JavaAPIで、Watch, 非同期ハンドラがオブジェクトで記述が長い
- 非同期APIでのリトライは別スレッド実行
- リトライ前に別の更新があると意図せず上書きしてしまう
- リトライ前に整合性の確認が必要
- トランザクションはZnode単位
- znode間に依存関係が存在する場合、整合性を保つのが難しい
- ACLがZnode単位で子ノードに継承されない
- マルチテナントのACL管理の責任がクライアント側になる
- 外部資源がある時にZooKeeperの値と整合性を保つのが難しい
- フェンシングで解決する
- ZooKeeper各サーバで提供する時点が異なる可能性がある
- ZooKeeperの変更通知などはZooKeeperからのみ取得する
- クライアント(A)が変更通知を受け取る(Watch)
- Aが別のクライアント(B)に変更通知
- Bから見たZooKeeperがAの受け取った変更通知前の可能性がある
- syncを実行して最新の状態にする
- ZooKeeperの変更通知などはZooKeeperからのみ取得する
- クラスタ再構成時アンサンブル内のズレにより歴史が逆戻る可能性がある
- 起動順序に注意する
- ズレを解消してから再構成を行なう
- 更新は同期実行され、その際に参照もロックされる
- 誤ったリーダを認識する時間が短期間存在しうる
- 新リーダ選出時に大幅に歴史が遅れているとSnapshotコピーが発生する
- リーダからコピーされネットワークの最適化はない
- DC, 電源系統毎の最低ノード数などの設定が難しい
- 障害を見越したクラスタが作りづらい
- group, weight で似た事が可能だが複雑な事は出来ない
- クライアントは起動時に識別子解決する
- サーバを再構成したらクライアントの再起動が必要
- ZooKeeperアンサンブル自体は静的に構成する必要がある
- 動的再構成は3.5系
- 動的構成する場合は事前に設定が必要
- 専用hostsを推奨しているがネットワーク冗長化のコストが高くなりそう
じゃあ別のオプションはって話だけど、わかってない。以下を読んで勉強しながら情報整理する。