Premium Azure Cache for Redis インスタンスに対する仮想ネットワーク (VNet) サポートの構成
Azure Virtual Network のデプロイにより、セキュリティと分離が強化されると共に、サブネット、アクセス制御ポリシーや、アクセスをさらに制限する他の機能も提供されます。 Azure Cache for Redis インスタンスが仮想ネットワークで構成された場合、パブリックにアドレスを指定することはできません。 代わりに、インスタンスには仮想ネットワーク内の仮想マシンとアプリケーションからのみアクセスできます。 この記事では、Premium レベルの Azure Cache for Redis インスタンスに対する仮想ネットワークのサポートを構成する方法について説明します。
Note
クラシック デプロイ モデルは、2024 年 8 月に廃止されます。 詳細については、「Cloud Services (クラシック) のデプロイ モデルが 2024 年 8 月 31 日に廃止される」を参照してください。
重要
Azure Cache for Redis では、ネットワーク アーキテクチャが簡素化され、Azure 内のエンドポイント間の接続がセキュリティで保護される Azure Private Link の使用を推奨しています。 仮想ネットワーク内のサブネットでプライベート IP アドレスが割り当てられているプライベート エンドポイント経由で、仮想ネットワークから Azure Cache インスタンスに接続できます。 Azure Private Link はすべてのレベルで提供されており、Azure Policy のサポートと、簡略化された NSG ルール管理が含まれます。 詳細については、Private Link に関するドキュメントのページを参照してください。 VNet インジェクションされたキャッシュから Private Link に移行する方法については、「VNet インジェクション キャッシュから Private Link キャッシュに移行する」を参照してください。
VNet インジェクションの制限事項
- 多くの場合、仮想ネットワーク構成を作成して維持すると、エラーが発生しやすくなります。 トラブルシューティングも困難です。 仮想ネットワークの構成が正しくないと、次の問題が発生する可能性があります:
- キャッシュ インスタンスからの妨害されたメトリックの送信
- レプリカ ノードがプライマリ ノードからデータをレプリケートできない
- データ損失の可能性
- スケーリングなどの管理操作の失敗
- 断続的または完全な SSL/TLS エラー
- セキュリティおよび信頼性の向上などの重要な更新を含め、更新プログラムを適用できない
- 最も深刻なシナリオでは、可用性の損失
- VNet の挿入されたキャッシュを使用する場合、証明書の失効リスト、公開キー基盤、Azure Key Vault、Azure Storage、Azure Monitor などのキャッシュの依存関係にアクセスできるように、VNet を最新の状態に保つ必要があります。
- VNet に挿入されたキャッシュは、Premium レベルの Azure Cache for Redis でのみ使用でき、他の層では使用できません。
- 既存の Azure Cache for Redis インスタンスを Virtual Network に挿入することはできません。 キャッシュを 作成 するときは、このオプションを選択する必要があります。
仮想ネットワーク サポートの設定
Virtual Network (VNet) のサポートは、キャッシュの作成中に [New Azure Cache for Redis](新しい Azure Cache for Redis) ペインで構成します。
Premium レベルのキャッシュを作成するには、Azure portal にサインインし、 [リソースの作成] を選択します。 これらは Resource Manager テンプレート、PowerShell、または Azure CLI を使用して作成することもできます。
![[リソースの作成] を示すスクリーンショット。](media/cache-private-link/1-create-resource.png)
[新規] ページで、 [データベース] を選択します。 次に [Azure Cache for Redis] を選択します。
![[Azure Cache for Redis] の選択を示すスクリーンショット。](media/cache-private-link/2-select-cache.png)
[新規 Redis Cache] ページで、新しい Premium レベルのキャッシュの設定を構成します。
設定 提案された値 説明 DNS 名 グローバルに一意の名前を入力します。 キャッシュ名は 1 から 63 文字の文字列で、数字、英字、ハイフンのみを使用する必要があります。 名前の先頭と末尾には数字または文字を使用する必要があり、連続するハイフンを含めることはできません。 キャッシュ インスタンスのホスト名は \<DNS name>.redis.cache.windows.netです。サブスクリプション ドロップダウン リストからサブスクリプションを選択します。 この新しい Azure Cache for Redis インスタンスが作成されるサブスクリプション。 リソース グループ ドロップダウン リストからリソース グループを選択するか、 [新規作成] を選択して新しいリソース グループの名前を入力します。 その中にキャッシュやその他のリソースを作成するリソース グループの名前。 すべてのアプリ リソースを 1 つのリソース グループに配置することで、それらをまとめて簡単に管理または削除できます。 場所 ドロップダウン リストから場所を選択します。 キャッシュを使用する他のサービスの近くのリージョンを選択します。 キャッシュの種類 Premium レベルの機能を構成するには、ドロップダウン リストから Premium レベルのキャッシュを選択します。 詳細については、Azure Cache for Redis の価格に関するページを参照してください。 価格レベルによって、キャッシュに使用できるのサイズ、パフォーマンス、および機能が決まります。 詳細については、Azure Cache for Redis の概要に関するページを参照してください。 [ネットワーク] タブを選択するか、ページの下部にある [ネットワーク] ボタンを選択します。
[ネットワーク] タブで、接続方法として [仮想ネットワーク] を選択します。 新しい仮想ネットワークを使用するには、まず Azure portal を使用した仮想ネットワークの作成に関するページまたは「Azure portal を使用した仮想ネットワーク (クラシック) の作成」の手順に従ってそれを作成します。 次に、 [New Azure Cache for Redis](新しい Azure Cache for Redis) ペインに戻り、Premium レベルのキャッシュを作成して構成します。
重要
Azure Cache for Redis を Resource Manager 仮想ネットワークにデプロイする場合、キャッシュは、Azure Cache for Redis インスタンス以外のリソースを含まない専用サブネット内に存在する必要があります。 Azure Cache for Redis インスタンスを、他のリソースを含む、または NAT Gateway が割り当てられた Resource Manager 仮想ネットワークのサブネットにデプロイしようとすると、そのデプロイは失敗します。 この失敗は、NAT Gateway と互換性のない基本ロード バランサーが Azure Cache for Redis で使用されているためです。
設定 提案された値 説明 Virtual Network ドロップダウン リストから仮想ネットワークを選択します。 ご自分のキャッシュと同じサブスクリプションと場所に存在する仮想ネットワークを選択します。 サブネット ドロップダウン リストからサブネットを選択します。 サブネットのアドレスの範囲は CIDR 表記である必要があります (例: 192.168.1.0/24)。 仮想ネットワークのアドレス空間に含まれている必要があります。 静的 IP アドレス (省略可能) 静的 IP アドレスを入力します。 静的 IP アドレスを指定しなかった場合は、IP アドレスが自動的に選択されます。 重要
Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。 サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。 詳細については、「これらのサブネット内の IP アドレスの使用に関する制限はありますか」をご覧ください。
Azure 仮想ネットワーク インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 Azure Cache for Redis インスタンスは、シャードごとに 2 つの IP アドレスと、ロード バランサー用に 1 つの追加 IP アドレスを使用します。 クラスター化されていないキャッシュは、1 つのシャードを持つと見なされます。
ページの下部にある [次へ: 詳細] タブを選択するか、ページの下部にある [次へ: 詳細] ボタンを選択します。
Premium レベルのキャッシュ インスタンスの [詳細] タブで、非 TLS ポート、クラスタリング、およびデータ永続化の設定を構成します。
ページの下部にある [次へ: タグ] タブを選択するか、ページの下部にある [次へ: タグ] ボタンを選択します。
必要に応じて、 [タグ] タブで、リソースを分類する場合は名前と値を入力します。
[Review + create](レビュー + 作成) を選択します。 [確認および作成] タブが表示され、Azure によって構成が検証されます。
緑色の検証に成功のメッセージが表示された後、 [作成] を選択します。
キャッシュが作成されるまで、しばらく時間がかかります。 Azure Cache for Redis の [概要] ページで進行状況を監視できます。 [状態] に "実行中" と表示されている場合は、キャッシュを使用する準備ができています。 キャッシュが作成されたら、 [リソース] メニューの [仮想ネットワーク] を選択することで、仮想ネットワークの構成を表示できます。
Azure Cache for Redis 仮想ネットワークに関する FAQ
次の一覧は、Azure Redis Cache ネットワークに関してよく寄せられる質問への回答です。
- Azure Cache for Redis と仮想ネットワークの誤った構成に関してよく見られる問題を教えてください
- 仮想ネットワークで自分のキャッシュの動作を確認するにはどうすればよいですか?
- 仮想ネットワークで自分の Azure Cache for Redis インスタンスに接続しようとすると、リモート証明書が無効であるというエラーが表示されるのはなぜですか?
- Standard または Basic キャッシュで仮想ネットワークを使用できますか?
- Azure Cache for Redis インスタンスの作成が失敗するサブネットと成功するサブネットがあるのはなぜですか?
- サブネット アドレス空間の要件には何がありますか
- ピアリングされた仮想ネットワークからキャッシュに接続できますか?
- Azure Lighthouse が有効になっているキャッシュで VNet インジェクションはサポートされていますか?
- キャッシュが仮想ネットワークでホストされている場合、すべてのキャッシュ機能が動作しますか?
- Azure Lighthouse が有効になっているキャッシュで VNet インジェクションはサポートされていますか?
Azure Cache for Redis と仮想ネットワークの誤った構成に関してよく見られる問題を教えてください
Azure Cache for Redis が仮想ネットワークでホストされている場合は、以下の表に含まれるポートが使用されます。
重要
以下の表に含まれるポートがブロックされている場合、キャッシュが正常に動作しない可能性があります。 仮想ネットワークで Azure Cache for Redis を使用する場合の構成の誤りに関する最も一般的な問題は、これらのポートのうち 1 つ以上がブロックされていることです。
送信ポートの要件
Azure Cache for Redis にはネットワーク接続要件があります。これはキャッシュを機能させるのに必要な他の依存関係サービスへの送信接続を行うため、またはノード間通信で Redis サブネット内部への接続を行うために必要となるものです。
| Port | Direction | トランスポート プロトコル | 目的 | ローカル IP | リモート IP |
|---|---|---|---|---|---|
| 80、443 | 送信 | TCP | Azure Storage、PKI (インターネット)、オペレーティング システム、インフラストラクチャ、ウイルス対策に対する Redis の依存関係 | (Redis サブネット) | * 4 |
| 443 | 送信 | TCP | Azure Key Vault と Azure Monitor に対する Redis の依存関係 | (Redis サブネット) | AzureKeyVault、AzureMonitor 1 |
| 12000 | 送信 | TCP | Azure Monitor に対する Redis の依存関係 | (Redis サブネット) | AzureMonitor 1 |
| 53 | 送信 | TCP/UDP | DNS (インターネット/仮想ネットワーク) に対する Redis の依存関係 | (Redis サブネット) | 168.63.129.16 および 169.254.169.254 2 およびサブネットのカスタム DNS サーバー 3 |
| 123 | Outbound | UDP | NTP に対するオペレーティング システムの依存関係 | (Redis サブネット) | * |
| 1688 | 送信 | TCP | ライセンス認証のためのオペレーティング システムの依存関係 | (Redis サブネット) | * |
| 8443 | 送信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
| 10221-10231 | 送信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
| 20226 | 送信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
| 13000-13999 | 送信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
| 15000-15999 | 送信 | TCP | Redis および geo レプリケーションの内部通信 | (Redis サブネット) | (Redis サブネット) (geo レプリカ ピア サブネット) |
| 6379-6380 | 送信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
1 Resource Manager ネットワーク セキュリティ グループ (NSG) でサービス タグ AzureKeyVault と AzureMonitor を使用できます。
2 Microsoft が所有するこれらの IP アドレスは、Azure DNS を提供するホスト VM をアドレス指定するために使用されます。
3 この情報は、カスタム DNS サーバーのないサブネット、またはカスタム DNS を無視する新しい Redis キャッシュには必要ありません。
4 詳細については、「仮想ネットワーク接続に関するその他の要件」を参照してください。
geo レプリケーション ピア ポートの要件
Azure 仮想ネットワーク内のキャッシュ間で geo レプリケーションを使用している場合は、a) 受信 "および" 送信方向の両方でサブネット全体に対して、および b) 両方のキャッシュに対して、ポート 15000-15999 のブロックを解除します。 この構成を使用すると、将来 geo フェールオーバーが発生しても、サブネット内のすべてのレプリカ コンポーネントが相互に直接通信できます。
受信ポートの要件
受信ポートの範囲には、8 個の要件があります。 これらの範囲の受信要求は、同じ仮想ネットワークでホストされている他のサービスからの受信のものです。 または、Redis サブネット通信の内部のものです。
| Port | Direction | トランスポート プロトコル | 目的 | ローカル IP | リモート IP |
|---|---|---|---|---|---|
| 6379, 6380 | 受信 | TCP | Redis へのクライアント通信、Azure 負荷分散 | (Redis サブネット) | (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer 1 |
| 8443 | 受信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
| 8500 | 受信 | TCP/UDP | Azure 負荷分散 | (Redis サブネット) | AzureLoadBalancer |
| 10221-10231 | 受信 | TCP | Redis クラスターへのクライアント通信、Redis の内部通信 | (Redis サブネット) | (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer |
| 13000-13999 | 受信 | TCP | Redis クラスターへのクライアント通信、Azure 負荷分散 | (Redis サブネット) | (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer |
| 15000-15999 | 受信 | TCP | Redis クラスター、Azure 負荷分散、geo レプリケーションへのクライアント通信 | (Redis サブネット) | (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer、(geo レプリカ ピア サブネット) |
| 16001 | 受信 | TCP/UDP | Azure 負荷分散 | (Redis サブネット) | AzureLoadBalancer |
| 20226 | 受信 | TCP | Redis の内部通信 | (Redis サブネット) | (Redis サブネット) |
1 NSG 規則を作成するために、サービス タグ AzureLoadBalancer (Resource Manager の場合) または AZURE_LOADBALANCER (クラシック デプロイ モデルの場合) を使用できます。
仮想ネットワーク接続に関するその他の要件
Azure Cache for Redis にはネットワーク接続要件があります。これはキャッシュを機能させるのに必要な他の依存関係サービスへの送信接続を行うため、またはノード間通信で Redis サブネット内部への接続を行うために必要となるものです。
Azure Cache for Redis を仮想ネットワーク内で使用する場合は、適切に機能させるために、次の送信接続項目がすべて必要です。
| ホスト名 | プロトコル | 送信ポート | 目的 | サービス タグ |
|---|---|---|---|---|
| *.vault.azure.net | HTTPS | 443 | Azure Key Vault | AzureKeyVault |
| *.table.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| *.blob.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| *.queue.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| *.file.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| ocsp.digicert.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| crl4.digicert.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| ocsp.msocsp.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| mscrl.microsoft.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| crl3.digicert.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| cacerts.digicert.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| oneocsp.microsoft.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| crl.microsoft.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| cacerts.geotrust.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| www.microsoft.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| cdp.geotrust.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| status.geotrust.com | HTTP | 80 | Azure Public Key Infrastructure | 該当なし |
| shoebox3.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| shoebox3-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| shoebox3-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| global.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| gcs.prod.monitoring.core.windows.net | HTTPS | 443 | Azure Monitor | AzureMonitor |
| *.prod.warm.ingest.monitor.core.windows.net | HTTPS | 443 | Azure Monitor | AzureMonitor |
| *.servicebus.windows.net | HTTPS | 443 | Azure Monitor | EventHub |
| *.update.microsoft.com | HTTPS | 443 | オペレーティング システム更新サービス | AzureCloud |
| *.windowsupdate.com | HTTP/HTTPS | 80、443 | オペレーティング システム更新サービス | 該当なし |
| *.delivery.mp.microsoft.com | HTTP/HTTPS | 80、443 | オペレーティング システム更新サービス | AzureCloud |
| go.microsoft.com | HTTP/HTTPS | 80、443 | ウイルス対策 | 該当なし |
| *.wdcp.microsoft.com | HTTPS | 443 | ウイルス対策 | AzureCloud |
| *.wdcpalt.microsoft.com | HTTPS | 443 | ウイルス対策 | AzureCloud |
| *.wd.microsoft.com | HTTPS | 443 | ウイルス対策 | AzureCloud |
| definitionupdates.microsoft.com | HTTPS | 443 | ウイルス対策 | 該当なし |
| azurewatsonanalysis-prod.core.windows.net | HTTPS | 443 | 内部診断 | AzureCloud |
| shavamanifestazurecdnprod1.azureedge.net | HTTPS | 443 | 内部診断 | 該当なし |
| shavamanifestcdnprod1.azureedge.net | HTTPS | 443 | 内部診断 | 該当なし |
| *.data.microsoft.com | HTTPS | 443 | 内部診断 | AzureCloud |
- 仮想ネットワーク用の DNS 構成では、前の表に記載されているすべてのエンドポイントとドメインを解決できるようにする必要があります。 これらの DNS 要件を満たすには、仮想ネットワークの有効な DNS インフラストラクチャを構成し、保守します。
仮想ネットワークで自分のキャッシュの動作を確認するにはどうすればよいですか?
重要
仮想ネットワークでホストされている Azure Cache for Redis インスタンスに接続する場合、キャッシュのクライアントは同じ仮想ネットワーク内か、同じ Azure リージョン内で仮想ネットワーク ピアリングが有効になっている仮想ネットワーク内に存在する必要があります。 グローバル仮想ネットワーク ピアリングは現在サポートされていません。 この要件は、すべてのテスト アプリケーションや診断 ping ツールに当てはまります。 クライアント アプリケーションがどこでホストされているかに関係なく、クライアントのネットワーク トラフィックが Azure Cache for Redis インスタンスに到達できるよう NSG または他のネットワーク層を構成する必要があります。
前のセクションで説明したようにポート要件を構成した後、変更が正しく反映されるようにするには、ほとんどの場合再起動が必要です。 そうしないと、接続の問題が発生する可能性があります。 次の手順に従うと、キャッシュが動作していることを確認できます。
- すべてのキャッシュ ノードを再起動します。 「受信ポートの要件」と「送信ポートの要件」に記載されているように、必要なすべてのキャッシュ依存関係に到達できない場合、キャッシュは正常に再起動できません。
- キャッシュ ノードが再起動したら (Azure portal のキャッシュの状態で報告されます)、次のテストを実行できます。
tcpingを使って、キャッシュと同じ仮想ネットワーク内にあるコンピューターから、ポート 6380 を使用してキャッシュ エンドポイントを ping します。 例:tcping.exe contosocache.redis.cache.windows.net 6380tcpingツールからポートが開いていることがレポートされる場合、キャッシュは仮想ネットワーク内のクライアントからの接続に使用できます。別のテスト方法: キャッシュに接続してキャッシュのいくつかの項目を追加および取得するテスト キャッシュ クライアントを作成します。 テスト キャッシュ クライアントは、StackExchange.Redis を使用するコンソール アプリケーションなどが考えられます。 キャッシュと同じ仮想ネットワーク内にある VM にサンプル クライアント アプリケーションをインストールします。 次に、それを実行して、キャッシュへの接続を確認します。
仮想ネットワークで自分の Azure Cache for Redis インスタンスに接続しようとすると、リモート証明書が無効であるというエラーが表示されるのはなぜですか?
仮想ネットワークで Azure Cache for Redis インスタンスに接続しようとすると、次のような証明書の検証エラーが表示されます。
{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}
IP アドレスでホストに接続していることが原因である可能性があります。 ホスト名を使用することをお勧めします。 つまり、次の文字列を使用してください。
[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False
次の接続文字列のような IP アドレスは使用しないでください。
10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False
DNS 名を解決できない場合、StackExchange.Redis クライアントによって指定される sslHost のような構成オプションが、クライアント ライブラリに含まれている場合があります。 このオプションによって、証明書の検証に使用されるホスト名をオーバーライドできます。 次に例を示します。
10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net
さらに、Azure Cache for Redis がホストされているサブネットが、SSL/TLS 機能のためにポート 80 経由の TCP 送信接続をブロックしている場合、クライアントで断続的な TLS 証明書の検証エラーが発生する可能性があります。
Standard または Basic キャッシュで仮想ネットワークを使用できますか?
仮想ネットワークは、Premium レベルのキャッシュでのみ使用できます。
Azure Cache for Redis インスタンスの作成が失敗するサブネットと成功するサブネットがあるのはなぜですか?
Azure Cache for Redis インスタンスを仮想ネットワークにデプロイする場合、キャッシュは、他のリソースの種類が含まれない専用サブネット内に配置する必要があります。 Azure Cache for Redis インスタンスを、他のリソース (Azure Application Gateway インスタンスや送信 NAT など) が含まれる Resource Manager 仮想ネットワーク サブネットにデプロイしようとすると、そのデプロイは通常失敗します。 新しい Azure Cache for Redis インスタンスを作成する前に、他の種類の既存のリソースを削除してください。
また、十分な数の使用可能な IP アドレスがサブネット内にある必要があります。
サブネット アドレス空間の要件には何がありますか
Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。 サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。 詳細については、「 これらのサブネット内の IP アドレスの使用に関する制限はありますか
Azure 仮想ネットワーク インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 Azure Cache for Redis インスタンスでは、クラスター シャードごとに 2 つの IP アドレスと、存在する場合は追加のレプリカ用の IP アドレスが使用されます。 ロード バランサー用に IP アドレスが追加で 1 つ使用されます。 クラスター化されていないキャッシュは、1 つのシャードを持つと見なされます。
ピアリングされた仮想ネットワークからキャッシュに接続できますか?
仮想ネットワークが同じリージョンに存在する場合は、仮想ネットワーク ピアリングまたは VPN Gateway VNET 間接続を使用してそれらを接続できます。
ピアリングされた Azure 仮想ネットワークが "異なる" リージョンにある場合、リージョン 1 のクライアント VM は、負荷分散された IP アドレスを使用してリージョン 2 のキャッシュにアクセスできませんが、これは Basic ロード バランサーによる制約のためです。 つまり、Standard ロード バランサーを使用したキャッシュである場合を除きますが、これは現時点では "可用性ゾーン" で作成されたキャッシュに限定されます。
仮想ネットワーク ピアリングの制約の詳細については、Virtual Network - ピアリングの要件と制約に関するページを参照してください。 解決策の 1 つは、仮想ネットワーク ピアリングではなく VPN Gateway VNet 間接続を使用することです。
キャッシュが仮想ネットワークでホストされている場合、すべてのキャッシュ機能が動作しますか?
キャッシュが仮想ネットワークの一部である場合は、仮想ネットワーク内のクライアントだけがキャッシュにアクセスできます。 そのため、次のキャッシュ管理機能は現時点では動作しません。
- Redis コンソール: Redis コンソールはローカル ブラウザーで実行されます。これは通常、仮想ネットワークに接続されていない開発者用コンピューター上にあるため、キャッシュに接続できません。
Azure Lighthouse が有効になっているキャッシュで VNet インジェクションはサポートされていますか?
いいえ。サブスクリプションで Azure Lighthouse が有効になっている場合、Azure Cache for Redis インスタンスで VNet インジェクションを使用することはできません。 代わりに、プライベート リンクを使用してください。
ExpressRoute と Azure Cache for Redis の使用
お客様は、Azure ExpressRoute 回線を各自の仮想ネットワーク インフラストラクチャに接続することができます。 こうすることで、オンプレミスのネットワークを Azure に拡張できます。
既定では、新たに作成した ExpressRoute 回線は、仮想ネットワークで強制トンネリング (既定のルート 0.0.0.0/0 のアドバタイズ) を使用しません。 その結果、送信インターネット接続は仮想ネットワークから直接許可されます。 クライアント アプリケーションでは、Azure Cache for Redis インスタンスを含む他の Azure エンドポイントに接続できます。
お客様の一般的な構成では、強制トンネリング (デフォルト ルートのアドバタイズ) が使用され、送信インターネット トラフィックを強制的にオンプレミスにフローさせます。 このトラフィック フローでは、送信トラフィックがオンプレミスでブロックされると、Azure Cache for Redis との接続が切断されます。そのため、Azure Cache for Redis インスタンスがその依存関係と通信できなくなります。
解決策は、Azure Cache for Redis インスタンスを含むサブネット上で 1 つ以上のユーザー定義ルート (UDR) を定義することです。 UDR は、既定のルートに優先するサブネット固有のルートを定義します。
可能な場合、次の構成を使用します。
- ExpressRoute 構成によって 0.0.0.0/0 をアドバタイズし、既定でオンプレミスの全送信トラフィックを強制的にトンネリングします。
- Azure Cache for Redis インスタンスを含むサブネットに適用される UDR では、0.0.0.0/0 と、パブリック インターネットへの TCP/IP トラフィック用に動作するルートを定義します。 たとえば、次ホップの種類を internet に設定します。
これらの手順を組み合わせた結果として、サブネットレベルの UDR は ExpressRoute 強制トンネリングよりも優先されるので、Azure Cache for Redis インスタンスからの送信インターネット アクセスを確保できます。
ExpressRoute を使用してオンプレミス アプリケーションから Azure Cache for Redis インスタンスに接続することは、パフォーマンス上の理由から、一般的な使用シナリオではありません。 最適なパフォーマンスを得るには、Azure Cache for Redis クライアントが Azure Cache for Redis インスタンスと同じリージョンにある必要があります。
重要
ExpressRoute 構成でアドバタイズされたルートよりも優先するには、UDR に定義されているルートを詳細にする 必要があります 。 以下の例では、0.0.0.0/0 という広域なアドレス範囲を使用しているので、より具体的なアドレスの範囲を使用するルート アドバタイズによって誤ってオーバーライドされる可能性があります。
警告
Azure Cache for Redis は、"Microsoft ピアリング パスからプライベート ピアリング パスにルートを正しくクロスアドバタイズしていない" ExpressRoute 構成ではサポートされません。 Microsoft ピアリングが構成された ExpressRoute 構成は、大規模な Microsoft Azure の IP アドレス範囲について Microsoft からルート アドバタイズを受信します。 これらのアドレス範囲がプライベート ピアリング パスで誤ってクロスアドバタイズされている場合、Azure Cache for Redis インスタンスのサブネットからのすべての発信ネットワーク パケットは、誤って顧客のオンプレミス ネットワーク インフラストラクチャに強制的にトンネリングされます。 このネットワーク フローでは、Azure Cache for Redis が機能しません。 この問題を解決するには、Microsoft ピアリング パスからプライベート ピアリング パスへのルートのクロスアドバタイズを停止します。
UDR の背景情報については、「仮想ネットワーク トラフィックのルーティング」を参照してください。
ExpressRoute の詳細については、「ExpressRoute の技術概要」を参照してください。
関連するコンテンツ
Azure Cache for Redis の機能について