연결 문제 해결

  • 아티클

이 문서에서는 클라이언트 애플리케이션을 Azure Cache for Redis에 연결하기 위한 문제 해결 도움말을 제공합니다. 연결 문제는 간헐적인 연결 문제와 지속적인 연결 문제의 두 가지 유형으로 나뉩니다.

일시적인 연결 문제

클라이언트 애플리케이션에는 패치와 같은 이벤트 또는 연결 수 급증으로 인한 일시적인 연결 문제가 있을 수 있습니다.

서버 유지 관리

경우에 따라 캐시에 계획된 서버 또는 계획되지 않은 서버 유지 관리가 진행됩니다. 유지 관리 중에 애플리케이션이 부정적인 영향을 받을 수 있습니다. 포털에서 Errors (Type: Failover) 메트릭을 확인하여 유효성을 검사할 수 있습니다. 장애 조치(failover)의 영향을 최소화하려면 연결 복원력을 참조하세요.

연결된 클라이언트 수

Connected Clients 메트릭에 대한 최대 집계가 특정 캐시 크기에 대해 허용되는 최대 연결 수보다 가깝거나 높은지 확인합니다. 클라이언트 연결당 크기 조정에 대한 자세한 내용은 Azure Cache for Redis 성능을 참조하세요.

Kubernetes 호스팅 애플리케이션

  • 클라이언트 애플리케이션이 Kubernetes에서 호스트되는 경우 클라이언트 애플리케이션을 실행하는 Pod 또는 클러스터 노드가 메모리/CPU/네트워크 압력을 받지 않는지 확인합니다. 클라이언트 애플리케이션을 실행하는 Pod는 동일한 노드에서 실행되는 다른 Pod의 영향을 받고 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>

보낸 패킷 수가 수신된 패킷과 같은지 확인할 수 있습니다. 확인하면 연결이 끊어지지 않습니다.

가상 네트워크 구성

가상 네트워크 구성을 확인하는 단계입니다.

  1. Azure Portal의 리소스 메뉴에 있는 설정 아래의 “Virtual Network” 섹션에서 가상 네트워크가 캐시에 할당되었는지 확인합니다.
  2. 클라이언트 호스트 머신이 Azure Cache For Redis와 동일한 가상 네트워크에 있는지 확인합니다.
  3. 클라이언트 애플리케이션이 Azure Cache For Redis와 다른 VNet에 있는 경우 두 VNet 모두 동일한 Azure 지역 내에서 VNet 피어링을 사용하도록 설정해야 합니다.
  4. 인바운드 및 아웃바운드 규칙이 요구 사항을 충족하는지 확인합니다.
  5. 자세한 내용은 가상 네트워크 구성 - 프리미엄 계층 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. 프라이빗 엔드포인트에 연결된 VNet 내에서 nslookup <hostname>과 같은 명령을 실행하여 명령이 캐시의 개인 IP 주소로 확인되는지 확인합니다.

방화벽 규칙

Azure Cache For Redis에 대해 구성된 방화벽이 있는 경우 클라이언트 IP 주소가 방화벽 규칙에 추가되었는지 확인합니다. Azure Portal의 설정 아래의 리소스 메뉴에서 방화벽을 확인할 수 있습니다.

타사 방화벽 또는 외부 프록시

네트워크에서 타사 방화벽 또는 프록시를 사용하는 경우 Azure Cache for Redis에 대한 엔드포인트인 *.redis.cache.windows.net이 6379 및 6380 포트와 함께 허용되는지 확인합니다. 클러스터형 캐시 또는 지역 복제를 사용할 때 더 많은 포트를 허용해야 할 수 있습니다.

공용 IP 주소 변경

캐시의 공용 IP 주소를 사용하도록 네트워킹 또는 보안 리소스를 구성한 경우 캐시의 공용 IP 주소가 변경되었는지 확인합니다. 자세한 내용은 캐시에 대한 공용 IP 주소가 아닌 호스트 이름에 의존을 참조하세요.

프리미엄 캐시에서 VNet 삽입을 사용하여 지역 복제

프리미엄 캐시에서 VNet 주입을 사용할 수 있지만 Azure Private Link를 사용하는 것이 좋습니다.

자세한 내용은 다음을 참조하세요.

VNet의 캐시에 대한 지역에서 복제가 지원됩니다.

  • 동일한 VNet에 있는 캐시 간의 지역 복제가 지원됩니다.
  • 서로 다른 VNet 캐시 간의 지역 복제도 지원됩니다.
    • VNet이 동일한 지역에 있는 경우 VNet 피어링 또는 VPN Gateway VNet 간 연결을 사용하여 연결할 수 있습니다.
    • VNet이 다른 지역에 있는 경우 VNet 피어링을 사용하는 지역 복제가 지원되지 않습니다. 기본 내부 부하 분산 장치의 제약 때문에 VNet 1(지역 1)의 클라이언트 VM은 DNS 이름을 사용하여 VNet 2(지역 2)의 캐시에 액세스할 수 없습니다. VNet 피어링 제약 조건에 대한 자세한 내용은 가상 네트워크 - 피어링 - 요구 사항 및 제약 조건을 참조하세요. VPN Gateway VNet 간 연결을 사용하는 것이 좋습니다.

VNet을 효과적으로 구성하고 지역 복제 문제를 방지하려면 인바운드 포트와 아웃바운드 포트를 모두 올바르게 구성해야 합니다. 가장 일반적인 VNet 구성 오류 문제를 방지하는 방법에 대한 자세한 내용은 지역 복제 피어 포트 요구 사항을 참조하세요.

관련 내용

이러한 문서에서는 연결 및 복원력에 대한 자세한 정보를 제공합니다.