Amazon ElastiCache Well-Architected 렌즈 성능 효율성 기둥 - 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 렌즈 성능 효율성 기둥

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

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

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

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

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

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

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

  • [Best] ElastiCache (Redis OSS) 워크로드의 경우 프로덕션 클러스터에서 차단 명령을 실행할 수 있는 사용자의 기능을 제한KEYS하려면 와 같이 계산 비용이 많이 드는 명령의 이름을 변경합니다.

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

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

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

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

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

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

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

  • [리소스]:

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

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

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

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

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

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

  • [더 좋음] 확장성을 개선하기 위해 활성화된 ElastiCache (Redis OSS) 클러스터 모드를 활용합니다.

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

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

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

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

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

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

    • ElastiCache Valkey 7.2 이상 및 Redis OSS 버전 6 이상에서는 서버 지원 클라이언트 측 캐싱을 지원합니다. 이렇게 하면 애플리케이션이 로 다시 네트워크 호출하기 전에 키가 변경될 때까지 기다릴 수 있습니다ElastiCache.

  • [리소스]:

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

질문 수준 소개: 캐싱은 에서 일반적으로 발생하는 워크로드 ElastiCache 이며 캐시의 효율성과 성능을 관리하는 방법을 이해하는 것이 중요합니다.

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

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

    [리소스]:

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

    [리소스]:

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

    [리소스]:

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

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

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

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

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

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

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

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

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

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

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

  • [리소스]:

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

질문 수준 소개: 워크로드는 요구 사항이 다르며 클러스터 노드가 메모리 소비 제한에 가까워질 때 예상되는 동작이 다릅니다. ElastiCache (Redis OSS)에는 이러한 상황을 처리하기 위한 다양한 정책이 있습니다.

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

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

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

    • 기본 정책은 만료 시간(TTL 값)이 설정된 키를 제거하여 메모리를 volatile-lru 확보합니다. 가장 자주 사용하지 않는 (LFU) 및 가장 최근에 사용하지 않는 (LRU) 정책은 사용량에 따라 키를 제거합니다.

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

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

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

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

  • [리소스]:

PE 6: 의 데이터를 모델링하고 상호 작용하는 방법은 무엇입니까 ElastiCache?

질문 수준 소개: ElastiCache 는 사용되는 데이터 구조와 데이터 모델에 크게 의존하지만 기본 데이터 스토어(있는 경우)도 고려해야 합니다. 사용 가능한 ElastiCache (Redis OSS) 데이터 구조를 이해하고 필요에 가장 적합한 데이터 구조를 사용하고 있는지 확인합니다.

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

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

    [리소스]:

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

    [리소스]:

  • [최고] APIs 를 사용하여 클러스터의 데이터 모델을 GUI 확인할 수 있습니다.

    [리소스]:

PE 7: Amazon ElastiCache 클러스터에서 실행 속도가 느린 명령을 어떻게 로깅하나요?

질문 수준의 소개: 성능 튜닝은 오래 실행되는 명령의 캡처, 집계 및 알림에 유용합니다. 명령이 실행되는 데 걸리는 시간을 이해하여 성능이 저하되는 명령과 엔진의 최적 성능을 차단하는 명령을 결정할 수 있습니다. ElastiCache (Redis OSS)에는 이 정보를 Amazon CloudWatch 또는 Amazon Kinesis Data Firehose 에 전달할 수 있는 기능도 있습니다.

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

  • [필수] 엔진 버전 6.0 이상을 실행하는 Amazon ElastiCache (Redis OSS)과 올바르게 구성된 파라미터 그룹 및 클러스터에서 활성화된 SLOWLOG 로깅.

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

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

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

  • [최고] CloudWatch 또는 Kinesis Data Firehose 기능을 활용합니다.

    • CloudWatch, CloudWatch Logs Insights 및 Amazon Simple Notification Services의 필터링 및 경보 기능을 사용하여 성능 모니터링 및 이벤트 알림을 달성합니다.

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

    • JSON 또는 일반 TEXT 형식이 요구 사항에 가장 적합한지 확인합니다.

    • 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 메모리에 더 많은 명령을 유지할 수 있습니다.

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

  • [리소스]:

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

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

질문 수준의 이점: 워크로드의 급증에 대한 이해 및 계획을 통해 캐싱 성능과 비즈니스 연속성을 향상시킬 수 있습니다. ElastiCache (Redis OSS) Auto Scaling은 CPU/Memory 사용률을 지속적으로 모니터링하여 클러스터가 원하는 성능 수준에서 작동하는지 확인합니다.

  • [필수] ElastiCache (Redis )에 대한 클러스터를 시작할 때OSS:

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

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

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

    [리소스]:

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

    [리소스]:

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

    [리소스]:

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

    [리소스]: