Amazon ElastiCache Well-Architected 렌즈 성능 효율성 기둥 - 아마존 ElastiCache (레디 스 OSS)
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 지표를 모니터링하여 사용 가능한 지표를 파악하고 성능 기준을 설정하십시오.

  • [최고] ElastiCache (Redis OSS) 워크로드의 경우 사용자가 프로덕션 클러스터에서 차단 명령을 실행할 수 없도록 하는 등 KEYS 계산 비용이 많이 드는 명령의 이름을 변경하십시오.

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

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

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

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

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

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

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

  • [리소스]:

PE 2: 클러스터 노드 전체에 작업을 어떻게 분배하고 있습니까? ElastiCache

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

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

  • [필수] 클라이언트가 적절한 엔드포인트에 연결되도록 하십시오. ElastiCache

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

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

  • [더 좋음] ElastiCache (Redis OSS) 클러스터 모드를 활성화하여 확장성을 개선하십시오.

    • ElastiCache (Redis OSS) (클러스터 모드 사용) 클러스터는 샤드에 데이터를 동적으로 분배하는 데 도움이 되는 온라인 확장 작업 (출력/입력 및 업/다운) 을 지원합니다. 구성 엔드포인트를 사용하면 클러스터 인식 클라이언트가 클러스터 토폴로지의 변화에 맞게 조정할 수 있습니다.

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

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

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

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

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

    • E ElastiCache (Redis OSS) 버전 6은 서버 지원 클라이언트 측 캐싱을 지원합니다. 이를 통해 애플리케이션은 네트워크 호출을 다시 걸기 전에 키가 변경될 때까지 기다릴 수 있습니다. ElastiCache

  • [리소스]:

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

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

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

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

    [리소스]:

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

    [리소스]:

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

    [리소스]:

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

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

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

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

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

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

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

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

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

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

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

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

    • ElastiCache (Redis OSS) 6.x 워크로드의 경우 파라미터를 사용하여 파라미터 그룹에서 DEL 명령의 동작을 수정할 수 있습니다. lazyfree-lazy-user-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) 의 단일 스레드 설계로 인해 시간 복잡성이 높은 대량의 작업을 수행하면 성능이 저하되고 작업 제한 시간이 초과될 수 있습니다.

    [리소스]:

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

    [리소스]:

PE 7: Amazon ElastiCache 클러스터에서 느리게 실행되는 명령을 어떻게 기록합니까?

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

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

  • [필수] Amazon ElastiCache (Redis OSS) 은 엔진 버전 6.0 이상을 실행하고 있으며 클러스터에서 올바르게 구성된 파라미터 그룹과 SLOWLOG 로깅이 활성화되어 있습니다.

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

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

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

  • [최고] Kinesis Data CloudWatch Firehose의 기능을 활용하십시오.

    • CloudWatchLogs Insights 및 Amazon Simple Notification Services의 CloudWatch 필터링 및 경보 기능을 사용하여 성능 모니터링 및 이벤트 알림을 달성하십시오.

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

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

    • CloudWatch 또는 Kinesis Data Firehose에 게시할 수 있는 권한을 IAM 에 제공하십시오.

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

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

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

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

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

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

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

  • [리소스]:

PE8: Auto Scaling은 ElastiCache 클러스터의 성능 향상에 어떻게 도움이 됩니까?

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

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

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

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

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

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

    [리소스]:

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

    [리소스]:

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

    [리소스]:

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

    [리소스]: