중요합니다
Azure Cache for Redis는 모든 SKU에 대한 사용 중지 타임라인을 발표했습니다. 가능한 한 빨리 기존 Azure Cache for Redis 인스턴스를 Azure Managed Redis 로 이동하는 것이 좋습니다.
사용 중지에 대한 자세한 내용은 다음과 같습니다.
복원력 있고 성공적인 클라이언트 애플리케이션을 빌드하려면 Azure Cache for Redis 서비스에서 장애 조치(failover)를 이해하는 것이 중요합니다. 장애 조치(failover)는 계획된 관리 작업의 일부이거나 계획되지 않은 하드웨어 또는 네트워크 오류로 인해 발생할 수 있습니다. Azure Cache for Redis 바이너리를 관리 서비스가 패치할 때, 캐시 장애 조치(failover)가 일반적으로 사용됩니다.
이 문서에서는 다음 정보를 찾습니다.
- 장애 조치(failover)란?
- 패치가 진행되는 동안 장애 조치가 발생하는 방식.
- 복원력 있는 클라이언트 애플리케이션을 빌드하는 방법입니다.
장애 조치(failover)란?
먼저 Azure Cache for Redis에 대한 장애 조치(failover)의 개요를 살펴보겠습니다.
캐시 아키텍처의 빠른 요약
캐시는 별도의 개인 IP 주소가 있는 여러 가상 머신으로 구성됩니다. 노드라고도 하는 각 가상 머신은 단일 가상 IP 주소를 사용하여 공유 부하 분산 장치에 연결됩니다. 각 노드는 Redis 서버 프로세스를 실행하고 호스트 이름 및 Redis 포트를 사용하여 액세스할 수 있습니다. 각 노드는 주 노드 또는 복제본 노드로 간주됩니다. 클라이언트 애플리케이션이 캐시에 연결되면 해당 트래픽은 이 부하 분산 장치를 통과하고 자동으로 주 노드로 라우팅됩니다.
기본 캐시에서 단일 노드는 항상 기본 노드입니다. 표준 또는 프리미엄 캐시에는 두 개의 노드가 있습니다. 하나는 주 노드로 선택되고 다른 하나는 복제본입니다. 표준 및 프리미엄 캐시에는 여러 노드가 있으므로 한 노드를 사용할 수 없는 반면 다른 노드는 요청을 계속 처리할 수 있습니다. 클러스터형 캐시는 각각 고유한 주 노드와 복제본 노드가 있는 여러 분할된 데이터베이스로 구성됩니다. 하나의 샤드가 다운될 수 있지만, 다른 샤드들은 여전히 사용 가능합니다.
비고
기본 캐시에는 여러 노드가 없으며 가용성에 대한 SLA(서비스 수준 계약)를 제공하지 않습니다. 기본 캐시는 개발 및 테스트 목적으로만 권장됩니다. 다중 노드 배포에 표준 또는 프리미엄 캐시를 사용하여 가용성을 높입니다.
장애 조치(failover) 설명
장애 조치(failover)는 복제본 노드가 자신을 주 노드로 승격하고 이전 주 노드가 기존 연결을 닫을 때 발생합니다. 주 노드가 다시 활성화되면, 역할의 변경을 확인하고 복제본이 되도록 자신의 역할을 강등시킵니다. 그런 다음 새 주 서버에 연결하고 데이터를 동기화합니다. 장애 조치(failover)는 계획되거나 계획되지 않을 수 있습니다.
계획된 장애 조치(failover)는 서로 다른 두 시기에 수행됩니다.
- Redis 패치 또는 OS 업그레이드와 같은 시스템 업데이트
- 크기 조정 및 다시 부팅과 같은 관리 작업
노드는 업데이트에 대한 사전 알림을 받기 때문에 역할을 협조적으로 교환하고 변경의 부하 분산 장치를 신속하게 업데이트할 수 있습니다. 계획된 장애 조치(failover)는 일반적으로 1초 이내에 완료됩니다.
하드웨어 오류, 네트워크 오류 또는 주 노드에 대한 기타 예기치 않은 중단으로 인해 계획되지 않은 장애 조치(failover )가 발생할 수 있습니다. 복제본 노드는 자신을 주 노드로 승격하지만 프로세스는 더 오래 걸립니다. 복제본 노드는 장애 조치(failover) 프로세스를 시작하기 전에 먼저 주 노드를 사용할 수 없음을 감지해야 합니다. 또한 복제본 노드는 불필요한 장애 조치(failover)를 방지하기 위해 계획되지 않은 이 오류가 일시적이거나 로컬이 아닌지 확인해야 합니다. 이러한 검색 지연은 계획되지 않은 장애 조치(failover)가 일반적으로 10~15초 이내에 완료됨을 의미합니다.
패치는 어떻게 발생하나요?
Azure Cache for Redis 서비스는 최신 플랫폼 기능 및 수정 사항으로 캐시를 정기적으로 업데이트합니다. 캐시를 패치하기 위해 서비스는 다음 단계를 수행합니다.
- 서비스는 복제본 노드를 먼저 패치합니다.
- 패치된 복제본은 자체적으로 주 복제본으로 승격됩니다. 이 프로모션은 계획된 장애 복구(failover)로 간주됩니다.
- 이전 주 노드가 다시 부팅되어 새 변경 내용을 적용하고 복제본 노드로 다시 시작합니다.
- 복제본 노드는 주 노드에 연결하고 데이터를 동기화합니다.
- 데이터 동기화가 완료되면 나머지 노드에 대해 패치 프로세스가 반복됩니다.
패치는 계획된 장애 조치(failover)이므로 복제본 노드는 신속하게 자신을 주 노드로 승격합니다. 그런 다음 노드가 요청 및 새 연결 서비스를 시작합니다. 기본 캐시에는 복제본 노드가 없으며 업데이트가 완료될 때까지 사용할 수 없습니다. 클러스터형 캐시의 각 분할된 데이터베이스는 별도로 패치되며 다른 분할된 데이터베이스에 대한 연결을 닫지 않습니다.
중요합니다
노드는 데이터 손실을 방지하기 위해 한 번에 하나씩 패치됩니다. 기본 캐시는 데이터가 손실됩니다. 클러스터형 캐시는 한 번에 하나의 샤드씩 패치됩니다.
동일한 리소스 그룹 및 지역의 여러 캐시도 한 번에 하나씩 패치됩니다. 다른 리소스 그룹 또는 다른 지역에 있는 캐시는 동시에 패치될 수 있습니다.
프로세스가 반복되기 전에 전체 데이터 동기화가 발생하므로 표준 또는 프리미엄 캐시를 사용할 때 데이터 손실이 발생할 가능성이 낮습니다. 데이터를 내보내 고 지속성을 사용하도록 설정하여 데이터 손실을 추가로 방지할 수 있습니다.
추가 캐시 로드
장애 조치(failover)가 발생할 때마다 표준 및 프리미엄 캐시는 한 노드에서 다른 노드로 데이터를 복제해야 합니다. 이 복제로 인해 서버 메모리와 CPU가 모두 부하가 증가합니다. 캐시 인스턴스가 이미 많이 로드된 경우 클라이언트 애플리케이션의 대기 시간이 증가할 수 있습니다. 극단적인 경우 클라이언트 애플리케이션은 시간 제한 예외를 받을 수 있습니다. 더 많은 부하의 영향을 완화하려면 캐시 설정을 maxmemory-reserved합니다.
장애 조치(failover)가 내 클라이언트 애플리케이션에 어떤 영향을 주나요?
클라이언트 애플리케이션은 Azure Cache For Redis에서 일부 오류를 수신할 수 있습니다. 클라이언트 애플리케이션에서 볼 수 있는 오류 수는 장애 조치(failover) 시 해당 연결에서 보류 중인 작업 수에 따라 달라집니다. 해당 연결을 닫은 노드를 통해 라우팅된 모든 연결에 오류가 표시됩니다.
많은 클라이언트 라이브러리는 다음을 포함하여 연결이 끊어질 때 다양한 유형의 오류를 throw할 수 있습니다.
- 타임아웃 예외
- 연결 예외
- 소켓 예외
예외의 수와 유형은 캐시가 연결을 닫을 때 요청이 코드 경로에 있는 위치에 따라 달라집니다. 예를 들어 장애 조치(failover)가 발생할 때 요청을 보내지만 응답을 받지 못한 작업은 시간 제한 예외를 가져올 수 있습니다. 닫힌 연결 개체의 새 요청은 다시 연결이 성공적으로 수행될 때까지 연결 예외를 수신합니다.
대부분의 클라이언트 라이브러리는 이렇게 하도록 구성된 경우 캐시에 다시 연결하려고 시도합니다. 그러나 예기치 않은 버그로 인해 때때로 라이브러리 개체를 복구할 수 없는 상태로 전환할 수 있습니다. 오류가 미리 구성된 시간보다 오래 지속되는 경우 연결 개체를 다시 만들어야 합니다. Microsoft.NET 및 기타 개체 지향 언어에서는 ForceReconnect 패턴을 사용하여 애플리케이션을 다시 시작하지 않고 연결을 다시 만들 수 있습니다.
유지 관리 전에 알림을 받을 수 있나요?
Azure Cache for Redis는 AzureRedisEvents으로 명명된 채널(게시/구독 채널, pub/sub)에 실시간 유지 관리 알림을 게시합니다. 많은 인기 있는 Redis 클라이언트 라이브러리는 pub/sub 채널 구독을 지원합니다. 일반적으로 채널에서 AzureRedisEvents 알림을 받는 것은 클라이언트 애플리케이션에 간단하게 추가됩니다. 유지 관리 이벤트에 대한 자세한 내용은 AzureRedisEvents를 참조하세요.
비고
AzureRedisEvents 채널은 며칠 또는 몇 시간 전에 알릴 수 있는 메커니즘이 아닙니다. 채널은 서버 가용성에 영향을 줄 수 있는 예정된 서버 유지 관리 이벤트를 클라이언트에 알릴 수 있습니다.
AzureRedisEvents 는 기본, 표준 및 프리미엄 계층에만 사용할 수 있습니다.
유지 관리에 포함된 업데이트는 무엇인가요?
유지 관리에는 다음 업데이트가 포함됩니다.
- Redis Server 업데이트: Redis 서버 이진 파일의 모든 업데이트 또는 패치입니다.
- VM(가상 머신) 업데이트: Redis 서비스를 호스트하는 가상 머신의 모든 업데이트입니다. VM 업데이트에는 호스팅 환경의 소프트웨어 구성 요소를 네트워킹 구성 요소 업그레이드 또는 서비스 해제로 패치하는 기능이 포함됩니다.
패치 전에 Azure Portal의 서비스 상태에 유지 관리가 표시됩니까?
아니요, 유지 관리는 포털의 서비스 상태 또는 다른 위치에 표시되지 않습니다.
계획된 유지 관리 전에 알림을 받을 수 있는 시간은 얼마인가요?
채널을 사용하는 AzureRedisEvents 경우 유지 관리 15분 전에 알림을 받습니다.
클라이언트 네트워크 구성 변경
특정 클라이언트 쪽 네트워크 구성 변경으로 인해 사용 가능한 연결 없음 오류가 발생할 수 있습니다. 이러한 변경 내용에는 다음이 포함될 수 있습니다.
- 스테이징 슬롯과 프로덕션 슬롯 간에 클라이언트 애플리케이션의 가상 IP 주소를 교환합니다.
- 애플리케이션 인스턴스의 크기 또는 수 크기 조정
이러한 변경으로 인해 일반적으로 1분 미만 지속되는 연결 문제가 발생할 수 있습니다. 클라이언트 애플리케이션은 다른 외부 네트워크 리소스뿐만 아니라 Azure Cache for Redis 서비스에 대한 연결이 끊어질 수 있습니다.
복원력 구축
장애 조치를 완전히 피할 수는 없습니다. 대신 연결 중단 및 실패한 요청에 탄력적이 되도록 클라이언트 애플리케이션을 작성합니다. 대부분의 클라이언트 라이브러리는 캐시 엔드포인트에 자동으로 다시 연결되지만 실패한 요청을 다시 시도하려는 클라이언트 라이브러리는 거의 없습니다. 애플리케이션 시나리오에 따라 백오프와 함께 재시도 논리를 사용하는 것이 합리적일 수 있습니다.
애플리케이션을 복원력 있게 만들려면 어떻게 해야 하나요?
복원력 있는 클라이언트, 특히 회로 차단기 및 재시도 패턴을 빌드하려면 다음 디자인 패턴을 참조하세요.
클라이언트 애플리케이션의 복원력을 테스트하려면 다시 부팅 을 연결 끊기 수동 트리거로 사용합니다.
또한 예약된 업데이트를 사용하여 특정 주간 기간 동안 Redis 런타임 패치를 적용하도록 캐시에 대한 업데이트 채널 및 유지 관리 기간을 선택하는 것이 좋습니다. 이러한 기간은 일반적으로 잠재적인 인시던트 방지를 위해 클라이언트 애플리케이션 트래픽이 낮은 기간입니다. 자세한 내용은 업데이트 채널 및 업데이트 예약을 참조하세요.
자세한 내용은 연결 복원력을 참조하세요.
관련 콘텐츠
- 업데이트 채널 및 업데이트 예약
- 다시 부팅을 사용하여 애플리케이션 복원력 테스트
- 메모리 예약 및 정책 구성