노드 크기 선택

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

노드 크기(Valkey 및 RedisOSS)

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

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

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

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

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

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

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

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

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

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

• 어떤 버전의 RedisOSS를 실행하고 있습니까?

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

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

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

  • 동기화 및 백업 구현 방법

  • Valkey 또는 Redis OSS 스냅샷을 생성하기에 충분한 메모리 확보

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

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

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

• 구현이 독립 실행형 Valkey 또는 RedisOSS(클러스터 모드 비활성화됨) 클러스터이거나 여러 개의 샤드가 있는 Valkey 또는 RedisOSS(클러스터 모드 활성화됨) 클러스터입니까?

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

  Valkey 또는 RedisOSS(클러스터 모드 비활성화됨) 클러스터를 구현하는 경우 이전 글머리 기호에 설명된 대로 노드 유형이 모든 데이터와 필요한 오버헤드를 수용할 수 있어야 합니다.

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

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

  샤드가 여러 개인 Valkey 또는 RedisOSS(클러스터 모드 활성화됨) 클러스터를 구현하는 경우 노드 유형이 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를 사용하고 있습니까?

  로컬 영역을 사용하면 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 사용량을 모니터링할 때 Valkey와 RedisOSS는 단일 스레드임을 기억하세요. 따라서 보고된 CPU 사용량에 CPU 코어 수를 곱하여 실제 사용량을 구합니다. 예를 들어 20% 사용률을 CPU 보고하는 4개 코어는 실제로 1개 코어 Redis가 80% 사용률로 실행OSS되고 있습니다.

노드 크기(Memcached)

Memcached 클러스터에는 여러 노드로 분할된 클러스터 데이터와 한 개 이상의 노드가 포함되어 있습니다. 클러스터의 메모리 요구와 노드의 메모리가 서로 관련은 있지만 동일하지는 않습니다. 큰 노드 두세 개나 작은 노드 여러 개를 두어 필요한 클러스터 메모리 용량을 확보할 수 있습니다. 또한 요구량이 달라지면 클러스터에서 노드를 추가하거나 제거하여 필요한 만큼만 비용을 지불할 수 있습니다.

클러스터의 총 메모리 용량은 시스템 오버헤드를 공제한 후 클러스터의 노드 수에 각 노드의 RAM 용량을 곱하여 계산됩니다. 각 노드의 용량은 노드 유형에 따라 다릅니다.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

클러스터의 노드 수는 Memcached를 실행하는 클러스터의 가용성을 결정하는 핵심 요인입니다. 단일 노드의 오류는 애플리케이션 가용성과 백엔드 데이터베이스에 대한 로드에 영향을 미칠 수 있습니다. 이 경우 ElastiCache는 실패한 노드에 대한 대체를 프로비저닝하고 다시 채워집니다. 이러한 가용성 영향을 줄이려면 적은 수의 대용량 노드를 사용하는 대신 더 적은 용량의 더 여러 개의 노드로 메모리 및 컴퓨팅 용량을 분산해야 합니다.

캐시 메모리가 35GB인 시나리오에서 다음과 같은 구성으로 설정할 수 있습니다.

• 메모리 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개와 같습니다.

노드 옵션 비교

노드 유형	메모리(GB)	코어	시간당 비용*	필요한 노드	총 메모리(GiB)	총 코어	월별 비용
cache.t2.medium	3.22	2	0.068 USD	11	35.42	22	538.56 USD
cache.m4.large	6.42	2	0.156 USD	6	38.52	12	673.92 USD
cache.m4.xlarge	14.28	4	0.311 USD	3	42.84	12	671.76 USD
cache.m5.xlarge	12.93	4	0.311 USD	3	38.81	12	671.76 USD
cache.m6g.large	6.85	2	$ 0.147	6	41.1	12	$635
cache.r4.large	12.3	2	0.228 USD	3	36.9	6	492.48 USD
cache.r5.large	13.07	2	0.216 USD	3	39.22	6	466.56 USD
cache.r6g.large	13.07	2	$ 0.205	3	42.12	6	$442
* 2020년 10월 8일 기준 각 노드의 시간당 비용
† 30일간(720시간) 사용량 100%의 월별 비용

여기에 나와 있는 옵션은 각각 비슷한 메모리 용량을 제공하지만 컴퓨팅 용량과 비용은 다릅니다. 특정 옵션의 비용을 비교하려면 Amazon ElastiCache 요금 섹션을 참조하세요.

Memcached를 실행하는 클러스터의 경우 각 노드의 사용 가능한 메모리 일부가 연결 오버헤드에 사용됩니다. 자세한 내용은 Memcached 연결 오버헤드 섹션을 참조하세요.

여러 노드를 사용하면 노드에 키를 분산시켜야 합니다. 노드마다 고유한 엔드포인트가 있습니다. 엔드포인트를 쉽게 관리하기 위해 ElastiCache Auto Discovery 기능을 사용할 수 있습니다. 이 기능을 사용하면 클라이언트 프로그램이 클러스터의 모든 노드를 자동으로 식별할 수 있습니다. 자세한 내용은 클러스터의 노드 자동 식별(Memcached) 단원을 참조하십시오.

경우에 따라 얼마나 많은 용량이 필요한지 확신할 수 없을 수도 있습니다. 그렇다면, 테스트를 위해 1개의 cache.m5.large 노드를 사용하는 것이 좋습니다. 그런 다음 Amazon 에 게시된 ElastiCache 지표를 사용하여 메모리 사용량, CPU 사용률 및 캐시 적중률을 모니터링합니다 CloudWatch. 의 CloudWatch 지표에 대한 자세한 내용은 섹션을 ElastiCache참조하세요 CloudWatch 지표 사용 모니터링. 프로덕션 및 대규모 워크로드의 경우 R5 노드는 최상의 성능과 RAM 비용 가치를 제공합니다.

클러스터의 적중률이 기대에 미치지 못하면 간편하게 노드를 더 추가하여 클러스터의 총 가용 메모리를 늘릴 수 있습니다.

클러스터에 바인딩되어 CPU 있지만 적중률이 충분한 경우 더 많은 컴퓨팅 성능을 제공하는 노드 유형을 사용하여 새 클러스터를 설정합니다.