Azure Cache for Redis インスタンスのスケーリング
[アーティクル] 2024/07/01
15 人の共同作成者
フィードバック
この記事の内容
スケールのタイプ
可用性のスコープ
スケーリングするタイミング
スケーリングAzure Cache for Redisの前提条件/制限事項
スケーリング方法 - Basic、Standard、Premium レベル
スケールアップとスケールアウトの方法 - Enterprise および Enterprise Flash レベル
スケーリングに関する FAQ
次のステップ
さらに 4 個を表示
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 に関する価格 」を参照してください。
ネットワーク帯域幅
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を使用してスケールアップとスケールダウンを行う
キャッシュをスケーリングするには、Azure portal でキャッシュを参照 し、リソースメニューの スケール をクリックします。
作動中のウィンドウにある価格レベルを選択し、[選択] を選択します。
キャッシュを新しいレベルにスケーリングしている間、 [Redis Cache のスケールを設定しています] という通知が表示されます。
スケーリングが完了すると、状態が [拡大中] から [実行中] に変わります。
注意
ポータルでキャッシュをスケールアップまたはスケールダウンすると、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.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、CLI、または Azure CLI を使用してプログラムによってキャッシュをスケールアップまたはスケールダウンする場合、更新要求の一部としての maxmemory-reserved
または maxfragmentationmemory-reserved
は無視されます。 スケーリングの変更のみが受け入れられます。 これらのメモリ設定は、スケーリング操作の完了後に更新できます。
クラスタリングを使用してスケールアウトされる新しいキャッシュを作成する
クラスタリングは、新しいAzure Cache for Redisを作成するときに、作業ウィンドウからキャッシュを作成するときに有効になります。
オープンソース Redis キャッシュの作成 クイックスタート ガイド を使用して、Azure portalを使用して新しいキャッシュの作成を開始します。
premium キャッシュ インスタンスの [詳細] タブで、非 TLS ポート、クラスタリング、データ永続化の設定を構成します。 クラスタリングを有効にするには、 [有効] を選択します。
クラスター内に最大 30 個のシャードを作成できます。 [有効] を選択した後に、スライダーを操作するか、[シャード数] に 1 から 30 の値を入力し、[OK] を選択します。
各シャードは、Azure によって管理されるプライマリ/レプリカ キャッシュ ペアです。 キャッシュの合計サイズはシャードの数に価格レベルで選択したキャッシュ サイズを掛けることによって計算されます。
キャッシュを作成したら、クラスター化されていないキャッシュと同じように接続して使用します。 Redis は、キャッシュのシャード全体にデータを分散させます。 診断が有効 になっている場合は、シャードごとにメトリックが個別にキャプチャされ、リソースメニューを使用している Azure Cache for Redis に表示 できます。
クイック スタート ガイド を使用してキャッシュの作成を完了します。
キャッシュが作成されるまで、しばらく時間がかかります。 Azure Cache for Redis の [概要] ページで進行状況を監視できます。 [状態] に "実行中 " と表示されている場合は、キャッシュを使用する準備ができています。
StackExchange.Redis クライアントを使用したクラスタリングの操作でのサンプル コードについては、Hello World サンプルの clustering.cs 部分を参照してください。
実行中の Premium キャッシュのスケールインまたはスケールアウト
前に作成し、クラスタリングが有効になっている状態で既に実行されている Premium キャッシュのクラスター サイズを変更するには、[リソース] メニューから [クラスター サイズ] を選びます。
クラスター サイズを変更するには、スライダーを使用するか、[シャード数] ボックスに 1 から 30 の範囲の数値を入力してください。 その後、 [OK] を選択して保存します。
クラスター サイズを増やすと、スループットとキャッシュの最大サイズが増えます。 クラスター サイズを増やして、クライアントが利用できる最大接続数が増えることはありません。
PowerShell を使用したスケールアウトとスケール イン
PowerShell を使用して Azure Cache for Redis インスタンスをスケールアウトするには、または ShardCount
プロパティを変更するときに Set-AzRedisCache コマンドレットを使用します。 次の例は、myCache
という名前 のキャッシュをスケールアウトして 3 つのシャードを使用する方法を示しています (つまり、3 倍のスケール アウト)
Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3
PowerShell によるスケーリングの詳細については、PowerShell を使用した Azure Cache for Redis のスケーリング に関するページを参照してください。
Azure CLI を使用したスケールアウトとスケールイン
Azure CLI を使用してAzure Cache for Redis インスタンスをスケーリングするには、az redis 更新プログラム コマンドを呼び出し、shard-count
のプロパティを使用します。 次の例では、 myCache
という名前 のキャッシュをスケールアウトして 3 つのシャードを使用する方法を示します (つまり、3 倍のスケール アウト)。
az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3
Azure CLI によるスケーリングの詳細については、「Change settings of an existing Azure Cache for Redis 」 (既存の Azure Cache for Redis の設定を変更する) をご覧ください。
注意
PowerShell、または Azure CLI を使用してプログラムによってキャッシュをスケールアップまたはスケールダウンする場合、更新要求の一部としての maxmemory-reserved
または maxfragmentationmemory-reserved
は無視されます。 スケーリングの変更のみが受け入れられます。 これらのメモリ設定は、スケーリング操作の完了後に更新できます。
注意
クラスターをスケーリングして、高価なコマンドのMIGRATE コマンドを実行します。 影響を最小限に抑える場合は、ピーク時以外にこの操作を実行することを検討してください。 移行プロセス中には、サーバーの負荷が急増します。 クラスターのスケーリングは時間を要する処理であり、必要な時間は、キーの数とこれらのキーに関連付けられている値のサイズによって異なります。
スケールアップとスケールアウトの方法 - Enterprise および Enterprise Flash レベル
Enterprise および Enterprise Flash レベルは、1 回の操作でスケールアップおよびスケールアウトできます。 その他のレベルでは、アクションごとに個別の操作が必要です。
注意事項
Enterprise および Enterprise Flash レベルでは、 スケール ダウン や スケールイン 操作はまだサポートされていません。
キャッシュをスケーリングするには、Azure portal でキャッシュを参照 し、リソースメニューの スケール をクリックします。
スケールアップするには、別のキャッシュの種類 を選択し、 保存 を選択します。
重要
この時点でのみスケールアップできます。 スケールダウンできません。
スケールアウトするには、容量 スライダーを大きくします。 容量は 2 ずつ増加します。 この数は、追加する基になる Redis Enterprise ノードの数を反映しています。 この数は、プライマリ シャードとレプリカ シャードの両方に対して追加されるノードを反映するために、常に 2 つの倍数です。
重要
現時点では、スケールアウト、容量の増加のみ可能です。 スケール インすることはできません。
キャッシュを新しいレベルにスケーリングしている間、 [Redis Cache のスケールを設定しています] という通知が表示されます。
スケーリングが完了すると、状態が [拡大中] から [実行中] に変わります。
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 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
次の一覧は、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 クラスタリングを使用します。 詳細については、「クラスタリング 」を参照してください。
キー配布モデル の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 リダイレクト例外 が発生するか、または単にアプリケーションが中断される場合があります。
注意
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 レベルのキャッシュは、常にクラスター化されます。
クラスタリングは、Premium、Enterprise、Enterprise Flash の各キャッシュでのみ使用できます。
Redis ASP.NET セッション状態および出力キャッシュ プロバイダーでクラスタリングを使用できますか
StackExchange.Redis とクラスタリングを使用すると、MOVE 例外が発生します。どうすればよいですか。
クラスタリングを使用しているときに StackExchange.Redis を使用すると MOVE
例外が発生する場合は、StackExchange.Redis 1.1.603 以降を使用していることを確認してください。
OSS クラスタリングと Enterprise レベル キャッシュ上のEnterprise クラスタリングの違いは何ですか?
OSS クラスター モードは Premium レベルでのクラスタリングと同じであり、オープンソースクラスタリングの仕様に従います。 Enterprise クラスター モードはパフォーマンスを低下させることができますが、使用するクライアントの変更を必要としない Redis Enterprise クラスタリングを使用します。 詳細については、「クラスタリング 」を参照してください。
Enterprise レベルのキャッシュで使用されるシャードの数はいくつですか?
Enterprise および Enterprise Flash キャッシュでは、Basic、Standard、Premium レベルのキャッシュとは異なり、1 つのノード上の複数のシャードを利用できます。 詳細については、「シャーディング構成 」を参照してください。