次の方法で共有

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 Premium Enterprise および Enterprise Flash
スケールアップ はい イエス はい
スケールダウン はい はい いいえ
Scale Out いいえ イエス はい
スケールイン いいえ 有効 いいえ

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

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 の Enterprise と Enterprise Flash レベルのベスト プラクティスを参照してください。
  • メモリ使用量
    • メモリ使用量が多い場合は、データ サイズが現在のキャッシュ サイズに対して大きすぎるかことを示します。 メモリがより大きいキャッシュ サイズにスケーリングを検討してください。 ここでは、スケールアップ または スケールアウト のいずれかが効果的です。
  • クライアント接続
    • 各キャッシュ サイズには、サポートできるクライアント接続の数に制限があります。 クライアント接続がキャッシュ サイズの制限に近い場合は、より大きなレベルにスケールアップすることを検討してください。 スケールアウトしても、サポートされているクライアント接続の数は増えません。
    • キャッシュ サイズ別の接続制限の詳細については、「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 計画に関するよくあるご質問」を参照してください。

Note

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

スケーリング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. スケーリングが完了すると、状態が [拡大中] から [実行中] に変わります。

Note

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

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

PowerShell を使用して Azure Cache for Redis インスタンスをスケーリングするには、SizeまたはSku プロパティを変更するときに Set-AzRedisCache コマンドレットを使用します。 次の例は、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.capcity プロパティを使用して、たとえば 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 の設定を変更する) をご覧ください。

Note

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

スケールアップとスケールアウトの方法 - Enterprise および Enterprise Flash レベル

Enterprise および Enterprise Flash レベルは、1 回の操作でスケールアップおよびスケールアウトできます。 その他のレベルでは、アクションごとに個別の操作が必要です。

注意事項

Enterprise および Enterprise Flash レベルでは、 スケール ダウン や スケールイン 操作はまだサポートされていません。

Azure Portal を使用したスケール

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

    エンタープライズ キャッシュの リソース メニューで スケール が選択されていることを示すスクリーンショット。

  2. スケールアップするには、別のキャッシュの種類 を選択し、 保存 を選択します。

    重要

    この時点でのみスケールアップできます。 スケールダウンできません。

    作業ウィンドウの エンタープライズ層 を示すスクリーンショット。

  3. スケールアウトするには、容量 スライダーを大きくします。 容量は 2 ずつ増加します。 この数は、追加する基になる Redis Enterprise ノードの数を反映しています。 この数は、プライマリ シャードとレプリカ シャードの両方に対して追加されるノードを反映するために、常に 2 つの倍数です。

    重要

    現時点では、スケールアウト、容量の増加のみ可能です。 スケール インすることはできません。

    作業ウィンドウの容量の周囲に赤いボックスが表示されているスクリーンショット。

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

    エンタープライズ キャッシュのスケーリングの通知を示すスクリーンショット。

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

PowerShell を使用したスケーリング

Update-AzRedisEnterpriseCache コマンドレットを使用して、PowerShell を使用してAzure Cache for Redis インスタンスをスケーリングできます。 Sku プロパティを 変更して、インスタンスをスケールアップできます。 Capacity プロパティを 変更して、インスタンスをスケールアウトできます。 次の例は、myCache という名前のキャッシュを、容量 4 の Enterprise E20 (25 GB) インスタンスにスケーリングする方法を示しています。

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Azure CLI を使用したスケーリング

Azure CLI を使用してAzure Cache for Redis インスタンスをスケーリングするには、 az redisenterprise update コマンドを呼び出します。 sku プロパティを 変更して、インスタンスをスケールアップできます。 capacity プロパティを 変更して、インスタンスをスケールアウトできます。 次の例は、myCache という名前のキャッシュを、容量 4 の Enterprise E20 (25 GB) インスタンスにスケーリングする方法を示しています。

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

スケーリングに関する FAQ

次の一覧は、Azure Cache for Redis のスケーリングに関するよく寄せられる質問への回答です。

Premium キャッシュへのスケーリング、Premium キャッシュからのスケーリング、または Premium キャッシュ内でのスケーリングは可能ですか

  • Premium キャッシュから Basic または Standard の価格レベルにスケーリングすることはできません。
  • ある Premium キャッシュの価格レベルから別の Premium キャッシュの価格レベルにスケーリングすることはできます。
  • Basic キャッシュから直接 Premium キャッシュにスケールすることはできません。 まず、1 回のスケーリング操作で Basic から Standard にスケーリングし、次の操作で Standard から Premium にスケーリングします。
  • Premium キャッシュから Enterprise または Enterprise Flash キャッシュにスケーリングすることはできません。
  • Premium キャッシュを作成したときにクラスタリングを有効にしている場合、クラスター サイズを変更できます。 クラスタリングを有効にせずに作成されたキャッシュの場合、後でクラスタリングを構成できます。

スケーリング後にキャッシュ名やアクセス キーを変更する必要はありますか

いいえ、スケーリング処理中にキャッシュ名やキーが変更されることはありません。

スケーリングはどのように処理されますか

  • Basic キャッシュを別のサイズにスケーリングすると、キャッシュはシャットダウンされ、新しいキャッシュが新しいサイズでプロビジョニングされます。 この間キャッシュは使用できず、キャッシュ内のすべてのデータは失われます。
  • Basic キャッシュを Standard キャッシュにスケーリングすると、レプリカ キャッシュがプロビジョニングされ、データがプライマリ キャッシュからレプリカ キャッシュにコピーされます。 スケーリングの処理中、キャッシュは引き続き使用できます。
  • Standard、Premium, EnterpriseまたはEnterprise Flash キャッシュを別のサイズにスケーリングすると、一方のレプリカはシャットダウンし、新しいサイズに再プロビジョニングされてデータが転送されます。もう一方のレプリカは、キャッシュ ノードの 1 つでエラーが発生したときに実行されるプロセスと同様に、フェールオーバーを実行してから、再プロビジョニングされます。
  • クラスター化されたキャッシュをスケールアウトすると、新しいシャードがプロビジョニングされ、Redis サーバー クラスターに追加されます。 その後、すべてのシャード間でデータが再シャードされます。
  • クラスター化キャッシュでスケーリングすると、最初にデータが再調整され、クラスターサイズが必要なシャードに縮小されます。
  • スケーリングやキャッシュを別のクラスターに移行するなどの場合では、キャッシュの基礎 IP アドレスが変わることがあります。 キャッシュの DNS レコードが変わり、ほとんどのアプリケーションに対して透過的になります。 ただし、IP アドレスを利用してキャッシュへの接続を構成するか、キャッシュへのトラフィックを許可する NSG またはファイアウォールを構成する場合、DNS レコードの更新後、アプリケーションで接続に問題が発生することがあります。

スケーリング中にキャッシュからデータは失われますか?

  • 新しいサイズに Basic キャッシュをスケーリングすると、すべてのデータが失われ、スケーリング処理中にキャッシュは使用できなくなります。
  • Basic キャッシュを Standard キャッシュにスケーリングする場合、通常、キャッシュのデータは保存されます。
  • Standard、Premium、Enterprise、または Enterprise Flash キャッシュを大きなサイズにスケーリングすると、通常、すべてのデータが保持されます。 Standard または Premium のキャッシュを小さいサイズにスケーリングする場合、データ サイズが新しい小規模なサイズを超えていると、キャッシュのスケールダウン時にデータが失われる場合があります。 スケールダウンのときにデータが失われた場合、 allkeys-lru 削除ポリシーを使用してキーが削除されます。

スケーリング後に Premium レベルのすべての機能を使用できますか

いいえ。一部の機能は Premium レベルでキャッシュを作成するときにのみ設定でき、スケーリング後は使用できません。

Premium キャッシュを作成した後、これらの機能を追加することはできません。

  • 仮想ネットワーク インジェクション
  • ゾーン冗長の追加
  • プライマリごとに複数のレプリカを使用

これらの機能のいずれかを使用するには、Premium レベルで新しいキャッシュ インスタンスを作成する必要があります。

スケーリング中に影響を受けるカスタム データベース

キャッシュの作成中に databases の設定のカスタム値を構成した場合、価格レベルによってさまざまなデータベース制限があることに注意してください。 このシナリオでスケーリングを行う場合は、次の点を考慮します。

  • 現在のレベルより低いdatabases制限に価格レベルをスケーリングする場合:
    • すべての価格レベルが 16 の databases の既定の数を使っている場合、データは失われません。
    • スケーリングしているレベルの制限範囲に含まれるユーザー設定の数値の databases を使用している場合、この databases の設定は保持され、データは失われません。
    • 新しいレベルの制限を超えるユーザー設定の数値の databases を使用している場合、databases の設定は新しいレベルの制限より低くなり、削除されたデータベースのすべてのデータが失われます。
  • 現在のレベル以上のdatabases制限を持つ価格レベルにスケーリングする場合、databasesの設定は保持され、データは失われません。

Standard、Premium、Enterprise およびEnterprise Flash キャッシュには可用性について 99.9% の SLA がある一方で、データの喪失については SLA がありません。

スケーリング中にキャッシュを使用できますか

  • Standard、 Premium、 Enterprise、 Enterprise Flash の各キャッシュは、スケーリング操作中も引き続き使用できます。 ただし、これらのキャッシュのスケーリングや、Basic から Standard キャッシュへのスケーリングの際に接続の中断が発生する可能性があります。 こうした接続の中断はわずかで、Redis クライアントは通常すぐに接続を再確立できます。
  • アクティブ geo レプリケーションを使用する Enterprise および Enterprise Flash キャッシュの場合、リンクされたキャッシュのサブセットのみをスケーリングすると、場合によっては問題が発生する可能性があります。 可能な場合は、geo レプリケーション グループ内のすべてのキャッシュをまとめてスケーリングすることをお勧めします。
  • 別のサイズにスケーリングする場合、Basic キャッシュはオフラインになります。 Basic から Standard にスケーリングする際は、Basic キャッシュを引き続き利用できますが、接続の中断がわずかに発生する可能性があります。 接続の中断が発生しても、Redis クライアントは通常、すぐに接続を再確立できます。

geo レプリケーションにスケーリング制限はありますか

パッシブgeo レプリケーションが構成されている場合は、キャッシュをスケーリングしたり、クラスター内のシャードを変更したりすることはできません。 2 つのキャッシュ間の geo レプリケーション リンクを使用すると、クラスター内のスケーリング操作やシャードの数の変更を防ぐことができます。 これらのコマンドを発行するには、キャッシュのリンクを解除する必要があります。 詳細については、「geo レプリケーションの構成」を参照してください。

アクティブ geo レプリケーションが構成されている場合、キャッシュをスケーリングすることはできません。 geo レプリケーション グループ内のすべてのキャッシュは、同じサイズと容量である必要があります。

サポートされていない操作

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

スケーリング処理でエラーが発生すると、サービスは処理を取り消してキャッシュを元のサイズに戻すように試行します。

スケーリングにはどのくらいの時間がかかりますか

スケーリング時間はいくつかの要因によって異なります。 ここでは、スケーリングにかかる時間に影響する要因について説明します。

  • データ量: 大量のデータがレプリケートされるまでに長い時間がかかります。
  • 高書き込み要求: 書き込み数が多いほど、ノードまたはシャード間でデータがレプリケートされることを意味します。
  • 高サーバー負荷: 高サーバー負荷とは、Redis サーバーがビジーであり、データの再配布を完了するための CPU サイクルが限られていることを指します。

キャッシュのスケーリングは簡単な操作ではなく、時間がかかる場合があります。

実際の例に基づくと、1 から 2 つのシャードでキャッシュをスケーリングする時間は、キャッシュの負荷が大きくない場合に 1 から 2 時間になる可能性があります。シャードの数が多い場合、スケーリングする時間は直線的には増加しません。

スケーリングが完了したことをどのようにして確認できますか

スケール処理の進捗は Azure Portal で確認できます。 スケーリングが完了すると、キャッシュの状態が [実行中] に変わります。

クラスタリングを使用するためにクライアント アプリケーションを変更する必要がありますか

重要

Enterprise または Enterprise FLash レベルを使用する場合は、 OSS クラスター モード または Enterprise クラスター モードを選択できます。 OSS クラスター モードは Premium レベルでのクラスタリングと同じであり、オープンソースクラスタリングの仕様に従います。 Enterprise クラスター モードはパフォーマンスを低下させることができますが、使用するクライアントの変更を必要としない Redis Enterprise クラスタリングを使用します。 詳細については、Enterpriseのクラスタリングを参照してください。

クラスターにはキーはどのように配布されるのですか

キー配布モデルのRedisごと に関するドキュメントによると、キー スペースは 1,6384 スロットに分割されます。 各キーはハッシュされ、クラスターのノード全体に配布される、これらのスロットのいずれかに割り当てられます。 ハッシュ タグを使用して同じシャードに複数のキーが配置されていることを確認するために、キーのどの部分をハッシュするかを構成することができます。

  • ハッシュ タグのあるキー - キーの任意の部分を { と } で囲むと、キーのその部分のみが、キーのハッシュ スロットを決定するためにハッシュされます。 たとえば、{key}1、{key}2、{key}3 という 3 つのキーは、名前の key 部分のみがハッシュされるため、同じシャードに配置されます。 キーのハッシュ タグ仕様に関する完全なリストについては、「 キーのハッシュ タグ」を参照してください。
  • ハッシュ タグのないキー - キー名全体がハッシュに使用されるので、キャッシュのシャードにわたって統計的に均等に配布されます。

最高のパフォーマンスとスループットを得るために、キーを均等に配布することをお勧めします。 ハッシュ タグのあるキーを使用する場合、キーが均等に配布されていることを確認するのはアプリケーションの責任です。

詳細については、「Keys distribution model (キー配布モデル)」、「Redis Cluster data sharding (Redis クラスターのデータ シャーディング)」、および「Keys hash tags (キーのハッシュ タグ)」を参照してください。

StackExchange.Redis クライアントを使用した同じシャードでのクラスタリングおよびキーの検索の操作に関するサンプル コードについては、Hello World サンプルの clustering.cs 部分を参照してください。

作成できる最大キャッシュ サイズはどれくらいですか

設定できる最大キャッシュ サイズは 4.5 TB です。 この結果は、容量 9 のクラスター化された F1500 キャッシュになります。 詳細については、Azure Cache for Redis の価格に関するページを参照してください。

すべての Redis クライアントがクラスタリングをサポートしますか

多くのクライアント ライブラリが Redis クラスタリングをサポートしていますが、すべてではありません。 使用しているライブラリのドキュメントをチェックして、クラスタリングをサポートするライブラリとバージョンを使用していることを確認してください。 StackExchange.Redis は、その新しいバージョンでクラスタリングをサポートする 1 つのライブラリです。 他のクライアントの詳細については、「Redis cluster tutorial (Redis クラスター チュートリアル)」の「Playing with the cluster (クラスターの使用)」を参照してください。

Redis クラスタリング プロトコルでは、各クライアントはクラスタリング モードで各シャードに直接接続する必要があり、MOVED、CROSSSLOTS などの新しいエラー応答も定義されます。 クロススロット マルチキー要求を行っている場合に、クラスタリングをサポートしないクライアント ライブラリをクラスター モードのキャッシュで使用しようとすると、多数の MOVED リダイレクト例外が発生するか、または単にアプリケーションが中断される場合があります。

Note

StackExchange.Redis をクライアントとして使用する場合は、クラスタリングが正常に動作するように、 StackExchange.Redis 1.0.481 以降の最新バージョンを使用するようにしてください。 move 例外に関する問題の詳細については、move 例外に関する記事を参照してください。

クラスタリングが有効になっているとき、キャッシュに接続するにはどうすればよいですか

クラスタリングが有効になっていないキャッシュに接続するときに使用するものと同じエンドポイント、ポート、キーを使用して、キャッシュに接続できます。 Redis がバックエンドのクラスタリングを管理するので、クライアントから管理する必要はありません。

キャッシュの個々のシャードに直接接続できますか

クラスタリング プロトコルでは、クライアントが正しいシャード接続を行う必要があるため、クライアントは共有接続を行う必要があります。 つまり、各シャードは、キャッシュ インスタンスと総称される、プライマリ/レプリカ キャッシュ ペアで構成されています。 GitHub で Redis リポジトリの 不安定な ブランチにある Redis-CLI ユーティリティを使用して、これらのキャッシュ インスタンスに接続できます。 このバージョンは、 -c スイッチ付きで起動した場合、基本的なサポートを実装しています。 詳細については、https://redis.io の「Redis cluster tutorial」 (Redis クラスター チュートリアル) にある「Playing with the cluster」 (クラスターの使用) をご覧ください。

-p スイッチを使用して、接続する正しいポートを指定する必要があります。 CLUSTER NODES コマンドを使用して、プライマリ ノードとレプリカ ノードに使用される正確なポートを指定します。 次のポート範囲が使用されます:

  • TLS Premium レベル以外のキャッシュの場合、ポートは130XX の範囲内で 使用できます
  • TLS Premium レベル有効のキャッシュの場合、ポートは150XX の範囲内で 使用できます
  • OSS クラスタリングを使用する Enterprise および Enterprise Flash キャッシュの場合、最初の接続はポート 10000 経由です。 個々のノードへの接続は、85XX 範囲のポートを使用して行うことができます。 85xx ポートは時間の経過と伴って変更されるため、アプリケーションにハードコーディングしないでください。

以前に作成したキャッシュのクラスタリングを構成できますか。

はい。 まず、キャッシュをスケールアップして確実に Premium レベルにします。 次に、クラスター構成オプション (クラスターを有効にするオプションを含む) を表示できます。 キャッシュが作成された後、または初めてクラスタリングを有効にした後、クラスター サイズを変更します。

重要

クラスタリングを有効すると元には戻せません。 また、クラスタリングが有効であり、かつシャードが 1 つだけのキャッシュは、クラスタリングなしの同じサイズのキャッシュとは動作が異なります。

すべての Enterprise および Enterprise Flash レベルのキャッシュは、常にクラスター化されます。

Basic または Standard キャッシュのクラスタリングを構成できますか。

クラスタリングは、Premium、Enterprise、Enterprise Flash の各キャッシュでのみ使用できます。

Redis ASP.NET セッション状態および出力キャッシュ プロバイダーでクラスタリングを使用できますか

  • Redis 出力キャッシュ プロバイダー - 変更する必要はありません。
  • Redis セッション状態プロバイダー - クラスタリングを使用するには、RedisSessionStateProvider 2.0.1 以降を使用する必要があります。そうしないと、例外がスローされます。これは破壊的変更です。 詳細については、「v2.0.0 の破壊的変更の詳細」を参照してください。

StackExchange.Redis とクラスタリングを使用すると、MOVE 例外が発生します。どうすればよいですか。

クラスタリングを使用しているときに StackExchange.Redis を使用すると MOVE 例外が発生する場合は、StackExchange.Redis 1.1.603 以降を使用していることを確認してください。 StackExchange.Redis を使用するための .NET アプリケーションの構成手順については、「キャッシュ クライアントの構成」を参照してください。

OSS クラスタリングと Enterprise レベル キャッシュ上のEnterprise クラスタリングの違いは何ですか?

OSS クラスター モードは Premium レベルでのクラスタリングと同じであり、オープンソースクラスタリングの仕様に従います。 Enterprise クラスター モードはパフォーマンスを低下させることができますが、使用するクライアントの変更を必要としない Redis Enterprise クラスタリングを使用します。 詳細については、Enterpriseのクラスタリングを参照してください。

Enterprise レベルのキャッシュで使用されるシャードの数はいくつですか?

Enterprise および Enterprise Flash キャッシュでは、Basic、Standard、Premium レベルのキャッシュとは異なり、1 つのノード上の複数のシャードを利用できます。 詳細については、シャーディングと CPU 使用率を参照してください。

次のステップ