接続のトラブルシューティング

この記事では、クライアント アプリケーションを Azure Cache for Redis に接続する場合のトラブルシューティングのヘルプを示します。 接続の問題は、断続的な接続の問題と継続的な接続の問題の 2 つの種類に分かれています。

• 断続的な接続の問題
  • サーバー メンテナンス
  • 接続されているクライアントの数
  • Kubernetes でホストされるアプリケーション
  • Linux ベースのクライアント アプリケーション
• 継続的な接続の問題
  • redis-cli を使用して接続をテストする
  • PSPING を使用して接続をテストする
  • 仮想ネットワークの構成
  • プライベート エンドポイントの構成
  • ファイアウォール規則
  • パブリック IP アドレスの変更
• Premium キャッシュでの VNet インジェクションを使用した geo レプリケーション

断続的な接続の問題

クライアント アプリケーションには、修正プログラムの適用や接続数の急増などのイベントが原因で断続的な接続の問題が発生する可能性があります。

サーバー メンテナンス

場合によっては、キャッシュに対して予定どおりまたは予定外のサーバー メンテナンスが行われることがあります。 メンテナンス中にアプリケーションが悪影響を受ける可能性があります。 検証するには、ポータルで Errors (Type: Failover) メトリックを検査します。 フェールオーバーの影響を最小限に抑える方法については、「接続の回復力」を参照してください。

接続されているクライアントの数

Connected Clients メトリックの Max 集計が、特定のキャッシュ サイズに対して許可される接続の最大数に近いかあるいは大きいか検査してください。 クライアント接続ごとのサイズ設定の詳細については、「Azure Cache for Redis のパフォーマンス」をご覧ください。

Kubernetes でホストされるアプリケーション

• クライアント アプリケーションが Kubernetes でホストされている場合は、クライアント アプリケーションを実行しているポッドまたはクラスター ノードにメモリ/CPU/ネットワークの負荷がないか検査してください。 クライアント アプリケーションを実行しているポッドは、同じノードで実行されている他のポッドの影響を受け、Redis 接続や IO 操作を抑えます。
• Istioまたはその他のサービス メッシュを使用している場合は、サービス メッシュ プロキシでポート 13000 から 13019 または 15000 から 15019 が予約されているか検査してください。 これらのポートはクラスター化された Azure Cache For Redis ノードと通信するためにクライアントによって使用され、これらのポートで接続の問題が発生する可能性があります。

Linux ベースのクライアント アプリケーション

Linux でオプティミスティック TCP 設定を使用すると、クライアント アプリケーションで接続の問題が発生する可能性があります。 接続停止が 15 分間続くことに関する記事を参照してください。

継続的な接続

アプリケーションが Azure Cache for Redis に接続できない場合、キャッシュ上の一部の構成が正しく設定されていない可能性があります。 次のセクションでは、キャッシュが正しく構成されていることを確認する方法について提案します。

redis-cli を使用して接続をテストする

redis-cli を使用して接続をテストします。 CLI の詳細については、「Azure Cache for Redis での Redis コマンドライン ツールの使用」を参照してください。

PSPING を使用して接続をテストする

redis-cli を使用して接続できない場合は、PowerShell で PSPING を使用して接続をテストできます。

psping -q <cache DNS endpoint>:<Port Number>

送信されたパケットの数が受信したパケット数と等しいか確認できます。 確認すると、接続で切断がないことが保証されます。

Virtual Network の構成

仮想ネットワークの構成を検査するステップを以下に示します。

1. Azure portal の [リソース] メニューの [設定] の下にある [仮想ネットワーク] セクションから、仮想ネットワークがキャッシュに割り当てられているかどうか検査します。
2. クライアント ホスト マシンが、Azure Cache For Redis と同じ仮想ネットワーク内にあることを確認します。
3. クライアント アプリケーションが Azure Cache For Redis とは異なる VNet にある場合、同じ Azure リージョン内の両方の VNet で VNet ピアリングが有効になっている必要があります。
4. インバウンド規則とアウトバウンド規則が要件を満たしていることを検証します。
5. 詳細については、「Premium Azure Cache for Redis インスタンスに対する仮想ネットワーク サポートの構成」を参照してください。

プライベート エンドポイントの構成

プライベート エンドポイントの構成を検査するステップを以下に示します。

1. Public Network Access フラグは、プライベート エンドポイントを作成する場合、既定で無効になっています。 Public Network Access を正しく設定していることを確認します。 キャッシュが Azure portal 内にある場合、この設定の左側にある [リソース] メニューの [プライベート エンドポイント] を確認します。
2. キャッシュの仮想ネットワークの外部からキャッシュ プライベート エンドポイントに接続しようとしている場合は、Public Network Access を有効にする必要があります。
3. プライベート エンドポイントを削除した場合は、公衆ネットワーク アクセスが有効になっていることを確認します。
4. プライベート エンドポイントが正しく構成されているかどうか検証します。 詳細については、「新しい Azure Cache for Redis インスタンスを使用してプライベート エンドポイントを作成する」を参照してください。
5. アプリケーションがポート 6380 で <cachename>.redis.cache.windows.net に接続されているかどうかを確認します。 構成または接続文字列では <cachename>.privatelink.redis.cache.windows.net を使用しないことをお勧めします。
6. プライベート エンドポイントにリンクされている nslookup <hostname> のようなコマンドを VNet 内から実行して、コマンドによって、キャッシュのプライベート IP アドレスに解決されることを確認します。

ファイアウォール規則

Azure Cache For Redis 用にファイアウォールが構成されている場合は、クライアント IP アドレスがファイアウォール規則に追加されていることを確認します。 Azure portal で [設定] の下にある [リソース] メニュー上の [ファイアウォール] を検査できます。

サード パーティのファイアウォールまたは外部プロキシ

ネットワークでサードパーティのファイアウォールまたはプロキシを使用する場合は、Azure Cache for Redis のエンドポイント *.redis.cache.windows.net がポート 6379 および 6380 と共に許可されているか検査してください。 クラスター化キャッシュまたは geo レプリケーションを使用する場合は、より多くのポートを許可する必要が生じる場合があります。

パブリック IP アドレスの変更

ネットワークまたはセキュリティ リソースでキャッシュのパブリック IP アドレスを使用するように構成している場合は、キャッシュのパブリック IP アドレスが変更されていないかどうかを確認してください。 詳しくは、「パブリック IP アドレスではなくホスト名に依存する」をご覧ください。

Premium キャッシュでの VNet インジェクションを使用した geo レプリケーション

Premium キャッシュで VNet インジェクションを使用することは可能ですが、Azure Private Link をお勧めします。

詳細については、以下を参照してください:

• VNet インジェクション キャッシュから Private Link キャッシュに移行する
• Azure Private Link を使用した Azure Cache for Redis とは

VNet 内のキャッシュの geo レプリケーションは注意事項付きでサポートされています。

• 同じ VNet 内のキャッシュ間の geo レプリケーションがサポートされています。
• 異なる VNet 内のキャッシュ間の geo レプリケーションもサポートされています。
  • VNet が同じリージョンに存在する場合は、VNet ピアリングまたは VPN Gateway VNet 間接続を使用してそれらを接続できます。
  • VNet が異なるリージョンにある場合、VNet ピアリングを使用した geo レプリケーションはサポートされません。 Basic 内部ロード バランサーの制約により、VNet 1 (リージョン 1) のクライアント VM は DNS を使用して VNet 2 (リージョン 2) のキャッシュにアクセスすることはできません。 VNet ピアリングの制約の詳細については、Virtual Network - ピアリングの要件と制約に関するページを参照してください。 VPN Gateway による VNet 間接続を使用することをお勧めします。

VNet を効果的に構成し、geo レプリケーションの問題を回避するには、受信ポートと送信ポートの両方を正しく構成する必要があります。 VNet の構成ミスに関する最も一般的な問題を回避する方法の詳細については、「geo レプリケーション ピア ポートの要件」を参照してください。

関連コンテンツ

次の記事では、接続性と回復力の詳細について説明します。

• 接続の回復力に関するベスト プラクティス
• Azure Cache for Redis の高可用性