新世代ElastiCache for Redisの性能：マルチコアを効率的に利用できるRedis7.1+Graviton3

SREチームの中島です。

こちらは Applibot Advent Calendar 2023 15日目の記事になります。前回の記事はコチラです。

サイバーエージェントグループでは、AWSが提供するArmベースのプロセッサであるGravitonの積極的な活用を行っています。

弊社アプリボットでも、Amazon RDSやAmazon ElastiCacheがGravitonプロセッサをサポートし始めた直後(2020年頃)からこれらを積極的に活用してきました。初期の導入から数年が経過しましたが、特に大きな問題は発生しておらず、パフォーマンスの向上やコスト削減に大いに貢献しています。

この記事では、ElastiCacheで2023年8月に利用可能となったm7g系を始めとするGraviton3インスタンスと、2023年11月14日にリリースされたばかりのElastiCache for Redis7.1のパフォーマンスに関する検証結果を共有します。

ElastiCache for Redisのバージョンとインスタンスタイプについて

まず、Amazon ElastiCache for RedisにおけるRedisのバージョンと機能、インスタンスタイプについて確認します。

ElastiCache for Redisでは、5.0.6以降でEnhanced I/O、Redis 7.0.4以降でEnhanced I/O Multiplexingの拡張が利用できるようになっており、インスタンスタイプにより対応している内容が違います。

特に注目したいのは、新世代のGraviton3インスタンスであるm7g系のパフォーマンスと、Redis 7.0.4以降で利用可能になったEnhanced I/O Multiplexingの効果です。

かつてのRedisではエンジンがシングルスレッド動作している関係上、マシンをスケールアップさせて利用できるCPUコア数を増やしてもそれほど性能に反映されないという特性があり、弊社での過去の検証結果でもr5.largeとr5.xlargeでさほど差がない結果が出ています。そのような理由から、largeなど低コア数でのインスタンス運用をされているプロジェクトも多かったと思います。

m7gインスタンスとRedis 7の圧倒的パフォーマンス

では、早速になりますが各インスタンスの性能をRPSベースで比較した結果をご覧いただきます。今回はmemtier_benchmarkを利用して検証を行いました（コマンドなどの詳細は後述します）。

Enhanced I/O Multiplexingの効果により、マルチコア環境のRedis7系での利用時に数倍以上のパフォーマンスが発揮されているのがわかりました。特に直近の7.1.0へのアップデートでは、m7g.2xlarge以上（物理8コア以上）でさらに性能が発揮されています。”up to 72% increased throughput” (AWSブログから抜粋) とうたわれていましたが、間違いではなかったようです。

実際にm7g.2xlargeにEngineCPUUtilizationが100%に張り付くような負荷をかけた場合のRedis7.0.7とRedis7.1.0のメトリクスを比較した場合、インスタンス全体のCPUがRedis7.1.0の場合により多く使われていることが確認でき、バージョンアップにより多くのコアを効率的に使うことでRPSが向上している様子がわかりました。

m6g世代以前のマルチコアインスタンスでもRedis7.1へのアップデートでかなりの性能向上が見込めるため、RIなどで前世代のインスタンスに利用が固定されている場合も嬉しいアップデートと言えるのではないでしょうか。Redis7.1の利用により、今までRedisのスケールにおいては選択肢にはあまり含めなかったスケールアップによるCPU負荷への対応が現実的に可能になっているため、贅沢を言えばElastiCacheにもRIのサイズ柔軟性が欲しいところです。

今回は対象のElastiCacheインスタンスに対し、同一AZ上のc7gn.4xlargeインスタンスから以下のコマンドを実行しています。

docker run -v /root/memtier:/app -it redislabs/memtier_benchmark:edge \
    -s <REDISHOST> -p 6379 -P redis \
    --data-size=512 --threads 16 \
    -c 2000 \
    --test-time=600 \
    --key-maximum=160000 \
    --ratio=1:1 \
    --key-pattern=S:S

表の結果からは割愛していますが、クライアントの同時接続数が増えるほどレイテンシが悪化していく傾向にあります。今回の結果はすべての結果でレイテンシの最大値5ms〜10ms程度に収まる範囲の結果としてクライアント数2000の結果をまとめました。
また、ElastiCacheは性能に対してネットワークの使用量が超過しがちのため、検証したい負荷に合わせてdatasizeを変更する際はご注意ください。ノードタイプの説明にも以下のようにあり(link)、EC2ベースのnetworkI/Oクレジットが適用されます。
> Instance types with burstable network performance use a network I/O credit mechanism to burst beyond their baseline bandwidth on a best-effort basis.

幸い、ElastiCacheがデフォルトで用意してくれているメトリクスにネットワーク利用の超過を示すNetworkBandwidthAllowanceExceeded (link)　がありますので、そちらをきちんと把握しておくのがよいでしょう。

まとめ

• ElastiCache for Redis 7.1 において、4物理コア以上のインスタンスは大きな性能向上が見込める。
• Graviton3インスタンスであるm7gは平均して同じサイズのm5の1.5倍程度のパフォーマンスを期待できる。xlargeでは特に差が大きい。

実はRedis7.1がリリースする前の段階でRedis7+Graviton3の性能を検証した内容を書いていたのですが、書き上がる直前に出た7.1での性能向上を見て急遽記事を追記しました。昨今コスト削減に関する取り組みも各所で行われていますが、このようなクラウド基盤側の性能向上を積極的に取り込むことでも費用の削減が可能です。

その後にさらにElastiCache Serverlessが発表されましたが、Redisの対応バージョンが7.1からになっていることを見ると、Serverlessのような機能を効率よく提供するための機能改善がクラウドのバックエンドでも行われていることが伺えて興味深いです。

弊社では既に上記ElastiCacheでのm7g系の投入と、コンテナ環境のベースとしてEC2でのGraviton3利用も進んでいます。今回の結果を受けて、Redis7.1以降へのアップデートを進めて行ければと思っています。マネージドなサービスではGravitonインスタンス導入のハードルも低いため、ぜひチャレンジしてみてください。

ここまでお読みいただいてありがとうございました。今回の結果が皆さんの管理するプロジェクトでも新世代インスタンスの導入を進める一助となれば幸いです。発表されたばかりのGraviton4も待ち遠しいですね。

nakashimahiroki