2025/07/10 12:46 Beating Redis with a Dictionary and Redis
やっほー、ロボ子！今日のITニュースはFrappe Frameworkの高速化についてじゃ。
Frappe Frameworkですか。どのようなフレームワークなのでしょう？
Frappe Frameworkは、スキーマを本番環境で定義・変更できる柔軟なWebフレームワークのことじゃ。でも、柔軟性が高い分、ランタイム計算が必要になるのじゃ。
なるほど。柔軟性とパフォーマンスはトレードオフになりがちですね。
そうなんじゃ。そこで、FrappeチームはRedisキャッシュを使って処理速度を上げようとしたのじゃ。
Redisは高速なキャッシュとしてよく使われますよね。
ところが、単一ドキュメントのAPIリクエストのFlamegraphによると、処理時間の約半分がドキュメントの取得以外のオーバーヘッドに費やされていたのじゃ。しかも、Redisへのクエリが多かったみたいじゃぞ。
えっ、Redisがボトルネックになっているんですか？
そうなんじゃ。Redisは高速なキャッシュなんじゃが、すべてのリクエストで使用されるデータを提供するためにRedisに依存しているため、ボトルネックになってしまったのじゃ。
それで、どうしたんですか？
そこで、Redisのクライアント側キャッシュを利用することにしたのじゃ！Redisクライアントは最近アクセスしたデータをローカルにキャッシュして、RedisのRESP3プロトコルは無効化メッセージをプッシュするのじゃ。
クライアント側でキャッシュを持つことで、Redisへのアクセスを減らせるんですね。
そういうことじゃ！クライアントは、フェッチされたデータをグローバル辞書のようにプロセスのメモリに保持して、Redisが無効化シグナルを送信するたびにローカルコピーを削除するのじゃ。
なるほど。データの整合性も保たれるんですね。
ただし、追跡するものを制限したり、ローカルキャッシュサイズを制限したり、本番環境で問題が発生した場合の緊急時対応を考慮する必要があるのじゃ。
考慮事項は色々あるんですね。
クライアント側のキャッシュを実装した後、最も頻繁なRedisアクセスでクライアント側のキャッシュを使用するように変更した結果、アプリケーションコードに触れることなく、全体で1.5倍の高速化が実現したのじゃ！
すごい！アプリケーションコードを変更せずに高速化できるのは素晴らしいですね。
ベンチマークの結果、get_metaのマイクロベンチマークで132倍の高速化、ERPNextのERP-Cワークロードで1.47倍の高速化が確認されたのじゃ。
132倍ですか！驚異的な数字ですね。
Frappe v16では、これらのパフォーマンス改善がリリースされて、ほとんどのワークロードで2倍以上の高速化が期待されているのじゃ！
それは楽しみですね。Frappe Frameworkの今後に期待です。
というわけで、今日のニュースはここまでじゃ！最後にロボ子、何か面白いこと言って！
えーと…、博士、Redisは「もう一度」という意味の名前だそうですよ。キャッシュだけに、何度もアクセスされるからでしょうか？
うまい！…けど、ちょっと寒いぞ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
