읽기 복제본

표준 등급의 Memorystore for Redis는 읽기 복제본을 사용해서 애플리케이션의 읽기 쿼리를 확장하는 기능을 제공합니다. 이 페이지에서는 사용자가 여러 Memorystore Redis 등급 기능에 익숙하다고 가정합니다.

읽기 복제본을 사용하면 복제본을 쿼리하여 읽기 워크로드를 확장할 수 있습니다. 읽기 복제본은 애플리케이션이 복제본 간에 쿼리를 더 쉽게 배포할 수 있도록 하기 위해 제공됩니다. 자세한 내용은 읽기 엔드포인트로 읽기 확장을 참조하세요.

읽기 복제본으로 Redis 인스턴스를 관리하는 방법은 읽기 복제본 관리를 참조하세요.

읽기 복제본 사용 사례

세션 저장소, 리더보드, 추천 엔진, 기타 사용 사례에서는 인스턴스에 높은 가용성이 요구됩니다. 이러한 사용 사례에서는 쓰기보다 읽기가 더 많고 일반적으로 어느 정도의 읽기 지연이 용인됩니다. 이러한 경우 인스턴스 가용성 및 확장성 증가를 위해 읽기 복제본을 활용하는 것이 좋습니다.

읽기 복제본 동작

  • 표준 등급 인스턴스에서는 기본적으로 읽기 복제본이 사용 설정되지 않습니다.
  • 인스턴스에서 읽기 복제본을 사용 설정한 다음에는 해당 인스턴스에서 더 이상 읽기 복제본을 사용 중지할 수 없습니다.
  • 표준 등급 인스턴스는 1~5개의 읽기 복제본을 포함할 수 있습니다.
  • 읽기 엔드포인트는 복제본 노드 간의 쿼리 분산을 위한 단일 엔드포인트를 제공합니다.
  • 읽기 복제본은 Redis 비동기 복제를 사용하여 유지 관리됩니다.

주의사항 및 제한사항

  • 노드가 5GB 이상인 인스턴스 크기에 대해서만 읽기 복제본이 지원됩니다.
  • Redis 버전 5.0 이상을 사용하는 인스턴스에서만 읽기 복제본을 사용 설정할 수 있습니다.
  • 노드 프로비저닝을 위한 영역 및 대체 영역을 지정하면 Memorystore가 인스턴스에서 첫 번째 및 두 번째 노드에 대해 이러한 영역을 사용합니다. 그런 다음 Memorystore가 인스턴스에 대해 프로비저닝된 남은 모든 노드의 영역을 선택합니다.
  • CIDR IP 주소 범위가 /28 이상인 인스턴스를 프로비저닝해야 합니다. /27 및 /26과 같이 큰 범위 크기는 유효합니다. 이 기능은 /29와 같은 작은 범위를 지원하지 않습니다.

아키텍처

읽기 복제본을 사용 설정할 때는 인스턴스에 포함할 복제본 수를 지정합니다. Memorystore는 한 리전에서 사용 가능한 영역에 기본 및 읽기 복제본 노드를 자동으로 배포합니다.

각 인스턴스에는 기본 엔드포인트와 읽기 엔드포인트가 있습니다. 기본 엔드포인트는 항상 기본 노드로 트래픽을 전달하지만, 읽기 엔드포인트는 사용 가능한 복제본 간에 읽기 쿼리를 자동으로 부하 분산합니다.

Memorystore for Redis 상태 모니터링 서비스는 인스턴스를 모니터링하고 기본 노드의 장애를 감지하고 복제본을 새 기본 노드로 선택하고 새로운 기본 인스턴스로 자동 장애 조치를 시작합니다.

읽기 복제본이 있는 인스턴스의 장애 조치

기본 노드가 실패하면 Memorystore 상태 모니터링 서비스가 장애 조치를 시작하고 읽기 및 쓰기를 위해 새로운 기본 노드가 제공됩니다. 장애 조치는 일반적으로 30초 내에 완료됩니다.

장애 조치가 발생하면 기본 엔드포인트가 트래픽을 새 기본 노드로 자동으로 리디렉션하지만 기본 엔드포인트에 대한 모든 클라이언트 연결이 장애 조치 중에 끊어집니다. 연결 재시도 논리가 있는 애플리케이션은 새 기본 노드가 온라인이 되었을 때 자동으로 다시 연결합니다. 읽기 엔드포인트에 대한 클라이언트 연결 중 일부도 장애 조치 중 기본 노드로 승격된 읽기 복제본에서 연결 끊김이 발생합니다. 남은 복제본에 대한 연결은 장애 조치 중에도 계속 작동합니다. 재시도할 때는 연결이 새로운 복제본으로 리디렉션됩니다.

장애 조치가 발생하면 비동기적인 복제 특성으로 인해 복제본에 서로 다른 복제 지연이 발생할 수 있습니다. 하지만 장애 조치 프로세스는 최선의 방식으로 지연을 최소화해서 복제본으로 장애 조치를 수행합니다. 이렇게 해서 장애 조치 중 데이터 손실 및 읽기 처리량 감소를 최소화합니다. 새로 승격된 기본 노드의 영역은 이전 기본 노드의 영역과 같거나 다를 수 있습니다. 특정 복제본이 이전 기본 노드와 동일한 영역에 있고 지연이 가장 작으면 이 복제본이 새 기본 노드로 선택됩니다. 그렇지 않으면 다른 영역의 복제본이 새로운 기본 노드가 될 수 있습니다.

복제가 비동기적이기 때문에 장애 조치 중에는 항상 오래된 데이터를 읽을 가능성이 존재합니다. 또한 새로운 기본 노드를 승격하는 동안 인스턴스에 대한 일부 쓰기 작업이 손실될 수 있습니다. 애플리케이션이 이러한 동작을 처리할 수 있어야 합니다.

Redis는 최선을 다해서 장애 조치 중 다른 복제본이 전체 동기화를 요구하지 않도록 하지만, 드물게도 이러한 경우가 발생할 수 있습니다. 전체 동기화는 복제되는 데이터 세트의 크기 및 쓰기 속도에 따라 몇 분에서 최대 1시간까지 걸릴 수 있습니다. 이러한 시간 동안 전체 동기화가 수행되는 복제본은 읽을 수 없습니다. 동기화가 완료되면 읽기 목적으로 복제본에 액세스할 수 있습니다.

읽기 복제본의 장애 모드

읽기 복제본이 있는 인스턴스에서는 애플리케이션에 영향을 주는 여러 장애 및 비정상 상태가 발생할 수 있습니다. 이러한 동작은 인스턴스에 복제본이 하나만 있는지 또는 두 개 이상인지에 따라 달라집니다. 이 섹션에서는 몇 가지 일반적인 장애 모드와 이러한 상황에서의 인스턴스 동작에 대해 설명합니다.

복제본 사용 불가

  • 어떤 이유로든 복제본에 장애가 발생하면 복제본이 사용 불가로 표시되고 일정 제한 시간이 지난 후 복제본에 대한 모든 연결이 종료됩니다. 복제본이 복구된 다음에는 새 연결이 복원된 복제본으로 라우팅됩니다. 복제본 복구 시간은 장애 모드에 따라 달라집니다.

  • Compute Engine이 소진되거나 영역에 장애가 발생하면 이 조건이 해결될 때까지 복제본이 복구되지 않습니다.

영역 장애

  • 기본 노드가 있는 영역에 장애가 발생하면 기본 노드가 다른 영역에 있는 복제본으로 자동으로 장애 조치됩니다. 인스턴스에 복제본이 하나만 있으면 영역 중단 기간 동안 읽기 엔드포인트를 사용할 수 없습니다. 인스턴스에 복제본이 두 개 이상 있으면 영향을 받는 영역 외부에 있는 복제본을 읽기에 사용할 수 있습니다.

  • 복제본이 하나 이상 있는 영역에 장애가 발생하면 영역 장애 기간 동안 해당 복제본을 사용할 수 없습니다. 영역 장애가 2개 있고 복제본이 2개 이상 있으면 남은 영역에서 지연이 가장 적은 복제본이 기본 노드로 승격됩니다. 영향을 받지 않는 영역에 있는 남은 복제본은 읽기에 사용할 수 있습니다.

네트워크 파티션.

네트워크 파티션은 노드가 계속 실행되지만 클라이언트, 영역, 피어 노드에 연결할 수 없는 경우의 시나리오입니다. Memorystore는 쿼럼 기반 시스템을 사용해서 격리된 노드가 쓰기를 지원하지 못하도록 방지합니다. 네트워크 파티션의 경우 열등 파티션에 있는 기본 노드가 자동으로 강등됩니다. 아직 기본 노드가 없으면 우수 파티션(있는 경우)이 새로운 기본 노드로 선택됩니다. 격리된 복제본은 계속 읽기를 지원합니다. 하지만 기본 노드와 동기화할 수 없으면 데이터가 오래될 수 있습니다.

연결이 끊어졌는지 확인하려면 master_link_down_since_seconds 및 offset_diff 측정항목을 모니터링해서 격리된 노드를 확인합니다.

소진

일부 경우에는 Memorystore에 필요한 Compute Engine 리소스가 영역에 제공되지 않아 리소스가 소진될 수 있습니다. 인스턴스를 프로비저닝하려고 시도할 때 한 리전에서 리소스 소진이 발생하면 인스턴스 만들기 작업이 실패합니다.

전체 동기화

복제본이 기본 노드에서 너무 뒤쳐지면 기본 노드에서 복제본으로 전체 스냅샷을 복사하는 전체 동기화가 트리거됩니다. 이 작업은 몇 분에서 최악의 경우 한 시간까지 걸릴 수 있습니다. 전체 동기화는 인스턴스 장애를 일으키지 않지만, 이 기간 동안 전체 동기화가 진행되는 복제본에서 읽기를 수행할 수 없고, 기본 노드에서 CPU 및 메모리 사용량이 증가합니다.

기본 엔드포인트가 READONLY를 반환

읽기 복제본이 있는 Memorystore for Redis 인스턴스의 기본 엔드포인트에 쓰면 예기치 않게 -READONLY You can't write against a read only replica. 오류가 발생할 수 있습니다. 인스턴스에 대한 연결을 닫고 다시 만드는 것이 좋습니다. 대부분의 경우 클라이언트 애플리케이션을 다시 시작하면 문제가 완화될 수 있습니다. 이러한 옵션을 사용할 수 없거나 동작이 지속되면 Google Cloud 지원팀에 문의하세요.

읽기 엔드포인트를 사용하여 읽기 확장

읽기 복제본은 애플리케이션이 복제본에서 읽기를 수행하여 읽기를 확장할 수 있게 해줍니다. 애플리케이션은 읽기 엔드포인트를 통해 읽기 복제본에 연결할 수 있습니다.

읽기 엔드포인트

읽기 엔드포인트는 애플리케이션이 연결하는 대상 IP 주소입니다. 인스턴스의 복제본에서 연결을 고르게 부하 분산합니다. 읽기 복제본에 대한 연결은 읽기 쿼리를 전송할 수 있지만 쓰기 쿼리는 전송할 수 없습니다. 읽기 복제본이 사용 설정된 모든 표준 등급 인스턴스에는 읽기 엔드포인트가 있습니다. 인스턴스의 읽기 엔드포인트를 보는 방법은 인스턴스의 읽기 복제본 정보 보기를 참조하세요.

읽기 엔드포인트 동작

  • 읽기 엔드포인트는 사용 가능한 모든 복제본에 자동으로 연결을 배포합니다. 기본 노드로는 연결이 전달되지 않습니다.
  • 클라이언트 트래픽을 처리할 수 있는 복제본은 사용 가능한 것으로 간주됩니다. 복제본에서 기본 노드에 전체 동기화가 수행되는 시간은 여기에 포함되지 않습니다.
  • 복제 지연이 높은 복제본은 계속 트래픽을 처리합니다. 쓰기 볼륨이 높은 애플리케이션은 많은 쓰기 작업을 처리하는 복제본에서 오래된 데이터를 읽을 수 있습니다.
  • 복제본 노드가 기본 노드가 되면 해당 노드에 대한 연결이 종료되고 새 복제본 노드로 새 연결이 리디렉션됩니다.
  • 읽기 엔드포인트에 대한 개별 연결은 연결 전체 기간 동안 동일 복제본을 대상으로 합니다. 동일한 클라이언트 호스트의 연결이라도 모두 동일한 복제본 노드를 대상으로 하지는 않습니다.

읽기 일관성

읽기 복제본은 OSS Redis 비동기 복제를 사용하여 유지 관리됩니다. 비동기 복제의 특성으로 인해 복제본이 기본 노드보다 뒤쳐질 수 있습니다. 이 복제본에서도 읽기를 수행하는 지속적인 쓰기를 수행하는 애플리케이션은 일관적이지 않은 읽기를 허용할 수 있어야 합니다.

애플리케이션에 '쓰기 읽기' 일관성이 필요하면 쓰기 및 읽기 모두 기본 엔드포인트를 사용하는 것이 좋습니다. 기본 엔드포인트를 사용하면 읽기가 항상 기본 노드로 전달됩니다. 이 경우에도 장애 조치 후 오래된 데이터 읽기가 발생할 수 있습니다.

기본 노드의 키에 TTL을 설정하면 기본 노드 또는 복제본에서 만료된 키 읽기가 수행되지 않습니다. Redis에서는 복제본에서 만료된 키를 읽을 수 없도록 보장하기 때문입니다.

기존 인스턴스에서 읽기 복제본을 사용 설정할 때의 동작

  • 기존 Redis 인스턴스에서 읽기 복제본 사용 설정은 배타적인 작업입니다. 즉, 읽기 복제본을 사용 설정하는 동일 작업의 일부로 다른 업데이트 작업 인스턴스 알림을 수행할 수 없습니다.

  • 기존 Redis 인스턴스에서 읽기 복제본을 사용 설정하려면 Memorystore for Redis에 할당된 기존 IP 주소 범위의 크기에 관계없이 /28 크기의 유효한 IP 주소 범위를 추가로 할당해야 합니다.

    • Redis 인스턴스에 대해 읽기 복제본을 사용 설정할 때는 IP 주소를 추가로 제공해야 합니다. 특정 범위를 직접 선택하거나 Memorystore에서 범위를 자동으로 선택할 수 있습니다.

  • 읽기 복제본을 사용 설정할 때는 인스턴스의 읽기/쓰기 IP 주소가 변경되지 않습니다. 읽기 엔드포인트 IP 주소는 읽기 복제본을 사용 설정할 때 제공하는 추가 범위가 아니라 Memorystore 인스턴스에 할당된 원래 범위에 있습니다.

  • 새 읽기 엔드포인트를 찾으려면 읽기 복제본 사용 설정 작업이 완료된 후 인스턴스의 읽기 복제본 정보를 확인합니다.

인스턴스 확장

인스턴스의 읽기 복제본 수를 확장하고 노드 크기도 수정할 수 있습니다.

애플리케이션에 미치는 영향을 최소화하기 위해서는 읽기 및 쓰기 트래픽이 낮을 때 인스턴스를 확장하는 것이 좋습니다.

새 복제본을 추가하면 복제본이 전체 동기화를 수행하는 동안 기본 노드에서 추가 로드가 발생합니다. 노드를 추가할 때 기존 연결은 영향을 받거나 전송되지 않습니다. 새 복제본을 사용할 수 있게 되면 해당 엔드포인트에서 연결을 수신하고 읽기를 지원합니다. 복제본을 삭제하면 해당 복제본으로 라우팅된 모든 활성 연결이 닫힙니다. 자동으로 읽기 엔드포인트에 다시 연결해서 남은 복제본에 대해 연결을 다시 설정하도록 클라이언트 애플리케이션을 구성해야 합니다.

권장사항

메모리 관리

Redis는 클라이언트 쓰기가 인스턴스의 maxmemory 한도를 초과하도록 허용하지 않습니다. 하지만 조각화와 같은 오버헤드, 복제 버퍼, EVAL과 같은 비용이 높은 명령어의 경우 메모리 사용량이 이 한도를 초과할 수 있습니다. 이러한 경우에는 메모리 압력이 감소할 때까지 Memorystore에서 쓰기가 실패합니다. 자세한 내용은 메모리 관리 권장사항을 참조하세요.

내보내기 또는 전체 동기화 복제로 인해 Memorystore에서 BGSAVE 작업이 수행되고 OOM 상태가 발생하는 경우, 하위 프로세스가 종료됩니다. 이 경우 BGSAVE 작업이 실패하고 Redis 노드 서버가 사용 가능한 상태로 유지됩니다.

모든 상황에서 복제 및 스냅샷 만들기를 보장하기 위해서는 내보내기, 확장 등 중요한 작업 중 메모리 사용률을 50% 미만으로 유지하는 것이 좋습니다. 이러한 작업의 성능 영향을 보기 위해서는 내보내기 또는 장애 조치를 수동으로 트리거할 수 있습니다.

CPU 관리

Memorystore는 각 노드의 CPU 사용량 및 연결 개수에 대해 측정항목을 제공합니다. 단일 가용성 영역 손실이 허용되도록 오버헤드를 충분히 할당하는 것이 좋습니다. 즉, 복제본의 CPU 사용률을 50% 미만으로 유지해야 합니다. 이렇게 하면 3개 영역 중 하나를 사용할 수 없더라도 남은 복제본이 75%로 실행됩니다.

클라이언트 사용 패턴이 불균형적이거나 장애 조치 작업으로 인해 연결이 불균형적으로 배포될 경우 개별 노드에서 사용량이 높아질 수 있습니다. 이 경우에는 Memorystore가 연결을 자동으로 다시 균형적으로 조정하도록 연결을 주기적으로 닫는 것이 좋습니다. Memorystore는 열려 있는 연결을 다시 균형적으로 조정하지 않습니다.

연결 균형 관리

노드 연결이 닫힐 때마다 선택한 클라이언트 라이브러리에서 자동 다시 연결을 사용 설정하여 클라이언트가 다시 연결되어야 합니다. 노드가 다시 사용될 때 기존 연결이 다시 라우팅되지 않지만, 새 연결은 새 노드로 라우팅됩니다. 클라이언트는 사용 가능한 노드 간에 균형적으로 조정되도록 연결을 주기적으로 종료할 수 있습니다.

복제 지연 관리

특히 쓰기 속도가 너무 높으면 복제본 지연이 높아질 수 있습니다. 이러한 시나리오에서는 복제본이 계속 읽기 작업에 제공됩니다. 이 경우 복제본에서 읽기가 오래 될 수 있고 애플리케이션이 이를 처리할 수 있어야 하거나 높은 쓰기 속도를 해결해야 합니다.

다음 단계