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