BLOG
본 게시물에서는 Amazon ElastiCache 워크로드에 적합한 노드 크기 및 클러스터 토폴로지 결정 프로세스와 중요한 고려 사항에 대해 설명해드리도록 하겠습니다. 이 게시물에서는 독자가 Redis 및 해당 명령에 대해 잘 알고 있으며 online cluster resizing, scaling, online migration from Amazon EC2 to ElastiCache, general-purpose and memory-optimized nodes 및 enhanced I/O와 같은 Amazon ElastiCache for Redis와 이 기능에 대한 이해도가 있다고 가정합니다.
기준 권장 사항
입문의 경우, 소규모 (2,000 이하의 TPS 및 10GB 이하의 데이터 크기) 및 중간 규모 (TPS 2,000-20,000 사이의 데이터 크기 및 10GB-100GB의 데이터 크기) 캐시 워크로드 (임시 스파이크가 발생할 수도 있는 캐시 워크로드 포함) 사용 중인 경우 차세대 범용 버스트 가능 T3- 표준 캐시 노드인 T3 제품군에서 캐시 노드를 선택하세요. 워크로드에 ElastiCache를 사용하기 시작한 경우 프리 티어를 제공하므로 T3.micro 캐시 노드에서 시작하세요. 로드를 늘리면 T3.medium 캐시 노드까지도 가능합니다.
최신 노드 유형이 최신 세대 CPU 및 네트워킹 기능을 지원하므로 중간에서 고급(20,000 TPS 및 100GB 데이터 크기) 워크로드의 경우 M5 또는 R5 제품군에서 캐시 노드를 선택하세요. 이러한 캐시 노드 제품군은 ENA (Elastic Network Adapter) 및 600GiB 이상의 메모리를 기반으로 한 향상된 네트워킹으로 최대 25Gbps의 집계 네트워크 대역폭을 제공 할 수 있습니다. R5 노드 유형은 vCPU 당 5 % 더 많은 메모리를 제공하고 R4 노드 유형보다 GiB 당 10 %의 가격을 제공합니다. 또한 R5 노드 유형은 R4 노드 유형보다 CPU 성능이 약 20 % 향상됩니다.
T3.medium이 부족해지면 다음 중 하나로 이동할 수 있습니다.
- 증가된 메모리로 더 많은 처리량이 필요한 경우 M5 캐시 노드
- 캐시 노드 당 더 많은 처리량과 최대 35 % –51 % 더 높은 메모리가 필요한 경우 R5 캐시 노드
워크로드에 적합한 노드 크기 및 클러스터 토폴로지를 더욱 좁히려면 다음을 수행해야 합니다.
- 5가지 워크로드 특성 결정
- 벤치 마크 테스트 실행
5가지 워크로드 특성 결정
애플리케이션 지표, Redis의 INFO 명령 또는 Amazon CloudWatch 지표를 사용하여 대부분의 워크로드 특성을 확인할 수 있습니다. 최대 노드 메모리에 대한 자세한 정보는 Redis 노드 유형별 매개 변수를 참조하세요.
ElastiCache 노드 요구 사항을 결정할 때는 다음을 고려하세요.
- 기억
- 예비 또는 예약 메모리
- 유효성
- 스케일링
- 데이터
메모리
다음 고려 사항은 잠재적 노드 크기를 식별하는 데 도움이 될 수 있습니다.
- 전체 데이터 저장소 크기, 키 및 값 데이터 크기를 식별하세요. 캐시하려는 항목의 크기에 캐시를 유지하려는 항목 수를 곱하여 필요한 캐시 메모리 크기의 대략적인 추정치를 얻을 수 있습니다.
- 데이터 보존 여부를 결정하거나 TTL을 사용하여 캐시의 키를 만료시키세요. TT은 노드에서 명시적 메모리 관리를 가능하게 합니다.
- 캐시 전용 사용 사례에서와 같이 중요한 메트릭인 경우 기존 및 선호하는 캐시 적중률을 확인하세요. 클러스터 적중률이 기대하는 적중률에 도달하는지와 키가 너무 자주 제거되지 않음을 확인하고자 하실 겁니다. 더 많은 메모리 용량으로 이를 달성할 수 있습니다.
예비 또는 예약 메모리
데이터베이스 크기를 포함하지 않는 한 노드 크기의 25 % 이상을 유지해야 합니다. 복제는 기본 노드의 일부 메모리를 사용합니다. 또한 캐시 노드에는 예상치 못한 로드 피크 및 메모리 사용량 증가에 대한 CloudWatch 경보를 통한 조기 감지를 위해 약 10 % – 15 %의 여유 메모리가 있어야 합니다. 발 빠른 검토를 통해 특정 요구 사항에 따라 스케일 업 또는 스케일 아웃 여부를 결정할 수 있습니다.
쓰기가 많은 응용 프로그램에는 데이터가 사용하지 않는 훨씬 더 많은 사용 가능 메모리가 필요할 수 있습니다. 스냅 샷을 만들거나 복제본 중 하나로 장애 조치할 때 이 스페어 메모리가 필요합니다.
유효성
고객의 요청을 처리하기 위해 클러스터를 사용 가능해야 할 경우 하나의 기본, 최소 두 개의 복제본 및 다중 AZ가 활성화된 복제 그룹 설정을 고려하세요. 이를 통해 데이터를 보호하고 어떤 이유로든 기본 노드가 실패할 경우 클러스터가 계속 트래픽을 처리합니다. 이 경우 복제본 중 하나가 새로운 기본이 됩니다. 복제본은 또한 읽기 처리량을 높이는 데 도움이 될 수 있습니다.
쓰기 대 읽기 비율이 50% 이상이고 해당 노드 유형에 대한 요청 비율 한계의 80%에 가까운 쓰기 기본 노드를 주의하세요. 대량 쓰기 기본 노드는 복제본과 더 자주 전체 동기화를 수행하여 클러스터 성능에 영향을 줄 수 있습니다. 자주 전체 동기화를 수행하면 들어오는 요청을 처리하는 데 사용할 수 있었던 기본 노드 시간이 사라집니다.
또한 가용성을 위해 많은 복제본을 가동하려는 충동에 저항하십시오. 많은 복제본과 동기화하기 위해 기본에 불필요한 스트레스를 발생시킵니다. 기본 노드 당 5개의 복제본이 있습니다. 다른 가용 영역에 있는 하나 또는 두 개의 복제본이 가용성에 충분합니다.
스케일링
ElastiCache는 클러스터가 계속 요청을 처리하는 동안 수직 (up / down) 및 수평 (in / out) 온라인 스케일링을 지원하는 cluster-mode enabled configuration를 제공합니다. 기본 노드에서 여러 동시 클라이언트 (예: 10,000개 클라이언트의 경우 1 TPS 또는 2,000개 클라이언트의 경우 5 TPS 와 같은 10,000개 이상)를 사용하는 경우 모든 서비스를 제공할 수 있는 컴퓨팅 용량이 있는지 확인하는 것이 좋습니다. 기본 노드 당 최적의 동시 클라이언트는 특정 사용 사례 및 전체 애플리케이션 아키텍처에 따라 다릅니다. 많은 수의 동시 클라이언트를 지원하는 것 외에도, 수평 확장은 데이터가 여러 샤드에 분산되어 클러스터의 데이터 가용성을 더욱 향상시킵니다. 그러나 비즈니스가 기존 클러스터 구성에서 더 높은 성능을 요구하는 경우 확장해야 합니다.
두 클러스터 구성 (클러스터 모드 비활성화 및 클러스터 모드 활성화) 간의 마이그레이션은 소스 클러스터의 .rdb 파일을 사용하는 오프라인 작업인 백업 / 복원에서 지원됩니다. 따라서 수직 및 수평 확장이 모두 향후 요구를 충족시킬 수 있으므로 기본적으로 클러스터 모드 사용 구성을 사용해야 합니다.
확장 또는 축소를 통해 클러스터의 크기 및 메모리 용량을 줄이려면 새 구성에 데이터 및 Redis 오버 헤드를 위한 충분한 메모리가 있는지 확인하세요.
데이터
워크로드에 빠른 속도로 요청되거나 갑자기 커지는 하나 이상의 데이터 오브젝트와 같은 단축키가 있는지 확인하세요. 단축키는 캐시 엔진의 성능을 유지하고 모든 요청을 처리하는 기능을 손상시킬 수 있습니다. 이 사용 사례의 경우 권장되는 클러스터 모드 지원 구성을 사용한다고 가정하면 로드를 다양한 샤드에 분산시키고 핫 키를 한 샤드에 보관하고 나머지 키는 다른 샤드에 보관하여 다른 수신 요청이 차단되지 않도록 할 수 있습니다. 여러 개의 단축키가 있는 경우 샤드에 이를 분산시키는 것이 좋습니다.
또한 읽기 및 쓰기 워크로드를 분리하면 응용 프로그램이 증가함에 따라 추가 복제본을 추가하여 읽기를 확장할 수 있습니다. 복제본은 일관된 읽기를 제공합니다. ElastiCache는 클러스터 모드 비활성화 구성에 대한 복제본 엔드 포인트를 제공하여 복제본에서 읽기 트래픽을 로드 밸런싱하여 읽기와 쓰기를 분리할 수 있습니다. 또한 클러스터 모드 지원 구성을 위한 일부 Redis 클라이언트는 트래픽을 복제본으로 라우팅할 수 있습니다. 이 메커니즘에 대한 특정 Redis 클라이언트 설명서를 검토해야 합니다.
벤치 마크 테스트 실행
사례에 적용할 수 있는 매개 변수를 결정한 후 가장 적합한 몇 가지 캐시 노드와 클러스터 토폴로지를 확인해야 합니다. 두 개의 큰 캐시 노드를 선택하는 것이 하나의 xlarge 캐시 노드보다 나을 수도 있고 그렇지 않을 수도 있습니다. 프로덕션 환경과 같은 워크로드 특성으로 클라이언트 애플리케이션을 구성하고 이러한 각 인라인에서 벤치 마크 테스트를 실행하세요. 14 일 이상 프로덕션 데이터 및 트래픽 패턴으로 벤치 마크 테스트를 실행하여 정기적인 프로덕션 워크로드 패턴의 올바른 기준을 생성해야 합니다. 기준이 설정되면 휴일, 블랙 프라이데이 판매와 같은 이벤트성을 워크로드에 포함시켜 실제 워크로드 패턴을 더 자세히 반영하는 성능 벤치 마크 결과를 가져와야 합니다. 벤치 마크 테스트 결과를 바탕으로 Redis 워크로드에 맞는 적절한 노드 사이즈와 클러스터 구성을 선택할 수 있습니다.
ElastiCache 벤치마킹
ElastiCache는 오픈 소스 벤치마킹 도구 rpc-perf및 redis-benchmark을 사용하여 벤치마킹 결과를 발표했습니다. 첫 번째 벤치마킹 실행에서는 R4와 최적화 된 R5 캐시 노드를 비교하며 다음 섹션에서 이에 대해 자세히 설명합니다. 자세한 내용은 Amazon EC2 M5 및 R5 인스턴스의 Amazon ElastiCache 성능 향상을 참고하세요. 두 번째 벤치마킹 방법은 R5 제품군에 있으며 Redis 5.0.3과 향상된 I / O를 향상된 I / O를 제공하지 않는 Redis 5.0.0과 비교합니다. 자세한 내용은 Amazon ElastiCache for Redis로 애플리케이션 성능 향상 및 비용 절감을 참고하세요.
R4와 최적화된 R5 캐시 노드 비교
이 벤치 마크에는 1,470 만 개의 고유 키, 200 바이트 문자열 값, 80 % 가져 오기, 20 % 세트 및 명령 파이프 라이닝이 없었습니다. 이 게시물의 벤치 마크는 동일한 가용 영역의 ElastiCache R5 인스턴스에 연결하는 20 개의 클라이언트 인스턴스에서 실행되었습니다.
다음 표는 벤치 마크 테스트 설정을 요약한 것입니다.
| 워크로드 속성 | 값 |
| 메모리 | 200 바이트 문자열 값 = 2.9GB의 1470만 키
TTL이 없습니다. 키는 [az AZ 0-9] 범위 (62 ** 4 값 = 1,470 만 키)의 값을 가진 4 바이트 임의 문자열입니다. 값은 200 바이트의 비 랜덤 / 재생 문자열입니다. |
| 스페어 메모리 | 5GB; 스냅 샷의 25%를 차지하는 캐시 노드는 2.9 + 5 + 2.7 = 10.5GB 이상이어야 합니다. |
| 유효성 | 복제본이 없는 기본 1 개 |
| 스케일링 | 클러스터 모드가 비활성화
각 테스트에는 20개의 응용 프로그램 노드가 준비되어 있었고 각 응용 프로그램 노드는 노드 유형에 따라 다양한 수의 연결이 가능했습니다. 더 큰 노드의 경우 처리량을 높이기 위해 더 많은 연결이 가능하고 더 작은 노드의 경우 더 적은 연결이 가능합니다. 연결 수는 요청의 p99.9 대기 시간을 크게 늘리지 않고 열 수 있는 연결 수를 기반으로 합니다. |
| 데이터 | 단축키가 없음
20개의 클라이언트 연결 키는 무작위로 생성 |
벤치마킹 결과에 따르면 최신 R5 캐시 노드는 비슷한 크기의 R4 인스턴스보다 초당 59 % ~ 144 % 더 많은 트랜잭션을 지원했습니다. R5 캐시 노드는 또한 평균 (p50) 및 테일 (p99) 대기 시간이 최대 23 % 감소하여 평균 대기 시간이 350 마이크로 초에 불과했습니다. 다음 표는 이 연습의 데이터를 요약한 것입니다.
| 캐시 노드 크기 | ElastiCache R4 노드 | ElastiCache 최적화 R5 노드 | ElastiCache R4에서 최적화 된 R5 개선 |
| large | 88,000 RPS | 215,000 RPS | 144 % |
| xlarge | 93,000 RPS | 207,000 RPS | 122 % |
| 2 xlarge | 107,000 RPS | 217,000 RPS | 102 % |
| 4 xlarge | 131,000 RPS | 225,000 RPS | 71 % |
| 8xlarge / 12xlarge | 128,000 RPS | 247,000 RPS | 92 % |
| 16xlarge / 24xlarge | 149,000 RPS | 237,000 RPS | 59 % |
결론
워크로드에 적합한 노드 크기 및 클러스터 구성을 선택하는 것은 일회성이 아닌 ElastiCache로 마이그레이션하기 전에 정기적으로 수행해야 하는 중요한 작업입니다. 일 년 내내, 특히 다가오는 주요 비즈니스 행사를 앞두고는 더욱 자주 검토해야 합니다. 이를 통해 팀은 규모와 예상되는 트래픽 증가를 보다 잘 처리할 수 있으므로 고객에게 지속적으로 원활하게 서비스를 제공할 수 있습니다.
질문이나 의견이 있으면 AWS ElastiCache 토론 포럼 또는 의견을 남겨주세요.
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.