BT

Flickrは高可用性RedisにSentinelを選択した

| 作者: Benjamin Darfler フォローする 0 人のフォロワー , 翻訳者 尾崎 義尚 フォローする 0 人のフォロワー 投稿日 2014年8月20日. 推定読書時間: 2 分 |

原文(投稿日:2014/08/13)へのリンク

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の影響はなかったが、私たちはリスクよりも利益が大幅に上回ると確信している。と説明する。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT