Amazon ElastiCache Redis のクラスターを適切にサイジングする際に考慮すべき 5 つのワークロード特性



この投稿では、Amazon ElastiCache ワークロードに適したノードサイズとクラスタートポロジを決定するプロセス、および考慮すべき重要な要素について説明します。この投稿は、Redis とそのコマンドについて十分な知識があり、Amazon ElastiCache for Redis とオンラインでのクラスターサイズ変更、スケーリング、Amazon EC2 から ElastiCache へのオンラインでの移行、汎用およびメモリ最適化ノード、強化された I/O などの機能を理解していることを前提としています。

基準の推奨事項

エントリーレベルの小規模 (2,000 件以下の TPS と 10 GB 以下のデータサイズ) とおよび規模 (TPS が 2,000〜20,000 件、データサイズが 10 GB〜100 GB) のキャッシュワークロード (一時的なスパイクも発生する可能性があるものを含む) 使用中は、次世代の汎用バースト可能 T3 標準キャッシュノードである T3 ファミリーからキャッシュノードを選択します。ワークロードに ElastiCache を使い始めたばかりの場合は、無料利用枠の T3.micro キャッシュノードから始めてください。負荷を増やすと、T3.medium キャッシュノードまで増加できます。

最新ノードタイプは最新世代の CPU とネットワーク機能をサポートしているため、中規模から大規模 (20,000 の TPS と100 GB のデータサイズを超える) ワークロードの場合は、M5 または R5 ファミリーからキャッシュノードを選択します。これらのキャッシュノードファミリーは Elastic Network Adapter (ENA) に基づく拡張ネットワーキングと 600 GiB を超えるメモリにより、最大 25 Gbps の総ネットワーク帯域幅を提供できます。R5 ノードタイプは R4 ノードタイプよりも vCPU あたり 5％ 多いメモリを提供し、GiB あたり 10％ 料金が低くなっています。さらに、R5 ノードタイプでは、R4 ノードタイプよりも約 20％ 高い CPU パフォーマンスを実現しています。

T3.medium では不十分な場合は、次のいずれかに移行できます。

• メモリを増やしてスループットを拡大する必要がある場合は、M5 キャッシュノード
• より多くのスループット、およびキャッシュノードあたり最大 35〜51％ 大きいメモリが必要な場合は、R5 キャッシュノード

ワークロードに適したノードサイズとクラスタートポロジをさらに絞り込むには、以下を行う必要があります。

• 5 つのワークロード特性を決定する
• ベンチマークテストを実行する

5 つのワークロード特性の決定

ほとんどのワークロード特性は、アプリケーションメトリクス、Redis の INFO コマンドを使用して、または Amazon CloudWatch メトリクスから決定できます。最大ノードメモリの詳細については、「Redis のノードタイプ固有のパラメータ」をご参照ください。

ElastiCache ノードの要件を決定するときは、以下を考慮してください。

• メモリ
• 予備または予約済みメモリ
• 可用性
• スケーリング
• データ

メモリ

潜在的なノードサイズの特定を開始する際に、次の考慮事項が役立ちます。

• データストアの完全なサイズ、キー、値のデータサイズを特定します。キャッシュするアイテムのサイズに、一度にキャッシュしておくアイテムの数を掛けることにより、必要なキャッシュメモリの概算を取得できます。
• データを保持するか、TTL を使用してキャッシュ内のキーを期限切れにするかを決定します。TTL により、ノードで明示的なメモリ管理が可能になります。
• キャッシュのみのユースケースなど重要なメトリクスである場合は、既存の優先キャッシュヒット率を特定します。クラスターのヒット率が適切であること、またはキーが頻繁に削除されないことを確認します。より多くのメモリ容量で、これが実現します。

予備または予約済みメモリ

データベースサイズを含むだけでなく、ノードサイズの少なくとも 25％ を維持する必要があります。レプリケーションでは、プライマリノードのメモリを使用します。さらに、キャッシュノードには約 10％〜15％ の予備のメモリが必要です。これは、予想外の負荷ピークやメモリフットプリントの増加を示す CloudWatch アラームによる早期検出のためです。この早期検出を利用して、特定の要件に応じてスケールアップするかスケールアウトするかを決定できます。

書き込みの多いアプリケーションでは、データが使用していないかなり多くの利用可能なメモリが必要になる場合があります。スナップショットを作成する際、またはレプリカの 1 つにフェイルオーバーを行う際に、この予備のメモリが必要となります。

可用性

お客様からの要求にクラスターが対応できるようにする必要がある場合は、1 つのプライマリ、少なくとも 2 つのレプリカを使用する、およびマルチ AZ を有効にして、レプリケーショングループをセットアップすることを検討してください。これはデータを保護するのに役立ち、何らかの理由でプライマリに障害が発生しても、クラスターは引き続きトラフィックを処理します。この場合、レプリカの 1 つが新しいプライマリになります。レプリカは読み込みスループットの向上にも役立ちます。

書き込み : 読み込みの比率が 50％ を超え、そのノードタイプの要求レート制限の 80％ に近い大量の書き込みプライマリには注意してください。書き込みが多いプライマリノードは、レプリカとの完全な同期をより頻繁に行う可能性があり、クラスターのパフォーマンスに影響します。頻繁に完全な同期を行うと、代わりに着信リクエストの処理に使用できたはずのプライマリノードへの時間が費やされます。

また、多くのレプリカと同期することでプライマリに不必要な負荷がかかるにも関わらず、可用性のためだけに多数のレプリカをスピンアップしたくなる気持ちを抑えることができます。プライマリノードごとにレプリカ数が 5 という制限があります。可用性を得るには、異なるアベイラビリティーゾーンの 1 つまたは 2 つのレプリカで十分です。

スケーリング

ElastiCache では、クラスターが引き続き要求を処理している間、垂直 (アップとダウン) および水平 (インとアウト) のオンラインスケーリングをサポートするクラスターモード対応の設定が可能です。プライマリノードで複数の同時クライアント (10,000 クライアントで 1 TPS、2,000 クライアントで 5 TPS のような 10,000 以上のクライエント) を使用する場合にはスケールアウトし、それらすべてにサービスを提供するために利用可能なコンピューティング能力があることを確認することをお勧めします。プライマリノードごとの最適な同時クライアントは、特定のユースケースと全体的なアプリケーションアーキテクチャによって異なります。スケールアウトは非常に多くの同時クライアントにサービスを行うだけでなく、データを複数のシャードに確実に分散します。このため、クラスター内のデータの可用性がさらに向上します。ただし、ビジネスが既存のクラスター設定でより高いパフォーマンスを必要とする場合には、スケールアップする必要があります。スケールアップは、個々のノードのパフォーマンスを向上させる手段を提供します。

2 つのクラスター設定 (クラスターモード無効とクラスターモード有効) 間の移行を、バックアップ/復元 (ソースクラスターの .rdb ファイルを利用するオフライン操作) でサポートします。したがって、垂直方向と水平方向の両方のスケーリングを可能にし、将来のニーズに対応できるため、デフォルトのクラスターモードが有効な設定を使用する必要があります。

スケールインまたはスケールダウンしてクラスターのサイズとメモリ容量を削減する場合は、新しい設定にデータおよび Redis のオーバーヘッドに十分なメモリがあることを確認してください。

データ

非常に高いレートで要求された、または突然非常に大きくなった複数のデータオブジェクトなどのホットキーがワークロードにあるかどうかを確認します。ホットキーで、キャッシュエンジンが高いパフォーマンスを維持したり、すべての要求に対応する能力を損なったりする可能性があります。このユースケースでは、推奨されるクラスターモード対応の設定を使用していると想定して、負荷をさまざまなシャードに分散し、ホットキーを 1 つのシャードに保持し、残りのキーを他のシャードに保持して、他の受信要求がブロックされないようにすることができます。複数のホットキーがある場合、それらをシャード全体に分散することを検討してください。

加えて、読み込みと書き込みのワークロードを分離することを検討してください。この分離により、アプリケーションの成長に応じてレプリカを追加して、読み込みをスケーリングできるようになります。レプリカは最終的に整合性のある読み込みを行います。ElastiCache にはクラスターモード無効設定のレプリカエンドポイントがあります。これは、クラスター上の読み込みトラフィックを負荷分散して、読み書きの分離を可能にするものです。さらに、クラスターモード対応の一部の Redis クライアントでは、トラフィックをレプリカにルーティングできます。このメカニズムについては、特定の Redis クライアントドキュメントをご確認ください。

ベンチマークテストの実行

ケースに適用可能なパラメータを決定したら、最適なキャッシュノードとクラスタートポロジをいくつか特定する必要があります。2 つの large キャッシュノードの選択は、xlarge キャッシュノード 1 つよりも優れている場合とそうでない場合があります。クライアントアプリケーションを設定し、本番のような環境でワークロードの特性に合わせて、それぞれにベンチマークテストを実行します。通常の運用ワークロードパターンの適切なベースラインを作成するには、運用データとトラフィックパターンを使ったベンチマークテストを 14 日間以上実行する必要があります。ベースラインを取得したら、休日、ブラックフライデーの売上などの季節性をワークロードに含め、実際のワークロードパターンをより正確に反映するパフォーマンスベンチマーク結果を取得する必要があります。ベンチマークテストの結果に基づいて、Redis ワークロードに適したノードサイズとクラスター設定を選択できます。

ElastiCache のベンチマーク

ElastiCache では、オープンソースのベンチマークツールの rpc-perf と redis-benchmark を使用したベンチマーク結果を公開しています。ベンチマークの最初のエクササイズでは、R4 キャッシュノードと最適化済み R5 キャッシュノードを比較します。これについては、次のセクションで詳しく説明します。詳細については、「Amazon ElastiCache performance boost with Amazon EC2 M5 and R5 instances」をご覧ください。ベンチマークの 2 つ目のエクササイズは R5 ファミリーで実施し、強化された I/O を備えていない Redis 5.0.0 と、強化された I/O を備える Redis 5.0.3 とを比較します。詳細については、「Boosting application performance and reducing costs with Amazon ElastiCache for Redis」をご参照ください。

R4 と最適化済み R5 キャッシュノードの比較

このベンチマークには、1470 万個の一意のキー、200 バイトの文字列値、80％ の取得、20％ のセットがあり、コマンドのパイプライン処理はありませんでした。この投稿では、同じアベイラビリティーゾーンの ElastiCache R5 インスタンスに接続する 20 個のクライアントインスタンスでベンチマークが実行されました。

次のテーブルは、ベンチマークテストのセットアップをまとめたものです。

ベンチマークの結果は、最新の R5 キャッシュノードが同じサイズの R4 インスタンスよりも 1 秒あたり 59〜144％ 多いトランザクションをサポートすることを示しました。R5 キャッシュノードでは、平均 (p50) とテール (p99) のレイテンシーが最大 23％ 削減し、平均のレイテンシーは 350 マイクロ秒になりました。次のテーブルは、このエクササイズのデータをまとめたものです。

まとめ

ワークロードに適したノードサイズとクラスター設定の選択は、ElastiCache に移行する前だけでなく、定期的に行う必要がある重要なアクティビティです。1 度行うだけでよいアクティビティではありません。年間を通じて、特に重要な今後のビジネスイベントの前には十分な余裕を持って、頻繁に行う必要があります。この結果、チームはトラフィックの規模と予想される増加をより適切に処理する準備ができ、シームレスに顧客にサービスを提供し続けることが可能となります。

質問やご感想があれば、AWS ElastiCache ディスカッションフォーラム、またはコメント欄にご記入ください。

著者について

Anumeha はアマゾン ウェブ サービスのプロダクトマネージャーです。