ElastiCache for Redis 크기 조정 시 가동 중지 시간을 최소화하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2022년 7월 19일

Amazon ElastiCache for Redis의 크기를 조정하는 동안 가동 중지 시간을 최소화하고 싶습니다. 어떻게 해야 합니까?

해결 방법

가동 중지 시간을 최소화하려면 다음 사항을 고려하십시오.

  • 동기화의 영향을 최소화하려면 워크로드 양이 많을 때 크기 조정을 수행하지 마십시오. 클러스터의 워크로드 양이 많고, 크기 조정에 시간이 오래 소요되는 경우, Redis 수신 요청을 줄여 동기화 실패를 예방하십시오. 크기 조정 프로세스 중에 동기화(백그라운드 저장, 포크 또는 포크리스)가 트리거될 수 있습니다. 동기화는 컴퓨팅 집약적인 작업이며, 추가 메모리를 사용합니다. 동기화 발생 시점을 확인하려면 Amazon CloudWatch에서 SaveInProgress 메트릭을 확인하십시오. 이 메트릭이 1분마다 데이터를 수집한다는 점에 유의하십시오. 이로 인해 메트릭이 1분 이내에 완료된 동기화를 포함하지 않을 수 있습니다. 모니터링 워크로드에 대한 자세한 내용은 Amazon CloudWatch를 사용하여 Amazon ElastiCache for Redis로 모범 사례 모니터링을 참조하십시오.
  • 크기 조정 유형에 따라 새 노드를 결합하거나, 클러스터에서 노드가 제거되거나, 또는 조정 중에 노드의 IP가 변경될 수 있습니다. Amazon ElastiCache for Redis는 클러스터에 연결하기 위한 다양한 유형의 연결 엔드포인트를 제공합니다. 연결 엔드포인트 유형 선택은 애플리케이션 요구 사항에 따라 다릅니다. Redis 클러스터를 연결하는 동안 클라이언트 측 구성 오류로 인해 발생하는 예기치 않은 문제를 식별하기 위해 비프로덕션 환경에서 스케일 인을 테스트하는 것이 제일 좋습니다.
  • 클라이언트가 동기화 진행 중인 새 복제본에 연결하는 경우 LOADING: Redis가 데이터 세트를 메모리에 로드하고 있습니다 오류가 나타납니다. 다른 복제본에서 쿼리를 다시 시도하거나 프라이머리 노드로 쿼리를 보내도록 Redis 클라이언트 또는 애플리케이션 코드를 구성합니다. 데이터 세트 로드에 소요되는 시간은 노드의 데이터 크기 및 성능에 따라 달라집니다. 테스트 환경에서 테스트하여 문제가 발생할 수 있는지 확인합니다.
  • 수동으로 조정하는 대신 클러스터를 크기를 자동으로 조정하도록 구성할 수 있습니다. 자동 크기 조정은 수신되는 워크로드의 갑작스러운 증가로 인한 성능 문제를 방지합니다. 자세한 내용은 ElastiCache for Redis 클러스터 자동 크기 조정을 참조하십시오.

크기 조정 작업 가동 중지 시간 개요

네 가지의 크기 조정 작업은 다음과 같습니다.

  • 스케일 인합니다.
  • 스케일 아웃합니다.
  • 노드 유형을 변경합니다.
  • 노드 그룹 수를 변경합니다. 이는 Redis(클러스터 모드 비활성화) 클러스터에서만 지원됩니다.

자세한 내용은 ElastiCache for Redis 클러스터 크기 조정을 참조하십시오.

일반적으로 크기 조정 작업 및 클러스터 구성에 따라 크기 조정 가동 중지 시간은 최대 몇 초가 소요될 수 있습니다. 다음은 각 클러스터 유형 및 조정 작업에 대한 가동 중지 시간에 관련된 설명입니다.

Redis(클러스터 모드 비활성화) 클러스터

스케일 인: 스케일 인하면 클러스터에서 복제본 노드가 제거됩니다. 이러면 비용을 줄일 수 있습니다. 스케일 인을 수행하면 데이터 내구성도 저하된다는 점에 유의하십시오. 애플리케이션이 기본 엔드포인트만 사용하여 클러스터에 연결하는 경우, 복제본 노드를 제거해도 가동 중지 시간이 발생하지 않습니다. 이는 기본 엔드포인트가 프라이머리 노드를 가리키기 때문입니다.

그러나 애플리케이션이 리더 엔드포인트 또는 개별 엔드포인트를 사용하여 해당 복제본 노드에 연결하는 경우에는 제거한 복제본 노드와의 기존 연결이 끊어지고, 애플리케이션은 다른 복제본 노드에 대한 새 TCP 연결을 설정해야 합니다. 또한 애플리케이션은 제거된 복제본 노드에 연결하지 않도록 DNS 조회를 다시 수행해야 합니다. 클라이언트가 리더 엔드포인트를 사용하는 경우 리더 엔드포인트의 DNS 전파로 몇 초 간 가동 중지 시간이 발생할 수 있습니다.

스케일 아웃: 스케일 아웃하면 기존 클러스터에 복제본 노드가 추가됩니다. 프라이머리 노드가 새 노드와 동기화됩니다. 동기화 중 가동 중지 시간이 발생하지 않도록 예방하려면, 워크로드가 최소인 시간 동안 스케일 아웃하는 것이 좋습니다.

노드 유형 변경: 노드 유형을 변경하면 지정된 유형의 새 노드가 생성됩니다. 이전 프라이머리 노드는 새 프라이머리 노드와 동기화되고 새 프라이머리 노드는 새 복제본 노드와 동기화됩니다. 이 크기 조정 프로세스 중에 다음을 확인하십시오.

  • 워크로드가 너무 높지 않아 동기화가 실패합니다.
  • 새 노드의 IP는 이전 노드와 다를 수 있습니다. 애플리케이션이 프라이머리 엔드포인트 또는 리더 엔드포인트에서 DNS 조회를 다시 수행하고, 새 노드에 대한 새 연결을 설정해야 할 수도 있습니다. DNS 전파에는 몇 초 정도 소요되므로, 클라이언트가 새 노드에 도달하기 전에 서비스가 중단될 수 있습니다.
    Redis 버전 5.0.5 이상에서는 중단이 최소화됩니다. Redis 클라이언트는 이전 노드의 종료로 인해 요청이 실패한 경우 새 노드에 대한 요청을 재시도합니다. ElastiCache 서비스의 최적화를 활용하려면 새 Redis 버전으로 업그레이드하는 것이 모범 사례입니다.

Redis (클러스터 모드 활성화) 클러스터

스케일 인: 스케일 인은 클러스터에서 샤드를 제거하는 것을 의미합니다. 샤드가 제거되기 전에 해당 샤드의 데이터가 다른 노드로 마이그레이션됩니다. 이 프로세스를 "리샤딩"이라고 합니다. 리샤딩은 클러스터에 추가 워크로드를 발생시키고, 클라이언트는 Redis 클러스터를 지원해야 합니다. 스케일 인 중 가동 중지 시간을 최소화하는 방법에 대한 자세한 내용은 모범 사례: 온라인 클러스터 크기 조정을 참조하십시오.

과도한 스케일 인으로 인한 성능 문제를 최소화하려면 점진적으로 조정하는 것이 좋습니다. 예를 들어 대상이 샤드 12개에서 샤드 6개로 스케일 인한다면, 우선 샤드 12개에서 샤드 9개로 스케일 인합니다. 초기 스케일 인 후 피크 시간대에 클러스터의 성능을 확인하고, 그런 다음 추가 스케일 인을 수행합니다.

스케일 아웃: 스케일아웃은 클러스터에 샤드를 추가합니다. 다른 샤드의 분할된 데이터는 새로운 샤드로 마이그레이션됩니다. 이 프로세스를 "리샤딩"이라고 합니다. 리샤딩은 클러스터에 추가 워크로드를 발생시키고, 클라이언트는 Redis 클러스터를 지원해야 합니다. 스케일 아웃 중 가동 중지 시간을 최소화하는 방법에 대한 자세한 내용은 모범 사례: 온라인 클러스터 크기 조정을 참조하십시오.

노드 유형 변경: "노드 유형 변경" 중에, 각 샤드에 대하여 이전의 프라이머리 노드가 새 프라이머리 노드와 동기화됩니다. 그런 다음 새 프라이머리 노드가 새 복제본 노드와 동기화됩니다. 이 크기 조정 프로세스 중에 다음을 확인하십시오.

  • 워크로드가 너무 높지 않아 동기화가 실패합니다.
  • 새 노드의 IP는 이전 노드와 다를 수 있습니다. IP 주소를 확인하기 위해 애플리케이션은 클러스터 노드 또는 클러스터 슬롯 명령을 사용해 클러스터에서 업데이트된 토폴로지 정보를 가져올 수 있습니다. Redis 클러스터를 지원하는 대부분의 Redis 클라이언트는 클러스터의 토폴로지를 업데이트할 수 있습니다. 하지만 이를 수행하기 위해 Redis 클라이언트를 구성해야 할 수 있습니다. Redis 클라이언트 구성 방법에 대한 자세한 내용은 특정 클라이언트 유형에 대한 설명서를 참조하십시오.

노드 그룹 수 변경: 노드 그룹 수를 변경하면 각 샤드의 복제본 노드 수가 변경됩니다. 복제본 노드 수가 증가하면 새 복제본 노드가 클러스터에 결합되며, 프라이머리 노드가 새 노드와 동기화됩니다. 따라서 추가 복제본 노드를 추가하기 전에 프라이머리 노드의 성능을 확인하십시오. 복제본 노드 수가 감소하고, 클라이언트가 제거된 복제본 노드의 내용을 읽어야 하는 경우, 새 복제본 노드 중 하나로 요청을 보내야 합니다. 또한 클라이언트는 제거된 노드로 추가 요청이 전송되지 않도록 클러스터의 토폴로지를 업데이트해야 합니다.