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 を利用できることです。 そのため、これらの層でのスケールアップとスケールアウトの両方が、サーバーの負荷を軽減するのに役立ちます。 詳細についてはAzure Cache for Redis の Enterprise と Enterprise Flash レベルのベスト プラクティスを参照してください。
- メモリ使用量
- メモリ使用量が多い場合は、データ サイズが現在のキャッシュ サイズに対して大きすぎるかことを示します。 メモリがより大きいキャッシュ サイズにスケーリングを検討してください。 ここでは、スケールアップ または スケールアウト のいずれかが効果的です。
- クライアント接続
- 各キャッシュ サイズには、サポートできるクライアント接続の数に制限があります。 クライアント接続がキャッシュ サイズの制限に近い場合は、より大きなレベルにスケールアップすることを検討してください。 スケールアウトしても、サポートされているクライアント接続の数は増えません。
- キャッシュ サイズ別の接続制限の詳細については、「Azure Cache for Redis に関する価格」を参照してください。
- ネットワーク帯域幅
- Redis サーバーが使用可能な帯域幅を超えると、サーバーがクライアントに十分な速度でデータをプッシュできないので、クライアントの要求がタイムアウトする可能性があります。 "キャッシュの読み取り" および "キャッシュの書き込み" メトリックを使用して、サーバー側の帯域幅がどれだけ使用されているかを確認します。 Redis サーバーが使用可能なネットワーク帯域幅を超える場合は、より大きなネットワーク帯域幅でより大きなキャッシュ サイズにスケールアップすることを検討をする必要があります。
- Enterprise クラスター ポリシーを使用するエンタープライズ層キャッシュの場合、スケールアウトではネットワーク帯域幅は増加しません。
- キャッシュ サイズ別のネットワークで使用可能な帯域幅の詳細については、「Azure Cache for Redis 計画に関するよくあるご質問」を参照してください。
使用するキャッシュの価格レベルを決定する方法の詳細については、「最適なサービス レベルを選択する」および「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 キャッシュまでスケールアップすることはできません。
- Enterprise とEnterprise Flashの間でスケーリングすることはできません。
以下の制限事項でスケールアウト/インすることができます:
- スケールアウト は、 Premium、 Enterprise、 Enterprise Flash の各レベルでのみサポートされます。
- スケール イン は Premium レベルでのみサポートされます。
- Premium レベルでは、スケールインまたはスケールアウトの前に、クラスタリングを最初に有効にする必要があります。
- Premium レベルでは、最大 10 シャードのスケールアウトに対する GA サポートがあります。 最大 30 シャードのサポートはプレビュー段階です。 (2 つのレプリカを含むキャッシュの場合、シャードの制限は 20 です。3 つのレプリカが含まれる場合、シャードの制限は 15 です)。
- 同時にスケールアップおよびスケールアウトできるのは、 Enterprise および Enterprise Flash レベルのみです。
スケーリング方法 - Basic、Standard、Premium レベル
Azure portalを使用してスケールアップとスケールダウンを行う
キャッシュをスケーリングするには、Azure portal でキャッシュを参照し、リソースメニューの スケール をクリックします。
作動中のウィンドウにある価格レベルを選択し、[選択] を選択します。
キャッシュを新しいレベルにスケーリングしている間、 [Redis Cache のスケールを設定しています] という通知が表示されます。
スケーリングが完了すると、状態が [拡大中] から [実行中] に変わります。
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 を使用したスケール
キャッシュをスケーリングするには、Azure portal でキャッシュを参照し、リソースメニューの スケール をクリックします。
スケールアップするには、別のキャッシュの種類 を選択し、 保存 を選択します。
重要
この時点でのみスケールアップできます。 スケールダウンできません。
スケールアウトするには、容量 スライダーを大きくします。 容量は 2 ずつ増加します。 この数は、追加する基になる Redis Enterprise ノードの数を反映しています。 この数は、プライマリ シャードとレプリカ シャードの両方に対して追加されるノードを反映するために、常に 2 つの倍数です。
重要
現時点では、スケールアウト、容量の増加のみ可能です。 スケール インすることはできません。
キャッシュを新しいレベルにスケーリングしている間、 [Redis Cache のスケールを設定しています] という通知が表示されます。
スケーリングが完了すると、状態が [拡大中] から [実行中] に変わります。
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 レベルのすべての機能を使用できますか
- スケーリング中に影響を受けるカスタム データベース
- スケーリング中にキャッシュを使用できますか
- geo レプリケーションにスケーリング制限はありますか
- サポートされていない操作
- スケーリングにはどのくらいの時間がかかりますか
- スケーリングが完了したことをどのようにして確認できますか
- クラスタリングを使用するためにクライアント アプリケーションを変更する必要がありますか
- クラスターにはキーはどのように配布されるのですか
- 作成できる最大キャッシュ サイズはどれくらいですか
- すべての Redis クライアントがクラスタリングをサポートしますか
- クラスタリングが有効になっているとき、キャッシュに接続するにはどうすればよいですか
- キャッシュの個々のシャードに直接接続できますか
- 以前に作成したキャッシュのクラスタリングを構成できますか。
- Basic または Standard キャッシュのクラスタリングを構成できますか。
- Redis ASP.NET セッション状態および出力キャッシュ プロバイダーでクラスタリングを使用できますか
- StackExchange.Redis とクラスタリングを使用すると、MOVE 例外が発生します。どうすればよいですか。
- エンタープライズ層キャッシュでの OSS クラスタリングとエンタープライズ クラスタリングの違いは何ですか?
- Enterprise レベルのキャッシュで使用されるシャードの数はいくつですか?
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 キャッシュを作成した後、これらの機能を追加することはできません。
- VNet インジェクション
- ゾーン冗長の追加
- プライマリごとに複数のレプリカを使用
これらの機能のいずれかを使用するには、Premium レベルで新しいキャッシュ インスタンスを作成する必要があります。
スケーリング中に影響を受けるカスタム データベース
キャッシュの作成中に databases の設定のカスタム値を構成した場合、価格レベルによってさまざまなデータベース制限があることに注意してください。 このシナリオでスケーリングを行う場合は、次の点を考慮します。
- 現在のレベルより低い
databases制限に価格レベルをスケーリングする場合:- すべての価格レベルが 16 の
databasesの既定の数を使っている場合、データは失われません。 - スケーリングしているレベルの制限範囲に含まれるユーザー設定の数値の
databasesを使用している場合、このdatabasesの設定は保持され、データは失われません。 - 新しいレベルの制限を超えるユーザー設定の数値の
databasesを使用している場合、databasesの設定は新しいレベルの制限より低くなり、削除されたデータベースのすべてのデータが失われます。
- すべての価格レベルが 16 の
- 現在のレベル以上の
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 サイクルが制限されます。
一般に、データを含まないキャッシュをスケーリングする場合は、約 20 分かかります。 クラスター化されたキャッシュの場合、スケーリングには最小データでシャードあたり約 20 分かかります。
スケーリングが完了したことをどのようにして確認できますか
スケール処理の進捗は Azure Portal で確認できます。 スケーリングが完了すると、キャッシュの状態が [実行中] に変わります。
クラスタリングを使用するためにクライアント アプリケーションを変更する必要がありますか
クラスタリングが有効になっている場合は、データベース 0 のみを使用できます。 クライアント アプリケーションで複数のデータベースを使用している状態で、0 以外のデータベースに対して読み取りまたは書き込みを試みると、次の例外がスローされます:
Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6。詳細については、「 Redis Cluster Specification - Implemented subset (Redis クラスターの仕様 - 実装済みのサブセット)」を参照してください。
StackExchange.Redis を使用する場合は、1.0.481 以降を使用する必要があります。 クラスタリングが無効になっているキャッシュに接続するときに使用するものと同じエンドポイント、ポート、キーを使用して、キャッシュに接続します。 唯一の違いは、すべての読み取りと書き込みをデータベース 0 に対して実行する必要があることです。
他のクライアントの要件は異なる場合があります。 「 すべての Redis クライアントがクラスタリングをサポートしますか
アプリケーションで 1 つのコマンドにバッチ処理された複数のキー操作を使用する場合は、すべてのキーを同じシャードに配置する必要があります。 キーを同じシャードに配置するには、「クラスターにはキーはどのように配布されるのですか」を参照してください。
Redis ASP.NET セッション状態プロバイダーを使用する場合は、2.0.1 以降を使用する必要があります。 「 Redis ASP.NET セッション状態および出力キャッシュ プロバイダーでクラスタリングを使用できますか
重要
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 レベルのキャッシュで使用されるシャードの数はいくつですか?
Basic、Standard、Premium レベルのキャッシュとは異なり、Enterprise および Enterprise Flash キャッシュでは、1 つのノード上の複数のシャードを利用できます。 詳細については、シャーディングと CPU 使用率を参照してください。