Amazon ElastiCache Well-Architected Lens 성능 효율성 요소 - Amazon ElastiCache
PE 1: Amazon ElastiCache 클러스터의 성능을 어떻게 모니터링하나요?PE 2: ElastiCache 클러스터 노드에 작업을 어떻게 분배하고 있나요?PE 3: 캐싱 워크로드의 경우, 캐시의 효율성과 성능을 어떻게 추적하고 보고하나요?PE 4: 워크로드가 네트워킹 리소스 및 연결 사용을 어떻게 최적화하나요?PE 5: 키 삭제 또는 제거를 어떻게 관리하나요?PE 6: ElastiCache에서 어떻게 데이터를 모델링하고 데이터와 상호 작용하나요?PE 7: Amazon ElastiCache 클러스터에서 느리게 실행되는 명령을 어떻게 로깅하나요?PE8: Auto Scaling은 ElastiCache 클러스터의 성능을 높이는 데 어떻게 도움이 되나요?

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon ElastiCache Well-Architected Lens 성능 효율성 요소

성능 효율성 요소는 IT 및 컴퓨팅 리소스를 효율적으로 사용하는 데 중점을 둡니다. 주요 주제로는 워크로드 요구 사항을 기반으로 적절한 리소스 유형 및 크기 선택하기, 성능 모니터링하기, 비즈니스 요구 사항이 변화함에 따라 효율성을 유지하기 위해 정보에 입각하여 의사 결정 내리기가 있습니다.

PE 1: Amazon ElastiCache 클러스터의 성능을 어떻게 모니터링하나요?

질문 수준의 소개: 기존 모니터링 지표를 이해하면 현재 사용률을 파악할 수 있습니다. 적절한 모니터링은 클러스터 성능에 영향을 미치는 잠재적 병목 현상을 식별하는 데 도움이 될 수 있습니다.

질문 수준의 이점: 클러스터와 관련된 지표를 이해하면 지연 시간을 줄이고 처리량을 높이는 데 도움이 되는 최적화 기법을 익힐 수 있습니다.

  • [필수] 워크로드의 일부를 사용하여 기준 성능을 테스트합니다.

    • 로드 테스트와 같은 메커니즘을 사용하여 실제 워크로드의 성능을 모니터링해야 합니다.

    • 이러한 테스트를 실행하는 동안 CloudWatch 지표를 모니터링하여 사용 가능한 지표를 이해하고 성능 기준을 설정합니다.

  • [가장 좋음] Valkey 및 Redis OSS용 ElastiCache 워크로드의 경우와 같이 계산 비용이 많이 드는 명령의 이름을 변경KEYS하여 사용자가 프로덕션 클러스터에서 차단 명령을 실행하는 기능을 제한합니다.

    • 엔진 6.x for Redis OSS를 실행하는 ElastiCache 워크로드는 역할 기반 액세스 제어를 활용하여 특정 명령을 제한할 수 있습니다. AWS 콘솔 또는 CLI를 사용하여 사용자 및 사용자 그룹을 생성하고 사용자 그룹을 클러스터에 연결하여 명령에 대한 액세스를 제어할 수 있습니다. Redis OSS 6에서는 RBAC가 활성화되면 '-@dangerous'를 사용할 수 있으며, 이는 해당 사용자가 KEYS, MONITOR, SORT 등과 같이 비용이 많이 드는 명령을 사용하는 것을 허용하지 않습니다.

    • 엔진 버전 5.x의 경우 클러스터 rename-commands 파라미터 그룹의 파라미터를 사용하여 명령의 이름을 변경합니다.

  • [더 좋음] 느린 쿼리를 분석하고 최적화 기법을 찾아봅니다.

    • ElastiCache for Valkey 및 Redis OSS 워크로드의 경우 느린 로그를 분석하여 쿼리에 대해 자세히 알아봅니다. 예를 들어 valkey-cli slowlog get 10 명령을 사용하여 지연 시간 임계값(기본값 10초)을 초과한 마지막 10개의 명령을 표시할 수 있습니다.

    • 특정 쿼리는 복잡한 ElastiCache for Valkey 및 Redis OSS 데이터 구조를 사용하여 더 효율적으로 수행할 수 있습니다. 예를 들어, 숫자 스타일 범위 조회의 경우 애플리케이션은 정렬된 세트를 사용하여 간단한 숫자 인덱스를 구현할 수 있습니다. 이러한 인덱스를 관리하면 데이터 세트에 대해 수행되는 스캔을 줄이고 더 높은 성능 효율성으로 데이터를 반환할 수 있습니다.

    • ElastiCache for Valkey 및 Redis OSS 워크로드의 경우는 클라이언트 수 및 데이터 크기와 같은 사용자 정의 입력을 사용하여 다양한 명령의 성능을 테스트하기 위한 간단한 인터페이스를 redis-benchmark 제공합니다.

    • Memcached는 간단한 키 수준 명령만 지원하므로 클라이언트 쿼리를 처리하기 위해 키 공간을 반복하지 않도록 추가 키를 인덱스로 구축하는 것이 좋습니다.

  • [리소스]:

PE 2: ElastiCache 클러스터 노드에 작업을 어떻게 분배하고 있나요?

질문 수준의 소개: 애플리케이션이 Amazon ElastiCache 노드에 연결하는 방식이 클러스터의 성능 및 확장성에 영향을 미칠 수 있습니다.

질문 수준의 이점: 클러스터에서 사용 가능한 노드를 적절히 사용하면 사용 가능한 리소스 전체에 작업이 분산됩니다. 다음 기법은 유휴 리소스를 방지하는 데도 도움이 됩니다.

  • [필수] 클라이언트가 적절한 ElastiCache 엔드포인트에 연결되도록 합니다.

    • ElastiCache for Valkey 및 Redis OSS는 사용 중인 클러스터 모드에 따라 다양한 엔드포인트를 구현합니다. 클러스터 모드가 활성화된 경우 ElastiCache는 구성 엔드포인트를 제공합니다. 클러스터 모드가 비활성화된 경우 ElastiCache는 일반적으로 쓰기에 사용되는 기본 엔드포인트와 복제본 간에 읽기 밸런싱을 위한 리더 엔드포인트를 제공합니다. 이러한 엔드포인트를 올바르게 구현하면 성능이 향상되고 확장 작업이 더 쉬워집니다. 특별한 요구 사항이 없는 한 개별 노드 엔드포인트에 연결하지 마시기 바랍니다.

    • 다중 노드 Memcached 클러스터의 경우 ElastiCache는 자동 검색을 지원하는 구성 엔드포인트를 제공합니다. 캐시 노드 전체에 작업을 균등하게 분배하려면 해싱 알고리즘을 사용하는 것이 좋습니다. 많은 Memcached 클라이언트 라이브러리는 일관된 해싱을 구현합니다. 사용할 라이브러리의 설명서에서 일관적 해싱 지원 여부와 그 구현 방법을 참조하세요. 이러한 기능 구현에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

  • [더 좋음] Valkey용 ElastiCache 및 Redis OSS 클러스터 모드 지원 클러스터를 활용하여 확장성을 개선합니다.

    • ElastiCache for Valkey 및 Redis OSS(클러스터 모드 활성화됨) 클러스터는 온라인 조정 작업(out/in 및 up/down)을 지원하여 샤드 간에 데이터를 동적으로 분산하는 데 도움이 됩니다. 구성 엔드포인트를 사용하면 클러스터 인식 클라이언트가 클러스터 토폴로지의 변화에 맞게 조정할 수 있습니다.

    • 또한 ElastiCache for Valkey 및 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 사용 가능한 샤드 간에 해시 슬롯을 이동하여 클러스터의 균형을 재조정할 수도 있습니다. 이렇게 하면 사용 가능한 샤드에 작업을 더 효율적으로 분배할 수 있습니다.

  • [더 좋음] 워크로드의 단축키를 식별하고 정정하기 위한 전략을 구현합니다.

    • 목록, 스트림, 세트 등과 같은 다차원 Valkey 또는 Redis OSS 데이터 구조의 영향을 고려하세요. 이러한 데이터 구조는 단일 노드에 있는 단일 키에 저장됩니다. 매우 큰 다차원 키는 다른 데이터 유형보다 더 많은 네트워크 용량과 메모리를 사용할 가능성이 있으며, 이로 인해 해당 노드가 불균형하게 사용될 수 있습니다. 가능하면 여러 개별 키로 데이터 액세스를 분산하도록 워크로드를 설계하세요.

    • 워크로드의 핫키는 사용 중인 노드의 성능에 영향을 미칠 수 있습니다. Valkey 및 Redis OSS 워크로드용 ElastiCache의 경우 LFU 최대 메모리 정책이 마련되어 있는 valkey-cli --hotkeys 경우를 사용하여 핫 키를 감지할 수 있습니다.

    • 여러 노드에 핫키를 복제하여 액세스를 더 균등하게 분산하는 것을 고려해 보세요. 이 방법을 사용하려면 클라이언트가 여러 프라이머리 노드에 쓰고(Valkey 또는 Redis OSS 노드 자체에서는 이 기능을 제공하지 않음) 원래 키 이름 외에도 읽을 키 이름 목록을 유지 관리해야 합니다.

    • Valkey 이상용 ElastiCache 엔진 7.2와 Redis OSS 이상용 ElastiCache 버전 6은 모두 서버 지원 클라이언트 측 캐싱을 지원합니다. 이렇게 하면 애플리케이션이 키 변경을 기다린 후 ElastiCache로 다시 네트워크를 호출할 수 있습니다.

  • [리소스]:

PE 3: 캐싱 워크로드의 경우, 캐시의 효율성과 성능을 어떻게 추적하고 보고하나요?

질문 수준의 소개: 캐싱은 ElastiCache에서 흔히 볼 수 있는 워크로드이므로 캐시의 효율성과 성능을 관리하는 방법을 이해하는 것이 중요합니다.

질문 수준의 이점: 애플리케이션의 성능이 저하되었다는 징후가 보일 수 있습니다. 캐시별 지표를 사용하여 앱 성능을 높이는 방법을 결정하는 것은 캐시 워크로드에 매우 중요합니다.

  • [필수] 시간에 따른 캐시 적중률을 측정하고 추적합니다. 캐시의 효율성은 '캐시 적중률'로 결정됩니다. 캐시 적중률이란 총 키 적중 수를 총 적중 수와 누락 수로 나눈 값을 말합니다. 비율이 1에 가까울수록 캐시의 효율성이 높은 것입니다. 캐시 적중률이 낮은 이유는 캐시 누락의 수가 많기 때문입니다. 요청된 키를 캐시에서 찾을 수 없을 때 캐시 누락이 발생합니다. 키가 캐시에 없는 이유는 키가 제거 또는 삭제되었거나, 만료되었거나, 존재한 적이 없기 때문입니다. 키가 캐시에 없는 이유를 이해하고 키를 캐시에 포함하는 데 적절한 전략을 개발하세요.

    [리소스]:

  • [필수] 지연 시간 및 CPU 사용률 값과 함께 애플리케이션 캐시 성능을 측정 및 수집하여 TTL(Time To Live) 또는 기타 애플리케이션 구성 요소를 조정해야 하는지 파악합니다. ElastiCache는 각 데이터 구조에 집계된 지연 시간에 대한 CloudWatch 지표 세트를 제공합니다. 이러한 지연 시간 지표는 INFO 명령의 commandstats 통계를 사용하여 계산되며 네트워크 및 I/O 시간은 포함하지 않습니다. 이는 ElastiCache가 작업을 처리하는 데 소비하는 시간입니다.

    [리소스]:

  • [가장 좋음] 필요에 맞는 캐싱 전략을 선택합니다. 캐시 적중률이 낮은 이유는 캐시 누락의 수가 많기 때문입니다. 워크로드가 캐시 누락이 적도록 설계된 경우(예: 실시간 통신), 캐싱 전략을 검토하고 메모리 및 성능 측정을 위한 쿼리 계측과 같이 워크로드에 가장 적합한 방법을 적용하는 것이 가장 좋습니다. 캐시를 채우고 유지 관리하기 위해 사용하는 실제 전략은 클라이언트가 캐싱해야 하는 데이터의 유형과 해당 데이터에 대한 액세스 패턴에 따라 달라집니다. 예를 들어 스트리밍 애플리케이션의 맞춤형 추천과 최신 뉴스 기사 모두에 동일한 전략을 사용할 가능성은 거의 없습니다.

    [리소스]:

PE 4: 워크로드가 네트워킹 리소스 및 연결 사용을 어떻게 최적화하나요?

질문 수준 소개: ElastiCache for Valkey, Memcached 및 Redis OSS는 많은 애플리케이션 클라이언트에서 지원되며 구현은 다를 수 있습니다. 성능에 미치는 잠재적인 영향을 분석하려면 현재 사용 중인 네트워킹 및 연결 관리 방법을 이해해야 합니다.

질문 수준의 이점: 네트워킹 리소스를 효율적으로 사용하면 클러스터의 성능 효율성을 높일 수 있습니다. 다음 권장 사항을 적용하면 네트워킹 수요를 줄이고 클러스터 지연 시간 및 처리량을 개선할 수 있습니다.

  • [필수] ElastiCache 클러스터에 대한 연결을 사전에 관리합니다.

    • 애플리케이션의 연결 풀링은 연결을 열고 닫을 때 생성되는 클러스터의 오버헤드를 줄입니다. CurrConnections 및 NewConnections를 사용하여 Amazon CloudWatch의 연결 동작을 모니터링하세요.

    • 상황에 따라 클라이언트 연결을 제대로 닫아 연결 누수를 방지합니다. 연결 관리 전략에는 사용하지 않는 연결을 올바르게 닫고 연결 시간 제한을 설정하는 것이 포함됩니다.

    • Memcached 워크로드의 경우, memcached_connections_overhead라는 연결 처리를 위해 예약된 메모리의 양을 구성할 수 있습니다.

  • [더 좋음] 대용량 객체를 압축하여 메모리를 줄이고 네트워크 처리량을 개선합니다.

    • 데이터를 압축하면 필요한 네트워크 처리량(Gbps)을 줄일 수 있지만 애플리케이션에서 데이터를 압축 및 압축 해제하는 작업량이 늘어날 수 있습니다.

    • 압축은 키가 소비하는 메모리의 양도 줄여줍니다.

    • 애플리케이션 요구 사항에 따라 압축률과 압축 속도 간의 균형을 고려하세요.

  • [리소스]:

PE 5: 키 삭제 또는 제거를 어떻게 관리하나요?

질문 수준의 소개: 워크로드는 요구 사항이 각기 다르며 클러스터 노드가 메모리 소비 제한에 근접했을 때 예상되는 동작이 각기 다릅니다. ElastiCache는 이러한 상황을 처리하기 위한 정책이 다릅니다.

질문 수준의 이점: 사용 가능한 메모리를 적절히 관리하고 제거 정책을 이해하면 인스턴스 메모리 제한을 초과했을 때 클러스터 동작을 인식하는 데 도움이 됩니다.

  • [필수] 데이터 액세스를 계측하여 적용할 정책을 평가합니다. 클러스터에서 제거를 수행할지, 수행한다면 어떻게 수행할지 제어하는 데 적합한 최대 메모리 정책을 식별합니다.

    • 제거는 클러스터에서 최대 메모리가 소비되고 제거를 허용하는 정책이 있을 때 발생합니다. 이 상황에서 클러스터의 동작은 지정된 제거 정책에 따라 달라집니다. 이 정책은 클러스터 파라미터 그룹의 maxmemory-policy를 사용하여 관리할 수 있습니다.

    • 기본 정책인 volatile-lru는 만료 시간(TTL 값)이 설정된 키를 제거하여 메모리를 확보합니다. 가장 낮은 빈도로 사용(LFU) 및 가장 오래 전에 사용(LRU) 정책은 사용 현황에 따라 키를 제거합니다.

    • Memcached 워크로드의 경우, 각 노드의 제거를 제어하는 기본 LRU 정책이 있습니다. Amazon CloudWatch의 제거 지표를 사용하여 Amazon ElastiCache 클러스터의 제거 수를 모니터링할 수 있습니다.

  • [더 좋음] 삭제 동작을 표준화하여 클러스터의 성능에 미치는 영향을 제어함으로써 예상치 못한 성능 병목 현상을 방지합니다.

    • Valkey 및 Redis OSS용 ElastiCache 워크로드의 경우 클러스터에서 키를 명시적으로 제거할 때 UNLINK는 DEL와 같습니다. 지정된 키를 제거합니다. 그러나 이 명령은 다른 스레드에서 실제 메모리 회수를 수행하므로 DEL과는 달리 차단하지 않습니다. 실제 제거는 나중에 비동기적으로 수행됩니다.

    • ElastiCache 버전 6.x for Redis OSS 워크로드의 경우 lazyfree-lazy-user-del 파라미터를 사용하여 파라미터 그룹에서 DEL 명령의 동작을 수정할 수 있습니다.

  • [리소스]:

PE 6: ElastiCache에서 어떻게 데이터를 모델링하고 데이터와 상호 작용하나요?

질문 수준의 소개: ElastiCache는 사용되는 데이터 구조 및 데이터 모델과 관련해서 애플리케이션에 크게 의존하지만 데이터 스토어가 있는 경우 기본 데이터 스토어도 고려해야 합니다. 사용 가능한 데이터 구조를 이해하고 필요에 가장 적합한 데이터 구조를 사용하고 있는지 확인합니다.

질문 수준의 이점: ElastiCache의 데이터 모델링에는 애플리케이션 사용 사례, 데이터 유형 및 데이터 요소 간 관계를 비롯한 여러 계층이 있습니다. 또한 각 데이터 유형 및 명령에는 잘 문서화된 자체 성능 서명이 있습니다.

  • [가장 좋음]  가장 좋음은 의도하지 않은 데이터 덮어쓰기를 줄이는 것입니다. 중복되는 키 이름을 최소화하는 이름 지정 규칙을 사용하세요. 일반적으로 데이터 구조의 이름을 지정할 때는 APPNAME:CONTEXT:ID, ORDER-APP:CUSTOMER:123 등의 계층적 방법을 사용합니다.

    [리소스]:

  • [가장 좋음] Valkey 및 Redis OSS용 ElastiCache 명령에는 Big O 표기법으로 정의된 시간 복잡성이 있습니다. 이때 명령의 시간 복잡도는 그 영향을 알고리즘/수학적으로 표현한 것입니다. 애플리케이션에 새 데이터 유형을 도입할 때는 관련 명령의 시간 복잡도를 주의 깊게 검토해야 합니다. 시간 복잡도가 O(1)인 명령은 시간이 일정하며 입력 크기에 의존하지 않지만 시간 복잡도가 O(N)인 명령은 시간이 선형이며 입력 크기의 영향을 받습니다. Valkey 및 Redis OSS용 ElastiCache의 단일 스레드 설계로 인해 시간이 많이 걸리는 복잡한 작업이 많으면 성능이 저하되고 작업 제한 시간이 초과될 수 있습니다.

    [리소스]:

  • [가장 좋음] API를 사용하여 클러스터의 데이터 모델에 대한 GUI 가시성을 확보합니다.

    [리소스]:

PE 7: Amazon ElastiCache 클러스터에서 느리게 실행되는 명령을 어떻게 로깅하나요?

질문 수준의 소개: 성능 튜닝은 오래 실행되는 명령의 캡처, 집계 및 알림에 유용합니다. 명령을 실행하는 데 걸리는 시간을 이해하면 저조한 성능을 초래하는 명령과 엔진이 최적의 성능을 발휘하지 못하게 하는 명령을 파악할 수 있습니다. 또한 ElastiCache는이 정보를 Amazon CloudWatch 또는 Amazon Kinesis Data Firehose에 전달할 수 있습니다.

질문 수준의 이점: 영구적인 전용 위치에 로깅하고 느린 명령에 대한 알림 이벤트를 제공하면 상세한 성능 분석에 도움이 되고 자동화된 이벤트를 트리거하는 데 사용할 수 있습니다.

  • [필수] Valkey 엔진 7.2 이상을 실행하거나 Redis OSS 엔진 버전 6.0 이상을 실행하는 ElastiCache, 클러스터에서 제대로 구성된 파라미터 그룹 및 SLOWLOG 로깅 활성화.

    • 필요한 파라미터는 엔진 버전 호환성이 Valkey 7.2 이상 또는 Redis OSS 버전 6.0 이상으로 설정된 경우에만 사용할 수 있습니다.

    • SLOWLOG 로깅은 명령의 서버 실행 시간이 지정된 값보다 오래 걸릴 때 발생합니다. 클러스터의 동작은 관련 파라미터 그룹 파라미터(slowlog-log-slower-than 및 slowlog-max-len)에 따라 달라집니다.

    • 변경 사항은 즉시 적용됩니다.

  • [가장 좋음] CloudWatch 또는 Kinesis Data Firehose 기능을 활용합니다.

    • CloudWatch, CloudWatch 로그 인사이트 및 Amazon Simple Notification Services의 필터링 및 경보 기능을 사용하여 성능을 모니터링하고 이벤트 알림을 받습니다.

    • Kinesis Data Firehose의 스트리밍 기능을 사용하여 SLOWLOG 로그를 영구 스토리지에 보관하거나 자동화된 클러스터 파라미터 튜닝을 트리거합니다.

    • JSON과 일반 텍스트 형식 중에서 요구 사항에 가장 적합한 형식을 결정하세요.

    • CloudWatch 또는 Kinesis Data Firehose에 게시할 수 있는 IAM 권한을 제공합니다.

  • [더 좋음] 기본값이 아닌 다른 값으로 slowlog-log-slower-than을 구성합니다.

    • 이 파라미터는 느리게 실행되는 명령으로 로깅되기 전에 Valkey 또는 Redis OSS 엔진 내에서 명령을 실행할 수 있는 기간을 결정합니다. 기본값은 1만 마이크로초(10밀리초)입니다. 일부 워크로드의 경우 기본값이 너무 높을 수 있습니다.

    • 애플리케이션 요구 사항 및 테스트 결과를 기반으로 워크로드에 더 적합한 값을 결정하세요. 그러나 값이 너무 낮으면 과도한 데이터가 생성될 수 있습니다.

  • [더 좋음] slowlog-max-len의 기본값을 그대로 둡니다.

    • 이 파라미터는 주어진 시간에 Valkey 또는 Redis OSS 메모리에 캡처되는 느리게 실행되는 명령 수의 상한선을 결정합니다. 값이 0이면 캡처가 사실상 비활성화됩니다. 값이 클수록 더 많은 항목이 메모리에 저장되므로 중요한 정보가 검토되기 전에 제거될 가능성이 줄어듭니다. 기본값은 128입니다.

    • 기본값은 대부분의 워크로드에 적합합니다. SLOWLOG 명령을 통해 valkey-cli에서 더 오랜 기간 동안 데이터를 분석해야 하는 경우 이 값을 높이는 것이 좋습니다. 이렇게 하면 더 많은 명령을 Valkey 또는 Redis OSS 메모리에 유지할 수 있습니다.

      SLOWLOG 데이터를 CloudWatch Logs 또는 Kinesis Data Firehose로 내보내는 경우, 데이터가 유지되고 ElastiCache 시스템 외부에서 분석할 수 있으므로 느리게 실행되는 대량의 명령을 Valkey 또는 Redis OSS 메모리에 저장할 필요가 줄어듭니다.

  • [리소스]:

PE8: Auto Scaling은 ElastiCache 클러스터의 성능을 높이는 데 어떻게 도움이 되나요?

질문 수준의 소개: Valkey 또는 Redis OSS 오토 스케일링 기능을 구현하면 ElastiCache 구성 요소가 시간이 지남에 따라 조정되어 원하는 샤드 또는 복제본을 자동으로 늘리거나 줄일 수 있습니다. 이는 대상 추적 또는 예약된 규모 조정 정책을 구현하여 수행할 수 있습니다.

질문 수준의 이점: 워크로드의 급증을 이해하고 이에 대한 계획을 세우면 향상된 캐싱 성능과 비즈니스 연속성을 보장할 수 있습니다. ElastiCache Auto Scaling은 CPU/메모리 사용률을 지속적으로 모니터링하여 클러스터가 원하는 성능 수준에서 작동하는지 확인합니다.

  • [필수] Valkey 또는 Redis OSS용 ElastiCache 클러스터를 시작하는 경우:

    1. 클러스터 모드가 활성화되었는지 확인합니다.

    2. 인스턴스가 Auto Scaling을 지원하는 특정 유형 및 크기의 패밀리에 속하는지 확인합니다.

    3. 클러스터가 글로벌 데이터 스토어, Outposts 또는 로컬 영역에서 실행되고 있지 않은지 확인합니다.

    [리소스]:

  • [가장 좋음] 워크로드에 읽기 작업이 많은지, 쓰기 작업이 많은지 파악하여 규모 조정 정책을 정의합니다. 최상의 성능을 위해서는 하나의 추적 지표만 사용하세요. Auto Scaling 정책은 목표에 도달하면 스케일 아웃이 수행되지만 모든 대상 추적 정책이 스케일 인 준비가 된 경우에만 스케일 인이 수행되므로 각 차원에 대해 여러 정책을 사용하지 않는 것이 좋습니다.

    [리소스]:

  • [가장 좋음] 시간 경과에 따른 성능 모니터링은 특정 시점에 모니터링할 경우 눈에 띄지 않는 워크로드 변경을 감지하는 데 도움이 될 수 있습니다. 4주간의 클러스터 사용률에 대한 CloudWatch 지표를 분석하여 대상 값 임계값을 확인할 수 있습니다. 어떤 값을 선택할지 잘 모르는 경우 지원되는 최소 사전 정의 지표 값으로 시작하는 것이 좋습니다.

    [리소스]:

  • [더 좋음] 클러스터가 규모 조정 정책을 개발하고 가용성 문제를 완화하는 데 필요한 샤드/복제본의 정확한 수를 파악하기 위해 예상되는 최소 및 최대 워크로드로 애플리케이션을 테스트하는 것이 좋습니다.

    [리소스]: