Redisの負荷を1/3改善した話

Sat, 16 Dec 2023 12:00:00 +0900

はじめに

現在とある金融系Webメディアを運営する会社で、主にバックエンドの開発を担当しており、フロントエンド、インフラに関する業務も担当しています。

今回は、先輩エンジニアがデータ圧縮アルゴリズムを変更することでRedisの負荷を1/3に削減することに成功した実例をもとに記述して行きます。

先輩エンジニア(通称 ichigozero)は、vimmer, hacker, rustが得意なエンジニアです。（共通の趣味（おうちKubernetes）について語り合うのが日課です。笑）

サービスの概要

金融に関する記事を掲載するWebメディアを運用しています。

背景

現在運用しているメディアでは約100万記事掲載しており、直近一年で約50万記事と急激に増加し、Redisのパフォーマンスが劣化する課題がありました。

RedisのCPU使用率が高負荷状態になると、インスタンスを増やすことで一時的な対応を行っていました。

そこで根本的なアプローチをし、改善を行うとなったのが背景です。

*別アプローチも行っており、大幅な改善が見られました。別記事にて紹介する予定です。

前提

データ取得のフロー

サーバーでは、Redis->PostgreSQLという順番で問い合わせを行っています。

sequenceDiagram
 participant Client
 participant Server
 participant Redis
 participant PostgreSQL

 Client->Server: リクエスト

 Server->Redis: Redisからデータを取得
 Redis->Server: データが存在する場合、データを返す

 alt Redisからデータが存在しない場合
 Server->PostgreSQL: PostgreSQLからデータを取得
 Server->Redis: データを保存
 end

 Server->Client: レスポンス

解決策

データ圧縮アルゴリズムのGob形式から、パフォーマンスの高いアルゴリズムであるMgspack形式とSnappy形式を採用することで、大幅な改善に成功しました。

採用理由

データ圧縮のベンチマークについては、GobとMgspack + Snappyは同等のパフォーマンスです。

しかしバイトサイズを比較するとMgspack + SnappyがGobと比べ、半分のサイズに圧縮することができています。

結果、Redisのベンチマークを比べるとns/op(1回の操作にかかる平均時間)が約11%、B/op(1回の操作で消費する平均メモリ量)が約3%、allocs/op(1回の操作で生成される平均割り当て数)が約80%と大幅に改善したので採用しました。

ベンチマーク

データ圧縮のベンチマーク

BenchmarkJSONMarshal-12 	 45304	 25614 ns/op	 17984 B/op	 35 allocs/op
BenchmarkJSONUnmarshal-12 	 14763	 81072 ns/op	 31334 B/op	 74 allocs/op
BenchmarkGobMarshal-12 	 120536	 10011 ns/op	 29876 B/op	 51 allocs/op
BenchmarkGobUnmarshal-12 	 56109	 21446 ns/op	 36464 B/op	 243 allocs/op
BenchmarkMsgpackMarshal-12 	 373802	 2888 ns/op	 28005 B/op	 5 allocs/op
BenchmarkMsgpackUnmarshal-12 	 369746	 3261 ns/op	 15286 B/op	 34 allocs/op
BenchmarkMsgpackSnappyMarshal-12 	 55236	 21330 ns/op	 44386 B/op	 5 allocs/op
BenchmarkMsgpackSnappyUnmarshal-12 	 140824	 8507 ns/op	 28951 B/op	 35 allocs/op

Redisベンチマーク

Redis on Yossy's Notes