Azure Cache for Redis FAQ

Azure Cache for Redis에 대한 일반적인 질문과 대답, 패턴 및 모범 사례를 알아봅니다.

Redis 라이선스 변경

Redis 라이선싱에 대한 변경 내용은 무엇인가요?

Redis 오픈 소스 프로젝트는 Redis 원본 사용 가능한 라이선스 버전 2(RSALv2) 또는 SSPLv1(서버 쪽 공용 라이선스 버전 1)을 지원하는 이중 라이선스 모델로 변경되었습니다. 자세한 내용은 Redis 보도 자료를 참조하세요. Redis 라이선스 변경에 대한 Microsoft 블로그 게시물도 참조 하세요.

Azure Cache for Redis는 이제 RSALv2 및 SSPLv1 라이선스에서도 적용되고 있나요?

아니요, Azure Cache for Redis는 Microsoft 서비스 약관에 따라 고객에게 제공됩니다. RSALv2 및 SSPLv1 라이선스는 Azure Cache for Redis 사용에 적용되지 않습니다.

Azure Cache for Redis 인스턴스는 패치 및 버그 수정을 계속 받나요?

예, Azure Cache for Redis, Azure Cache for Redis Enterprise 및 Enterprise Flash는 라이선스 발표 후에도 패치 및 버그 수정을 계속 받습니다.

이 라이선스 공지에 대한 응답으로 Azure Cache for Redis 고객으로 무엇을 해야 하나요?

라이선스 공지와 관련하여 Azure 고객에게 필요한 조치는 없습니다.

사용되지 않는 서비스

더 이상 사용되지 않는 Azure Cache for Redis 서비스는 무엇인가요?

  • Managed Cache Service -Managed Cache Service는 2016년 11월 30일에 사용이 중지되었습니다.

  • In-Role Cache - In-Role Cache는 2016년 11월 30일에 사용이 중지되었습니다.

Cloud Services(클래식)에 대한 종속성이 있는 캐시

Cloud Services(클래식)에 의존하는 Azure Cache for Redis 인스턴스는 어떻게 해야 하나요?

Cloud Services(클래식)에 대한 종속성이 있는 모든 캐시를 마이그레이션해야 합니다. 2021년 8월에 Cloud Services(클래식)가 2024년 8월 31일에 사용 중지될 것이라고 발표되었습니다. Cloud Services(클래식)에 종속된 Azure Cache for Redis 인스턴스는 동일한 날짜까지 사용 중지해야 합니다.

2024년 8월 31일 이전에 Cloud Services(클래식)에 종속된 캐시를 마이그레이션해야 합니다.

얼마나 많은 캐시가 영향을 받나요?

최대한 많은 캐시를 투명하게 마이그레이션하기 위해 노력했습니다. 그래서 영향을 받는 캐시와 고객은 거의 없습니다.

캐시가 영향을 받는지 어떻게 알 수 있나요?

Azure Advisor 권장 사항을 확인하세요. 캐시가 영향을 받는 경우 구독에 권장 사항이 표시됩니다.

Advisor가 클라우드 서비스에서 캐시를 마이그레이션하도록 권장하는 스크린샷.

Cloud Services(클래식) 캐시를 Azure Virtual Machine Scale Sets로 마이그레이션하려면 어떻게 해야 하나요?

대부분의 캐시를 Cloud Services(클래식) 기반에서 Azure Virtual Machine Scale Sets 기반으로 마이그레이션했습니다. Azure Virtual Machine Scale Sets로 마이그레이션하면 종속성이 제거됩니다. 가상 네트워크의 캐시에서 이 프로세스를 시작하는 방법은 세 가지가 있습니다.

  • 프라이빗 링크를 사용하여 새 캐시로 마이그레이션

    가상 네트워크 삽입이 아닌 네트워크 격리용으로 Private Link를 사용하는 새 캐시를 만들고 데이터를 이 캐시로 마이그레이션합니다. 이 옵션은 가장 안전한 최상의 네트워크 격리 환경을 제공하는 동시에 업데이트된 인프라를 사용하여 모든 새 캐시가 생성되도록 합니다.

  • 새 Azure Resource Manager VNet 서브넷의 새 캐시로 마이그레이션합니다.

    클래식 VNet 내에서 캐시를 만들면 Azure Virtual Machine Scale Sets 캐시가 아닌 Cloud Services(클래식) 캐시가 만들어집니다. 새 Azure Resource Manager VNet 서브넷의 새 캐시로 마이그레이션하면 유사한 가상 네트워크 환경을 유지하면서 Cloud Services에 대한 기본 종속성이 수정됩니다.

    대부분의 캐시를 Cloud Services(클래식) 기반에서 Azure Virtual Machine Scale Sets 기반으로 마이그레이션했습니다. 마이그레이션하려면 기존 캐시를 삭제하고 새 Azure Resource Manager VNet 서브넷에 새 캐시를 만듭니다. 캐시를 마이그레이션하는 동안에는 이전 서브넷을 사용하지 않는 것이 좋습니다. 캐시의 데이터를 마이그레이션하는 데 권장되는 옵션은 Azure Cache for Redis로 마이그레이션을 참조하세요.

  • 데이터가 손실되는 자동 마이그레이션(권장)

    캐시 구성(액세스 키, 호스트 이름 포함)을 유지한 채 Cloud Services(클래식) 사용에서 Virtual Machine Scale Sets 자동 사용으로 캐시를 마이그레이션할 수 있습니다. 그러나 이 방법을 사용하려면 약 30분간 가동을 중지해야 하며 캐시에서 데이터가 완전히 손실됩니다. 가져오기/내보내기 기능을 사용하여 마이그레이션하기 전 데이터 복사본을 저장할 수 있습니다.

    이 옵션을 활용하려면 azurecachemigration@microsoft.com에 문의하거나 지원 요청을 만들어 마이그레이션을 요청하세요.

내 캐시는 VNet 삽입을 사용하지 않지만 마이그레이션해야 한다는 알림을 받았습니다. 어떻게 해야 합니까?

캐시가 지역 복제를 사용하고 있는지 확인합니다. 그렇다면 현재 지역 복제 쌍에서 새로운 지역 복제 쌍으로 데이터를 마이그레이션해야 합니다.

예시:

  1. 현재 캐시 쌍과 동일한 구성과 일치하는 새 지역 복제 프리미엄 캐시 쌍을 만듭니다.
  2. 지역에서 복제된 캐시의 원래 쌍을 연결 해제하고 기본 캐시에서 RDB 파일을 내보냅니다.
  3. 새 지역 복제 쌍의 기본 캐시로 RDB 파일을 가져옵니다.

지역 복제 캐시의 새 쌍은 Cloud Services에 대해 동일한 종속성을 갖지 않습니다.

"서브넷이 Cloud Services 사용 중지로 인해 영향을 받았습니다."라는 오류 메시지가 표시되면서 새 캐시 인스턴스를 만들 수 없는 경우 어떻게 해야 하나요?

Cloud Services(클래식) 배포 모델을 사용하여 새 캐시 만들기를 차단하기 시작했습니다. Cloud Services 캐시가 포함된 가상 네트워크 서브넷에서 만들거나 캐시가 클래식 VNet에 배포된 경우에도 이 이전 배포 모델을 사용하여 새 캐시를 계속 만들 수 있습니다. 이 메시지가 표시되면 캐시를 배포할 VNet에 새 서브넷을 만듭니다. 가상 네트워크에서 서브넷을 만들면 Cloud Services 종속성 없이 캐시가 만들어집니다.

서브넷에 하나 이상의 Cloud Services 기반 캐시가 있는지 확인하려면 포털에서 Azure Advisor를 확인하거나 resource-navigation-links REST API를 사용하면 됩니다. 구독 ID, 리소스 그룹 이름, 가상 네트워크 이름 및 서브넷 이름과 함께 resource-navigation-links API를 사용하여 Cloud Services를 사용하는 해당 서브넷의 캐시를 가져옵니다.

REST API를 사용하여 새 캐시를 만드는 경우 만들기 요청과 함께 {"CacheVmType": "CloudService"} redis 구성을 전달하지 않는지도 확인합니다. 해당 매개 변수는 문서화되지 않은 매개 변수이므로 이 작업을 수행할 가능성은 거의 없습니다.

Cloud Services(클래식) 배포 모델을 사용하여 새 캐시를 만들어야 하는 경우 azurecachemigration@microsoft.com에 문의하거나 지원 요청을 만들어 제외를 요청하세요.

캐시가 2024년 8월 31일까지 업그레이드/마이그레이션되지 않으면 어떻게 되나요?

이러한 캐시는 종료되며 캐시의 모든 데이터가 손실됩니다.

지원 타임라인은 어떻게 되나요?

사용 중지 과정은 마이그레이션 시간을 최대한 확보하도록 세 단계로 진행됩니다.

  1. 활성 단계(현재에서 2023년 4월 30일까지)

    캐시는 오늘부터 상태 변경 없이 완벽하게 지원됩니다. 이 기간은 고객이 중단을 최소화하면서 Cloud Services(클래식)를 전환할 수 있도록 하기 위해 제공됩니다.

  2. 유지 관리 단계(2023년 5월 1일~2023년 12월 31일)

    캐시에는 중요한 보안, 안정성 및 버그 수정이 제공되지만 새로운 기능은 제공되지 않습니다.

  3. 비활성 단계(2024년 1월 1일~2024년 8월 31일)

    캐시는 중요한 보안 수정 사항만 수신합니다. 지원 문제가 있는 모든 고객은 지원을 받기 전에 VMSS 기반 캐시로 마이그레이션해야 합니다. 고객은 2024년 8월 31일까지 캐시를 이전해야 합니다.

클라우드 서비스 사용 중지 타임라인을 보여 주는 타임라인 그림(클래식).

이 타임라인은 Redis 4.0에서 실행되는 캐시에 적용되나요?

아니요. 이 타임라인은 Redis 6.0에서 실행되는 캐시에만 적용됩니다. Redis 4.0은 Cloud Services(클래식)의 사용이 중지되기 전에 완료되는 별도 사용 중지 과정의 일부입니다. Cloud Services(클래식)에서 Redis 4.0을 사용하는 나머지 모든 캐시는 2023년 10월 31일 이후 Virtual Machine Scale Sets 및 Redis 6.0을 사용하도록 자동으로 마이그레이션됩니다. 이 마이그레이션 방법을 사용하려면 가동을 중지하거나 캐시의 모든 데이터를 손실해야 하므로, 가동 중지 시간 또는 데이터 손실을 방지하려면 이 날짜가 되기 전에 마이그레이션하세요. 2023년 10월 31일 이전에 자동 업그레이드를 요청하려면 azurecachemigration@microsoft.com에 문의하거나 지원 요청을 만들어 자동 업그레이드를 요청하세요.

이 사용 중지에 대해 더 궁금한 사항이 있으면 어디에서 더 많은 정보를 얻을 수 있나요?

Cloud Services(클래식) 사용 중지에 대한 Q&A 페이지에 질문을 게시하세요. 또한 자세한 내용을 보려면 azurecachemigration@microsoft.com에 이메일을 보낼 수 있습니다.

일반적인 질문

여기서 Azure Cache for Redis 질문에 답변되지 않으면 어떻게 해야 할까요?

질문이 여기에 나열되어 있지 않은 경우 답변을 찾는 데 도움을 드릴 수 있도록 알려주세요.