Azure Cache for Redis를 위한 장애 조치(failover) 및 패치

  • 아티클

복원력 있고 성공적인 클라이언트 애플리케이션을 빌드하려면 Azure Cache for Redis 서비스의 장애 조치(failover)를 이해하는 것이 중요합니다. 장애 조치(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 서비스는 정기적으로 최신 플랫폼 기능 및 수정 사항으로 캐시를 업데이트합니다. 캐시를 패치하기 위해 서비스는 다음 단계를 수행합니다.

  1. 서비스는 복제본 노드를 먼저 패치합니다.
  2. 패치된 복제본은 공동으로 자신을 주 복제본으로 승격합니다. 이 승격은 계획된 장애 조치(failover)로 간주됩니다.
  3. 이전의 주 노드가 다시 부팅되어 새 변경 내용을 적용하고 복제본 노드로 백업됩니다.
  4. 복제본 노드는 주 노드에 연결되고 데이터를 동기화합니다.
  5. 데이터 동기화가 완료되면 나머지 노드에 대해 패치 프로세스가 반복됩니다.

패치는 계획된 장애 조치(failover)이므로 복제본 노드는 신속하게 주 노드가 되도록 자체적으로 승격합니다. 그런 다음, 노드는 요청 및 새 연결 서비스를 시작합니다. 기본 캐시에는 복제본 노드가 없으며 업데이트가 완료될 때까지 사용할 수 없습니다. 클러스터형 캐시의 각 분할된 데이터베이스는 별도로 패치되며 다른 분할된 데이터베이스에 대한 연결을 닫지 않습니다.

Important

노드는 데이터 손실을 방지하기 위해 한 번에 하나씩 패치됩니다. 기본 캐시는 데이터가 손실됩니다. 클러스터형 캐시는 한 번에 하나의 분할된 데이터베이스로 패치됩니다.

동일한 리소스 그룹 및 지역의 여러 캐시도 한 번에 하나씩 패치됩니다. 다른 리소스 그룹 또는 다른 지역에 있는 캐시는 동시에 패치될 수 있습니다.

프로세스가 반복되기 전에 전체 데이터 동기화가 발생하기 때문에 표준 또는 프리미엄 캐시를 사용할 때 데이터 손실이 발생할 가능성이 낮습니다. 데이터를 내보내고지속성을 사용하도록 설정하여 데이터 손실을 추가로 방지할 수 있습니다.

추가 캐시 로드

장애 조치(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은(는) 기본, 표준 및 프리미엄 계층에만 사용할 수 있습니다.

클라이언트 네트워크 구성 변경 사항

특정 클라이언트 쪽 네트워크 구성 변경은 “연결을 사용할 수 없음” 오류를 트리거할 수 있습니다. 이러한 변경 내용에는 다음이 포함됩니다.

  • 스테이징 슬롯과 프로덕션 슬롯 간에 클라이언트 애플리케이션의 가상 IP 주소 교환.
  • 애플리케이션의 인스턴스 크기 또는 수 조정.

이러한 변경으로 인해 1분 미만으로 지속되는 연결 문제가 발생할 수 있습니다. 클라이언트 애플리케이션은 다른 외부 네트워크 리소스뿐만 아니라 Azure Cache for Redis 서비스에 대한 연결이 끊어질 수 있습니다.

복원력 구축

장애 조치를 완전히 피할 수는 없습니다. 대신 연결 끊기와 실패한 요청에 복원력이 있는 클라이언트 애플리케이션을 작성합니다. 대부분의 클라이언트 라이브러리가 캐시 엔드포인트에 자동으로 다시 연결되지만 실패한 요청을 다시 시도하려는 경우는 거의 없습니다. 애플리케이션 시나리오에 따라 백오프와 함께 재시도 논리를 사용하는 것이 좋을 수 있습니다.

복원력 있는 애플리케이션을 만들려면 어떻게 해야 하나요?

복원력 있는 클라이언트, 특히 회로 차단기와 다시 시도 패턴을 빌드하려면 다음 디자인 패턴을 참조하세요.

클라이언트 애플리케이션의 복원력을 테스트하려면 연결 중단을 수동 트리거로 다시 부팅을 사용합니다.

또한 특정 주간 기간 동안 Redis 런타임 패치를 적용하려면 예약된 업데이트를 사용하여 캐시에서 채널 및 유지 관리 기간을 업데이트하는 것이 좋습니다. 이러한 기간은 일반적으로 잠재적인 인시던트 방지를 위해 클라이언트 애플리케이션 트래픽이 낮은 기간입니다. 자세한 내용은 채널 업데이트 및 업데이트 예약을 참조하세요.

자세한 내용은 연결 복원력을 참조하세요.

관련 콘텐츠