ノードサイズの選択

複数のクライアント接続によるスループット制限のあるワークロードを想定していますか?

その場合、Redis OSS バージョン 5.0.6 以降を実行している場合は、Redis OSS エンジンの代わりに利用可能な CPU をクライアント接続のオフロードに使用する AWS の拡張 I/O 機能を使用すると、スループットとレイテンシーを向上させることができます。Redis OSS バージョン 7.0.4 以降を実行している場合、拡張 I/O に加え、拡張 I/O 多重化によってさらに高速化されます。この機能では、各専用ネットワーク I/O スレッドが複数のクライアントからのコマンドを Redis OSS エンジンにパイプライン処理し、Redis OSS の処理能力を活用してコマンドをバッチ処理します。ElastiCache for Redis OSS v7.1 以降では、拡張 I/O スレッド機能を拡張して、プレゼンテーションレイヤーロジックも処理しました。プレゼンテーション層とは、クライアント入力を読み取るだけでなく、入力を Redis OSS バイナリコマンド形式に解析する拡張 I/O スレッドを指します。これをメインスレッドに転送して実行することで、パフォーマンスが向上します。詳細については、ブログ投稿とサポート対象バージョンのページを参照してください。

ごく一部のデータに定期的にアクセスするワークロードがありませんか。

このような場合、Redis OSS エンジンバージョン 6.2 以降で実行していれば、r6gd ノードタイプを選択することでデータ階層化を活用できます。データ階層化によって、最も長く使用されていないデータが SSD に保存されます。データが取得される際にレイテンシーのコストがわずかに発生しますが、コスト削減によって相殺されます。詳細については、「ElastiCache のデータ階層化」を参照してください。

詳細については、「サポートされているノードの種類」を参照してください。

データに必要となる合計メモリ量。

全般的な見積もりを得るには、キャッシュするアイテムのサイズを調べます。このサイズに、同時にキャッシュに保持するアイテムの数を掛けます。項目サイズを合理的に算出するには、まずキャッシュ項目をシリアル化して文字数をカウントします。その結果をクラスター内のシャードの数で割ります。

詳細については、「サポートされているノードの種類」を参照してください。

実行している Redis OSS のバージョン。

Redis OSS バージョン 2.8.22 より前では、フェイルオーバー、スナップショット、同期、およびレプリカをプライマリに昇格させるために、より多くのメモリを確保する必要があります。これは、十分な量のメモリを用意して、プロセスの実行時に生じるすべての書き込みに対応する必要があるためです。

Redis OSS バージョン 2.8.22 以降では、分岐なしの保存プロセスが使用されているため、以前のプロセスよりも使用可能なメモリが少なくて済みます。

詳細については次を参照してください:

アプリケーションでの書き込み負荷の大きさ。

書き込み量が多いアプリケーションでは、スナップショットの作成時またはフェイルオーバー時に、データでは使用されないより多くの使用可能メモリが必要となります。BGSAVE プロセスが実行されるたびに、BGSAVE プロセス中に発生するすべての書き込みに対応するために、データによって使用されない十分なメモリが必要です。例えば、スナップショットを作成するとき、プライマリクラスターをクラスター内のレプリカと同期させるとき、AOF (Append-Only File) 機能を有効にするときです。また、レプリカをプライマリに昇格させるときです (マルチ AZ が有効になっている場合)。さらに、最悪の場合、プロセス中にすべてのデータが書き換えられるときです。この場合、データのみに必要なメモリの 2 倍のサイズのノードインスタンスが必要です。

詳細については、「Valkey または Redis OSS スナップショットを作成するのに十分なメモリがあることを確認する」を参照してください。

スタンドアロンの Valkey または Redis OSS (クラスターモードが無効) クラスターを実装するか、複数のシャードを持つ Valkey または Redis OSS (クラスターモードが有効) クラスターを実装するか。

Valkey または Redis OSS (クラスターモードが無効) クラスター

Valkey または Redis OSS (クラスターモードが無効) クラスターを実装する場合は、ノードタイプがすべてのデータと前の項目で説明した必要なオーバーヘッドに対応できる必要があります。

例えば、すべてのアイテムの合計サイズを 12 GB と見積もったします。この場合、13.3 GB のメモリを搭載した cache.m3.xlarge ノードまたは 13.5 GB のメモリを搭載した cache.r3.large ノードを使用できます。ただし、BGSAVE オペレーションではより多くのメモリが必要になる場合があります。書き込み負荷の高いアプリケーションの場合、メモリ要件を少なくとも 24 GB に倍増します。したがって、27.9 GB のメモリを搭載した cache.m3.2xlarge または 30.5 GB のメモリを搭載した cache.r3.xlarge を使用します。

複数のシャードを持つ Valkey または Redis OSS (クラスターモードが有効)

複数のシャードを持つ Valkey または Redis OSS (クラスターモードが有効) クラスターを実装する場合は、ノードタイプが bytes-for-data-and-overhead / number-of-shards バイトのデータに対応できる必要があります。

例えば、すべてのアイテムの合計サイズが 12 GB で、シャードが 2 つあると見積もったとします。この場合、6.05 GB のメモリ (12 GB / 2) を搭載した cache.m3.large ノードを使用できます。ただし、BGSAVE オペレーションではより多くのメモリが必要になる場合があります。書き込み負荷の高いアプリケーションの場合、メモリ要件をシャードあたり少なくとも 12 GB に倍増します。したがって、13.3 GB のメモリを搭載した cache.m3.xlarge または 13.5 GB のメモリを搭載した cache.r3.large を使用します。

Local Zones を使用していますか?

[Local Zones] を使用すると、ElastiCache クラスターなどのリソースをユーザーの近くの複数の場所に配置できます。ただし、ノードサイズを選択する場合、容量要件にかかわらず、現時点では、使用可能なノードサイズは次のサイズに制限されることに注意してください。

それぞれ 3.22 GB のメモリと 2 つのスレッドを持つ 11 の cache.t2.medium ノード = 35.42 GB、22 スレッド。

それぞれ 6.42 GB のメモリと 2 つのスレッドを持つ 6 つの cache.m4.large ノード = 38.52 GB、12 スレッド。

それぞれ 12.3 GB のメモリと 2 つのスレッドを持つ 3 つの cache.r4.large ノード = 36.90 GB、6 スレッド。

それぞれ 14.28 GB のメモリと 4 つのスレッドを持つ 3 つの cache.m4.xlarge ノード = 42.84 GB、12 スレッド。