メニュー
Amazon ElastiCache
ユーザーガイド (API Version 2015-02-02)

ノードサイズの選択

このセクションは、使用するノードシナリオどのインスタンスタイプが必要となるかを判断するのに役立ちます。エンジン、Memcached、Redis ではクラスターの実装方法が異なるため、エンジンの選択により、アプリケーションで必要となるノードサイズに違いが発生します。

Memcached クラスターのノードサイズの選択

Memcached クラスターには 1 個または複数のノードが含まれます。このため、クラスターで必要なメモリとノードで必要なメモリには関連性がありますが、同じではありません。ノードの数を減らすか、より多くのより小さなノードを確保することにより、必要なクラスターメモリの容量を実現できます。また、ニーズの変化に応じてクラスターへのノードの追加や削除を行い、必要なものだけに支払うことができます。

クラスターの合計メモリ容量は、クラスター内のノードの数に各ノードの RAM 容量を乗算して計算されます。各ノードの容量はノードタイプに基づいています。

クラスター内のノード数は、Memcached を実行するクラスターの可用性の重要な要素です。1 つのノードで障害が発生した場合、ElastiCache で障害が発生したノードの置き換えをプロビジョニングして再入力する間、アプリケーションの可用性やバックエンドデータベースへの負荷に影響を及ぼす可能性があります。この潜在的な可用性に対する影響を軽減するには、少数の容量の大きいノードを使用する代わりに、それぞれが容量の小さい多数のノードにメモリとコンピューティング性能を分散させます。

40 GB のキャッシュメモリが必要なシナリオでは、次のいずれかを設定できます。

  • それぞれ 3.22 GB のメモリと 2 つのスレッドを持つ 13 の cache.t2.medium ノード = 41.86 GB、26 スレッド。

     

  • それぞれ 6.05 GB のメモリと 2 つのスレッドを持つ 7 つの cache.m3.large ノード = 42.35 GB、14 スレッド。

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

     

  • それぞれ 13.50 GB のメモリと 2 つのスレッドを持つ 3 つの cache.r3.large ノード = 40.50 GB、6 スレッド。

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

ノードオプションの比較

ノードの種類 メモリ コア 時間あたりのコスト * 必要なノード 合計メモリ 合計コア 毎月のコスト †
cache.t2.medium 3.22 GB 2 0.068 USD 13 41.86 GB 26 $ 636.48
cache.m3.large 6.05 GB 2 $ 0.182 7 42.35 GB 14 $ 917.28
cache.m4.large 6.42 GB 2 0.156 USD 7 44.94 GB 14 $ 768.24
cache.r3.large 13.50 GB 2 0.228 USD 3 40.50 GB 6 $ 492.48
cache.m4.xlarge 14.28 GB 4 0.311 USD 3 42.84 GB 12 $ 671.76
* 2016 年 8 月 4 日現在のノードあたりの時間あたりのコスト。
30 日 (720 時間) の使用率 100% の場合†の 1 か月あたりのコスト。

これらのオプションは、それぞれ同様のメモリ容量を提供しますが、コンピューティング容量とコストは異なります。特定のオプションのコストを比較するには、「Amazon ElastiCache の料金表」を参照してください。

Memcached を実行するクラスターでは、各ノードの使用可能なメモリの一部は接続のオーバーヘッド用に使用されます。詳細については、「Memcached 接続オーバーヘッド」を参照してください。

複数のノードを使用して、それらの間でキーを分散する必要があります。各ノードには、独自のエンドポイントがあります。エンドポイント管理を簡単にするには、ElastiCache の自動検出機能を使用して、クライアントプログラムがクラスターのすべてのノードを自動的に識別できるようにします。詳細については、「ノードの自動検出 (Memcached) 」を参照してください。

必要な容量が不明な場合は、試験的に 1 個の cache.m3.medium のノードから始めて、ElastiCache に発行される CloudWatch のメトリクスで、メモリの使用状況、CPU 使用率、キャッシュヒット率をモニタリングすることをお勧めします。CloudWatch のメトリクス (ElastiCache 用) の詳細については、「CloudWatch メトリクスを使用したモニタリング」を参照してください。本稼働のより大きな優れたワークロードの場合は、R3 ノードが最高のパフォーマンスと RAM のコストバリューを提供します。

クラスターで目的のヒットレートが達成されない場合は、簡単な操作でノードを追加し、クラスター内の合計使用可能メモリを増やすことができます。

クラスターが、ヒットレートが十分ではない CPU の制約を受けていることがわかった場合は、ノードタイプでより大きな処理能力を持つ新しいクラスターをセットアップしてみてください。

Redis クラスターのノードサイズの選択

以下の項目に回答することで、Redis の実装に必要な最小ノードタイプを決定できます。

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

     

    キャッシュする項目のサイズを取得して、キャッシュで同時に維持する項目数を乗算することで、一般的な予測値が得られます。項目のサイズを合理的に見積もるには、キャッシュ項目をシリアル化して文字数をカウントし、その文字数をクラスターのシャード数で分割します。

     

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

     

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

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

    詳細については、以下を参照してください。

     

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

     

    書き込み量が多いアプリケーションでは、スナップショットの作成時またはフェイルオーバー時に、 データでは使用されないより多くの使用可能メモリが必要となります。BGSAVE プロセスの実行時 – スナップショットの作成時、クラスターでのプライマリクラスターとレプリカの同期時、AOF (append-only file) 機能を有効にした場合、レプリカのプライマリへの昇格時 (マルチ AZ で自動フェイルオーバーを有効にした場合) – データが使用する十分な量のメモリを用意して、BGSAVE プロセスの実行時に生じるすべての書き込みに対応する必要があります。最悪の場合は、処理中にすべての データが書き換えられます。その場合、データ単独で必要なメモリの倍のサイズのノードインスタンスが必要になります。

     

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

     

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

     

    Redis (クラスターモードが無効) クラスター

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

     

    たとえば、すべての項目の合計サイズが 12 GB になると予測される場合は、メモリ容量が 13.3 GB である cache.m3.xlarge ノードまたはメモリ容量が 13.5 GB である cache.r3.large ノードを使用できます。ただし、BGSAVE オペレーションではより多くのメモリが必要になる場合があります。書き込み量の多いアプリケーションがある場合は、メモリ要件の倍のメモリで最低 24 GB が必要になります。これは、cache.m3.2xlarge で 27.9 GB、cache.r3.rge で 28.4 GB のメモリが必要であることを意味します。

     

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

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

     

    たとえば、すべての項目の合計見積りサイズが 12 GB で 2 つのシャードがある場合は、6.05 GB のメモリを持つ cache.m3.large ノードを 2 つ使用できます。ただし、BGSAVE オペレーションではより多くのメモリが必要になる場合があります。書き込み量が多いアプリケーションの場合は、シャードごとに倍の 12 GB 以上のメモリが必要であり、13.3 GB の cache.m3.xlarge または 13.5 GB のcache.r3.large を使います。

     

    現在 Redis (クラスターモードが有効) クラスターにシャードを追加することはできません。したがって、予測される負荷の増大に対応するために、ある程度大きなノードタイプを使用することが必要になります。

     

キャッシュクラスターが実行中であるときに、CloudWatch に発行される、メモリの使用状況、プロセッサの使用率、キャッシュヒット、およびキャッシュミスのメトリクスをモニタリングできます。クラスターで目的のヒットレートが達成されない場合や、キーが頻繁に削除されている場合は、CPU やメモリの容量が大きい別のノードサイズを選択できます。

CPU の使用率をモニタリングする場合、Redis はシングルスレッドであることに留意します。したがって、報告された CPU 使用率に CPU のコア数を乗算することで、実際の使用率が得られます。たとえば、4 つのコアを持つ CPU で使用率 20% と報告された場合、実際に Redis が使用している 1 つのコアは 80% で稼働しています。