大規模環境でRedisキャッシュの性能を高める
(meetup.toast.com)Redisは、オンラインサービスのキャッシュに広く使われているインメモリ(In-Memory)データベースです。ですが、使い方を誤ると予期しない問題が起きたり、場合によっては大きな障害が発生したりすることもあります。私が最近書店に行った際、ある企業のSREチームで働く現役エンジニアに偶然会ったのですが、会話の中でその方が「Redisは実際のところ必要悪だ。いつかは関連する障害が一度くらい起きるものだと思いながら使うべきだ」と言うほどでした。
参考 - カカオ「Redis、使い方を間違えると危険」:
https://zdnet.co.kr/view/?no=20131119174125
参考 - クーパンの障害原因はオープンソースの「Redis DB」:
http://www.digitaltoday.co.kr/news/articleView.html?idxno=212904
このようにRedisは、よく理解したうえで繊細に扱わなければならないものです。
前置きが長くなりました。NHNがRedisConf 2020の発表内容をもとに、大規模トラフィック環境でRedisをキャッシュとして使う際に性能上の問題が発生しうるポイントを3つ指摘し、その解決法を説明した文書を紹介します。（韓国語）
-
Cache Stampede: キャッシュ領域には限りがあるため、保存されたデータには有効期限(TTL)を設定するのが一般的ですが、そのデータに対して読み取りリクエストが継続的に入っている最中にキャッシュの有効期限が切れると、瞬間的にその読み取りリクエストがDBへ集中し、それが再びRedisへの重複した書き込みリクエストとして殺到します。これをCache Stampedeと呼びますが、解決方法としては、確率分布に基づくアルゴリズムでTTL値をあらかじめ更新したり、あるいはデバウンス(Debounce、何度も繰り返されるイベントのうち最後のイベントだけを実行すること)の考え方を導入する方法があります。
-
Hot Keys: 1つのキーに読み取りが集中する場合も性能が低下することがあります。上の記事では、その対策としてキー名の前にPrefixを付けて複数のレプリカを作り、そのPrefix付きのレプリカへランダムに読み取りを分散させる方法を紹介しています。
-
Compression: サイズの大きいデータをRedisに保存する場合も性能低下が発生する可能性があります。このとき、適切な圧縮を適用するだけでも、速度とメモリ使用量の両面で大きな効果が得られます。適切な圧縮方法や圧縮率は状況や環境によって異なりうるため、これを適用する際には利用環境を再現したベンチマークテストが必須です。
1件のコメント
参考 - 上で言及した確率分布ベースのアルゴリズム（Probabilistic Early Recomputation）のサンプルコードが掲載されている記事:
https://engineering.linecorp.com/ko/blog/…