기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 노드 크기 선택
ElastiCache 클러스터에 대해 선택하는 노드 크기는 비용, 성능, 내결함성에 영향을 미칩니다.
## 노드 크기(Valkey 및 Redis OSS)
Graviton 프로세서의 이점에 대한 자세한 내용은 [AWS Graviton 프로세서](https://aws.amazon.com/pm/ec2-graviton/)를 참조하세요.
다음 질문의 답을 생각해 보면 Valkey 또는 Redis OSS 구현에 필요한 최소한의 노드 유형을 결정하는 데 도움이 될 수 있습니다.
+ 여러 클라이언트 연결을 사용하는 처리량 제한 워크로드를 기대하십니까?
그렇다면 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의 기능을 활용합니다. Redis OSS v7.1 이상의 ElastiCache에서는 프레젠테이션 계층 로직도 처리하도록 향상된 I/O 스레드 기능을 확장했습니다. 프레젠테이션 계층이란 이제 향상된 I/O 스레드가 클라이언트 입력을 읽을 뿐만 아니라 입력을 Redis OSS 바이너리 명령 형식으로 구문 분석한 다음, 실행을 위해 기본 스레드로 전달되므로 성능이 향상된다는 의미입니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/)과 [지원되는 버전](VersionManagement.md#supported-engine-versions) 페이지를 참조하세요.
+ 소량의 데이터에 정기적으로 액세스하는 워크로드가 있나요?
이 경우라면 Redis OSS 엔진 버전 6.2 이상에서 실행 중인 경우 r6gd 노드 유형을 선택하여 데이터 계층화를 활용할 수 있습니다. 데이터 계층화를 사용하면 최소최근사용 데이터가 SSD에 저장됩니다. 검색 시 대기 시간 비용이 적게 들고 비용 절감으로 균형을 이룹니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
자세한 내용은 [지원되는 노드 유형](CacheNodes.SupportedTypes.md) 섹션을 참조하세요.
+ 데이터에 필요한 총 메모리는 얼마나 됩니까?
일반적인 에상치를 알아보려면 캐시할 항목의 크기를 선택합니다. 이 크기를 동시에 캐시에 보관할 항목 수로 곱합니다. 적당한 항목 크기 예상치를 구하고 캐시 항목을 직렬화한 후 문자 수를 계산합니다. 그런 다음 클러스터에 있는 샤드의 수에 대해 이를 나눕니다.
자세한 내용은 [지원되는 노드 유형](CacheNodes.SupportedTypes.md) 섹션을 참조하세요.
+ 실행 중인 Redis OSS 버전은 무엇입니까?
2.8.22 이전의 Redis OSS 버전에서는 장애 조치, 스냅샷, 동기화, 기본 작업으로 복제본 승격을 위해 더 많은 메모리를 확보해야 합니다. 프로세스 중에 발생하는 모든 쓰기에 충분한 메모리를 사용할 수 있어야 하기 때문입니다.
Redis OSS 버전 2.8.22 이상에서는 이전 프로세스에 비해 사용 가능한 메모리가 더 적게 필요한 forkless 저장 프로세스가 사용됩니다.
자세한 내용은 다음 자료를 참조하세요.
+ [동기화 및 백업 구현 방법](Replication.Redis.Versions.md)
+ [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)
+ 애플리케이션의 쓰기 작업이 얼마나 많습니까?
쓰기 작업이 많은 애플리케이션에서는 스냅샷을 만들거나 장애 조치를 할 때 데이터에 사용되지 않으며 사용할 수 있는 메모리가 훨씬 더 많이 필요할 수 있습니다. `BGSAVE` 프로세스가 수행될 때마다 `BGSAVE` 프로세스 중에 발생하는 모든 쓰기를 수용할 수 있도록 데이터가 사용하지 않는 메모리가 충분해야 합니다. 예로는 스냅샷을 만들 때, 클러스터의 복제본과 기본 클러스터를 동기화할 때, AOF(append-only file) 기능을 활성화할 때 등이 있습니다. 또 다른 예로는 복제본을 기본으로 승격하는 경우입니다(활성화된 다중 AZ가 있는 경우). 최악의 경우는 프로세스 중에 모든 데이터가 다시 작성되는 경우입니다. 이 경우 데이터에만 필요한 메모리의 두 배가 되는 노드 인스턴스 크기가 필요합니다.
더 자세한 내용은 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md) 섹션을 참조하세요.
+ 구현 애플리케이션이 독립 실행형 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](Local_zones.md)를 사용하면 사용자에게 가까운 여러 위치에서 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 또는 Redis OSS는 단일 스레드입니다. 따라서 보고된 CPU 사용량을 CPU 코어 수에 곱하면 실제 사용량을 확인할 수 있습니다. 예를 들어, 사용률 20%로 보고된 4 코어 CPU는 실제로 코어 1개인 Redis OSS가 80% 사용률로 실행되는 것입니다.
## 노드 크기(Memcached)
Memcached 클러스터에는 여러 노드로 분할된 클러스터 데이터와 한 개 이상의 노드가 포함되어 있습니다. 클러스터의 메모리 요구와 노드의 메모리가 서로 관련은 있지만 동일하지는 않습니다. 큰 노드 두세 개나 작은 노드 여러 개를 두어 필요한 클러스터 메모리 용량을 확보할 수 있습니다. 또한 요구량이 달라지면 클러스터에서 노드를 추가하거나 제거하여 필요한 만큼만 비용을 지불할 수 있습니다.
클러스터의 총 메모리 용량은 시스템 오버헤드를 뺀 각 노드의 RAM 용량을 클러스터에 있는 노드 수에 곱하는 방식으로 계산됩니다. 각 노드의 용량은 노드 유형에 따라 다릅니다.
```
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)
```
클러스터의 노드 수는 Memcached를 실행하는 클러스터의 가용성을 결정하는 핵심 요인입니다. 단일 노드의 오류는 애플리케이션 가용성과 백엔드 데이터베이스에 대한 로드에 영향을 미칠 수 있습니다. 이러한 경우, ElastiCache가 오류 캐시 노드를 대체하기 위해 프로비저닝하고 다시 채워집니다. 이러한 가용성 영향을 줄이려면 적은 수의 대용량 노드를 사용하는 대신 더 적은 용량의 더 여러 개의 노드로 메모리 및 컴퓨팅 용량을 분산해야 합니다.
캐시 메모리가 35GB인 시나리오에서 다음과 같은 구성으로 설정할 수 있습니다.
+ `cache.t2.medium`메모리 3.22GB인 노드 11개에 스레드가 각각 2개이면 35.42GB, 스레드 22개와 같습니다.
+ `cache.m4.large`메모리 6.42GB인 노드 6개에 스레드가 각각 2개이면 38.52GB, 스레드 12개와 같습니다.
+ `cache.r4.large`메모리 12.3GB인 노드 3개에 스레드가 각각 2개이면 36.90GB, 스레드 6개와 같습니다.
+ `cache.m4.xlarge`메모리 14.28GB인 노드 3개에 스레드가 각각 4개이면 42.84GB, 스레드 12개와 같습니다.
**노드 옵션 비교**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/CacheNodes.SelectSize.html)
여기에 나와 있는 옵션은 각각 비슷한 메모리 용량을 제공하지만 컴퓨팅 용량과 비용은 다릅니다. 옵션별 비용을 비교하려면 [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/)을 참조하세요.
Memcached를 실행하는 클러스터의 경우 각 노드의 사용 가능한 메모리 일부가 연결 오버헤드에 사용됩니다. 자세한 내용은 [Memcached 연결 오버헤드](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead) 섹션을 참조하세요.
여러 노드를 사용하면 노드에 키를 분산시켜야 합니다. 노드마다 고유한 엔드포인트가 있습니다. ElastiCache Auto Discovery 기능을 사용하면 클라이언트 프로그램이 클러스터의 모든 노드를 자동으로 식별하여 엔드포인트를 쉽게 관리할 수 있습니다. 자세한 내용은 [클러스터의 노드 자동 식별(Memcached)](AutoDiscovery.md) 섹션을 참조하세요.
경우에 따라 얼마나 많은 용량이 필요한지 확신할 수 없을 수도 있습니다. 그렇다면, 테스트를 위해 1개의 `cache.m5.large` 노드를 사용하는 것이 좋습니다. 그런 다음 Amazon CloudWatch에 게시된 ElastiCache 지표를 사용하여 메모리 사용량, CPU 사용률 및 캐시 적중률을 모니터링합니다. ElastiCache용 CloudWatch 지표에 대한 자세한 내용은 [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md) 섹션을 참조하세요. 프로덕션 및 대규모 워크로드에는 R5 노드의 성능과 RAM 비용 가치가 가장 우수합니다.
클러스터의 적중률이 기대에 미치지 못하면 간편하게 노드를 더 추가하여 클러스터의 총 가용 메모리를 늘릴 수 있습니다.
클러스터가 CPU의 제약을 받지만 적중률은 충분할 경우 컴퓨팅 파워가 더 큰 노드 유형으로 새로운 클러스터를 설정해 보십시오.