この記事では、クライアント アプリケーションを Azure Cache for Redis に接続する際の一般的な問題のトラブルシューティング方法について説明します。 接続の問題は、断続的な状態、またはキャッシュ構成が正しくない場合に発生する可能性があります。 この記事は、断続的な問題とキャッシュ構成の問題に分かれています。
断続的な接続の問題
キャッシュ構成の接続に関する問題
接続をテストする
Redis コマンド ライン ツール redis-cli を使用して接続をテストできます。 Redis CLI の詳細については、「 Azure Cache for Redis で Redis コマンド ライン ツールを使用する」を参照してください。
redis-cli が接続できない場合は、Azure PowerShell で PSPING を使用して接続をテストできます。
psping -q <cachename>:<port>
送信されたパケットの数が受信したパケットの数と等しい場合、接続は低下しません。
断続的な接続の問題
クライアント アプリケーションでは、接続数の急増やパッチ適用などのイベントによって、断続的な接続の問題が発生する可能性があります。
Kubernetes でホストされるアプリケーション
クライアント アプリケーションが Kubernetes でホストされている場合は、クラスター ノードまたはクライアント アプリケーションを実行しているポッドがメモリ、CPU、またはネットワークの負荷の下にあるかどうかを確認します。 クライアントアプリケーションを実行しているポッドは、同じノードで実行されている他のポッドの影響を受ける可能性があり、Redis接続やIO操作が制限されることがあります。
Istio またはその他のサービス メッシュを使用している場合は、サービス メッシュ プロキシがポート13000-13019または15000-15019を予約していることを確認します。 クライアントは、これらのポートを使用してクラスター化された Azure Redis キャッシュ内のノードと通信し、それらのポートで接続の問題を引き起こす可能性があります。
Linux ベースのクライアント アプリケーション
Linux でオプティミスティック TCP 設定を使用すると、クライアント アプリケーションの接続の問題が発生する可能性があります。 詳細については、 Linux でホストされるクライアント アプリケーションの TCP 設定 と 、15 分間続く接続ストールに関するページを参照してください。
接続されているクライアントの数
[接続済みクライアント] メトリックの最大集計が、キャッシュ サイズで許可されている接続の最大数に近いか、それより大きいかどうかを確認します。 クライアント接続ごとのサイズ設定の詳細については、「Azure Cache for Redis のパフォーマンス」をご覧ください。
サーバー メンテナンス
キャッシュは、メンテナンス期間中にアプリケーションに悪影響を与える、計画的または計画外のサーバー メンテナンスを行う可能性があります。 この問題を確認するには、Azure portal でキャッシュの エラー (種類: フェールオーバー) メトリックを確認します。 フェールオーバーの影響を最小限に抑える方法については、「接続の回復力」を参照してください。
接続の構成に関する問題
アプリケーションが Azure Redis Cache にまったく接続できない場合は、一部のキャッシュ構成が正しく設定されていない可能性があります。 次のセクションでは、キャッシュが正しく構成されていることを確認する方法について提案します。
ファイアウォール規則
Azure Redis Cache 用に構成されたファイアウォールがある場合は、クライアント IP アドレスがファイアウォール規則に追加されていることを確認します。 ファイアウォール規則を確認するには、キャッシュ ページの左側のナビゲーション メニューの [設定] で [ファイアウォール] を選択します。
サード パーティのファイアウォールまたは外部プロキシ
ネットワークでサードパーティ製のファイアウォールまたはプロキシを使用する場合は、Azure Cache for Redis エンドポイントの *.redis.cache.windows.net とポートの 6379 と 6380が許可されていることを確認します。 クラスター化キャッシュまたは geo レプリケーションを使用する場合は、さらに多くのポートを許可する必要がある場合があります。
プライベート エンドポイントの構成
Azure portal で、キャッシュの左側のナビゲーション メニューの [設定] で [プライベート エンドポイント] を選択して、プライベート エンドポイントの構成を確認します。
[ プライベート エンドポイント] ページで、[ パブリック ネットワーク アクセスを有効にする] が正しく設定されていることを確認します。
- プライベート エンドポイントを作成すると、パブリック ネットワーク アクセスは既定で無効になります。
- キャッシュ仮想ネットワークの外部からキャッシュ プライベート エンドポイントに接続するには、パブリック ネットワーク アクセスを有効にする必要があります。
- プライベート エンドポイントを削除する場合は、パブリック ネットワーク アクセスを有効にしてください。
[ プライベート エンドポイント ] でリンクを選択し、プライベート エンドポイントが正しく構成されていることを確認します。 詳細については、「新しい Azure Cache for Redis インスタンスを使用してプライベート エンドポイントを作成する」を参照してください。
アプリケーションがポート
<cachename>.redis.cache.windows.netの6380に接続されていることを確認します。 構成または接続文字列で<cachename>.privatelink.redis.cache.windows.netを使用しないでください。コマンドがキャッシュのプライベート IP アドレスに解決されることを確認するには、プライベート エンドポイントにリンクされている仮想ネットワーク内から
nslookup <hostname>などのコマンドを実行します。
パブリック IP アドレスの変更
キャッシュのパブリック IP アドレスを使用するようにネットワークまたはセキュリティ リソースを構成する場合は、キャッシュのパブリック IP アドレスが変更されたかどうかを確認します。 詳細については、「 パブリック IP アドレスではなくホスト名に依存する」を参照してください。
Virtual Network の構成
仮想ネットワークの構成を次のように確認します。
- 仮想ネットワークがキャッシュに割り当てられていることを確認します。 Azure portal で、キャッシュの左側のナビゲーション メニューの [設定] で [仮想ネットワーク] を選択します。
- クライアント ホスト マシンがキャッシュと同じ仮想ネットワーク内にあることを確認します。
- クライアント アプリケーションがキャッシュとは異なる仮想ネットワーク内にある場合は、同じ Azure リージョン内の両方の仮想ネットワークのピアリングを有効にします。
- 受信規則と送信規則がポート要件を満たしていることを確認します。
詳細については、「 Premium Azure Cache for Redis インスタンスの仮想ネットワーク サポートを構成する」を参照してください。
Premium キャッシュでの VNet インジェクションを使用した geo レプリケーション
同じ仮想ネットワーク内のキャッシュ間の geo レプリケーションがサポートされています。 異なる仮想ネットワーク内のキャッシュ間の geo レプリケーションは、次の注意事項でサポートされています。
仮想ネットワークが同じリージョンにある場合は、 仮想ネットワーク ピアリング または VPN Gateway VNet 間接続を使用して接続できます。
仮想ネットワークが異なるリージョンにある場合、仮想ネットワーク ピアリングを使用した geo レプリケーションはサポートされません。
VNet 1(リージョン 1) のクライアント仮想マシンは、Basic 内部ロード バランサーの制約により、その名前を使用してVNet 2(リージョン 2) のキャッシュにアクセスできません。 代わりに、VPN Gateway の VNet-to-VNet 接続を使用します。 仮想ネットワーク ピアリングの制約の詳細については、「 仮想ネットワーク ピアリングの要件と制約」を参照してください。
仮想ネットワークを効果的に構成し、geo レプリケーションの問題を回避するには、受信ポートと送信ポートの両方を正しく構成する必要があります。 仮想ネットワークの構成ミスに関する最も一般的な問題を回避する方法の詳細については、 geo レプリケーション ピア ポートの要件に関するページを参照してください。
Premium キャッシュで仮想ネットワークインジェクションを使用することは可能ですが、Azure Private Link を使用することをお勧めします。 詳細については、以下を参照してください: