기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon ElastiCache의 Well-Architected Lens 사용
이 섹션에서는 효율적으로 아키텍팅된 ElastiCache 워크로드를 설계하기 위한 설계 원칙과 지침을 모은 Amazon ElastiCache Well-Architected Lens에 대해 설명합니다.
+ [ElastiCache Lens는 AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)에 포함됩니다.
+ 요소마다 ElastiCache 아키텍처에 대한 논의를 시작하는 데 도움이 되는 일련의 질문이 있습니다.
+ 각 질문에는 보고용 점수와 함께 여러 가지 주요 사례가 있습니다.
+ *필수* - 프로덕션 전 필요(따르지 않으면 위험도 높음)
+ *가장 좋음* - 고객이 될 수 있는 최상의 상태
+ *좋음* - 고객에게 권하는 상태(따르지 않으면 위험도 중간)
+ Well-Architected 용어
+ [구성 요소](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) - 요구 사항을 충족하는 코드, 구성 및 AWS 리소스. 구성 요소는 다른 구성 요소와 상호 작용하며 종종 마이크로 서비스 아키텍처의 서비스와 동일합니다.
+ [워크로드](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) - 함께 비즈니스 가치를 제공하는 구성 요소의 집합. 예를 들어, 마케팅 웹사이트, 전자 상거래 웹사이트, 모바일 앱 백엔드, 분석 플랫폼 등이 워크로드에 해당합니다.
**참고**
이 가이드의 업데이트에는 ElastiCache 서버리스 캐싱 및 새 Valkey 엔진에 대한 정보가 포함되지 않았습니다.
**Topics**
+ [Amazon ElastiCache Well-Archited Lens 운영 우수성 요소](OperationalExcellencePillar.md)
+ [Amazon ElastiCache의 Well-Architected Lens 보안 요소](SecurityPillar.md)
+ [Amazon ElastiCache의 Well-Architected Lens 신뢰성 요소](ReliabilityPillar.md)
+ [Amazon ElastiCache Well-Architected Lens 성능 효율성 요소](PerformanceEfficiencyPillar.md)
+ [Amazon ElastiCache의 Well-Architected Lens 비용 최적화 요소](CostOptimizationPillar.md)
# Amazon ElastiCache Well-Archited Lens 운영 우수성 요소
운영 우수성 요소는 비즈니스 가치를 제공하고 프로세스 및 절차를 지속적으로 개선하기 위한 시스템 운영 및 모니터링에 중점을 둡니다. 주요 주제에는 변경 자동화, 이벤트 대응, 일상 운영 관리를 위한 표준 정의 등이 포함됩니다.
**Topics**
+ [OE 1: ElastiCache 클러스터에서 트리거되는 경고 및 이벤트를 어떻게 이해하고 이에 대응하나요?](#OperationalExcellencePillarOE1)
+ [OE 2: 기존 ElastiCache 클러스터를 언제, 어떻게 확장하나요?](#OperationalExcellencePillarOE2)
+ [OE 3: ElastiCache 클러스터 리소스를 관리하고 클러스터를 최신 상태로 유지하려면 어떻게 해야 하나요?](#OperationalExcellencePillarOE3)
+ [OE 4: ElastiCache 클러스터에 대한 클라이언트의 연결을 어떻게 관리하나요?](#OperationalExcellencePillarOE4)
+ [OE 5: 워크로드에 대해 ElastiCache 구성 요소를 어떻게 배포하나요?](#OperationalExcellencePillarOE5)
+ [OE 6: 장애를 어떻게 대비하고 완화할 계획인가요?](#OperationalExcellencePillarOE6)
+ [OE 7: Valkey 또는 Redis OSS 엔진 이벤트 문제를 어떻게 해결하나요?](#OperationalExcellencePillarOE7)
## OE 1: ElastiCache 클러스터에서 트리거되는 경고 및 이벤트를 어떻게 이해하고 이에 대응하나요?
**질문 수준의 소개: **ElastiCache 클러스터를 운영할 때 선택적으로 특정 이벤트 발생 시 알림 및 경고를 받을 수 있습니다. ElastiCache는 기본적으로 장애 조치, 노드 교체, 규모 조정 작업, 예약된 유지 관리 등 리소스와 관련된 [이벤트](ECEvents.md)를 로깅합니다. 각 이벤트에는 날짜 및 시간, 소스 이름 및 소스 유형, 설명이 포함됩니다.
**질문 수준의 이점: **클러스터에서 생성되는 경고를 트리거하는 이벤트의 근본 원인을 이해하고 관리할 수 있다면 더 효과적으로 운영하고 이벤트에 적절하게 대응할 수 있습니다.
+ **[필수]** ElastiCache 콘솔에서 리전을 선택한 후 또는 [Amazon Command Line Interface](https://aws.amazon.com/cli)(AWS CLI) [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) 명령과 [ElastiCache API](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)를 사용하여 ElastiCache에서 생성된 이벤트를 검토합니다. Amazon Simple Notification Service(Amazon SNS)를 사용하여 중요한 클러스터 이벤트에 대해 알림을 보내도록 ElastiCache를 구성합니다. Amazon SNS를 클러스터와 함께 사용하면 프로그래밍 방식으로 ElastiCache 이벤트에 대한 조치를 취할 수 있습니다.
+ 이벤트에는 크게 현재 이벤트와 예정된 이벤트라는 두 가지 범주가 있습니다. 현재 이벤트 목록에는 리소스 생성 및 삭제, 규모 조정 작업, 장애 조치, 노드 재부팅, 생성된 스냅샷, 클러스터의 파라미터 수정, CA 인증서 갱신, 장애 이벤트(클러스터 프로비저닝 실패 - VPC 또는 ENI-, 규모 조정 실패 - ENI- 및 스냅샷 실패)가 포함됩니다. 예정된 이벤트 목록에는 유지 관리 기간 동안 교체가 예정된 노드 및 교체 일정이 변경된 노드가 포함됩니다.
+ 이러한 이벤트 중 일부에 즉시 대응할 필요는 없지만 먼저 모든 장애 이벤트를 살펴보는 것이 중요합니다.
+ ElastiCache:AddCacheNodeFailed
+ ElastiCache:CacheClusterProvisioningFailed
+ ElastiCache:CacheClusterScalingFailed
+ ElastiCache:CacheNodesRebooted
+ ElastiCache: SnapshotFailed(Valkey 또는 Redis OSS만 해당)
+ **[리소스]:**
+ [ElastiCache Amazon SNS 알림 관리](ECEvents.SNS.md)
+ [이벤트 알림 및 Amazon SNS](ElastiCacheSNS.md)
+ **[가장 좋음]** 이벤트에 대한 응답을 자동화하려면 SNS와 Lambda 함수 등의 AWS 제품 및 서비스 기능을 활용합니다. 모범 사례에 따라 작고 빈번하며 되돌릴 수 있는 변경을 코드로 적용하여 시간이 지남에 따라 운영을 발전시킵니다. 클러스터를 모니터링하려면 Amazon CloudWatch 지표를 사용해야 합니다.
**[리소스]:** [AWS Lambda, Amazon Route 53 및 Amazon SNS를 사용하여 ElastiCache(클러스터 모드 비활성화됨)에서 Lambda 및 SNS를 사용하는 사용 사례에 대해 읽기 전용 복제본 엔드포인트를 모니터링](https://aws.amazon.com/blogs/database/monitor-amazon-elasticache-for-redis-cluster-mode-disabled-read-replica-endpoints-using-aws-lambda-amazon-route-53-and-amazon-sns/)합니다.
## OE 2: 기존 ElastiCache 클러스터를 언제, 어떻게 확장하나요?
**질문 수준의 소개: **ElastiCache 클러스터의 크기를 적절하게 조정하는 것은 기본 워크로드 유형이 변경될 때마다 평가해야 하는 균형 조정 작업입니다. 목표는 워크로드에 적합한 규모의 환경에서 운영하는 것입니다.
**질문 수준의 이점: **리소스를 과도하게 사용하면 지연 시간이 늘어나고 전반적인 성능이 저하될 수 있습니다. 반면, 활용도가 낮으면 최적화되지 않은 비용으로 리소스를 과도하게 프로비저닝하게 될 수 있습니다. 환경을 적절한 규모로 조정하면 성능 효율성과 비용 최적화 간의 균형을 맞출 수 있습니다. ElastiCache는 두 가지 차원으로 스케일 인을 수행하여 리소스의 과도하거나 저조한 사용 문제를 해결할 수 있습니다. 노드 용량을 늘리거나 줄여서 수직으로 규모를 조정할 수 있습니다. 노드를 추가 및 제거하여 수평적으로 규모를 조정할 수도 있습니다.
+ **[필수]** 프라이머리 노드에서 CPU 및 네트워크의 과도한 사용은 읽기 작업을 복제본 노드로 오프로드하고 리디렉션하여 해결해야 합니다. 읽기 작업에 복제본 노드를 사용하여 프라이머리 노드 사용률을 줄입니다. 클러스터 모드가 비활성화된 경우 ElastiCache 리더 엔드포인트에 연결하거나 클러스터 모드가 활성화된 경우 READONLY 명령을 사용하여 Valkey 또는 Redis OSS 클라이언트 라이브러리에서 이를 구성할 수 있습니다.
**[리소스]:**
+ [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md)
+ [클러스터 적정 크기 조정](https://aws.amazon.com/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/)
+ [READONLY 명령](https://valkey.io/commands/readonly)
+ **[필수]** CPU, 메모리, 네트워크와 같은 중요 클러스터 리소스의 사용률을 모니터링합니다. 이러한 특정 클러스터 리소스의 사용률을 추적하여 규모 조정을 결정하고 규모 조정 작업의 유형을 결정하는 데 활용해야 합니다. ElastiCache 클러스터 모드가 비활성화된 경우 프라이머리 및 복제본 노드를 수직으로 규모를 조정할 수 있습니다. 복제본 노드는 0개 노드에서 5개 노드까지 수평적으로 확장할 수도 있습니다. 클러스터 모드가 활성화된 경우 클러스터의 각 샤드에 동일하게 적용됩니다. 또한 샤드 수를 늘리거나 줄일 수 있습니다.
**[리소스]:**
+ [Amazon CloudWatch를 사용하는 ElastiCache 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [Valkey and Redis OSS의 ElastiCache 클러스터 규모 조정](Scaling.md)
+ [ElastiCache for Memcached 클러스터 규모 조정](Scaling.md)
+ **[가장 좋음] **시간 경과에 따른 추세 모니터링은 특정 시점에 모니터링할 경우 눈에 띄지 않는 워크로드 변경을 감지하는 데 도움이 될 수 있습니다. 장기적인 추세를 감지하려면 CloudWatch 지표를 사용하여 더 긴 시간 범위를 스캔하세요. 장기간의 CloudWatch 지표를 관찰하면서 얻은 교훈은 클러스터 리소스 사용률에 대한 예측에 도움이 될 것입니다. CloudWatch 데이터 포인트 및 지표는 최대 455일 동안 사용할 수 있습니다.
**[리소스]:**
+ [CloudWatch 지표를 사용한 ElastiCache 모니터링](CacheMetrics.md)
+ [CloudWatch 지표를 사용한 Memcached 모니터링](CacheMetrics.md)
+ [Amazon CloudWatch를 사용하는 ElastiCache 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[가장 좋음]** CloudFormation으로 ElastiCache 리소스를 생성하는 경우 CloudFormation 템플릿을 사용하여 변경을 수행함으로써 운영 일관성을 유지하고 관리되지 않는 구성 변경 사항 및 스택 편차를 방지하는 것이 가장 좋습니다.
**[리소스]:**
+ [CloudFormation에 대한 ElastiCache 리소스 유형 참조](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[가장 좋음]** 클러스터 운영 데이터를 사용하여 규모 조정 작업을 자동화하고 CloudWatch에서 임계값을 정의하여 경고를 설정합니다. CloudWatch Events 및 Simple Notification Service(SNS)를 사용하여 Lambda 함수를 트리거하고 ElastiCache API를 실행하여 클러스터의 크기를 자동으로 조정합니다. `EngineCPUUtilization` 지표가 장기간 80%에 도달하면 클러스터에 샤드를 추가하는 경우를 예로 들 수 있습니다. 또 다른 옵션은 메모리 기반 임계값에 `DatabaseMemoryUsedPercentages`를 사용하는 것입니다.
**[리소스]:**
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch Events란?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon Simple Notification Service에서 AWS Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)
+ [ElastiCache API 참조](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
## OE 3: ElastiCache 클러스터 리소스를 관리하고 클러스터를 최신 상태로 유지하려면 어떻게 해야 하나요?
**질문 수준의 소개: **규모에 맞게 운영하려면 모든 ElastiCache 리소스를 정확히 찾아내고 식별할 수 있어야 합니다. 새 애플리케이션 기능을 배포할 때는 개발, 테스트, 프로덕션 등 모든 ElastiCache 환경 유형에서 클러스터 버전 대칭을 만들어야 합니다. 리소스 속성을 사용하면 새 기능을 배포하거나 새 보안 메커니즘을 활성화하는 등 다양한 운영 목표에 맞게 환경을 분리할 수 있습니다.
**질문 수준의 이점: **개발, 테스트 및 프로덕션 환경을 분리하는 것이 운영 모범 사례입니다. 또한 잘 이해되고 문서화된 프로세스를 사용하여 환경 전반의 클러스터와 노드에 최신 소프트웨어 패치를 적용하는 것이 가장 좋습니다. 네이티브 ElastiCache 기능을 활용하면 엔지니어링 팀이 ElastiCache 유지 관리가 아닌 비즈니스 목표를 달성하는 데 집중할 수 있습니다.
+ **[가장 좋음]** 사용 가능한 최신 엔진 버전에서 실행하고 셀프 서비스 업데이트가 출시되는 즉시 적용합니다. ElastiCache는 클러스터의 지정된 유지 관리 기간 동안 기본 인프라를 자동으로 업데이트합니다. 하지만 클러스터에서 실행 중인 노드는 셀프 서비스 업데이트를 통해 업데이트됩니다. 이러한 업데이트에는 보안 패치 또는 소프트웨어 소규모 업데이트의 두 가지 유형이 있습니다. 패치 유형과 적용 시기의 차이를 이해해야 합니다.
**[리소스]:**
+ [Amazon ElastiCache의 셀프 서비스 업데이트](Self-Service-Updates.md)
+ [Amazon ElastiCache 관리형 유지 관리 및 서비스 업데이트 도움말 페이지](https://aws.amazon.com/elasticache/elasticache-maintenance/)
+ **[가장 좋음]** 태그를 사용하여 ElastiCache 리소스를 구성합니다. 개별 노드가 아닌 복제 그룹에 태그를 사용합니다. 리소스를 쿼리할 때 표시되도록 태그를 구성하고 태그를 사용하여 검색을 수행하고 필터를 적용할 수 있습니다. 일반적인 태그 세트를 공유하는 리소스 모음을 쉽게 만들고 유지 관리하려면 리소스 그룹을 만들어야 합니다.
**[리소스]:**
+ [태깅 모범 사례](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)
+ [CloudFormation에 대한 ElastiCache 리소스 유형 참조](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [파라미터 그룹](ParameterGroups.Engine.md#ParameterGroups.Redis)
## OE 4: ElastiCache 클러스터에 대한 클라이언트의 연결을 어떻게 관리하나요?
**질문 수준의 소개: **규모에 맞게 운영할 때는 클라이언트가 ElastiCache 클러스터와 연결하여 애플리케이션 운영 측면(예: 응답 시간)을 관리하는 방법을 이해해야 합니다.
**질문 수준의 이점: **가장 적절한 연결 메커니즘을 선택하면 시간 초과와 같은 연결 오류로 인해 애플리케이션 연결이 끊기지 않습니다.
+ **[필수]** 읽기와 쓰기 작업을 분리하고 복제본 노드에 연결하여 읽기 작업을 실행합니다. 그러나 쓰기와 읽기를 분리하면 Valkey 및 Redis OSS 복제의 비동기적 특성으로 인해 쓰기 직후에 키를 읽을 수 없게 된다는 점에 유의하시기 바랍니다. WAIT 명령을 사용하면 실제 데이터 안전성을 향상하고 복제본이 클라이언트에 응답하기 전에 쓰기를 확인하도록 강제할 수 있지만, 전반적인 성능 저하가 발생할 수 있습니다. 클러스터 모드가 비활성화된 경우, ElastiCache 리더 엔드포인트를 사용하여 ElastiCache 클라이언트 라이브러리에서 읽기 작업에 복제본 노드를 사용하도록 구성할 수 있습니다. 클러스터 모드가 활성화된 경우, READONLY 명령을 사용합니다. 많은 ElastiCache 클라이언트 라이브러리에서 READONLY는 기본적으로 또는 구성 설정을 통해 구현됩니다.
**[리소스]:**
+ [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md)
+ [READONLY](https://valkey.io/commands/readonly)
+ **[필수] **연결 풀링을 사용합니다. TCP 연결을 설정하면 클라이언트와 서버 측 모두에서 CPU 시간이 소모되며 풀링을 통해 TCP 연결을 재사용할 수 있습니다.
연결 오버헤드를 줄이려면 연결 풀링을 사용해야 합니다. 연결 풀을 사용하면 애플리케이션에서 연결 설정 비용 없이 '마음대로' 연결을 재사용하고 연결을 해제할 수 있습니다. ElastiCache 클라이언트 라이브러리(지원되는 경우)를 통해 애플리케이션 환경에 사용 가능한 프레임워크를 사용하여 연결 풀링을 구현하거나 처음부터 구축할 수 있습니다.
+ **[가장 좋음]** 클라이언트의 소켓 제한 시간이 최소 1초로 설정되어 있는지 확인합니다. 몇몇 클라이언트의 일반적인 기본값인 '없음'으로 설정되어 있으면 안 됩니다.
+ 제한 시간 값을 너무 낮게 설정하면 서버 로드가 높을 때 시간 초과가 발생할 수 있습니다. 너무 높게 설정하면 애플리케이션에서 연결 문제를 감지하는 데 시간이 오래 걸릴 수 있습니다.
+ 클라이언트 애플리케이션에서 연결 풀링을 구현하여 새 연결의 볼륨을 제어합니다. 이렇게 하면 클러스터에서 TLS가 활성화된 경우 연결을 열고 닫으며 TLS 핸드셰이크를 수행하는 데 필요한 지연 시간과 CPU 사용률이 줄어듭니다.
**[리소스]:** [더 높은 가용성을 위해 ElastiCache 구성](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ **[좋음]** (사용 사례에서 가능한 경우) 파이프라이닝을 사용하면 성능이 크게 향상될 수 있습니다.
+ 파이프라이닝을 사용하면 애플리케이션 클라이언트와 클러스터 간의 왕복 시간(RTT)이 줄어들고 클라이언트가 아직 이전 응답을 읽지 않은 경우에도 새 요청을 처리할 수 있습니다.
+ 파이프라이닝을 사용하면 응답/확인을 기다리지 않고 서버에 여러 명령을 보낼 수 있습니다. 파이프라이닝의 단점은 결국 모든 응답을 대량으로 가져올 때 끝에 가서야 잡을 수 있는 오류가 있을 수 있다는 점입니다.
+ 잘못된 요청을 생략하는 오류가 반환될 때 요청을 재시도하는 메서드를 구현합니다.
**[리소스]:** [파이프라이닝](https://valkey.io/topics/pipelining/)
## OE 5: 워크로드에 대해 ElastiCache 구성 요소를 어떻게 배포하나요?
**질문 수준의 소개: **ElastiCache 환경은 AWS 콘솔을 통해 수동으로 배포하거나 API, CLI, 툴킷 등을 통해 프로그래밍 방식으로 배포할 수 있습니다. 운영 우수성 모범 사례에서는 가능하면 코드를 통해 배포를 자동화하는 것을 권장합니다. 또한 ElastiCache 클러스터를 워크로드별로 분리하거나 비용 최적화를 위해 결합할 수 있습니다.
**질문 수준의 이점: **ElastiCache 환경에 가장 적합한 배포 메커니즘을 선택하면 시간이 지남에 따라 운영 우수성을 개선할 수 있습니다. 인적 오류를 최소화하고 반복성, 유연성 및 이벤트에 대한 응답 시간을 향상하기 위해서는 가능하면 코드로 작업을 수행하는 것이 좋습니다.
워크로드 격리 요구 사항을 이해하면 워크로드당 전용 ElastiCache 환경을 사용하거나 여러 워크로드를 단일 클러스터 또는 이들의 조합으로 결합할 수 있습니다. 장단점을 이해하면 운영 우수성과 비용 최적화 간의 균형을 맞추는 데 도움이 될 수 있습니다.
+ **[필수]** ElastiCache에서 사용할 수 있는 배포 옵션을 이해하고 가능하면 이러한 절차를 자동화합니다. 가능한 자동화 수단으로는 CloudFormation, AWS CLI/SDK 및 API가 있습니다.
**[리소스]: **
+ [Amazon ElastiCache 리소스 유형 참조](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
+ [Amazon ElastiCache API 참조](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[필수]** 모든 워크로드에 대해 필요한 클러스터 격리 수준을 결정합니다.
+ **[가장 좋음]:** 높은 수준의 격리 - 워크로드와 클러스터를 1:1로 매핑합니다. 워크로드별로 ElastiCache 리소스의 액세스, 크기 조정, 규모 조정 및 관리를 가장 세밀하게 제어할 수 있습니다.
+ **[더 좋음]:** 중간 수준의 격리 - 목적별로 M:1로 격리하지만 여러 워크로드 간에 공유될 수 있습니다(예: 워크로드 캐싱 전용 클러스터와 메시징 전용 클러스터).
+ **[좋음]:** 낮은 수준의 격리 - M:1 격리로 다용도로 사용하며 완전히 공유합니다. 공유 액세스가 허용되는 워크로드에 권장됩니다.
## OE 6: 장애를 어떻게 대비하고 완화할 계획인가요?
**질문 수준의 소개: **운영 우수성에는 잠재적 장애 원인을 식별하여 제거하거나 완화할 수 있도록 정기적으로 '사전 검토' 훈련을 수행하여 장애를 예측하는 것이 포함됩니다. ElastiCache는 테스트 목적으로 노드 장애 이벤트를 시뮬레이션할 수 있는 장애 조치 API를 제공합니다.
**질문 수준의 이점: **장애 시나리오를 미리 테스트하면 장애 시나리오가 워크로드에 미치는 영향을 파악할 수 있습니다. 이를 통해 대응 절차와 그 효과를 안전하게 테스트할 수 있을 뿐만 아니라 팀이 대응 절차 실행에 익숙해질 수 있습니다.
**[필수]** 개발 및 테스트 계정에서 정기적으로 장애 조치 테스트를 수행합니다. [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
## OE 7: Valkey 또는 Redis OSS 엔진 이벤트 문제를 어떻게 해결하나요?
**질문 수준의 소개: **운영 우수성을 위해서는 서비스 수준 및 엔진 수준 정보를 모두 조사하여 클러스터의 상태를 분석할 수 있어야 합니다. ElastiCache는 Amazon CloudWatch와 Amazon Kinesis Data Firehose에 Valkey 또는 Redis OSS 엔진 로그를 보낼 수 있습니다.
**질문 수준의 이점: **ElastiCache 클러스터에서 Valkey 또는 Redis OSS 엔진 로그를 활성화하면 클러스터의 상태 및 성능에 영향을 미치는 이벤트를 파악할 수 있습니다. Valkey 또는 Redis OSS 엔진 로그는 ElastiCache 이벤트 메커니즘을 통해 사용할 수 없는 데이터를 엔진에서 직접 제공합니다. ElastiCache 이벤트(위 OE-1 참조)와 엔진 로그를 주의 깊게 관찰하면 문제 해결 시 ElastiCache 서비스 관점과 엔진 관점에서 이벤트 순서를 판단할 수 있습니다.
+ **[필수]** Redis OSS 엔진 로깅 기능이 활성화되었는지 확인합니다. 이 기능은 Redis OSS에 대해 ElastiCache 버전 6.2 이상부터 사용할 수 있습니다. 클러스터 생성 중에 또는 생성 후 클러스터를 수정하여 이 작업을 수행할 수 있습니다.
+ Amazon CloudWatch Logs 또는 Amazon Kinesis Data Firehose가 Redis OSS 엔진 로그의 적절한 대상인지 확인합니다.
+ 로그를 유지하려면 CloudWatch 또는 Kinesis Data Firehose에서 적절한 대상 로그를 선택합니다. 클러스터가 여러 개 있는 경우, 문제 해결 시 데이터를 분리하는 데 도움이 되므로 클러스터마다 다른 대상 로그를 사용하는 것이 좋습니다.
**[리소스]:**
+ 로그 전달: [로그 전달](Log_Delivery.md)
+ 로깅 대상: [Amazon CloudWatch Logs](Logging-destinations.md#Destination_Specs_CloudWatch_Logs)
+ Amazon CloudWatch Logs 소개: [Amazon CloudWatch Logs란 무엇인가요?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ Amazon Kinesis Data Firehose 소개: [Amazon Kinesis Data Firehose란 무엇인가요?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
+ **[가장 좋음]** Amazon CloudWatch Logs를 사용하는 경우 Amazon CloudWatch Logs Insights를 활용하여 Valkey 또는 Redis OSS 엔진 로그에서 중요한 정보를 쿼리하는 것을 고려합니다.
예를 들어, 다음과 같이 LogLevel이 'WARNING'인 이벤트를 반환하는 Valkey 또는 Redis OSS 엔진 로그가 포함된 CloudWatch 로그 그룹에 대한 쿼리를 생성합니다.
```
fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"
```
**[리소스]:** [CloudWatch 로그 인사이트를 사용한 로그 데이터 분석](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
# Amazon ElastiCache의 Well-Architected Lens 보안 요소
보안 요소는 정보 및 시스템 보호에 중점을 둡니다. 주요 주제로는 데이터의 기밀성 및 무결성, 권한 기반의 관리를 통해 누가 무엇을 할 수 있는지 식별 및 관리하기, 시스템 보호하기, 보안 이벤트 탐지를 위한 제어 설정하기 등이 있습니다.
**Topics**
+ [SEC 1: ElastiCache 데이터에 대한 승인된 액세스를 제어하기 위해 어떤 조치를 취하고 있나요?](#SecurityPillarSEC1)
+ [SEC 2: 네트워킹 기반 제어를 넘어 ElastiCache에 대한 추가 권한 부여가 애플리케이션에 필요한가요?](#SecurityPillarSEC2)
+ [SEC 3: 명령이 실수로 실행되어 데이터 손실이나 장애가 발생할 위험이 있나요?](#SecurityPillarSEC3)
+ [SEC 4: ElastiCache를 사용하여 저장 데이터를 암호화하려면 어떻게 해야 하나요?](#SecurityPillarSEC4)
+ [SEC 5: ElastiCache를 사용하여 전송 중인 데이터를 어떻게 암호화하나요?](#SecurityPillarSEC5)
+ [SEC 6: 컨트롤 플레인 리소스에 대한 액세스를 어떻게 제한하나요?](#SecurityPillarSEC6)
+ [SEC 7: 보안 이벤트를 어떻게 감지하고 이에 대응하나요?](#SecurityPillarSEC7)
## SEC 1: ElastiCache 데이터에 대한 승인된 액세스를 제어하기 위해 어떤 조치를 취하고 있나요?
**질문 수준의 소개: **모든 ElastiCache 클러스터는 VPC, 서버리스 함수(AWS Lambda) 또는 컨테이너(Amazon Elastic Container Service)의 Amazon Elastic Compute Cloud 인스턴스에서 액세스할 수 있도록 설계되었습니다. 가장 자주 접하는 시나리오는 동일한 Amazon Virtual Private Cloud(Amazon VPC) 내의 Amazon Elastic Compute Cloud 인스턴스에서 ElastiCache 클러스터에 액세스하는 것입니다. Amazon EC2 인스턴스에서 클러스터에 연결하려면 Amazon EC2 인스턴스가 클러스터에 액세스하도록 권한을 부여해야 합니다. VPC에서 실행 중인 ElastiCache 클러스터에 액세스하려면 클러스터에 네트워크 수신을 허용해야 합니다.
**질문 수준의 이점: **클러스터로의 네트워크 수신은 VPC 보안 그룹을 통해 제어됩니다. 보안 그룹은 Amazon EC2 인스턴스에 대한 수신 및 발신 트래픽을 제어하는 가상 방화벽 역할을 합니다. 인바운드 규칙은 인스턴스로 들어오는 트래픽을 제어하고 아웃바운드 규칙은 인스턴스에서 나가는 트래픽을 제어합니다. ElastiCache의 경우, 클러스터를 시작할 때 보안 그룹을 연결해야 합니다. 이렇게 하면 클러스터를 구성하는 모든 노드에 대해 인바운드 및 아웃바운드 트래픽 규칙이 적용됩니다. 또한 ElastiCache는 VPC의 프라이빗 네트워킹을 통해서만 액세스할 수 있게 하기 위해 프라이빗 서브넷에만 배포되도록 구성되어 있습니다.
+ **[필수] **클러스터와 연결된 보안 그룹은 클러스터에 대한 네트워크 수신 및 액세스를 제어합니다. 기본적으로 보안 그룹에는 인바운드 규칙이 정의되어 있지 않으므로 ElastiCache로의 수신 경로가 없습니다. 이를 활성화하려면 소스 IP 주소/범위, TCP 유형 트래픽 및 ElastiCache 클러스터용 포트(예: ElastiCache for Valkey 및 Redis OSS의 기본 포트 6379)를 지정하여 보안 그룹에 인바운드 규칙을 구성합니다. VPC 내의 모든 리소스(0.0.0.0/0)와 같이 매우 광범위한 수신 소스 세트를 허용할 수 있지만, 특정 보안 그룹과 연결된 Amazon EC2 인스턴스에서 실행 중인 Valkey 또는 Redis OSS 클라이언트에 대한 인바운드 액세스만 승인하는 등 인바운드 규칙을 최대한 세분화하는 것이 좋습니다.
**[리소스]: **
+ [서브넷 및 서브넷 그룹](SubnetGroups.md)
+ [클러스터 또는 복제 그룹에 액세스](accessing-elasticache.md)
+ [보안 그룹을 사용하여 리소스에 대한 트래픽 제어](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#DefaultSecurityGroupdefault%20security%20group)
+ [Linux 인스턴스용 Amazon Elastic Compute Cloud 보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#creating-your-own-security-groups)
+ **[필수] **AWS Identity and Access Management 정책을 AWS Lambda 함수에 할당하여 ElastiCache 데이터 액세스를 허용할 수 있습니다. 이 기능을 활성화하려면 `AWSLambdaVPCAccessExecutionRole` 권한이 있는 IAM 실행 역할을 생성한 다음, 해당 역할을 AWS Lambda 함수에 할당해야 합니다.
**[리소스]: **Amazon VPC에서 Amazon ElastiCache에 액세스하도록 Lambda 함수 구성: [자습서: Amazon VPC에서 Amazon ElastiCache에 액세스하도록 Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html)
## SEC 2: 네트워킹 기반 제어를 넘어 ElastiCache에 대한 추가 권한 부여가 애플리케이션에 필요한가요?
**질문 수준의 소개: **개별 클라이언트 수준에서 클러스터에 대한 액세스를 제한하거나 제어해야 하는 시나리오에서는 AUTH 명령을 통해 인증하는 것이 좋습니다. 선택적인 사용자 및 사용자 그룹 관리 기능이 포함된 ElastiCache 인증 토큰을 사용하면 클라이언트가 명령 및 액세스 키를 실행하도록 허용하기 전에 ElastiCache가 암호를 요구하므로 데이터 플레인 보안을 개선할 수 있습니다.
**질문 수준의 이점: **데이터를 안전하게 유지하기 위해 ElastiCache는 데이터에 대한 무단 액세스를 방지하는 메커니즘을 제공합니다. 여기에는 인증된 명령을 수행하기 전에 클라이언트가 ElastiCache에 연결할 때 역할 기반 액세스 제어(RBAC) AUTH 또는 AUTH 토큰(암호)을 사용하도록 강제하는 것이 포함됩니다.
+ **[가장 좋음] **ElastiCache for Redis OSS 버전 6.x 이상 또는 ElastiCache for Valkey 버전 7.2 이상의 경우 사용자 그룹, 사용자 및 액세스 문자열을 정의하여 인증 및 권한 부여 제어를 정의합니다. 사용자를 사용자 그룹에 할당한 다음, 클러스터에 사용자 그룹을 할당합니다. RBAC를 사용하려면 클러스터 생성 시 RBAC를 선택하고 전송 중 암호화를 활성화해야 합니다. RBAC를 활용할 수 있으려면 TLS를 지원하는 Valkey 또는 Redis OSS 클라이언트를 사용해야 합니다.
**[리소스]: **
+ [ElastiCache에 대한 복제 그룹에 RBAC 적용](Clusters.RBAC.md#rbac-using)
+ [액세스 문자열을 사용하여 권한 지정](Clusters.RBAC.md#Access-string)
+ [ ACL](https://valkey.io/topics/acl/)
+ [지원되는 ElastiCache 버전](VersionManagement.md#supported-engine-versions)
+ **[가장 좋음] **6.x 이전 버전의 ElastiCache for Redis 6.x 이전 버전의 경우, 강력한 토큰/암호를 설정하고 AUTH에 대해 엄격한 암호 정책을 유지하는 것 외에도 암호/토큰을 교체하는 것이 가장 좋습니다. ElastiCache는 언제든지 최대 2개의 인증 토큰을 관리할 수 있습니다. 인증 토큰 사용을 명시적으로 요구하도록 클러스터를 수정할 수도 있습니다.
**[리소스]: **[기존 ElastiCache 클러스터에서 AUTH 토큰 수정](auth.md#auth-modifyng-token)
## SEC 3: 명령이 실수로 실행되어 데이터 손실이나 장애가 발생할 위험이 있나요?
**질문 수준의 소개: **실수로 실행하거나 악의적인 공격자가 실행할 경우 운영에 부정적인 영향을 미칠 수 있는 Valkey 또는 Redis OSS 명령이 많이 있습니다. 이러한 명령은 성능 및 데이터 안전 관점에서 의도하지 않은 결과를 초래할 수 있습니다. 예를 들어 개발자가 개발 환경에서 일상적으로 FLUSHALL 명령을 호출할 수 있는데, 실수로 인해 프로덕션 시스템에서 실수로 이 명령을 호출하려고 시도하여 우발적으로 데이터가 손실될 수 있습니다.
**질문 수준의 이점: **ElastiCache for Redis OSS 버전 5.0.3부터 워크로드에 지장을 줄 수 있는 특정 명령의 이름을 변경할 수 있습니다. 명령의 이름을 바꾸면 클러스터에서 실수로 명령이 실행되는 것을 방지할 수 있습니다.
+ **[필수] **
**[리소스]: **
+ [ElastiCache for Redis OSS 버전 5.0.3(사용 중단, 버전 5.0.6 사용)](engine-versions.md#redis-version-5-0.3)
+ [ElastiCache for Redis OSS 버전 5.0.3 파라미터 변경](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3)
+ [Redis OSS 보안](https://redis.io/docs/management/security/)
## SEC 4: ElastiCache를 사용하여 저장 데이터를 암호화하려면 어떻게 해야 하나요?
**질문 수준의 소개: **ElastiCache는 인메모리 데이터 저장소이지만 클러스터의 표준 작업의 일부로 스토리지에 유지될 수 있는 모든 데이터를 암호화할 수 있습니다. 여기에는 Amazon S3에 기록된 정기 백업과 수동 백업뿐 아니라 동기화 및 스왑 작업의 결과로 디스크 스토리지에 저장된 데이터가 포함됩니다. M6g 및 R6g 패밀리의 인스턴스 유형에는 상시 켜져 있는 인메모리 암호화 기능도 있습니다.
**질문 수준의 이점: **ElastiCache는 데이터 보안을 강화하기 위해 저장 시 암호화를 선택적으로 제공합니다.
+ **[필수] **저장 데이터 암호화는 ElastiCache 클러스터(복제 그룹)를 생성할 때만 클러스터에서 활성화할 수 있습니다. 기존 클러스터를 수정하여 저장 데이터 암호화를 시작할 수 없습니다. 기본적으로 ElastiCache는 저장 데이터 암호화에 사용되는 키를 제공하고 관리합니다.
**[리소스]: **
+ [미사용 데이터 암호화 제약 조건](at-rest-encryption.md#at-rest-encryption-constraints)
+ [저장 데이터 암호화 활성화](at-rest-encryption.md#at-rest-encryption-enable)
+ **[가장 좋음] **메모리에 있는 데이터를 암호화하는 Amazon EC2 인스턴스 유형(예: M6g 또는 R6g)을 활용합니다. 가능하면 저장 데이터 암호화를 위해 자체 키를 관리하는 것이 좋습니다. 보다 엄격한 데이터 보안 환경의 경우, AWS Key Management Service(KMS)를 사용하여 고객 마스터 키(CMK)를 자체 관리할 수 있습니다. AWS Key Management Service와의 ElastiCache 통합을 통해 ElastiCache 클러스터의 저장 데이터를 암호화하는 데 사용되는 키를 생성, 소유 및 관리할 수 있습니다.
**[리소스]: **
+ [에서 고객 관리형 키 사용AWS Key Management Service](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)
+ [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
+ [AWS KMS 개념](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)
## SEC 5: ElastiCache를 사용하여 전송 중인 데이터를 어떻게 암호화하나요?
**질문 수준의 소개: **전송 중에 데이터가 손상되는 것을 방지하는 것은 일반적인 요구 사항입니다. 이는 분산 시스템의 구성 요소 내 데이터뿐만 아니라 애플리케이션 클라이언트와 클러스터 노드 간의 데이터를 나타냅니다. ElastiCache는 클라이언트와 클러스터 간 및 클러스터 노드 간에 전송 중 데이터를 암호화할 수 있도록 하여 이러한 요구 사항을 지원합니다. M6g 및 R6g 패밀리의 인스턴스 유형에는 상시 켜져 있는 인메모리 암호화 기능도 있습니다.
**질문 수준의 이점: **Amazon ElastiCache의 전송 중 데이터 암호화는 선택적 기능으로, 가장 취약한 지점 즉, 한 위치에서 다른 위치로 데이터를 전송할 때 데이터의 보안을 강화합니다.
+ **[필수] **전송 중 암호화는 클러스터(복제 그룹) 생성 시에만 클러스터에서 활성화할 수 있습니다. 데이터 암호화/복호화에 추가 처리가 필요하기 때문에 전송 중 암호화를 구현하면 성능에 어느 정도 영향을 미칠 수 있다는 점에 유의하시기 바랍니다. 영향을 이해하려면 전송 중 암호화를 활성화하기 전과 후에 워크로드를 벤치마킹하는 것이 좋습니다.
**[리소스]: **
+ [전송 중 데이터 암호화 개요](in-transit-encryption.md#in-transit-encryption-overview)
## SEC 6: 컨트롤 플레인 리소스에 대한 액세스를 어떻게 제한하나요?
**질문 수준의 소개: **IAM 정책과 ARN을 통해 ElastiCache for Valkey 및 Redis OSS에 대한 세밀한 액세스 제어가 가능하므로 클러스터의 생성, 수정 및 삭제를 보다 엄격하게 관리할 수 있습니다.
**질문 수준의 이점: **복제 그룹, 노드 등 Amazon ElastiCache 리소스의 관리를 IAM 정책에 따라 특정 권한이 있는 AWS 계정으로 제한하여 리소스의 보안과 신뢰성을 개선할 수 있습니다.
+ **[필수] **특정 AWS Identity and Access Management 정책을 AWS 사용자에게 할당하여 Amazon ElastiCache 리소스에 대한 액세스를 관리함으로써 어떤 계정이 클러스터에서 어떤 작업을 수행할 수 있는지 더 세밀하게 제어합니다.
**[리소스]: **
+ [ElastiCache 리소스에 대한 액세스 권한 관리 개요](IAM.Overview.md)
+ [Amazon ElastiCache에 대한 자격 증명 기반 정책(IAM 정책) 사용](IAM.IdentityBasedPolicies.md)
## SEC 7: 보안 이벤트를 어떻게 감지하고 이에 대응하나요?
**질문 수준의 소개: **ElastiCache는 RBAC를 활성화한 상태로 배포할 경우 CloudWatch 지표를 내보내 사용자에게 보안 이벤트를 알립니다. 이러한 지표는 실패한 인증 시도, 키 액세스 시도, RBAC 사용자 연결 권한이 없는 명령 실행 시도를 식별하는 데 도움이 됩니다.
또한 AWS 제품 및 서비스 리소스는 배포를 자동화하고 추후 검토 및 감사를 위해 모든 작업 및 수정 사항을 로깅하여 전체 워크로드를 보호하는 데 도움이 됩니다.
**질문 수준의 이점: **이벤트를 모니터링하면 조직이 요구 사항, 정책 및 절차에 따라 대응할 수 있습니다. 이러한 보안 이벤트에 대한 모니터링 및 대응을 자동화하면 전반적인 보안 태세가 강화됩니다.
+ **[필수] **RBAC 인증 및 권한 부여 실패와 관련하여 게시된 CloudWatch 지표를 숙지합니다.
+ AuthenticationFailures = Valkey 또는 Redis OSS에 대한 인증 시도 실패
+ KeyAuthorizationFailures = 사용자가 권한 없이 키에 액세스하려는 시도 실패
+ CommandAuthorizationFailures = 사용자가 권한 없이 명령을 실행하려는 시도 실패
**[리소스]: **
+ [Valkey 또는 Redis OSS에 대한 지표](CacheMetrics.Redis.md)
+ **[가장 좋음] **이러한 지표에 대한 경고 및 알림을 설정하고 필요에 따라 대응하는 것이 좋습니다.
**[리소스]: **
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ **[가장 좋음] **Valkey 또는 Redis OSS ACL LOG 명령을 사용하여 추가 세부 정보를 수집합니다.
**[리소스]: **
+ [ACL 로그](https://valkey.io/commands/acl-log/)
+ **[가장 좋음] **ElastiCache 배포 및 이벤트의 모니터링, 로깅 및 분석과 관련된 AWS 제품 및 서비스 기능을 숙지합니다.
**[리소스]: **
+ [AWS CloudTrail을 사용하여 Amazon ElastiCache API 호출 로깅](logging-using-cloudtrail.md)
+ [elasticache-redis-cluster-automatic-backup-check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)
+ [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md)
# Amazon ElastiCache의 Well-Architected Lens 신뢰성 요소
신뢰성 요소는 의도한 기능을 수행하는 워크로드와 수요를 충족하기 위해 실패에서 빠르게 복구하는 방법에 중점을 둡니다. 주요 주제에는 분산 시스템 설계, 복구 계획 및 변화하는 요구 사항에 대한 적응이 포함됩니다.
**Topics**
+ [REL 1: 고가용성(HA) 아키텍처 배포를 어떻게 지원하고 있나요?](#ReliabilityPillarREL1)
+ [REL 2: ElastiCache를 사용하여 Recovery Point Objective(RPO)를 어떻게 달성하고 있나요?](#ReliabilityPillarREL2)
+ [REL 3: 재해 복구(DR) 요구 사항을 어떻게 지원하나요?](#ReliabilityPillarREL3)
+ [REL 4: 장애 조치를 어떻게 효과적으로 계획하나요?](#ReliabilityPillarREL4)
+ [REL 5: ElastiCache 구성 요소가 규모를 조정하도록 설계되었나요?](#ReliabilityPillarREL5)
## REL 1: 고가용성(HA) 아키텍처 배포를 어떻게 지원하고 있나요?
**질문 수준의 소개: **Amazon ElastiCache의 고가용성 아키텍처를 이해하면 가용성 이벤트 발생 시에도 탄력적인 상태로 운영할 수 있습니다.
**질문 수준의 이점: **장애에 대한 복원력을 갖추도록 ElastiCache 클러스터를 설계하면 ElastiCache 배포의 가용성을 높일 수 있습니다.
+ **[필수] **ElastiCache 클러스터에 필요한 신뢰성 수준을 결정합니다. 완전히 일시적인 워크로드부터 미션 크리티컬 워크로드까지 워크로드마다 복원력에 대한 표준이 다릅니다. 개발, 테스트, 프로덕션 등 운영 환경의 각 유형에 대한 요구 사항을 정의합니다.
캐싱 엔진: ElastiCache for Memcached와 ElastiCache for Valkey 및 Redis OSS 비교
1. ElastiCache for Memcached는 복제 메커니즘을 제공하지 않으며 주로 임시 워크로드에 사용됩니다.
1. ElastiCache for Valkey 및 Redis OSS는 아래에 설명된 HA 기능을 제공합니다.
+ **[가장 좋음] **HA가 필요한 워크로드의 경우 샤드당 최소 2개의 복제본이 있는 클러스터 모드에서 ElastiCache를 사용합니다. 처리량에 대한 요구 사항이 적어 단 하나의 샤드만 필요한 워크로드의 경우에도 마찬가지입니다.
1. 클러스터 모드를 활성화하면 다중 AZ가 자동으로 활성화됩니다.
다중 AZ는 계획되거나 계획되지 않은 유지 관리 시 프라이머리 노드에서 복제본으로 자동 장애 조치를 수행하고 AZ 장애를 완화하여 가동 중지 시간을 최소화합니다.
1. Valkey 또는 Redis OSS Cluster Protocol에서는 쿼럼을 달성하기 위해 대부분의 프라이머리 노드를 사용할 수 있어야 하므로 샤딩된 워크로드의 경우 최소 3개의 샤드가 장애 조치 이벤트 시 더 빠른 복구를 제공합니다.
1. 가용성 전체에서 두 개 이상의 복제본을 설정합니다.
복제본이 두 개 있으면 읽기 확장성이 향상되고 하나의 복제본이 유지 관리되는 시나리오에서도 읽기 가용성이 향상됩니다.
1. Graviton2 기반 노드 유형(대부분 리전의 프라이머리 노드)을 사용합니다.
ElastiCache는 이러한 노드에 최적화된 성능을 추가했습니다. 따라서 복제 및 동기화 성능이 향상되어 전반적인 가용성이 향상됩니다.
1. 예상되는 트래픽 피크에 대처하기 위한 모니터링 및 적절한 크기 조정: 로드가 심한 경우 엔진이 응답하지 않아 가용성에 영향을 미칠 수 있습니다. `BytesUsedForCache` 및 `DatabaseMemoryUsagePercentage`는 메모리 사용량을 나타내는 좋은 지표이며 `ReplicationLag`는 쓰기 속도를 기반으로 복제 상태를 나타내는 지표입니다. 이러한 지표를 사용하여 클러스터 규모 조정을 트리거할 수 있습니다.
1. [프로덕션 장애 조치 이벤트 전에 장애 조치 API](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html)로 테스트하여 클라이언트 측 복원력을 보장합니다.
**[리소스]: **
+ [더 높은 가용성을 위해 ElastiCache for Redis OSS 구성](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [고가용성을 위한 복제 그룹 사용](Replication.md)
## REL 2: ElastiCache를 사용하여 Recovery Point Objective(RPO)를 어떻게 달성하고 있나요?
**질문 수준의 소개: **워크로드 RPO를 이해하여 ElastiCache 백업 및 복구 전략에 대한 의사 결정을 내립니다.
**질문 수준의 이점: **RPO 전략을 수립하면 재해 복구 시나리오 발생 시 비즈니스 연속성을 개선할 수 있습니다. 백업 및 복원 정책을 설계하면 ElastiCache 데이터에 대한 Recovery Point Objective(RPO)를 달성하는 데 도움이 될 수 있습니다. ElastiCache는 구성 가능한 보존 정책과 함께 Amazon S3에 저장되는 스냅샷 기능을 제공합니다. 이러한 스냅샷은 정의된 백업 기간 동안 생성되며 서비스에서 자동으로 처리됩니다. 워크로드에 추가적인 백업 세분화가 필요한 경우, 하루에 최대 20개의 수동 백업을 생성할 수 있습니다. 수동으로 생성한 백업에는 서비스 보존 정책이 없으며 무기한으로 보관할 수 있습니다.
+ **[필수] **ElastiCache 배포의 RPO를 이해하고 문서화합니다.
+ Memcached는 백업 프로세스를 제공하지 않는다는 점에 유의하시기 바랍니다.
+ ElastiCache 백업 및 복원 기능을 검토합니다.
+ **[가장 좋음] **클러스터를 백업하기 위해 소통과 합의를 통해 프로세스를 마련합니다.
+ 필요에 따라 수동 백업을 시작합니다.
+ 자동 백업에 대한 보존 정책을 검토합니다.
+ 수동 백업은 무기한으로 보존된다는 점에 유의하시기 바랍니다.
+ 사용량이 적은 시간대에 자동 백업을 예약하세요.
+ 읽기 전용 복제본에 대해 백업 작업을 수행하여 클러스터 성능에 미치는 영향을 최소화합니다.
+ **[좋음] **ElastiCache의 예약 백업 기능을 활용하여 지정된 기간 동안 데이터를 정기적으로 백업합니다.
+ 백업에서 정기적으로 복원을 테스트합니다.
+ **[리소스]: **
+ [Redis OSS](https://aws.amazon.com/elasticache/faqs/#Redis)
+ [ElastiCache의 백업 및 복원](backups.md)
+ [수동 백업 만들기](backups-manual.md)
+ [자동 백업 예약](backups-automatic.md)
+ [ElastiCache 클러스터 백업 및 복원](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)
## REL 3: 재해 복구(DR) 요구 사항을 어떻게 지원하나요?
**질문 수준의 소개: **재해 복구는 모든 워크로드 계획에서 중요한 측면입니다. ElastiCache는 워크로드 복원력 요구 사항에 따라 재해 복구를 구현하기 위한 여러 옵션을 제공합니다. Amazon ElastiCache 글로벌 데이터 저장소를 사용하면 한 리전에서 클러스터에 데이터를 쓰고 다른 두 교차 리전 간 복제본 클러스터에서 데이터를 읽을 수 있으므로 읽기 지연 시간이 짧고 리전 전체에서 재해 복구가 가능합니다.
**질문 수준의 이점: **다양한 재해 시나리오를 이해하고 계획하면 비즈니스 연속성을 보장할 수 있습니다. DR 전략은 비용, 성능에 미치는 영향 및 데이터 손실 가능성 사이에서 균형을 맞춰야 합니다.
+ **[필수] **워크로드 요구 사항을 기반으로 모든 ElastiCache 구성 요소에 대한 DR 전략을 개발하고 문서화합니다. ElastiCache가 독특한 점은 일부 사용 사례는 완전히 일시적이어서 DR 전략이 필요하지 않은 반면, 어떤 사용 사례는 스펙트럼의 반대편에 있어서 매우 강력한 DR 전략이 필요하다는 점입니다. 모든 옵션은 비용 최적화와 비교하여 평가해야 합니다. 복원력을 높이려면 더 많은 양의 인프라가 필요합니다.
리전 수준 및 다중 리전 수준에서 사용할 수 있는 DR 옵션을 이해합니다.
+ AZ 장애를 방지하려면 다중 AZ 배포를 권장합니다. 최소 3개의 AZ를 사용할 수 있는 다중 AZ 아키텍처에서 클러스터 모드를 활성화하여 배포해야 합니다.
+ 리전 장애를 방지하려면 글로벌 데이터 스토어를 사용하는 것이 좋습니다.
+ **[가장 좋음] **리전 수준의 복원력이 필요한 워크로드에 글로벌 데이터 스토어를 활성화합니다.
+ 기본 리전에서 성능 저하가 발생할 경우 보조 리전으로 장애 조치를 수행할 계획을 세웁니다.
+ 프로덕션 환경에서 장애 조치를 수행하기 전에 다중 리전 장애 조치 프로세스를 테스트합니다.
+ `ReplicationLag` 지표를 모니터링하여 장애 조치 이벤트 중 데이터 손실의 잠재적 영향을 파악합니다.
+ **[리소스]: **
+ [장애 완화](disaster-recovery-resiliency.md#FaultTolerance)
+ [글로벌 데이터 스토어를 사용한 AWS 리전 간 복제](Redis-Global-Datastore.md)
+ [선택적으로 클러스터 크기를 조정하여 백업에서 복원](backups-restoring.md)
+ [ElastiCache for Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 가동 중지 시간 최소화](AutoFailover.md)
## REL 4: 장애 조치를 어떻게 효과적으로 계획하나요?
**질문 수준의 소개: **자동 장애 조치가 포함된 다중 AZ를 활성화하는 것이 ElastiCache의 모범 사례입니다. 경우에 따라 ElastiCache for Valkey 및 Redis OSS는 서비스 운영의 일부로 프라이머리 노드를 대체합니다. 예를 들면 계획된 유지 관리 이벤트 및 드물지만 노드 장애나 가용 영역 문제가 발생하는 경우가 포함됩니다. 성공적인 장애 조치는 ElastiCache와 클라이언트 라이브러리 구성에 달려 있습니다.
**질문 수준의 이점: **특정 ElastiCache 클라이언트 라이브러리와 함께 ElastiCache 장애 조치의 모범 사례를 따르면 장애 조치 이벤트 중에 발생할 수 있는 가동 중지 시간을 최소화할 수 있습니다.
+ **[필수] **클러스터 모드가 비활성화된 경우, 클라이언트가 이전 프라이머리 노드와의 연결을 끊고 업데이트된 기본 엔드포인트 IP 주소를 사용하여 새 프라이머리 노드에 다시 연결해야 하는지 감지하도록 제한 시간을 사용합니다. 클러스터 모드가 활성화된 경우, 클라이언트 라이브러리가 기본 클러스터 토폴로지의 변경 사항을 감지합니다. 이는 주로 ElastiCache 클라이언트 라이브러리의 구성 설정을 통해 설정할 수 있으며, 구성 설정에서 새로 고침 빈도와 방법도 구성할 수 있습니다. 각 클라이언트 라이브러리는 자체 설정을 제공하며 자세한 내용은 해당 설명서에서 확인할 수 있습니다.
**[리소스]: **
+ [ElastiCache for Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 가동 중지 시간 최소화](AutoFailover.md)
+ ElastiCache 클라이언트 라이브러리의 모범 사례를 검토하세요.
+ **[필수] **성공적인 장애 조치는 프라이머리 노드와 복제본 노드 간의 정상적인 복제 환경에 달려 있습니다. Valkey 또는 Redis OSS 복제의 비동기적 특성 및 프라이머리 노드와 복제본 노드 간의 복제 지연을 보고하는 데 사용할 수 있는 CloudWatch 지표를 검토하고 이해합니다. 더 높은 데이터 안전성이 필요한 사용 사례의 경우 WAIT 명령을 활용하여 연결된 클라이언트에 응답하기 전에 복제본이 쓰기를 강제로 확인하도록 합니다.
**[리소스]: **
+ [Valkey 또는 Redis OSS에 대한 지표](CacheMetrics.Redis.md)
+ [Amazon CloudWatch를 사용하는 ElastiCache 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[가장 좋음] **ElastiCache 테스트 장애 조치 API를 사용하여 장애 조치 중에 애플리케이션의 응답성을 정기적으로 검증합니다.
**[리소스]: **
+ [Amazon ElastiCache의 읽기 전용 복제본에 대한 자동 장애 조치 테스트](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
+ [자동 장애 조치 테스트](AutoFailover.md#auto-failover-test)
## REL 5: ElastiCache 구성 요소가 규모를 조정하도록 설계되었나요?
**질문 수준의 소개: **규모 조정 기능과 사용 가능한 배포 토폴로지를 이해하면 변화하는 워크로드 요구 사항에 맞게 ElastiCache 구성 요소를 시간이 지남에 따라 조정할 수 있습니다. ElastiCache는 스케일 인/아웃(수평)과 스케일 업/다운(수직)의 4방향 규모 조정을 제공합니다.
**질문 수준의 이점: **ElastiCache 배포의 모범 사례를 따르면 규모 조정의 유연성이 극대화될 뿐만 아니라 수평적 규모 조정이라는 Well-Architected 원칙을 충족하여 장애의 영향을 최소화할 수 있습니다.
+ **[필수] **클러스터 모드 활성화 토폴로지와 클러스터 모드 비활성화 토폴로지의 차이점을 이해합니다. 클러스터 모드를 활성화하면 시간이 지남에 따라 확장성 향상이 가능하므로 대부분의 경우에 클러스터 모드를 활성화하여 배포하는 것이 좋습니다. 클러스터 모드가 비활성화된 구성 요소는 읽기 전용 복제본을 추가하여 수평적으로 확장할 수 있는 기능이 제한됩니다.
+ **[필수] **규모 조정 시기 및 방법을 이해합니다.
+ READIOPS 향상: 복제본 추가
+ WRITEOPS 향상: 샤드 추가(스케일 아웃)
+ 네트워크 I/O 향상: 네트워크에 최적화된 인스턴스 사용, 스케일 업
+ **[가장 좋음] **클러스터 모드를 활성화한 상태로 ElastiCache 구성 요소를 배포합니다. 더 적은 수의 더 큰 노드보다는 더 많은 수의 더 작 은 노드를 사용합니다. 이는 노드 장애가 영향을 미치는 범위를 효과적으로 제한합니다.
+ **[가장 좋음] **규모 조정 이벤트 시 응답성을 높이기 위해 클러스터에 복제본을 포함합니다.
+ **[좋음] **클러스터 모드가 비활성화된 경우, 읽기 전용 복제본을 활용하여 전체 읽기 용량을 늘립니다. ElastiCache는 클러스터 모드가 비활성화된 상태에서 최대 5개의 읽기 전용 복제본과 수직적 규모 조정을 지원합니다.
+ **[리소스]: **
+ [ElastiCache 클러스터의 규모 조정](Scaling.md)
+ [온라인 스케일 업](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# Amazon ElastiCache Well-Architected Lens 성능 효율성 요소
성능 효율성 요소는 IT 및 컴퓨팅 리소스를 효율적으로 사용하는 데 중점을 둡니다. 주요 주제로는 워크로드 요구 사항을 기반으로 적절한 리소스 유형 및 크기 선택하기, 성능 모니터링하기, 비즈니스 요구 사항이 변화함에 따라 효율성을 유지하기 위해 정보에 입각하여 의사 결정 내리기가 있습니다.
**Topics**
+ [PE 1: Amazon ElastiCache 클러스터의 성능을 어떻게 모니터링하나요?](#PerformanceEfficiencyPillarPE1)
+ [PE 2: ElastiCache 클러스터 노드에 작업을 어떻게 분배하고 있나요?](#PerformanceEfficiencyPillarPE2)
+ [PE 3: 캐싱 워크로드의 경우, 캐시의 효율성과 성능을 어떻게 추적하고 보고하나요?](#PerformanceEfficiencyPillarPE3)
+ [PE 4: 워크로드가 네트워킹 리소스 및 연결 사용을 어떻게 최적화하나요?](#PerformanceEfficiencyPillarPE4)
+ [PE 5: 키 삭제 또는 제거를 어떻게 관리하나요?](#PerformanceEfficiencyPillarPE5)
+ [PE 6: ElastiCache에서 어떻게 데이터를 모델링하고 데이터와 상호 작용하나요?](#PerformanceEfficiencyPillarPE6)
+ [PE 7: Amazon ElastiCache 클러스터에서 느리게 실행되는 명령을 어떻게 로깅하나요?](#PerformanceEfficiencyPillarPE7)
+ [PE8: Auto Scaling은 ElastiCache 클러스터의 성능을 높이는 데 어떻게 도움이 되나요?](#PerformanceEfficiencyPillarPE8)
## PE 1: Amazon ElastiCache 클러스터의 성능을 어떻게 모니터링하나요?
**질문 수준의 소개: **기존 모니터링 지표를 이해하면 현재 사용률을 파악할 수 있습니다. 적절한 모니터링은 클러스터 성능에 영향을 미치는 잠재적 병목 현상을 식별하는 데 도움이 될 수 있습니다.
**질문 수준의 이점: **클러스터와 관련된 지표를 이해하면 지연 시간을 줄이고 처리량을 높이는 데 도움이 되는 최적화 기법을 익힐 수 있습니다.
+ **[필수] **워크로드의 일부를 사용하여 기준 성능을 테스트합니다.
+ 로드 테스트와 같은 메커니즘을 사용하여 실제 워크로드의 성능을 모니터링해야 합니다.
+ 이러한 테스트를 실행하는 동안 CloudWatch 지표를 모니터링하여 사용 가능한 지표를 이해하고 성능 기준을 설정합니다.
+ **[가장 좋음] **ElastiCache for Valkey 및 Redis OSS 워크로드의 경우, 사용자가 프로덕션 클러스터에서 차단 명령을 실행하지 못하도록 `KEYS`와 같이 계산 비용이 많이 드는 명령의 이름을 변경하세요.
+ 엔진 6.x를 실행하는 ElastiCache for Redis OSS 워크로드는 역할 기반 액세스 제어를 활용하여 특정 명령을 제한할 수 있습니다.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는 간단한 키 수준 명령만 지원하므로 클라이언트 쿼리를 처리하기 위해 키 공간을 반복하지 않도록 추가 키를 인덱스로 구축하는 것이 좋습니다.
+ **[리소스]: **
+ [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Valkey 및 Redis OSS 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [ 벤치마크](https://valkey.io/topics/benchmark/)
## PE 2: ElastiCache 클러스터 노드에 작업을 어떻게 분배하고 있나요?
**질문 수준의 소개: **애플리케이션이 Amazon ElastiCache 노드에 연결하는 방식이 클러스터의 성능 및 확장성에 영향을 미칠 수 있습니다.
**질문 수준의 이점: **클러스터에서 사용 가능한 노드를 적절히 사용하면 사용 가능한 리소스 전체에 작업이 분산됩니다. 다음 기법은 유휴 리소스를 방지하는 데도 도움이 됩니다.
+ **[필수] **클라이언트가 적절한 ElastiCache 엔드포인트에 연결되도록 합니다.
+ ElastiCache for Valkey 및 Redis OSS는 사용 중인 클러스터 모드에 따라 각기 다른 엔드포인트를 구현합니다. 클러스터 모드가 활성화된 경우 ElastiCache는 구성 엔드포인트를 제공합니다. 클러스터 모드가 비활성화된 경우 ElastiCache는 일반적으로 쓰기에 사용되는 기본 엔드포인트와 복제본 간에 읽기 밸런싱을 위한 리더 엔드포인트를 제공합니다. 이러한 엔드포인트를 올바르게 구현하면 성능이 향상되고 확장 작업이 더 쉬워집니다. 특별한 요구 사항이 없는 한 개별 노드 엔드포인트에 연결하지 마시기 바랍니다.
+ 다중 노드 Memcached 클러스터의 경우 ElastiCache는 자동 검색을 지원하는 구성 엔드포인트를 제공합니다. 캐시 노드 전체에 작업을 균등하게 분배하려면 해싱 알고리즘을 사용하는 것이 좋습니다. 많은 Memcached 클라이언트 라이브러리는 일관된 해싱을 구현합니다. 사용할 라이브러리의 설명서에서 일관적 해싱 지원 여부와 그 구현 방법을 참조하세요. 이러한 기능 구현에 대한 자세한 내용은 [여기](BestPractices.LoadBalancing.md)에서 확인할 수 있습니다.
+ **[더 좋음] **확장성을 향상하기 위해 ElastiCache for Valkey 및 Redis OSS 클러스터 모드가 활성화된 클러스터의 이점을 활용합니다.
+ 클러스터 모드가 활성화된 ElastiCache for Valkey 및 Redis OSS 클러스터는 샤드 간에 데이터를 동적으로 배포하는 데 도움이 되는 [온라인 스케일링 작업](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)(스케일 아웃/인 및 스케일 업/다운)을 지원합니다. 구성 엔드포인트를 사용하면 클러스터 인식 클라이언트가 클러스터 토폴로지의 변화에 맞게 조정할 수 있습니다.
+ 또한 클러스터 모드를 활성화한 ElastiCache for Valkey 및 Redis OSS 클러스터에서 사용 가능한 샤드 간에 해시슬롯을 이동하여 클러스터의 균형을 재조정할 수 있습니다. 이렇게 하면 사용 가능한 샤드에 작업을 더 효율적으로 분배할 수 있습니다.
+ **[더 좋음] **워크로드의 단축키를 식별하고 정정하기 위한 전략을 구현합니다.
+ 목록, 스트림, 세트 등과 같은 다차원 Valkey 또는 Redis OSS 데이터 구조의 영향을 고려하세요. 이러한 데이터 구조는 단일 노드에 있는 단일 키에 저장됩니다. 매우 큰 다차원 키는 다른 데이터 유형보다 더 많은 네트워크 용량과 메모리를 사용할 가능성이 있으며, 이로 인해 해당 노드가 불균형하게 사용될 수 있습니다. 가능하면 여러 개별 키로 데이터 액세스를 분산하도록 워크로드를 설계하세요.
+ 워크로드의 핫키는 사용 중인 노드의 성능에 영향을 미칠 수 있습니다. ElastiCache for Valkey 및 Redis OSS 워크로드의 경우, LFU 최대 메모리 정책이 설정되어 있다면 `valkey-cli --hotkeys`를 사용하여 단축키를 감지할 수 있습니다.
+ 여러 노드에 핫키를 복제하여 액세스를 더 균등하게 분산하는 것을 고려해 보세요. 이 방법을 사용하려면 클라이언트가 여러 프라이머리 노드에 쓰고(Valkey 또는 Redis OSS 노드 자체에서는 이 기능을 제공하지 않음) 원래 키 이름 외에도 읽을 키 이름 목록을 유지 관리해야 합니다.
+ ElastiCache 엔진 7.2 이상 및 ElastiCache 버전 6 이상의 Redis OSS는 모두 서버 지원 [클라이언트 측 캐싱](https://valkey.io/topics/client-side-caching/)을 지원합니다. 이렇게 하면 애플리케이션이 키 변경을 기다린 후 ElastiCache로 다시 네트워크를 호출할 수 있습니다.
+ **[리소스]: **
+ [더 높은 가용성을 위해 ElastiCache for Valkey 및 Redis OSS 구성](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md)
+ [로드 밸런싱 모범 사례](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 온라인 리샤딩](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Valkey 및 Redis OSS의 클라이언트 측 캐싱](https://valkey.io/topics/client-side-caching/)
## PE 3: 캐싱 워크로드의 경우, 캐시의 효율성과 성능을 어떻게 추적하고 보고하나요?
**질문 수준의 소개: **캐싱은 ElastiCache에서 흔히 볼 수 있는 워크로드이므로 캐시의 효율성과 성능을 관리하는 방법을 이해하는 것이 중요합니다.
**질문 수준의 이점: **애플리케이션의 성능이 저하되었다는 징후가 보일 수 있습니다. 캐시별 지표를 사용하여 앱 성능을 높이는 방법을 결정하는 것은 캐시 워크로드에 매우 중요합니다.
+ **[필수] **시간에 따른 캐시 적중률을 측정하고 추적합니다. 캐시의 효율성은 '캐시 적중률'로 결정됩니다. 캐시 적중률이란 총 키 적중 수를 총 적중 수와 누락 수로 나눈 값을 말합니다. 비율이 1에 가까울수록 캐시의 효율성이 높은 것입니다. 캐시 적중률이 낮은 이유는 캐시 누락의 수가 많기 때문입니다. 요청된 키를 캐시에서 찾을 수 없을 때 캐시 누락이 발생합니다. 키가 캐시에 없는 이유는 키가 제거 또는 삭제되었거나, 만료되었거나, 존재한 적이 없기 때문입니다. 키가 캐시에 없는 이유를 이해하고 키를 캐시에 포함하는 데 적절한 전략을 개발하세요.
**[리소스]: **
+ [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md)
+ **[필수] **지연 시간 및 CPU 사용률 값과 함께 애플리케이션 캐시 성능을 측정 및 수집하여 TTL(Time To Live) 또는 기타 애플리케이션 구성 요소를 조정해야 하는지 파악합니다. ElastiCache는 각 데이터 구조에 집계된 지연 시간에 대한 CloudWatch 지표 세트를 제공합니다. 이러한 지연 시간 지표는 INFO 명령의 commandstats 통계를 사용하여 계산되며 네트워크 및 I/O 시간은 포함되지 않습니다. 이는 ElastiCache가 작업을 처리하는 데 소요되는 시간일 뿐입니다.
**[리소스]: **
+ [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md)
+ [Amazon CloudWatch를 사용하는 ElastiCache 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[가장 좋음] **필요에 맞는 캐싱 전략을 선택합니다. 캐시 적중률이 낮은 이유는 캐시 누락의 수가 많기 때문입니다. 워크로드가 캐시 누락이 적도록 설계된 경우(예: 실시간 통신), 캐싱 전략을 검토하고 메모리 및 성능 측정을 위한 쿼리 계측과 같이 워크로드에 가장 적합한 방법을 적용하는 것이 가장 좋습니다. 캐시를 채우고 유지 관리하기 위해 사용하는 실제 전략은 클라이언트가 캐싱해야 하는 데이터의 유형과 해당 데이터에 대한 액세스 패턴에 따라 달라집니다. 예를 들어 스트리밍 애플리케이션의 맞춤형 추천과 최신 뉴스 기사 모두에 동일한 전략을 사용할 가능성은 거의 없습니다.
**[리소스]: **
+ [Memcached에 대한 캐싱 전략](Strategies.md)
+ [캐싱 모범 사례](https://aws.amazon.com/caching/best-practices/)
+ [Amazon ElastiCache를 통한 규모에 따른 성능 백서](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## PE 4: 워크로드가 네트워킹 리소스 및 연결 사용을 어떻게 최적화하나요?
**질문 수준의 소개: **ElastiCache for Valkey, Memcached, and Redis OSS는 많은 애플리케이션 클라이언트에서 지원되며 구현은 다를 수 있습니다. 성능에 미치는 잠재적인 영향을 분석하려면 현재 사용 중인 네트워킹 및 연결 관리 방법을 이해해야 합니다.
**질문 수준의 이점: **네트워킹 리소스를 효율적으로 사용하면 클러스터의 성능 효율성을 높일 수 있습니다. 다음 권장 사항을 적용하면 네트워킹 수요를 줄이고 클러스터 지연 시간 및 처리량을 개선할 수 있습니다.
+ **[필수] **ElastiCache 클러스터에 대한 연결을 사전에 관리합니다.
+ 애플리케이션의 연결 풀링은 연결을 열고 닫을 때 생성되는 클러스터의 오버헤드를 줄입니다. `CurrConnections` 및 `NewConnections`를 사용하여 Amazon CloudWatch의 연결 동작을 모니터링하세요.
+ 상황에 따라 클라이언트 연결을 제대로 닫아 연결 누수를 방지합니다. 연결 관리 전략에는 사용하지 않는 연결을 올바르게 닫고 연결 시간 제한을 설정하는 것이 포함됩니다.
+ Memcached 워크로드의 경우, `memcached_connections_overhead`라는 연결 처리를 위해 예약된 메모리의 양을 구성할 수 있습니다.
+ **[더 좋음] **대용량 객체를 압축하여 메모리를 줄이고 네트워크 처리량을 개선합니다.
+ 데이터를 압축하면 필요한 네트워크 처리량(Gbps)을 줄일 수 있지만 애플리케이션에서 데이터를 압축 및 압축 해제하는 작업량이 늘어날 수 있습니다.
+ 압축은 키가 소비하는 메모리의 양도 줄여줍니다.
+ 애플리케이션 요구 사항에 따라 압축률과 압축 속도 간의 균형을 고려하세요.
+ **[리소스]: **
+ [ElastiCache - 글로벌 데이터 저장소](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [I/O 처리를 개선하여 성능을 향상하는 ElastiCache for Redis OSS 버전 5.0.3](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md)
+ [더 높은 가용성을 위해 ElastiCache 구성](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5: 키 삭제 또는 제거를 어떻게 관리하나요?
**질문 수준의 소개:** 워크로드는 요구 사항이 각기 다르며 클러스터 노드가 메모리 소비 제한에 근접했을 때 예상되는 동작이 각기 다릅니다. ElastiCache에는 이러한 상황을 처리하기 위해 다양한 정책이 있습니다.
**질문 수준의 이점: **사용 가능한 메모리를 적절히 관리하고 제거 정책을 이해하면 인스턴스 메모리 제한을 초과했을 때 클러스터 동작을 인식하는 데 도움이 됩니다.
+ **[필수] **데이터 액세스를 계측하여 적용할 정책을 평가합니다. 클러스터에서 제거를 수행할지, 수행한다면 어떻게 수행할지 제어하는 데 적합한 최대 메모리 정책을 식별합니다.
+ 제거는 클러스터에서 최대 메모리가 소비되고 제거를 허용하는 정책이 있을 때 발생합니다. 이 상황에서 클러스터의 동작은 지정된 제거 정책에 따라 달라집니다. 이 정책은 클러스터 파라미터 그룹에서 `maxmemory-policy`를 사용하여 관리할 수 있습니다.
+ 기본 정책인 `volatile-lru`는 만료 시간(TTL 값)이 설정된 키를 제거하여 메모리를 확보합니다. 가장 낮은 빈도로 사용(LFU) 및 가장 오래 전에 사용(LRU) 정책은 사용 현황에 따라 키를 제거합니다.
+ Memcached 워크로드의 경우, 각 노드의 제거를 제어하는 기본 LRU 정책이 있습니다. Amazon CloudWatch의 제거 지표를 사용하여 Amazon ElastiCache 클러스터의 제거 수를 모니터링할 수 있습니다.
+ **[더 좋음] **삭제 동작을 표준화하여 클러스터의 성능에 미치는 영향을 제어함으로써 예상치 못한 성능 병목 현상을 방지합니다.
+ ElastiCache for Valkey 및 Redis OSS 워크로드의 경우, 클러스터에서 키를 명시적으로 제거하면 `UNLINK`는 마치 `DEL`처럼 지정된 키를 제거합니다. 그러나 이 명령은 다른 스레드에서 실제 메모리 회수를 수행하므로 `DEL`과는 달리 차단하지 않습니다. 실제 제거는 나중에 비동기적으로 수행됩니다.
+ ElastiCache for Redis OSS 버전 6.x 워크로드의 경우, `lazyfree-lazy-user-del` 파라미터를 사용하여 파라미터 그룹에서 `DEL` 명령의 동작을 수정할 수 있습니다.
+ **[리소스]: **
+ [ElastiCache 파라미터 그룹을 사용해 엔진 파라미터 구성](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [를 사용한 클라우드 재무 관리AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6: ElastiCache에서 어떻게 데이터를 모델링하고 데이터와 상호 작용하나요?
**질문 수준의 소개: **ElastiCache는 사용되는 데이터 구조 및 데이터 모델과 관련해서 애플리케이션에 크게 의존하지만 데이터 스토어가 있는 경우 기본 데이터 스토어도 고려해야 합니다. 사용 가능한 데이터 구조를 이해하고 필요에 가장 적합한 데이터 구조를 사용하고 있는지 확인하세요.
**질문 수준의 이점: **ElastiCache의 데이터 모델링에는 애플리케이션 사용 사례, 데이터 유형 및 데이터 요소 간 관계를 비롯한 여러 계층이 있습니다. 또한 각 데이터 유형 및 명령에는 잘 문서화된 고유한 성능 시그니처가 있습니다.
+ **[가장 좋음] ** 가장 좋음은 의도하지 않은 데이터 덮어쓰기를 줄이는 것입니다. 중복되는 키 이름을 최소화하는 이름 지정 규칙을 사용하세요. 일반적으로 데이터 구조의 이름을 지정할 때는 `APPNAME:CONTEXT:ID`, `ORDER-APP:CUSTOMER:123` 등의 계층적 방법을 사용합니다.
**[리소스]: **
+ [키 이름 지정](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **[가장 좋음] **ElastiCache for Valkey 및 Redis OSS 명령에는 Big O 표기법으로 정의된 시간 복잡도가 있습니다. 이때 명령의 시간 복잡도는 그 영향을 알고리즘/수학적으로 표현한 것입니다. 애플리케이션에 새 데이터 유형을 도입할 때는 관련 명령의 시간 복잡도를 주의 깊게 검토해야 합니다. 시간 복잡도가 O(1)인 명령은 시간이 일정하며 입력 크기에 의존하지 않지만 시간 복잡도가 O(N)인 명령은 시간이 선형이며 입력 크기의 영향을 받습니다. ElastiCache for Valkey 및 Redis OSS의 단일 스레드 설계로 인해 시간 복잡도가 높은 걸리는 작업을 대량으로 수행하면 성능이 저하되고 작업 시간 초과가 발생할 수 있습니다.
**[리소스]: **
+ [명령](https://valkey.io/commands/)
+ **[가장 좋음] **API를 사용하여 클러스터의 데이터 모델에 대한 GUI 가시성을 확보합니다.
**[리소스]: **
+ [Redis OSS Commander](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Redis OSS 브라우저](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## 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 메모리에 저장할 필요가 줄어듭니다.
+ **[리소스]: **
+ [클러스터에서 느린 로그를 켜려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [로그 전달](Log_Delivery.md)
+ [Redis OSS 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/)Amazon CloudWatch
+ [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)
## PE8: Auto Scaling은 ElastiCache 클러스터의 성능을 높이는 데 어떻게 도움이 되나요?
**질문 수준의 소개: **Valkey 또는 Redis OSS 오토 스케일링 기능을 구현하면 ElastiCache 구성 요소가 시간이 지남에 따라 조정되어 원하는 샤드 또는 복제본을 자동으로 늘리거나 줄일 수 있습니다. 이는 대상 추적 또는 예약된 규모 조정 정책을 구현하여 수행할 수 있습니다.
**질문 수준의 이점: **워크로드의 급증을 이해하고 이에 대한 계획을 세우면 향상된 캐싱 성능과 비즈니스 연속성을 보장할 수 있습니다. ElastiCache Auto Scaling은 CPU/메모리 사용률을 지속적으로 모니터링하여 클러스터가 원하는 성능 수준으로 작동하는지 확인합니다.
+ **[필수] **ElastiCache for Valkey 및 Redis OSS용 클러스터를 시작할 경우:
1. 클러스터 모드가 활성화되었는지 확인합니다.
1. 인스턴스가 Auto Scaling을 지원하는 특정 유형 및 크기의 패밀리에 속하는지 확인합니다.
1. 클러스터가 글로벌 데이터 스토어, Outposts 또는 로컬 영역에서 실행되고 있지 않은지 확인합니다.
**[리소스]: **
+ [Valkey 및 Redis OSS(클러스터 모드 활성화됨)에서 클러스터 조정](scaling-redis-cluster-mode-enabled.md)
+ [샤드에 Auto Scaling 사용](AutoScaling-Using-Shards.md)
+ [복제본에 Auto Scaling 사용](AutoScaling-Using-Replicas.md)
+ **[가장 좋음] **워크로드에 읽기 작업이 많은지, 쓰기 작업이 많은지 파악하여 규모 조정 정책을 정의합니다. 최상의 성능을 위해서는 하나의 추적 지표만 사용하세요. Auto Scaling 정책은 목표에 도달하면 스케일 아웃이 수행되지만 모든 대상 추적 정책이 스케일 인 준비가 된 경우에만 스케일 인이 수행되므로 각 차원에 대해 여러 정책을 사용하지 않는 것이 좋습니다.
**[리소스]: **
+ [Auto Scaling 정책](AutoScaling-Policies.md)
+ [조정 정책 정의](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[가장 좋음] **시간 경과에 따른 성능 모니터링은 특정 시점에 모니터링할 경우 눈에 띄지 않는 워크로드 변경을 감지하는 데 도움이 될 수 있습니다. 4주간의 클러스터 사용률에 대한 CloudWatch 지표를 분석하여 대상 값 임계값을 확인할 수 있습니다. 어떤 값을 선택할지 잘 모르는 경우 지원되는 최소 사전 정의 지표 값으로 시작하는 것이 좋습니다.
**[리소스]: **
+ [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md)
+ **[더 좋음] **클러스터가 규모 조정 정책을 개발하고 가용성 문제를 완화하는 데 필요한 샤드/복제본의 정확한 수를 파악하기 위해 예상되는 최소 및 최대 워크로드로 애플리케이션을 테스트하는 것이 좋습니다.
**[리소스]: **
+ [확장 가능 목표 등록](AutoScaling-Register-Policy.md)
+ [를 사용하여 확장 가능 대상 등록AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)
# Amazon ElastiCache의 Well-Architected Lens 비용 최적화 요소
비용 최적화 요소는 불필요한 비용을 피하는 데 중점을 둡니다. 주요 주제로는 자금이 어디에 사용되는지 이해하고 제어하기, 가장 적합한 노드 유형 선택하기(워크로드 요구 사항에 따라 데이터 계층화를 지원하는 인스턴스 사용), 적절한 수의 리소스 유형(읽기 전용 복제본 수), 시간 경과에 따른 지출 분석하기, 과도한 지출 없이 비즈니스 요구 사항을 충족할 수 있도록 확장하기 등이 있습니다.
**Topics**
+ [COST 1: ElastiCache 리소스와 관련된 비용을 어떻게 식별하고 추적하나요? 사용자가 리소스를 생성하고 생성된 리소스를 관리 및 폐기할 수 있도록 하는 메커니즘을 어떻게 개발하나요?](#CostOptimizationPillarCOST1)
+ [COST 2: ElastiCache 리소스와 관련된 비용을 최적화하는 데 도움이 되는 지속적 모니터링 도구를 어떻게 사용하나요?](#CostOptimizationPillarCOST2)
+ [COST 3: 데이터 계층화를 지원하는 인스턴스 유형을 사용해야 하나요? 데이터 계층화의 이점은 무엇인가요? 데이터 계층화 인스턴스를 사용하지 않는 경우는 언제인가요?](#CostOptimizationPillarCOST3)
## COST 1: ElastiCache 리소스와 관련된 비용을 어떻게 식별하고 추적하나요? 사용자가 리소스를 생성하고 생성된 리소스를 관리 및 폐기할 수 있도록 하는 메커니즘을 어떻게 개발하나요?
**질문 수준의 소개: **비용 지표를 이해하려면 소프트웨어 엔지니어링, 데이터 관리, 제품 소유자, 재무 및 리더십 등 여러 팀의 참여와 협업이 필요합니다. 비용의 주요 동인을 식별하려면 모든 관련 당사자가 서비스 사용 제어 레버와 비용 관리의 절충점을 이해해야 하며, 이것이 비용 최적화 노력의 성공을 좌우하는 경우가 많습니다. 개발부터 프로덕션 및 사용 중지에 이르기까지 생성된 리소스를 추적할 수 있는 프로세스와 도구를 갖추면 ElastiCache와 관련된 비용을 관리하는 데 도움이 됩니다.
**질문 수준의 이점: **워크로드와 관련된 모든 비용을 지속적으로 추적하려면 ElastiCache를 구성 요소 중 하나로 포함하는 아키텍처에 대한 심층적인 이해가 필요합니다. 또한 사용량을 집계하여 예산과 비교할 수 있는 비용 관리 계획도 마련해 두어야 합니다.
+ **[필수]** 클라우드 혁신 센터(CCoE)를 설립하고, 설립 규범 중 하나로 CCoE가 조직의 ElastiCache 사용과 관련된 지표의 정의, 추적 및 조치 수행을 담당하도록 합니다. CCoE가 존재하고 운영되는 경우 CCoE가 ElastiCache와 관련된 비용을 읽고 추적하는 방법을 알고 있는지 확인하세요. 리소스가 생성되면 IAM 역할 및 정책을 사용하여 특정 팀 및 그룹만 리소스를 인스턴스화할 수 있는지 검증합니다. 이를 통해 비용을 비즈니스 성과와 연관시키고 비용 관점에서 명확한 책임 범위를 설정할 수 있습니다.
1. CCoE는 다음과 같은 범주형 데이터에서 주요 ElastiCache 사용량을 기준으로 정기적(월간)으로 업데이트되는 비용 지표를 식별, 정의 및 게시해야 합니다.
1. 사용된 노드 유형 및 속성: 표준 또는 메모리 최적화, 온디맨드 또는 예약 인스턴스, 리전 및 가용 영역
1. 환경 유형: 무료, 개발, 테스트 및 프로덕션
1. 백업 스토리지 및 보존 전략
1. 리전 내 및 리전 간 데이터 전송
1. Amazon Outposts에서 실행되는 인스턴스
1. CCoE는 조직 내 소프트웨어 엔지니어링, 데이터 관리, 제품 팀, 재무 및 리더십 팀 등 다양한 팀으로 구성됩니다.
**[리소스]: **
+ [클라우드 혁신 센터 만들기](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/)
+ **[필수] **비용 할당 태그를 사용하여 낮은 수준의 세밀함으로 비용을 추적합니다. AWS Cost Management를 사용하면 시간 경과에 따른 AWS 비용 및 사용량을 시각화하고 이해하며 관리할 수 있습니다.
1. 태그를 이용하여 리소스를 정리하고, 비용 할당 태그를 이용하여 AWS 비용을 더 자세히 추적합니다. 비용 할당 태그를 활성화하면, AWS는 비용 할당 태그를 이용해 비용 할당 보고서의 리소스 비용을 정리하기 때문에 사용자는 쉽게 AWS 비용을 분류하고 추적할 수 있습니다. AWS는 AWS 생성 태그 및 사용자 정의 태그라는 두 가지 유형의 비용 할당 태그를 제공합니다. AWS는 사용자를 위해 AWS 생성 태그를 정의, 생성 및 적용하며, 사용자는 사용자 정의 태그를 정의, 생성 및 적용합니다. 두 유형의 태그 모두 개별적으로 활성화해야만 Cost Management나 비용 할당 보고서에 표시됩니다.
1. 비용 할당 태그를 사용하여 자신만의 비용 구조를 반영하도록 AWS 청구서를 구성합니다. Amazon ElastiCache에서 리소스에 비용 할당 태그를 추가하면 인보이스 비용을 리소스 태그 값으로 그룹화하여 비용을 추적할 수 있습니다. 또한 태그를 결합하여 보다 세부적인 수준으로 비용을 추적하는 것을 고려해야 합니다.
**[리소스]: **
+ [AWS 비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [비용 할당 태그를 사용한 비용 모니터링](Tagging.md)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[가장 좋음] **ElastiCache 비용을 조직 전체에 적용되는 지표와 연계합니다.
1. 비즈니스 지표와 지연 시간 같은 운영 지표를 고려해 보세요. 비즈니스 모델에서 모든 역할이 이해할 수 있는 개념은 무엇인가요? 지표는 조직 내에서 가능한 많은 역할이 이해할 수 있어야 합니다.
1. 예 - 동시에 서비스되는 사용자, 작업 및 사용자당 최대 및 평균 지연 시간, 사용자 참여 점수, 사용자 재방문율/주, 세션 길이/사용자, 포기율, 캐시 적중률, 키 추적
**[리소스]: **
+ [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md)
+ **[좋음] **ElastiCache를 사용하는 전체 워크로드의 지표 및 비용에 대해 최신 아키텍처 가시성과 운영 가시성을 유지합니다.
1. 전체 솔루션 에코시스템을 이해하세요. ElastiCache는 클라이언트부터 API Gateway, Redshift 및 예를 들면 보고 도구용 QuickSight에 이르기까지 기술 세트의 전체 AWS 서비스 에코시스템에 속하는 경향이 있습니다.
1. 클라이언트, 연결, 보안, 인메모리 작업, 스토리지, 리소스 자동화, 데이터 액세스 및 관리 등 솔루션의 구성 요소를 아키텍처 다이어그램에 매핑합니다. 각 계층은 전체 솔루션에 연결되며 전체 비용에 추가되거나 전체 비용을 관리하는 데 도움이 되는 고유한 요구 사항과 기능을 가지고 있습니다.
1. 다이어그램에는 애플리케이션의 운영 및 기능적 ElastiCache 요소뿐만 아니라 컴퓨팅, 네트워킹, 스토리지, 수명 주기 정책, 지표 수집의 사용을 포함해야 합니다.
1. 워크로드 요구 사항은 시간이 지남에 따라 변할 가능성이 높으므로 워크로드 비용 관리에서 선제적으로 대응하기 위해서는 기본 구성 요소와 주요 기능 목표에 대한 이해를 지속적으로 유지하고 문서화하는 것이 중요합니다.
1. 가시성, 책임, 우선순위 지정 및 리소스에 대한 경영진의 지원은 ElastiCache에 대한 효과적인 비용 관리 전략을 수립하는 데 매우 중요합니다.
## COST 2: ElastiCache 리소스와 관련된 비용을 최적화하는 데 도움이 되는 지속적 모니터링 도구를 어떻게 사용하나요?
**질문 수준의 소개: **ElastiCache 비용과 애플리케이션 성능 지표 간의 적절한 균형을 맞추는 것을 목표로 해야 합니다. Amazon CloudWatch는 요구 사항에 따라 ElastiCache 리소스의 활용도가 과도한지, 저조한지 평가하는 데 도움이 되는 주요 운영 지표에 대한 가시성을 제공합니다. 비용 최적화 관점에서 보면 오버프로비저닝되는 시기를 이해하고 운영, 가용성, 복원력 및 성능 요구 사항을 유지하면서 ElastiCache 리소스 크기를 조정할 수 있는 적절한 메커니즘을 개발할 수 있어야 합니다.
**질문 수준의 이점: **워크로드 운영 요구 사항을 충족하기에 충분한 리소스를 프로비저닝하고, 낮은 리소스 활용도로 인해 비용이 최적화되지 않는 상태를 피하는 것이 이상적입니다. 과도하게 큰 ElastiCache 리소스가 장기간 운영되는 것을 식별하고 이를 방지할 수 있어야 합니다.
+ **[필수] **CloudWatch를 사용하여 ElastiCache 클러스터를 모니터링하고 이러한 지표가 AWSCost Explorer 대시보드와 어떤 관련이 있는지 분석합니다.
1. ElastiCache는 호스트 수준 지표(예: CPU 사용) 및 캐시 엔진 소프트웨어별 지표(예: 캐시가 얻은 것과 잃은 것) 모두를 제공합니다. 이러한 지표는 60초 간격으로 각 캐시 노드에 대해 측정되어 게시됩니다.
1. ElastiCache 성능 지표(CPUUtilization, EngineUtilization, SwapUsage, CurrConnections, Evictions)를 확인하여 스케일 업/다운(더 큰/작은 캐시 노드 유형 사용) 또는 스케일 인/아웃(샤드 추가/축소)이 필요하다는 것을 알 수 있습니다. 애플리케이션 성능 임계값을 충족하는 데 필요한 추가 비용과 최소 및 최대 시간을 추정하는 플레이북 매트릭스를 만들어 규모 조정에 대한 결정이 비용에 미치는 영향을 파악하세요.
**[리소스]: **
+ [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md)
+ [어떤 지표를 모니터링해야 합니까?](CacheMetrics.WhichShouldIMonitor.md)
+ [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/)
+ **[필수] **백업 전략과 비용에 미치는 영향을 이해하고 문서화합니다.
1. ElastiCache를 사용하면 백업이 내구성이 뛰어난 스토리지를 제공하는 Amazon S3에 저장됩니다. 장애 복구 능력과 관련하여 비용에 미치는 영향을 이해해야 합니다.
1. 보존 한도가 지난 백업 파일을 삭제하는 자동 백업을 활성화합니다.
**[리소스]: **
+ [자동 백업 예약](backups-automatic.md)
+ [Amazon Simple Storage Service 요금](https://aws.amazon.com/s3/pricing/)
+ **[가장 좋음]** 잘 이해되고 문서화된 워크로드의 비용을 관리하기 위한 의도적인 전략으로 인스턴스에 예약 노드를 사용합니다. 노드 유형과 예약 기간(1년 또는 3년)에 따라 예약 노드에 선결제 요금이 부과됩니다. 이 요금은 온디맨드 노드에서 발생하는 시간당 사용 요금보다 훨씬 낮습니다.
1. 예약 인스턴스 요구 사항을 추정하기에 충분한 데이터를 수집할 때까지 온디맨드 노드를 사용하여 ElastiCache 클러스터를 운영해야 할 수 있습니다. 요구 사항을 충족하는 데 필요한 리소스를 계획 및 문서화하고 인스턴스 유형(온디맨드 또는 예약형)의 예상 비용을 비교합니다.
1. 사용 가능한 새 캐시 노드 유형을 정기적으로 평가하고 비용 및 운영 지표 관점에서 인스턴스 플릿을 새 캐시 노드 유형으로 마이그레이션하는 것이 합리적인지 평가합니다.
## COST 3: 데이터 계층화를 지원하는 인스턴스 유형을 사용해야 하나요? 데이터 계층화의 이점은 무엇인가요? 데이터 계층화 인스턴스를 사용하지 않는 경우는 언제인가요?
**질문 수준의 소개: **적절한 인스턴스 유형을 선택하면 성능 및 서비스 수준뿐만 아니라 재정에도 영향을 미칠 수 있습니다. 인스턴스 유형마다 관련된 비용이 다릅니다. 메모리의 모든 스토리지 요구 사항을 수용할 수 있는 대규모 인스턴스 유형을 하나 또는 몇 개 선택하는 것은 자연스러운 결정일 수 있습니다. 그러나 이는 프로젝트가 성숙해짐에 따라 비용에 상당한 영향을 미칠 수 있습니다. 올바른 인스턴스 유형을 선택했는지 확인하려면 ElastiCache 객체 유휴 시간을 정기적으로 검사해야 합니다.
**질문 수준의 이점: **다양한 인스턴스 유형이 현재와 미래의 비용에 어떤 영향을 미치는지 명확히 이해해야 합니다. 사소하거나 주기적인 워크로드 변경으로 인해 과도한 비용 변동이 발생해서는 안 됩니다. 워크로드가 허용하는 경우 데이터 계층화를 지원하는 인스턴스 유형은 사용 가능한 스토리지당 더 나은 가격을 제공합니다. 인스턴스별로 사용 가능한 SSD 스토리지 때문에 데이터 계층화 인스턴스는 인스턴스 기능당 훨씬 더 높은 총 데이터 용량을 지원합니다.
+ **[필수] **데이터 계층화 인스턴스의 한계를 이해합니다.
1. ElastiCache Valkey for 또는 Redis OSS 클러스터에만 사용할 수 있습니다.
1. 제한된 인스턴스 유형만 데이터 계층화를 지원합니다.
1. ElastiCache for Redis OSS 버전 6.2 이상만 지원됩니다.
1. 대형 항목은 SSD로 교체되지 않습니다. 128MiB 이상의 객체는 메모리에 보관됩니다.
**[리소스]: **
+ [데이터 계층화](data-tiering.md)
+ [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/)
+ **[필수] **워크로드가 데이터베이스의 몇 퍼센트에 정기적으로 액세스하는지 파악합니다.
1. 데이터 계층화 인스턴스는 전체 데이터세트의 일부에만 액세스하는 경우가 많지만 나머지 데이터에는 빠른 액세스가 필요한 워크로드에 적합합니다. 즉, 핫 데이터와 웜 데이터의 비율이 약 20:80 입니다.
1. 객체 유휴 시간에 대한 클러스터 수준의 추적을 개발합니다.
1. 500Gb가 넘는 데이터를 대규모로 구현하는 데 적합합니다.
+ **[필수] **특정 워크로드에서는 데이터 계층화 인스턴스가 선택 사항이 아니라는 점을 이해합니다.
1. 자주 사용하지 않는 객체는 로컬 SSD로 교체되므로 액세스 빈도가 낮은 객체에는 약간의 성능 비용이 부과됩니다. 애플리케이션이 응답 시간에 민감한 경우 워크로드에 미치는 영향을 테스트하세요.
1. 대부분 크기가 128MiB 이상인 대형 객체를 저장하는 캐시에는 적합하지 않습니다.
**[리소스]: **
+ [제한 사항](data-tiering.md#data-tiering-prerequisites)
+ **[가장 좋음] **예약 인스턴스 유형은 데이터 계층화를 지원합니다. 이를 통해 인스턴스당 데이터 스토리지 용량 측면에서 가장 낮은 비용이 보장됩니다.
1. 요구 사항을 더 잘 이해할 때까지 데이터 계층화 인스턴스가 아닌 인스턴스를 사용하여 ElastiCache 클러스터를 운영해야 할 수도 있습니다.
1. ElastiCache 클러스터의 데이터 사용 패턴을 분석합니다.
1. 객체 유휴 시간을 주기적으로 수집하는 자동화된 작업을 생성합니다.
1. 대다수(약 80%)의 객체가 워크로드에 적합하다고 판단되는 기간 동안 유휴 상태인 경우, 조사 결과를 문서화하고 클러스터를 데이터 계층화를 지원하는 인스턴스로 마이그레이션하는 것을 제안하세요.
1. 사용 가능한 새 캐시 노드 유형을 정기적으로 평가하고 비용 및 운영 지표 관점에서 인스턴스 플릿을 새 캐시 노드 유형으로 마이그레이션하는 것이 합리적인지 평가합니다.
**[리소스]: **
+ [OBJECT IDLETIME](https://valkey.io/commands/object-idletime/)
+ [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/)