이 문서에서는 Azure Cache for Redis(기본, 표준, 프리미엄 및 엔터프라이즈 계층 포함)에서 Azure Managed Redis로 마이그레이션하는 이유와 방법을 설명합니다.
다음 항목에 대해 알아봅니다.
- 이전 계층에 비해 Azure Managed Redis를 선택할 경우의 이점입니다.
- 서비스 간의 주요 기능 차이점입니다.
- 캐시 데이터를 마이그레이션하기 위한 전략입니다.
- 원활한 마이그레이션 프로세스를 보장하는 방법입니다.
- 요구 사항에 적합한 Azure Managed Redis SKU 및 성능 계층을 선택하는 방법에 대한 지침입니다.
- 클라이언트 애플리케이션을 업데이트하기 위한 고려 사항 및 권장 사항
기본, 표준, 프리미엄 또는Enterprise 또는 OSS 계층을 사용하는지 여부에 관계없이 이 가이드는 Azure Managed Redis로의 마이그레이션을 계획하고 실행하는 데 도움이 됩니다.
문서는 두 섹션으로 나눕니다. 하나는 엔터프라이즈 인스턴스에 관한 것입니다. 다른 하나는 Azure Cache for Redis의 기본, 표준 및 프리미엄 계층에 관한 것입니다.
엔터프라이즈에서 Azure Managed Redis로 이동의 이점
Azure Managed Redis는 고급 Redis Enterprise 소프트웨어를 기반으로 합니다. Azure Managed Redis는 Azure 자사 제품으로, 관련된 Azure Marketplace 구성 요소가 없으며 사용자가 Marketplace와 별도로 거래할 필요가 없습니다. 다른 네이티브 Azure 서비스 또는 제품과 마찬가지로 Azure Managed Redis를 프로비전, 관리 및 지불합니다.
Azure Managed Redis는 사용되지 않는 리소스로 이어지는 쿼럼 노드 가 필요하지 않으며 Azure Cache for Redis Enterprise가 제공될 수 있는 지역 또는 클라우드를 제한합니다. Azure Managed Redis는 이제 대부분의 Azure 지역에서 사용할 수 있으며 다른 소버린 클라우드에서 지원될 계획입니다. 쿼럼 노드에 대한 자세한 내용은 Enterprise 및 Enterprise Flash 계층을 참조하세요. 사용되지 않는 쿼럼 노드를 제거하면 모든 노드를 데이터 노드로 사용할 수 있으므로 비용 효율성이 향상됩니다.
Azure 관리형 Redis는 기본적으로 영역 중복성을 지원합니다.
개발 및 테스트 환경에 HA(고가용성) 없이 Azure Managed Redis를 사용할 수 있습니다. HA 없이 비프로덕션 환경을 사용하면 인스턴스 비용이 절반으로 증가합니다.
Azure Managed Redis에 대한 SKU 구조는 메모리 및 성능 요구 사항을 기반으로 합니다. Azure Cache for Redis Enterprise와 마찬가지로 배율 인수 또는 용량을 관리하는 대신 Azure Managed Redis의 세 가지 성능 계층 중에서 선택할 수 있습니다. 자세한 내용은 올바른 계층 선택을 참조하세요.
마지막으로, Azure Managed Redis는 워크로드의 보안 상태를 개선하기 위해 캐시를 만들 때 Microsoft Entra ID 인증을 제공합니다.
기능 비교
| 특징 | 애저 캐시 포 레디스 엔터프라이즈 | Azure Managed Redis |
|---|---|---|
| Redis 버전 | 7.2 | 7.4 |
| 클러스터링 정책 | 오픈 소스 소프트웨어 (OSS), 엔터프라이즈 (Enterprise) | OSS, 엔터프라이즈, 비클러스터형 |
| Geo-replication | Active | Active |
| 서비스 수준 계약 (SLA) | 최대 99.999% | 최대 99.999% |
| 영역 중복성 | Yes | 예(기본값) |
| 비HA 모드 | No | 예(개발/테스트용) |
| 데이터 지속성 | 예(미리 보기) | Yes |
| 확장 | Yes | Yes |
| TLS 버전 지원 | 1.2,1.3 | 1.2,1.3 |
| Microsoft Entra ID 인증 | No | Yes |
| Azure 지역 지원 | 한정 | 포괄적인 |
| Azure 주권 클라우드 지원 | No | 예(출시 예정) |
| 호스트 이름 DNS 접미사 | <name>.<region>.redisenterprise.cache.azure.net |
<name>.<region>.redis.azure.net |
Enterprise에서 Azure Managed Redis로 이동할 때 고려 사항
Azure Managed Redis는 Azure Cache for Redis Enterprise와 동일한 소프트웨어 스택을 사용하므로 엔터프라이즈 계층을 사용하는 기존 애플리케이션에는 많은 변경이 필요하지 않습니다. 중요한 예외는 연결 자격 증명을 변경해야 한다는 것입니다.
다른 호스트 이름 및 접미사
Azure Cache for Redis Enterprise 및 Azure Managed Redis의 핵심 소프트웨어는 비슷하지만 Redis 클러스터 호스트 이름에 대한 DNS 접미사는 다릅니다. Azure Managed Redis로 이동하면 애플리케이션에서 Redis 클러스터 호스트 이름을 변경해야 합니다. 캐시에 연결하기 위해 액세스 키를 사용하는 경우 캐시에 연결하는 데 사용하는 액세스 키도 업데이트해야 합니다.
중요합니다
캐시에 연결하는 코드를 업데이트하는 것이 좋습니다. 액세스 키를 사용하는 대신 Microsoft Entra ID를 사용합니다. 액세스 키 대신 Microsoft Entra ID를 사용하는 것이 좋습니다.
올바른 Azure Managed Redis 크기 및 SKU 선택
Azure Managed Redis는 많은 메모리 크기와 세 가지 성능 계층을 제공합니다. 메모리 크기 및 성능 계층에 대한 자세한 내용은 여기에서 올바른 계층을 선택할 수 있습니다.
기존 Azure Cache for Redis Enterprise 인스턴스의 메모리 크기 식별
Azure Cache for Redis Enterprise 인스턴스를 확장하여 더 많은 메모리와 더 많은 컴퓨팅 리소스를 제공할 수 있으므로 캐시에 대한 스케일 아웃 요인에 유의해야 합니다. 규모 확장은 기본적으로 클러스터에서 실행되는 가상 머신의 수인 용량과도 관련이 있습니다.
올바른 Azure Managed Redis 메모리 크기를 선택하려면 다음을 수행합니다.
- Azure Portal로 이동하여 리소스 메뉴에서 개요 를 선택합니다.
- Enterprise 인스턴스 개요에서 상태 필드를 확인합니다. 상태 필드에는 Redis Enterprise 인스턴스의 메모리 크기가 표시됩니다.
가능한 시나리오를 살펴보겠습니다.
개요 창의 상태를 보면 실행 중 - Enterprise 8GB(2 x 4GB)가 표시됩니다. 이 표기법은 캐시가 현재 크기가 2인 E5 Enterprise SKU를 사용하여 8GB 캐시를 생성한다는 것을 의미합니다. 따라서 Azure Managed Redis에서 10GB 이상의 캐시로 시작해야 합니다.
이 경우 12GB의 메모리를 제공하는 계층을 사용합니다.
| SKU | 계층 |
|---|---|
| M10 | Memory Optimized |
| B10 | Balanced |
| X10 | Compute Optimized |
성능 계층 식별
또한 워크로드가 메모리 집약적이거나 컴퓨팅 집약적인지 고려해야 합니다. 현재 Enterprise 인스턴스가 CPU 전에 메모리가 부족할 가능성이 더 높은 경우 워크로드는 메모리를 많이 사용합니다. 메모리 최적화 성능 계층에서 선택하는 것이 좋습니다.
워크로드 처리량이 많거나 대기 시간이 너무 많은 경우 워크로드가 계산 집약적입니다. 컴퓨팅 최적화 성능 계층에서 선택하는 것이 좋습니다.
확실하지 않은 경우 메모리와 성능이 정상 혼합되어 있으므로 균형 잡힌 성능 계층으로 시작할 수 있습니다.
현재 Redis Enterprise Flash 계층을 사용하는 경우 플래시 최적화 계층을 선택해야 합니다.
새 Azure Managed Redis 인스턴스 만들기
새 Azure Managed Redis 인스턴스에 대한 메모리 및 성능 계층을 선택한 후 새 Azure Managed Redis 인스턴스를 만들 수 있습니다. 캐시를 만드는 방법에 대한 자세한 내용은 빠른 시작: Azure Managed Redis 인스턴스 만들기를 참조하세요.
다음으로, 데이터를 이동하기 위한 전략을 선택해야 합니다. 마지막으로 새 캐시를 사용하도록 애플리케이션을 업데이트해야 합니다.
Azure Managed Redis 인스턴스에 연결하도록 앱 업데이트
새 Azure Managed Redis 인스턴스를 만든 후에는 새 Azure Managed Redis 인스턴스를 가리키도록 애플리케이션의 Redis 엔드포인트/호스트 이름 및 액세스 키를 변경해야 합니다. 업무 시간이 아닐 때 이 엔드포인트 변경을 게시하는 것을 권장합니다. 이는 연결이 잠시 끊길 수 있기 때문입니다.
Note
프라이빗 엔드포인트를 통해 기존 Redis Enterprise 인스턴스에 연결하는 경우 새 Azure Managed Redis 캐시도 애플리케이션의 가상 네트워크에 피어링되었는지 확인합니다. 새 캐시에는 기존 Redis Enterprise 인스턴스와 유사한 설정이 있어야 합니다.
애플리케이션이 예상대로 실행되고 있는지 확인한 다음 이전 Redis Enterprise 인스턴스를 삭제합니다.
엔터프라이즈 캐시에서 새 Azure Managed Redis 캐시로 데이터 이동
Azure Managed Redis 인스턴스로 마이그레이션할 때 기존 Redis Enterprise 인스턴스에서 새 Azure Managed Redis 인스턴스로 데이터를 이동하는 가장 좋은 방법을 고려해야 합니다. 애플리케이션에서 데이터 손실을 허용할 수 있거나 부정적인 영향 없이 캐시를 리하일 수 있는 다른 메커니즘이 있는 경우 이 단계를 건너뛰고 다음 단계를 진행합니다.
애플리케이션이 데이터를 새 Azure Managed Redis 인스턴스로 마이그레이션해야 하는 경우 다음 옵션 중 하나를 선택합니다.
RDB 파일을 사용하여 데이터 내보내기 및 가져오기
- 장점: 데이터 스냅샷을 유지합니다.
- 단점: 스냅샷 후에 쓰기가 발생하는 경우 데이터 손실의 위험입니다.
기본 내보내기/가져오기 절차는 다음과 같습니다.
- 기존 Redis Enterprise 캐시에서 Azure Storage 계정으로 RDB를 내보냅니다.
- Azure Storage 계정에서 새 Azure Managed Redis 캐시로 데이터를 가져옵니다.
- Azure Managed Redis에서 데이터 가져오기 및 내보내기에서 데이터 내보내기/가져오기에 대해 자세히 알아보세요.
Dual-Write 전략
- 장점: 가동 중지 시간이 0개, 안전한 전환입니다.
- 단점: 임시 이중 캐시 설정이 필요합니다.
기본 이중 쓰기 절차는 다음과 같습니다.
- 기존 Azure Cache for Redis Enterprise 캐시와 새 Azure Managed Redis 캐시에 쓰도록 애플리케이션을 수정합니다.
- Redis Enterprise 캐시에서 읽기 및 쓰기를 계속합니다.
- 충분한 데이터 동기화 후 읽기를 Azure Managed Redis로 전환하고 Redis Enterprise 인스턴스를 삭제합니다.
RIOT-X 사용하여 프로그래밍 방식 마이그레이션
RIOT-X 엔터프라이즈에서 Azure Managed Redis로 콘텐츠를 마이그레이션하는 방법을 제공합니다. 자세한 내용은 Azure Managed Redis에 대한 RIOT-X 사용하여 데이터 마이그레이션을 참조하세요.
- 장점: 모든 권한, 사용자 지정할 수 있습니다.
- 단점: 개발 노력이 필요합니다.
기본, 표준 또는 프리미엄 캐시에서 Azure Managed Redis로 이동할 경우의 이점
OSS SKU, Basic, Standard 또는 Premium 중 하나를 사용하는 경우 Azure Managed Redis로 이동하면 모든 수준 캐시에서 더 많은 기능을 제공합니다.
다음은 Azure Cache for Redis의 기능과 Azure Managed Redis의 기능을 비교하는 표입니다.
| 기능 설명 | Basic OSS |
Standard OSS |
Premium OSS |
Balanced AMR |
Memory Optimized AMR |
Compute Optimized AMR |
|---|---|---|---|---|---|---|
| Availability | N/A | 99.9% | 99.9% | 최대 99.999% | 최대 99.999% | 최대 99.999% |
| 전송 중 암호화 | Yes | Yes | Yes | Yes | Yes | Yes |
| 네트워크 격리 | Yes | Yes | Yes | Yes | Yes | Yes |
| 확장 | Yes | Yes | Yes | Yes | Yes | Yes |
| 축소 | Yes | Yes | Yes | No | No | No |
| OSS 클러스터링 | No | No | Yes | Yes | Yes | Yes |
| 데이터 지속성 | No | No | Yes | Yes | Yes | Yes |
| 영역 중복성 | No | 예(미리 보기) | Yes | Yes | Yes | Yes |
| Geo-replication | No | No | 예(수동) | 예(활성) | 예(활성) | 예(활성) |
| 연결 감사 로그 | No | No | Yes | Yes(Event-based) | Yes(Event-based) | Yes(Event-based) |
| Redis 모듈 | No | No | No | Yes | Yes | Yes |
| Import/Export | No | No | Yes | Yes | Yes | Yes |
| Reboot | Yes | Yes | Yes | No | No | No |
| 예약된 업데이트 | Yes | Yes | Yes | No | No | No |
| Microsoft Entra ID 인증 | Yes | Yes | Yes | Yes | Yes | Yes |
| Microsoft Entra ID RBAC | Yes | Yes | Yes | No | No | No |
| 키스페이스 알림 | Yes | Yes | Yes | No | No | No |
| 고가용성이 아님 | N/A | No | No | Yes | Yes | Yes |
OSS 는 Azure Cache for Redis를 참조합니다.
AMR 은 Azure Managed Redis를 참조합니다.
다음은 Azure Managed Redis를 구현할 때 고려해야 할 몇 가지 다른 차이점입니다. 다음과 같은 클라이언트 애플리케이션 변경 내용을 고려하세요.
| 기능 설명 | Azure Cache for Redis (아주어 캐시 포 레디스) | Azure Managed Redis |
|---|---|---|
| DNS 접미사(PROD 클라우드에만 해당) | .redis.cache.windows.net |
<region>.redis.azure.net |
| TLS 포트 | 6380 | 10000 |
| TLS 포트가 아닌 포트 | 6379 | 지원되지 않음 |
| 개별 노드 TLS 포트 | 13XXX | 85xx |
| 개별 노드 비 TLS 포트 | 15XXX | 지원되지 않음 |
| 클러스터링 지원 | OSS 클러스터링 모드 | OSS 및 엔터프라이즈 클러스터 모드 |
| 지원되지 않는 명령 | 지원되지 않는 명령 | 다중 키 명령 |
| 지역별 가용성 | 모든 Azure 지역 | * 이 섹션 다음에 나오는 지역 목록을 참조하세요. |
| Redis 버전 | 6 | 7.4 |
| 지원되는 TLS 버전 | 1.2 및 1.3 | 1.2 및 1.3 |
기본, 표준 또는 프리미엄 캐시를 Azure Managed Redis로 마이그레이션
표를 기반으로 할 경우 Azure Cache for Redis SKU와 Azure Managed Redis의 캐시 옵션 간에는 다음과 같은 대응 관계가 있습니다.
Note
기본 SKU 마이그레이션을 위해 Azure Managed Redis의 고가용성 옵션이 아닌 옵션 사용
| Azure Cache for Redis (아주어 캐시 포 레디스) | Azure Managed Redis | 추가 메모리(%) |
|---|---|---|
| 기본/표준 - C0 | 균형형 - B0 | 50 |
| 기본/표준 - C1 | 균형형 - B1 | 0 |
| 기본/표준d - C2 | 균형형 - B3 | 17 |
| 기본/표준 - C3 | 균형형 - B5 | 0 |
| 기본/표준 - C4 | 메모리 최적화 – M10* | -8 |
| 기본/표준 – C4 | 메모리 최적화 – M20** | 46 |
| 기본/표준 - C5 | 메모리 최적화 – M20* | -8 |
| 기본/표준 – C5 | 메모리 최적화 – M50** | 57 |
| 기본/표준 - C6 | 메모리 최적화 - M50 | 12 |
| 프리미엄 - P1 | 균형형 - B5 | 0 |
| 프리미엄 - P2 | 균형형 - B10* | -8 |
| 프리미엄 - P2 | 균형형 - B20** | 46 |
| 프리미엄 - P3 | 균형형 - B20* | -8 |
| 프리미엄 - P3 | 균형형 - B50** | 57 |
| 프리미엄 - P4 | 균형형 - B50 | 12 |
| 프리미엄 - P5 | 균형형 - B100 | 0 |
- * 이 옵션은 비용 효율성을 위한 것입니다. 이 옵션을 선택하려면 지난 달에 사용된 총 메모리의 최댓값이 제안된 Azure Managed Redis 메모리보다 적은지 확인하세요.
- ** 이 옵션은 메모리 사용량이 많은 경우에 적합합니다.
Azure Cache for Redis 프리미엄 클러스터형
- 분할된 클러스터의 경우, 동등한 총 메모리가 있는 메모리 최적화 계층을 선택합니다.
- 읽기 복제본이 두 개 이상 있는 클러스터의 경우 기본 복제본과 동일한 총 메모리를 갖춘 컴퓨팅 최적화 계층을 선택합니다.
마이그레이션 옵션
클라이언트 애플리케이션은 다양한 클러스터링 모드와 엔드포인트를 갖춘 Azure Managed Redis 인스턴스를 사용할 수 있어야 합니다. Azure Cache for Redis 및 Azure Managed Redis는 호환되므로 대부분의 시나리오에서는 연결 구성 이외의 애플리케이션 코드 변경이 필요하지 않습니다.
자세히 알아보세요.
Azure Cache for Redis를 Azure Managed Redis로 마이그레이션하기 위한 옵션
| Option | Advantages | Disadvantages |
|---|---|---|
| 새 캐시 만들기 | 가장 간단하게 구현할 수 있습니다. | 데이터를 새 캐시로 다시 채워야 하므로, 많은 애플리케이션에서 이 방법이 작동하지 않을 수 있습니다. |
| RDB 파일을 통해 데이터 내보내기 및 가져오기 | 일반적으로 Redis 캐시와 호환됩니다. | RDB 파일이 생성된 후 데이터가 기존 캐시에 기록되는 경우 일부 데이터가 손실될 수 있습니다. |
| 2개의 캐시에 데이터 이중 쓰기 | 데이터 손실 또는 가동 중지 시간 없음 기존 캐시의 작업 중단이 없습니다. 새 캐시를 간편하게 테스트할 수 있습니다. | 긴 시간 동안 2개의 캐시가 필요합니다. |
| 프로그래밍 방식으로 데이터 마이그레이션 | 데이터 이동 방법을 완벽하게 제어할 수 있습니다. | 사용자 지정 코드가 필요합니다. |
새 Azure Cache for Redis 만들기
이 방법은 엄밀히 따지면 마이그레이션이 아닙니다. 데이터 손실이 문제가 되지 않는다면 Azure Managed Redis 계층으로 이동하는 가장 쉬운 방법은 새로운 캐시 인스턴스를 만들고 이에 애플리케이션을 연결하는 것입니다. 예를 들어 Redis를 데이터베이스 레코드의 조회 캐시로 사용하는 경우 간단하게 캐시를 처음부터 다시 작성할 수 있습니다. 이 옵션을 구현하는 일반적인 단계는 다음과 같습니다.
- 새로운 Azure Managed Redis 인스턴스를 만듭니다.
- 새 인스턴스를 사용하도록 애플리케이션을 업데이트합니다.
- 이전 Azure Cache for Redis 인스턴스를 삭제합니다.
RDB 파일로 데이터 내보내기 및 Azure Managed Redis로 가져오기
이 옵션은 프리미엄 계층 캐시에만 적용됩니다. 오픈 소스 Redis는 캐시의 메모리 내 데이터 세트 스냅샷을 만들어서 파일에 저장하는 표준 메커니즘을 정의합니다. 다른 Redis 캐시는 내보낸 RDB 파일을 읽을 수 있습니다. Azure Cache for Redis 프리미엄 계층은 RDB 파일을 통해 캐시 인스턴스에서 데이터를 내보내는 기능을 지원합니다. RDB 파일을 사용하여 기존 Azure Cache for Redis 인스턴스에서 Azure Managed Redis 인스턴스로 데이터를 전송할 수 있습니다.
이 옵션을 구현하는 일반적인 단계는 다음과 같습니다.
- 기존 Azure Cache for Redis 인스턴스와 크기가 같거나 더 큰 새로운 Azure Managed Redis 인스턴스를 만듭니다.
- 이러한 내보내기 지침 또는 PowerShell 내보내기 cmdlet을 사용하여 기존 Azure Cache for Redis 인스턴스에서 RDB 파일 내보내기
- 이러한 가져오기 지침 또는 PowerShell Import cmdlet을 사용하여 RDB 파일을 새 Azure Managed Redis 인스턴스로 가져오기
- 새로운 Azure Managed Redis 인스턴스 연결 문자열을 사용하도록 애플리케이션을 업데이트하세요.
마이그레이션 기간 동안 동시에 2개의 Redis 캐시에 쓰기
캐시 간에 직접 데이터를 이동하는 대신, 애플리케이션을 사용하여 기존 캐시 및 설정 중인 새 캐시에 데이터를 쓸 수 있습니다. 애플리케이션은 여전히 처음에 기존 캐시에서 데이터를 읽습니다. 새 캐시에 필요한 데이터가 생기면 애플리케이션을 해당 캐시로 전환하고 이전 캐시를 사용 중지합니다. 예를 들어 Redis를 세션 저장소로 사용하며, 애플리케이션 세션은 7일 동안 유효하다고 가정해 보겠습니다. 일주일 동안 2개의 캐시에 쓰면 새 캐시에 만료되지 않은 모든 세션 정보가 포함됩니다. 해당 시점부터 데이터 손실에 대한 걱정 없이 안전하게 새 캐시를 사용할 수 있습니다.
이 옵션을 구현하는 일반적인 단계는 다음과 같습니다.
- 기존 Azure Cache for Redis 인스턴스와 크기가 같거나 더 큰 새로운 Azure Managed Redis 인스턴스를 만듭니다.
- 새 인스턴스와 원래 인스턴스 모두에 쓰도록 애플리케이션 코드를 수정합니다.
- 새 인스턴스에 데이터가 충분히 채워질 때까지 계속해서 원래 인스턴스에서 데이터를 읽습니다.
- 새 인스턴스에서만 데이터를 읽고 쓰도록 애플리케이션 코드를 업데이트합니다.
- 원래 인스턴스를 삭제합니다.
프로그래밍 방식으로 마이그레이션
기존 Azure Cache for Redis 인스턴스에서 프로그래밍 방식으로 데이터를 읽고 Azure Managed Redis 인스턴스에 기록하여 사용자 지정 마이그레이션 프로세스를 만듭니다. 시도해 볼 수 있는 오픈 소스 도구는 다음 두 가지가 있습니다.
-
Redis-copy
- 이 오픈 소스 도구를 사용하여 한 Azure Cache for Redis 인스턴스에서 다른 인스턴스로 데이터를 복사할 수 있습니다. 이 도구는 서로 다른 Azure 캐시 지역에 있는 캐시 인스턴스 간에 데이터를 이동하는 데 유용합니다. 컴파일된 버전도 사용할 수 있습니다. 또한 고객 고유의 마이그레이션 도구를 작성하는 데 도움이 되는 소스 코드도 찾을 수 있습니다.
-
RIOT
- RIOT는 Redis 커뮤니티에서 테스트한 또 다른 인기 있는 마이그레이션 도구입니다. Redis에서 데이터를 가져오고 내보내는 데 도움을 주기 위해 설계된 명령줄 유틸리티입니다.
Note
이 도구는 Microsoft에서 공식적으로 지원하는 도구가 아닙니다.
이 옵션을 구현하는 일반적인 단계는 다음과 같습니다.
- 기존 캐시가 있는 지역에 VM을 만듭니다. 데이터 세트가 크면 비교적 강력한 VM을 선택하여 복사 시간을 줄입니다.
- 새로운 Azure Managed Redis 인스턴스를 만듭니다.
- 새 캐시의 데이터를 플러시하여 캐시를 비웁니다. 복사 도구 자체는 대상 캐시의 기존 키를 덮어쓰지 않기 때문에 이 단계가 필수입니다. 중요: 원본 캐시에서 플러시하지 않도록 주의하세요.
- 이전에 언급한 오픈소스 도구와 같은 애플리케이션을 사용하여 소스 캐시에서 대상으로 데이터를 자동으로 복사합니다. 데이터 세트의 크기에 따라 복사 프로세스가 완료될 때까지 다소 시간이 걸릴 수 있습니다.
Azure Managed Redis의 지역별 가용성
Azure Managed Redis는 지속적으로 새로운 지역으로 확장되고 있습니다. 지역별 사용 가능 여부를 확인하려면 지역별 사용 가능한 제품을 참조하세요.