Flickrは先日、一貫性に関する懸念にもかかわらず、彼らのオフラインでタスク処理するサブシステムで自動化されたRedisフェールオーバーを提供するためにSentinelを展開していることを発表した。
昨年、Factualエンジニアで分散システムエキスパートのKyle Kingsbury氏は、彼のJespenシリーズの一部としてRedisの一貫性の特性を調査した。そこで彼は、Redisは書き込みの56%を投げて私たちに成功したと語り
、RedisとSentinelsを使ったシナリオを構築できることを示した。Kingsbury氏は、これはSentinelシステムにあった2つの問題の結果であることを指摘した。
ひとつめは、すべてのクライアントでパーティションの先頭への書き込みが失われた… ネットワークにドロップされた、それらはすべてn1に書き込まれ、後に降格されたため、そのウィンドウ内の書き込みは破棄された。2つめの問題は、split-brainによるものだった: n1とn5の両方は、パーティションが修復されるまでプライマリーアップであった。彼らがどのノードと話していたかによって、いくつかのクライアント書き込みは生き残り、その他の書き込みは失われる。
RedisのクリエーターであるSalvatore Sanfilippo氏は、問題を認識したが、データロスを最小化することはSentinel設計のゴールではなかったと言う。
明確にしたいのは、批判はよいものであり、Sentinelは最小のデータロスで抑えた複雑なネット分割を処理するのによくない方法であることを示している。これはゴールではなく、99%のケースではユーザーが自作スクリプトでフェールオーバーを処理する場合、Sentineが実現した障害検出とフェールオーバープロセスの処理よりもはるかに悪い状況になる。
Flickrはこの問題を認識しながらも、最初に決めたオフラインタスクを処理するサブシステムのアグレッシブなSLAを目標にしてSentinelへの移行を始めた。彼らは既存の手動フェールオーバー処理が目標の99.995%の稼働時間を実現できていないことに注目して、他のソリューションと比較しつつSentinelに落ち着いた。
Sentinelシステムとその構成の両方をテストした後、彼らは稼働率目標を達成できるように、4-6秒の自動フェールオーバーを提供できるように設計することができるようになった。テストの間、彼らはまたKingsbury氏の調査結果を複製することができた。しかしながら、FlickrエンジニアのRichard Thorn氏とShawn Cook氏は、私たちの本番環境では、split-brainの影響はなかったが、私たちはリスクよりも利益が大幅に上回ると確信している。
と説明する。