4章状態変化の取り扱い
ZooKeeperアンサンブルの状態変化を知りたいというアプリケーションプロセスは珍しaくない。例えば、「1章 はじめに」で見た例では、バックアップマスタはプライマリマスタがクラッシュしたことを知らなければならないし、ワーカは、新しいタスクが自分に割り当てられたことを知らなければならない。もちろん、ZooKeeperのクライアントから定期的にZooKeeperアンサンブルにポーリングを行い、状態が変わったかを確認することもできる。しかし、この方法は特に、知りたい変化の頻度が低いときには効率が悪い。
例えば、バックアップマスタの件を考えてみよう。バックアップマスタは、プライマリマスタがクラッシュしたら役割を引き継ぐために、クラッシュしたことを知る必要がある。プライマリがクラッシュしてから復旧までの時間を短くするには、ポーリングの頻度を上げなければならない。例えば、アグレッシブなポーリングの例としては、50msに一度ぐらいになるだろう。この場合、ここのバックアップマスタは1秒に20回リクエストを送ることになる。複数のバックアップマスタがあれば、この頻度は台数倍になる。このくらいのトラフィックはZooKeeperのようなシステムにとっては楽に扱えるとはいえ、プライマリマスタのクラッシュが稀であることを考えると、このトラフィックのほとんどは無駄だということになる。ポーリングによるZooKeeperへのトラフィック量を減らすためにリクエスト間の時間を長く、例えば1秒にすることもできる。この場合問題になるのは、プライマリがクラッシュした際に、リカバーにかかる時間が長くなることである。
ZooKeeperが特定のイベントが起きた際に、それに興味を持つクライアントに通知することができれば、このようなチューニングの手間やポーリングのトラフィックをまるごと消すことができる。ZooKeeperが変化を扱うために提供する基本的なメカニズムが ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access