노드 크기 선택

클러스터에 대해 선택하는 노드 크기는 비용, 성능, 내결함성에 영향을 미칩니다.

노드 크기 선택

Graviton 프로세서의 이점에 대한 자세한 내용은 AWS  Graviton 프로세서를 참조하세요.

다음 질문에 답하면 Redis OSS 구현에 필요한 최소 노드 유형을 결정하는 데 도움이 될 수 있습니다.

• 여러 클라이언트 연결을 사용하는 처리량 제한 워크로드를 기대하십니까?

  이 경우 Redis OSS 버전 5.0.6 이상을 실행하는 경우 Redis OSS 엔진 대신 사용 가능한 CPU를 사용하여 클라이언트 연결을 오프로드하는 경우 향상된 I/O 기능을 통해 처리량과 지연 시간을 개선할 수 있습니다. Redis OSS 버전 7.0.4 이상을 실행하는 경우 향상된 I/O 멀티플렉싱과 함께 향상된 I/O 멀티플렉싱을 통해 추가 가속을 얻을 수 있습니다. 이 멀티플렉싱은 각 전용 네트워크 IO 스레드가 여러 클라이언트의 명령을 Redis OSS 엔진으로 파이프라인하여 명령을 일괄적으로 효율적으로 처리하는 Redis의 기능을 활용합니다. Redis OSS v7.1 이상에서는 ElastiCache 프레젠테이션 계층 로직도 처리하도록 향상된 I/O 스레드 기능을 확장했습니다. 프레젠테이션 계층이란 이제 향상된 I/O 스레드가 클라이언트 입력을 읽을 뿐만 아니라 입력을 Redis OSS 바이너리 명령 형식으로 파싱한 다음 기본 스레드로 전달되어 실행되므로 성능이 향상된다는 의미입니다. 자세한 내용은 블로그 게시물과 지원되는 버전 페이지를 참조하세요.

• 소량의 데이터에 정기적으로 액세스하는 워크로드가 있나요?

  이 경우 Redis OSS 엔진 버전 6.2 이상에서 실행 중인 경우 r6gd 노드 유형을 선택하여 데이터 계층화를 활용할 수 있습니다. 데이터 계층화를 사용하면 최소최근사용 데이터가 SSD에 저장됩니다. 검색 시 대기 시간 비용이 적게 들고 비용 절감으로 균형을 이룹니다. 자세한 정보는 데이터 계층화을 참조하세요.

  자세한 정보는 지원되는 노드 유형을 참조하세요.

• 데이터에 필요한 총 메모리는 얼마나 됩니까?

  일반적인 에상치를 알아보려면 캐시할 항목의 크기를 선택합니다. 이 크기를 동시에 캐시에 보관할 항목 수로 곱합니다. 적당한 항목 크기 예상치를 구하고 캐시 항목을 직렬화한 후 문자 수를 계산합니다. 그런 다음 클러스터에 있는 샤드의 수에 대해 이를 나눕니다.

  자세한 정보는 지원되는 노드 유형을 참조하세요.

• 실행 중인 Redis OSS 버전은 무엇입니까?

  2.8.22 이전의 Redis OSS 버전에서는 장애 조치, 스냅샷, 동기화 및 복제본을 기본 작업으로 승격하기 위해 더 많은 메모리를 예약해야 합니다. 프로세스 중에 발생하는 모든 쓰기에 충분한 메모리를 사용할 수 있어야 하기 때문입니다.

  Redis OSS 버전 2.8.22 이상에서는 이전 프로세스보다 사용 가능한 메모리가 덜 필요한 포크 없는 저장 프로세스를 사용합니다.

  자세한 내용은 다음 자료를 참조하십시오.

  • 동기화 및 백업 구현 방법

  • Redis OSS 스냅샷을 생성할 수 있는 충분한 메모리가 있는지 확인

• 애플리케이션의 쓰기 작업이 얼마나 많습니까?

  쓰기 작업이 많은 애플리케이션에서는 스냅샷을 만들거나 장애 조치를 할 때 데이터에 사용되지 않으며 사용할 수 있는 메모리가 훨씬 더 많이 필요할 수 있습니다. BGSAVE 프로세스가 수행될 때마다 BGSAVE 프로세스 중에 발생하는 모든 쓰기를 수용할 수 있도록 데이터가 사용하지 않는 메모리가 충분해야 합니다. 예로는 스냅샷을 만들 때, 클러스터의 복제본과 기본 클러스터를 동기화할 때, AOF(append-only file) 기능을 활성화할 때 등이 있습니다. 또 다른 예로는 복제본을 기본으로 승격하는 경우입니다(활성화된 다중 AZ가 있는 경우). 최악의 경우는 프로세스 중에 모든 데이터가 다시 작성되는 경우입니다. 이 경우 데이터에만 필요한 메모리의 두 배가 되는 노드 인스턴스 크기가 필요합니다.

  더 자세한 내용은 Redis OSS 스냅샷을 생성할 수 있는 충분한 메모리가 있는지 확인 섹션을 참조하세요.

• 독립 실행형 Redis OSS (클러스터 모드 비활성화) 클러스터 또는 여러 샤드가 있는 Redis OSS (클러스터 모드 활성화) 클러스터를 구현할 예정입니까?

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

  Redis OSS (클러스터 모드 비활성화) 클러스터를 구현하는 경우 노드 유형은 이전 항목에서 설명한 대로 모든 데이터와 필요한 오버헤드를 수용할 수 있어야 합니다.

  예를 들어, 모든 항목의 총 크기를 12GB로 추정합니다. 이 경우, 메모리가 13.3GB인 cache.m3.xlarge 노드 또는 메모리가 13.5GB인 cache.r3.large 노드를 사용할 수 있습니다. 하지만 BGSAVE 작업에는 메모리가 더 필요할 수 있습니다. 애플리케이션이 쓰기 작업이 많은 경우 메모리 요구 사항을 최소 24GB로 두 배로 늘립니다. 따라서 27.9GB의 메모리가 있는 cache.m3.2xlarge 또는 30.5GB의 메모리가 있는 cache.r3.xlarge를 사용합니다.

  샤드가 여러 개 있는 Redis OSS (클러스터 모드 사용)

  여러 샤드가 있는 Redis OSS (클러스터 모드 활성화) 클러스터를 구현하는 경우 노드 유형이 바이트의 데이터를 수용할 수 있어야 합니다. bytes-for-data-and-overhead / number-of-shards

  예를 들어, 모든 항목의 총 크기를 12GB로 추정하고 샤드가 2개입니다. 이 경우, 메모리가 6.05GB인 cache.m3.large 노드를 사용할 수 있습니다(12GB/2). 하지만 BGSAVE 작업에는 메모리가 더 필요할 수 있습니다. 애플리케이션이 쓰기 작업이 많은 경우 메모리 요구 사항을 최소 샤드당 12GB로 두 배로 늘립니다. 따라서 13.3GB의 메모리가 있는 cache.m3.xlarge 또는 13.5GB의 메모리가 있는 cache.r3.large를 사용합니다.

• Local Zones를 사용하고 있습니까?

  Local Zones를 사용하면 ElastiCache 클러스터와 같은 리소스를 사용자와 가까운 여러 위치에 배치할 수 있습니다. 그러나 노드 크기를 선택할 때 사용 가능한 노드 크기는 용량 요구 사항에 관계없이 현재 다음과 같이 제한된다는 것에 주의하세요.

  • 현재 세대:

    M5 노드 유형: cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

    R5 노드 유형: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

    T3 노드 유형: cache.t3.micro, cache.t3.small, cache.t3.medium

클러스터가 실행되는 동안 게시되는 메모리 사용량, 프로세서 사용률, 캐시 적중률 및 캐시 실패 지표를 모니터링할 CloudWatch 수 있습니다. 클러스터의 적중률이 기대에 미치지 못하거나 키가 너무 자주 제거되고 있음을 알 수 있습니다. 이러한 경우 CPU 및 메모리 사양이 더 큰 다른 노드 크기를 선택할 수 있습니다.

CPU 사용량을 모니터링할 때는 Redis OSS가 단일 스레드라는 점을 기억하십시오. 따라서 보고된 CPU 사용량을 CPU 코어 수에 곱하면 실제 사용량을 확인할 수 있습니다. 예를 들어 사용률이 20% 라고 보고한 4코어 CPU는 실제로 Redis OSS가 80% 사용률로 실행되는 1코어 CPU와 같습니다.