중요합니다
Azure Cache for Redis Enterprise에 대한 마이그레이션 에이전트 기술을 사용하여 마이그레이션 관련 질문에 답변하고 사용자 환경에 맞는 마이그레이션 계획을 준비할 수 있습니다. 자세한 내용은 Redis Enterprise 마이그레이션 에이전트 기술을 참조하세요.
이 문서에서는 두 마이그레이션 경로에 대한 단계별 지침을 제공합니다.
업무 시간 외에 마이그레이션을 수행하는 것이 좋습니다. 이는 정기적인 유지 관리 작업 중 동작과 유사한 짧은 연결 문제를 일으킬 수 있기 때문입니다.
지역에서 복제가 없는 캐시에 대한 셀프 서비스 마이그레이션
1단계: 배포 스크립트 업데이트
적절한 Azure Managed Redis SKU를 확인한 후 배포 스크립트(예: ARM 템플릿, Bicep 파일 또는 Terraform 구성)를 업데이트하여 Azure Cache for Redis Enterprise 대신 Azure Managed Redis를 프로비전합니다.
2단계: 새 Azure Managed Redis 인스턴스 만들기
앞에서 식별한 크기 및 성능 계층 을 사용하여 빠른 시작: Azure Managed Redis 인스턴스 만들기에 따라 인스턴스를 만듭니다.
Redis Enterprise 인스턴스에서 권장되는 Azure Managed Redis 인스턴스를 확인하는 대안 방법으로 list-skus-for-scaling 명령을 사용할 수 있습니다.
az redisenterprise list-skus-for-scaling --resource-group rg --cluster-name clustername.region.redisenterprise.cache.azure.net
3단계: 데이터 마이그레이션
가동 중지 시간 및 데이터 손실에 대한 허용 오차에 따라 데이터 마이그레이션 전략을 선택합니다. 애플리케이션이 데이터 손실을 허용할 수 있거나 데이터 원본에서 캐시를 리하이딩하는 메커니즘이 있는 경우 이 단계를 건너뛰고 4단계: 애플리케이션 업데이트로 직접 진행할 수 있습니다.
중요합니다
Azure Managed Redis는 시스템 작업 및 오버헤드를 위해 약 20% 메모리를 예약합니다. 새 인스턴스에 적합한 메모리 크기를 선택할 때 이 예약을 고려합니다. 예를 들어 워크로드에 10GB의 사용 가능한 메모리가 필요한 경우 총 메모리가 12.5GB 이상인 SKU를 선택합니다.
RDB 파일을 사용하여 데이터 내보내기 및 가져오기
데이터의 지정 시간 스냅샷을 만드는 데 가장 적합합니다.
- 장점: 데이터 스냅샷을 보존하고 간단한 프로세스.
- 단점: 스냅샷이 생성된 후에 작성된 데이터는 캡처되지 않습니다.
Steps:
- 기존 Enterprise 캐시에서 Azure Storage 계정으로 RDB 파일을 내보냅니다.
- Azure Storage 계정에서 새 Azure Managed Redis 인스턴스로 데이터를 가져옵니다.
- 자세한 지침은 Azure Managed Redis에서 데이터 가져오기 및 내보내기를 참조하세요.
이중 쓰기 전략
데이터 손실이 필요하지 않으며 두 개의 캐시 실행을 일시적으로 허용할 수 있는 경우에 가장 적합합니다.
- 프로: 데이터 손실 없음, 가동 중지 시간 없음, 중단 없는 작업
- 단점: 오랜 시간 동안 두 개의 캐시를 실행해야 합니다.
Steps:
- 기존 엔터프라이즈 캐시와 새 Azure Managed Redis 인스턴스 모두에 쓰도록 애플리케이션을 수정합니다.
- 데이터가 새 인스턴스에 채워질 때 Enterprise 캐시에서 계속 읽습니다.
- 충분한 데이터 동기화 후 읽기를 Azure Managed Redis로 전환합니다.
- 4단계: 애플리케이션 업데이트로 진행합니다.
RIOT를 사용한 프로그래밍 방식 마이그레이션
RIOT는 엔터프라이즈에서 Azure Managed Redis로 콘텐츠를 마이그레이션하는 방법을 제공합니다. 자세한 내용은 Azure Managed Redis에 대한 RIOT-X 사용하여 데이터 마이그레이션을 참조하세요.
- 프로: 모든 권한, 사용자 지정할 수 있습니다.
- 단점: 개발 노력이 필요합니다.
4단계: 애플리케이션 업데이트
새 Azure Managed Redis 인스턴스를 가리키도록 애플리케이션의 연결 구성을 업데이트합니다. 최소한 다음을 업데이트해야 합니다.
-
호스트 이름: DNS 접미사가 .로
redisenterprise.cache.azure.netredis.azure.net변경되었습니다. - 액세스 키: 새 Azure Managed Redis 인스턴스의 액세스 키를 사용합니다.
중요합니다
액세스 키 대신 Microsoft Entra ID 인증으로 전환하는 것이 좋습니다. Microsoft Entra ID는 향상된 보안을 제공하며 권장 인증 방법입니다.
메모
프라이빗 엔드포인트를 통해 기존 Enterprise 인스턴스에 연결하는 경우 유사한 네트워킹 설정으로 새 Azure Managed Redis 인스턴스가 애플리케이션과 동일한 가상 네트워크에 피어링되는지 확인합니다.
5단계: 유효성 검사 및 서비스 해제
- 애플리케이션이 새 Azure Managed Redis 인스턴스에서 올바르게 작동하는지 확인합니다.
- 새 캐시에서 예상 동작, 성능 및 오류 비율을 모니터링합니다.
- 새 인스턴스가 예상대로 작동하는지 확신하면 이전 Enterprise 인스턴스를 삭제합니다.
지리적 복제가 있는 캐시에 대한 셀프 서비스 마이그레이션
Azure Managed Redis로 마이그레이션하려는 지역 복제 Redis Enterprise 캐시 집합이 있는 경우 다음 단계를 사용합니다.
- Azure CLI에서
list-skus-for-scaling명령을 사용하여az redisenterprise list-skus-for-scaling --resource-group --cluster-name를 통해 적절한 Azure Managed Redis SKU를 식별합니다. - 지역 복제 그룹의 모든 Redis Enterprise 캐시가 동일한 SKU 및 크기인지 확인합니다.
- 새 Azure Managed Redis 인스턴스를 만들고, 생성 중에 마이그레이션하려는 Redis Enterprise 인스턴스가 포함된 지리적 복제 그룹에 추가합니다.
- 프라이빗 엔드포인트를 사용하는 경우 동일한 가상 네트워크에 대한
*.redis.azure.net새 프라이빗 DNS 영역을 프로비전하고 이 새 Azure Managed Redis 인스턴스에 대한 새 프라이빗 엔드포인트를 만듭니다. - 새 Azure Managed Redis 인스턴스에 액세스할 수 있는지 확인하고 새 Azure Managed Redis 엔드포인트를 포함하도록 애플리케이션을 업데이트합니다.
- Azure Managed Redis 인스턴스가 모든 데이터 세트를 복제한 후에는 지역 복제 그룹에서 Redis Enterprise 인스턴스를 하나 제거합니다.
- 지역 복제 그룹의 나머지 모든 Redis Enterprise 캐시에 대해 이전 단계를 반복합니다.
제한 사항/주의 사항
- Azure Managed Redis 인스턴스가 Redis Enterprise 인스턴스의 기존 지역 복제 그룹에 추가되면 해당 지역 복제 그룹에 새 Redis Enterprise 인스턴스를 추가할 수 없습니다. Azure Managed Redis만 추가하고 Redis Enterprise 인스턴스만 제거할 수 있습니다.
- 지역 복제에 Azure Managed Redis 및 Redis Enterprise 인스턴스가 혼합되어 있으면 크기 조정이 차단됩니다.
- 지역 복제 그룹은 5개의 Redis 인스턴스로 제한되지만 마이그레이션을 용이하게 하기 위해 Azure Managed Redis 및 Redis Enterprise가 혼합된 지역 복제 그룹에 대해 최대 6개의 Redis 인스턴스를 허용합니다.
중요합니다
처음에 기존 액세스 키를 계속 사용하는 경우에도 마이그레이션 후 Microsoft Entra ID 인증으로 이동하는 것이 좋습니다.