新機能 – Amazon ElastiCache リザーブドノードにサイズ柔軟性が適用

本記事は 2024 年 10 月 1 日に公開された “New – Size flexibility for Amazon ElastiCache reserved nodes” を翻訳したものです。

Amazon ElastiCache は、完全マネージド型の Redis OSS と Memcached 互換のキャッシングサービスです。2024 年 10 月 1 日より、すべてのリザーブドノードオファリングでサイズの柔軟性をサポートするようになりました。これにより、予約時に指定したサイズ以外のノードタイプに対してもリザーブドノード割引が適用されるようになります。
サイズの柔軟性をサポートしたリザーブドノードでは、予約購入時に特定のノードサイズを指定する必要がなくなり、キャパシティプランニングのオーバーヘッドが削減され、ワークロードやキャパシティの変化に合わせてクラスターのサイズを調整できるようになります。この記事では、この新しいサイズ柔軟性機能により、ElastiCache クラスターに割引価格がどのように適用されるかを説明します。

Amazon ElastiCache は、数十万人のお客様のアプリケーションのパフォーマンスを向上させ、より高いスケーラビリティを実現し、コストを最適化するのに役立っています。ElastiCache は、データキャッシング、Web、モバイルアプリ、ヘルスケアアプリ、金融アプリ、ゲーム、アドテック、IoT (モノのインターネット)、メディアストリーミング、セッションストア、リーダーボード、機械学習 (ML)、マイクロサービスベースのアプリケーションなど、高パフォーマンスが必要とされる用途に適しています。ElastiCache はフルマネージドサービスであり、キャッシュのハードウェアプロビジョニング、監視、ノード交換、ソフトウェアパッチ適用の管理をお客様にかわって支援します。

ElastiCache には、サーバーレスとセルフデザイン (ノードベース) の 2 つのデプロイオプションがあります。ノードベースのクラスターの場合、ノードタイプ、ノード数、AWS アベイラビリティーゾーン間でのノード配置を選択します。リザーブドノードを購入して、1 年または 3 年の期間 ElastiCache ノードタイプを予約し、オンデマンドノード価格に比べて割引 (最大 55%) を受けることができます。ElastiCache リザーブドノードは、前払い不要、一部前払い、全額前払いの構成で利用できます。長期契約でより多くの前払いをすれば、予約期間中の割引率が高くなります。

従来は、特定のインスタンスタイプ (例: cache.r7g.xlarge) の予約を購入した場合、指定されたタイプに対してのみ割引が適用されていました。これによりクラスターのスケールアップまたはダウンのためにノードサイズを変更した場合、リザーブドノードによる割引が適用されなくなっていました。
この柔軟性の欠如により、リザーブドノードでは 1 年または 3 年の期間の使用を予約する必要があるため、長期的な容量計画が困難になっていました。
2024 年 10 月 1 日以降、すべての ElastiCache リザーブドノードはより柔軟になり、特定の AWS リージョンとキャッシュエンジン (Redis OSS または Memcached) のノードファミリー (例: cache.r7g) 内のすべてのノードサイズに適用されるようになります。割引料金は利用に応じて自動的に適用されるため、リザーブドノード割引を実行中のキャッシュノードに合わせる必要がなくなり、管理オーバーヘッドが軽減されます。

割引料金を計算するために、各 ElastiCache ノードには ユニット で測定される 正規化係数 があります。リザーブドノードユニットは、リザーブドノードのインスタンスファミリー内の実行中のノードに適用できます。任意のノードの正規化係数を確認するには、ノードサイズチャートを参照できます。これは、Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Relational Database Service (Amazon RDS) などの他のサービスが、予約のサイズを柔軟に変更できるプロセスと同様です。

シナリオ 1: クラスターのスケールアウトとスケールダウン

例えば、Memcached エンジンで cache.r7g.4xlarge ノード (正規化係数 32) のリザーブドノードを購入した場合です。
このリザーブドノードは、同じリージョン内の任意の Memcached cache.r7g ノードで使用できます。
ノードサイズを小さくしてより多くのノード (同じアカウント内の同じクラスターまたは別のクラスター内) を実行し、リザーブドノードの恩恵を受けることができます。

例えば：

cache.r7g.large ノード 8 台 (8 * 4 = 32 ユニット)
cache.r7g.xlarge ノード 4 台 (4 * 8 = 32 ユニット)
cache.r7g.2xlarge ノード 2 台 (2 * 16 = 32 ユニット)
cache.r7g.4xlarge ノード 1 台 (1 * 32 = 32 ユニット)

シナリオ 2: 異なるサイズのノードの併用

この cache.r7g.4xlarge のリザーブドノードは、cache.r7g.large ノード 4 台 (4 * 4 = 16 ユニット) と cache.r7g.xlarge ノード 2 台 (2 * 8 = 16 ユニット) のような、異なるサイズのノードの組み合わせにも使用できます。
リザーブドノードの価格は、自動的に、より大きなサイズのノードタイプに適用される前に、同じ種類の中で実行中の小さいサイズのノードタイプに適用されます。リザーブドノードの恩恵を受けるインスタンスを選択することはできません。
たとえば、cache.r7g.large ノード 8 台 (32 ユニット) とcache.r7g.4xlarge ノード 1 台 (32 ユニット) を実行している場合、cache.r7g.large ノード 8 台がリザーブドノードによってカバーされます。

シナリオ 3: クラスターのスケールアップ

リザーブドノードよりも大きなノードを実行する場合、超過分に対して時間単位のオンデマンド価格が課金されます。例えば、実行中の 2 ノード cache.m7g.large Redis OSS クラスターをカバーするために、cache.m7g.large Redis OSS のリザーブドノードが 2 つある時、より多くの vCPU を活用するために cache.m7g.2xlarge ノードを使用してクラスターをスケールアップしたい場合を考えます。リザーブドノードの合計は 8 ユニット (ノードのサイズに対応した単位) で、新しいクラスター (16 ユニット) の 50% のリソースを確保できます。つまり、1 つの 2xlarge ノードに相当します。残りのノードは、cache.m7g.2xlarge ノードの時間単位のオンデマンド価格に基づいて課金されます。また、追加で 1 つの cache.m7g.2xlarge リザーブドノードを購入すれば、クラスター全体のリソースを確保できます。

シナリオ 4: クラスターのスケールダウン

所定の使用時間内に適格な実行中のノードが足りない場合、その時間の残りのリザーブドノードユニットは無駄になってしまいます。例えば、Redis OSS エンジンの cache.t4g.medium リザーブドノードがあり、1 ノードの Redis OSS クラスターを cache.t4g.small にスケールダウンした場合、その地域で他の Redis OSS cache.t4g ノードを起動しない限り、残りの 1 ノード分のユニットは消失してしまいます。

結論

ノードタイプの柔軟性は、すべての ElastiCache エンジンのすべてのリージョンで利用できるようになり、10 月 1 日から既存および新規購入のリザーブドノードに自動的に適用されます。柔軟なリザーブドノードの詳細については、Amazon ElastiCache リザーブドノードページをご覧ください。

この記事の翻訳は Solutions Architect の堤勇人が担当しました。

著者について

Kevin McGehee は、Amazon In-Memory Databases チームのプリンシパルエンジニアです。優秀な開発者と共に、パフォーマンスが高く保守性の高いシステムを構築することに情熱を注いでいます。

Goumi Viswanathan は、Amazon In-Memory Databases チームのシニアプロダクトマネージャーです。
12 年以上のプロダクト経験があり、データベースソリューションを提供するクロスファンクショナルチームをリードしています。
仕事以外では、旅行と屋外での時間を楽しんでいます。

Amazon Web Services ブログ