Redis® and the secret of fluctuating readsの翻訳です。

2021年7月13日

Redis®と変動するリードの秘密

楽な日もある。ある日はスループットが低下し、Redis®*の不良のせいにします。Aivenがどのようにこの問題を解決できるかをご覧ください。

オフィスでバーボンを飲みながらキーボードを拭いていると、電話が鳴った。最近の顧客からで、問題があるとのことだった。

その顧客の既読率が奇妙に変動していたのだ。[Redis]®*(https://aiven.io/redis"Aiven for Redis product page")が負荷に耐えられないのだそうだ。彼らはAiven for Redisのプレミアムプランをテストしていたのですが、彼らの期待がいかに満たされていなかったか、今私は耳打ちされていました。彼らは強力なデータベースを求めていたが、三流のフラッターボックスのような恥ずかしいものを提供されていると言っていた。

私は気の利いた反論はひとまず棚上げした。その代わり、トレンチコートとフェドーラ（オフィスの空調はいつも問題だ）を手に取り、キーボードを再び接続し、彼らのクラウドに接続した。

数時間いろいろと見て回った後、私は顧客よりもずっと不思議に思った。Redisは非常に安定している。高負荷にも簡単に対応し、顧客がプレミアムプラン（プライマリ1台とレプリカ5台からなるサーバー6台）に拡張したことで、十分すぎるほどの負荷がかかるはずだった。そして、最悪の場合、負荷の増加でデータベースが座屈したときに、急降下するポイントを見ることができるはずだ。

その代わりに、グラフは山脈を描き、読み込みは上昇し、下降し、そしてまた上昇した。Redisがこのような動きをするのを見たことがなかった。

私はその顧客に電話をかけ直し、徹底的に問い詰めた。彼らが何を知っているのか知りたかった。彼らはRedisに対して何をしていたのか？その顧客は私の尋問に満足しなかったが、私は彼らがカスタムのテスト・スイートを使っていることを突き止めた。私は驚いた。

そして案の定、どこに鼻を突っ込めばいいのかわかったので、私はその匂いを嗅ぎつけた。顧客テストは計画通りに進んでいなかった。

顧客専用のテスト・ハーネスを使うのではなく、業界標準のmemtier_benchmarkに公平な意見を求めた。私は3つのAivenプランをテストした：ビジネス（プライマリ＋レプリカ）、プレミアム（プライマリ＋2レプリカ）、カスタム（プライマリ＋5レプリカ）だ。プライマリ・ノードへのWRITEレートが一貫していること、レプリカ全体のREADレートが、レプリカが増えるにつれてプラン間でどんどん速くなっていることを確認する必要がありました。

最初は静かでした。WRITEレートは、2500バイトのペイロードサイズで10Mエントリを書き込もうとした場合、3つのサービスプランで一貫していました。サービスプランのレプリカ数が増えるにつれて、追加IOPSがデータを複製するのに役立つので、期待される書き込み速度は低下するはずです。

以下は、Redisにデータを書き込み、それをベンチマークするスクリプトです：

 -p <PORT> -a <PASSWORD> --hide-histogram --key-maximum=10000000  \
 -n allkeys -d 2500 --key-pattern=P:P --ratio=1:0`Copy to clipboard

WRITEオペレーションが終わったので、READレートのベンチマークに移った。もちろん、3つのAivenサービスプランの間で怪しいことが起こっていないことを確認するために、PRIMARYノードに対してREADSを行い、一貫して行いました。予想通り、READSはすべてのプランタイプで狭い範囲に収まった。

を実行する。
 -s <PRIMARY / REPLICA HOST> -p <PORT> -a <PASSWORD>  \
 --hide-histogram ˶ -t 30 -c 10 --pipeline=1 --ratio=0:1 ˶ - test-time=180` ˶ -p
 -test-time=180`クリップボードにコピーする

最後に、レプリカ・ノードに対するREADレートを直接テストしてみた。

ここまでは順調だ。ビジネス・プラン（青線）のリード・パフォーマンスは、予想通りプライマリ・ノードのそれに匹敵している。2つのレプリカを持つプレミアム・プラン（赤線）のスループットはほぼ2倍（正確には2倍ではないが、予想通り）であり、良好である！

その後、カスタム6ノードプラン（緑線）のスループットが南下し、状況は一転した。私はあごが外れた。どうなっているんだ？ノードの数が多いのに、わずかなパフォーマンス向上しか得られないとは......。

タオルを投げる準備ができた矢先、私はこの探求がどこから始まったのかを思い出した。ヒントはベンチマーク・テストそのものにあった。顧客が自前のソリューションでひどいメトリクスを示していたのと同じように、私のソリューションも苦戦していた！

もちろんだ！もちろん！テスト自体がボトルネックになっているのであれば、同じ接続で同じテストを行い、自動的に毎秒より多くのオペレーションを生成することは期待できない。バケツが大きくなったからといって、同じホースで同じ速度でバケツを満たすことは期待できない！くそう！

というわけで、別のVMで2つ目の『memtier_benchmark』を立ち上げ、2本のホースでバケツに水を入れ始めた。

という感じだった！

つまり、テストが失敗したのはRedisのせいではなく、テストの設定と実行方法のせいだったのだ。私は満足げにため息をつき、グラスを空けた。

私は今、自分自身の問題に直面していた。どうすれば顧客に、自分たちが問題を引き起こしていることを知らせることができるだろうか？私は考えるのを助けるために、2本目のバーボンを開けた。

翌朝、私は二日酔いだったが、より良い答えが見つからなかったので、ただ顧客に電話をかけ、私が発見したことをわかりやすく説明した。確かに彼らは不満そうだったが、私はメッセージを伝えた。さらに、テストの問題が修正された後、彼らは私の仕事とRedisにとても満足し、何の問題もなくプレミアム・プランへのアップグレードを完了した。

Redisは、接続するだけで機能する信頼性の高いソリューションであり、Aivenは他のどのクラウド企業よりも優れたサポートを提供してくれることが改めて証明されたのです。この点についてはお好きなように。

まとめ

自分の直感を信じて歩けば、思いがけないところで答えが見つかるかもしれない。そして、翌朝すっきりした頭でいたいなら、バーボンはやめましょう...。

この記事が何について書かれたものなのか分からなかった人は、こちらを見てほしい：Redis入門.

--

Aivenのサービスをまだご利用でない方は、https://console.aiven.io/signupから無料トライアルにお申し込みください。そうしないと、問題に直面するかもしれません。

いずれにせよ、私たちから目を離さないようにしてください。私たちのchangelogとblogのRSSフィード、または私たちのLinkedInとTwitterのアカウントをフォローしてください。

• RedisはRedis Ltd.の商標です。RedisはRedis Ltd.の商標です。Aivenによる使用は参照目的のみであり、RedisとAiven Oyの間のいかなる後援、承認、提携を示すものではありません。