翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ノードサイズの選択
ElastiCache クラスター用に選択したノードサイズは、コスト、パフォーマンス、耐障害性に影響します。
ノードサイズ (Valkey と Redis OSS）
Graviton プロセッサの利点については、「AWS Graviton プロセッサ
以下の質問に回答すると、Valkey または Redis のOSS実装に必要な最小ノードタイプを判断するのに役立ちます。
-
複数のクライアント接続によるスループット制限のあるワークロードを想定していますか?
この場合、Redis OSSバージョン 5.0.6 以降を実行している場合は、Redis OSS エンジンの代わりにクライアント接続のオフロードに使用可能な拡張 I/O 機能CPUsを使用すると、スループットとレイテンシーが向上します。Redis OSSバージョン 7.0.4 以降を実行している場合は、拡張 I/O に加えて、拡張 I/O 多重化によってさらに高速化されます。各専用ネットワーク IO スレッドは、複数のクライアントから Redis OSS エンジンにコマンドをパイプラインし、Redis OSSの 機能を利用してコマンドをバッチで効率的に処理します。 ElastiCache (Redis OSS) v7.1 以降では、拡張 I/O スレッド機能を拡張して、プレゼンテーションレイヤーロジックも処理しました。プレゼンテーションレイヤーとは、拡張 I/O スレッドがクライアント入力を読み取るだけでなく、入力を Redis OSSバイナリコマンド形式に解析し、実行のためにメインスレッドに転送してパフォーマンスを向上させるということです。詳細については、ブログ投稿
とサポート対象バージョンのページを参照してください。 -
ごく一部のデータに定期的にアクセスするワークロードがありませんか。
この場合、Redis OSS エンジンバージョン 6.2 以降で実行している場合は、r6gd ノードタイプを選択してデータ階層化を活用できます。データ階層化では、最近使用されていないデータは に保存されますSSD。データが取得される際にレイテンシーのコストがわずかに発生しますが、コスト削減によって相殺されます。詳細については、「のデータ階層化 ElastiCache」を参照してください。
詳細については、「サポートされているノードの種類」を参照してください。
-
データに必要となる合計メモリ量。
全般的な見積もりを得るには、キャッシュするアイテムのサイズを調べます。このサイズに、同時にキャッシュに保持するアイテムの数を掛けます。項目サイズを合理的に算出するには、まずキャッシュ項目をシリアル化して文字数をカウントします。その結果をクラスター内のシャードの数で割ります。
詳細については、「サポートされているノードの種類」を参照してください。
-
どのバージョンの Redis を実行OSSしていますか？
2.8.22 より前の Redis OSSバージョンでは、フェイルオーバー、スナップショット、同期、レプリカのプライマリオペレーションへの昇格のためにより多くのメモリを予約する必要があります。これは、十分な量のメモリを用意して、プロセスの実行時に生じるすべての書き込みに対応する必要があるためです。
Redis OSSバージョン 2.8.22 以降では、以前のプロセスよりも少ないメモリを必要とするフォークレス保存プロセスを使用します。
詳細については、次を参照してください。
-
アプリケーションでの書き込み負荷の大きさ。
書き込み量が多いアプリケーションでは、スナップショットの作成時またはフェイルオーバー時に、データでは使用されないより多くの使用可能メモリが必要となります。
BGSAVEプロセスが実行されるたびに、BGSAVEプロセス中に発生するすべての書き込みに対応するために、データによって使用されない十分なメモリが必要です。例としては、スナップショットを作成する場合、プライマリクラスターをクラスター内のレプリカと同期する場合、および追加専用ファイル (AOF) 機能を有効にする場合などがあります。また、レプリカをプライマリに昇格させるときです (マルチ 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 を使用していますか?
ローカルゾーンを使用すると、 ElastiCache クラスターなどのリソースをユーザーに近い複数の場所に配置できます。ただし、ノードサイズを選択する場合、容量要件にかかわらず、現時点では、使用可能なノードサイズは次のサイズに制限されることに注意してください。
-
現行世代:
M5 ノードタイプ:
cache.m5.large、cache.m5.xlarge、cache.m5.2xlarge、cache.m5.4xlarge、cache.m5.12xlarge、cache.m5.24xlargeR5 ノードタイプ:
cache.r5.large、cache.r5.xlarge、cache.r5.2xlarge、cache.r5.4xlarge、cache.r5.12xlarge、cache.r5.24xlargeT3 ノードタイプ:
cache.t3.micro、cache.t3.small、cache.t3.medium
-
クラスターの実行中に、メモリ使用量、プロセッサ使用率、キャッシュヒット、キャッシュミスのメトリクスをモニタリングできます。メトリクスは に発行されます CloudWatch。クラスターに必要なヒット率がないことや、キーが頻繁に削除されていることに気付くことがあります。このような場合は、より大きな CPU とメモリ仕様を持つ別のノードサイズを選択できます。
CPU 使用状況をモニタリングするときは、Valkey と Redis OSSがシングルスレッドであることに注意してください。したがって、報告されたCPU使用量にCPUコア数を掛けて、実際の使用量を取得します。例えば、使用率が 20% とCPU報告される 4 コアは、実際には Redis が 80% の使用率で実行OSSしている 1 つのコアです。
ノードサイズ (Memcached)
Memcached クラスターには 1 つまたは複数のノードが含まれ、クラスターのデータは複数のノードに分割されます。このため、クラスターで必要なメモリとノードで必要なメモリには関連性がありますが、同じではありません。ノードの数を減らすか、より多くのより小さなノードを確保することにより、必要なクラスターメモリの容量を実現できます。また、ニーズの変化に応じてクラスターへのノードの追加や削除を行い、必要なものだけに支払うことができます。
クラスターの合計メモリ容量は、システムオーバーヘッドを差し引いた後に、クラスター内のノード数に各ノードのRAM容量を掛けて計算されます。各ノードの容量はノードタイプに基づいています。
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)クラスター内のノード数は、Memcached を実行するクラスターの可用性の重要な要素です。1 つのキャッシュノードで障害が発生した場合、アプリケーションの可用性とバックエンドデータベースの負荷に影響を与える可能性があります。このような場合、 ElastiCache は障害が発生したノードの代替をプロビジョニングし、再入力されます。この可用性への影響を小さくするには、使用している大容量のノードを減らすのではなく、メモリとコンピューティングの容量をより小さい容量のより多くのノードに分散させます。
35 GB のキャッシュメモリが必要なシナリオでは、以下のいずれかを設定できます。
-
それぞれ 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 スレッド。
ノードオプションの比較 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ノードの種類 | メモリ (GiB) | コア | 時間あたりのコスト* | 必要なノード | 合計メモリ (GiB) | 合計コア | 毎月のコスト | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.t2.medium | 3.22 | 2 | 0.068 USD | 11 | 35.42 | 22 | 538.56 USD | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m4.large | 6.42 | 2 | 0.156 USD | 6 | 38.52 | 12 | 673.92 USD | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m4.xlarge | 14.28 | 4 | 0.311 USD | 3 | 42.84 | 12 | $ 671.76 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m5.xlarge | 12.93 | 4 | 0.311 USD | 3 | 38.81 | 12 | $ 671.76 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m6g.large | 6.85 | 2 | $ 0.147 | 6 | 41.1 | 12 | 635 ドル | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.r4.large | 12.3 | 2 | 0.228 USD | 3 | 36.9 | 6 | $ 492.48 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.r5.large | 13.07 | 2 | 0.216 USD | 3 | 39.22 | 6 | 466.56 USD | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.r6g.large | 13.07 | 2 | $ 0.205 | 3 | 42.12 | 6 | 442 ドル | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| * 2020 年 10 月 8 日現在のノードあたりの時間あたりのコスト。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 30 日 (720 時間) の使用率 100% の場合†の 1 か月あたりのコスト。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
これらのオプションは、それぞれ同様のメモリ容量を提供しますが、コンピューティング容量とコストは異なります。特定のオプションのコストを比較するには、「Amazon ElastiCache 料金
Memcached を実行するクラスターでは、各ノードの使用可能なメモリの一部は接続のオーバーヘッド用に使用されます。詳細については、「Memcached 接続オーバーヘッド」を参照してください。
複数のノードを使用して、それらの間でキーを分散させる必要があります。各ノードには、独自のエンドポイントがあります。エンドポイント管理を容易にするために、 ElastiCache Auto Discovery 機能を使用できます。この機能を使用すると、クライアントプログラムはクラスター内のすべてのノードを自動的に識別できます。詳細については、「クラスター内のノードを自動的に識別する (Memcached)」を参照してください。
場合によっては、必要な容量がわからないことがあります。その場合、テストのために、1 つの cache.m5.large ノードから始めることをお勧めします。次に、Amazon に公開されている ElastiCache メトリクスを使用して、メモリ使用量、CPU使用率、キャッシュヒット率をモニタリングします CloudWatch。の CloudWatch メトリクスの詳細については ElastiCache、「」を参照してください CloudWatch メトリクスの使用のモニタリング。本番稼働ワークロードや大規模なワークロードの場合、R5 ノードは最高のパフォーマンスとRAMコスト価値を提供します。
クラスターに必要なヒット率がない場合は、ノードを簡単に追加して、クラスターで使用可能なメモリの合計を増やすことができます。
クラスターが にバインドされているCPUが、十分なヒット率がある場合は、より多くのコンピューティング能力を提供するノードタイプで新しいクラスターを設定します。
