あなたにRedisは必要ないかもしれません

(viblo.se)

9 ポイント投稿者 GN⁺ 2025-03-10 | 5件のコメント | WhatsAppで共有

Redisは技術業界で最も好意的な評価を得ている技術の1つ
- 非常によく設計された優れた技術であり、それ自体に欠陥があるわけではないが、常に必要とは限らない
10年以上にわたり3社で同じパターンを見てきた:
- 問題が発生し、Redisが適しているように見えたが、実際には状況を改善できなかったり、根本的な問題を解決できなかったりした
- ただ複雑さのために複雑さを増やしただけだった

最初の事例: Tantanでの経験

Tantanは中国で2番目に大きいデーティングアプリで、PostgreSQLベースの50〜100台の高性能データベースサーバーを運用している
各サーバーはユーザーIDごとにシャーディングされており、特定ユーザーのデータは1台のサーバーにのみ保存される
問題状況
- 「スワイプ」回数を保存し、素早く更新しなければならない要件が発生
- 当初はRedisに保存するのが適切だと判断した
- 高性能なRedisサーバーが数台あれば十分だと考えて設定を進めた
再検討と解決策
- チーム内でRedisの代わりにPostgreSQLへ直接保存する案を議論した
- PostgreSQLサーバーの負荷はすでに高いため、追加負荷はわずかだろうと予想した
- PostgreSQLに保存した後も性能低下はなく、Redis導入は不要だった

2番目の事例: Bannerflowでの経験

背景
- Bannerflowは広告の制作・配信プラットフォーム
- 新しいマイクロサービスでFacebookのようなソーシャルネットワークへの広告配信を支援するため、Redisの導入を決定
問題状況
- Tantanに比べて負荷が著しく低い状況で、Redis導入が本当に必要だったのか不明だった
- 初期開発者が去った後、Redis導入理由を明確に説明できる人がいなかった
結果
- 負荷が低く、Redisは特に必要ではなかった
- 長期的にはRedisを削除するのが最善という結論に達した

3番目の事例: MAJORITYでの経験

背景
- MAJORITYはフィンテック企業で、外部API呼び出し結果をキャッシュするためにRedisを導入
- Redisは位置情報検索データをキャッシュし、処理速度を高めてコストを削減する目的で導入された
問題状況
- 同じデータがDB（Azure SQL）にも保存されていた
- Redis呼び出しをDB呼び出しに置き換えても、負荷増加はほとんどないと予想された
- ロック処理が必要でRedisを使い続けようとしたが、Azure SQLで十分に対応可能だった
結果
- Redis導入は不要だという結論に達した
- Redisの代わりにAzure SQLへ切り替える計画を立てた

結論

3つの事例はいずれも異なるドメイン、技術スタック、負荷条件で発生した
共通点は不要なRedis導入だったこと
Redis導入前には、実際の必要性と性能上の利点を十分に検討すべき
Dan McKinleyの「Choose Boring Technology」講演を推奨

5件のコメント

iolothebard 2025-03-10

Redisを使うかどうかはさておき、ドメインと永続化の間にキャッシュレイヤーを挟むこと（基本実装はバイパス）は、まったくオーバーエンジニアリングではない。ロギング、フェイクデータ、デバッグ、プロファイリング、あるいは本当のキャッシュにさえ使えるかもしれない…

nodelay 2025-03-10

+1 私も同意します。レイヤーを1つ追加するだけでも 余地 が生まれ、数多くのことを解決できる余白を作ってくれます。

galadbran 2025-03-10

Redisに問題があるというより、DBだけで十分なのに、なぜ追加の構成要素を導入して運用負担を増やす必要があるのか、という観点のようです。
やや簡潔に説明しているので、こういう視点も考えてみるべきだ、という程度で受け取るとよさそうですね。
アプリケーションロジックをシンプルに保ちながらRedisキャッシュを導入するほうが、よりよい選択になる状況もあるので、
状況に応じて選ぶ必要がありそうです。

zinisuni 2025-03-24

タイトルに釣られましたね。笑同感です~~

GN⁺ 2025-03-10

Hacker Newsの意見

2015年にUberで働いていたとき、郵便番号ベースの地理的分割を六角形ベースの方式へ切り替えようとしていた
- 都市を数十の郵便番号に分ける代わりに、数十万の六角形に分けて動的にエリアを生成する方式だった
- フェニックスで最初のローンチがあり、チームは需給価格システムをスケールさせるために徹夜した
- グローバル展開は遅延した
- Redisを好むエンジニアが多かった
- 価格サービスはRedisを基盤としており、数百万件のリクエストを処理していた
- コストが高く、スケーラビリティの問題もあった
- アルゴリズムを改善し、単一マシンで複数都市の動的エリアを計算できるようになった
- Isaacというエンジニアが週末の間に実装してデプロイした
Redisの過剰利用について議論があった
- Redisは素晴らしいが、使うとネットワーク遅延とシリアライズのオーバーヘッドが発生する
- データがすでに分割されているなら、通常のハッシュマップのほうがよい場合がある
- JavaにはConcurrentHashMap、Guava Caches、Caffeine Cachesなどがある
- ローカルキャッシュの実装は、ネットワークを使うよりほとんど常に速い
- Redisは過剰に使われる傾向がある
Redis利用の文化は、その人気に比べて発展してこなかった
- Redisはさまざまなデータ構造をサポートしており、企業文化が成熟するほど、より多くのパターンを学べる
- Redisのパターン集がないのは残念だ
Redisか非Redisかの問題ではなく、シリアライズしにくいデータを扱う問題である
- カウンター、ニュースフィード、チャットメッセージなどはRedisのほうが効率的な場合がある
- ほとんどの場合はMySQLでも十分に処理できる
ソフトウェア開発はしばしば他人のやり方を繰り返す傾向がある
- Memcachedから始まり、Redisへ発展してきた
- データベースの複雑さを避けるためにキャッシュを使う傾向がある
- データベースは依然として複雑で難しい
Redisは唯一の本番運用対応の「データ構造サーバー」である
- 複数のインスタンスから同じサービスにアクセスするときに有用である
キャッシュが不要なこともある
- キャッシュを導入せず、アーキテクチャ改善に集中した経験がある
RedisのAPIは素晴らしいが、運用上のリスクがある
- キャッシュとしては良いが、本番データストアとしては信頼できない
Redisの利用を勧めない傾向には驚かされる
- Redisは今でも優れたデータ構造と性能を提供している
Redisは一時的なキャッシュとしては問題ないが、トランザクションや分散ストレージには不十分である
- 分散ロックの問題について学ぶ必要がある