중요
Azure Cache for Redis는 모든 SKU에 대한 사용 중지 타임라인을 발표했습니다. 가능한 한 빨리 기존 Azure Cache for Redis 인스턴스를 Azure Managed Redis 로 이동하는 것이 좋습니다.
사용 중지에 대한 자세한 내용은 다음과 같습니다.
Azure Virtual Network 배포는 서브넷과 함께 보안 및 격리를 향상하고 액세스 제어 정책과 액세스를 추가로 제한하는 기타 기능을 제공합니다. Azure Cache for Redis 인스턴스가 가상 네트워크로 구성된 경우 공개적으로 주소를 지정할 수 없습니다. 대신 가상 네트워크 내의 가상 머신 및 애플리케이션에서만 인스턴스에 액세스할 수 있습니다. 이 문서에서는 프리미엄 계층 Azure Cache for Redis 인스턴스에 대한 가상 네트워크 지원을 구성하는 방법을 설명합니다.
참고
클래식 배포 모델은 2024년 8월에 사용 중지됩니다. 자세한 내용은 Cloud Services(클래식) 배포 모델이 2024년 8월 31일에 사용 중지됨을 참조하세요.
중요
Azure Cache for Redis에서는 네트워크 아키텍처를 간소화하고 Azure의 엔드포인트 간 연결을 보호하는 Azure Private Link를 사용하는 것이 좋습니다. 가상 네트워크 내 서브넷의 개인 IP 주소가 할당된 프라이빗 엔드포인트를 통해 가상 네트워크에서 Azure Cache 인스턴스에 연결할 수 있습니다. Azure Private Links는 모든 계층에서 제공되며 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에 삽입할 수 없습니다. 캐시를 만들 때 이 옵션을 선택해야 합니다.
- Azure Portal은 리소스를 만드는 동안 VNET 삽입 구성을 지원하지 않습니다.
가상 네트워크 지원 설정
Azure Cache for Redis 가상 네트워크 FAQ
Azure Cache for Redis 네트워킹에 대해 자주 묻는 질문과 대답이 나와 있는 목록은 다음과 같습니다.
- Azure Cache for Redis 및 가상 네트워크와 관련된 몇 가지 일반적인 구성 오류 문제는 무엇인가요?
- 캐시가 가상 네트워크에서 작동하는지 확인하려면 어떻게 해야 하나요?
- 가상 네트워크에서 내 Azure Cache for Redis 인스턴스에 연결하려고 하면 원격 인증서가 유효하지 않다는 오류가 표시되는 이유는 무엇인가요?
- 표준 또는 기본 캐시에 가상 네트워크를 사용할 수 있나요?
- 일부 서브넷에서만 Azure Cache for Redis 인스턴스를 만드는 데 실패하는 이유는 무엇인가요?
- 서브넷 주소 공간 요구 사항은 무엇입니까?
- 피어링된 가상 네트워크에서 내 캐시에 연결할 수 있나요?
- Azure Lighthouse가 사용하도록 설정된 캐시에서 VNet 삽입이 지원되나요?
- 캐시가 가상 네트워크에서 호스트될 때 모든 캐시 기능이 작동하나요?
- Azure Lighthouse가 사용하도록 설정된 캐시에서 VNet 삽입이 지원되나요?
Azure Cache for Redis 및 가상 네트워크와 관련된 몇 가지 일반적인 구성 오류 문제는 무엇인가요?
Azure Cache for Redis가 가상 네트워크에 호스트되는 경우 사용되는 포트는 다음 표에 나와 있습니다.
중요
다음 표의 포트가 차단되면 캐시가 제대로 작동하지 않을 수 있습니다. 이러한 포트 중 하나 이상이 차단되면 가상 네트워크에서 Azure Cache for Redis를 사용하는 경우 가장 일반적인 잘못된 구성 문제가 발생합니다.
아웃바운드 포트 요구 사항
Azure Cache for Redis에는 캐시가 작동하는 데 필요한 다른 종속성 서비스에 대한 아웃바운드 연결이나 노드 간 통신을 위한 Redis 서브넷 내부에 대한 네트워크 연결 요구 사항이 있습니다.
| 포트 | 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 및 서브넷 3에 대한 모든 사용자 지정 DNS 서버 |
| 123 | 아웃바운드 | 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 및 지역 복제에 대한 내부 통신 | (Redis 서브넷) | (Redis 서브넷) (지역 복제본 피어 서브넷) |
| 6379-6380 | 아웃바운드 | TCP | Redis에 대한 내부 통신 | (Redis 서브넷) | (Redis 서브넷) |
1 Resource Manager NSG(네트워크 보안 그룹)와 함께 AzureKeyVault 및 AzureMonitor 서비스 태그를 사용할 수 있습니다.
2 Microsoft가 소유한 이러한 IP 주소는 Azure DNS를 제공하는 호스트 VM의 주소를 지정하는 데 사용됩니다.
3 사용자 지정 DNS 서버가 없는 서브넷이나 사용자 지정 DNS를 무시하는 최신 Redis 캐시에는 이 정보가 필요하지 않습니다.
4 자세한 내용은 추가 가상 네트워크 연결 요구 사항을 참조하세요.
지역 복제 피어 포트 요구 사항
Azure 가상 네트워크에서 캐시 간의 지역 복제를 사용하는 경우: a) 인바운드 및 아웃바운드 방향 모두에서 전체 서브넷에 대해 포트 15000-15999를 차단 해제하고 b) 두 캐시에 대해 모두 차단 해제합니다. 이 구성을 사용하면 나중에 지역 장애 조치(failover)가 있더라도 서브넷의 모든 복제본 구성 요소가 서로 직접 통신할 수 있습니다.
인바운드 포트 요구 사항
8개의 인바운드 포트 범위 요구 사항이 있습니다. 이러한 범위의 인바운드 요청은 동일한 가상 네트워크에서 호스트되는 다른 서비스로부터 인바운드됩니다. 또는 Redis 서브넷 통신 내부에 있습니다.
| 포트 | 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 부하 분산 및 지역 복제 | (Redis 서브넷) | (Redis 서브넷), (클라이언트 서브넷), AzureLoadBalancer, (지역 복제본 피어 서브넷) |
| 16001 | 인바운드 | TCP/UDP | Azure 부하 분산 | (Redis 서브넷) | AzureLoadBalancer |
| 20226 | 인바운드 | TCP | Redis에 대한 내부 통신 | (Redis 서브넷) | (Redis 서브넷) |
1 NSG 규칙을 작성하기 위해 클래식 배포 모델에 대한 Resource Manager 또는 AZURE_LOADBALANCER 서비스 태그 AzureLoadBalancer를 사용할 수 있습니다.
추가 가상 네트워크 연결 요구 사항
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 | 스토리지 |
| \*.blob.core.windows.net | HTTPS | 443 | Azure Storage | 스토리지 |
| *.queue.core.windows.net | HTTPS | 443 | Azure Storage | 스토리지 |
| *.file.core.windows.net | HTTPS | 443 | Azure Storage | 스토리지 |
| ocsp.digicert.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| crl4.digicert.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| ocsp.msocsp.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| mscrl.microsoft.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| crl3.digicert.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| cacerts.digicert.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| oneocsp.microsoft.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| crl.microsoft.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| cacerts.geotrust.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| www.microsoft.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| cdp.geotrust.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| status.geotrust.com | HTTP | 80 | Azure 공개 키 인프라 | 해당 없음 |
| 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 지역 내에서 가상 네트워크 피어링이 활성화된 가상 네트워크에 있어야 합니다. 전체 가상 네트워크 피어링은 현재 지원되지 않습니다. 이 요구 사항은 모든 테스트 애플리케이션 또는 진단 핑 도구에 적용됩니다. 클라이언트 애플리케이션이 호스트되는 위치와 관계없이 클라이언트의 네트워크 트래픽이 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 인증서 유효성 검사 오류를 경험할 수 있습니다.
표준 또는 기본 캐시에 가상 네트워크를 사용할 수 있나요?
가상 네트워크는 프리미엄 계층 캐시에서만 사용할 수 있습니다.
일부 서브넷에서만 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 인스턴스는 클러스터 분할당 두 개의 IP 주소와 더 많은 복제본에 대한 IP 주소(있는 경우)를 사용합니다. 부하 분산 장치에는 하나 이상의 IP 주소가 사용됩니다. 클러스터되지 않은 캐시는 분할된 데이터베이스 1개가 있는 것으로 간주됩니다.
피어링된 가상 네트워크에서 내 캐시에 연결할 수 있나요?
가상 네트워크가 동일한 지역에 있는 경우 가상 네트워크 피어링 또는 VPN Gateway VNET 간 연결을 사용하여 연결할 수 있습니다.
피어링된 Azure 가상 네트워크가 서로 다른 지역에 있는 경우: 지역 1의 클라이언트 VM은 기본 부하 분산 장치를 사용하는 제약 조건 때문에 부하 분산된 IP 주소를 통해 지역 2의 캐시에 액세스할 수 없습니다. 즉, 표준 부하 분산 장치를 사용하는 캐시가 아닌 경우(현재는 가용성 영역을 사용하여 만든 캐시만)입니다.
가상 네트워크 피어링 제약 조건에 대한 자세한 내용은 가상 네트워크 - 피어링 - 요구 사항 및 제약 조건을 참조하세요. 한 가지 해결 방법은 가상 네트워크 피어링 대신 VPN Gateway VNET 간 연결을 사용하는 것입니다.
캐시가 가상 네트워크에서 호스트될 때 모든 캐시 기능이 작동하나요?
캐시가 가상 네트워크의 일부인 경우 가상 네트워크의 클라이언트만 캐시에 액세스할 수 있습니다. 결과적으로 이번에는 다음 캐시 관리 기능이 작동하지 않습니다.
- Redis 콘솔: Redis 콘솔은 일반적으로 가상 네트워크에 연결되지 않은 개발자 컴퓨터의 로컬 브라우저에서 실행되기 때문에 캐시에 연결할 수 없습니다.
Azure Lighthouse가 사용하도록 설정된 캐시에서 VNet 삽입이 지원되나요?
아니요, 구독에 Azure Lighthouse가 사용하도록 설정되어 있으면 Azure Cache for Redis 인스턴스에서 VNet 삽입을 사용할 수 없습니다. 대신 프라이빗 링크를 사용합니다.
Azure Cache for Redis에서 ExpressRoute 사용
고객은 Azure ExpressRoute 회로를 가상 네트워크 인프라에 연결할 수 있습니다. 이러한 방식으로 Azure로 온-프레미스 네트워크를 확장합니다.
기본적으로 새로 만든 ExpressRoute 회로는 가상 네트워크에서 강제 터널링(기본 경로의 보급 알림, 0.0.0.0/0)을 사용하지 않습니다. 따라서 아웃바운드 인터넷 연결은 가상 네트워크에서 직접 허용됩니다. 클라이언트 애플리케이션은 Azure Cache for Redis 인스턴스를 포함하는 다른 Azure 엔드포인트에 연결할 수 있습니다.
일반적인 고객 구성은 강제 터널링(기본 경로 보급)을 사용하여 아웃바운드 인터넷 트래픽을 온-프레미스로 강제로 흐르도록 합니다. 이 트래픽 흐름은 아웃바운드 트래픽이 온-프레미스에서 차단되어 Azure Cache for Redis 인스턴스가 해당 종속성과 통신할 수 없는 경우 Azure Cache for Redis와의 연결을 끊습니다.
해결 방법은 하나 이상의 UDR(사용자 정의 경로)을 Azure Cache for Redis 인스턴스가 포함된 서브넷에 정의하는 것입니다. UDR은 기본 경로 대신 적용되는 서브넷별 경로를 정의합니다.
가능한 경우 다음 구성을 사용합니다.
- ExpressRoute 구성은 0.0.0.0/0을 보급하고 기본적으로 모든 아웃바운드 트래픽 온-프레미스를 강제로 터널링합니다.
- Azure Cache for Redis 인스턴스를 포함하는 서브넷에 적용된 UDR은 공용 인터넷에 대한 TCP/IP 트래픽에 대한 작업 경로로 0.0.0.0/0을 정의합니다. 예를 들어, 다음 홉 유형을 인터넷으로 설정합니다.
이러한 단계를 결합하면 서브넷 수준 UDR이 ExpressRoute 강제 터널링보다 우선하고 Azure Cache for Redis 인스턴스에서 아웃바운드 인터넷 액세스를 보장한다는 것입니다.
ExpressRoute를 사용하여 온-프레미스 애플리케이션에서 Azure Cache for Redis 인스턴스에 연결하는 것은 성능상의 이유로 일반적인 사용 시나리오가 아닙니다. 최상의 성능을 위해 Azure Cache for Redis 클라이언트는 Azure Cache for Redis 인스턴스와 동일한 지역에 있어야 합니다.
중요
UDR에 정의된 경로는 ExpressRoute 구성을 통해 보급된 경로보다 우선하도록 구체적이어야 합니다. 다음 예에서는 광범위한 0.0.0.0/0 주소 범위를 사용하고 따라서 잠재적으로 더 구체적인 주소 범위를 사용하는 경로 보급 알림에서 실수로 재정의될 수 있습니다.
Warning
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 기능에 대해 자세히 알아봅니다.