次の方法で共有

Azure Cache for Redis インスタンスのスケーリング

  • 適用対象: ✅ Azure Cache for Redis

Azure Cache for Redis には、キャッシュ サイズやフィーチャーを柔軟に選べるよう、さまざまなレベルオファリングが用意されています。 スケーリングを通じて、アプリケーションのニーズに合わせてキャッシュ インスタンスを作成した後に、ノードのサイズ、層、数を変更できます。 このアーティクルでは、Azure Portal と、Azure PowerShell や Azure CLI などのツールを使用して、キャッシュをスケーリングする方法を説明します。

スケールのタイプ

Azure Cache for Redis インスタンスをスケーリングするには、基本的に 以下の2 つの方法があります:

  • スケールアップ すると、Redis サーバーを実行する仮想マシン (VM) のサイズが大きくなり、メモリ、仮想 CPU (vCPU)、ネットワーク帯域幅が追加されます。 スケールアップは 垂直スケーリングとも呼ばれます。 スケールアップの反対はスケールダウンです。

  • スケールアウト すると、キャッシュ インスタンスが同じサイズのより多くのノードに除算され、並列化によってメモリ、vCPU、ネットワーク帯域幅が増加します。 スケールアウトは、 水平スケーリング または シャード化とも呼ばれます。 スケールアウトの反対は、スケールインです。 Redis コミュニティでは、スケールアウトは クラスタリングと呼ばれる場合が多いです。

可用性のスコープ

レベル Basic および Standard プレミアム Enterprise および Enterprise Flash
スケールアップ はい はい はい
スケールダウン はい はい いいえ
スケールアウト いいえ はい はい
スケールイン いいえ はい いいえ

スケーリングするタイミング

Azure Cache for Redis の 監視機能を使用して、お使いのキャッシュの正常性とパフォーマンスを監視できます。 その情報を使用して、キャッシュのスケーリングが必要である場合を判断します。

次のメトリックを監視して、スケーリングの必要性が判断できます。

  • Redis サーバーの負荷
    • Redis サーバーの負荷が高いということは、サーバーがすべてのクライアントからの要求に対応できないという意味です。 Redis サーバーはシングル スレッド プロセスであるため、通常はスケールアップではなくスケールアウトする方が便利です。 クラスタリングを有効にしてスケールアウトすると、オーバーヘッド関数を複数の Redis プロセスに配布できます。 スケールアウトは、TLS 暗号化/暗号化解除と接続/切断を配布し、TLS を使用してキャッシュ インスタンスを高速化するのにも役立ちます。
    • バックグラウンド タスクではより多くの vCPU を利用し、メイン Redis サーバー プロセスのスレッドを解放できるため、スケールアップはサーバーの負荷を軽減するのに引き続き役立ちます。
    • Enterprise および Enterprise Flash レベルでは、オープンソースRedis ではなく Redis Enterpriseが使用されます。 これらのレベルの利点の 1 つは、Redis サーバー プロセスが複数の vCPU を利用できることです。 複数の vCPU があることで、これらのレベルではスケールアップとスケールアウトの両方がサーバー負荷の軽減に役立ちます。
  • メモリ使用量
    • メモリ使用量が多い場合は、データ サイズが現在のキャッシュ サイズに対して大きすぎるかことを示します。 メモリがより大きいキャッシュ サイズにスケーリングを検討してください。 ここでは、スケールアップ または スケールアウト のいずれかが効果的です。
  • クライアント接続
    • 各キャッシュ サイズには、サポートできるクライアント接続の数に制限があります。 クライアント接続がキャッシュ サイズの制限に近い場合は、より大きなレベルにスケールアップすることを検討してください。 スケールアウトしても、サポートされているクライアント接続の数は増えません。
    • キャッシュ サイズ別の接続制限の詳細については、「Azure Cache for Redis に関する価格」を参照してください。
  • ネットワーク帯域幅
    • Redis サーバーが使用可能な帯域幅を超えると、サーバーがクライアントに十分な速度でデータをプッシュできないので、クライアントの要求がタイムアウトする可能性があります。 サーバー側の帯域幅がどれだけ使用されているかを把握するには、"キャッシュの読み取り" および "キャッシュの書き込み" メトリックを確認します。 Redis サーバーが使用可能なネットワーク帯域幅を超える場合は、より大きなネットワーク帯域幅でより大きなキャッシュ サイズにスケールアップすることを検討をする必要があります。
    • Enterprise クラスター ポリシーを使用するエンタープライズ層キャッシュの場合、スケールアウトではネットワーク帯域幅は増加しません。
    • キャッシュ サイズ別のネットワークで使用可能な帯域幅の詳細については、「Azure Cache for Redis 計画に関するよくあるご質問」を参照してください。
  • 内部 Defender スキャン
    • C0 および C1 Standard のキャッシュでは、内部 Defender スキャンが VM 上で実行されている間に、キャッシュ要求の増加以外の要因で、サーバーの負荷の短期的な急増が発生する場合があります。 内部 Defender スキャンがこれらのレベルで実行される場合、日ごとに 2 回前後、要求の待ち時間が長くなります。 C0 および C1 レベルのキャッシュには、マルチタスクを実行するコアが 1 つだけあり、ウイルス スキャンと Redis 要求の処理が分割されます。 C2などの複数の CPU コアを持つオファリングにスケーリングすると、その影響を軽減できます。
    • 上位レベルではキャッシュ サイズが増加するため、待機時間の問題に対処できます。 また、C2 レベルでは、2,000 のクライアント接続をサポートしています。

使用するキャッシュの価格レベルを決定する方法の詳細については、「最適なサービス レベルを選択する」および「Azure Cache for Redis 計画に関するよくあるご質問」を参照してください。

注

スケーリング プロセスを最適化する方法の詳細については、スケーリング ガイドのベスト プラクティスに関するページを参照してください

スケーリングAzure Cache for Redisの前提条件/制限事項

別の価格レベルにスケールアップ/ダウンできますが、次のような制約があります:

  • 上位の価格レベルから下位の価格レベルにスケーリングすることはできません。
    • Enterprise または Enterprise Flash キャッシュから他のレベルにスケールダウンすることはできません。
    • Premium キャッシュから Standard または Basic キャッシュにスケールすることはできません。
    • Standard キャッシュから Basic キャッシュにスケールすることはできません。
  • Basic キャッシュから Standard キャッシュにスケールすることはできますが、同時にサイズを変更することはできません。 サイズを変更する必要がある場合、後からスケーリング操作で必要なサイズに変更できます。
  • Basic キャッシュから直接 Premium キャッシュにスケールすることはできません。 まず、1 回のスケーリング操作で Basic から Standard にスケーリングし、次の操作で Standard から Premium にスケーリングします。
  • C0 (250 MB) サイズには、それより大きなサイズからスケールインすることはできません。 ただし、同じ価格レベル内の他の任意のサイズにスケールインすることはできます。 たとえば、C5 Standard から C1 Standard にスケールインできます。
  • Premium、Standard、または Basic キャッシュから Enterprise または Enterprise Flash キャッシュまでスケールアップすることはできません。
  • EnterpriseFlash とEnterprise Flashの間でスケーリングすることはできません。

以下の制限事項でスケールアウト/インすることができます:

  • スケールアウト は、 Premium、 Enterprise、 Enterprise Flash の各レベルでのみサポートされます。
  • スケール イン は Premium レベルでのみサポートされます。
  • Premium レベルでは、スケールインまたはスケールアウトの前に、クラスタリングを最初に有効にする必要があります。
  • Premium レベルでは、最大 10 シャードのスケールアウトが全般的にサポートされています。 最大 30 シャードのサポートはプレビュー段階です。 (2 つのレプリカを含むキャッシュの場合、シャードの制限は 20 です。3 つのレプリカが含まれる場合、シャードの制限は 15 です)。
  • 同時にスケールアップおよびスケールアウトできるのは、 Enterprise および Enterprise Flash レベルのみです。

スケーリング方法 - Basic、Standard、Premium レベル

Azure portalを使用してスケールアップとスケールダウンを行う

  1. キャッシュをスケーリングするには、Azure portal でキャッシュを参照し、リソースメニューの スケール をクリックします。

    リソース メニューの スケール を示すスクリーンショット。

  2. 作動中のウィンドウにある価格レベルを選択し、[選択] を選択します。

    Azure Cache for Redis層を示すスクリーンショット。

  3. キャッシュを新しいレベルにスケーリングしている間、 [Redis Cache のスケールを設定しています] という通知が表示されます。

    スケーリングの通知を示すスクリーンショット。

  4. スケーリングが完了すると、状態が [拡大中] から [実行中] に変わります。

注

ポータルでキャッシュをスケールアップまたはスケールダウンすると、maxmemory-reserved と maxfragmentationmemory-reserved の設定の両方が、キャッシュ サイズに比例して自動的にスケーリングされます。 たとえば、6 GB のキャッシュで maxmemory-reserved が 3 GB に設定されている場合、キャッシュを 12 GB にスケーリングすると、スケーリングの間に設定が 6 GB に自動的に更新されます。 スケールダウンすると、逆の処理が行われます。

PowerShell を使用したスケールアップとスケールダウン

PowerShell を使用して Azure Cache for Redis インスタンスをスケーリングするには、またはSize プロパティを変更するときに Sku コマンドレットを使用します。 次の例は、myCache という名前のキャッシュを同じレベルで6 GB のキャッシュにスケーリングする方法を示しています。

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

PowerShell によるスケーリングの詳細については、PowerShell を使用した Azure Cache for Redis のスケーリングに関するページを参照してください。

Azure CLI を使用したスケールアップとスケールダウン

Azure CLI を使用してAzure Cache for Redis インスタンスをスケーリングするには、az redis 更新プログラム コマンドを呼び出します。 sku.capacity プロパティを使用して、たとえば Standard C0 から Standard C1 キャッシュに階層内でスケーリングします:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

"sku.name" プロパティと "sku.family" プロパティを使用して、Standard C1 キャッシュから Premium P1 キャッシュなど、別のレベルにスケールアップします:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Azure CLI によるスケーリングの詳細については、「Change settings of an existing Azure Cache for Redis」 (既存の Azure Cache for Redis の設定を変更する) をご覧ください。

注

プログラムによってキャッシュをスケールアップまたはスケールダウンすると (PowerShell や Azure CLI を使用するなど)、更新要求の一部として maxmemory-reserved または maxfragmentationmemory-reserved は無視されます。 スケーリングの変更のみが受け入れられます。 これらのメモリ設定は、スケーリング操作の完了後に更新できます。