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