Enterprise レベルと Enterprise Flash レベルのベスト プラクティスとは何か
Azure Cache for Redis の Enterprise レベルと Enterprise Flash レベルの使用時のベスト プラクティスは次のようになります。
ゾーン冗長
ゾーン冗長構成で新しいキャッシュをデプロイすることを強くお勧めします。 ゾーン冗長性により、Redis Enterprise ノードが 3 つの可用性ゾーンに分散され、データ センター レベルの障害からの冗長性が向上します。 ゾーン冗長を使用すると、可用性が向上します。 詳細については、「Online Services のサービス レベル アグリーメント (SLA)」を参照してください。
キャッシュ インスタンスでは常に少なくとも 3 つのノードが使用されるため、Enterprise レベルではゾーン冗長性が重要です。 2 つのノードは、データを保持するデータ ノードと "クォーラム ノード" です。 容量を増やすと、データ ノードの数が偶数単位でスケーリングされます。
クォーラム ノードと呼ばれる別のノードもあります。 このノードでは、データ ノードを監視し、フェールオーバーがあった場合は新しいプライマリ ノードを自動的に選択します。 ゾーン冗長性により、ノードが 3 つの可用性ゾーンに均等に分散され、クォーラム損失の可能性が最小限に抑えられます。 お客様はクォーラム ノードに対して課金されず、ゾーン内帯域幅の料金を除いて、ゾーン冗長性の使用に対するその他の料金は発生しません。
スケーリング
Azure Cache for Redis の Enterprise と Enterprise Flash レベルでは、"スケールアウト" よりも "スケールアップ" を優先することをお勧めします。Enterprise レベルは Redis Enterprise 上に構築されており、大規模な VM でより多くの CPU コアを利用できるため、スケールアップを優先します。
逆に、オープンソースの Redis 上に構築された Basic、Standard、Premium の各レベルでは、反対のレコメンデーションが当てはまります。 これらのレベルでは、ほとんどの場合、"スケールアウト" よりも "スケールアップ" を優先することをお勧めします。
シャーディングと CPU 使用率
Azure Cache for Redis の Basic、Standard、Premium の各レベルでは、使用される仮想 CPU (vCPU) の数を簡単に判断できます。 各 Redis ノードは、専用仮想マシン (VM) 上で実行されます。 Redis サーバー プロセスはシングルスレッドであり、各プライマリ ノードと各レプリカ ノードで 1 つの vCPU を使用します。 VM 上の他の vCPU は、さまざまなタスクのワークフロー調整、正常性の監視、TLS の読み込みなど、他のアクティビティにも引き続き使用されます。
クラスタリングを使用すると、ノードごとに 1 つのシャードを使用して、より多くのノードにデータが分散されます。 シャードの数を増やすと、クラスター内のシャードの数に基づいて、使用する vCPU の数が直線的に増えます。
一方、Redis Enterprise では、Redis インスタンス自体に複数の vCPU を使用できます。 言い換えると、Azure Cache for Redis のすべてのレベルで、バックグラウンド タスクと監視タスクに複数の vCPU を使用できますが、Redis シャード用の VM ごとに複数の vCPU を使用できるのは Enterprise と Enterprise Flash レベルのみです。 この表は、各 SKU と容量 (つまりスケールアウト) 構成に使用される有効な vCPU の数を示しています。
表には、レプリカ シャードではなく、プライマリ シャードに使用される vCPU の数が示されています。 シャードは、vCPU の数に 1 対 1 で対応していません。 表には、シャードではなく vCPU のみを示しています。 一部の構成では、使用可能な vCPU よりも多くのシャードを使用して、一部の使用シナリオでパフォーマンスを向上させています。
E1
| 容量 | 有効な vCPU |
|---|---|
| 2 | 1 (バースト可能) |
E5
| 容量 | 有効な vCPU |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| 容量 | 有効な vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| 容量 | 有効な vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| 容量 | 有効な vCPU |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| 容量 | 有効な vCPU |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| 容量 | 有効な vCPU |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| 容量 | 有効な vCPU |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| 容量 | 有効な vCPU |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| 容量 | 有効な vCPU |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| 容量 | 有効な vCPU |
|---|---|
| 3 | 30 |
| 9 | 90 |
Enterprise でのクラスタリング
Enterprise と Enterprise Flash レベルは、Basic、Standard、Premium の各レベルとは対照的に、本質的にクラスター化されています。 実装は、選択されているクラスタリング ポリシーによって異なります。 Enterprise レベルでは、クラスタリング ポリシーに OSS と Enterprise の 2 つの選択肢があります。 OSS クラスター ポリシーは最大スループットが高くなるためほとんどのアプリケーションにお勧めしますが、各バージョンには長所と短所があります。
"OSS クラスタリング ポリシー" では、オープンソース Redis と同じ Redis クラスター API が実装されます。 Redis クラスター API を使用すると、Redis クライアントは各 Redis ノードに直接接続でき、待機時間を最小限に抑え、ネットワーク スループットを最適化できます。 その結果、より多くのノードを使用してクラスターをスケールアウトすると、ほぼ線形のスケーラビリティが得られます。 OSS クラスタリング ポリシーでは、一般に最適な待機時間とスループットのパフォーマンスが提供されますが、Redis クラスタリングをサポートするにはクライアント ライブラリが必要です。 また、OSS クラスタリング ポリシーは RediSearch モジュールでは使用できません。
"Enterprise クラスタリング ポリシー" は、すべてのクライアント接続に単一のエンドポイントを使用するという、よりシンプルな構成です。 Enterprise クラスタリング ポリシーを使用すると、すべての要求が 1 つの Redis ノードにルーティングされ、その後プロキシとして使用され、クラスター内の正しいノードに要求が内部的にルーティングされます。 この方法の利点は、Redis クライアント ライブラリが複数のノードを利用するために Redis クラスタリングをサポートする必要がないということです。 欠点は、単一ノード プロキシが、コンピューティング使用率またはネットワーク スループットのボトルネックになる可能性があるということです。 Enterprise クラスタリング ポリシーは、RediSearch モジュールで使用できる唯一のポリシーです。
マルチキー コマンド
Enterprise レベルではクラスター化された構成が使用されるため、複数のキーで動作するコマンドに CROSSSLOT 例外が表示される場合があります。 動作は使用されるクラスタリング ポリシーによって異なります。 OSS クラスタリング ポリシーを使用する場合、マルチキー コマンドでは、すべてのキーを同じハッシュ スロットにマップする必要があります。
Enterprise クラスタリング ポリシーで CROSSSLOT エラーが表示される場合もあります。 Enterprise クラスタリングを使用するスロットでは、DEL、MSET、MGET、EXISTS、UNLINK、TOUCH のマルチキー コマンドのみを使用できます。
アクティブ/アクティブ データベースでは、マルチキー書き込みコマンド (DEL、MSET、UNLINK) は、同じスロット内のキーに対してのみ実行できます。 ただし、次のマルチキー コマンドは、アクティブ/アクティブ データベース内のスロット間で許可されます: MGET、EXISTS、および TOUCH。 詳細については、「データベース クラスタリング」を参照してください。
Enterprise Flash のベスト プラクティス
Enterprise Flash レベルでは、NVMe フラッシュ ストレージと RAM の両方が利用されます。 フラッシュ ストレージの方がコストが低いため、Enterprise Flash レベルを使用すると、価格効率のためにパフォーマンスをトレードオフできます。
Enterprise Flash インスタンスでは、キャッシュ領域の 20% が RAM 上にあり、残りの 80% はフラッシュ ストレージを使用します。 キーはすべて RAM に格納されますが、値はフラッシュ ストレージまたは RAM に格納できます。 Redis ソフトウェアは、値の場所をインテリジェントに決定します。 頻繁にアクセスされる "ホット" 値は RAM に格納され、使用頻度の低い "コールド" 値はフラッシュに保持されます。 データを読み取るか書き込む前に、RAM に移動し、"ホット" データにする必要があります。
Redis は最適なパフォーマンスのために最適化するので、インスタンスは最初に使用可能な RAM をいっぱいにしてから、フラッシュ ストレージに項目を追加します。 最初に RAM に格納することで、パフォーマンスにいくつかの影響があります。
- メモリ使用量が少ないテストでは、パフォーマンスが向上し、待ち時間が短くなる可能性があります。 キャッシュ インスタンスをいっぱいまで使うテストでは、RAM はメモリ使用量の少ないテスト フェーズでのみ使われるため、パフォーマンスが低下する可能性があります。
- キャッシュに書き込むデータが増えるにつれて、RAM 内のデータの割合がフラッシュ ストレージと比較して減少し、通常、待機時間とスループットのパフォーマンスも低下します。
Enterprise Flash レベルに適したワークロード
多くの場合、Enterprise Flash レベルで適切に動作する可能性が高いワークロードには、次の特性があります。
- 読み取り負荷が高く、書き込みコマンドに対する読み取りコマンドコマンドの比率が高い。
- データセットの残りの部分よりもはるかに頻繁に使用されるキーのサブセットにアクセスの重点が置かれている。
- キー名と比較して値が比較的大きい。 (キー名は常に RAM に格納されるため、大きい値がメモリの増加のボトルネックになる可能性があります)。
Enterprise Flash レベルに適していないワークロード
一部のワークロードには、Flash レベルの設計に対してあまり最適化されていないアクセス特性があります。
- 書き込み負荷の高いワークロード。
- データセットの大部分にわたるランダムまたは均一なデータ アクセスのパターン。
- 値のサイズが比較的小さい長いキー名。
アクティブ geo レプリケーションを使用したリージョン ダウン シナリオの処理
アクティブ geo レプリケーションは、Azure Cache for Redis の Enterprise レベルを使用する場合に可用性を大幅に向上させる強力な機能です。 ただし、リージョンで障害が発生した場合は、キャッシュを準備する手順を実行する必要があります。
たとえば、次のヒントについて考えてみます。
- リージョンがダウンした場合に切り替える geo レプリケーション グループ内の他のキャッシュを事前に特定します。
- 特定されたバックアップ キャッシュにアプリケーションとクライアントがアクセスできるように、ファイアウォールの設定を確認します。
- geo レプリケーション グループ内の各キャッシュには、独自のアクセス キーがあります。 バックアップ キャッシュをターゲットにするときに、アプリケーションでさまざまなアクセス キーを切り替える方法を決定します。
- geo レプリケーション グループ内のキャッシュがダウンすると、geo レプリケーション グループ内のすべてのキャッシュでメタデータの蓄積が開始されます。 書き込みをすべてのキャッシュに再度同期できるようになるまで、メタデータを破棄することはできません。 ダウンしているキャッシュの "リンクを強制的に解除" して、メタデータの蓄積を防ぐことができます。 特に書き込み負荷の高いワークロードでは、キャッシュ内の使用可能なメモリを監視し、メモリ不足がある場合はリンクを解除することを検討してください。
サーキット ブレーカー パターンを使用することもできます。 このパターンを使用して、リージョンが停止しているキャッシュから、同じ geo レプリケーション グループ内のバックアップ キャッシュにトラフィックを自動的にリダイレクトします。 リダイレクトを有効にするには、Azure Traffic Manager や Azure Load Balancer などの Azure サービスを使用します。
データ永続化とデータ バックアップ
Enterprise と Enterprise Flash レベルのデータ永続化機能は、キャッシュがダウンしたときにデータの迅速な復旧ポイントを自動的に提供するように設計されています。 キャッシュ インスタンスにマウントされているマネージド ディスクに RDB または AOF ファイルを格納することで、迅速な復旧が可能になります。 ディスク上の永続化ファイルにはユーザーがアクセスできません。
多くのお客様は、永続化を使用して、キャッシュ上のデータの定期的なバックアップを取得したいと考えています。 この方法でデータ永続化を使用することはお勧めしません。 代わりに、インポート/エクスポート機能を使用します。 RDB 形式のキャッシュ データのコピーを選択したストレージ アカウントに直接エクスポートし、必要な頻度でデータ エクスポートをトリガーできます。 エクスポートは、ポータルから、または CLI、PowerShell、または SDK ツールを使用してトリガーできます。
E1 SKU の制限
E1 SKU は主に、開発/テストのシナリオを対象としています。 E1 は、小さめのバースト可能な VM で実行されます。 バースト可能な VM では、CPU の使用量に基づいて可変のパフォーマンスが提供されます。 他の Enterprise SKU オファリングとは異なり、E1 SKU を "スケールアウト" することはできませんが、より大きな SKU に "スケールアップ" することはできます。 また、E1 SKU ではアクティブ geo レプリケーションはサポートされていません。