Azure Cache for Redis를 관리하는 방법

  • 아티클

이 문서에서는 Azure Cache for Redis 인스턴스에 대한 다시 부팅, 업데이트 채널 및 업데이트 예약과 같은 관리 작업을 수행하는 방법을 설명합니다.

Reboot

왼쪽의 다시 부팅을 사용하면 하나 이상의 캐시 노드를 다시 부팅할 수 있습니다. 이 다시 부팅 기능을 사용하면 캐시 노드에 오류가 발생하는 경우 애플리케이션의 복원력을 테스트할 수 있습니다.

Important

다시 부팅은 아직 Enterprise 계층에 사용할 수 없습니다. 다른 모든 가격 책정 계층에서는 다시 부팅을 사용할 수 있습니다.

Screenshot that highlights the Reboot menu option

다시 부팅할 노드를 선택하고 다시 부팅을 선택합니다.

Screenshot that shows which nodes you can reboot

클러스터링이 설정된 프리미엄 캐시를 사용하는 경우 재부팅할 캐시 분할을 선택할 수 있습니다.

screenshot of shard options

하나 이상의 캐시 노드를 다시 부팅하려면 노드를 선택하고 다시 부팅을 선택합니다. 클러스터링이 설정된 프리미엄 캐시를 사용하는 경우 재부팅할 분할을 선택하고 다시 부팅을 클릭합니다. 몇 분 후 선택된 노드가 다시 부팅되고, 다시 몇 분 후에 온라인 상태가 됩니다.

클라이언트 애플리케이션에 미치는 영향은 다시 부팅하는 노드에 따라 달라집니다.

  • 기본 - 기본 노드가 다시 부팅되면 Azure Cache for Redis는 복제본 노드로 장애 조치(failover)하고 해당 노드를 기본으로 승격합니다. 이 장애 조치(failover) 동안에는 짧은 시간 동안 캐시에 연결되지 않을 수 있습니다.
  • 복제본 - 복제본 노드가 다시 부팅되면 일반적으로 캐시 클라이언트는 영향을 받지 않습니다.
  • 기본 및 복제본 모두 - 두 캐시 노드가 모두 다시 부팅되면 Azure Cache for Redis는 두 노드를 모두 다시 부팅하려고 시도하며, 다른 노드를 다시 부팅하기 전에 한 노드가 완료될 때까지 기다립니다. 일반적으로 데이터 손실은 발생하지 않습니다. 그러나 예기치 못한 유지 관리 이벤트나 오류로 인해 데이터 손실이 계속 발생할 수 있습니다. 캐시를 여러 번 연속으로 다시 부팅하면 데이터 손실 가능성이 높아집니다.
  • 클러스터링이 설정된 프리미엄 캐시 노드 - 클러스터링이 설정된 프리미엄 캐시 중 하나 이상의 노드를 다시 부팅하면 선택한 노드에서도 해당하는 노드 또는 클러스터링되지 않은 캐시의 노드를 다시 부팅할 때와 같은 동작이 나타납니다.

다시 부팅 FAQ

애플리케이션을 테스트하려는 경우 어떤 노드를 다시 부팅해야 하나요?

캐시의 주 노드 장애 시 애플리케이션의 복원력을 테스트하려면 기본 노드를 다시 부팅합니다. 복제본 노드 장애 시 애플리케이션 복원력을 테스트하려면 복제본 노드를 다시 부팅합니다.

캐시를 다시 부팅하여 클라이언트 연결을 끊을 수 있나요?

예, 캐시를 다시 부팅하면 모든 클라이언트 연결이 끊어집니다. 다시 부팅은 클라이언트 애플리케이션의 논리 오류나 버그로 인해 각 클라이언트 연결이 다 사용된 경우에 유용할 수 있습니다. 각 가격 책정 계층에는 다양한 크기의 클라이언트 연결 제한이 있으며 이러한 제한에 도달하면 추가적인 클라이언트 연결이 더 이상 허용되지 않습니다. 캐시를 다시 부팅하면 모든 클라이언트 연결을 끊을 수 있습니다.

Important

캐시를 다시 부팅하여 클라이언트 연결의 선택을 취소하는 경우 Redis 노드가 다시 온라인 상태가 되면 StackExchange.Redis가 자동으로 다시 연결됩니다. 기본 문제가 해결되지 않으면 클라이언트 연결은 계속 소비될 것입니다.

다시 부팅하는 경우 캐시의 데이터가 손실되나요?

기본 노드와 복제본 노드를 모두 다시 부팅하면 캐시(또는 클러스터링이 사용하도록 설정된 프리미엄 캐시를 사용하는 경우 해당 분할)에 있는 모든 데이터가 안전할 가능성이 높습니다. 그러나 경우에 따라 데이터가 손실될 수 있습니다. 두 노드를 모두 다시 부팅할 때는 주의해야 합니다.

노드 중 하나만 다시 부팅하는 경우 일반적으로는 데이터가 손실되지 않지만 여전히 손실될 가능성이 있습니다. 예를 들어 캐시 쓰기가 진행 중일 때 기본 노드를 다시 부팅하면 캐시 쓰기의 데이터가 손실됩니다. 데이터 손실이 발생할 수 있는 또 다른 시나리오는 노드 하나를 다시 부팅하는 동시에 오류로 인해 다른 노드가 작동 중단되는 경우입니다. 데이터 손실의 가능한 원인에 대한 자세한 내용은 내 Redis 데이터에서 무엇이 변경되었나요?를 참조하세요.

PowerShell, CLI 또는 기타 관리 도구를 사용하여 내 캐시를 다시 부팅할 수 있나요?

예, PowerShell 명령은 Azure Cache for Redis를 다시 부팅하려면을 참조하세요.

Enterprise 캐시를 다시 부팅할 수 있나요?

아니요. 다시 부팅은 아직 Enterprise 계층에 사용할 수 없습니다. 다시 부팅은 기본, 표준 및 프리미엄 계층에 사용할 수 있습니다. 관리 아래의 리소스 메뉴에 표시되는 설정은 캐시 계층에 따라 달라집니다. Enterprise 계층에서 캐시를 사용할 때 다시 부팅이 표시되지 않습니다.

데이터 플러시(미리 보기)

Azure Cache for Redis의 기본, 표준 또는 프리미엄 계층을 사용하는 경우 리소스 메뉴에 데이터 플러시가 표시됩니다. 데이터 플러시 작업을 사용하면 캐시의 모든 데이터를 삭제하거나 플러시할 수 있습니다. 이 플러시 작업은 크기 조정 작업 전에 사용하여 캐시에서 크기 조정 작업을 완료하는 데 필요한 시간을 잠재적으로 줄일 수 있습니다. 또한 개발/테스트 캐시에서 주기적으로 플러시 작업을 실행하여 메모리 사용량을 확인하도록 구성할 수도 있습니다.

클러스터형 캐시에서 실행되는 플러시 작업은 모든 분할에서 데이터를 동시에 지웁니다.

Important

이전에는 지역 복제된 엔터프라이즈 계층 캐시에만 플러시 작업을 사용할 수 있었습니다. 이제 기본, 표준 및 프리미엄 계층으로 제공됩니다.

Screenshot showing flush data selected in the resource menu of a cache instance.

채널 업데이트 및 업데이트 예약

왼쪽에서 업데이트 예약을 사용하면 캐시 인스턴스에 대한 업데이트 채널과 유지 관리 기간을 선택할 수 있습니다.

안정적인 업데이트 채널을 사용하는 모든 캐시 인스턴스는 미리 보기 업데이트 채널을 사용하는 캐시 인스턴스보다 몇 주 늦게 업데이트를 받습니다. 프로덕션이 아닌 워크로드와 덜 중요한 워크로드에 대해서는 미리 보기 업데이트 채널을 선택하는 것이 좋습니다. 가장 중요한 프로덕션 워크로드에 대해서는 안정적인 업데이트 채널을 선택합니다. 모든 캐시는 기본적으로 안정적인 업데이트 채널로 기본 설정됩니다.

Important

캐시 인스턴스에서 업데이트 채널을 변경하면 캐시에서 올바른 업데이트를 적용하기 위한 패치 이벤트가 진행됩니다. 유지 관리 기간 동안 업데이트 채널을 변경하는 것이 좋습니다.

유지 관리 기간을 사용하면 캐시를 호스팅하는 VM이 업데이트될 수 있는 요일과 시간을 제어할 수 있습니다. Azure Cache for Redis는 사용자가 정의한 지정된 기간 내에 Redis 서버 소프트웨어 업데이트를 시작 및 종료하는 데 가장 적합합니다.

Important

업데이트 채널 및 유지 관리 기간은 Redis 서버 업데이트와 캐시를 호스팅하는 VM의 운영 체제 업데이트에 적용됩니다. 업데이트 채널 및 유지 관리 기간은 캐시 VM 또는 기타 Azure 네트워킹 구성 요소를 호스팅하는 호스트에 대한 호스트 OS 업데이트에 적용되지 않습니다. 드물지만 이전 모델에서 캐시가 호스트되는 경우 유지 관리 기간이 게스트 OS 업데이트에도 적용되지 않습니다. 캐시의 DNS 이름이 접미사 cloudapp.net, chinacloudapp.cn, usgovcloudapi.net 또는 cloudapi.de로 확인되면 캐시가 이전 모델에 있는지 알 수 있습니다.

현재는 엔터프라이즈 계층 캐시에 대한 업데이트 채널 또는 예약된 업데이트를 구성하는 데 사용할 수 있는 옵션이 없습니다.

Screenshot showing schedule updates

유지 관리 기간을 지정하려면 원하는 요일을 선택하고 각 요일의 유지 관리 기간 시작 시간을 지정합니다. 그런 다음 확인을 선택합니다. 유지 관리 기간 시간은 UTC이며 시간 단위로만 구성할 수 있습니다.

업데이트를 위한 기본 및 최소 유지 관리 기간은 5시간입니다. 이 값은 Azure Portal에서는 구성할 수 없지만 PowerShell에서 New-AzRedisCacheScheduleEntry cmdlet의 MaintenanceWindow 매개 변수를 사용하여 구성할 수 있습니다. 자세한 내용은 PowerShell, CLI 또는 기타 관리 도구를 사용하여 예약된 업데이트를 관리할 수 있나요?를 참조하세요.

업데이트 예약 FAQ

일정 업데이트 기능을 사용하지 않으면 업데이트가 언제 발생하나요?

유지 관리 기간을 지정하지 않으면, 언제든지 업데이트가 진행될 수 있습니다.

예약된 유지 관리 기간 동안에는 어떤 유형의 업데이트가 진행되나요?

예약된 유지 관리 기간 동안에는 Redis 서버 업데이트만 수행됩니다. 유지 관리 기간이 Azure 업데이트 또는 호스트 운영 체제에 대한 업데이트에는 적용되지 않습니다.

PowerShell, CLI 또는 기타 관리 도구를 사용하여 예약된 업데이트를 관리할 수 있나요?

예, 다음 PowerShell cmdlet을 사용하여 예약된 업데이트를 관리할 수 있습니다.

예약된 업데이트 기능을 통해 적용되고 관리되는 업데이트는 예약된 업데이트 기간 외에 발생할 수 있나요?

예. 일반적으로 업데이트는 구성된 예약된 업데이트 기간 외에 적용되지 않습니다. 드물지만 중요한 보안 업데이트는 보안 정책의 일부로 패치 일정 외에 적용할 수 있습니다.

다음 단계

Azure Cache for Redis 기능에 대해 자세히 알아봅니다.