노드 크기 선택

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

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

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

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

자세한 내용은 지원되는 노드 유형 단원을 참조하십시오.

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

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

자세한 내용은 지원되는 노드 유형 단원을 참조하십시오.

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

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

Redis OSS 버전 2.8.22 이상에서는 이전 프로세스에 비해 사용 가능한 메모리가 더 적게 필요한 forkless 저장 프로세스가 사용됩니다.

자세한 내용은 다음 자료를 참조하세요.

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

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

더 자세한 내용은 충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성 섹션을 참조하세요.

구현 애플리케이션이 독립 실행형 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터입니까, 아니면 샤드가 여러 개인 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터입니까?

Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터

Valkey 또는 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를 사용합니다.

샤드가 여러 개인 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)

샤드가 여러 개인 Valkey 또는 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 클러스터와 같은 리소스를 배치할 수 있습니다. 그러나 노드 크기를 선택할 때 사용 가능한 노드 크기는 용량 요구 사항에 관계없이 현재 다음과 같이 제한된다는 것에 주의하세요.

메모리 3.22GB인 cache.t2.medium 노드 11개에 스레드가 각각 2개이면 35.42GB, 스레드 22개와 같습니다.

메모리 6.42GB인 cache.m4.large 노드 6개에 스레드가 각각 2개이면 38.52GB, 스레드 12개와 같습니다.

메모리 12.3GB인 cache.r4.large 노드 3개에 스레드가 각각 2개이면 36.90GB, 스레드 6개와 같습니다.

메모리 14.28GB인 cache.m4.xlarge 노드 3개에 스레드가 각각 4개이면 42.84GB, 스레드 12개와 같습니다.