翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ノードサイズの選択
ElastiCache クラスターに選択するノードのサイズによって、コスト、パフォーマンス、耐障害性が変わります。
## ノードサイズ (Valkey および Redis OSS)
Graviton プロセッサの利点については、「[AWS Graviton プロセッサ](https://aws.amazon.com/pm/ec2-graviton/)」を参照してください。
以下の項目に回答することで、Valkey または Redis OSS の実装に必要な最小ノードタイプを決定できます。
+ 複数のクライアント接続によるスループット制限のあるワークロードを想定していますか?
その場合、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 スレッドを指します。これをメインスレッドに転送して実行することで、パフォーマンスが向上します。詳細については、[ブログ投稿](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/)と[サポート対象バージョン](VersionManagement.md#supported-engine-versions)のページを参照してください。
+ ごく一部のデータに定期的にアクセスするワークロードがありませんか。
このような場合、Redis OSS エンジンバージョン 6.2 以降で実行していれば、r6gd ノードタイプを選択することでデータ階層化を活用できます。データ階層化によって、最も長く使用されていないデータが SSD に保存されます。データが取得される際にレイテンシーのコストがわずかに発生しますが、コスト削減によって相殺されます。詳細については、「[ElastiCache のデータ階層化](data-tiering.md)」を参照してください。
詳細については、「[サポートされているノードの種類](CacheNodes.SupportedTypes.md)」を参照してください。
+ データに必要となる合計メモリ量。
全般的な見積もりを得るには、キャッシュするアイテムのサイズを調べます。このサイズに、同時にキャッシュに保持するアイテムの数を掛けます。項目サイズを合理的に算出するには、まずキャッシュ項目をシリアル化して文字数をカウントします。その結果をクラスター内のシャードの数で割ります。
詳細については、「[サポートされているノードの種類](CacheNodes.SupportedTypes.md)」を参照してください。
+ 実行している Redis OSS のバージョン。
Redis OSS バージョン 2.8.22 より前では、フェイルオーバー、スナップショット、同期、およびレプリカをプライマリに昇格させるために、より多くのメモリを確保する必要があります。これは、十分な量のメモリを用意して、プロセスの実行時に生じるすべての書き込みに対応する必要があるためです。
Redis OSS バージョン 2.8.22 以降では、分岐なしの保存プロセスが使用されているため、以前のプロセスよりも使用可能なメモリが少なくて済みます。
詳細については次を参照してください:
+ [同期とバックアップの実装方法](Replication.Redis.Versions.md)
+ [Valkey または Redis OSS スナップショットを作成するのに十分なメモリがあることを確認する](BestPractices.BGSAVE.md)
+ アプリケーションでの書き込み負荷の大きさ。
書き込み量が多いアプリケーションでは、スナップショットの作成時またはフェイルオーバー時に、データでは使用されないより多くの使用可能メモリが必要となります。`BGSAVE` プロセスが実行されるたびに、`BGSAVE` プロセス中に発生するすべての書き込みに対応するために、データによって使用されない十分なメモリが必要です。例えば、スナップショットを作成するとき、プライマリクラスターをクラスター内のレプリカと同期させるとき、AOF (Append-Only File) 機能を有効にするときです。また、レプリカをプライマリに昇格させるときです (マルチ AZ が有効になっている場合)。さらに、最悪の場合、プロセス中にすべてのデータが書き換えられるときです。この場合、データのみに必要なメモリの 2 倍のサイズのノードインスタンスが必要です。
詳細については、「[Valkey または Redis OSS スナップショットを作成するのに十分なメモリがあることを確認する](BestPractices.BGSAVE.md)」を参照してください。
+ スタンドアロンの 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](Local_zones.md)] を使用すると、ElastiCache クラスターなどのリソースをユーザーの近くの複数の場所に配置できます。ただし、ノードサイズを選択する場合、容量要件にかかわらず、現時点では、使用可能なノードサイズは次のサイズに制限されることに注意してください。
+ 現行世代:
**M5 ノードタイプ:** `cache.m5.large`、`cache.m5.xlarge`、`cache.m5.2xlarge`、`cache.m5.4xlarge`、`cache.m5.12xlarge`、`cache.m5.24xlarge`
**R5 ノードタイプ:** `cache.r5.large`、`cache.r5.xlarge`、`cache.r5.2xlarge`、`cache.r5.4xlarge`、`cache.r5.12xlarge`、`cache.r5.24xlarge`
**T3 ノードタイプ:** `cache.t3.micro`、`cache.t3.small`、`cache.t3.medium`
キャッシュクラスターが実行中であるときに、CloudWatch に発行される、メモリの使用状況、プロセッサの使用率、キャッシュヒット、およびキャッシュミスのメトリクスをモニタリングできます。クラスターに必要なヒット率がないことや、キーが頻繁に削除されていることに気付くことがあります。これらの場合は、より高い仕様の CPU とメモリの異なるノードサイズを選択できます。
CPU 使用率をモニタリングする際は、Valkey または Redis OSS はシングルスレッドであることに注意してください。したがって、レポートされた CPU 使用率に CPU コアの数を掛けて、実際の使用率を得ます。例えば、4 つのコアの CPU での使用率が 20 パーセントとレポートされた場合、実際には 1 つのコアの Redis OSS が使用率 80 パーセントで稼働しています。
## ノードサイズ (Memcached)
Memcached クラスターには 1 つまたは複数のノードが含まれ、クラスターのデータは複数のノードに分割されます。このため、クラスターで必要なメモリとノードで必要なメモリには関連性がありますが、同じではありません。ノードの数を減らすか、より多くのより小さなノードを確保することにより、必要なクラスターメモリの容量を実現できます。また、ニーズの変化に応じてクラスターへのノードの追加や削除を行い、必要なものだけに支払うことができます。
クラスターの合計メモリ容量は、システムのオーバーヘッドを差し引いた後に、クラスター内のキャッシュノードの数に各ノードの RAM 容量を乗算して計算されます。各ノードの容量はノードタイプに基づいています。
```
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)
```
クラスター内のノード数は、Memcached を実行するクラスターの可用性の重要な要素です。1 つのキャッシュノードで障害が発生した場合、アプリケーションの可用性とバックエンドデータベースの負荷に影響を与える可能性があります。そのような場合、ElastiCache によって、障害が発生したノードの交換がプロビジョニングされ、再配置されます。この可用性への影響を小さくするには、使用している大容量のノードを減らすのではなく、メモリとコンピューティングの容量をより小さい容量のより多くのノードに分散させます。
35 GB のキャッシュメモリが必要なシナリオでは、以下のいずれかを設定できます。
+ `cache.t2.medium`それぞれ 3.22 GB のメモリと 2 つのスレッドを持つ 11 の ノード = 35.42 GB、22 スレッド。
+ `cache.m4.large`それぞれ 6.42 GB のメモリと 2 つのスレッドを持つ 6 つの ノード = 38.52 GB、12 スレッド。
+ `cache.r4.large`それぞれ 12.3 GB のメモリと 2 つのスレッドを持つ 3 つの ノード = 36.90 GB、6 スレッド。
+ `cache.m4.xlarge`それぞれ 14.28 GB のメモリと 4 つのスレッドを持つ 3 つの ノード = 42.84 GB、12 スレッド。
**ノードオプションの比較**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/CacheNodes.SelectSize.html)
これらのオプションは、それぞれ同様のメモリ容量を提供しますが、コンピューティング容量とコストは異なります。特定のオプションのコストを比較するには、「[Amazon ElastiCache の料金表](https://aws.amazon.com/elasticache/pricing/)」を参照してください。
Memcached を実行するクラスターでは、各ノードの使用可能なメモリの一部は接続のオーバーヘッド用に使用されます。詳細については、「[Memcached 接続オーバーヘッド](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead)」を参照してください。
複数のノードを使用して、それらの間でキーを分散させる必要があります。各ノードには、独自のエンドポイントがあります。エンドポイント管理を簡単にするには、ElastiCache の自動検出機能を使用して、クライアントプログラムがクラスターのすべてのノードを自動的に識別できるようにします。詳細については、「[クラスター (Memcached) 内のノードを自動的に識別する](AutoDiscovery.md)」を参照してください。
場合によっては、必要な容量がわからないことがあります。その場合、テストのために、1 つの `cache.m5.large` ノードから始めることをお勧めします。次に、Amazon CloudWatch に発行されている ElastiCache メトリクスを使用して、メモリ使用量、CPU 使用率、キャッシュヒット率をモニタリングします。ElastiCache の CloudWatch メトリクスの詳細については、「[CloudWatch メトリクスの使用状況のモニタリング](CacheMetrics.md)」を参照してください。本稼働のより大きな優れたワークロードの場合は、R5 ノードが最高のパフォーマンスと RAM のコストバリューを提供します。
クラスターに必要なヒット率がない場合は、ノードを簡単に追加して、クラスターで使用可能なメモリの合計を増やすことができます。
クラスターが CPU の制約を受けているが、十分なヒット率がある場合は、処理能力のより高いノードタイプで新しいクラスターを設定します。