기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# ElastiCache 사용
이 섹션에서는 ElastiCache 구현의 다양한 구성 요소를 관리하는 방법에 관한 세부 정보를 얻을 수 있습니다.
**Topics**
+ [스냅샷 및 복원](backups.md)
+ [ElastiCache의 엔진 버전 및 업그레이드](engine-versions.md)
+ [ElastiCache 모범 사례 및 캐싱 전략](BestPractices.md)
+ [ElastiCache에서 노드 기반 클러스터 관리](manage-self-designed-cluster.md)
+ [EC2 인스턴스 및 ElastiCache 캐시 자동 연결](compute-connection.md)
+ [ElastiCache 규모 조정](Scaling.md)
+ [Bloom 필터 시작하기](BloomFilters.md)
+ [Serverless에서 Watch 시작하기](ServerlessWatch.md)
+ [벡터 검색 시작](vector-search.md)
+ [Valkey 및 Redis OSS용 JSON 시작하기](json-gs.md)
+ [ElastiCache 리소스에 태그 지정](Tagging-Resources.md)
+ [Amazon ElastiCache의 Well-Architected Lens 사용](WellArchitechtedLens.md)
+ [ElastiCache를 사용한 일반적인 문제 해결 단계 및 모범 사례](wwe-troubleshooting.md)
# 스냅샷 및 복원
Valkey, Redis OSS 또는 서버리스 Memcached를 실행하는 Amazon ElastiCache 캐시는 스냅샷을 생성하여 데이터를 백업할 수 있습니다. 백업을 사용하여 캐시를 복원하거나 데이터를 새 캐시에 시드할 수 있습니다. 백업은 캐시의 모든 데이터와 캐시의 메타데이터로 구성됩니다. 모든 백업은 Amazon Simple Storage Service(S3)에 쓰여지므로 내구성 있는 스토리지가 확보됩니다. 언제든지 새 Valkey, Redis OSS 또는 서버리스 Memcached 캐시를 만들고 백업의 데이터로 채워 데이터를 복원할 수 있습니다. ElastiCache를 사용하면 ,AWS Command Line Interface(AWS CLI) 및 ElastiCache API AWS Management Console를 사용하여 백업을 관리할 수 있습니다.
캐시를 삭제할 계획을 세우고 데이터를 보존하는 것이 중요한 경우 추가적인 예방 조치를 취할 수 있습니다. 이렇게 하려면 먼저 수동 백업을 생성하고 *사용 가능한* 상태인지 확인한 다음 캐시를 삭제합니다. 이렇게 하면 백업에 실패하더라도 캐시 데이터를 계속 사용할 수 있습니다. 앞서 설명한 모범 사례에 따라 백업을 다시 시도할 수 있습니다.
**Topics**
+ [백업 제약 조건](#backups-constraints)
+ [노드 기반 클러스터 백업이 성능에 미치는 영향](#backups-performance)
+ [자동 백업 예약](backups-automatic.md)
+ [수동 백업 지원](backups-manual.md)
+ [최종 백업 생성](backups-final.md)
+ [백업 설명](backups-describing.md)
+ [백업 복사](backups-copying.md)
+ [백업 내보내기](backups-exporting.md)
+ [백업에서 새 캐시로 복원](backups-restoring.md)
+ [백업 삭제](backups-deleting.md)
+ [백업 태그 지정](backups-tagging.md)
+ [자습서: 외부에서 생성된 백업으로 새로운 노드 기반 클러스터 시드](backups-seeding-redis.md)
## 백업 제약 조건
백업을 계획하거나 만들려는 경우 다음 제약 조건을 고려해야 합니다.
+ 백업 및 복원은 Valkey, Redis OSS 또는 서버리스 Memcached에서 실행되는 캐시에만 지원됩니다.
+ Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 경우 `cache.t1.micro` 노드에서 백업 및 복원이 지원되지 않습니다. 다른 모든 캐시 노드 유형은 지원됩니다.
+ Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 경우 모든 노드 유형에 대해 백업 및 복원이 지원됩니다.
+ 24시간 연속으로 서버리스 캐시당 24개 이내의 수동 백업을 만들 수 있습니다. Valkey 및 Redis OSS 노드 기반 클러스터의 경우 클러스터의 노드당 20개 이하의 수동 백업을 생성할 수 있습니다.
+ Valkey 또는 Redis OSS(클러스터 모드 활성화됨)는 클러스터 수준(API 또는 CLI의 경우 복제 그룹 수준)에서만 백업 생성을 지원합니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨)는 샤드 수준(API 또는 CLI의 경우 노드 그룹 수준)에서는 백업 생성을 지원하지 않습니다.
+ 백업 프로세스 중에는 서버리스 캐시에서 다른 API 또는 CLI 작업을 실행할 수 없습니다. 백업 중에 노드 기반 클러스터에서 API 또는 CLI 작업을 실행할 수 있습니다.
+ 데이터 계층화와 함께 Valkey 또는 Redis OSS 캐시를 사용하는 경우 백업을 Amazon S3로 내보낼 수 없습니다.
+ r6gd 노드 유형을 사용하는 클러스터의 백업은 r6gd 노드 유형을 사용하는 클러스터에만 복원할 수 있습니다.
## 노드 기반 클러스터 백업이 성능에 미치는 영향
서버리스 캐시의 백업은 성능뿐 아니라 애플리케이션에도 영향을 미치지 않습니다. 하지만 노드 기반 클러스터의 백업을 생성할 때는 가용할 수 있는 예약 메모리에 따라 성능에 어느 정도 영향을 미칠 수 있습니다. 노드 기반 클러스터에 대한 백업은 ElastiCache for Memcached에서는 사용할 수 없지만 ElastiCache for Redis OSS에서는 사용할 수 있습니다.
다음은 노드 기반 클러스터에서 백업 성능을 개선하기 위한 지침입니다.
+ `reserved-memory-percent` 파라미터 설정 - 과도한 페이징을 완화하려면 *reserved-memory-percent* 파라미터를 설정하는 것이 좋습니다. 이 파라미터를 사용하면 Valkey 및 Redis OSS가 노드의 모든 사용 가능한 메모리를 소비하고 페이징 양을 줄이는 데 도움이 됩니다. 더 큰 노드를 사용하기만 해도 성능 개선을 확인할 수 있습니다. *reserved-memory* 및 *reserved-memory-percent* 파라미터에 대한 자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 섹션을 참조하세요.
+ 읽기 전용 복제본으로 백업을 만듭니다. 노드가 2개 이상인 노드 그룹에서 Valkey 또는 Redis OSS를 실행하는 경우 프라이머리 노드 또는 읽기 전용 복제본 중 하나에서 백업을 만들 수 있습니다. BGSAVE 도중 필요한 시스템 리소스로 인해 읽기 전용 복제본 중 하나에서 백업을 생성하는 것이 좋습니다. 복제본으로 백업을 생성하는 동안 프라이머리 노드는 BGSAVE 리소스 요구 사항의 영향을 받지 않습니다. 프라이머리 노드는 속도를 늦추지 않고 계속해서 요청을 처리할 수 있습니다.
이렇게 하려면 [수동 백업 생성(콘솔)](backups-manual.md#backups-manual-CON) 섹션을 참조하고, **백업 생성** 창의 **클러스터 이름** 필드에서 기본값인 프라이머리 노드 대신 복제본을 선택합니다.
복제 그룹을 삭제하고 최종 백업을 요청할 경우 ElastiCache에서는 언제나 프라이머리 노드에서 백업을 만듭니다. 그러면 복제 그룹이 삭제되기 전에 가장 최신 Valkey 또는 Redis OSS 데이터를 캡처할 수 있습니다.
# 자동 백업 예약
모든 Valkey 또는 Redis OSS 서버리스 캐시 또는 노드 기반 클러스터에 자동 백업을 활성화할 수 있습니다. 자동 백업이 활성화되면 ElastiCache에서 매일 캐시 백업을 생성합니다. 캐시에는 영향을 주지 않으며 변경 사항이 즉시 적용됩니다. 자동 백업은 데이터 손실을 막는 데 도움이 됩니다. 실패할 경우 새로운 캐시를 생성해 최신 백업에서 모든 데이터를 복원할 수 있습니다. 그 결과 웜 부팅 캐시로 전환되고 데이터가 사전 로드되어 사용할 수 있게 됩니다. 자세한 내용은 [백업에서 새 캐시로 복원](backups-restoring.md) 단원을 참조하십시오.
모든 Memcached 서버리스 캐시에 자동 백업을 활성화할 수 있습니다. 자동 백업이 활성화되면 ElastiCache에서 매일 캐시 백업을 생성합니다. 캐시에는 영향을 주지 않으며 변경 사항이 즉시 적용됩니다. 자동 백업은 데이터 손실을 막는 데 도움이 됩니다. 실패할 경우 새로운 캐시를 생성해 최신 백업에서 모든 데이터를 복원할 수 있습니다. 그 결과 웜 부팅 캐시로 전환되고 데이터가 사전 로드되어 사용할 수 있게 됩니다. 자세한 내용은 [백업에서 새 캐시로 복원](backups-restoring.md) 단원을 참조하십시오.
자동 백업을 예약할 때는 다음 설정을 계획해야 합니다.
+ **백업 시작 시간** - ElastiCache에서 하루 중 백업 생성을 시작하는 시각입니다. 가장 편리한 시간에 백업 기간을 설정할 수 있습니다. 백업 기간을 지정하지 않으면 ElastiCache에서 자동으로 할당합니다.
+ **백업 보존 제한** - Amazon S3에서 백업을 보존되는 일수입니다. 예를 들어, 보존 제한을 5로 설정하면 오늘 만든 백업이 5일간 보존됩니다. 보존 제한이 만료되면 백업이 자동으로 삭제됩니다.
최대 백업 보존 제한은 35일입니다. 백업 보존 제한을 0으로 설정하면 캐시의 자동 백업이 비활성화됩니다.
자동 백업을 예약하면 ElastiCache가 백업 생성을 시작합니다. 가장 편리한 시간에 백업 기간을 설정할 수 있습니다. 백업 기간을 지정하지 않으면 ElastiCache에서 자동으로 할당합니다.
ElastiCache 콘솔, 또는 ElastiCache API를 사용하여 새 캐시를 생성하거나 기존 캐시를 업데이트할 때 자동 백업을 활성화AWS CLI하거나 비활성화할 수 ElastiCache. Valkey 및 Redis OSS의 경우 **고급 Valkey 설정** 또는 **고급 Redis OSS 설정** 섹션에서 **자동 백업 활성화** 상자를 선택하면 됩니다. Memcached의 경우 **고급 Memcached 설정** 섹션에서 **자동 백업 활성화** 상자를 선택하면 됩니다.
# 수동 백업 지원
자동 백업 외에도 언제든지 *수동* 백업을 만들 수 있습니다. 지정한 보존 기간 후에 자동으로 삭제되는 자동 백업과 달리 수동 백업에는 나중에 자동으로 삭제되는 보존 기간이 없습니다. 캐시를 삭제하더라도 해당 캐시의 모든 수동 백업은 보존됩니다. 수동 백업을 더 이상 보존하지 않으려면 이 백업을 직접 명시적으로 삭제해야 합니다.
수동 백업을 직접 생성할 뿐 아니라 다음 방법 중 하나로 수동 백업을 생성할 수 있습니다.
+ [백업 복사](backups-copying.md). 소스 백업을 자동으로 생성했는지 수동으로 생성했는지는 중요하지 않습니다.
+ [최종 백업 생성](backups-final.md). 클러스터나 노드를 삭제하기 직전에 백업을 생성합니다.
AWS CLI, 또는 ElastiCache API를 사용하여 캐시AWS Management Console의 수동 백업을 생성할 수 있습니다.
클러스터 모드가 활성화되고 클러스터 모드가 비활성화된 복제본에서 수동 백업을 생성할 수 있습니다.
## 수동 백업 생성(콘솔)
**캐시의 백업을 생성하려면 다음과 같이 하세요(콘솔).**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 기본 설정에 따라 **Valkey 캐시**, **Redis OSS 캐시** 또는 **Memcached 캐시**를 선택합니다.
1. 백업할 캐시의 이름 왼쪽에 있는 상자를 선택합니다.
1. [**Backup**]을 선택합니다.
1. [**Create Backup**] 대화 상자의 [**Backup Name**] 상자에 백업 이름을 입력합니다. 이름은 백업된 클러스터와 백업 날짜 및 시간을 나타내는 것이 좋습니다.
클러스터 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
1. [**Create Backup**]을 선택합니다.
클러스터 상태가 *snapshotting*으로 바뀝니다.
## 수동 백업 생성(AWS CLI)
**를 사용한 서버리스 캐시의 수동 백업AWS CLI**
를 사용하여 캐시의 수동 백업을 생성하려면 다음 파라미터와 함께 `create-serverless-snapshot`AWS CLI작업을AWS CLI사용합니다.
+ `--serverless-cache-name` - 백업하는 서버리스 캐시 이름입니다.
+ `--serverless-cache-snapshot-name` - 생성할 스냅샷의 이름입니다.
Linux, macOS, Unix의 경우:
+
```
aws elasticache create-serverless-snapshot \
--serverless-cache-name CacheName \
--serverless-cache-snapshot-name bkup-20231127
```
Windows의 경우:
+
```
aws elasticache create-serverless-snapshot ^
--serverless-cache-name CacheName ^
--serverless-cache-snapshot-name bkup-20231127
```
**를 사용한 노드 기반 클러스터의 수동 백업AWS CLI**
를 사용하여 노드 기반 클러스터의 수동 백업을 생성하려면 다음 파라미터와 함께 `create-snapshot`AWS CLI작업을AWS CLI사용합니다.
+ `--cache-cluster-id`
+ 백업 중인 클러스터에 복제본 노드가 없으면 `--cache-cluster-id`는 백업 중인 클러스터의 이름입니다(예: *mycluster*).
+ 백업 중인 클러스터에 복제본 노드가 하나 이상 있으면 `--cache-cluster-id`는 백업에 사용하려는 클러스터의 노드 이름입니다. 예를 들면, 이름은 *mycluster-002*일 수 있습니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 백업할 때에만 이 파라미터를 사용합니다.
+ `--replication-group-id` - 백업 원본으로 사용할 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(CLI/API의 경우 복제 그룹)의 이름입니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 백업할 때 이 파라미터를 사용하세요.
+ `--snapshot-name` - 생성할 스냅샷의 이름입니다.
클러스터 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
### 예제 1: 복제본 노드가 없는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 백업
다음AWS CLI작업은 읽기 전용 복제본`myNonClusteredRedis`이 없는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터`bkup-20150515`에서 백업을 생성합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis \
--snapshot-name bkup-20150515
```
Windows의 경우:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis ^
--snapshot-name bkup-20150515
```
### 예제 2: 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 백업
다음AWS CLI작업은 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 `bkup-20150515`에서 백업을 생성합니다`myNonClusteredRedis`. 이 백업에는 하나 이상의 읽기 전용 복제본이 있습니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis-001 \
--snapshot-name bkup-20150515
```
Windows의 경우:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis-001 ^
--snapshot-name bkup-20150515
```
**예제 출력: 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 백업**
이 작업의 출력은 다음과 같습니다.
```
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis6.x",
"VpcId": "vpc-91280df6",
"CacheClusterId": "myNonClusteredRedis-001",
"SnapshotRetentionLimit": 0,
"NumCacheNodes": 1,
"SnapshotName": "bkup-20150515",
"CacheClusterCreateTime": "2017-01-12T18:59:48.048Z",
"AutoMinorVersionUpgrade": true,
"PreferredAvailabilityZone": "us-east-1c",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "08:30-09:30",
"EngineVersion": "6.0",
"NodeSnapshots": [
{
"CacheSize": "",
"CacheNodeId": "0001",
"CacheNodeCreateTime": "2017-01-12T18:59:48.048Z"
}
],
"CacheSubnetGroupName": "default",
"Port": 6379,
"PreferredMaintenanceWindow": "wed:07:30-wed:08:30",
"CacheNodeType": "cache.m3.2xlarge",
"DataTiering": "disabled"
}
}
```
### 예제 3: Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 클러스터 백업
다음AWS CLI작업은 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `bkup-20150515`에서 백업을 생성합니다`myClusteredRedis`. `--replication-group-id` 대신 `--cache-cluster-id`를 사용하여 원본을 식별하세요. 또한 ElastiCache는 복제본 노드가 있는 경우 복제본 노드를 사용하여 백업을 수행하며 복제본 노드를 사용할 수 없는 경우 프라이머리 노드로 설정됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-snapshot \
--replication-group-id myClusteredRedis \
--snapshot-name bkup-20150515
```
Windows의 경우:
```
aws elasticache create-snapshot ^
--replication-group-id myClusteredRedis ^
--snapshot-name bkup-20150515
```
**예제 출력: Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 백업**
이 작업의 출력은 다음과 같이 표시됩니다.
```
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis6.x.cluster.on",
"VpcId": "vpc-91280df6",
"NodeSnapshots": [
{
"CacheSize": "",
"NodeGroupId": "0001"
},
{
"CacheSize": "",
"NodeGroupId": "0002"
}
],
"NumNodeGroups": 2,
"SnapshotName": "bkup-20150515",
"ReplicationGroupId": "myClusteredRedis",
"AutoMinorVersionUpgrade": true,
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "10:00-11:00",
"EngineVersion": "6.0",
"CacheSubnetGroupName": "default",
"ReplicationGroupDescription": "2 shards 2 nodes each",
"Port": 6379,
"PreferredMaintenanceWindow": "sat:03:30-sat:04:30",
"CacheNodeType": "cache.r3.large",
"DataTiering": "disabled"
}
}
```
### 관련 주제
자세한 내용은 *AWS CLI명령 참조*의 [create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-snapshot.html)을 참조하세요.
## 를 사용하여 백업 생성CloudFormation
또는 `AWS::ElastiCache::ServerlessCache` `AWS::ElastiCache::ReplicationGroup` 속성을 사용하여CloudFormation를 사용하여 ElastiCache Redis OSS 또는 Valkey 캐시의 백업을 생성할 수 있습니다.
**`AWS::ElastiCache::ServerlessCache` 리소스 사용 **
이를 사용하여 AWS::ElastiCache::ServerlessCache 리소스로 백업을 생성합니다.
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ServerlessCache
Properties:
...
ServerlessCacheName: "your-cache-name"
Engine: "redis"
CacheUsageLimits
```
**AWS::ElastiCache::ReplicationGroup 리소스 사용 **
`AWS::ElastiCache::ReplicationGroup` 리소스를 사용합니다.
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ReplicationGroup
Properties:
...
ReplicationGroupDescription: "Description of your replication group"
Engine: "redis"
CacheNodeType
NumCacheClusters
AutomaticFailoverEnabled
AtRestEncryptionEnabled
```
# 최종 백업 생성
ElastiCache 콘솔AWS CLI, 또는 ElastiCache API를 사용하여 최종 백업을 생성할 수 있습니다.
## 최종 백업 생성(콘솔)
ElastiCache 콘솔을 사용하여 Valkey, Memcached 또는 Redis OSS 서버리스 캐시, Valkey 또는 Redis OSS 노드 기반 클러스터를 삭제할 때 최종 백업을 생성할 수 있습니다.
캐시를 삭제할 때 최종 백업을 만들려면 대화 상자의 **백업 생성**에서 **예**를 선택하고 백업 이름을 입력합니다.
**관련 주제**
+ [사용AWS Management Console](Clusters.Delete.md#Clusters.Delete.CON)
+ [복제 그룹 삭제(콘솔)](Replication.DeletingRepGroup.md#Replication.DeletingRepGroup.CON)
## 최종 백업 생성(AWS CLI)
AWS CLI를 사용하여 캐시를 삭제할 때 최종 백업을 만들 수 있습니다.
**Topics**
+ [Valkey 캐시, Memcached 서버리스 캐시 또는 Redis OSS 캐시를 삭제할 때](#w2aac24b7c29b7b1b7)
+ [읽기 전용 복제본이 없는 Valkey 또는 Redis OSS 클러스터를 삭제하는 경우](#w2aac24b7c29b7b1b9)
+ [읽기 전용 복제본이 있는 Valkey 또는 Redis OSS 클러스터를 삭제하는 경우](#w2aac24b7c29b7b1c11)
### Valkey 캐시, Memcached 서버리스 캐시 또는 Redis OSS 캐시를 삭제할 때
최종 백업을 생성하려면 다음 파라미터와 함께 `delete-serverless-cache`AWS CLI작업을 사용합니다.
+ `--serverless-cache-name` - 삭제 중인 캐시 이름입니다.
+ `--final-snapshot-name` - 백업 이름입니다.
다음 코드는 캐시 `myserverlesscache`를 삭제할 때 최종 백업 `bkup-20231127-final`을 생성합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache delete-serverless-cache \
--serverless-cache-name myserverlesscache \
--final-snapshot-name bkup-20231127-final
```
Windows의 경우:
```
aws elasticache delete-serverless-cache ^
--serverless-cache-name myserverlesscache ^
--final-snapshot-name bkup-20231127-final
```
자세한 내용은 *AWS CLI명령 참조*의 [delete-serverless-cache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache.html)를 참조하세요.
### 읽기 전용 복제본이 없는 Valkey 또는 Redis OSS 클러스터를 삭제하는 경우
읽기 전용 복제본이 없는 노드 기반 클러스터에 대한 최종 백업을 생성하려면 다음 파라미터와 함께 `delete-cache-cluster`AWS CLI작업을 사용합니다.
+ `--cache-cluster-id` - 삭제 중인 클러스터의 이름입니다.
+ `--final-snapshot-identifier` - 백업 이름입니다.
다음 코드는 클러스터 `myRedisCluster`를 삭제할 때 최종 백업 `bkup-20150515-final`을 생성합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache delete-cache-cluster \
--cache-cluster-id myRedisCluster \
--final-snapshot-identifier bkup-20150515-final
```
Windows의 경우:
```
aws elasticache delete-cache-cluster ^
--cache-cluster-id myRedisCluster ^
--final-snapshot-identifier bkup-20150515-final
```
자세한 내용은 *AWS CLI명령 참조*의 [delete-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-cluster.html)를 참조하세요.
### 읽기 전용 복제본이 있는 Valkey 또는 Redis OSS 클러스터를 삭제하는 경우
복제 그룹을 삭제할 때 최종 백업을 생성하려면 다음 파라미터와 함께 `delete-replication-group`AWS CLI작업을 사용합니다.
+ `--replication-group-id` - 삭제 중인 복제 그룹의 이름입니다.
+ `--final-snapshot-identifier` - 최종 백업 이름입니다.
다음 코드는 복제 그룹 `myReplGroup`을 삭제할 때 최종 백업 `bkup-20150515-final`을 만듭니다.
Linux, macOS, Unix의 경우:
```
aws elasticache delete-replication-group \
--replication-group-id myReplGroup \
--final-snapshot-identifier bkup-20150515-final
```
Windows의 경우:
```
aws elasticache delete-replication-group ^
--replication-group-id myReplGroup ^
--final-snapshot-identifier bkup-20150515-final
```
자세한 내용은 *AWS CLI명령 참조*에서 [delete-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-replication-group.html)을 참조하세요.
# 백업 설명
다음 절차는 백업 목록을 표시하는 방법을 보여줍니다. 원한다면 특정 백업의 세부 정보를 볼 수도 있습니다.
## 백업 설명(콘솔)
**를 사용하여 백업을 표시하려면AWS Management Console**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 [**Backups**]를 선택합니다.
1. 특정 백업의 세부 정보를 보려면 백업 이름 왼쪽의 상자를 선택합니다.
## 서버리스 백업 설명(AWS CLI)
서버리스 백업 목록을 표시하고 필요에 따라 특정 백업에 대한 세부 정보를 표시하려면 `describe-serverless-cache-snapshots` CLI 작업을 사용합니다.
**예시**
다음 작업에서는 `--max-records` 파라미터를 사용하여 계정에 연결된 백업을 20개까지 나열합니다. `--max-records` 파라미터를 생략하면 백업이 50개까지 나열됩니다.
```
aws elasticache describe-serverless-cache-snapshots --max-records 20
```
다음 작업에서는 `--serverless-cache-name` 파라미터를 사용하여 캐시 `my-cache`에 연결된 백업만 나열합니다.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-name my-cache
```
다음 작업에서는 `--serverless-cache-snapshot-name` 파라미터를 사용하여 백업 `my-backup`의 세부 정보를 표시합니다.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-snapshot-name my-backup
```
자세한 내용은AWS CLI명령 참조의 [describe-serverless-cache-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-serverless-cache-snapshots.html)를 참조하세요.
## 노드 기반 클러스터 백업 설명(AWS CLI)
노드 기반 클러스터 백업 목록을 표시하고 특정 백업에 대한 세부 정보를 선택적으로 표시하려면 `describe-snapshots` CLI 작업을 사용하세요.
**예시**
다음 작업에서는 `--max-records` 파라미터를 사용하여 계정에 연결된 백업을 20개까지 나열합니다. `--max-records` 파라미터를 생략하면 백업이 50개까지 나열됩니다.
```
aws elasticache describe-snapshots --max-records 20
```
다음 작업에서는 `--cache-cluster-id` 파라미터를 사용하여 클러스터 `my-cluster`에 연결된 백업만 나열합니다.
```
aws elasticache describe-snapshots --cache-cluster-id my-cluster
```
다음 작업에서는 `--snapshot-name` 파라미터를 사용하여 백업 `my-backup`의 세부 정보를 표시합니다.
```
aws elasticache describe-snapshots --snapshot-name my-backup
```
자세한 내용은AWS CLI명령 참조의 [describe-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-snapshots.html)를 참조하세요.
# 백업 복사
자동 또는 수동으로 백업을 생성했을 때 모든 백업 복사본을 생성할 수 있습니다. 또한 백업을 내보낼 수 있으므로 ElastiCache 외부에서 백업에 액세스할 수 있습니다. 백업을 내보내기 위한 지침은 [백업 내보내기](backups-exporting.md) 섹션을 참조하세요.
다음 단계에서는 백업을 복사하는 방법을 보여 줍니다.
## 백업 복사(콘솔)
**백업을 복사하려면(콘솔)**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 백업 목록을 표시하려면 왼쪽 탐색 창에서 [**Backups**]를 선택합니다.
1. 백업 목록에서 복사할 백업의 이름 왼쪽에 있는 상자를 선택합니다.
1. **작업**, **복사** 순으로 선택합니다.
1. [**New backup name**] 상자에 새 백업의 이름을 입력합니다.
1. **복사**를 선택합니다.
## 서버리스 백업 복사(AWS CLI)
서버리스 캐시의 백업을 복사하려면 `copy-serverless-cache-snapshot` 작업을 사용합니다.
**Parameters**
+ `--source-serverless-cache-snapshot-name` - 복사할 백업의 이름입니다.
+ `--target-serverless-cache-snapshot-name` - 백업 복사본의 이름입니다.
다음 예제에서는 자동 백업 복사본을 만듭니다.
Linux, macOS, Unix의 경우:
```
aws elasticache copy-serverless-cache-snapshot \
--source-serverless-cache-snapshot-name automatic.my-cache-2023-11-27-03-15 \
--target-serverless-cache-snapshot-name my-backup-copy
```
Windows의 경우:
```
aws elasticache copy-serverless-cache-snapshot ^
--source-serverless-cache-snapshot-name automatic.my-cache-2023-11-27-03-15 ^
--target-serverless-cache-snapshot-name my-backup-copy
```
자세한 내용은 *`copy-serverless-cache-snapshot`*의 [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html) 섹션을 참조하세요.
## 노드 기반 클러스터 백업 복사(AWS CLI)
노드 기반 클러스터의 백업을 복사하려면 `copy-snapshot` 작업을 사용합니다.
**Parameters**
+ `--source-snapshot-name` - 복사할 백업의 이름입니다.
+ `--target-snapshot-name` - 백업 복사본의 이름입니다.
+ `--target-bucket` - 백업을 내보내기 위해 예약됩니다. 백업 복사본을 만들 때 이 파라미터를 사용하지 마십시오. 자세한 내용은 [백업 내보내기](backups-exporting.md) 단원을 참조하십시오.
다음 예제에서는 자동 백업 복사본을 만듭니다.
Linux, macOS, Unix의 경우:
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 \
--target-snapshot-name amzn-s3-demo-bucket
```
Windows의 경우:
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 ^
--target-snapshot-name amzn-s3-demo-bucket
```
자세한 내용은 *`copy-snapshot`*의 [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html) 섹션을 참조하세요.
# 백업 내보내기
Amazon ElastiCache에서는 Amazon Simple Storage Service(Amazon S3) 버킷에 ElastiCache for Redis OSS 백업 내보내기가 지원되므로 ElastiCache 외부에서 백업에 액세스할 수 있습니다. ElastiCache 콘솔AWS CLI, 또는 ElastiCache API를 사용하여 백업을 내보낼 수 있습니다.
다른AWS리전에서 클러스터를 시작해야 하는 경우 백업을 내보내는 것이 유용할 수 있습니다. 데이터를 한AWS리전으로 내보내고 .rdb 파일을 새AWS리전으로 복사한 다음 해당 .rdb 파일을 사용하여 새 클러스터가 사용을 통해 채워질 때까지 기다리지 않고 새 캐시를 시드할 수 있습니다. 새 클러스터 시드에 대한 자세한 내용은 [자습서: 외부에서 생성된 백업으로 새로운 노드 기반 클러스터 시드](backups-seeding-redis.md) 섹션을 참조하세요. 오프라인 처리를 위해 .rdb 파일을 사용하기 위해 캐시의 데이터를 내보낼 수도 있습니다.
**중요**
ElastiCache 백업과 이를 복사하려는 Amazon S3 버킷은 동일한AWS리전에 있어야 합니다.
Amazon S3 버킷으로 복사된 백업이 암호화되긴 하지만 백업을 저장하려는 Amazon S3 버킷에 대한 액세스 권한을 다른 사람에게 부여하지 않는 것이 좋습니다.
데이터 계층화를 사용하는 클러스터는 Amazon S3로 백업 내보내기가 지원되지 않습니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 단원을 참조하십시오.
백업 내보내기는 노드 기반 Valkey 클러스터, 노드 기반 Redis OSS 클러스터, Valkey, Memcached 및 Redis OSS 서버리스 캐시에 사용할 수 있습니다. 노드 기반 Memcached 클러스터에는 백업 내보내기를 사용할 수 없습니다.
백업을 Amazon S3 버킷으로 내보내려면 먼저 백업과 동일한AWS리전에 Amazon S3 버킷이 있어야 합니다. 버킷에 ElastiCache 액세스 권한을 부여합니다. 처음 두 단계에서는 이 작업을 수행할 방법을 보여줍니다.
## Amazon S3 버킷 생성
다음 단계에서는 Amazon S3 콘솔을 사용하여 ElastiCache 백업을 내보내고 저장할 Amazon S3 버킷을 생성합니다.
**Amazon S3 버킷을 생성하려면**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. **버킷 생성**을 선택합니다.
1. [**Create a Bucket - Select a Bucket Name and Region**]에서 다음을 수행합니다.
1. **버킷 이름**에서 Amazon S3 버킷의 이름을 입력합니다.
Amazon S3 버킷의 이름은 DNS를 준수해야 합니다. 그렇지 않으면 ElastiCache가 백업 파일에 액세스할 수 없습니다. DNS 준수 규칙은 다음과 같습니다.
+ 이름은 3자 이상, 63자 이하여야 합니다.
+ 이름은 마침표(.)로 구분된 일련의 레이블(1개 이상)이어야 합니다. 여기서 각 레이블은 다음과 같아야 합니다.
+ 소문자 또는 숫자로 시작합니다.
+ 소문자 또는 숫자로 끝납니다.
+ 소문자, 숫자 및 대시만 포함합니다.
+ 이름에는 IP 주소 형식(예: 192.0.2.0)을 사용할 수 없습니다.
1. **리전** 목록에서 Amazon S3 버킷의AWS리전을 선택합니다. 이AWS리전은 내보내려는 ElastiCache 백업과 동일한AWS리전이어야 합니다.
1. **생성(Create)**을 선택합니다.
Amazon S3 버킷 생성에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html)을 참조하세요.
## Amazon S3 버킷에 대한 ElastiCache 액세스 권한 부여
ElastiCache에서 스냅샷을 Amazon S3 버킷에 복사할 수 있게 하려면 버킷 정책을 업그레이드하여 IAM 버킷에 대한 ElastiCache 액세스 권한을 부여해야 합니다.
**주의**
Amazon S3 버킷으로 복사된 백업이 암호화되더라도 Amazon S3 버킷에 대한 액세스 권한이 있는 사람이 데이터에 액세스할 수 있습니다. 따라서 이 Amazon S3 버킷에 대한 무단 액세스를 방지하도록 IAM 정책을 설정하는 것이 좋습니다. 자세한 정보는 *Amazon S3 사용 설명서*의 [액세스 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html)를 참조하세요.
Amazon S3 버킷에 대한 적절한 권한을 생성하려면 다음 단계를 수행합니다.
**S3 버킷에 ElastiCache 액세스 권한 부여**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. 백업을 복사할 Amazon S3 버킷 이름을 선택합니다. [Amazon S3 버킷 생성](#backups-exporting-create-s3-bucket)에서 생성한 S3 버킷이어야 합니다.
1. **권한(Permissions)** 탭을 선택하고 **권한(Permissions)**에서 **ACL(액세스 제어 목록)(Access control list (ACL))**을 선택한 다음 **편집(Edit)**을 선택합니다.
1. 다음 옵션을 사용하여 피부여자 정식 ID `540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353`을 추가합니다.
+ **객체: 나열, 쓰기(Objects: List, Write)**
+ **버킷 ACL: 읽기, 쓰기(Bucket ACL: Read, Write)**
**참고**
PDT GovCloud 리전의 경우 정식 ID는 `40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6`입니다.
OSU GovCloud 리전의 경우 정식 ID는 `c54286759d2a83da9c480405349819c993557275cf37d820d514b42da6893f5c`입니다.
1. **저장**을 선택합니다.
## ElastiCache 백업 내보내기
이제 S3 버킷을 생성하고 ElastiCache에 액세스할 수 있는 권한을 부여했습니다. 다음으로 ElastiCache 콘솔,AWS CLI 또는 ElastiCache API를 사용하여 스냅샷을 내보낼 수 있습니다.
다음은 업데이트된 정책의 예입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399484",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
}
]
}
```
------
옵트인 리전의 경우, S3 버킷을 위해 업데이트된 IAM 정책은 다음 예와 유사합니다. (이 예에서는 아시아 태평양(홍콩) 리전을 사용합니다.)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
},
{
"Sid": "Stmt15399484",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
}
]
}
```
------
### ElastiCache 백업 내보내기(콘솔)
다음 단계에서는 ElastiCache 외부에서 액세스할 수 있도록 ElastiCache 콘솔을 사용하여 Amazon S3 버킷에 백업을 내보냅니다. Amazon S3 버킷은 ElastiCache 백업과 동일한AWS리전에 있어야 합니다.
**Amazon S3 버킷으로 ElastiCache 백업을 내보내려면**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 백업 목록을 표시하려면 왼쪽 탐색 창에서 [**Backups**]를 선택합니다.
1. 백업 목록에서 내보낼 백업의 이름 왼쪽에 있는 상자를 선택합니다.
1. **복사**를 선택합니다.
1. **백업 복사본을 생성**에서 다음 작업을 수행하세요.
1. [**New backup name**] 상자에 새 백업의 이름을 입력합니다.
이름은 1\$11,000자여야 하며 UTF-8 인코딩일 수 있습니다.
ElastiCache에서는 여기에 입력하는 값에 인스턴스 식별자 및 `.rdb`를 추가합니다. 예를 들어 `my-exported-backup`을 입력하면 ElastiCache에서 `my-exported-backup-0001.rdb`를 생성합니다.
1. **대상 S3 위치** 목록에서 백업을 복사할 Amazon S3 버킷([Amazon S3 버킷 생성](#backups-exporting-create-s3-bucket)에서 생성한 버킷)을 선택합니다.
**대상 S3 위치**는 내보내기 프로세스가 성공하려면 다음 권한이 있는 백업AWS리전의 Amazon S3 버킷이어야 합니다.
+ 객체 액세스 - **읽기** 및 **쓰기**.
+ 권한 액세스 - **읽기**.
자세한 내용은 [Amazon S3 버킷에 대한 ElastiCache 액세스 권한 부여](#backups-exporting-grant-access) 단원을 참조하십시오.
1. **복사**를 선택합니다.
**참고**
ElastiCache에서 백업을 내보내는 데 필요한 권한이 S3 버킷에 없으면 다음 오류 메시지 중 하나를 받습니다. [Amazon S3 버킷에 대한 ElastiCache 액세스 권한 부여](#backups-exporting-grant-access)로 돌아가 지정한 권한을 추가하고 백업 내보내기를 다시 시도하세요.
S3 버킷에 대한 READ 권한이 ElastiCache에 부여되지 않았습니다.
**해결 방법:** 버킷에 대한 읽기 권한을 추가합니다.
S3 버킷에 대한 WRITE 권한이 ElastiCache에 부여되지 않았습니다.
**해결 방법:** 버킷에 대한 쓰기 권한을 추가합니다.
S3 버킷에 대한 READ\$1ACP 권한이 ElastiCache에 부여되지 않았습니다.
**해결 방법:** 버킷에 대한 권한 액세스로 [**Read**]를 추가합니다.
백업을 다른AWS리전에 복사하려면 Amazon S3를 사용하여 복사합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [객체 복사](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MakingaCopyofanObject.html)를 참조하세요.
### ElastiCache 서버리스 백업 내보내기(AWS CLI)
**서버리스 캐시 백업 내보내기**
다음 파라미터와 함께 `export-serverless-cache-snapshot` CLI 작업을 사용하여 Amazon S3 버킷에 백업을 내보냅니다.
**Parameters**
+ `--serverless-cache-snapshot-name` - 복사할 백업의 이름입니다.
+ `--s3-bucket-name` - 백업을 내보낼 Amazon S3 버킷의 이름입니다. 지정한 버킷에 백업 복사본이 생성됩니다.
내보내기 프로세스가 성공하려면가 다음 권한이 있는 백업AWS리전의 Amazon S3 버킷이어야 `--s3-bucket-name` 합니다.
+ 객체 액세스 - **읽기** 및 **쓰기**.
+ 권한 액세스 - **읽기**.
다음 작업은 my-s3-bucket에 백업을 복사합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache export-serverless-cache-snapshot \
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 \
--s3-bucket-name my-s3-bucket
```
Windows의 경우:
```
aws elasticache export-serverless-cache-snapshot ^
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 ^
--s3-bucket-name my-s3-bucket
```
### 노드 기반 ElastiCache 클러스터 백업 내보내기(AWS CLI)
**노드 기반 클러스터의 백업 내보내기**
다음 파라미터와 함께 `copy-snapshot` CLI 작업을 사용하여 Amazon S3 버킷에 백업을 내보냅니다.
**Parameters**
+ `--source-snapshot-name` - 복사할 백업의 이름입니다.
+ `--target-snapshot-name` - 백업 복사본의 이름입니다.
이름은 1\$11,000자여야 하며 UTF-8 인코딩일 수 있습니다.
ElastiCache에서는 여기에 입력하는 값에 인스턴스 식별자 및 `.rdb`를 추가합니다. 예를 들어 `my-exported-backup`을 입력하면 ElastiCache에서 `my-exported-backup-0001.rdb`를 생성합니다.
+ `--target-bucket` - 백업을 내보낼 Amazon S3 버킷의 이름입니다. 지정한 버킷에 백업 복사본이 생성됩니다.
내보내기 프로세스가 성공하려면가 다음 권한이 있는 백업AWS리전의 Amazon S3 버킷이어야 `--target-bucket` 합니다.
+ 객체 액세스 - **읽기** 및 **쓰기**.
+ 권한 액세스 - **읽기**.
자세한 내용은 [Amazon S3 버킷에 대한 ElastiCache 액세스 권한 부여](#backups-exporting-grant-access) 단원을 참조하십시오.
다음 작업은 my-s3-bucket에 백업을 복사합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2016-06-27-03-15 \
--target-snapshot-name my-exported-backup \
--target-bucket my-s3-bucket
```
Windows의 경우:
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2016-06-27-03-15 ^
--target-snapshot-name my-exported-backup ^
--target-bucket my-s3-bucket
```
# 백업에서 새 캐시로 복원
Valkey의 기존 백업을 새 Valkey 캐시 또는 노드 기반 클러스터로 복원하고 기존 Redis OSS 백업을 새 Redis OSS 캐시 또는 노드 기반 클러스터로 복원할 수 있습니다. 기존 Memcached 서버리스 캐시 백업을 새 Memcached 서버리스 캐시로 복원할 수도 있습니다.
## 서버리스 캐시로 백업 복원(콘솔)
**참고**
ElastiCache 서버리스는 Valkey 7.2 이상과 호환되는 RDB 파일 및 5.0 및 최신 버전 사이의 Redis OSS 버전을 지원합니다.
**서버리스 캐시로 백업을 복원하려면 다음과 같이 하세요(콘솔).**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 [**Backups**]를 선택합니다.
1. 백업 목록에서 복원할 백업의 이름 왼쪽에 있는 상자를 선택합니다.
1. **작업**을 선택한 다음 **복원**을 선택합니다.
1. 새 서버리스 캐시의 이름과 설명(선택 사항)을 입력합니다.
1. **생성**을 클릭하여 새 캐시를 생성하고 백업에서 데이터를 가져옵니다.
## 백업을 노드 기반 클러스터로 복원(콘솔)
**백업을 노드 기반 클러스터로 복원하려면(콘솔)**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 [**Backups**]를 선택합니다.
1. 백업 목록에서 복원할 백업의 이름 왼쪽에 있는 상자를 선택합니다.
1. **작업**을 선택한 다음 **복원**을 선택합니다.
1. **노드 기반 캐시**를 선택하고 노드 유형, 크기, 샤드 수, 복제본, AZ 배치, 보안 설정 등 클러스터 설정을 사용자 지정합니다.
1. **생성**을 선택하여 새 노드 기반 클러스터를 생성하고 백업에서 데이터를 가져옵니다.
## 서버리스 캐시로 백업 복원(AWS CLI)
**참고**
ElastiCache 서버리스는 Valkey 7.2 이상과 호환되는 RDB 파일 및 5.0 및 최신 버전 사이의 Redis OSS 버전을 지원합니다.
**서버리스 캐시로 백업을 복원하려면 다음과 같이 하세요(AWS CLI).**
다음AWS CLI예제에서는를 사용하여 새 캐시를 생성하고 백업에서 데이터를 `create-serverless-cache` 가져옵니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine redis
--snapshot-arns-to-restore Snapshot-ARN
```
Windows의 경우:
```
aws elasticache create-serverless-cache ^
--serverless-cache-name CacheName ^
--engine redis ^
--snapshot-arns-to-restore Snapshot-ARN
```
# 백업 삭제
보존 기간 제한이 만료되면 자동 백업이 자동으로 삭제됩니다. 클러스터를 삭제하면 모든 자동 백업도 삭제됩니다. 복제 그룹을 삭제하면 해당 그룹에 속한 클러스터의 모든 자동 백업도 삭제됩니다.
백업이 자동으로 생성되건 수동으로 생성되건 관계없이 ElastiCache에서는 언제든지 백업을 삭제할 수 있는 삭제 API 작업을 제공합니다. 수동 백업에는 보존 제한이 없으므로 수동 삭제를 통해서만 수동 백업을 제거할 수 있습니다.
ElastiCache 콘솔AWS CLI, 또는 ElastiCache API를 사용하여 백업을 삭제할 수 있습니다.
## 백업 삭제(콘솔)
다음 절차에서는 ElastiCache 콘솔을 사용하여 백업을 삭제합니다.
**백업 삭제**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **백업**을 선택합니다.
백업 화면에 백업 목록이 나타납니다.
1. 삭제할 백업의 이름 왼쪽에 있는 상자를 선택합니다.
1. **삭제**를 선택합니다.
1. 이 백업을 삭제하려면 [**Delete Backup**] 확인 화면에서 [**Delete**]를 선택합니다. 상태가 *삭제 중(deleting)*으로 변경됩니다.
## 서버리스 백업 삭제(AWS CLI)
다음 파라미터와 함께 delete-snapshot AWS CLI작업을 사용하여 서버리스 백업을 삭제합니다.
+ `--serverless-cache-snapshot-name` - 삭제할 백업의 이름입니다.
다음 코드는 `myBackup` 백업을 삭제합니다.
```
aws elasticache delete-serverless-cache-snapshot --serverless-cache-snapshot-name myBackup
```
자세한 내용은 *AWS CLI명령 참조*의 [delete-serverless-cache-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache-snapshot.html)을 참조하세요.
## 노드 기반 클러스터 백업 삭제(AWS CLI)
다음 파라미터와 함께 delete-snapshot AWS CLI작업을 사용하여 노드 기반 클러스터 백업을 삭제합니다.
+ `--snapshot-name` - 삭제할 백업의 이름입니다.
다음 코드는 `myBackup` 백업을 삭제합니다.
```
aws elasticache delete-snapshot --snapshot-name myBackup
```
자세한 내용은 *AWS CLI명령 참조*의 [delete-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-snapshot.html)을 참조하세요.
# 백업 태그 지정
사용자 고유의 메타데이터를 태그 형태로 각 백업에 할당할 수 있습니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 백업을 다양한 방식으로 분류할 수 있습니다. 이 기능은 동일 유형의 리소스가 많을 때 유용합니다. 지정한 태그에 따라 특정 리소스를 빠르게 식별할 수 있습니다. 자세한 내용은 [태그 지정이 가능한 리소스](Tagging-Resources.md#Tagging-your-resources) 섹션을 참조하세요.
비용 할당 태그는 태그 값으로 인보이스의 비용을 그룹화하여 여러 AWS 서비스에서 비용을 추적하는 수단입니다. 비용 할당 태그에 대해 자세히 알아보려면 [비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)을 참조하세요.
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 백업에서 비용 할당 태그를 추가, 나열, 수정, 제거 또는 복사할 수 있습니다. 자세한 내용은 [비용 할당 태그를 사용하여 비용 모니터링](Tagging.md) 섹션을 참조하세요.
# 자습서: 외부에서 생성된 백업으로 새로운 노드 기반 클러스터 시드
Valkey 또는 Redis OSS의 새로운 노드 기반 클러스터를 만들 때 Valkey 또는 Redis OSS .rdb 백업 파일의 데이터로 이 클러스터를 시드할 수 있습니다. 현재 ElastiCache 외부에서 Valkey 또는 Redis OSS 인스턴스를 관리하면서 ElastiCache for Redis OSS의 새로운 노드 기반 클러스터에 기존의 Valkey 또는 Redis OSS 데이터를 채우려는 경우 클러스터 시드가 유용합니다.
Amazon ElastiCache에서 생성한 Valkey 또는 Redis OSS 백업 파일에서 Valkey 또는 Redis OSS의 새로운 노드 기반 클러스터를 시드하려면 [백업에서 새 캐시로 복원](backups-restoring.md) 섹션을 참조하세요.
Valkey 또는 Redis OSS .rdb 파일을 사용하여 새로운 노드 기반 클러스터를 시드할 때 다음을 수행할 수 있습니다.
+ 분할되지 않은 클러스터에서 Redis OSS 버전 3.2.4를 실행하는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)의 노드 기반 클러스터로 업그레이드합니다.
+ 새 노드 기반 클러스터에서 여러 샤드(API 및 CLI에서 노드 그룹이라고 함)를 지정합니다. 이 숫자는 백업 파일을 생성하는 데 사용된 노드 기반 클러스터의 샤드 수와 다를 수 있습니다.
+ 백업을 만든 클러스터에 사용된 것보다 크거나 작은 새 노드 기반 클러스터의 다른 노드 유형을 지정합니다. 더 작은 노드 유형으로 조정하는 경우 새로운 노드 유형에 충분한 메모리가 있어 데이터와 Valkey 또는 Redis OSS 오버헤드를 수용할 수 있어야 합니다. 자세한 내용은 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md) 단원을 참조하십시오.
+ 백업 파일 생성에 사용한 클러스터에서와 다른 새 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 슬롯에 키를 배포합니다.
**참고**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 생성된 .rdb 파일에서 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 시드할 수 없습니다.
**중요**
Valkey 또는 Redis OSS 백업 데이터가 노드의 리소스를 초과하지 않아야 합니다. 예를 들어 Valkey 또는 Redis OSS 데이터가 5GB인 .rdb 파일을 메모리가 2.9GB인 cache.m3.medium 노드에 업로드할 수 없습니다.
백업이 너무 크면 결과 클러스터의 상태는 `restore-failed`가 됩니다. 이 경우 클러스터를 삭제하고 다시 시작해야 합니다.
노드 유형 및 사양의 전체 목록은 [Redis OSS 노드 유형별 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) 및 [Amazon ElastiCache 제품 기능 및 세부 정보](https://aws.amazon.com/elasticache/details/)를 참조하세요.
Amazon S3 서버 측 암호화(SSE-S3)만으로 Valkey 또는 Redis OSS .rdb 파일을 암호화할 수 있습니다. 자세한 내용은 [서버 측 암호화를 사용하여 데이터 보호](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html)를 참조하세요.
아래에서는 Valkey 또는 Redis OSS용 ElastiCache 외부에서 ElastiCache for Redis OSS로 클러스터를 마이그레이션하는 과정을 안내하는 항목을 찾을 수 있습니다.
**Topics**
+ [1단계: Valkey 또는 Redis OSS 백업 생성](#backups-seeding-redis-create-backup)
+ [2단계: Amazon S3 버킷 및 폴더 생성](#backups-seeding-redis-create-s3-bucket)
+ [3단계: Amazon S3에 백업 업로드](#backups-seeding-redis-upload)
+ [4단계: ElastiCache에 .rdb 파일에 대한 읽기 액세스 부여](#backups-seeding-redis-grant-access)
**Topics**
+ [1단계: Valkey 또는 Redis OSS 백업 생성](#backups-seeding-redis-create-backup)
+ [2단계: Amazon S3 버킷 및 폴더 생성](#backups-seeding-redis-create-s3-bucket)
+ [3단계: Amazon S3에 백업 업로드](#backups-seeding-redis-upload)
+ [4단계: ElastiCache에 .rdb 파일에 대한 읽기 액세스 부여](#backups-seeding-redis-grant-access)
## 1단계: Valkey 또는 Redis OSS 백업 생성
**ElastiCache for Redis OSS 인스턴스를 시드할 Valkey 또는 Redis OSS 백업을 생성하려면**
1. 기존의 Valkey 또는 Redis OSS 인스턴스에 연결합니다.
1. `BGSAVE` 또는 `SAVE` 작업을 실행하여 백업을 생성합니다. .rdb 파일의 위치를 메모합니다.
`BGSAVE`는 비동기식이며 처리하는 동안 다른 클라이언트를 차단하지 않습니다. 자세한 내용은 Valkey 웹 사이트의 [BGSAVE](https://valkey.io/commands/bgsave)를 참조하세요.
`SAVE`는 동기식이며 마칠 때까지 다른 프로세스를 차단합니다. 자세한 내용은 Valkey 웹 사이트의 [SAVE](https://valkey.io/commands/save)를 참조하세요.
백업 생성에 대한 추가 정보는 Valkey 웹 사이트의 [지속성](https://valkey.io/topics/persistence)을 참조하십시오.
## 2단계: Amazon S3 버킷 및 폴더 생성
백업 파일을 만들었으면 Amazon S3 버킷에 있는 폴더에 업로드해야 합니다. 그러려면 먼저 Amazon S3 버킷과 버킷 내의 폴더가 있어야 합니다. 적절한 권한을 가진 Amazon S3 버킷과 폴더가 이미 있으면 [3단계: Amazon S3에 백업 업로드](#backups-seeding-redis-upload) 섹션으로 건너뛸 수 있습니다.
**Amazon S3 버킷을 생성하려면**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. *Amazon Simple Storage Service 사용 설명서*에서 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html)의 Amazon S3 버킷 생성 지침을 따릅니다.
Amazon S3 버킷의 이름은 DNS를 준수해야 합니다. 그렇지 않으면 ElastiCache가 백업 파일에 액세스할 수 없습니다. DNS 준수 규칙은 다음과 같습니다.
+ 이름은 3자 이상, 63자 이하여야 합니다.
+ 이름은 마침표(.)로 구분된 일련의 레이블(1개 이상)이어야 합니다. 여기서 각 레이블은 다음과 같아야 합니다.
+ 소문자 또는 숫자로 시작합니다.
+ 소문자 또는 숫자로 끝납니다.
+ 소문자, 숫자 및 대시만 포함합니다.
+ 이름에는 IP 주소 형식(예: 192.0.2.0)을 사용할 수 없습니다.
새 ElastiCache for Redis OSS 클러스터와 동일한AWS리전에 Amazon S3 버킷을 생성해야 합니다. 이 방법은 ElastiCache가 Amazon S3에서 .rdb 파일을 읽을 때 최고의 데이터 전송 속도를 경험할 수 있도록 합니다.
**참고**
데이터를 최대한 안전하게 유지하려면 Amazon S3 버킷에 대한 권한을 최대한 제한적으로 설정합니다. 또한 새 Valkey 또는 Redis OSS 클러스터를 시드하는 데 버킷과 버킷의 콘텐츠를 사용하기 위해 권한이 계속 필요합니다.
**Amazon S3 버킷에 폴더를 추가하려면**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. .rdb 파일을 업로드할 버킷 이름을 선택합니다.
1. **폴더 생성**을 선택합니다.
1. 새 폴더의 이름을 입력합니다.
1. **저장**을 선택합니다.
버킷 이름과 폴더 이름을 모두 메모합니다.
## 3단계: Amazon S3에 백업 업로드
이제 [1단계: Valkey 또는 Redis OSS 백업 생성](#backups-seeding-redis-create-backup)에서 생성한 .rdb 파일을 업로드합니다. [2단계: Amazon S3 버킷 및 폴더 생성](#backups-seeding-redis-create-s3-bucket)에서 생성한 Amazon S3 버킷과 폴더로 업로드합니다. 이 작업에 대한 자세한 내용은 [버킷에 객체 추가](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)를 참조하세요. 2단계와 3단계 사이에 생성된 폴더 이름을 선택합니다.
**.rdb 파일을 Amazon S3 폴더에 업로드하려면**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. 2단계에서 만든 Amazon S3 버킷 이름을 선택합니다.
1. 2단계에서 만든 폴더 이름을 선택합니다.
1. **업로드**를 선택합니다.
1. **Add Files**를 선택합니다.
1. 업로드할 파일을 찾아 선택합니다. 파일을 여러 개 선택하려면 Ctrl 키를 누른 상태로 각 파일 이름을 선택합니다.
1. **Open**을 선택합니다.
1. [**Upload**] 대화 상자에서 정확한 파일 이름이 표시되는지 확인하고 [**Upload**]를 선택합니다.
.rdb 파일에 대한 경로를 기록합니다. 예를 들어 버킷 이름이 `myBucket`이고 경로가 `myFolder/redis.rdb`이면 `myBucket/myFolder/redis.rdb`를 입력합니다. 이 백업의 데이터로 새 클러스터를 시드하려면 이 경로가 필요합니다.
자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 규제 및 제한](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html)을 참조하세요.
## 4단계: ElastiCache에 .rdb 파일에 대한 읽기 액세스 부여
이제 ElastiCache에 .rdb 백업 파일에 대한 읽기 액세스 권한을 부여합니다. 버킷이 기본AWS리전 또는 옵트인AWS리전에 있는지에 따라 ElastiCache에 백업 파일에 대한 액세스 권한을 다른 방식으로 부여합니다.
AWS 2019년 3월 20일 이전에 도입된 리전은 기본적으로 활성화됩니다. 이러한AWS리전에서 즉시 작업을 시작할 수 있습니다. 아시아 태평양(홍콩) 및 중동(바레인)과 같이 2019년 3월 20일 이후에 도입된 리전은 기본적으로 비활성 상태입니다. 사용하려면 먼저 **AWS 일반 참조의 [AWS리전 관리](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)에 설명된 대로 리전을 활성화하거나 옵트인해야 합니다.
AWS리전에 따라 접근 방식을 선택합니다.
+ 기본 리전의 경우 [ElastiCache에 기본 리전의 .rdb 파일에 대한 읽기 액세스 권한 부여](#backups-seeding-redis-default-region)의 절차를 사용합니다.
+ 옵트인 리전의 경우 [ElastiCache에 옵트인 리전의 .rdb 파일에 대한 읽기 액세스 권한 부여](#backups-seeding-opt-in-region)의 절차를 사용합니다.
### ElastiCache에 기본 리전의 .rdb 파일에 대한 읽기 액세스 권한 부여
AWS 2019년 3월 20일 이전에 도입된 리전은 기본적으로 활성화됩니다. 이러한AWS리전에서 즉시 작업을 시작할 수 있습니다. 아시아 태평양(홍콩) 및 중동(바레인)과 같이 2019년 3월 20일 이후에 도입된 리전은 기본적으로 비활성 상태입니다. 사용하려면 먼저 **AWS 일반 참조의 [AWS리전 관리](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)에 설명된 대로 리전을 활성화하거나 옵트인해야 합니다.
**ElastiCache에 기본적으로 활성화된AWS리전의 백업 파일에 대한 읽기 액세스 권한을 부여하려면**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. .rdb 파일이 포함된 S3 버킷 이름을 선택합니다.
1. .rdb 파일이 포함된 폴더 이름을 선택합니다.
1. .rdb 백업 파일 이름을 선택합니다. 선택한 파일 이름은 페이지 맨 위의 탭 위에 나타납니다.
1. **권한**을 선택합니다.
1. **aws-scs-s3-readonly** 또는 다음 목록에 있는 정식 ID 중 하나가 사용자로 나열되지 않으면 다음을 수행합니다.
1. **다른AWS계정에 대한 액세스**에서 피부**여자 추가**를 선택합니다.
1. 상자에 다음과 같이AWS리전의 정식 ID를 추가합니다.
+ AWS GovCloud(미국 서부) 리전:
```
40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6
```
**중요**
Valkey 또는 Redis OSS 클러스터에 다운로드AWS GovCloud (US)하려면의 S3 버킷에 백업이 있어야 합니다AWS GovCloud (US).
+ AWS기본적으로 활성화된 리전:
```
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
```
1. 다음에 대해 **예**를 선택하여 버킷에 대한 권한을 설정합니다.
+ **나열/쓰기 객채(List/write object)**
+ **Read/write object ACL permissions**(읽기/쓰기 객체 ACL 권한)
1. **저장**을 선택합니다.
1. **개요**를 선택한 다음 **다운로드**를 선택합니다.
### ElastiCache에 옵트인 리전의 .rdb 파일에 대한 읽기 액세스 권한 부여
AWS 2019년 3월 20일 이전에 도입된 리전은 기본적으로 활성화됩니다. 이러한AWS리전에서 즉시 작업을 시작할 수 있습니다. 아시아 태평양(홍콩) 및 중동(바레인)과 같이 2019년 3월 20일 이후에 도입된 리전은 기본적으로 비활성 상태입니다. 사용하려면 먼저 **AWS 일반 참조의 [AWS리전 관리](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)에 설명된 대로 리전을 활성화하거나 옵트인해야 합니다.
이제 ElastiCache에 .rdb 백업 파일에 대한 읽기 액세스 권한을 부여합니다.
**ElastiCache에 백업 파일에 대한 읽기 액세스 권한 부여**
1. 에 로그인AWS Management Console하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. .rdb 파일이 포함된 S3 버킷 이름을 선택합니다.
1. .rdb 파일이 포함된 폴더 이름을 선택합니다.
1. .rdb 백업 파일 이름을 선택합니다. 선택한 파일 이름은 페이지 맨 위의 탭 위에 나타납니다.
1. **권한** 탭을 선택합니다.
1. **권한(Permissions)**에서 **버킷 정책(Bucket policy)**을 선택한 다음 **편집(Edit)**을 선택합니다.
1. 정책을 업데이트하여 ElastiCache에 작업을 수행하는 데 필요한 권한을 부여합니다.
+ `[ "Service" : "region-full-name.elasticache-snapshot.amazonaws.com" ]`을 `Principal`에 추가합니다.
+ Amazon S3 버킷으로 스냅샷을 내보내는 데 필요한 다음 권한을 추가합니다.
+ `"s3:GetObject"`
+ `"s3:ListBucket"`
+ `"s3:GetBucketAcl"`
다음은 업데이트된 정책의 예입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/backup1.rdb",
"arn:aws:s3:::amzn-s3-demo-bucket/backup2.rdb"
]
}
]
}
```
------
1. **변경 사항 저장**을 선택합니다.
### .rdb 파일 데이터로 ElastiCache 클러스터 시드
이제 ElastiCache 클러스터를 생성하고 .rdb 파일의 데이터로 클러스터를 시드할 수 있습니다. 클러스터를 생성하려면 [Valkey 또는 Redis OSS용 클러스터 생성](Clusters.Create.md) 또는 [처음부터 Valkey 또는 Redis OSS 복제 그룹 생성](Replication.CreatingReplGroup.NoExistingCluster.md)의 지시를 따릅니다. Valkey 또는 Redis OSS를 클러스터 엔진으로 선택해야 합니다.
Amazon S3에 업로드한 백업의 위치를 ElastiCache에 알리는 데 사용하는 방법은 클러스터 생성에 사용한 방법에 따라 결정됩니다.
**ElastiCache for Redis OSS 클러스터 또는 .rdb 파일 데이터 포함 복제 그룹 시드**
+ **ElastiCache 콘솔 사용**
**클러스터 설정**을 선택할 때 클러스터 생성 방법으로 **백업에서 복원**을 선택한 다음, **백업 소스** 섹션에서 **소스**로 **기타 백업**을 선택합니다. **RDB 파일 시드 S3 위치** 상자에 파일의 Amazon S3 경로를 입력합니다. .rdb 파일이 여러 개 있으면 쉼표로 구분된 목록에 각 파일의 경로를 입력합니다. Amazon S3 경로는 `myBucket/myFolder/myBackupFilename.rdb`처럼 표시될 수 있습니다.
+ **사용AWS CLI**
`create-cache-cluster` 또는 `create-replication-group` 작업을 사용하는 경우 `--snapshot-arns` 파라미터를 사용하여 각 .rdb 파일의 정규화된 ARN을 지정합니다. 예를 들어 `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`입니다. ARN은 Amazon S3에 저장한 백업 파일로 확인되어야 합니다.
+ **ElastiCache API 사용**
`CreateCacheCluster` 또는 `CreateReplicationGroup` ElastiCache API 작업을 사용하는 경우`SnapshotArns` 파라미터 를 사용하여 각 .rdb 파일의 정규화된 ARN을 지정합니다. 예를 들어 `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`입니다. ARN은 Amazon S3에 저장한 백업 파일로 확인되어야 합니다.
**중요**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 시드 시 새 클러스터 또는 복제 그룹에서 각 노드 그룹(샤드)을 구성해야 합니다. 이를 수행하려면 `--node-group-configuration`(API: `NodeGroupConfiguration`) 파라미터를 사용합니다. 자세한 내용은 다음을 참조하세요.
CLI:AWS CLI참조의 [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
API: ElastiCache API 참조의 [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
클러스터 생성 프로세스 중에 Valkey 또는 Redis OSS 백업의 데이터가 클러스터에 쓰여집니다. ElastiCache 이벤트 메시지를 보면서 프로세스를 모니터링할 수 있습니다. 그러려면 ElastiCache 콘솔 화면에서 **캐시 이벤트(Cache Events)**를 선택합니다.AWS ElastiCache 명령줄 인터페이스 또는 ElastiCache API를 사용하여 이벤트 메시지를 가져올 수도 있습니다. 자세한 내용은 [ElastiCache 이벤트 보기](ECEvents.Viewing.md) 단원을 참조하십시오.
# ElastiCache의 엔진 버전 및 업그레이드
이 섹션에서는 지원되는 Valkey, Memcached 및 Redis OSS 엔진과 업그레이드 방법에 대해 설명합니다. Redis OSS 7.2에서 사용할 수 있는 모든 기능은 기본적으로 Valkey 7.2 이상에서 사용할 수 있습니다. 기존 ElastiCache for Redis OSS 엔진을 Valkey 엔진으로 업그레이드할 수도 있습니다.
# 엔진 간 업그레이드를 포함한 엔진 버전 업그레이드
**Valkey 및 Redis OSS**
Valkey 및 Redis OSS를 사용하면 ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 클러스터 또는 복제 그룹을 수정하고 최신 엔진 버전을 지정하여 버전 업그레이드를 시작할 수 있습니다.
Redis OSS에서 Valkey로 교차 업그레이드할 수도 있습니다. 교차 업그레이드 방법에 대한 자세한 내용은 [Redis OSS에서 Valkey로의 엔진 간 업그레이드 방법](#VersionManagement.HowTo.cross-engine-upgrade) 섹션을 참조하세요.
**Topics**
+ [Redis OSS에서 Valkey로의 엔진 간 업그레이드 방법](#VersionManagement.HowTo.cross-engine-upgrade)
+ [차단된 Valkey 또는 Redis OSS 엔진 업그레이드 해결](#resolving-blocked-engine-upgrades)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Memcached**
Memcached 사용 시, 클러스터로 버전 업그레이드를 시작하려면 이를 수정하고 새 엔진 버전을 지정합니다. ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 이 작업을 수행할 수 있습니다.
+ AWS Management Console 사용 시에는 [ElastiCache AWS Management Console 사용](Clusters.Modify.md#Clusters.Modify.CON) 섹션을 참조하세요.
+ AWS CLI 사용 시에는 [ElastiCache와 함께 AWS CLI 사용](Clusters.Modify.md#Clusters.Modify.CLI) 섹션을 참조하세요.
+ ElastiCache API를 사용하려면 [ElastiCache API 사용](Clusters.Modify.md#Clusters.Modify.API) 섹션을 참조하세요.
## Redis OSS에서 Valkey로의 엔진 간 업그레이드 방법
Valkey는 Redis OSS 7의 드롭인 대체품으로 설계되었습니다. 새 엔진 및 메이저 엔진 버전을 지정하여 콘솔, API 또는 CLI를 사용하여 Redis OSS에서 Valkey로 업그레이드할 수 있습니다. 업그레이드로 인해 엔드포인트 IP 주소와 애플리케이션의 다른 모든 측면이 변경되지는 않습니다. Redis OSS 5.0.6 이상에서 업그레이드할 때 가동 중지 시간이 발생하지 않습니다.
**참고**
**Redis OSS에서 Valkey로의 업그레이드에 대한 AWS CLI 버전 요구 사항:**
AWS CLI v1: 최소 필수 버전 1.35.2(현재 버전: 1.40.22)
AWS CLI v2: 최소 필수 버전 2.18.2(현재 버전: 2.27.22)
**참고**
5.0.6 이전의 Redis OSS 버전에서 업그레이드할 때 DNS 전파 중에 장애 조치 시간이 30\$160초가 될 수 있습니다.
기존 Redis OSS(클러스터 모드 비활성화됨) 단일 노드 클러스터를 Valkey 엔진으로 업그레이드하려면 먼저 다음 단계를 따르세요. [기존 클러스터를 사용하여 복제 그룹 생성](Replication.CreatingReplGroup.ExistingCluster.md). Redis OSS(클러스터 모드 비활성화됨) 단일 노드 클러스터가 복제 그룹에 추가되면 Valkey로 교차 엔진 업그레이드를 수행할 수 있습니다.
### Redis OSS에서 Valkey로 복제 그룹 업그레이드
기본 캐시 파라미터 그룹을 사용하는 기존 Redis OSS 복제 그룹이 있는 경우 modify-replication-group API를 사용하여 새 엔진과 엔진 버전을 지정하여 Valkey로 업그레이드할 수 있습니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0
```
업그레이드하려는 기존 Redis OSS 복제 그룹에 사용자 지정 캐시 파라미터 그룹이 적용된 경우 요청에서 사용자 지정 Valkey 캐시 파라미터 그룹도 전달해야 합니다. 입력 Valkey 사용자 지정 파라미터 그룹은 기존 Redis OSS 사용자 지정 파라미터 그룹과 동일한 Redis OSS 정적 파라미터 값을 가져야 합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0 \
--cache-parameter-group-name myParamGroup
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--cache-parameter-group-name myParamGroup
```
### CLI를 사용하여 Redis OSS 서버리스 캐시를 Valkey로 업그레이드
Linux, macOS, Unix의 경우:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name myCluster \
--engine valkey \
--major-engine-version 8
```
Windows의 경우:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name myCluster ^
--engine valkey ^
--major-engine-version 8
```
### 콘솔을 사용하여 Redis OSS를 Valkey로 업그레이드
**Redis OSS 5에서 Valkey로 업그레이드**
1. 업그레이드할 Redis OSS 캐시를 선택합니다.
1. **Valkey로 업그레이드** 창이 나타나야 합니다. **Valkey로 업그레이드** 버튼을 선택합니다.
1. **캐시 설정**으로 이동한 다음 **엔진 버전**을 선택합니다. Valkey의 최신 버전이 권장됩니다.
1. 이 캐시가 서버리스인 경우 파라미터 그룹을 업데이트해야 합니다. **캐시 설정**의 **파라미터 그룹** 영역으로 이동하여 *default.valkey8*과 같은 적절한 파라미터 그룹을 선택합니다.
1. **업그레이드**를 선택하세요.
이제이 캐시가 콘솔의 Valkey 영역에 나열됩니다.
**참고**
Redis OSS 4 이하에서 Valkey로 직접 업그레이드하면 DNS 전파 중에 장애 조치 시간이 30\$160초 더 길어질 수 있습니다.
### Valkey에서 Redis OSS로 다운그레이드하는 방법
어떤 이유로든 업그레이드된 클러스터를 롤백하려는 경우 Amazon ElastiCache는 Valkey 7.2 캐시를 Redis OSS 7.1로 롤백하도록 지원합니다. 엔진 업그레이드와 동일한 콘솔, API 또는 CLI 단계를 사용하고 Redis OSS 7.1을 대상 엔진 버전으로 지정하여 롤백을 수행할 수 있습니다. 롤백은 업그레이드와 동일한 프로세스를 사용합니다. 엔드포인트 IP 주소와 애플리케이션의 다른 모든 측면은 롤백에 의해 변경되지 않으며 가동 중지 시간이 발생하지 않습니다.
또한 Valkey 7.2 캐시에서 생성된 스냅샷을 Redis OSS 7.1 캐시로 복원할 수 있습니다. 스냅샷에서 복원할 때 Redis OSS 7.1을 대상 엔진 버전으로 지정할 수 있습니다. 이 옵션을 사용하면 스냅샷에서 새 캐시가 생성됩니다. 스냅샷에서 복원해도 스냅샷이 생성된 Valkey 캐시에는 영향을 주지 않습니다.
롤백을 수행할 때 다음 요구 사항 및 제한 사항이 적용됩니다.
+ ElastiCache는 Valkey 7.2에서 Redis OSS 7.1로의 롤백만 지원합니다. 이는 Redis OSS 7.1 이전 버전에서 Valkey 7.2로 업그레이드한 경우에도 마찬가지입니다.
+ 롤백되는 복제 그룹 또는 서버리스 캐시와 연결된 모든 사용자 그룹 및 사용자는 엔진 유형 `REDIS`로 구성해야 합니다.
## 차단된 Valkey 또는 Redis OSS 엔진 업그레이드 해결
다음 표에 표시된 대로 대기 중인 스케일 업 작업이 있는 경우, Valkey 또는 Redis OSS 엔진 업그레이드 작업이 차단됩니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**차단된 Valkey 또는 Redis OSS 엔진 업그레이드를 해결하려면**
+ 다음 중 하나를 수행합니다.
+ **즉시 적용** 확인란을 선택 취소하여 다음 유지 관리 기간에 대해 Redis OSS 또는 Valkey 엔진 업그레이드 작업을 예약합니다.
CLI의 경우, `--no-apply-immediately`를 사용합니다. API의 경우, `ApplyImmediately=false`를 사용합니다.
+ Redis OSS 엔진 업그레이드 작업을 수행하기 위해 다음 유지 관리 기간(또는 그 이후)까지 기다립니다.
+ **즉시 적용** 확인란을 선택한 채로 이 클러스터 수정 사항에 Redis OSS 스케일 업 작업을 추가합니다.
CLI의 경우, `--apply-immediately`를 사용합니다. API의 경우, `ApplyImmediately=true`를 사용합니다.
이러한 접근 방식에서는 이를 즉시 수행하여 다음 유지 관리 기간 동안 엔진 업그레이드를 효과적으로 취소합니다.
# ElastiCache 추가 지원
ElastiCache 추가 지원을 사용하면 표준 지원 종료일이 지난 후 메이저 엔진 버전에서 추가 비용을 지불하고 캐시를 계속 실행할 수 있습니다. 표준 지원 종료일 이후에 업그레이드하지 않으면 요금이 부과됩니다.
추가 지원은 다음과 같은 업데이트 및 기술 지원을 제공합니다.
+ 캐시 및 캐시 엔진의 중요하고 높은 CVE에 대한 보안 업데이트
+ 중요한 문제에 대한 버그 수정 및 패치
+ 표준 ElastiCache 서비스 수준 계약 내에서 지원 사례를 열고 문제 해결 지원을 받을 수 있는 기능
이 유료 기능을 사용하면 지원되는 메이저 엔진 버전으로 업그레이드하는 데 더 많은 시간을 할애할 수 있습니다.
예를 들어 Redis OSS 4.0.10에 대한 ElastiCache 표준 지원 종료일은 2026년 1월 31일입니다. 해당 날짜까지 Valkey 또는 Redis OSS 6 이상으로 수동으로 업그레이드할 준비가 되지 않은 경우 ElastiCache는 추가 지원에 캐시를 자동으로 등록하고 Redis OSS 4.0.10을 계속 실행할 수 있습니다. 표준 지원이 종료된 다음 달 1일부터 2026년 2월 1일부터 ElastiCache는 자동으로 추가 지원 요금을 청구합니다.
추가 지원은 메이저 엔진 버전의 표준 지원 종료일이 지난 후 최대 3년 동안 제공됩니다. Elasticache for Redis OSS 버전 4 및 5의 경우 2029년 1월 31일이 됩니다. 이 날짜 이후에는 Redis OSS 버전 4 및 5를 계속 실행하는 모든 캐시가 Valkey의 최신 버전으로 자동 업그레이드됩니다.
엔진의 지원 기간이 끝나면 이전 버전을 계속 실행하는 캐시가 자동으로 추가 지원으로 전환됩니다. 대신 인스턴스를 업그레이드할 수 있도록 추가 지원 요금 시작일 이전에 알림을 받게 됩니다. 지원되는 버전으로 업그레이드하여 언제든지 명시적으로 옵트아웃할 수도 있습니다.
표준 지원 종료일 및 추가 지원 종료일에 대한 자세한 내용은 Valkey, Memcached 또는 Redis OSS를 위한 [ElastiCache for Redis OSS 버전의 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 섹션을 참조하세요.
**Topics**
+ [ElastiCache 추가 지원 요금](extended-support-charges.md)
+ [ElastiCache 추가 지원이 포함된 버전](extended-support-versions.md)
+ [ElastiCache 추가 지원을 통한 ElastiCache 및 고객 책임](extended-support-responsibilities.md)
# ElastiCache 추가 지원 요금
표준 지원 종료일 이후부터 ElastiCache 추가 지원에 등록된 모든 엔진에 대해 요금이 부과됩니다. ElastiCache 표준 지원 종료일에 대해 알아보려면 [ElastiCache 추가 지원이 포함된 버전](extended-support-versions.md) 섹션을 참조하세요.
다음 작업 중 하나를 수행하는 경우 ElastiCache 추가 지원에 대한 추가 요금이 자동으로 중지됩니다.
+ 표준 지원이 적용되는 엔진 버전으로 업그레이드하세요.
+ ElastiCache 표준 지원 종료일이 지난 메이저 버전을 실행 중인 캐시를 삭제합니다.
향후 대상 엔진 버전이 추가 지원으로 전환되면 요금이 다시 부과됩니다.
예를 들어 ElastiCache for Redis OSS 버전 4가 2026년 2월 1일에 추가 지원을 시작하고 v4의 캐시를 2027년 1월 1일에 v6으로 업그레이드한다고 가정해 보겠습니다. ElastiCache for Redis OSS 버전 4에서는 11개월의 추가 지원에 대해서만 요금이 부과됩니다. 표준 지원 종료일인 2027년 1월 31일 이후에도 ElastiCache for Redis OSS 버전 6을 계속 실행하면 해당 캐시에는 2027년 2월 1일부터 추가 지원 요금이 다시 발생합니다.
ElastiCache 표준 지원 종료일 이후에 ElastiCache가 캐시를 생성하거나 복원하지 못하도록 하여 ElastiCache 추가 지원에 대한 요금이 부과되지 않도록 할 수 있습니다.
자세한 내용은 [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/)을 참조하세요.
# ElastiCache 추가 지원이 포함된 버전
Redis 오픈 소스 소프트웨어(OSS) 버전 4와 5는 각각 2020년과 2022년에 커뮤니티 수명 종료에 도달했습니다. 즉, 커뮤니티에서 추가 업데이트, 버그 수정 또는 보안 패치를 릴리스하지 않습니다. ElastiCache의 ElastiCache Redis OSS 버전 4 및 5에 대한 표준 지원은 2026년 1월 31일에 종료됩니다. 지원되지 않는 버전의 Redis OSS를 계속 사용하면 데이터가 알려진 [일반적인 취약성 및 노출](https://nvd.nist.gov/vuln-metrics/cvss)(CVE)에 데이터를 취약하게 만들 수 있습니다.
2026년 2월 1일부터 Redis OSS 버전 4 및 5에서 여전히 실행 중인 ElastiCache 캐시는 지속적인 가용성과 보안을 제공하기 위해 추가 지원에 자동으로 등록됩니다. 추가 지원은 유연성을 제공하지만 표준 지원 종료를 프로덕션 워크로드의 계획 마일스톤으로 처리하는 것이 좋습니다. 표준 지원이 종료되기 전에 Redis OSS v4 및 v5 캐시를 ElastiCache for Valkey 또는 Redis OSS v6 이상으로 업그레이드하는 것이 좋습니다.
다음 표에는 Amazon ElastiCache 표준 지원 종료일 및 추가 지원 날짜가 요약되어 있습니다.
**추가 지원 및 수명 종료 일정**
| 메이저 엔진 버전 | 표준 지원 종료일 | 추가 지원 Y1 Premium 시작 | 추가 지원 Y2 Premium 시작 | 추가 지원 Y3 Premium 시작 | 추가 지원 종료 및 버전 수명 종료 |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 |
| Redis OSS v5 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 |
| Redis OSS v6 | 1/31/2027 | 2/1/2027 | 2/1/2028 | 2/1/2029 | 1/31/2030 |
추가 지원은 각 주요 Redis OSS 버전의 지원되는 최신 패치 버전에만 제공됩니다. 추가 지원이 2026년 2월 1일에 시작되면 Redis OSS v4 및 v5 클러스터가 아직 최신 패치 버전에 있지 않은 경우 추가 지원에 등록되기 전에 Redis OSS v4의 경우 v4.0.10으로, Redis OSS v5의 경우 v5.0.6으로 자동 업그레이드됩니다. 이렇게 하면 추가 지원을 통해 보안 업데이트 및 버그 수정을 받을 수 있습니다. 추가 지원 전환의 일환으로 이러한 최신 패치 버전으로 업그레이드하기 위해 조치를 취할 필요가 없습니다.
# ElastiCache 추가 지원을 통한 ElastiCache 및 고객 책임
다음은 Amazon ElastiCache의 책임과 ElastiCache 추가 지원에 대한 사용자의 책임입니다.
**Amazon ElastiCache 책임**
ElastiCache의 표준 지원 종료일 이후, Amazon ElastiCache는 ElastiCache 추가 지원에 등록된 엔진에 대한 패치, 버그 수정 및 업그레이드를 제공합니다. 이는 최대 3년 동안 또는 추가 지원의 엔진 사용을 중지할 때까지(둘 중 먼저 발생하는 날짜) 지원됩니다.
**귀하의 책임**
ElastiCache 추가 지원에서 캐시에 대해 제공된 패치, 버그 수정 및 업그레이드를 적용할 책임은 사용자에게 있습니다. Amazon ElastiCache는 언제든지 이러한 패치, 버그 수정 및 업그레이드를 변경, 교체 또는 철회할 권한을 보유합니다. 보안 또는 중요한 안정성 문제를 해결하기 위해 패치가 필요한 경우 Amazon ElastiCache는 패치로 캐시를 업데이트하거나 패치를 설치하도록 요구할 수 있는 권한을 보유합니다.
또한 ElastiCache의 추가 지원 종료일 이전에 엔진을 최신 엔진 버전으로 업그레이드하는 것은 사용자의 책임입니다. ElastiCache 추가 지원 종료일은 일반적으로 ElastiCache 표준 지원 종료일로부터 3년입니다.
엔진을 업그레이드하지 않으면 ElastiCache 추가 지원 종료일 이후에 Amazon ElastiCache가 ElastiCache 표준 지원에서 지원되는 최신 엔진 버전으로 엔진 업그레이드를 시도합니다. 업그레이드에 실패하면 Amazon ElastiCache는 ElastiCache 표준 지원 종료일 이후에 엔진을 실행하는 캐시를 삭제할 수 있는 권한을 보유합니다. 하지만 이렇게 하기 전에 Amazon ElastiCache는 해당 엔진의 데이터를 보존합니다.
# ElastiCache용 버전 관리
Valkey, Memcached 및 Redis OSS 엔진에 맞게 업데이트된 ElastiCache 캐시 및 노드 기반 클러스터를 업데이트하는 방법을 관리합니다.
## ElastiCache 서버리스 캐시용 버전 관리
ElastiCache 서버리스 캐시가 업그레이드되는 경우 및 시기를 관리하고, 자체 조건과 일정에 맞춰 버전 업그레이드를 수행합니다.
ElastiCache Serverless는 애플리케이션에 영향을 미치거나 가동 중지 시간을 발생시키지 않고 최신 마이너 및 패치 소프트웨어 버전을 캐시에 자동으로 적용합니다. 여러분은 아무 작업도 수행할 필요가 없습니다.
새 메이저 버전이 사용 가능하면 ElastiCache Serverless는 콘솔에서 알림을 보내고 EventBridge에서 이벤트를 보냅니다. 콘솔, CLI 또는 API를 사용하여 캐시를 수정하고 최신 엔진 버전을 선택하여 캐시를 최신 메이저 버전으로 업그레이드할 수 있습니다. 마이너 및 패치 업그레이드와 마찬가지로 메이저 버전 업그레이드는 애플리케이션의 가동 중지 시간 없이 수행됩니다.
## 노드 기반 ElastiCache 클러스터의 버전 관리
노드 기반 ElastiCache 클러스터로 작업하는 경우 ElastiCache에서 지원되는 새 버전으로 클러스터를 실행하는 소프트웨어를 업그레이드할 때 제어할 수 있습니다. 캐시를 사용 가능한 최신 메이저, 마이너, 패치 버전으로 업그레이드할 시기를 제어할 수 있습니다. 클러스터 또는 복제 그룹을 수정하고 새 엔진 버전을 지정하여 엔진 버전 업그레이드를 시작합니다.
사용자는 클러스터를 실행하는 프로토콜 표준 소프트웨어를 ElastiCache에서 제공하는 새 버전으로 업그레이드할지 여부와 그 시기를 조정할 수 있습니다. 이 제어 수준을 사용하면 특정 버전과의 호환성을 유지하고, 프로덕션에 배포하기 전에 애플리케이션으로 새 버전을 테스트하고, 원하는 조건과 일정에 맞춰 버전 업그레이드를 수행할 수 있습니다.
버전 업그레이드에는 약간의 호환성 위험이 있을 수 있으므로 업그레이드가 자동으로 이루어지지 않기 때문에 업그레이드는 사용자가 시작해야 합니다.
**Valkey 및 Redis OSS 클러스터**
**참고**
Valkey 또는 Redis OSS 클러스터가 하나 이상의 리전에 복제되면 엔진 버전이 보조 리전에 대해 업그레이드된 후 기본 리전에 대해 업그레이드됩니다.
ElastiCache for Redis OSS 버전은 메이저, 마이너 구성 요소를 구성하는 시맨틱 버전과 일치합니다. 예를 들어 Redis OSS 6.2에서 메이저 버전은 6, 마이너 버전은 2입니다. 노드 기반 클러스터를 운영하는 경우 ElastiCache for Redis OSS는 패치 구성 요소(예: Redis OSS 6.2.1)도 노출하며 패치 버전은 1입니다.
메이저 버전은 API 비호환 변경 사항을 위한 것이고 마이너 버전은 이전 버전과 호환되는 방식으로 추가된 새로운 기능을 위한 것입니다. 패치 버전은 이전 버전과 호환되는 버그 수정 및 비기능 변경용입니다.
Valkey 및 Redis OSS를 사용하면 클러스터 또는 복제 그룹을 수정하고 새 엔진 버전을 지정하여 엔진 버전 업그레이드를 시작할 수 있습니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 단원을 참조하십시오.
**Memcached**
Memcached를 사용하여 최신 버전으로 업그레이드하려면 클러스터를 수정하고 사용할 새 엔진 버전을 지정해야 합니다. 최신 Memcached 버전으로의 업그레이드는 안전하지 않은 프로세스로, 데이터가 손상되고 콜드 캐시로 시작합니다. 자세한 내용은 [ElastiCache 클러스터 수정](Clusters.Modify.md) 단원을 참조하십시오.
이전 Memcached 버전을 Memcached 버전 1.4.33 이후로 업그레이드할 때 다음과 같은 요구 사항을 주의해야 합니다. 다음 조건에서는 `CreateCacheCluster` 및 `ModifyCacheCluster`에 실패합니다.
+ `slab_chunk_max > max_item_size`의 경우.
+ `max_item_size modulo slab_chunk_max != 0`의 경우.
+ `max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4)`의 경우.
`(max_cache_memory - memcached_connections_overhead)` 값은 데이터에 사용할 수 있는 노드의 메모리입니다. 자세한 내용은 [Memcached 연결 오버헤드](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead) 단원을 참조하십시오.
## 지원되는 엔진 및 버전
ElastiCache Serverless 캐시는 ElastiCache for Valkey 버전 7.2 이상, ElastiCache for Memcached 버전 1.6 이상, ElastiCache for Redis OSS 7.0이상을 지원합니다.
노드 기반 ElastiCache 클러스터는 ElastiCache for Valkey 버전 7.2 이상, ElastiCache for Memcached 버전 1.4.5 이상, ElastiCache for Redis OSS 4.0.10 이상을 지원합니다.
**Topics**
+ [지원되는 Valkey 버전](#supported-engine-versions.valkey)
+ [Valkey 8.2](#valkey-version-8.2)
+ [Valkey 8.1](#valkey-version-8.1)
+ [Valkey 8.0](#valkey-version-8)
+ [ElastiCache for Valkey 버전 7.2.6](#valkey-version-7.2.6)
### 지원되는 Valkey 버전
지원되는 Valkey 버전은 다음과 같습니다. Valkey는 기본적으로 ElastiCache for Redis OSS 버전 7.2에서 사용할 수 있는 대부분의 기능을 지원합니다.
+ 5.0.6 이전 버전으로 ElastiCache 클러스터를 업그레이드할 수도 있습니다. 관련된 프로세스는 동일하지만 DNS 전파 중에 장애 조치 시간이 더 길어질 수 있습니다(30s-1m).
+ Redis OSS 7부터 ElastiCache는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)와 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 간의 전환을 지원합니다.
+ Amazon ElastiCache for Redis OSS 엔진 업그레이드 프로세스는 기존 데이터를 최대한 유지할 수 있도록 진행되며, 성공적인 Redis OSS 복제가 필요합니다.
+ 엔진을 업그레이드할 때 ElastiCache는 기존 클라이언트 연결을 종료합니다. 엔진 업그레이드 중 가동 중지 시간을 최소화하려면 오류 재시도 및 지수 백오프를 사용하는 [Redis OSS 클라이언트의 모범 사례](BestPractices.Clients.redis.md)와 [유지 관리 중 가동 중지 시간 최소화](BestPractices.MinimizeDowntime.md)를 위한 모범 사례를 구현하는 것이 좋습니다.
+ 엔진을 업그레이드할 때 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에서 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)로 직접 업그레이드할 수 없습니다. 다음 절차에서는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에서 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)로 업그레이드하는 방법을 보여줍니다.
**Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에서 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)로 엔진 버전을 업그레이드하려면**
1. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 또는 복제 그룹에 대한 백업을 만듭니다. 자세한 내용은 [수동 백업 지원](backups-manual.md) 단원을 참조하십시오.
1. 백업을 사용하여 샤드가 하나인 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(노드 그룹)를 만들고 시드합니다. 클러스터 또는 복제 그룹을 생성할 때 새 엔진 버전을 지정하고 클러스터 모드를 활성화합니다. 자세한 내용은 [자습서: 외부에서 생성된 백업으로 새로운 노드 기반 클러스터 시드](backups-seeding-redis.md) 단원을 참조하십시오.
1. 이전 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 또는 복제 그룹을 삭제합니다. 자세한 내용은 [ElastiCache에서 클러스터 삭제](Clusters.Delete.md) 또는 [복제 그룹 삭제](Replication.DeletingRepGroup.md)을 참조하세요.
1. 새 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 또는 복제 그룹을 필요한 샤드(노드 그룹) 수까지 확장합니다. 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) 섹션을 참조하세요.
+ 메이저 엔진 버전을 업그레이드하는 경우(예: 5.0.6에서 6.0으로 업그레이드) 새 엔진 버전과 호환되는 새 파라미터 그룹도 선택해야 합니다.
+ 단일 Redis OSS 클러스터 및 다중 AZ가 비활성화된 클러스터의 경우 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)에 명시된 대로 Redis OSS에 충분한 메모리를 사용할 수 있도록 하는 것이 좋습니다. 이러한 경우 업그레이드 프로세스 중에는 서비스 요청에 기본 항목을 사용할 수 없습니다.
+ 다중 AZ가 활성화된 Redis OSS 클러스터의 경우, 수신 쓰기 트래픽이 낮은 기간 동안 엔진 업그레이드를 예약하는 것이 좋습니다. Redis OSS 5.0.6 이상으로 업그레이드하면 업그레이드 프로세스 동안 기본 클러스터를 서비스 요청에 계속 사용할 수 있습니다.
샤드가 여러 개인 클러스터 및 복제 그룹은 다음과 같이 처리되고 패치가 적용됩니다.
+ 모든 샤드는 병렬로 처리됩니다. 언제든지 하나의 샤드에서 오직 하나의 업그레이드 작업이 수행됩니다.
+ 각 샤드에서 기본 복제본이 처리되기 전에 모든 복제본이 처리됩니다. 하나의 샤드에 복제본이 적게 있는 경우에는 다른 샤드의 복제본의 처리가 완료되기 전에 해당 샤드의 기본 복제본이 처리됩니다.
+ 모든 샤드에서 프라이머리 노드가 연속하여 처리됩니다. 한번에 오직 하나의 프라이머리 노드가 업그레이드됩니다.
+ 현재 클러스터 또는 복제 그룹에서 암호화가 활성화되어 있는 경우에는 암호화를 지원하지 않는 엔진 버전으로 업그레이드할 수 없습니다(예를 들면 3.2.6에서 3.2.10로 업그레이드 불가능).
**Memcached 고려 사항**
노드 기반 Memcached 클러스터를 업그레이드할 때만 다음 내용을 고려합니다.
+ 엔진 버전 관리는 패치 발생 방법을 최대한 제어할 수 있도록 설계되었습니다. 그러나 ElastiCache는 시스템 또는 캐시 소프트웨어에 심각한 보안 취약성이 발견되는 등 발생할 가능성이 거의 없는 이벤트의 경우 사용자를 대신하여 클러스터에 패치를 적용할 수 있는 권한을 보유합니다.
+ Memcached 엔진은 지속성을 지원하지 않으므로 Memcached 엔진 버전 업그레이드는 항상 클러스터에서 모든 캐시 데이터를 지우는 방해가 되는 프로세스입니다.
### ElastiCache for Valkey 버전 8.2
다음은 Valkey 8.2에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Valkey 8.1과 비교).
+ [벡터 검색](vector-search.md)을 기본적으로 지원하므로 수십억 개의 고차원 벡터 임베딩을 마이크로초 미만의 지연 시간으로 메모리에 저장, 인덱싱, 검색 및 업데이트할 수 있습니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
벡터 검색을 도입하는 Valkey 8.2 릴리스에 대한 자세한 내용은 [Valkey 검색](https://github.com/valkey-io/valkey-search)을 참조하세요.
### ElastiCache for Valkey 버전 8.1
다음은 Valkey 8.1에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Valkey 8.0과 비교).
+ 일반적인 키/값 패턴에 대해 메모리 오버헤드를 줄여 메모리 사용량을 최대 20% 줄이는 [새로운 해시 테이블](https://valkey.io/blog/new-hash-table/) 구현입니다.
+ 데이터 유형 설정 사용에 비해 메모리를 최대 98% 적게 사용하여 조회를 수행할 수 있는 새로운 데이터 유형인 [Bloom 필터](https://valkey.io/topics/bloomfilters/)를 기본적으로 지원합니다.
+ 느린 실행, 큰 요청 및 큰 응답을 기록하는 새로운 명령 [COMMANDLOG](https://valkey.io/commands/commandlog-get/)입니다.
+ IFEQ 인수를 사용하여 SET 명령에 대한 새로운 조건부 업데이트를 지원합니다.
+ ZRANK 명령의 최대 45% 더 짧은 지연 시간, PFMERGE 및 PFCOUNT의 최대 12배 더 빠른 성능, BITCOUNT의 최대 514% 더 높은 처리량을 포함한 성능을 개선합니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
Valkey 8.1 릴리스에 대한 자세한 내용은 [Valkey 8.1 릴리스 정보](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Valkey 버전 8.0
다음은 Valkey 8.0에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Valkey 7.2.6과 비교).
+ 메모리 효율성이 개선되어 사용자가 애플리케이션 변경 없이 노드당 최대 20% 더 많은 데이터를 저장할 수 있습니다.
+ 노드 기반 클러스터에 대해 새로 도입된 슬롯별 지표 인프라를 통해 개별 슬롯의 성능 및 리소스 사용량에 대한 자세한 가시성을 제공합니다.
+ Valkey 8.0용 ElastiCache Serverless는 2\$13분마다 지원되는 초당 요청 수(RPS)를 두 배로 늘려 13분 이내에 캐시당 5M RPS에 도달할 수 있으며, 밀리초 미만의 일관된 p50 읽기 지연 시간을 제공합니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
Valkey 8 릴리스에 대한 자세한 내용은 [Valkey 8 릴리스 정보](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Valkey 버전 7.2.6
2024년 10월 10일, ElastiCache for Valkey 7.2.6가 릴리스되었습니다. 다음은 7.2에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Redis OSS 버전 7.1과 비교).
+ 다양한 데이터 유형에 대한 성능 및 메모리 최적화: 목록 및 세트 유형 키에 대한 메모리 최적화, 정렬된 세트 명령에 대한 속도 최적화, 클러스터 모드에 여러 키가 있는 명령에 대한 성능 최적화, pub/sub 성능 개선, SCAN, SSCAN, HSCAN, ZSCAN 명령 및 기타 여러 소규모 최적화를 수행했습니다.
+ ZRANK 및 ZREVRANK 명령에 대한 새로운 WITHSCORE 옵션
+ CLIENT NO-TOUCH - 클라이언트가 키의 LRU/LFU에 영향을 주지 않고 명령을 실행할 수 있습니다.
+ 새 명령 CLUSTER MYSHARDID는 복제를 기반으로 클러스터 모드에서 노드를 논리적으로 그룹화하기 위해 노드의 샤드 ID를 반환합니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
Valkey용 ElastiCache 버전 7.2 릴리스에 대한 자세한 내용은 [Redis OSS 7.2.4 릴리스 정보](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES)를 참조하세요(ElastiCache for Valkey 버전 7.2에는 ElastiCache for Redis OSS 버전 7.1부터 ElastiCache for Redis OSS 버전 7.2.4까지의 모든 변경 사항이 포함됨). GitHub의 Valkey에서 [Valkey 7.2 릴리스 정보](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES).
## ElastiCache for Valkey 버전 8.2
다음은 Valkey 8.2에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Valkey 8.1과 비교).
+ [벡터 검색](vector-search.md)을 기본적으로 지원하므로 수십억 개의 고차원 벡터 임베딩을 마이크로초 미만의 지연 시간으로 메모리에 저장, 인덱싱, 검색 및 업데이트할 수 있습니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
벡터 검색을 도입하는 Valkey 8.2 릴리스에 대한 자세한 내용은 [Valkey 검색](https://github.com/valkey-io/valkey-search)을 참조하세요.
## ElastiCache for Valkey 버전 8.1
다음은 Valkey 8.1에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Valkey 8.0과 비교).
+ 일반적인 키/값 패턴에 대해 메모리 오버헤드를 줄여 메모리 사용량을 최대 20% 줄이는 [새로운 해시 테이블](https://valkey.io/blog/new-hash-table/) 구현입니다.
+ 데이터 유형 설정 사용에 비해 메모리를 최대 98% 적게 사용하여 조회를 수행할 수 있는 새로운 데이터 유형인 [Bloom 필터](https://valkey.io/topics/bloomfilters/)를 기본적으로 지원합니다.
+ 느린 실행, 큰 요청 및 큰 응답을 기록하는 새로운 명령 [COMMANDLOG](https://valkey.io/commands/commandlog-get/)입니다.
+ IFEQ 인수를 사용하여 SET 명령에 대한 새로운 조건부 업데이트를 지원합니다.
+ ZRANK 명령의 최대 45% 더 짧은 지연 시간, PFMERGE 및 PFCOUNT의 최대 12배 더 빠른 성능, BITCOUNT의 최대 514% 더 높은 처리량을 포함한 성능을 개선합니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
Valkey 8.1 릴리스에 대한 자세한 내용은 [Valkey 8.1 릴리스 정보](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)를 참조하세요.
## ElastiCache for Valkey 버전 8.0
다음은 Valkey 8.0에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Valkey 7.2.6과 비교).
+ 메모리 효율성이 개선되어 사용자가 애플리케이션 변경 없이 노드당 최대 20% 더 많은 데이터를 저장할 수 있습니다.
+ 노드 기반 클러스터에 대해 새로 도입된 슬롯별 지표 인프라를 통해 개별 슬롯의 성능 및 리소스 사용량에 대한 자세한 가시성을 제공합니다.
+ Valkey 8.0용 ElastiCache Serverless는 2\$13분마다 지원되는 초당 요청 수(RPS)를 두 배로 늘려 13분 이내에 캐시당 5M RPS에 도달할 수 있으며, 밀리초 미만의 일관된 p50 읽기 지연 시간을 제공합니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
Valkey 8 릴리스에 대한 자세한 내용은 [Valkey 8 릴리스 정보](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)를 참조하세요.
## ElastiCache for Valkey 버전 7.2.6
2024년 10월 10일, ElastiCache for Valkey 7.2.6가 릴리스되었습니다. 다음은 7.2에 도입된 몇 가지 새로운 기능입니다(ElastiCache for Redis OSS 버전 7.1과 비교).
+ 다양한 데이터 유형에 대한 성능 및 메모리 최적화: 목록 및 세트 유형 키에 대한 메모리 최적화, 정렬된 세트 명령에 대한 속도 최적화, 클러스터 모드에 여러 키가 있는 명령에 대한 성능 최적화, pub/sub 성능 개선, SCAN, SSCAN, HSCAN, ZSCAN 명령 및 기타 여러 소규모 최적화를 수행했습니다.
+ ZRANK 및 ZREVRANK 명령에 대한 새로운 WITHSCORE 옵션
+ CLIENT NO-TOUCH - 클라이언트가 키의 LRU/LFU에 영향을 주지 않고 명령을 실행할 수 있습니다.
+ 새 명령 CLUSTER MYSHARDID는 복제를 기반으로 클러스터 모드에서 노드를 논리적으로 그룹화하기 위해 노드의 샤드 ID를 반환합니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요.
Valkey용 ElastiCache 버전 7.2 릴리스에 대한 자세한 내용은 [Redis OSS 7.2.4 릴리스 정보](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES)를 참조하세요(ElastiCache for Valkey 버전 7.2에는 ElastiCache for Redis OSS 버전 7.1부터 ElastiCache for Redis OSS 버전 7.2.4까지의 모든 변경 사항이 포함됨). GitHub의 Valkey에서 [Valkey 7.2 릴리스 정보](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES).
## 지원되는 Redis OSS 엔진 버전
ElastiCache Serverless 캐시 및 노드 기반 클러스터는 모든 Redis OSS 버전 7.1 이하를 지원합니다.
+ [ElastiCache for Redis OSS 버전 7.1(향상된 버전)](#redis-version-7.1)
**Topics**
+ [ElastiCache for Redis OSS 버전 7.1(향상된 버전)](#redis-version-7.1)
+ [ElastiCache for Redis OSS 버전 7.0(향상된 버전)](#redis-version-7.0)
+ [ElastiCache for Redis OSS 버전 6.2(향상된 버전)](#redis-version-6.2)
+ [ElastiCache for Redis OSS 버전 6.0(향상된 버전)](#redis-version-6.0)
+ [ElastiCache for Redis OSS 버전 5.0.6(향상된 버전)](#redis-version-5-0.6)
+ [ElastiCache for Redis OSS 버전 5.0.5(사용 중단, 버전 5.0.6 사용)](#redis-version-5-0.5)
+ [ElastiCache for Redis OSS 버전 5.0.4(사용 중단, 버전 5.0.6 사용)](#redis-version-5-0.4)
+ [ElastiCache for Redis OSS 버전 5.0.3(사용 중단, 버전 5.0.6 사용)](#redis-version-5-0.3)
+ [ElastiCache for Redis OSS 버전 5.0.0(사용 중단, 버전 5.0.6 사용)](#redis-version-5-0)
+ [ElastiCache for Redis OSS 버전 4.0.10(향상된 버전)](#redis-version-4-0-10)
+ [수명 종료(EOL) 지난 버전(3.x)](#redis-version-3-2-10-scheduled-eol)
+ [수명 종료(EOL) 지난 버전(2.x)](#redis-version-2-x-eol)
### ElastiCache for Redis OSS 버전 7.1(향상된 버전)
이번 릴리스에는 워크로드의 처리량을 높이고 작업 지연 시간을 줄일 수 있는 성능 개선 사항이 포함되어 있습니다. ElastiCache for Redis OSS 버전 7.1에는 [2가지 주요 개선 사항이 도입되었습니다](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/).
프레젠테이션 계층 로직도 처리하도록 향상된 I/O 스레드 기능이 확장되었습니다. 프레젠테이션 계층이란 이제 향상된 I/O 스레드가 클라이언트 입력을 읽을 뿐만 아니라 입력을 Redis OSS 바이너리 명령 형식으로 구문 분석한다는 의미입니다. 그런 다음 기본 스레드로 전달되어 실행되므로 성능이 향상됩니다. Redis OSS 메모리 액세스 패턴이 개선되었습니다. 여러 데이터 구조 작업의 실행 단계가 삽입되므로 병렬 메모리 액세스가 보장되고 메모리 액세스 지연 시간이 단축됩니다. Graviton3 기반 `R7g.4xlarge` 이상에서 ElastiCache를 실행하는 경우 고객은 노드별로 초당 1백만 개 이상의 요청을 처리할 수 있습니다. ElastiCache for Redis OSS v7.1의 성능 개선 사항을 통해 고객은 ElastiCache for Redis OSS v7.0에 비해 최대 100% 더 많은 처리량과 50% 더 낮은 P99 지연 시간을 달성할 수 있습니다. 이러한 개선 사항은 CPU 유형에 관계없이 물리적 코어가 8개 이상인 노드 크기(Graviton 기반 `2xlarge`, x86 기반 `4xlarge`)에서 사용할 수 있으며 클라이언트를 변경할 필요가 없습니다.
**참고**
ElastiCache v7.1은 Redis OSS v7.0과 호환됩니다.
### ElastiCache for Redis OSS 버전 7.0(향상된 버전)
ElastiCache for Redis OSS 7.0에는 여러 가지 개선 사항과 새로운 기능 지원이 추가되었습니다.
+ [함수](https://valkey.io/topics/functions-intro/): ElastiCache for Redis OSS 7에 Redis OSS 함수 지원이 추가되었고, 연결할 때마다 클라이언트가 스크립트를 서버로 다시 전송할 필요 없이 개발자가 ElastiCache 클러스터에 저장된 애플리케이션 로직으로 [LUA 스크립트](https://valkey.io/topics/eval-intro/)를 실행할 수 있는 관리형 경험을 제공합니다.
+ [ACL 개선](https://valkey.io/topics/acl/): Valkey 및 Redis OSS 7은 다음 버전의 ACL(액세스 제어 목록)에 대한 지원을 추가합니다. 이제 클라이언트가 Valkey 및 Redis OSS 내 특정 키 또는 키스페이스에 다수의 권한 집합을 지정할 수 있습니다.
+ [샤딩된 Pub/Sub](https://valkey.io/topics/pubsub/): ElastiCache for Valkey 및 Redis OSS 7은 클러스터 모드 활성화(CME) 상태에서 ElastiCache를 실행할 때 샤딩된 방식으로 Pub/Sub 기능을 실행할 수 있도록 지원됩니다. 게시자는 Pub/Sub 기능으로 원하는 수의 채널 구독자에게 메시지를 발행할 수 있습니다. 채널이 ElastiCache 클러스터 내 샤드에 바인딩되므로 샤드 간에 채널 정보를 전파할 필요가 없어 확장성이 향상됩니다.
+ 향상된 I/O 멀티플렉싱: ElastiCache for Valkey 및 Redis OSS 7에는 향상된 I/O 멀티플렉싱이 도입되어 ElastiCache 클러스터에 대한 동시 클라이언트 연결이 여럿이고 처리량이 많은 워크로드에 대해 처리량을 늘리고 지연 시간을 줄입니다. 예를 들어, r6g.xlarge 노드로 구성된 클러스터를 사용하고 5,200개의 동시 클라이언트를 실행하는 경우 ElastiCache for Redis OSS 버전 6에 비해 처리량(초당 읽기 및 쓰기 작업)을 최대 72% 늘리고 P99 지연 시간을 최대 71% 줄일 수 있습니다.
Valkey에 대한 자세한 내용은 [Valkey](https://valkey.io/)를 참조하세요. Redis OSS 7.0 릴리스에 대한 자세한 내용은 GitHub의 Redis OSS에서 [Redis OSS 7.0 릴리스 정보](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Redis OSS 버전 6.2(향상된 버전)
ElastiCache for Redis OSS 6.2에는 vCPU가 8개 이상인 x86 노드 유형 또는 vCPU가 4개 이상인 Graviton2 노드 유형을 사용하는 TLS 지원 클러스터의 성능 향상 기능이 포함되어 있습니다. 이러한 향상된 기능은 암호화를 다른 vCPU로 오프로드하여 처리량을 향상하고 클라이언트 연결 설정 시간을 단축합니다. Redis OSS 6.2를 사용하면 액세스 제어 목록(ACL) 규칙을 사용하여 Pub/Sub 채널에 대한 액세스를 관리할 수도 있습니다.
이 버전에서는 로컬로 연결된 NVMe SSD를 포함하는 클러스터 노드의 데이터 계층화에 대한 지원도 제공됩니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 단원을 참조하십시오.
Redis OSS 엔진 버전 6.2.6에는 기본 JSON(JavaScript Object Notation) 형식에 대한 지원이 포함됩니다. 이 형식은 Redis OSS 클러스터 내에서 복잡한 데이터세트를 인코딩하는 간단한 스키마리스 방법입니다. JSON 지원으로 JSON을 통해 작동하는 애플리케이션의 성능 및 Redis OSS API를 활용할 수 있습니다. 자세한 정보는 [JSON 시작하기](json-gs.md)를 참조하세요. 이 데이터 유형의 사용을 모니터링하기 위해 CloudWatch에 통합되는 JSON 관련 지표 `JsonBasedCmds` 및 `JsonBasedCmdsLatency`도 포함됩니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md) 단원을 참조하십시오.
6.2를 사용하여 엔진 버전을 지정합니다. ElastiCache는 사용 가능한 Redis OSS 6.2의 기본 패치 버전을 자동으로 간접 호출합니다. 예를 들어 클러스터를 생성/수정하는 경우 `--engine-version` 파라미터를 6.2로 설정합니다. 클러스터는 생성/수정 시 Redis OSS 6.2의 현재 사용 가능한 기본 패치 버전으로 시작됩니다. API에서 엔진 버전 6.x를 지정하면 Redis OSS 6의 최신 마이너 버전이 생성됩니다.
기존 6.0 클러스터의 경우 `AutoMinorVersionUpgrade` 파라미터를 `CreateCacheCluster`, `ModifyCacheCluster`, `CreateReplicationGroup` 또는 `ModifyReplicationGroup` API에서 `yes`로 설정하여 다음의 자동 마이너 버전 업그레이드를 선택할 수 있습니다. ElastiCache는 셀프 서비스 업데이트를 사용하여 기존 6.0 클러스터의 마이너 버전을 6.2로 업그레이드합니다. 자세한 내용은 [Amazon ElastiCache의 셀프 서비스 업데이트](Self-Service-Updates.md)를 참조하세요.
DescribeCacheEngineVersions API를 호출할 때 `EngineVersion` 파라미터 값이 6.2로 설정되고 패치 버전이 있는 실제 엔진 버전은 `CacheEngineVersionDescription` 필드에서 반환됩니다.
Redis OSS 6.2 릴리스에 대한 자세한 내용은 GitHub의 Redis OSS에서 [Redis OSS 6.2 릴리스 정보](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Redis OSS 버전 6.0(향상된 버전)
Amazon ElastiCache for Redis는 차기 버전의 ElastiCache for Redis OSS 엔진을 새로 제공합니다. 이 버전에는 [역할 기반 액세스 제어를 사용한 사용자 인증](Clusters.RBAC.md), 클라이언트 측 캐싱 및 상당한 작동 성능이 향상이 포함되어 있습니다.
Redis OSS 6.0부터 ElastiCache는 여러 개의 패치 버전을 제공하는 대신 각 Redis OSS 마이너 릴리스의 단일 버전을 제공합니다. ElastiCache는 실행 중인 클러스터의 패치 버전을 자동으로 관리하여 개선된 성능과 향상된 보안을 보장합니다.
`AutoMinorVersionUpgrade` 파라미터를 `yes`로 설정하여 다음의 자동 마이너 버전 업그레이드를 선택하면 ElastiCache는 셀프 서비스 업데이트를 통해 마이너 버전 업그레이드를 관리합니다. 자세한 내용은 [ElastiCache의 서비스 업데이트](Self-Service-Updates.md) 단원을 참조하십시오.
`6.0`를 사용하여 엔진 버전을 지정합니다. ElastiCache는 사용 가능한 Redis OSS 6.0의 기본 패치 버전을 자동으로 간접 호출합니다. 예를 들어 클러스터를 생성/수정하는 경우 `--engine-version` 파라미터를 6.0으로 설정합니다. 클러스터는 생성/수정 시 Redis OSS 6.0의 현재 사용 가능한 기본 패치 버전으로 시작됩니다. 특정 패치 버전 값을 사용한 모든 요청이 거부되고 예외가 발생한 후 프로세스가 실패합니다.
DescribeCacheEngineVersions API를 호출하는 경우 `EngineVersion` 파라미터 값이 6.0으로 설정되고 패치 버전이 있는 실제 엔진 버전은 `CacheEngineVersionDescription` 필드에서 반환됩니다.
Redis OSS 6.0 릴리스에 대한 자세한 내용은 GitHub의 Redis OSS에서 [Redis OSS 6.0 릴리스 정보](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Redis OSS 버전 5.0.6(향상된 버전)
Amazon ElastiCache는 차기 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. 여기에는 버그 수정과 다음의 누적된 업데이트가 포함됩니다.
+ 특별한 조건에서 엔진 안정성 보장.
+ 향상된 Hyperloglog 오류 처리.
+ 안정적인 복제를 위한 향상된 핸드셰이크 명령
+ `XCLAIM` 명령을 통한 일관된 메시지 배달 추적.
+ 객체에서의 향상된 `LFU ` 필드 관리.
+ `ZPOP` 사용 시 향상된 트랜잭션 관리.
+ 명령 이름 변경 기능: 위험할 수 있거나 비용이 높은 Redis OSS 명령(`FLUSHALL` 또는 `FLUSHDB` 등과 같이 데이터 손실 사고를 유발할 수 있는 명령)의 이름을 변경할 수 있는 `rename-commands`라는 파라미터가 새로 포함되었습니다. 이것은 오픈 소스 Redis OSS의 rename-command 구성과 비슷합니다. 하지만 ElastiCache는 완전 관리형 워크플로를 제공함으로써 보다 향상된 경험을 제공합니다. 명령 이름 변경은 즉시 적용되며, 명령 목록을 포함하는 클러스터의 모든 노드에 자동으로 전파됩니다. 사용자의 개입(노드 재부팅 등)은 필요 없습니다.
다음 예제에서는 기존 파라미터 그룹을 수정하는 방법을 보여줍니다. 이러한 예제에는 이름을 변경하려는 명령 목록(공백으로 구분)인 `rename-commands` 파라미터가 포함됩니다.
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region
```
이 예제에서는 *rename-commands* 파라미터를 사용하여 `flushall` 명령을 `restrictedflushall`로 이름 변경합니다.
여러 명령의 이름을 변경하려면 다음을 사용하세요.
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall flushdb restrictedflushdb''" --region region
```
변경을 되돌리려면 다음과 같이 명령을 다시 실행하고, 유지하려는 `ParameterValue` 목록에서 이름 변경된 값을 제외시킵니다.
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region
```
이 경우, `flushall` 명령은 `restrictedflushall`로 이름이 변경되고 이름 변경된 다른 명령은 원래 명령 이름으로 되돌려집니다.
**참고**
명령 이름 변경 시 다음과 같은 제한이 따릅니다.
이름 변경된 모든 명령은 영숫자여야 합니다.
새 명령 이름의 최대 길이는 20자(영숫자)입니다.
명령 이름을 변경할 경우 해당 클러스터와 연결된 파라미터 그룹을 업데이트해야 합니다.
명령 사용을 전체적으로 차단하려면 다음과 같이 `blocked` 키워드를 사용합니다.
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall blocked'" --region region
```
파라미터 변경에 대한 정보와 이름을 변경할 수 있는 명령 목록을 보려면 [Redis OSS 5.0.3 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3) 섹션을 참조하세요.
+ Redis OSS 스트림: 이 모델에서는 생산자가 실시간으로 새 항목을 추가할 수 있는 로그 데이터 구조를 모델링합니다. 또한 소비자가 차단 또는 차단하지 않는 방식으로 메시지를 소비할 수 있습니다. 또한 스트림을 사용하여 클라이언트 그룹을 대표하는 소비자 그룹이 [Apache Kafka](https://kafka.apache.org/documentation/)와 비슷한 메시지 스트림의 서로 다른 부분을 공동으로 사용할 수 있습니다. 자세한 내용은 [Streams](https://valkey.io/topics/streams-intro)를 참조하세요.
+ `XADD`, `XRANGE` 및 `XREAD`와 같은 스트림 명령군 지원. 자세한 내용은 [Streams Commands](https://valkey.io/commands/#stream)를 참조하세요.
+ 새 파라미터 및 이름이 변경된 파라미터의 수. 자세한 내용은 [Redis OSS 5.0.0 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0) 단원을 참조하십시오.
+ 새로운 Redis OSS 지표인 `StreamBasedCmds`.
+ Redis OSS 노드의 스냅샷 시간 단축.
**중요**
ElastiCache는 [Redis OSS 오픈 소스 버전 5.0.1](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)의 두 가지 중요한 버그 수정을 백포팅했습니다. 해당되는 사항은 다음과 같습니다.
특정 키가 이미 만료되면 RESTORE 불일치가 회신됩니다.
`XCLAIM` 명령은 잠재적으로 잘못된 항목을 반환하거나 프로토콜을 동기화 해제할 수 있습니다.
이 두 가지 버그 수정은 Redis OSS 엔진 버전 5.0.0의 ElastiCache for Redis OSS 지원에 포함되어 있으며 향후 버전 업데이트에서 사용됩니다.
자세한 내용은 GitHub의 Redis OSS에서 [Redis OSS 5.0.6 릴리스 정보](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Redis OSS 버전 5.0.5(사용 중단, 버전 5.0.6 사용)
Amazon ElastiCache는 차기 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. 이 버전에는 모든 계획된 작업 중에 자동 장애 조치 클러스터의 ElastiCache에 대한 온라인 구성 변경 사항이 포함되어 있습니다. 이제 클러스터가 온라인 상태에서 들어오는 요청을 계속 처리하는 동안 클러스터의 규모를 조정하고, Redis OSS 엔진 버전을 업그레이드하고, 패치 및 유지 관리 업데이트를 적용할 수 있습니다. 여기에는 버그 수정도 포함되어 있습니다.
자세한 내용은 GitHub의 Redis OSS에서 [Redis OSS 5.0.5 릴리스 정보](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Redis OSS 버전 5.0.4(사용 중단, 버전 5.0.6 사용)
Amazon ElastiCache는 ElastiCache가 지원하는 다음 버전의 Redis OSS 엔진을 새로 제공합니다. 다음과 같은 향상된 기능을 포함합니다.
+ 특별한 조건에서 엔진 안정성 보장.
+ 향상된 Hyperloglog 오류 처리.
+ 안정적인 복제를 위한 향상된 핸드셰이크 명령
+ `XCLAIM` 명령을 통한 일관된 메시지 배달 추적.
+ 객체에서의 향상된 `LFU ` 필드 관리.
+ `ZPOP` 사용 시 향상된 트랜잭션 관리.
자세한 내용은 GitHub의 Redis OSS에서 [Redis OSS 5.0.4 릴리스 정보](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)를 참조하세요.
### ElastiCache for Redis OSS 버전 5.0.3(사용 중단, 버전 5.0.6 사용)
Amazon ElastiCache는 차기 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. 여기에는 버그 수정이 포함됩니다.
### ElastiCache for Redis OSS 버전 5.0.0(사용 중단, 버전 5.0.6 사용)
Amazon ElastiCache는 차기 메이저 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. ElastiCache for Redis OSS 버전 5.0.0은 다음 개선 사항을 지원합니다.
+ Redis OSS 스트림: 이 모델에서는 생산자가 실시간으로 새 항목을 추가할 수 있는 로그 데이터 구조를 모델링합니다. 또한 소비자가 차단 또는 차단하지 않는 방식으로 메시지를 소비할 수 있습니다. 또한 스트림을 사용하여 클라이언트 그룹을 대표하는 소비자 그룹이 [Apache Kafka](https://kafka.apache.org/documentation/)와 비슷한 메시지 스트림의 서로 다른 부분을 공동으로 사용할 수 있습니다. 자세한 내용은 [Streams](https://valkey.io/topics/streams-intro)를 참조하세요.
+ `XADD`, `XRANGE` 및 `XREAD`와 같은 스트림 명령군 지원. 자세한 내용은 [Streams Commands](https://valkey.io/commands/#stream)를 참조하세요.
+ 새 파라미터 및 이름이 변경된 파라미터의 수. 자세한 내용은 [Redis OSS 5.0.0 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0) 단원을 참조하십시오.
+ 새로운 Redis OSS 지표인 `StreamBasedCmds`.
+ Redis OSS 노드의 스냅샷 시간 단축.
### ElastiCache for Redis OSS 버전 4.0.10(향상된 버전)
Amazon ElastiCache는 차기 메이저 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. ElastiCache for Redis OSS 버전 4.0.10은 다음 개선 사항을 지원합니다.
+ 단일 ElastiCache 버전에서 온라인 클러스터 크기 조정 및 암호화가 모두 지원됩니다. 자세한 내용은 다음을 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 온라인 리샤딩](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Amazon ElastiCache의 데이터 보안](encryption.md)
+ 새 파라미터의 수입니다. 자세한 내용은 [Redis OSS 4.0.10 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.4-0-10) 단원을 참조하십시오.
+ `MEMORY`와 같은 메모리 명령군 지원. 자세한 내용은 [Commands](https://valkey.io/commands)(MEMO에서 검색)를 참조하세요.
+ 온라인 상태에서 메모리 조각 모음을 지원하여 더욱 효율적인 메모리 사용률과 데이터에 대해 더 많이 사용 가능한 메모리가 허용됩니다.
+ 비동기 플러시 및 삭제를 지원합니다. ElastiCache for Redis OSS는 기본 스레드와 다른 스레드에서 실행할 수 있도록 `UNLINK`, `FLUSHDB` 및 `FLUSHALL` 같은 명령을 지원합니다. 이렇게 하면 비동기식으로 메모리를 확보하여 애플리케이션의 성능 및 응답 시간을 향상시킬 수 있습니다.
+ 새로운 Redis OSS 지표인 `ActiveDefragHits`. 자세한 정보는 [Redis OSS 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html) 섹션을 참조하세요.
ElastiCache for Redis OSS 버전 3.2.10을 실행하는 Redis OSS(클러스터 모드 비활성화됨) 사용자는 콘솔을 사용하여 온라인 업그레이드를 통해 클러스터를 업그레이드할 수 있습니다.
**ElastiCache 클러스터 크기 조정 및 암호화 지원 비교**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/engine-versions.html)
### 수명 종료(EOL) 지난 버전(3.x)
#### ElastiCache for Redis OSS 버전 3.2.10(향상된 버전)
Amazon ElastiCache는 차기 메이저 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. ElastiCache for Redis OSS 버전 3.2.10(향상된 버전)에서는 온라인 클러스터 크기 조정을 도입해 클러스터에서 샤드를 추가 또는 제거하고 동시에 수신되는 I/O 요청을 계속해서 처리합니다. ElastiCache for Redis OSS 3.2.10 사용자는 데이터를 암호화하는 옵션을 제외한 이전 Redis OSS 버전의 모든 기능을 사용할 수 있습니다. 이 기능은 현재 버전 3.2.6에서만 사용할 수 있습니다.
**ElastiCache for Redis OSS 버전 3.2.6 및 3.2.10 비교**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/engine-versions.html)
자세한 내용은 다음을 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 온라인 리샤딩](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [온라인 클러스터 크기 조정](best-practices-online-resharding.md)
#### ElastiCache for Redis OSS 버전 3.2.6(향상된 버전)
Amazon ElastiCache는 차기 메이저 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. ElastiCache for Redis OSS 3.2.6 사용자는 데이터를 암호화하는 옵션 이외에도 이전 Redis OSS 버전의 모든 기능에 액세스할 수 있습니다. 자세한 내용은 다음을 참조하세요.
+ [ElastiCache 전송 중 데이터 암호화(TLS)](in-transit-encryption.md)
+ [ElastiCache에서 저장 시 암호화](at-rest-encryption.md)
+ [Amazon ElastiCache의 규정 준수 확인](elasticache-compliance.md)
#### ElastiCache for Redis OSS 버전 3.2.4(향상된 버전)
Amazon ElastiCache 버전 3.2.4는 차기 메이저 버전의 ElastiCache for Redis OSS 엔진을 제공합니다. ElastiCache 3.2.4 사용자는 사용할 수 있는 이전 Redis OSS 버전의 모든 기능과 *클러스터 모드* 또는 *비클러스터 모드*에서 실행할 수 있는 옵션을 보유합니다. 다음 표에는 이에 대해 요약되어 있습니다.
**Redis OSS 3.2.4 비클러스터 모드와 클러스터 모드 비교**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/engine-versions.html)
**참고:**
+ **분할** - 각 노드 그룹에 대한 복제 지원을 통해 데이터를 2\$1500개의 노드 그룹(샤드)으로 분할할 수 있는 기능입니다.
+ **지역 검색 인덱싱** - Redis OSS 3.2.4에서는 GEO 명령 6개를 통한 지역 검색 인덱싱의 지원을 도입합니다. 자세한 내용은 Redis 명령 페이지의 Redis OSS GEO\$1 명령 설명서 [Commands: GEO](http://valkey.io/commands#geo)를 참조하세요(GEO에 대해 필터링됨).
추가 Redis OSS 3 기능에 대한 자세한 내용은 [Redis OSS 3.2 릴리스 정보](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES) 및 [Redis OSS 3.0 릴리스 정보](https://github.com/redis/redis/blob/3.0/00-RELEASENOTES)를 참조하세요.
현재 ElastiCache 관리형 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)는 다음 Redis OSS 3.2 기능을 지원하지 않습니다.
+ 복제본 마이그레이션
+ 클러스터 재분배
+ Lua 디버거
ElastiCache는 다음 Redis OSS 3.2 관리 명령을 비활성화합니다.
+ `cluster meet`
+ `cluster replicate`
+ `cluster flushslots`
+ `cluster addslots`
+ `cluster delslots`
+ `cluster setslot`
+ `cluster saveconfig`
+ `cluster forget`
+ `cluster failover`
+ `cluster bumpepoch`
+ `cluster set-config-epoch`
+ `cluster reset`
Redis OSS 3.2.4 파라미터에 대한 자세한 내용은 [Redis OSS 3.2.4 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.3-2-4) 섹션을 참조하세요.
### 수명 종료(EOL) 지난 버전(2.x)
#### ElastiCache for Redis OSS 버전 2.8.24(향상된 버전)
버전 2.8.23부터 추가된 Redis OSS 개선 사항에는 버그 수정 및 불량 메모리 액세스 주소의 로깅이 포함됩니다. 자세한 내용은 [Redis OSS 2.8 릴리스 정보](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)를 참조하세요.
#### ElastiCache for Redis OSS 버전 2.8.23(향상된 버전)
버전 2.8.22부터 추가된 Redis OSS 개선 사항에는 버그 수정이 포함됩니다. 자세한 내용은 [Redis OSS 2.8 릴리스 정보](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)를 참조하세요. 이 릴리스에는 새 파라미터 `close-on-slave-write`에 대한 지원도 포함됩니다. 이 파라미터가 활성화되면 읽기 전용 복제본에 쓰려고 시도하는 클라이언트를 연결 해제합니다.
Redis OSS 2.8.23 파라미터에 대한 자세한 내용은 ElastiCache 사용 설명서의 [Redis OSS 2.8.23(확장) 추가 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis.2-8-23) 섹션을 참조하세요.
#### ElastiCache for Redis OSS 버전 2.8.22(향상된 버전)
버전 2.8.21부터 추가된 Redis OSS 개선 사항에는 다음이 포함됩니다.
+ 백업 오버헤드에 대해 메모리를 적게 할당하고 애플리케이션에 많이 할당할 수 있는 forkless 백업 및 동기화에 대해 지원합니다. 자세한 내용은 [동기화 및 백업 구현 방법](Replication.Redis.Versions.md) 단원을 참조하십시오. forkless 프로세스는 지연 시간과 처리량 모두에 영향을 줄 수 있습니다. 높은 쓰기 처리량의 경우 복제본이 다시 동기화되면, 동기화되는 전체 시간에 대해 접속 불가능하게 될 수 있습니다.
+ 장애 조치가 발생한 경우, 가능하면 언제든지 복제본이 기본 항목과 전체 동기화가 아닌 부분적인 동기화를 수행하므로 이제 복제 그룹이 더 빠르게 복구됩니다. 또한, 기본 항목 및 복제본 모두 동기화 중 더 이상 디스크를 사용하지 않으므로 속도가 향상됩니다.
+ 두 가지 새로운 CloudWatch 지표 지원
+ `ReplicationBytes` - 읽기 전용 복제본으로 전송되는 복제 그룹 기본 클러스터의 바이트 수.
+ `SaveInProgress` - 백그라운드 저장 프로세스가 실행 중인지 여부를 나타내는 이진 값.
자세한 내용은 [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md) 단원을 참조하십시오.
+ 복제 PSYNC 동작에서 중요한 버그 수정의 수. 자세한 내용은 [Redis OSS 2.8 릴리스 정보](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)를 참조하세요.
+ 다중 AZ 복제 그룹에서 향상된 복제 성능을 유지하고 증가된 클러스터 안정성을 유지하기 위해 비 ElastiCache 복제본이 더 이상 지원되지 않습니다.
+ 복제 그룹에서 기본 클러스터와 복제본 간의 데이터 일관성을 향상하기 위해 복제본에서는 기본 클러스터와 별도로 더 이상 키를 제거하지 않습니다.
+ Redis OSS 구성 변수 `appendonly` 및 `appendfsync`는 Redis OSS 버전 2.8.22 이상에서 지원되지 않습니다.
+ 메모리가 부족한 상황에서 큰 출력 버퍼가 있는 클라이언트는 복제본 클러스터에서 연결이 해제될 수 있습니다. 연결이 해제되면 클라이언트가 다시 연결해야 합니다. 이러한 상황은 대부분 PUBSUB 클라이언트에 대해 발생합니다.
#### ElastiCache for Redis OSS 버전 2.8.21
버전 2.8.19부터 추가된 Redis OSS 개선 사항에는 여러 가지 버그 수정이 포함됩니다. 자세한 내용은 [Redis OSS 2.8 릴리스 정보](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)를 참조하세요.
#### ElastiCache for Redis OSS 버전 2.8.19
버전 2.8.6부터 추가된 Redis OSS 개선 사항에는 다음이 포함됩니다.
+ HyperLogLog에 대해 지원합니다. 자세한 내용은 [Redis OSS 새 데이터 구조: HyperLogLog](http://antirez.com/news/75)를 참조하세요.
+ 정렬된 세트 데이터 유형은 이제 `ZRANGEBYLEX`, `ZLEXCOUNT` 및 `ZREMRANGEBYLEX`의 새 명령을 통해 사전 순 범위 쿼리를 지원합니다.
+ 기본 노드에서 복제본 노드로 부실 데이터가 전송되는 것을 방지하기 위해 백그라운드 저장(`bgsave`) 하위 프로세스가 중단될 경우 마스터 SYNC가 실패합니다.
+ *HyperLogLogBasedCommands* CloudWatch 지표를 지원합니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md) 단원을 참조하십시오.
#### ElastiCache for Redis OSS 버전 2.8.6
버전 2.6.13부터 추가된 Redis OSS 개선 사항에는 다음이 포함됩니다.
+ 읽기 전용 복제본에 대한 복원성 및 내결함성이 개선되었습니다.
+ 부분적 재동기화를 지원합니다.
+ 항상 사용할 수 있어야 하는 읽기 전용 복제본의 사용자 정의 최소 숫자를 지원합니다.
+ 게시/구독에 대한 전체 지원 - 서버에서의 이벤트를 클라이언트에 알리는 기능입니다.
+ 기본 노드 장애의 자동 감지 및 기본 노드에서 보조 노드로 장애 조치
#### ElastiCache for Redis OSS 버전 2.6.13
ElastiCache for Redis OSS 버전 2.6.13은 ElastiCache가 지원하는 초기 Redis OSS 버전이었습니다. 다중 AZ는 ElastiCache for Redis OSS 버전 2.6.13에서 지원되지 않습니다.
## ElastiCache for Redis OSS 버전의 수명 종료 일정
이 섹션에서는 발표되는 이전 주요 버전의 수명 종료(EOL) 날짜를 결정합니다. 이를 통해 향후 버전 및 업그레이드 결정을 내릴 수 있습니다.
**참고**
5.0.0부터 5.0.5까지의 ElastiCache for Redis OSS 패치 버전은 더 이상 사용되지 않습니다. 버전 5.0.6 이상을 사용하세요.
다음 표에는 ElastiCache for Redis OSS 엔진에 대한 [추가 지원](extended-support.md) 일정이 나와 있습니다.
**추가 지원 및 수명 종료 일정**
| 메이저 엔진 버전 | 표준 지원 종료일 | 추가 지원 Y1 Premium 시작 | 추가 지원 Y2 Premium 시작 | 추가 지원 Y3 Premium 시작 | 추가 지원 종료 및 버전 수명 종료 |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 |
| Redis OSS v5 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 |
| Redis OSS v6 | 1/31/2027 | 2/1/2027 | 2/1/2028 | 2/1/2029 | 1/31/2030 |
다음 표에는 각 버전 및 발표된 EOL 날짜 그리고 권장 업그레이드 대상 버전이 요약되어 있습니다.
**EOL 지남**
| 원본 메이저 버전 | 원본 마이너 버전 | 권장 업그레이드 대상 | EOL 날짜 |
| --- | --- | --- | --- |
| 버전 3 | 3.2.4, 3.2.6 및 3.2.10 | 버전 6.2 이상 US-ISO-EAST-1, US-ISO-WEST-1 및 US-ISOB-EAST-1 리전의 경우 5.0.6 이상을 사용하는 것이 좋습니다. | 2023년 7월 31일 |
| 버전 2 | 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19, 2.8.12, 2.8.6, 2.6.13 | 버전 6.2 이상 US-ISO-EAST-1, US-ISO-WEST-1 및 US-ISOB-EAST-1 리전의 경우 5.0.6 이상을 사용하는 것이 좋습니다. | 2023년 1월 13일 |
## 지원되는 ElastiCache for Memcached 버전
ElastiCache는 다음 Memcached 버전과 새 버전으로의 업그레이드를 지원합니다. 새 버전으로 업그레이드할 때 충족되지 않을 경우 업그레이드가 실패하는 조건에 주의를 기울이십시오.
**Topics**
+ [ElastiCache for Memcached 버전 1.6.22](#memcached-version-1-6-22)
+ [ElastiCache for Memcached 버전 1.6.17](#memcached-version-1-6-17)
+ [ElastiCache for Memcached 버전 1.6.12](#memcached-version-1-6-12)
+ [ElastiCache for Memcached 버전 1.6.6](#memcached-version-1-6-6)
+ [ElastiCache for Memcached 버전 1.5.16](#memcached-version-1-5-16)
+ [ElastiCache for Memcached 버전 1.5.10](#memcached-version-1-5-10)
+ [ElastiCache for Memcached 버전 1.4.34](#memcached-version-1-4-34)
+ [ElastiCache for Memcached 버전 1.4.33](#memcached-version-1-4-33)
+ [ElastiCache for Memcached 버전 1.4.24](#memcached-version-1-4-24)
+ [ElastiCache for Memcached 버전 1.4.14](#memcached-version-1-4-14)
+ [ElastiCache for Memcached 버전 1.4.5](#memcached-version-1-4-5)
### ElastiCache for Memcached 버전 1.6.22
ElastiCache for Memcached 버전 1.6.22에 Memcached 엔진 버전 1.6.22에 대한 지원이 추가되었습니다. 새로운 기능은 없지만 [Memcached 1.6.18](https://github.com/memcached/memcached/wiki/ReleaseNotes1618)의 버그 수정 및 누적 업데이트가 포함되어 있습니다.
자세한 내용은 GitHub의 Memcached에서 [ReleaseNotes1622](https://github.com/memcached/memcached/wiki/ReleaseNotes1622)을 참조하세요.
### ElastiCache for Memcached 버전 1.6.17
ElastiCache for Memcached 버전 1.6.17에 Memcached 엔진 버전 1.6.17에 대한 지원이 추가되었습니다. 새로운 기능은 없지만 [Memcached 1.6.17](https://github.com/memcached/memcached/wiki/ReleaseNotes1617)의 버그 수정 및 누적 업데이트가 포함되어 있습니다.
자세한 내용은 GitHub의 Memcached에서 [ReleaseNotes1617](https://github.com/memcached/memcached/wiki/ReleaseNotes1617)을 참조하세요.
### ElastiCache for Memcached 버전 1.6.12
ElastiCache for Memcached 버전 1.6.12에 Memcached 엔진 1.6.12 및 전송 중 암호화 지원이 추가되었습니다. [Memcached 1.6.6](https://github.com/memcached/memcached/wiki/ReleaseNotes166)부터의 버그 해결 및 누적 업데이트도 포함되었습니다.
자세한 내용은 GitHub의 Memcached에서 [ReleaseNotes1612](https://github.com/memcached/memcached/wiki/ReleaseNotes1612)를 참조하세요.
### ElastiCache for Memcached 버전 1.6.6
ElastiCache for Memcached 버전 1.6.6에 Memcached 엔진 버전 1.6.6에 대한 지원이 추가되었습니다. 새로운 기능은 없지만 [Memcached 1.5.16](https://github.com/memcached/memcached/wiki/ReleaseNotes1.5.16)의 버그 수정 및 누적 업데이트가 포함되어 있습니다. ElastiCache for Memcached에는 [Extstore](https://memcached.org/extstore)에 대한 지원이 포함되어 있지 않습니다.
자세한 내용은 GitHub의 Memcached에서 [ReleaseNotes166](https://github.com/memcached/memcached/wiki/ReleaseNotes166)을 참조하세요.
### ElastiCache for Memcached 버전 1.5.16
ElastiCache for Memcached 버전 1.5.16에 Memcached 버전 1.5.16에 대한 지원이 추가되었습니다. 새로운 기능은 없지만 [Memcached 1.5.14](https://github.com/memcached/memcached/wiki/ReleaseNotes1514) 및 [Memcached 1.5.15](https://github.com/memcached/memcached/wiki/ReleaseNotes1515)의 버그 수정 및 누적 업데이트가 포함되어 있습니다.
자세한 내용은 GitHub의 Memcached에서 [Memcached 1.5.16 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1516)를 참조하세요.
### ElastiCache for Memcached 버전 1.5.10
ElastiCache for Memcached 버전 1.5.10은 다음 Memcached 기능을 지원합니다.
+ 자동화된 슬래브 재분배 기능.
+ `murmur3` 알고리즘으로 더 빠른 해시 테이블 조회.
+ 세분화된 LRU 알고리즘.
+ background-reclaim 메모리에 대한 LRU 크롤러.
+ `--enable-seccomp`: 컴파일 시간 옵션.
또한 `no_modern` 및 `inline_ascii_resp` 파라미터를 도입합니다. 자세한 내용은 [Memcached 1.5.10 파라미터 변경](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10) 단원을 참조하십시오.
ElastiCache for Memcached 버전 1.4.34부터 추가된 Memcached 개선 사항에는 다음이 포함됩니다.
+ ASCII multigets, CVE-2017-9951 및 `metadumper`에 대한 크롤링 한도와 같은 누적 방식 수정.
+ 연결 한도에서 연결을 닫는 방식으로 연결 관리 향상.
+ 1MB 이상의 항목 크기에 대한 항목 크기 관리 개선.
+ 항목당 메모리 요구 사항을 몇 바이트 줄임으로써 성능 및 메모리 오버헤드 개선.
자세한 내용은 GitHub의 Memcached에서 [Memcached 1.5.10 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1510)를 참조하세요.
### ElastiCache for Memcached 버전 1.4.34
ElastiCache for Memcached 버전 1.4.34는 버전 1.4.33에 대해 새 기능이 추가되지 않았습니다. 버전 1.4.34는 일반적인 릴리스보다 큰 버그 수정 릴리스입니다.
자세한 내용은 GitHub의 Memcached에서 [Memcached 1.4.34 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1434)를 참조하세요.
### ElastiCache for Memcached 버전 1.4.33
버전 1.4.24부터 추가된 개선 사항에는 다음이 포함됩니다.
+ 특정 슬래브 클래스, 슬래브 클래스 목록 또는 모든 슬래브 클래스에 대한 모든 메타데이터를 덤프할 수 있습니다. 자세한 내용은 [Memcached 1.4.31 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1431)를 참조하세요.
+ 1메가바이트 기본값보다 큰 항목에 대한 지원이 개선되었습니다. 자세한 내용은 [Memcached 1.4.29 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1429)를 참조하세요.
+ 종료하라는 메시지가 표시되기 전에 클라이언트가 유휴 상태로 있을 수 있는 기간을 지정할 수 있습니다.
클러스터를 다시 시작하지 않고 Memcached에 사용할 수 있는 메모리의 양을 동적으로 늘릴 수 있습니다. 자세한 내용은 [Memcached 1.4.27 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1427)를 참조하세요.
+ 이제 `fetchers`, `mutations` 및 `evictions`의 로깅이 지원됩니다. 자세한 내용은 [Memcached 1.4.26 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1426)를 참조하세요.
+ 빈 메모리를 전역 풀로 다시 회수하여 새 슬래브 클래스로 재할당할 수 있습니다. 자세한 내용은 [Memcached 1.4.25 릴리스 정보](https://github.com/memcached/memcached/wiki/ReleaseNotes1425)를 참조하세요.
+ 여러 가지 버그 수정.
+ 일부 새 명령 및 파라미터. 목록을 보려면 [Memcached 1.4.33 추가 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-33) 섹션을 참조하세요.
### ElastiCache for Memcached 버전 1.4.24
버전 1.4.14부터 추가된 개선 사항에는 다음이 포함됩니다.
+ 백그라운드 프로세스를 통한 LRU(가장 오랫동안 사용되지 않음) 관리.
+ 해시 알고리즘으로 *jenkins* 또는 *murmur3*의 옵션이 추가되었습니다.
+ 일부 새 명령 및 파라미터. 목록을 보려면 [Memcached 1.4.24 추가 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24) 섹션을 참조하세요.
+ 여러 가지 버그 수정.
### ElastiCache for Memcached 버전 1.4.14
버전 1.4.5부터 추가된 개선 사항에는 다음이 포함됩니다.
+ 슬래브 재분배 기능이 개선되었습니다.
+ 성능 및 확장성 개선.
+ 기존 항목을 가져오지 않고 해당 항목의 만료 시간을 업데이트하기 위해 *터치* 명령이 도입되었습니다.
+ 자동 검색 - 클라이언트 프로그램이 클러스터의 모든 캐시 노드를 자동으로 확인하고 이러한 모든 노드에 대한 연결을 시작하고 유지 관리할 수 있는 기능입니다.
### ElastiCache for Memcached 버전 1.4.5
ElastiCache for Memcached 버전 1.4.5는 Amazon ElastiCache for Memcached가 지원하는 초기 엔진 및 버전이었습니다.
# 메이저 엔진 버전 동작 및 Valkey와의 호환성 차이
Valkey 7.2.6에는 Redis OSS 7.2.4 이전 버전과 유사한 호환성 차이가 있습니다. 지원되는 최신 버전의 Valkey는 [지원되는 엔진 및 버전](VersionManagement.md#supported-engine-versions) 섹션을 참조하세요.
Valkey 7.2 릴리스에 대한 자세한 내용은 GitHub의 Valkey에서 [Redis OSS 7.2.4 릴리스 정보](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES)(Valkey 7.2에는 Redis OSS 버전 7.2.4까지의 모든 변경 사항이 포함됨) 및 [Valkey 7.2 릴리스 정보](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES)를 참조하세요.
다음은 Valkey 7.2와 Redis OSS 7.1(또는 7.0) 간의 잠재적 동작 변경 사항입니다.
+ 정지 시간 샘플링은 명령 실행 중 및 스크립트에서 발생합니다.
+ 키가 더 이상 존재하지 않을 때 해제되는 차단된 스트림 명령은 다른 오류 코드(-unBLOCKED 대신 -NOGROUP 또는 -WRONGTYPE)를 전달합니다.
+ 스크립트에 대한 클라이언트 측 추적은 이제 EVAL/FCALL 호출자가 선언한 키 대신 스크립트가 읽는 키를 추적합니다.
# 메이저 엔진 버전 동작 및 Redis OSS와의 호환성 차이
**중요**
다음 페이지에서는 버전 간의 호환되지 않는 차이점을 모두 보여주며 최신 버전으로 업그레이드할 때 고려해야 할 사항을 알려줍니다. 이 목록에는 업그레이드 시 발생할 수 있는 모든 버전 비호환 문제가 포함되어 있습니다.
현재 Redis OSS 버전에서 순차적으로 업그레이드할 필요 없이 사용 가능한 최신 Redis OSS 버전으로 바로 업그레이드할 수 있습니다. 예를 들어, Redis OSS 버전 3.0에서 버전 7.0으로 바로 업그레이드 가능합니다.
Redis OSS 버전은 메이저, 마이너 및 패치 구성 요소를 구성하는 시맨틱 버전과 동일시됩니다. 예를 들어 Redis OSS 4.0.10에서 메이저 버전은 4, 마이너 버전은 0, 패치 버전은 10입니다. 이러한 값은 일반적으로 다음 규칙에 따라 증분됩니다.
+ 메이저 버전은 API 호환 변경용입니다.
+ 마이너 버전은 이전 버전과 호환되는 방식으로 추가된 새로운 기능용입니다.
+ 패치 버전은 이전 버전과 호환되는 버그 수정 및 비기능 변경용입니다.
최신 성능 및 안정성 개선을 위해 지정된 **메이저.마이너** 버전 내에서 항상 최신 패치 버전을 사용하는 것이 좋습니다. ElastiCache for Redis OSS 버전 6.0부터 여러 개의 패치 버전을 제공하는 대신 각 Redis OSS 마이너 릴리스의 단일 버전을 제공합니다. ElastiCache는 실행 중인 클러스터의 패치 버전을 자동으로 관리하여 개선된 성능과 향상된 보안을 보장합니다.
또한 대부분의 주요 개선 사항은 이전 버전으로 다시 포팅되지 않으므로 주기적으로 최신 메이저 버전으로 업그레이드하는 것이 좋습니다. ElastiCache가 새AWS리전으로 가용성을 확장함에 따라 ElastiCache for Redis OSS는 해당 시점에 새 리전에 대해 두 개의 최신 **major.minor** 버전을 지원합니다. 예를 들어 새AWS리전이 시작되고 Redis OSS에 대한 최신 major.minor ElastiCache 버전이 **7.0** 및 **6.2**인 경우 ElastiCache는 새AWS리전에서 Redis OSS 버전 **7.0** 및 **6.2**를 지원합니다. ElastiCache for Redis OSS의 최신 메이저.마이너 버전이 출시됨에 따라 ElastiCache는 새로 출시되는 버전에 대한 지원을 계속 추가할 예정입니다. ElastiCache 리전 선택에 대해 자세히 알아보려면 [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions)을 참조하세요.
메이저 또는 마이너 버전으로 업그레이드하는 경우 다음 목록을 고려하세요. 이 목록에는 시간이 지남에 따라 Redis OSS와 함께 릴리스된 동작 및 이전 버전과 호환되지 않는 변경 사항이 포함되어 있습니다.
## Redis OSS 7.0 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 7.0 릴리스 정보](https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES)를 참조하세요.
+ `SCRIPT LOAD` 및 `SCRIPT FLUSH`는 더 이상 복제본으로 전파되지 않습니다. 스크립트에 어느 정도 내구성이 필요한 경우, [Redis OSS 함수](https://valkey.io/topics/functions-intro/) 사용을 고려하는 것이 좋습니다.
+ 이제 Pubsub 채널은 기본적으로 새 ACL 사용자가 사용하지 못하게 차단됩니다.
+ `STRALGO` 명령이 `LCS` 명령으로 대체되었습니다.
+ `ACL GETUSER`의 형식이 변경되어 모든 필드에 표준 액세스 문자열 패턴이 표시됩니다. `ACL GETUSER`를 사용하여 자동화한 경우, 두 형식 중 하나가 처리되는지 검증해야 합니다.
+ `SELECT`, `WAIT`, `ROLE`, `LASTSAVE`, `READONLY`, `READWRITE`, `ASKING`의 ACL 범주가 변경되었습니다.
+ 이제 `INFO` 명령은 최상위 컨테이너 명령 대신 하위 명령별 명령 통계를 표시합니다.
+ 특정 엣지 상황에서 `LPOP`, `RPOP`, `ZPOPMIN`, `ZPOPMAX` 명령의 반환 값이 변경되었습니다. 이들 명령을 사용한다면, 릴리스 정보를 확인하고 영향이 있는지 평가해야 합니다.
+ 이제 `SORT` 및 `SORT_RO` 명령이 `GET` 및 `BY` 인수를 사용하려면 키스페이스 전체에 액세스할 수 있어야 합니다.
## Redis OSS 6.2 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 6.2 릴리스 정보](https://raw.githubusercontent.com/redis/redis/6.2/00-RELEASENOTES)를 참조하세요.
+ `TIME`, `ECHO`, `ROLE` 및 `LASTSAVE` 명령의 ACL 플래그가 변경되었습니다. 이로 인해 이전에 허용된 명령이 거부될 수 있으며 그 반대의 경우도 마찬가지입니다.
**참고**
이러한 명령 중 어느 것도 데이터를 수정하거나 액세스 권한을 부여하지 않습니다.
+ Redis OSS 6.0에서 업그레이드하면 맵 응답에서 lua 스크립트로 반환된 키/값 쌍의 순서가 변경됩니다. 스크립트에서 `redis.setresp()`를 사용하거나 맵을 반환하는 경우(Redis OSS 6.0의 새로운 기능) 업그레이드 시 스크립트가 중단될 수 있는 영향을 고려하세요.
## Redis OSS 6.0 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 6.0 릴리스 정보](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES)를 참조하세요.
+ 허용되는 최대 데이터베이스 수가 120만 개에서 1만 개로 감소했습니다. 기본값은 16입니다. 성능 및 메모리 문제가 발견되었으므로 이보다 훨씬 큰 값은 사용하지 않는 것이 좋습니다.
+ `AutoMinorVersionUpgrade` 파라미터를 예로 설정하면 ElastiCache가 셀프 서비스 업데이트를 통해 마이너 버전 업그레이드를 관리합니다. 이러한 관리는 셀프 서비스 업데이트 캠페인을 사용하는 표준 고객 알림 채널을 통해 처리됩니다. 자세한 정보는 [ElastiCache의 셀프 서비스 업데이트](Self-Service-Updates.md)를 참조하세요.
## Redis OSS 5.0 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 5.0 릴리스 정보](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES)를 참조하세요.
+ 스크립트는 복제본에서 스크립트를 다시 실행하지 않고 효과에 의해 복제됩니다. 이렇게 하면 일반적으로 성능이 향상되지만 기본 및 복제본 간에 복제된 데이터의 양이 증가할 수 있습니다. ElastiCache for Redis OSS 버전 5.0에서만 사용할 수 있는 이전 동작으로 되돌리는 옵션이 있습니다.
+ Redis OSS 4.0에서 업그레이드하는 경우 LUA 스크립트의 일부 명령은 이전 버전과 다른 순서로 인수를 반환합니다. Redis OSS 4.0에서 Redis OSS는 응답을 결정적으로 만들기 위해 일부 응답을 사전순으로 정렬합니다. 이 순서는 스크립트가 효과에 의해 복제될 때는 적용되지 않습니다.
+ Redis OSS 5.0.3부터 ElastiCache for Redis OSS는 VCPU가 4개 이상인 인스턴스 유형의 백그라운드 코어로 일부 IO 작업을 오프로드합니다. 이로 인해 Redis OSS의 성능 특성이 변경되고 일부 지표의 값이 변경될 수 있습니다. 자세한 정보는 [어떤 지표를 모니터링해야 합니까?](CacheMetrics.WhichShouldIMonitor.md) 섹션을 참조하여 지켜보는 지표를 변경해야 할 경우를 이해하세요.
## Redis OSS 4.0 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 4.0 릴리스 정보](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES)를 참조하세요.
+ 슬로우 로그는 이제 클라이언트 이름과 주소라는 두 개의 인수를 추가로 기록합니다. 이 변경 사항은 3개의 값을 포함하는 각 슬로우 로그 항목에 명시적으로 의존하지 않는 한 이전 버전과 호환되어야 합니다.
+ `CLUSTER NODES` 명령은 이제 약간 다른 형식을 반환하는데 이는 이전 버전과 호환되지 않습니다. 클라이언트는 클러스터에 있는 노드에 대해 알기 위해 이 명령을 사용하지 않는 것이 좋습니다. 대신 `CLUSTER SLOTS`를 사용해야 합니다.
## EOL 지남
### Redis OSS 3.2 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 3.2 릴리스 정보](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES)를 참조하세요.
+ 이 버전에 대해 호출할 호환성 변경 사항은 없습니다.
자세한 내용은 [ElastiCache for Redis OSS 버전의 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 단원을 참조하십시오.
### Redis OSS 2.8 동작 및 이전 버전과 호환되지 않는 변경 사항
전체 변경 사항 목록은 [Redis OSS 2.8 릴리스 정보](https://raw.githubusercontent.com/redis/redis/2.8/00-RELEASENOTES)를 참조하세요.
+ Redis OSS 2.8.22부터 Redis OSS AOF는 ElastiCache for Redis OSS에서 더 이상 지원되지 않습니다. 데이터를 안정적으로 유지해야 하는 경우 MemoryDB를 사용하는 것이 좋습니다.
+ Redis OSS 2.8.22부터 ElastiCache for Redis OSS는 더 이상 ElastiCache 내에서 호스팅되는 기본에 복제본을 연결하는 것을 지원하지 않습니다. 업그레이드하는 동안 외부 복제본의 연결이 끊어지고 다시 연결할 수 없게 됩니다. 외부 복제본의 대안으로 Redis OSS 6.0에서 사용 가능한 클라이언트 측 캐싱을 사용하는 것이 좋습니다.
+ `TTL` 및 `PTTL` 명령은 이제 키가 있지 않은 경우 -2를 반환하고, 키는 있지만 관련 만료 기간이 없으면 -1을 반환합니다. Redis OSS 2.6 및 이전 버전은 두 조건 모두에 대해 -1을 반환하는 데 사용되었습니다.
+ `ALPHA`를 사용하는 `SORT`는 이제 `STORE` 옵션이 사용되지 않는 경우 로컬 데이터 정렬 로캘에 따라 정렬합니다.
자세한 내용은 [ElastiCache for Redis OSS 버전의 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 단원을 참조하십시오.
# 노드 기반 클러스터를 사용할 때의 업그레이드 고려 사항
**참고**
다음 고려 사항은 노드 기반 클러스터를 업그레이드할 때만 적용됩니다. 이 내용은 ElastiCache 서버리스에는 적용되지 않습니다.
**Valkey 및 Redis OSS 고려 사항**
노드 기반 Valkey 또는 Redis OSS 클러스터를 업그레이드할 때는 다음을 고려하세요.
+ 엔진 버전 관리는 패치 발생 방법을 최대한 제어할 수 있도록 설계되었습니다. 그러나 ElastiCache는 시스템 또는 캐시 소프트웨어에 심각한 보안 취약성이 발견되는 등 발생할 가능성이 거의 없는 이벤트의 경우 사용자를 대신하여 클러스터에 패치를 적용할 수 있는 권한을 보유합니다.
+ ElastiCache for Valkey 버전 7.2 및 ElastiCache for Redis OSS 6.0부터 ElastiCache는 여러 개의 패치 버전을 제공하는 대신 각 마이너 릴리스의 단일 버전을 제공합니다.
+ Redis OSS 엔진 버전 5.0.6부터는 가동 중지 시간을 최소화하면서 클러스터 버전을 업그레이드할 수 있습니다. 전체 업그레이드 과정 중에도 클러스터를 읽을 수 있으며, 몇 초 정도 시간이 걸리는 장애 조치 작업 중인 경우를 제외하면 대부분 업그레이드 기간 중에 쓰기도 가능합니다.
+ 5.0.6 이전 버전으로 ElastiCache 클러스터를 업그레이드할 수도 있습니다. 관련된 프로세스는 동일하지만 DNS 전파 중에 장애 조치 시간이 더 길어질 수 있습니다(30s-1m).
+ Redis OSS 7부터 ElastiCache는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)와 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 간의 전환을 지원합니다.
+ Amazon ElastiCache for Redis OSS 엔진 업그레이드 프로세스는 기존 데이터를 최대한 유지할 수 있도록 진행되며, 성공적인 Redis OSS 복제가 필요합니다.
+ 엔진을 업그레이드할 때 ElastiCache는 기존 클라이언트 연결을 종료합니다. 엔진 업그레이드 중 가동 중지 시간을 최소화하려면 오류 재시도 및 지수 백오프를 사용하는 [Redis OSS 클라이언트의 모범 사례](BestPractices.Clients.redis.md)와 [유지 관리 중 가동 중지 시간 최소화](BestPractices.MinimizeDowntime.md)를 위한 모범 사례를 구현하는 것이 좋습니다.
+ 엔진을 업그레이드할 때 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에서 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)로 직접 업그레이드할 수 없습니다. 다음 절차에서는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에서 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)로 업그레이드하는 방법을 보여줍니다.
**Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에서 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)로 엔진 버전을 업그레이드하려면**
1. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 또는 복제 그룹에 대한 백업을 만듭니다. 자세한 내용은 [수동 백업 지원](backups-manual.md) 단원을 참조하십시오.
1. 백업을 사용하여 샤드가 하나인 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(노드 그룹)를 만들고 시드합니다. 클러스터 또는 복제 그룹을 생성할 때 새 엔진 버전을 지정하고 클러스터 모드를 활성화합니다. 자세한 내용은 [자습서: 외부에서 생성된 백업으로 새로운 노드 기반 클러스터 시드](backups-seeding-redis.md) 단원을 참조하십시오.
1. 이전 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 또는 복제 그룹을 삭제합니다. 자세한 내용은 [ElastiCache에서 클러스터 삭제](Clusters.Delete.md) 또는 [복제 그룹 삭제](Replication.DeletingRepGroup.md)을 참조하세요.
1. 새 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 또는 복제 그룹을 필요한 샤드(노드 그룹) 수까지 확장합니다. 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) 섹션을 참조하세요.
+ 메이저 엔진 버전을 업그레이드하는 경우(예: 5.0.6에서 6.0으로 업그레이드) 새 엔진 버전과 호환되는 새 파라미터 그룹도 선택해야 합니다.
+ 단일 Redis OSS 클러스터 및 다중 AZ가 비활성화된 클러스터의 경우 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)에 명시된 대로 Redis OSS에 충분한 메모리를 사용할 수 있도록 하는 것이 좋습니다. 이러한 경우 업그레이드 프로세스 중에는 서비스 요청에 기본 항목을 사용할 수 없습니다.
+ 다중 AZ가 활성화된 Redis OSS 클러스터의 경우, 수신 쓰기 트래픽이 낮은 기간 동안 엔진 업그레이드를 예약하는 것이 좋습니다. Redis OSS 5.0.6 이상으로 업그레이드하면 업그레이드 프로세스 동안 기본 클러스터를 서비스 요청에 계속 사용할 수 있습니다.
샤드가 여러 개인 클러스터 및 복제 그룹은 다음과 같이 처리되고 패치가 적용됩니다.
+ 모든 샤드는 병렬로 처리됩니다. 언제든지 하나의 샤드에서 오직 하나의 업그레이드 작업이 수행됩니다.
+ 각 샤드에서 기본 복제본이 처리되기 전에 모든 복제본이 처리됩니다. 하나의 샤드에 복제본이 적게 있는 경우에는 다른 샤드의 복제본의 처리가 완료되기 전에 해당 샤드의 기본 복제본이 처리됩니다.
+ 모든 샤드에서 프라이머리 노드가 연속하여 처리됩니다. 한번에 오직 하나의 프라이머리 노드가 업그레이드됩니다.
+ 현재 클러스터 또는 복제 그룹에서 암호화가 활성화되어 있는 경우에는 암호화를 지원하지 않는 엔진 버전으로 업그레이드할 수 없습니다(예를 들면 3.2.6에서 3.2.10로 업그레이드 불가능).
**Memcached 고려 사항**
노드 기반 Memcached 클러스터를 업그레이드할 때만 다음 내용을 고려합니다.
+ 엔진 버전 관리는 패치 발생 방법을 최대한 제어할 수 있도록 설계되었습니다. 그러나 ElastiCache는 시스템 또는 캐시 소프트웨어에 심각한 보안 취약성이 발견되는 등 발생할 가능성이 거의 없는 이벤트의 경우 사용자를 대신하여 클러스터에 패치를 적용할 수 있는 권한을 보유합니다.
+ Memcached 엔진은 지속성을 지원하지 않으므로 Memcached 엔진 버전 업그레이드는 항상 클러스터에서 모든 캐시 데이터를 지우는 방해가 되는 프로세스입니다.
# ElastiCache 모범 사례 및 캐싱 전략
다음은 Amazon ElastiCache에 대한 모범 사례입니다. 다음 모범 사례를 준수하면 클러스터의 성능과 신뢰성을 향상시킬 수 있습니다.
**Topics**
+ [전반적인 모범 사례](WorkingWithRedis.md)
+ [읽기 전용 복제본 사용 모범 사례](ReadReplicas.md)
+ [지원 및 제한된 Valkey, Memcached 및 Redis OSS 명령](SupportedCommands.md)
+ [Valkey 및 Redis OSS 구성 및 제한 사항](RedisConfiguration.md)
+ [Valkey, Memcached, Redis OSS에 대한 IPv6 클라이언트 예시](network-type-best-practices.md)
+ [클라이언트 모범 사례(Valkey 및 Redis OSS)](BestPractices.Clients.redis.md)
+ [클라이언트 모범 사례(Memcached)](BestPractices.Clients.memcached.md)
+ [TLS 활성화 듀얼 스택 ElastiCache 클러스터](#network-type-configuring-tls-enabled-dual-stack)
+ [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md)
+ [Valkey 및 Redis OSS 노드 기반 클러스터 사용 시 모범 사례](BestPractices.SelfDesigned.md)
+ [Memcached에 대한 캐싱 전략](Strategies.md)
# 전반적인 모범 사례
아래에서 ElastiCache 내에서 Valkey, Memcached 및 Redis OSS 인터페이스를 사용하기 위한 모범 사례에 대한 정보를 찾을 수 있습니다.
+ **클러스터 모드 지원 구성 사용** - 클러스터 모드를 활성화하면 수평으로 캐시 규모 조정을 실행하여 클러스터 모드 비활성화 구성보다 더 높은 스토리지 및 처리량에 도달할 수 있습니다. ElastiCache 서버리스는 클러스터 모드가 활성화된 구성에서만 사용할 수 있습니다.
+ **장시간 연결 사용** - 새 연결을 만들려면 비용이 많이 드는 것뿐 아니라 캐시에서 시간을 사용하고 CPU 리소스가 있어야 합니다. 가능하면 연결을 재사용하여(예: 연결 풀링 사용) 여러 명령에서 발생하는 이 비용을 분할 상환합니다.
+ **복제본에서 읽기** - ElastiCache Serverless를 사용하거나 프로비저닝된 읽기 전용 복제본(노드 기반 클러스터)이 있는 경우 복제본으로 직접 읽기를 수행하여 확장성을 향상하거나 지연 시간을 줄일 수 있습니다. 복제본에서의 읽기는 최종적으로 프라이머리와 일치합니다.
노드 기반 클러스터의 경우 노드에 장애가 발생하면 일시적으로 읽기가 불가능할 수 있으므로 읽기 요청을 단일 읽기 전용 복제본으로 보내지 않도록 합니다. 적어도 2개 이상의 읽기 전용 복제복으로 읽기 요청을 보내거나, 단일 복제복과 프라이머리로 읽기 전용 복제복으로 보내도록 클라이언트를 구성할 수 있습니다.
ElastiCache 서버리스의 경우 복제본 포트(6380)에서 읽으면 가능할 때 클라이언트의 로컬 가용 영역으로 읽기가 전달되므로 검색 지연 시간이 줄어듭니다. 장애가 발생하면 자동으로 다른 노드로 대체됩니다.
+ **비용이 많이 드는 명령 피하기** - 컴퓨팅 및 I/O 집약적인 작업(예: `KEYS` 및 `SMEMBERS` 명령)을 실행하지 않습니다. 이러한 작업은 클러스터에 대한 부하를 늘리고 클러스터의 성능에 영향을 미치기 때문에 이러한 접근 방식을 채택하는 것이 좋습니다. 대신 `SCAN` 및 `SSCAN` 명령을 사용합니다.
+ **Lua 모범 사례 따르기** - 오래 실행되는 Lua 스크립트의 사용을 피하고 항상 사전에 Lua 스크립트에 사용되는 키를 선언합니다. 이렇게 하면 Lua 스크립트가 슬롯 간 명령을 사용하지 않습니다. Lua 스크립트에 사용되는 키가 동일한 슬롯에 속해 있는지 확인하세요.
+ **샤딩된 pub/sub 사용** - Valkey 또는 Redis OSS를 사용하여 처리량이 높은 pub/sub 워크로드를 지원하는 경우 [샤딩된 pub/sub](https://valkey.io/topics/pubsub/)(Valkey 및 Redis OSS 7 이상에서 사용 가능)를 사용하는 것이 좋습니다. 클러스터 모드가 활성화된 클러스터의 기존 pub/sub는 클러스터의 모든 노드에 메시지를 브로드캐스트하므로 높은 `EngineCPUUtilization` 결과가 발생할 수 있습니다. ElastiCache 서버리스의 경우 기존 pub/sub 명령에서 내부적으로 샤딩된 pub/sub 명령을 사용합니다.
**Topics**
# 읽기 전용 복제본 사용 모범 사례
세션 스토어, 리더보드, 추천 엔진과 같은 많은 애플리케이션은 고가용성이 필요하며 쓰기 작업보다 훨씬 더 많은 읽기 작업을 처리합니다. 이러한 애플리케이션은 종종 약간 오래된 데이터(이벤트 일관성)를 허용할 수 있습니다. 즉, 서로 다른 사용자가 일시적으로 동일한 데이터의 약간 다른 버전을 보는 경우 허용됩니다. 예제:
+ 캐시된 쿼리 결과는 특히 사실의 출처가 외부인 캐시 어사이드 패턴에서 약간 오래된 데이터를 허용할 수 있는 경우가 많습니다.
+ 게임 리더보드에서 업데이트된 점수의 몇 초 지연은 사용자 경험에 큰 영향을 미치지 않는 경우가 많습니다.
+ 세션 스토어의 경우 복제본 간에 세션 데이터를 전파하는 데 약간의 지연이 발생하면 애플리케이션 기능에 거의 영향을 미치지 않습니다.
+ 권장 엔진은 일반적으로 과거 데이터 분석을 사용하므로 실시간 일관성은 덜 중요합니다.
최종 일관성이란 복제 프로세스가 완료되면 일반적으로 밀리초 이내에 모든 복제본 노드가 동일한 데이터를 반환한다는 의미입니다. 이러한 사용 사례에서 읽기 전용 복제본을 구현하는 것은 ElastiCache 인스턴스에서 읽을 때 지연 시간을 줄이는 효과적인 전략입니다.
Amazon ElastiCache에서 읽기 전용 복제본을 사용하면 다음을 통해 상당한 성능 이점을 얻을 수 있습니다.
**향상된 읽기 확장성**
+ 여러 복제본 노드에 읽기 작업 분산
+ 프라이머리 노드에서 읽기 트래픽 오프로드
+ 지리적으로 더 가까운 복제본의 요청을 처리하여 읽기 지연 시간 단축
**프라이머리 노드 성능 최적화**
+ 프라이머리 노드 리소스를 전용하여 작업을 작성
+ 프라이머리 노드의 연결 오버헤드 감소
+ 최대 트래픽 기간 동안 쓰기 성능을 개선하고 더 나은 응답 시간 유지
## ElastiCache Serverless의 복제본에서 읽기 사용
ElastiCache Serverless는 서로 다른 일관성 요구 사항에 맞는 두 가지 엔드포인트를 제공합니다. 두 엔드포인트는 동일한 DNS 이름을 사용하지만 포트는 다릅니다. read-from-replica 포트를 사용하려면 [VPC의 보안 그룹 및 네트워크 액세스 제어 목록을 구성](set-up.md#elasticache-install-grant-access-VPN)하여 클라이언트 애플리케이션의 두 포트에 대한 액세스를 승인해야 합니다.
**기본 엔드포인트(포트 6379)**
+ 즉각적인 일관성이 필요한 작업에 사용
+ 최신 데이터 읽기 보장
+ 중요한 트랜잭션 및 쓰기 작업에 가장 적합
+ 쓰기 작업에 필요
+ 예시: `test-12345.serverless.use1.cache.amazonaws.com:6379`
**지연 시간 최적화 엔드포인트(포트 6380)**
+ 최종 일관성을 허용할 수 있는 읽기 작업에 최적화됨
+ 가능하면 ElastiCache Serverless는 클라이언트의 로컬 가용 영역에 있는 복제본 노드로 읽기 요청을 자동으로 라우팅합니다. 이 최적화는 다른 가용 영역의 노드에서 데이터를 검색할 때 발생하는 추가 네트워크 지연 시간을 방지하여 지연 시간을 줄입니다.
+ ElastiCache Serverless는 로컬 노드를 사용할 수 없는 경우 다른 영역에서 사용 가능한 노드를 자동으로 선택합니다.
+ 예시: `test-12345.serverless.use1.cache.amazonaws.com:6380`
+ 복제본 구성에서 읽기를 제공하는 경우 Glide 및 Lettuce와 같은 클라이언트는 읽기를 자동으로 감지하여 지연 시간 최적화 엔드포인트로 라우팅합니다. 클라이언트가 라우팅 구성(예: valkey-java 및 이전 jedis 버전)을 지원하지 않는 경우 복제본에서 읽을 올바른 포트 및 클라이언트 구성을 정의해야 합니다.
## ElastiCache Serverless의 읽기 전용 복제본에 연결 - Valkey 및 Glide
다음 코드 조각은 Valkey 글라이드 라이브러리에서 ElastiCache Serverless의 복제본에서 읽기를 구성하는 방법을 보여줍니다. 복제본에서 읽기 위한 포트를 지정할 필요는 없지만 라우팅 구성 `ReadFrom.PREFER_REPLICA`를 구성해야 합니다.
```
package glide.examples;
import glide.api.GlideClusterClient;
import glide.api.logging.Logger;
import glide.api.models.configuration.GlideClusterClientConfiguration;
import glide.api.models.configuration.NodeAddress;
import glide.api.models.exceptions.ClosingException;
import glide.api.models.exceptions.ConnectionException;
import glide.api.models.exceptions.TimeoutException;
import glide.api.models.configuration.ReadFrom;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;
public class ClusterExample {
public static void main(String[] args) {
// Set logger configuration
Logger.setLoggerConfig(Logger.Level.INFO);
GlideClusterClient client = null;
try {
System.out.println("Connecting to Valkey Glide...");
// Configure the Glide Client
GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder()
.address(NodeAddress.builder()
.host("your-endpoint")
.port(6379)
.build())
.useTLS(true)
.readFrom(ReadFrom.PREFER_REPLICA)
.build();
// Create the GlideClusterClient
client = GlideClusterClient.createClient(config).get();
System.out.println("Connected successfully.");
// Perform SET operation
CompletableFuture setResponse = client.set("key", "value");
System.out.println("Set key 'key' to 'value': " + setResponse.get());
// Perform GET operation
CompletableFuture getResponse = client.get("key");
System.out.println("Get response for 'key': " + getResponse.get());
// Perform PING operation
CompletableFuture pingResponse = client.ping();
System.out.println("PING response: " + pingResponse.get());
} catch (ClosingException | ConnectionException | TimeoutException | ExecutionException e) {
System.err.println("An exception occurred: ");
e.printStackTrace();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
// Close the client connection
if (client != null) {
try {
client.close();
System.out.println("Client connection closed.");
} catch (ClosingException | ExecutionException e) {
System.err.println("Error closing client: " + e.getMessage());
}
}
}
}
}
```
# 지원 및 제한된 Valkey, Memcached 및 Redis OSS 명령
## 지원되는 Valkey 및 Redis OSS 명령
**지원되는 Valkey 및 Redis OSS 명령**
서버리스 캐시에서 지원되는 Valkey 및 Redis OSS 명령은 다음과 같습니다. 이러한 명령 외에도 이러한 [지원되는 Valkey 및 Redis OSS 명령JSON 명령](json-list-commands.md) 명령도 지원됩니다.
Bloom 필터 명령에 대한 자세한 내용은 [Bloom 필터 명령](BloomFilters.md#SupportedCommandsBloom) 섹션을 참조하세요.
**비트맵 명령**
+ `BITCOUNT`
문자열에 설정된 비트 수(인구 수 계산)를 계산합니다.
[자세히 알아보기](https://valkey.io/commands/bitcount/)
+ `BITFIELD`
문자열에 대해 임의의 비트필드 정수 연산을 수행합니다.
[자세히 알아보기](https://valkey.io/commands/bitfield/)
+ `BITFIELD_RO`
문자열에 대해 임의의 읽기 전용 비트필드 정수 연산을 수행합니다.
[자세히 알아보기](https://valkey.io/commands/bitfield_ro/)
+ `BITOP`
여러 문자열에 대해 비트 논리곱 연산을 수행하고 결과를 저장합니다.
[자세히 알아보기](https://valkey.io/commands/bitop/)
+ `BITPOS`
문자열에서 첫 번째 세트(1) 또는 클리어(0) 비트를 찾습니다.
[자세히 알아보기](https://valkey.io/commands/bitpos/)
+ `GETBIT`
오프셋을 기준으로 비트 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/getbit/)
+ `SETBIT`
문자열 값의 오프셋에서 비트를 설정하거나 지웁니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/setbit/)
**클러스터 관리 명령**
+ `CLUSTER COUNTKEYSINSLOT`
해시 슬롯의 키 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-countkeysinslot/)
+ `CLUSTER GETKEYSINSLOT`
해시 슬롯의 키 이름을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-getkeysinslot/)
+ `CLUSTER INFO`
노드 상태에 대한 정보를 반환합니다. 서버리스 캐시에서는 클라이언트에 노출된 단일 가상 ‘샤드’에 대한 상태를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-info/)
+ `CLUSTER KEYSLOT`
키의 해시 슬롯을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-keyslot/)
+ `CLUSTER MYID`
노드의 ID를 반환합니다. 서버리스 캐시에서는 클라이언트에 노출된 단일 가상 ‘샤드’에 대한 상태를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-myid/)
+ `CLUSTER NODES`
노드의 클러스터 구성을 반환합니다. 서버리스 캐시에서는 클라이언트에 노출된 단일 가상 ‘샤드’에 대한 상태를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-nodes/)
+ `CLUSTER REPLICAS`
프라이머리 노드의 복제 노드를 나열합니다. 서버리스 캐시에서는 클라이언트에 노출된 단일 가상 ‘샤드’에 대한 상태를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-replicas/)
+ `CLUSTER SHARDS`
클러스터 슬롯의 매핑을 샤드에 반환합니다. 서버리스 캐시에서는 클라이언트에 노출된 단일 가상 ‘샤드’에 대한 상태를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-shards/)
+ `CLUSTER SLOTS`
클러스터 슬롯의 매핑을 노드에 반환합니다. 서버리스 캐시에서는 클라이언트에 노출된 단일 가상 ‘샤드’에 대한 상태를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/cluster-slots/)
+ `CLUSTER SLOT-STATS`
키 수, CPU 사용률, 네트워크 바이트 입력 및 네트워크 바이트 출력에 대한 슬롯당 지표를 추적할 수 있습니다.
[자세히 알아보기](https://valkey.io/commands/cluster-slot-stats/)
+ `READONLY`
Valkey 또는 Redis OSS 클러스터 복제 노드에 대한 연결에서 읽기 전용 쿼리를 활성화합니다.
[자세히 알아보기](https://valkey.io/commands/readonly/)
+ `READWRITE`
Valkey 또는 Redis OSS 클러스터 복제 노드에 대한 연결에서 읽기 쓰기 쿼리를 활성화합니다.
[자세히 알아보기](https://valkey.io/commands/readwrite/)
+ `SCRIPT SHOW`
스크립트 캐시에 있는 스크립트의 원본 소스 코드를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/script-show/)
**연결 관리 명령**
+ `AUTH`
연결을 인증합니다.
[자세히 알아보기](https://valkey.io/commands/auth/)
+ `CLIENT GETNAME`
연결 이름을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/client-getname/)
+ `CLIENT REPLY`
명령에 응답할지 여부를 서버에 지시합니다.
[자세히 알아보기](https://valkey.io/commands/client-reply/)
+ `CLIENT SETNAME`
연결 이름을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/client-setname/)
+ `ECHO`
주어진 문자열을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/echo/)
+ `HELLO`
Valkey 또는 Redis OSS 서버와 핸드셰이크합니다.
[자세히 알아보기](https://valkey.io/commands/hello/)
+ `PING`
서버의 활성 응답을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/ping/)
+ `QUIT`
연결을 종료합니다.
[자세히 알아보기](https://valkey.io/commands/quit/)
+ `RESET`
연결을 초기화합니다.
[자세히 알아보기](https://valkey.io/commands/reset/)
+ `SELECT`
선택한 데이터베이스를 변경합니다.
[자세히 알아보기](https://valkey.io/commands/select/)
**일반 명령**
+ `COPY`
키 값을 새 키로 복사합니다.
[자세히 알아보기](https://valkey.io/commands/copy/)
+ `DEL`
하나 이상의 키를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/del/)
+ `DUMP`
키에 저장된 값의 직렬화된 표현을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/dump/)
+ `EXISTS`
키가 하나 이상 존재하는지 확인합니다.
[자세히 알아보기](https://valkey.io/commands/exists/)
+ `EXPIRE`
키의 만료 시간(초 기준)을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/expire/)
+ `EXPIREAT`
키의 만료 시간을 Unix 타임스탬프로 설정합니다.
[자세히 알아보기](https://valkey.io/commands/expireat/)
+ `EXPIRETIME`
키의 만료 시간을 Unix 타임스탬프로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/expiretime/)
+ `PERSIST`
키의 만료 시간을 제거합니다.
[자세히 알아보기](https://valkey.io/commands/persist/)
+ `PEXPIRE`
키의 만료 시간(밀리초 기준)을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/pexpire/)
+ `PEXPIREAT`
키의 만료 시간을 Unix 밀리초 타임스탬프로 설정합니다.
[자세히 알아보기](https://valkey.io/commands/pexpireat/)
+ `PEXPIRETIME`
키의 만료 시간을 Unix 밀리초 타임스탬프로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pexpiretime/)
+ `PTTL`
키의 만료 시간(밀리초 기준)을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pttl/)
+ `RANDOMKEY`
데이터베이스에서 임의의 키 이름을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/randomkey/)
+ `RENAME`
키 이름을 바꾸고 대상을 덮어씁니다.
[자세히 알아보기](https://valkey.io/commands/rename/)
+ `RENAMENX`
대상 키 이름이 존재하지 않는 경우에만 키 이름을 변경합니다.
[자세히 알아보기](https://valkey.io/commands/renamenx/)
+ `RESTORE`
직렬화된 값 표현에서 키를 만듭니다.
[자세히 알아보기](https://valkey.io/commands/restore/)
+ `SCAN`
데이터베이스의 키 이름을 반복합니다.
[자세히 알아보기](https://valkey.io/commands/scan/)
+ `SORT`
목록, 집합 또는 정렬된 집합의 요소를 정렬하고 필요에 따라 결과를 저장합니다.
[자세히 알아보기](https://valkey.io/commands/sort/)
+ `SORT_RO`
목록, 집합 또는 정렬된 집합의 정렬된 요소를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/sort_ro/)
+ `TOUCH`
마지막으로 액세스한 시각을 업데이트한 후 지정된 키 중에서 기존 키의 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/touch/)
+ `TTL`
키의 만료 시간(초 기준)을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/ttl/)
+ `TYPE`
키에 저장된 값의 유형을 결정합니다.
[자세히 알아보기](https://valkey.io/commands/type/)
+ `UNLINK`
하나 이상의 키를 비동기적으로 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/unlink/)
**지리공간 명령**
+ `GEOADD`
지리공간 인덱스에 하나 이상의 멤버를 추가합니다. 키가 존재하지 않으면 생성됩니다.
[자세히 알아보기](https://valkey.io/commands/geoadd/)
+ `GEODIST`
지리공간 인덱스의 두 멤버 간 거리를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/geodist/)
+ `GEOHASH`
지리공간 인덱스의 멤버를 geohash 문자열로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/geohash/)
+ `GEOPOS`
지리공간 인덱스에서 멤버의 경도와 위도를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/geopos/)
+ `GEORADIUS`
좌표로부터 거리 이내에 있는 멤버의 지리공간 인덱스를 쿼리하고 결과를 필요에 따라 저장합니다.
[자세히 알아보기](https://valkey.io/commands/georadius/)
+ `GEORADIUS_RO`
좌표로부터 거리 이내에 있는 지리공간 인덱스에서 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/georadius_ro/)
+ `GEORADIUSBYMEMBER`
멤버의 거리 이내에 있는 멤버에 대한 지리공간 인덱스를 쿼리하고 결과를 필요에 따라 저장합니다.
[자세히 알아보기](https://valkey.io/commands/georadiusbymember/)
+ `GEORADIUSBYMEMBER_RO`
멤버의 거리 이내에 있는 지리공간 인덱스에서 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/georadiusbymember_ro/)
+ `GEOSEARCH`
상자 또는 원 영역 안에 있는 멤버에 대한 지리공간 인덱스를 쿼리합니다.
[자세히 알아보기](https://valkey.io/commands/geosearch/)
+ `GEOSEARCHSTORE`
상자 또는 원 영역 안에 있는 멤버에 대한 지리공간 인덱스를 쿼리하고, 필요에 따라 결과를 저장합니다.
[자세히 알아보기](https://valkey.io/commands/geosearchstore/)
**해시 명령**
+ `HDEL`
해시에서 하나 이상의 필드와 해당 값을 삭제합니다. 남아 있는 필드가 없으면 해시를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/hdel/)
+ `HEXISTS`
필드가 해시에 존재하는지 여부를 결정합니다.
[자세히 알아보기](https://valkey.io/commands/hexists/)
+ `HGET`
해시의 필드 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hget/)
+ `HGETALL`
해시의 모든 필드와 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hgetall/)
+ `HINCRBY`
해시에 있는 필드의 정수 값을 숫자만큼 증가시킵니다. 필드가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/hincrby/)
+ `HINCRBYFLOAT`
필드의 부동 소수점 값을 숫자만큼 증가시킵니다. 필드가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/hincrbyfloat/)
+ `HKEYS`
해시의 모든 필드를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hkeys/)
+ `HLEN`
해시의 필드 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hlen/)
+ `HMGET`
해시의 모든 필드 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hmget/)
+ `HMSET`
여러 필드의 값을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/hmset/)
+ `HRANDFIELD`
해시에서 하나 이상의 임의 필드를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hrandfield/)
+ `HSCAN`
해시의 필드와 값을 반복합니다.
[자세히 알아보기](https://valkey.io/commands/hscan/)
+ `HSET`
해시에서 필드 값을 만들거나 수정합니다.
[자세히 알아보기](https://valkey.io/commands/hset/)
+ `HSETNX`
필드가 존재하지 않는 경우에만 해시의 필드 값을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/hsetnx/)
+ `HSTRLEN`
필드 값의 길이를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hstrlen/)
+ `HVALS`
해시의 모든 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/hvals/)
**HyperLogLog 명령**
+ `PFADD`
HyperLogLog 키에 요소를 추가합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/pfadd/)
+ `PFCOUNT`
HyperLogLog 키로 관찰한 집합의 대략적인 카디널리티를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pfcount/)
+ `PFMERGE`
하나 이상의 HyperLoglog 값을 단일 키로 병합합니다.
[자세히 알아보기](https://valkey.io/commands/pfmerge/)
**목록 명령**
+ `BLMOVE`
목록에서 요소를 가져와 다른 목록으로 푸시한 다음 반환합니다. 다른 방법으로 요소를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 이동된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/blmove/)
+ `BLMPOP`
여러 목록 중 하나에서 첫 번째 요소를 팝업합니다. 다른 방법으로 요소를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/blmpop/)
+ `BLPOP`
목록에서 첫 번째 요소를 제거하고 반환합니다. 다른 방법으로 요소를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/blpop/)
+ `BRPOP`
목록에서 마지막 요소를 제거하고 반환합니다. 다른 방법으로 요소를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/brpop/)
+ `BRPOPLPUSH`
목록에서 요소를 가져와 다른 목록으로 푸시한 다음 반환합니다. 다른 방법으로 요소를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/brpoplpush/)
+ `LINDEX`
인덱스를 기준으로 목록에서 요소를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/lindex/)
+ `LINSERT`
목록에서 다른 요소 앞 또는 뒤에 요소를 삽입합니다.
[자세히 알아보기](https://valkey.io/commands/linsert/)
+ `LLEN`
목록의 길이를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/llen/)
+ `LMOVE`
한 목록에서 요소를 가져와 다른 목록으로 푸시한 후 요소를 반환합니다. 마지막 요소가 이동된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/lmove/)
+ `LMPOP`
요소를 제거한 후 목록에서 여러 요소를 반환합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/lmpop/)
+ `LPOP`
목록의 첫 번째 요소를 제거한 후 해당 요소를 반환합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/lpop/)
+ `LPOS`
목록에서 일치하는 요소의 인덱스를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/lpos/)
+ `LPUSH`
하나 이상의 요소를 목록 앞에 추가합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/lpush/)
+ `LPUSHX`
목록이 있는 경우에만 목록 앞에 요소를 하나 이상 추가합니다.
[자세히 알아보기](https://valkey.io/commands/lpushx/)
+ `LRANGE`
목록에서 요소 범위를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/lrange/)
+ `LREM`
목록에서 요소를 제거합니다. 마지막 요소가 제거된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/lrem/)
+ `LSET`
인덱스를 기준으로 목록의 요소 값을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/lset/)
+ `LTRIM`
목록의 양쪽 끝에서 요소를 제거합니다. 모든 요소가 잘린 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/ltrim/)
+ `RPOP`
목록에서 마지막 요소를 반환하고 제거합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/rpop/)
+ `RPOPLPUSH`
목록의 마지막 요소를 제거하고 다른 목록으로 푸시한 후 해당 요소를 반환합니다. 마지막 요소가 팝업된 경우 목록을 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/rpoplpush/)
+ `RPUSH`
하나 이상의 요소를 목록 앞에 추가합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/rpush/)
+ `RPUSHX`
목록이 있는 경우에만 목록에 요소를 추가합니다.
[자세히 알아보기](https://valkey.io/commands/rpushx/)
**Pub/Sub 명령**
**참고**
PUBSUB 명령은 내부적으로 샤딩된 PUBSUB를 사용하므로 채널 이름이 혼합됩니다.
+ `PUBLISH`
채널에 메시지를 게시합니다.
[자세히 알아보기](https://valkey.io/commands/publish/)
+ `PUBSUB CHANNELS`
활성 채널을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pubsub-channels/)
+ `PUBSUB NUMSUB`
채널 구독자 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pubsub-numsub/)
+ `PUBSUB SHARDCHANNELS`
활성 샤드 채널을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pubsub-shardchannels/)
+ `PUBSUB SHARDNUMSUB`
샤드 채널 구독자 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/pubsub-shardnumsub/)
+ `SPUBLISH`
샤드 채널에 메시지를 게시합니다.
[자세히 알아보기](https://valkey.io/commands/spublish/)
+ `SSUBSCRIBE`
샤드 채널에 게시된 메시지를 수신합니다.
[자세히 알아보기](https://valkey.io/commands/ssubscribe/)
+ `SUBSCRIBE`
채널에 게시된 메시지를 수신합니다.
[자세히 알아보기](https://valkey.io/commands/subscribe/)
+ `SUNSUBSCRIBE`
샤드 채널에 게시된 메시지 수신을 중단합니다.
[자세히 알아보기](https://valkey.io/commands/sunsubscribe/)
+ `UNSUBSCRIBE`
채널에 게시된 메시지 수신을 중단합니다.
[자세히 알아보기](https://valkey.io/commands/unsubscribe/)
**스크립팅 명령**
+ `EVAL`
서버 측 Lua 스크립트를 실행합니다.
[자세히 알아보기](https://valkey.io/commands/eval/)
+ `EVAL_RO`
읽기 전용 서버 측 Lua 스크립트를 실행합니다.
[자세히 알아보기](https://valkey.io/commands/eval_ro/)
+ `EVALSHA`
SHA1 다이제스트에서 서버 측 Lua 스크립트를 실행합니다.
[자세히 알아보기](https://valkey.io/commands/evalsha/)
+ `EVALSHA_RO`
SHA1 다이제스트에서 읽기 전용 서버 측 Lua 스크립트를 실행합니다.
[자세히 알아보기](https://valkey.io/commands/evalsha_ro/)
+ `SCRIPT EXISTS`
서버 측 Lua 스크립트가 스크립트 캐시에 존재하는지 여부를 결정합니다.
[자세히 알아보기](https://valkey.io/commands/script-exists/)
+ `SCRIPT FLUSH`
현재 운영되지 않는 스크립트 캐시는 서비스에서 관리합니다.
[자세히 알아보기](https://valkey.io/commands/script-flush/)
+ `SCRIPT LOAD`
서버 측 Lua 스크립트를 스크립트 캐시에 로드합니다.
[자세히 알아보기](https://valkey.io/commands/script-load/)
**서버 관리 명령**
**참고**
Valkey 및 Redis OSS에 노드 기반 ElastiCache 클러스터를 사용하는 경우 클라이언트가 모든 기본에 플러시 명령을 전송하여 모든 키를 플러시해야 합니다. Valkey 및 Redis OSS용 ElastiCache 서버리스는 기본 클러스터 토폴로지를 추상화하기 때문에 다르게 작동합니다. 결과적으로 ElastiCache 서버리스에서 `FLUSHDB` 및 `FLUSHALL` 명령은 항상 클러스터 전체의 모든 키를 플러시합니다. 이러한 이유로 서버리스 트랜잭션에는 플러시 명령을 포함할 수 없습니다.
+ `ACL CAT`
ACL 범주 또는 범주 내의 명령을 나열합니다.
[자세히 알아보기](https://valkey.io/commands/acl-cat/)
+ `ACL GENPASS`
ACL 사용자를 식별하는 데 사용할 수 있는 안전한 유사 무작위 암호를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/acl-genpass/)
+ `ACL GETUSER`
사용자의 ACL 규칙을 나열합니다.
[자세히 알아보기](https://valkey.io/commands/acl-getuser/)
+ `ACL LIST`
유효 규칙을 ACL 파일 형식으로 덤프합니다.
[자세히 알아보기](https://valkey.io/commands/acl-list/)
+ `ACL USERS`
모든 ACL 사용자를 나열합니다.
[자세히 알아보기](https://valkey.io/commands/acl-users/)
+ `ACL WHOAMI`
현재 연결의 인증된 사용자 이름을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/acl-whoami/)
+ `DBSIZE`
현재 선택한 데이터베이스의 키 수를 반환합니다. 이 작업이 모든 슬롯에서 세부적으로 수행된다고 보장할 수는 없습니다.
[자세히 알아보기](https://valkey.io/commands/dbsize/)
+ `COMMAND`
모든 명령에 대한 자세한 정보를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/command/)
+ `COMMAND COUNT`
명령 개수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/command-count/)
+ `COMMAND DOCS`
하나, 여러 개 또는 모든 명령에 대한 문서 정보를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/command-docs/)
+ `COMMAND GETKEYS`
임의의 명령에서 키 이름을 추출합니다.
[자세히 알아보기](https://valkey.io/commands/command-getkeys/)
+ `COMMAND GETKEYSANDFLAGS`
임의 명령의 키 이름과 액세스 플래그를 추출합니다.
[자세히 알아보기](https://valkey.io/commands/command-getkeysandflags/)
+ `COMMAND INFO`
하나, 여러 개 또는 모든 명령에 대한 정보를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/command-info/)
+ `COMMAND LIST`
명령 이름 목록을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/command-list/)
+ `COMMANDLOG`
명령 로그 명령을 위한 컨테이너입니다.
[자세히 알아보기](https://valkey.io/commands/commandlog/)
+ `COMMANDLOG GET`
지정된 명령 로그의 항목을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/commandlog-get/)
+ `COMMANDLOG HELP`
다양한 하위 명령에 대한 유용한 텍스트를 표시합니다.
[자세히 알아보기](https://valkey.io/commands/commandlog-help/)
+ `COMMANDLOG LEN`
지정된 유형의 명령 로그에 있는 항목 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/commandlog-len/)
+ `COMMANDLOG RESET`
지정된 유형의 명령 로그에서 모든 항목을 지웁니다.
[자세히 알아보기](https://valkey.io/commands/commandlog-reset/)
+ `FLUSHALL`
모든 데이터베이스에서 모든 키를 제거합니다. 이 작업이 모든 슬롯에서 세부적으로 수행된다고 보장할 수는 없습니다.
[자세히 알아보기](https://valkey.io/commands/flushall/)
+ `FLUSHDB`
현재 데이터베이스에서 모든 키를 제거합니다. 이 작업이 모든 슬롯에서 세부적으로 수행된다고 보장할 수는 없습니다.
[자세히 알아보기](https://valkey.io/commands/flushdb/)
+ `INFO`
서버에 대한 정보와 통계를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/info/)
+ `LOLWUT`
컴퓨터 아트와 Valkey 또는 Redis OSS 버전을 표시합니다.
[자세히 알아보기](https://valkey.io/commands/lolwut/)
+ `ROLE`
복제 역할을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/role/)
+ `TIME`
서버 시각을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/time/)
**설정 명령**
+ `SADD`
세트에 하나 이상의 멤버를 추가합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/sadd/)
+ `SCARD`
세트에 멤버 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/scard/)
+ `SDIFF`
여러 세트의 차이를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/sdiff/)
+ `SDIFFSTORE`
여러 세트의 차이를 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/sdiffstore/)
+ `SINTER`
여러 세트의 교차점을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/sinter/)
+ `SINTERCARD`
여러 세트의 교차점에 있는 멤버 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/sintercard/)
+ `SINTERSTORE`
여러 세트의 교차점을 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/sinterstore/)
+ `SISMEMBER`
멤버가 세트에 속하는지 여부를 결정합니다.
[자세히 알아보기](https://valkey.io/commands/sismember/)
+ `SMEMBERS`
세트의 모든 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/smembers/)
+ `SMISMEMBER`
멤버가 세트에 속하는지 여부를 결정합니다.
[자세히 알아보기](https://valkey.io/commands/smismember/)
+ `SMOVE`
한 세트에서 다른 세트로 멤버를 이동합니다.
[자세히 알아보기](https://valkey.io/commands/smove/)
+ `SPOP`
하나 이상의 무작위 멤버를 제거한 후 세트에서 해당 멤버를 반환합니다. 마지막 멤버가 팝업된 경우 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/spop/)
+ `SRANDMEMBER`
세트에서 하나 또는 여러 개의 무작위 멤버를 가져옵니다.
[자세히 알아보기](https://valkey.io/commands/srandmember/)
+ `SREM`
세트에서 하나 이상의 멤버를 제거합니다. 마지막 멤버가 제거된 경우 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/srem/)
+ `SSCAN`
세트의 멤버를 반복합니다.
[자세히 알아보기](https://valkey.io/commands/sscan/)
+ `SUNION`
여러 세트의 결합을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/sunion/)
+ `SUNIONSTORE`
여러 세트의 결합을 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/sunionstore/)
**정렬된 세트 명령**
+ `BZMPOP`
하나 이상의 정렬된 세트에서 점수별로 멤버를 제거하고 반환합니다. 다른 방법으로 멤버를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/bzmpop/)
+ `BZPOPMAX`
하나 이상의 정렬된 세트에서 높은 점수별로 멤버를 제거하고 반환합니다. 다른 방법으로 멤버를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/bzpopmax/)
+ `BZPOPMIN`
하나 이상의 정렬된 세트에서 낮은 점수별로 멤버를 제거하고 반환합니다. 다른 방법으로 멤버를 사용할 수 있을 때까지 차단합니다. 마지막 요소가 팝업된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/bzpopmin/)
+ `ZADD`
정렬된 세트에 하나 이상의 멤버를 추가하거나 멤버의 점수를 업데이트합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/zadd/)
+ `ZCARD`
정렬된 세트에서 멤버 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zcard/)
+ `ZCOUNT`
일정 범위 내에 점수가 있는 정렬된 세트의 멤버 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zcount/)
+ `ZDIFF`
여러 정렬된 세트의 차이를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zdiff/)
+ `ZDIFFSTORE`
여러 정렬된 세트의 차이를 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/zdiffstore/)
+ `ZINCRBY`
정렬된 세트에 있는 멤버의 점수를 증가시킵니다.
[자세히 알아보기](https://valkey.io/commands/zincrby/)
+ `ZINTER`
여러 정렬된 세트의 교차점을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zinter/)
+ `ZINTERCARD`
여러 정렬된 세트의 교차점에 있는 멤버 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zintercard/)
+ `ZINTERSTORE`
여러 정렬된 세트의 교차점을 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/zinterstore/)
+ `ZLEXCOUNT`
사전 범위 내에 있는 정렬된 세트의 멤버 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zlexcount/)
+ `ZMPOP`
하나 이상의 정렬된 세트에서 가장 높은 점수 또는 가장 낮은 점수를 받은 멤버를 제거한 후 해당 멤버를 반환합니다. 마지막 멤버가 팝업된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zmpop/)
+ `ZMSCORE`
정렬된 세트에 있는 하나 이상의 멤버 점수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zmscore/)
+ `ZPOPMAX`
가장 높은 점수를 받은 멤버를 제거한 후 정렬된 세트에서 해당 멤버를 반환합니다. 마지막 멤버가 팝업된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zpopmax/)
+ `ZPOPMIN`
가장 낮은 점수를 받은 멤버를 제거한 후 정렬된 세트에서 해당 멤버를 반환합니다. 마지막 멤버가 팝업된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zpopmin/)
+ `ZRANDMEMBER`
정렬된 세트에서 하나 이상의 임의 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrandmember/)
+ `ZRANGE`
인덱스 범위 내에 있는 정렬된 세트의 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrange/)
+ `ZRANGEBYLEX`
사전 범위 내에 있는 정렬된 세트의 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrangebylex/)
+ `ZRANGEBYSCORE`
점수 범위 내에 있는 정렬된 세트의 멤버를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrangebyscore/)
+ `ZRANGESTORE`
정렬된 세트의 멤버 범위를 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/zrangestore/)
+ `ZRANK`
오름차순 점수를 기준으로 정렬된 세트의 멤버 인덱스를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrank/)
+ `ZREM`
정렬된 세트에서 하나 이상의 멤버를 제거합니다. 모든 멤버가 제거된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zrem/)
+ `ZREMRANGEBYLEX`
사전 범위 내에 있는 정렬된 세트의 멤버를 제거합니다. 모든 멤버가 제거된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zremrangebylex/)
+ `ZREMRANGEBYRANK`
인덱스 범위 내에 있는 정렬된 세트의 멤버를 제거합니다. 모든 멤버가 제거된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zremrangebyrank/)
+ `ZREMRANGEBYSCORE`
점수 범위 내에 있는 정렬된 세트의 멤버를 제거합니다. 모든 멤버가 제거된 경우 정렬된 세트를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/zremrangebyscore/)
+ `ZREVRANGE`
인덱스 범위 내에 있는 정렬된 세트의 멤버를 역순으로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrevrange/)
+ `ZREVRANGEBYLEX`
사전 범위 내에 있는 정렬된 세트의 멤버를 역순으로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrevrangebylex/)
+ `ZREVRANGEBYSCORE`
점수 범위 내에 있는 정렬된 세트의 멤버를 역순으로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrevrangebyscore/)
+ `ZREVRANK`
내림차순 점수를 기준으로 정렬된 세트의 멤버 인덱스를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zrevrank/)
+ `ZSCAN`
정렬된 세트의 멤버와 점수를 반복합니다.
[자세히 알아보기](https://valkey.io/commands/zscan/)
+ `ZSCORE`
정렬된 세트에 있는 멤버의 점수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zscore/)
+ `ZUNION`
여러 정렬된 세트의 결합을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/zunion/)
+ `ZUNIONSTORE`
여러 정렬된 세트의 결합을 키에 저장합니다.
[자세히 알아보기](https://valkey.io/commands/zunionstore/)
**스트림 명령**
+ `XACK`
스트림의 소비자 그룹 멤버가 성공적으로 확인한 메시지 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xack/)
+ `XADD`
스트림에 새 메시지를 추가합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/xadd/)
+ `XAUTOCLAIM`
메시지가 소비자 그룹 멤버로 전달된 것처럼 소비자 그룹의 메시지 소유권을 변경하거나 획득합니다.
[자세히 알아보기](https://valkey.io/commands/xautoclaim/)
+ `XCLAIM`
메시지가 소비자 그룹 멤버로 전달된 것처럼 소비자 그룹의 메시지 소유권을 변경하거나 획득합니다.
[자세히 알아보기](https://valkey.io/commands/xclaim/)
+ `XDEL`
스트림에서 메시지를 제거한 후 메시지 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xdel/)
+ `XGROUP CREATE`
소비자 그룹을 생성합니다.
[자세히 알아보기](https://valkey.io/commands/xgroup-create/)
+ `XGROUP CREATECONSUMER`
소비자 그룹에 소비자를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/xgroup-createconsumer/)
+ `XGROUP DELCONSUMER`
소비자 그룹에서 소비자를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/xgroup-delconsumer/)
+ `XGROUP DESTROY`
소비자 그룹을 제거합니다.
[자세히 알아보기](https://valkey.io/commands/xgroup-destroy/)
+ `XGROUP SETID`
소비자 그룹에 마지막으로 전달된 ID를 설정합니다.
[자세히 알아보기](https://valkey.io/commands/xgroup-setid/)
+ `XINFO CONSUMERS`
소비자 그룹의 소비자 목록을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xinfo-consumers/)
+ `XINFO GROUPS`
스트림의 소비자 그룹 목록을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xinfo-groups/)
+ `XINFO STREAM`
스트림에 대한 정보를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xinfo-stream/)
+ `XLEN`
스트림의 메시지 수를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xlen/)
+ `XPENDING`
스트림 소비자 그룹의 보류 중인 항목 목록에서 정보와 항목을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xpending/)
+ `XRANGE`
ID 범위 내의 스트림에서 메시지를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xrange/)
+ `XREAD`
요청된 ID보다 큰 ID를 가진 여러 스트림의 메시지를 반환합니다. 다른 방법으로 메시지를 사용할 수 있을 때까지 차단합니다.
[자세히 알아보기](https://valkey.io/commands/xread/)
+ `XREADGROUP`
스트림에서 그룹 내 소비자에게 새 메시지 또는 과거 메시지를 반환합니다. 다른 방법으로 메시지를 사용할 수 있을 때까지 차단합니다.
[자세히 알아보기](https://valkey.io/commands/xreadgroup/)
+ `XREVRANGE`
ID 범위 내의 스트림에서 역순으로 메시지를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/xrevrange/)
+ `XTRIM`
스트림의 시작 부분부터 메시지를 삭제합니다.
[자세히 알아보기](https://valkey.io/commands/xtrim/)
**문자열 명령**
+ `APPEND`
키 값에 문자열을 추가합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/append/)
+ `DECR`
키의 정수 값을 1씩 줄입니다. 키가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/decr/)
+ `DECRBY`
키의 정수 값에서 숫자를 줄입니다. 키가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/decrby/)
+ `GET`
키의 문자열 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/get/)
+ `GETDEL`
키를 삭제한 후 키의 문자열 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/getdel/)
+ `GETEX`
만료 시각을 설정한 후 키의 문자열 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/getex/)
+ `GETRANGE`
키에 저장된 문자열의 하위 문자열을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/getrange/)
+ `GETSET`
키를 새 값으로 설정한 후 키의 이전 문자열 값을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/getset/)
+ `INCR`
키의 정수 값을 1씩 증가시킵니다. 키가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/incr/)
+ `INCRBY`
키의 정수 값을 숫자만큼 증가시킵니다. 키가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/incrby/)
+ `INCRBYFLOAT`
필드의 부동 소수점 값을 숫자만큼 증가시킵니다. 키가 존재하지 않는 경우 0을 초기값으로 사용합니다.
[자세히 알아보기](https://valkey.io/commands/incrbyfloat/)
+ `LCS`
가장 긴 공통 하위 문자열을 찾습니다.
[자세히 알아보기](https://valkey.io/commands/lcs/)
+ `MGET`
하나 이상인 키의 문자열 값을 세부적으로 반환합니다.
[자세히 알아보기](https://valkey.io/commands/mget/)
+ `MSET`
하나 이상인 키의 문자열 값을 세부적으로 생성 또는 수정합니다.
[자세히 알아보기](https://valkey.io/commands/mset/)
+ `MSETNX`
모든 키가 존재하지 않는 경우에만 하나 이상인 키의 문자열 값을 세부적으로 수정합니다.
[자세히 알아보기](https://valkey.io/commands/msetnx/)
+ `PSETEX`
키의 문자열 값과 만료 시각(밀리초 기준)을 모두 설정합니다. 키가 존재하지 않으면 생성됩니다.
[자세히 알아보기](https://valkey.io/commands/psetex/)
+ `SET`
유형을 무시하고 키의 문자열 값을 설정합니다. 키가 존재하지 않으면 생성됩니다.
[자세히 알아보기](https://valkey.io/commands/set/)
+ `SETEX`
키의 문자열 값과 만료 시각을 설정합니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/setex/)
+ `SETNX`
키가 존재하지 않는 경우에만 키의 문자열 값을 설정합니다.
[자세히 알아보기](https://valkey.io/commands/setnx/)
+ `SETRANGE`
문자열 값의 일부를 오프셋에서 다른 값으로 덮어씁니다. 존재하지 않으면 키를 생성합니다.
[자세히 알아보기](https://valkey.io/commands/setrange/)
+ `STRLEN`
문자열 값의 길이를 반환합니다.
[자세히 알아보기](https://valkey.io/commands/strlen/)
+ `SUBSTR`
문자열 값에서 하위 문자열을 반환합니다.
[자세히 알아보기](https://valkey.io/commands/substr/)
**트랜잭션 명령**
+ `DISCARD`
트랜잭션을 폐기합니다.
[자세히 알아보기](https://valkey.io/commands/discard/)
+ `EXEC`
트랜잭션의 모든 명령을 실행합니다.
[자세히 알아보기](https://valkey.io/commands/exec/)
+ `MULTI`
트랜잭션을 시작합니다.
[자세히 알아보기](https://valkey.io/commands/multi/)
## 제한된 Valkey 및 Redis OSS 명령
관리형 서비스 환경을 제공하기 위해 ElastiCache는 고급 권한이 필요한 특정 캐시 엔진별 명령에 대한 액세스를 제한합니다. Redis OSS를 실행하는 캐시의 경우 다음 명령을 사용할 수 없습니다.
+ `acl setuser`
+ `acl load`
+ `acl save`
+ `acl deluser`
+ `bgrewriteaof`
+ `bgsave`
+ `cluster addslot`
+ `cluster addslotsrange`
+ `cluster bumpepoch`
+ `cluster delslot`
+ `cluster delslotsrange `
+ `cluster failover `
+ `cluster flushslots `
+ `cluster forget `
+ `cluster links`
+ `cluster meet`
+ `cluster setslot`
+ `config`
+ `debug`
+ `migrate`
+ `psync`
+ `replicaof`
+ `save`
+ `slaveof`
+ `shutdown`
+ `sync`
또한 서버리스 캐시에는 다음 명령을 사용할 수 없습니다.
+ `acl log`
+ `client caching`
+ `client getredir`
+ `client id`
+ `client info`
+ `client kill`
+ `client list`
+ `client no-evict`
+ `client pause`
+ `client tracking`
+ `client trackinginfo`
+ `client unblock`
+ `client unpause`
+ `cluster count-failure-reports`
+ `commandlog`
+ `commandlog get`
+ `commandlog help`
+ `commandlog len`
+ `commandlog reset`
+ `fcall`
+ `fcall_ro`
+ `function`
+ `function delete`
+ `function dump`
+ `function flush`
+ `function help`
+ `function kill`
+ `function list`
+ `function load`
+ `function restore`
+ `function stats`
+ `keys`
+ `lastsave`
+ `latency`
+ `latency doctor`
+ `latency graph`
+ `latency help`
+ `latency histogram`
+ `latency history`
+ `latency latest`
+ `latency reset`
+ `memory`
+ `memory doctor`
+ `memory help`
+ `memory malloc-stats`
+ `memory purge`
+ `memory stats`
+ `memory usage`
+ `monitor`
+ `move`
+ `object`
+ `object encoding`
+ `object freq`
+ `object help`
+ `object idletime`
+ `object refcount`
+ `pfdebug`
+ `pfselftest`
+ `psubscribe`
+ `pubsub numpat`
+ `punsubscribe`
+ `script kill`
+ `slowlog`
+ `slowlog get`
+ `slowlog help`
+ `slowlog len`
+ `slowlog reset`
+ `swapdb`
+ `wait`
## 지원되는 Memcached 명령
ElastiCache Serverless for Memcached는 다음을 제외하고 오픈 소스 memcached 1.6의 모든 memcached [명령](https://github.com/memcached/memcached/wiki/Commands)을 지원합니다.
+ 클라이언트를 연결하려면 TLS가 필요하므로 UDP 프로토콜이 지원되지 않습니다.
+ 바이너리 프로토콜은 memcached 1.6에서 공식적으로 [지원 중단](https://github.com/memcached/memcached/wiki/ReleaseNotes160)되었으므로 지원되지 않습니다.
+ 많은 수의 키를 가져와서 서버에 대한 잠재적인 DoS 공격을 피하기 위해 `GET/GETS` 명령은 16KB로 제한됩니다.
+ `CLIENT_ERROR`에서는 지연된 `flush_all` 명령이 거부됩니다.
+ 다음과 같이 엔진을 구성하거나 엔진 상태 또는 로그에 대한 내부 정보를 표시하는 명령은 지원되지 않습니다.
+ `STATS` 명령의 경우 `stats`, `stats reset`만 지원됩니다. 다른 변형은 `ERROR`를 반환합니다.
+ `lru / lru_crawler` - LRU 및 LRU 크롤러 설정 수정
+ `watch` - memcached 서버 로그 감시
+ `verbosity` - 서버 로그 수준 구성
+ `me` - 메타 디버그(me) 명령은 지원되지 않습니다.
# Valkey 및 Redis OSS 구성 및 제한 사항
Valkey 및 Redis OSS 엔진은 각각 여러 구성 파라미터를 제공하며, 그중 일부는 ElastiCache for Redis OSS에서 수정할 수 있고 일부는 안정적인 성능과 신뢰성을 제공하기 위해 수정할 수 없습니다.
## 서버리스 캐시
서버리스 캐시의 경우 파라미터 그룹은 사용되지 않으며 모든 Valkey 또는 Redis OSS 구성은 수정할 수 없습니다. 다음과 같은 Valkey 또는 Redis OSS 파라미터가 있습니다.
****
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| acl-pubsub-default | `allchannels` | 캐시의 ACL 사용자에 대한 기본 pub/sub 채널 권한입니다. |
| client-output-buffer-limit | `normal 0 0 0` `pubsub 32mb 8mb 60` | 일반 클라이언트에는 버퍼 제한이 없습니다. PUB/SUB 클라이언트가 32MiB 백로그를 위반하거나 60초 동안 8MiB 백로그를 위반하는 경우 연결이 해제됩니다. |
| client-query-buffer-limit | 1GiB | 단일 클라이언트 쿼리 버퍼의 최대 크기입니다. 또한 클라이언트는 3,999개 이상의 인수로 요청을 발행할 수 없습니다. |
| cluster-allow-pubsubshard-when-down | yes | 이렇게 하면 캐시가 부분적으로 다운된 상태에서도 캐시가 pubsub 트래픽을 처리할 수 있습니다. |
| cluster-allow-reads-when-down | yes | 이렇게 하면 캐시가 부분적으로 다운된 상태에서도 캐시가 읽기 트래픽을 처리할 수 있습니다. |
| cluster-enabled | yes | 모든 서버리스 캐시는 클러스터 모드를 지원하므로 데이터를 여러 백엔드 샤드에 투명하게 분할할 수 있습니다. 모든 슬롯은 단일 가상 노드에 포함된 것으로 클라이언트에 표시됩니다. |
| cluster-require-full-coverage | no | 키스페이스가 부분적으로 다운된 경우(즉, 적어도 하나 이상의 해시 슬롯에 액세스할 수 없는 경우) 캐시는 여전히 포함되는 키스페이스 부분의 쿼리를 계속 수락합니다. 전체 키스페이스는 항상 cluster slots의 단일 가상 노드에서 ‘포함’ 상태로 존재합니다. |
| lua-time-limit | 5000 | ElastiCache가 스크립트를 중지하기 전 Lua 스크립트의 최대 실행 시간(밀리초)입니다.`lua-time-limit`이 초과되면 모든 Valkey 또는 Redis OSS 명령은 *\$1\$1\$1\$1-BUSY* 형식의 오류를 반환할 수 있습니다. 이런 상태는 여러 가지 필수적인 Valkey 또는 Redis OSS 작업에 방해가 될 수 있으므로 ElastiCache는 먼저 *SCRIPT KILL* 명령을 실행합니다. 실패할 경우 ElastiCache는 Valkey 또는 Redis OSS를 강제로 다시 시작합니다. |
| maxclients | 65000 | 한 번에 캐시에 연결할 수 있는 최대 클라이언트 수입니다. 설정된 추가 연결이 성공하거나 성공하지 못할 수 있습니다. |
| maxmemory-policy | volatile-lru | TTL이 설정된 항목은 캐시가 메모리 한도에 도달하면 가장 오랫동안 사용되지 않은(LRU) 것을 추정하여 제거합니다. |
| notify-keyspace-events | (빈 문자열) | 현재 키스페이스 이벤트는 서버리스 캐시에서는 지원되지 않습니다. |
| port | 기본 포트: 6379 읽기 포트: 6380 | 서버리스 캐시는 동일한 호스트 이름이 있는 포트 2개로 제시됩니다. 기본 포트에서는 쓰기 및 읽기가 가능한 반면, 읽기 포트는 READONLY 명령을 사용하여 짧은 지연 시간으로 최종 읽기 일관성을 지원합니다. |
| proto-max-bulk-len | 512MiB | 단일 요소 요청의 최대 크기입니다. |
| timeout | 0 | 클라이언트는 특정 유휴 시간에 강제로 연결이 해제되지는 않지만 로드 밸런싱을 위해 정상 상태일 때 연결이 해제되는 경우도 있을 수 있습니다. |
또한 다음과 같은 제한 사항이 있습니다.
****
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| 캐시당 크기 | 5,000GiB | 서버리스 캐시당 저장할 수 있는 최대 데이터 양입니다. |
| 슬롯당 크기 | 32GiB | 단일 Valkey 또는 Redis OSS 해시 슬롯의 최대 크기입니다. 클라이언트가 단일 Valkey 또는 Redis OSS 슬롯에 이 기준보다 많은 데이터를 설정하려고 하면 슬롯에서 제거 정책이 트리거되고 제거할 수 있는 키가 없는 경우 메모리 부족(OOM) 오류가 발생합니다. |
| 캐시당 ECPU | 15,000,000 ECPU/초 | ElastiCache 처리 단위(ECPU) 지표입니다. 요청에 사용되는 ECPU 수는 소요된 vCPU 시간과 전송된 데이터의 양에 따라 달라집니다. |
| 슬롯당 ECPU | 30,000\$190,000 ECPU/초 | 슬롯당 최대 30,000 ECPU/초, 또는 READONLY 연결을 사용하여 복제본에서 읽기를 사용하는 경우 90,000 ECPU/초를 지원합니다. |
| 요청당 인수 | 3,999 | 요청당 최대 인수 수입니다. 요청당 더 많은 인수를 보내는 클라이언트는 오류를 수신합니다. |
| 키 이름 길이 | 4KiB | 단일 Valkey 또는 Redis OSS 키 또는 채널 이름의 최대 크기입니다. 이 기준보다 큰 키를 참조하는 클라이언트에는 오류가 발생합니다. |
| Lua 스크립트 크기 | 4MiB | 단일 Valkey 또는 Redis OSS Lua 스크립트의 최대 크기입니다. 이 기준보다 큰 Lua 스크립트를 로드하려고 하면 오류가 발생합니다. |
## 노드 기반 클러스터
노드 기반 클러스터의 경우 구성 가능한 구성 파라미터의 기본값에 대해 알아보려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요. 기본값을 재정의해야 하는 특정 사용 사례가 없는 한 일반적으로 기본값을 사용하는 것이 좋습니다.
# Valkey, Memcached, Redis OSS에 대한 IPv6 클라이언트 예시
ElastiCache는 Valkey, Memcached, Redis OSS와 호환됩니다. 즉, IPv6 연결을 지원하는 클라이언트는 IPv6 지원 ElastiCache for Memcached 클러스터에 연결할 수 있어야 합니다. IPv6 활성화 리소스와 상호 작용할 때 주의해야 할 점이 몇 가지 있습니다.
AWS 데이터베이스 블로그의 [Best practices for Valkey and Redis clients](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) 블로그 게시물에서 ElastiCache 리소스에 대한 Valkey 및 Redis OSS 클라이언트 구성에 대한 권장 사항을 확인할 수 있습니다.
다음은 일반적으로 사용되는 오픈 소스 클라이언트 라이브러리로 IPv6 활성화 ElastiCache 리소스와 상호 작용하는 모범 사례입니다.
## Valkey 및 Redis OSS로 검증된 클라이언트
ElastiCache는 Valkey 및 오픈 소스 Redis OSS와 호환됩니다. 즉, IPv6 연결을 지원하는 Valkey 및 오픈 소스 Redis OSS 클라이언트는 IPv6 활성화 ElastiCache for Redis OSS 클러스터에 반드시 연결 가능합니다. 또한 가장 널리 사용되는 Python 및 Java 클라이언트 몇 종도 특별한 테스트를 거쳐 지원되는 모든 네트워크 유형 구성(IPv4 전용, IPv6 전용, 듀얼 스택)에서 동작한다고 검증되었습니다.
다음 클라이언트는 Valkey 및 Redis OSS에 대해 지원되는 모든 네트워크 유형 구성에서 작동한다고 특별 검증되었습니다.
검증된 클라이언트:
+ [Redis Py ()](https://github.com/redis/redis-py) – [4.1.2](https://github.com/redis/redis-py/tree/v4.1.2)
+ [Lettuce](https://lettuce.io/) – [버전: 6.1.6.RELEASE](https://github.com/lettuce-io/lettuce-core/tree/6.1.6.RELEASE)
+ [Jedis](https://github.com/redis/jedis) – [버전: 3.6.0](https://github.com/redis/jedis/tree/jedis-3.6.0)
# 클라이언트 모범 사례(Valkey 및 Redis OSS)
일반적인 시나리오의 모범 사례를 알아보고 가장 인기 있는 오픈 소스 Valkey 및 Redis OSS 클라이언트 라이브러리(redis-py, PHPRedis 및 Lettuce)의 코드 예제와 함께 일반적으로 사용되는 오픈 소스 Memcached 클라이언트 라이브러리를 사용하여 ElastiCache 리소스와 상호 작용하기 위한 모범 사례를 따르세요.
**Topics**
+ [많은 수의 연결(Valkey 및 Redis OSS)](BestPractices.Clients.Redis.Connections.md)
+ [클러스터 클라이언트 검색 및 지수 백오프(Valkey 및 Redis OSS)](BestPractices.Clients.Redis.Discovery.md)
+ [클라이언트 측 제한 시간 구성(Valkey 및 Redis OSS)](BestPractices.Clients.Redis.ClientTimeout.md)
+ [서버 측 유휴 제한 시간 구성(Valkey 및 Redis OSS)](BestPractices.Clients.Redis.ServerTimeout.md)
+ [Lua 스크립트](BestPractices.Clients.Redis.LuaScripts.md)
+ [대규모 복합 항목 저장(Valkey 및 Redis OSS)](BestPractices.Clients.Redis.LargeItems.md)
+ [Lettuce 클라이언트 구성(Valkey 및 Redis OSS)](BestPractices.Clients-lettuce.md)
+ [듀얼 스택 클러스터에 선호되는 프로토콜 구성(Valkey 및 Redis OSS)](#network-type-configuring-dual-stack-redis)
# 많은 수의 연결(Valkey 및 Redis OSS)
서버리스 캐시와 각 ElastiCache for Redis OSS 노드는 최대 65,000개의 동시 클라이언트 연결을 지원합니다. 하지만 성능을 최적화하려면 클라이언트 애플리케이션이 해당 연결 수준에서 계속 작동하지 않는 것이 좋습니다. Valkey와 Redis OSS는 각각 들어오는 클라이언트 요청이 순차적으로 처리되는 이벤트 루프를 기반으로 하는 단일 스레드 프로세스입니다. 즉, 연결된 클라이언트 수가 늘어날수록 해당 클라이언트의 응답 시간이 길어집니다.
Valkey 또는 Redis OSS 서버에서 연결 병목 현상이 발생하지 않도록 다음과 같이 조치를 취할 수 있습니다.
+ 읽기 전용 복제본에서 읽기 작업을 수행합니다. 이렇게 하려면 클러스터 모드가 비활성화된 상태에서 ElastiCache 리더 엔드포인트를 사용하거나, 클러스터 모드가 활성화된 상태에서 읽기 전용 복제본(서버리스 캐시 포함)을 사용하여 수행할 수 있습니다.
+ 쓰기 트래픽을 여러 프라이머리 노드에 분산합니다. 2가지 방법으로 수행할 수 있습니다. Valkey 또는 Redis OSS 클러스터 모드 지원 클라이언트와 함께 다중으로 샤딩된 클러스터를 사용할 수 있습니다. 클라이언트 측 샤딩이 비활성화된 클러스터 모드에서 여러 프라이머리 노드에 쓸 수도 있습니다. 이 작업은 서버리스 캐시에서 자동으로 수행됩니다.
+ 클라이언트 라이브러리에서 사용 가능한 경우 연결 풀을 사용하세요.
일반적으로 TCP 연결을 생성하는 작업은 일반적인 Valkey 또는 Redis OSS 명령보다 계산 비용이 많이 듭니다. 예를 들어 기존 연결을 재사용할 경우 SET/GET 요청을 처리하는 속도가 훨씬 빠릅니다. 크기가 한정된 클라이언트 연결 풀을 사용하면 연결 관리 시의 오버헤드가 줄어듭니다. 또한 클라이언트 애플리케이션에서 동시에 들어오는 연결 수를 제한합니다.
PHPRedis의 다음 코드 예제는 새 사용자 요청별로 새 연결이 생성된다는 것을 보여 줍니다.
```
$redis = new Redis();
if ($redis->connect($HOST, $PORT) != TRUE) {
//ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
AWS는 이 코드를 Graviton2(m6g.2xlarge) ElastiCache for Redis OSS 노드에 연결된 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 루프로 벤치마킹했습니다. 클라이언트와 서버를 동일 가용 영역에 배치했습니다. 전체 작업의 평균 지연 시간은 2.82밀리초였습니다.
코드를 업데이트하고 영구 연결과 연결 풀을 사용했을 때 전체 작업의 평균 지연 시간은 0.21밀리초였습니다.
```
$redis = new Redis();
if ($redis->pconnect($HOST, $PORT) != TRUE) {
// ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
필수 redis.ini 구성:
+ `redis.pconnect.pooling_enabled=1`
+ `redis.pconnect.connection_limit=10`
다음 코드는 [Redis-py 연결 풀](https://redis.readthedocs.io/en/stable/)의 예제입니다.
```
conn = Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
conn.set(key, value)
```
다음 코드는 [Lettuce 연결 풀](https://lettuce.io/core/release/reference/#_connection_pooling)의 예제입니다.
```
RedisClient client = RedisClient.create(RedisURI.create(HOST, PORT));
GenericObjectPool pool = ConnectionPoolSupport.createGenericObjectPool(() -> client.connect(), new GenericObjectPoolConfig());
pool.setMaxTotal(10); // Configure max connections to 10
try (StatefulRedisConnection connection = pool.borrowObject()) {
RedisCommands syncCommands = connection.sync();
syncCommands.set(key, value);
}
```
# 클러스터 클라이언트 검색 및 지수 백오프(Valkey 및 Redis OSS)
클러스터 모드가 활성화된 상태에서 ElastiCache Valkey 또는 Redis OSS 클러스터에 연결하는 경우 해당 클라이언트 라이브러리가 클러스터를 인식해야 합니다. 요청을 올바른 노드로 보내고 클러스터 리디렉션을 처리하는 데 따른 성능 오버헤드를 피하려면 클라이언트가 클러스터의 해당 노드에 대한 해시 슬롯 맵을 가져와야 합니다. 따라서 클라이언트는 다음과 같은 2가지 상황에서 전체 슬롯 목록과 매핑된 노드를 검색해야 합니다.
+ 클라이언트가 초기화되었으므로 초기 슬롯 구성을 채워야 합니다.
+ MOVED 리디렉션은 서버에서 수신됩니다. 이전 프라이머리 노드가 제공하는 모든 슬롯이 복제본에서 인계되는 장애 조치이거나, 슬롯이 소스 프라이머리 노드에서 대상 프라이머리 노드로 이동할 때 샤딩이 다시 수행되는 경우가 그러한 예입니다.
클라이언트 검색은 일반적으로 Valkey 또는 Redis OSS 서버에 CLUSTER SLOT 또는 CLUSTER NODE 명령을 실행하여 수행됩니다. CLUSTER SLOT 메서드는 슬롯 범위 집합과 관련된 프라이머리 노드 및 복제본 노드를 클라이언트에 반환하므로 이 메서드를 사용하는 것이 좋습니다. 이렇게 하면 클라이언트의 추가 구문 분석이 필요하지 않아 더 효율적입니다.
클러스터 토폴로지에 따라 CLUSTER SLOT 명령의 응답 크기가 클러스터 크기를 기반으로 달라질 수 있습니다. 큰 클러스터의 노드 수가 많을수록 응답 크기도 커집니다. 따라서 클러스터 토폴로지 검색을 수행하는 클라이언트 수가 무제한으로 증가하지 않도록 하는 것이 중요합니다. 예를 들어 클라이언트 애플리케이션이 시작되거나 서버와의 연결이 끊기고 클러스터 검색을 수행해야 하는 경우, 일반적인 실수 중 하나는 클라이언트 애플리케이션이 재시도 시 지수 백오프를 추가하지 않고 여러 번 재연결 및 검색 요청을 실행하는 것입니다. 이로 인해 CPU 활용률이 100%인 상태에서 Valkey 또는 Redis OSS 서버가 장시간 응답하지 않을 수 있습니다. 각 CLUSTER SLOT 명령이 클러스터 버스의 많은 노드를 처리해야 하는 경우 중단 시간이 길어집니다. Python(redis-py-cluster) 및 Java(Lettuce 및 Redisson) 등 여러 다양한 언어에서 이러한 동작으로 인해 과거에 여러 번 클라이언트가 중단되는 경우가 있었습니다.
서버리스 캐시의 경우, 알려진 클러스터 토폴로지가 정적이고 쓰기 엔드포인트와 읽기 엔드포인트의 두 항목으로 구성되어 있으므로 많은 문제가 자동으로 완화됩니다. 또한 캐시 엔드포인트를 사용하면 클러스터 검색이 여러 노드에 자동으로 분산됩니다. 하지만 여전히 다음 권장 사항을 따르는 것이 좋습니다.
연결 및 검색 요청의 갑작스러운 유입으로 인한 영향을 완화하려면 다음 내용을 따르세요.
+ 제한된 크기의 클라이언트 연결 풀을 구현하여 클라이언트 애플리케이션에서 동시에 들어오는 연결 수를 제한합니다.
+ 제한 시간 초과로 인해 서버에서 클라이언트 연결이 끊어지면 지터가 있는 지수 백오프를 사용하여 다시 시도합니다. 이렇게 하면 여러 클라이언트가 동시에 서버에 과부하를 가하지 않도록 할 수 있습니다.
+ [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md) 섹션의 가이드를 사용하여 클러스터 검색을 수행할 클러스터 엔드포인트를 확인합니다. 이렇게 하면 클러스터에서 몇 개의 하드코딩된 시드 노드에 도달하지 않고 클러스터의 모든 노드(최대 90개)에 검색 부하를 분산할 수 있습니다.
다음은 redis-py, PHPRedis 및 Lettuce의 지수 백오프 재시도 로직에 대한 몇 가지 코드 예제입니다.
**백오프 로직 샘플 1: redis-py**
redis-py에는 실패하자마자 한 번 재시도하는 재시도 메커니즘이 내장되어 있습니다. 이 메커니즘은 [Redis OSS](https://redis.readthedocs.io/en/stable/examples/connection_examples.html#redis.Redis) 객체를 생성할 때 제공된 `retry_on_timeout` 인수를 통해 활성화할 수 있습니다. 여기서는 지수 백오프와 지터를 사용하는 사용자 지정 재시도 메커니즘을 보여 줍니다. [redis-py(\$11494)](https://github.com/andymccurdy/redis-py/pull/1494)에서 기본적으로 지수 백오프를 구현하기 위한 풀 요청이 제출된 상태입니다. 향후에는 수동으로 구현할 필요가 없을 수도 있습니다.
```
def run_with_backoff(function, retries=5):
base_backoff = 0.1 # base 100ms backoff
max_backoff = 10 # sleep for maximum 10 seconds
tries = 0
while True:
try:
return function()
except (ConnectionError, TimeoutError):
if tries >= retries:
raise
backoff = min(max_backoff, base_backoff * (pow(2, tries) + random.random()))
print(f"sleeping for {backoff:.2f}s")
sleep(backoff)
tries += 1
```
그런 다음, 다음 코드를 사용하여 값을 설정할 수 있습니다.
```
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
res = run_with_backoff(lambda: client.set("key", "value"))
print(res)
```
워크로드에 따라 지연 시간에 민감한 워크로드의 기본 백오프 값을 1초에서 수십 또는 수백 밀리초로 변경하는 것을 고려할 수 있습니다.
**백오프 로직 샘플 2: PHPRedis**
PHPRedis에는 최대 10번(구성 불가능) 재시도하는 재시도 메커니즘이 내장되어 있습니다. 시도 사이에는 지연을 구성할 수 있습니다(두 번째 재시도부터 지터 사용). 자세한 내용은 다음 [샘플 예제](https://github.com/phpredis/phpredis/blob/b0b9dd78ef7c15af936144c1b17df1a9273d72ab/library.c#L335-L368)를 참조하세요. [PHPredis(\$11986)](https://github.com/phpredis/phpredis/pull/1986)에서 기본적으로 지수 백오프를 구현하기 위한 풀 요청이 제출된 상태이며, 해당 풀 요청은 병합 후 [기록](https://github.com/phpredis/phpredis/blob/develop/README.md#retry-and-backoff)되어 있습니다. PHPRedis의 최신 릴리스를 사용하는 사용자의 경우 수동으로 구현할 필요는 없지만 이전 버전을 사용하는 사용자를 위해 여기에 참조를 포함했습니다. 다음은 현재 재시도 메커니즘의 지연을 구성하는 코드 예제입니다.
```
$timeout = 0.1; // 100 millisecond connection timeout
$retry_interval = 100; // 100 millisecond retry interval
$client = new Redis();
if($client->pconnect($HOST, $PORT, $timeout, NULL, $retry_interval) != TRUE) {
return; // ERROR: connection failed
}
$client->set($key, $value);
```
**백오프 로직 샘플 3: Lettuce**
Lettuce에는 [지수 백오프 및 Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) 관련 게시물에 명시된 지수 백오프 전략을 기반으로 하는 재시도 메커니즘이 내장되어 있습니다. 다음은 코드 발췌문은 전체적인 지터의 접근 방식을 보여 줍니다.
```
public static void main(String[] args)
{
ClientResources resources = null;
RedisClient client = null;
try {
resources = DefaultClientResources.builder()
.reconnectDelay(Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(5), // maximum 5 second delay
100, TimeUnit.MILLISECONDS) // 100 millisecond base
).build();
client = RedisClient.create(resources, RedisURI.create(HOST, PORT));
client.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofMillis(100)).build()) // 100 millisecond connection timeout
.timeoutOptions(TimeoutOptions.builder().fixedTimeout(Duration.ofSeconds(5)).build()) // 5 second command timeout
.build());
// use the connection pool from above example
} finally {
if (connection != null) {
connection.close();
}
if (client != null){
client.shutdown();
}
if (resources != null){
resources.shutdown();
}
}
}
```
# 클라이언트 측 제한 시간 구성(Valkey 및 Redis OSS)
**클라이언트 측 제한 시간 구성**
서버가 요청을 처리하고 응답을 생성하는 데 충분한 시간을 할애할 수 있도록 클라이언트 측 제한 시간을 적절하게 구성합니다. 또한 서버와의 연결을 설정할 수 없는 경우 빠른 실패로 이어질 수 있습니다. 특정 Valkey 또는 Redis OSS 명령은 다른 명령보다 계산 비용이 더 많이 들 수 있습니다. 세부적으로 실행해야 하는 여러 명령이 포함된 Lua 스크립트 또는 MULTI/EXEC 트랜잭션을 예로 들 수 있습니다. 일반적으로 서버로부터 응답을 받기 전에 클라이언트 제한 시간이 초과되지 않도록 하려면 다음을 포함하여 클라이언트 측 제한 시간을 높게 설정하는 것이 좋습니다.
+ 여러 키에서 명령 실행
+ 여러 개별 Valkey 또는 Redis OSS 명령으로 구성된 MULTI/EXEC 트랜잭션 또는 Lua 스크립트 실행
+ 큰 값 읽기
+ 차단 작업 수행(예: BLPOP)
BLPOP 등 차단 작업의 경우 모범 사례는 명령 제한 시간을 소켓 제한 시간보다 낮은 숫자로 설정하는 것입니다.
다음은 redis-py, PHPRedis 및 Lettuce에서 클라이언트 측 제한 시간을 구현하는 코드 예제입니다.
**제한 시간 구성 샘플 1: redis-py**
다음은 redis-py를 사용한 코드 예제입니다.
```
# connect to Redis server with a 100 millisecond timeout
# give every Redis command a 2 second timeout
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10,socket_connect_timeout=0.1,socket_timeout=2))
res = client.set("key", "value") # will timeout after 2 seconds
print(res) # if there is a connection error
res = client.blpop("list", timeout=1) # will timeout after 1 second
# less than the 2 second socket timeout
print(res)
```
**제한 시간 구성 샘플 2: PHPRedis**
다음은 PHPRedis를 사용한 코드 예제입니다.
```
// connect to Redis server with a 100ms timeout
// give every Redis command a 2s timeout
$client = new Redis();
$timeout = 0.1; // 100 millisecond connection timeout
$retry_interval = 100; // 100 millisecond retry interval
$client = new Redis();
if($client->pconnect($HOST, $PORT, 0.1, NULL, 100, $read_timeout=2) != TRUE){
return; // ERROR: connection failed
}
$client->set($key, $value);
$res = $client->set("key", "value"); // will timeout after 2 seconds
print "$res\n"; // if there is a connection error
$res = $client->blpop("list", 1); // will timeout after 1 second
print "$res\n"; // less than the 2 second socket timeout
```
**제한 시간 구성 샘플 3: Lettuce**
다음은 Lettuce를 사용한 코드 예제입니다.
```
// connect to Redis server and give every command a 2 second timeout
public static void main(String[] args)
{
RedisClient client = null;
StatefulRedisConnection connection = null;
try {
client = RedisClient.create(RedisURI.create(HOST, PORT));
client.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofMillis(100)).build()) // 100 millisecond connection timeout
.timeoutOptions(TimeoutOptions.builder().fixedTimeout(Duration.ofSeconds(2)).build()) // 2 second command timeout
.build());
// use the connection pool from above example
commands.set("key", "value"); // will timeout after 2 seconds
commands.blpop(1, "list"); // BLPOP with 1 second timeout
} finally {
if (connection != null) {
connection.close();
}
if (client != null){
client.shutdown();
}
}
}
```
# 서버 측 유휴 제한 시간 구성(Valkey 및 Redis OSS)
고객 애플리케이션에 연결된 유휴 클라이언트 수가 많지만 적극적으로 명령이 전송되지 않는 경우가 있습니다. 이러한 시나리오의 경우 유휴 클라이언트 수가 많으면 65,000개의 연결이 모두 소진될 수 있습니다. 이러한 시나리오가 발생하지 않도록 하려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis)를 통해 서버의 제한 시간 설정을 적절하게 구성하세요. 이렇게 하면 서버가 유휴 클라이언트의 연결을 적극적으로 해제하여 연결 수가 증가하지 않도록 할 수 있습니다. 서버리스 캐시에서는 이 설정을 사용할 수 없습니다.
# Lua 스크립트
Valkey 또는 Redis OSS는 Lua 스크립트 실행 명령을 포함하여 200개 이상의 명령을 지원합니다. 그러나 Lua 스크립트의 경우 Valkey 또는 Redis OSS의 메모리 및 가용성에 영향을 줄 수 있는 몇 가지 문제가 있습니다.
**파라미터화되지 않은 Lua 스크립트**
각 Lua 스크립트는 실행 전에 Valkey 또는 Redis OSS 서버에 캐시됩니다. 파라미터화되지 않은 Lua 스크립트는 고유하므로 Valkey 또는 Redis OSS 서버가 많은 수의 Lua 스크립트를 저장하고 더 많은 메모리를 사용할 수 있습니다. 이를 완화하려면 모든 Lua 스크립트가 파라미터화되었는지 확인하고 필요한 경우 정기적으로 SCRIPT FLUSH를 수행하여 캐시된 Lua 스크립트를 정리합니다.
또한 키를 제공해야 합니다. KEY 파라미터의 값이 제공되지 않으면 스크립트가 실패합니다. 예를 들어 다음과 같은 경우에는 작동하지 않습니다.
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return "Hello World"' 0
(error) ERR Lua scripts without any input keys are not supported.
```
이 작업은 다음과 같이 작동합니다.
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return redis.call("get", KEYS[1])' 1 mykey-2
"myvalue-2"
```
다음 예제는 파라미터화된 스크립트를 사용하는 방법을 보여 줍니다. 먼저 3개의 캐시된 Lua 스크립트가 생성되는 파라미터화되지 않은 접근 방식의 예제가 있으며 이 방식은 권장하지 않습니다.
```
eval "return redis.call('set','key1','1')" 0
eval "return redis.call('set','key2','2')" 0
eval "return redis.call('set','key3','3')" 0
```
대신 다음 패턴을 사용하여 전달된 파라미터를 사용할 수 있는 단일 스크립트를 생성합니다.
```
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key1 1
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key2 2
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key3 3
```
**장기 실행 Lua 스크립트**
Lua 스크립트는 여러 명령을 세부적으로 실행할 수 있으므로 일반 Valkey 또는 Redis OSS 명령보다 완료하는 데 시간이 더 오래 걸릴 수 있습니다. Lua 스크립트가 읽기 전용 작업만 실행하는 경우 중간에 중지할 수 있습니다. 하지만 Lua 스크립트는 쓰기 작업을 수행하는 즉시 종료할 수 없으므로 실행을 완료해야 합니다. 장기 실행 Lua 스크립트가 변경되면 Valkey 또는 Redis OSS 서버가 오랫동안 응답하지 않을 수 있습니다. 이 문제를 완화하려면 장기 실행 Lua 스크립트를 사용하지 말고 사전 프로덕션 환경에서 스크립트를 테스트해 보세요.
**Stealth 쓰기 기능이 있는 Lua 스크립트**
Valkey 또는 Redis OSS가 `maxmemory`를 초과한 경우에도 Lua 스크립트가 Valkey 또는 Redis OSS에 새 데이터를 계속 쓸 수 있는 몇 가지 방법이 있습니다.
+ 스크립트는 Valkey 또는 Redis OSS 서버가 `maxmemory` 이하일 때 시작되며 내부에는 여러 쓰기 작업이 포함됩니다.
+ 스크립트의 첫 번째 쓰기 명령은 메모리(예: DEL)를 사용하지 않고, 이어서 메모리를 사용하는 쓰기 작업이 늘어납니다.
+ `noeviction`이 아닌 Valkey 또는 Redis OSS 서버에서 적절한 제거 정책을 구성하여 이 문제를 완화할 수 있습니다. 이렇게 하면 Redis OSS는 항목을 제거하고 Lua 스크립트 간에 메모리를 정리할 수 있습니다.
# 대규모 복합 항목 저장(Valkey 및 Redis OSS)
애플리케이션이 Valkey 또는 Redis OSS에 대규모 복합 항목을 저장하는 경우가 있습니다(예: 다중 GB 해시 데이터세트). 이렇게 하면 빈번하게 Valkey 또는 Redis OSS에서 성능 문제가 발생하므로 권장하지는 않습니다. 예를 들어 클라이언트는 HGETALL 명령을 사용하여 전체 다중 GB 해시 컬렉션을 검색할 수 있습니다. 이로 인해 클라이언트 출력 버퍼의 대규모 항목을 버퍼링하는 Valkey 또는 Redis OSS 서버에 상당한 메모리 부하가 발생할 수 있습니다. 또한 클러스터 모드의 슬롯 마이그레이션의 경우, ElastiCache는 직렬화 크기가 256MB보다 큰 항목이 포함된 슬롯은 마이그레이션하지 않습니다.
대규모 항목 문제를 해결하기 위한 권장 사항은 다음과 같습니다.
+ 대규모 복합 항목을 여러 개의 작은 항목으로 나눕니다. 예를 들어 항목 컬렉션을 식별하기 위해 키 이름에 공통 접두사를 사용하는 등 컬렉션을 적절하게 반영하는 키 이름 스키마를 사용하여 대규모 해시 컬렉션을 개별 키-값 필드로 나눕니다. 동일한 컬렉션의 여러 필드에 세부적으로 액세스해야 하는 경우 MGET 명령을 사용하여 동일한 명령에서 여러 키-값을 검색할 수 있습니다.
+ 모든 옵션을 평가했는데도 여전히 대규모 컬렉션 데이터 세트를 분리할 수 없으면 전체 컬렉션 대신 컬렉션의 데이터 하위 집합에서 작동하는 명령어를 사용해 보세요. 동일한 명령어로 전체 다중 GB 컬렉션을 세부적으로 검색해야 하는 사용 사례는 피하도록 합니다. 일례로 해시 컬렉션에서 HGETALL 대신 HGET 또는 HMGET 명령을 사용합니다.
# Lettuce 클라이언트 구성(Valkey 및 Redis OSS)
이 섹션에서는 권장되는 Java 및 Lettuce 구성 옵션과 이러한 옵션을 ElastiCache 클러스터에 적용하는 방법을 설명합니다.
이 섹션의 권장 사항은 Lettuce 버전 6.2.2에서 테스트되었습니다.
**Topics**
+ [예: 클러스터 모드에 대한 Lettuce 구성, TLS 활성화됨](BestPractices.Clients-lettuce-cme.md)
+ [예: 클러스터 모드에 대한 Lettuce 구성 비활성화됨, TLS 활성화됨](BestPractices.Clients-lettuce-cmd.md)
**Java DNS 캐시 TTL**
Java 가상 머신(JVM)은 DNS 이름 조회를 캐시합니다. JVM은 호스트 이름을 IP 주소로 확인하는 경우 *Time-To-Live*(TTL)라고 하는 지정된 기간 동안 IP 주소를 캐시합니다.
TTL 값을 선택할 때는 지연 시간과 변경 사항에 대한 응답성 사이에서 절충해야 합니다. TTL이 짧을수록 DNS 해석기가 클러스터의 DNS에서 업데이트를 더 빨리 알아차릴 수 있습니다. 이렇게 하면 클러스터가 수행하는 교체 또는 기타 워크플로에 애플리케이션이 더 빠르게 응답할 수 있습니다. 그러나 TTL이 너무 낮으면 쿼리 볼륨이 증가하여 애플리케이션의 지연 시간이 늘어날 수 있습니다. TTL 값에 정답은 없지만 TTL 값을 설정할 때는 변경 사항이 적용될 때까지 기다릴 수 있는 시간을 고려하는 것이 좋습니다.
ElastiCache 노드는 변경될 수 있는 DNS 이름 항목을 사용하므로 TTL 값을 5\$110초로 짧게 설정하여 JVM을 구성하는 것이 좋습니다. 이렇게 하면 노드의 IP 주소가 변경될 때 애플리케이션이 DNS 항목을 다시 쿼리하여 리소스의 새 IP 주소를 수신하고 사용할 수 있습니다.
일부 Java 구성에서는 JVM이 다시 시작될 때까지 DNS 항목을 새로 고치지 않도록 JVM 기본 TTL이 설정되기도 합니다.
JVM TTL을 설정하는 방법에 대한 자세한 내용은 [JVM TTL을 설정하는 방법](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html#how-to-set-the-jvm-ttl)을 참조하세요.
**Lettuce 버전**
Lettuce 버전 6.2.2 이상을 사용하는 것이 좋습니다.
**Endpoints**.
클러스터 모드가 활성화된 클러스터를 사용하는 경우 `redisUri`를 클러스터 구성 엔드포인트로 설정합니다. 이 URI에 대한 DNS 조회는 클러스터에서 사용 가능한 모든 노드 목록을 반환하며 클러스터 초기화 중에 해당 노드 중 하나로 무작위로 확인됩니다. 토폴로지 새로 고침의 작동 방식에 대한 자세한 내용은 이 항목 뒷부분의 *dynamicRefreshResources*를 참조하세요.
**SocketOption**
[KeepAlive](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.KeepAliveOptions.html)를 활성화합니다. 이 옵션을 활성화하면 명령 런타임 중에 실패한 연결을 처리할 필요가 줄어듭니다.
애플리케이션 요구 사항 및 워크로드에 따라 [연결 제한 시간](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.Builder.html#connectTimeout-java.time.Duration-)을 설정해야 합니다. 자세한 내용은 이 주제의 후반부에서 연결 제한 섹션을 참조하세요.
**ClusterClientOption: 클러스터 모드가 활성화된 클라이언트 옵션**
연결이 끊어지면 [AutoReconnect](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#autoReconnect-boolean-)를 활성화합니다.
[CommandTimeout](https://lettuce.io/core/release/api/io/lettuPrce/core/RedisURI.html#getTimeout--)을 설정합니다. 자세한 내용은 이 주제의 후반부에서 연결 제한 섹션을 참조하세요.
토폴로지에서 장애가 발생한 노드를 필터링하도록 [nodeFilter](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#nodeFilter-java.util.function.Predicate-)를 설정합니다. Lettuce는 '클러스터 노드' 출력에 있는 모든 노드(PFAIL/FAIL 상태의 노드 포함)를 클라이언트의 '파티션'(샤드라고도 함)에 저장합니다. 클러스터 토폴로지를 생성하는 동안 모든 파티션 노드에 연결을 시도합니다. 장애가 발생한 노드를 추가하는 이러한 Lettuce 동작은 어떤 이유로든 노드를 교체할 때 연결 오류(또는 경고)를 유발할 수 있습니다.
예를 들어 장애 조치가 완료되고 클러스터가 복구 프로세스를 시작한 후 clusterTopology가 새로 고쳐지는 동안 다운 노드가 토폴로지에서 완전히 제거되기 전에 클러스터 버스 노드 맵에 잠시 FAIL 노드로 나열됩니다. 이 기간 동안 Lettuce 클라이언트는 이 노드를 정상 노드로 간주하고 지속적으로 연결합니다. 이로 인해 재시도가 모두 끝난 후 오류가 발생합니다.
예:
```
final ClusterClientOptions clusterClientOptions =
ClusterClientOptions.builder()
... // other options
.nodeFilter(it ->
! (it.is(RedisClusterNode.NodeFlag.FAIL)
|| it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL)
|| it.is(RedisClusterNode.NodeFlag.HANDSHAKE)
|| it.is(RedisClusterNode.NodeFlag.NOADDR)))
.validateClusterNodeMembership(false)
.build();
redisClusterClient.setOptions(clusterClientOptions);
```
**참고**
노드 필터링은 DynamicRefreshSources를 참으로 설정한 상태에서 사용하는 것이 가장 좋습니다. 그러지 않으면 문제가 있는 단일 시드 노드에서 토폴로지 보기를 가져와서 일부 샤드의 프라이머리 노드에 장애가 있는 것으로 간주하면 이 프라이머리 노드가 필터링되어 슬롯이 포함되지 않습니다. 여러 시드 노드가 있으면(DynamicRefreshSources가 참인 경우) 이 문제가 발생할 가능성이 줄어듭니다. 새로 승격된 프라이머리 노드로 장애 조치 후 적어도 일부 시드 노드에 업데이트된 토폴로지 보기가 있을 것이기 때문입니다.
**ClusterTopologyRefreshOptions: 클러스터 모드가 활성화된 클라이언트의 클러스터 토폴로지 새로 고침을 제어하는 옵션**
**참고**
클러스터 모드가 비활성화된 클러스터는 클러스터 검색 명령을 지원하지 않으며 모든 클라이언트 동적 토폴로지 검색 기능과 호환되지 않습니다.
ElastiCache 사용이 비활성화된 클러스터 모드는 Lettuce의 `MasterSlaveTopologyRefresh`와 호환되지 않습니다. 대신, 비활성화된 클러스터 모드에는 `StaticMasterReplicaTopologyProvider`를 구성하여 클러스터 읽기 및 쓰기 엔드포인트를 제공할 수 있습니다.
클러스터 모드 비활성화 클러스터 연결에 대한 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 엔드포인트 찾기(콘솔)](Endpoints.md#Endpoints.Find.Redis)를 참조하십시오.
Lettuce의 동적 토폴로지 검색 기능을 사용하려면 클러스터 모드 활성화 클러스터를 만들고 기존 클러스터와 샤드 구성을 동일하게 해야 합니다. 하지만 클러스터 모드 활성화 클러스터에는 최소 3개의 샤드와 1개 이상의 복제본을 구성하는 것을 권장하며, 이렇게 해야 빠른 장애 조치를 지원할 수 있습니다.
[enablePeriodicRefresh](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enablePeriodicRefresh-java.time.Duration-)를 활성화합니다. 이렇게 하면 클라이언트가 refreshPeriod 간격(기본값: 60초)에 따라 클러스터 토폴로지를 업데이트할 수 있도록 클러스터 토폴로지를 정기적으로 업데이트할 수 있습니다. 비활성화된 경우 클라이언트는 클러스터에 대해 명령을 실행하려고 할 때 오류가 발생한 경우에만 클러스터 토폴로지를 업데이트합니다.
이 옵션을 활성화하면 이 작업을 백그라운드 작업에 추가하여 클러스터 토폴로지 새로 고침과 관련된 지연 시간을 줄일 수 있습니다. 토폴로지 새로 고침은 백그라운드 작업에서 수행되지만 노드가 많은 클러스터의 경우 다소 느릴 수 있습니다. 이는 가장 업데이트된 클러스터 보기를 얻기 위해 모든 노드에 보기를 쿼리하기 때문입니다. 대규모 클러스터를 실행하는 경우 기간을 늘리는 것이 좋습니다.
[enableAllAdaptiveRefreshTriggers](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enableAllAdaptiveRefreshTriggers--)를 활성화합니다. 이렇게 하면 MOVED\$1REDIRECT, ASK\$1REDIRECT, PERSISTENT\$1RECONNECTS, UNCOVERED\$1SLOT, UNKNOWN\$1NODE와 같은 모든 [트리거](https://lettuce.io/core/6.1.6.RELEASE/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.RefreshTrigger.html)를 사용하는 적응형 토폴로지 새로 고침이 가능합니다. 적응형 새로 고침 트리거는 Valkey 또는 Redis OSS 클러스터 작업 중에 발생하는 이벤트를 기반으로 토폴로지 보기 업데이트를 시작합니다. 이 옵션을 활성화하면 위 트리거 중 하나가 발생할 때 즉시 토폴로지가 새로 고쳐집니다. 이벤트가 대규모로 발생할 수 있으므로 적응형 트리거 새로 고침은 제한 시간을 사용하여 속도를 제한합니다(업데이트 간 기본 제한 시간: 30).
[closeStaleConnections](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#closeStaleConnections-boolean-)를 활성화합니다. 이렇게 하면 클러스터 토폴로지를 새로 고칠 때 오래된 연결을 닫을 수 있습니다. [ClusterTopologyRefreshOptions.isPeriodicRefreshEnabled()](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.html#isPeriodicRefreshEnabled--)가 참인 경우에만 적용됩니다. 활성화되면 클라이언트는 오래된 연결을 닫고 백그라운드에서 새 연결을 만들 수 있습니다. 그러면 명령 런타임 중에 실패한 연결을 처리할 필요가 줄어듭니다.
[dynamicRefreshResources](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#dynamicRefreshSources-boolean-)를 활성화합니다. 소규모 클러스터에서는 dynamicRefreshResources를 활성화하고 대규모 클러스터에서는 비활성화하는 것이 좋습니다. dynamicRefreshResources를 활성화하면 제공된 시드 노드(예: 클러스터 구성 엔드포인트)에서 클러스터 노드를 검색할 수 있습니다. 검색된 모든 노드를 소스로 사용하여 클러스터 토폴로지를 새로 고칩니다.
동적 새로 고침을 사용하면 클러스터 토폴로지에 대해 검색된 모든 노드를 쿼리하고 가장 정확한 클러스터 보기를 선택하려고 시도합니다. 거짓으로 설정하면 초기 시드 노드만 토폴로지 검색의 소스로 사용되고 초기 시드 노드에 대한 클라이언트 수만 가져옵니다. 비활성화된 경우 클러스터 구성 엔드포인트가 장애가 발생한 노드로 확인되면 클러스터 보기를 새로 고치려는 시도가 실패하고 예외가 발생합니다. 이 시나리오는 장애가 발생한 노드의 항목이 클러스터 구성 엔드포인트에서 제거될 때까지 어느 정도 시간이 걸리기 때문에 발생할 수 있습니다. 따라서 구성 엔드포인트는 여전히 짧은 시간 동안 장애가 발생한 노드로 무작위로 확인될 수 있습니다.
하지만 활성화되면 클러스터 보기에서 수신한 모든 클러스터 노드를 사용하여 현재 보기를 쿼리합니다. 해당 보기에서 장애가 발생한 노드를 필터링하므로 토폴로지 새로 고침이 성공적으로 이루어집니다. 그러나 dynamicRefreshSources가 참인 경우 Lettuce는 모든 노드를 쿼리하여 클러스터 보기를 가져온 다음, 결과를 비교합니다. 따라서 노드가 많은 클러스터의 경우 비용이 많이 들 수 있습니다. 노드가 많은 클러스터의 경우 이 기능을 끄는 것이 좋습니다.
```
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
```
**ClientResources**
[DnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#dnsResolver-io.lettuce.core.resource.DnsResolver-)를 [DirContextDnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DirContextDnsResolver.html)를 사용하여 구성합니다. DNS 해석기는 Java의 com.sun.jndi.dns.DnsContextFactory를 기반으로 합니다.
지수 백오프 및 풀 지터를 사용하여 [reconnectDelay](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#reconnectDelay-io.lettuce.core.resource.Delay-)를 구성합니다. Lettuce에는 지수 백오프 전략을 기반으로 하는 재시도 메커니즘이 내장되어 있습니다. 자세한 내용은 AWS 아키텍처 블로그의 [지수 백오프 및 지터](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter)를 참조하세요. 재시도 백오프 전략의 중요성에 대한 자세한 내용은 AWS 데이터베이스 블로그의 [모범 사례 블로그 게시물](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)에서 백오프 논리 섹션을 참조하세요.
```
ClientResources clientResources = DefaultClientResources.builder()
.dnsResolver(new DirContextDnsResolver())
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100, TimeUnit.MILLISECONDS)) // 100 millisecond base
.build();
```
**제한 시간**
명령 제한 시간보다 낮은 연결 제한 시간 값을 사용합니다. Lettuce는 지연 연결 설정을 사용합니다. 따라서 연결 제한 시간이 명령 제한 시간보다 긴 경우 Lettuce가 비정상 노드에 연결하려고 시도하고 명령 제한 시간이 항상 초과하면 토폴로지 새로 고침 후에도 오류가 계속 발생하는 기간이 있을 수 있습니다.
서로 다른 명령에 동적 명령 제한 시간을 사용합니다. 명령에 기대되는 기간에 따라 명령 제한 시간을 설정하는 것이 좋습니다. 예를 들어 FLUSHDB, FLUSHALL, KEYS, SMEMBERS 또는 Lua 스크립트와 같은 여러 키를 반복하는 명령에는 더 긴 제한 시간을 사용하세요. SET, GET 및 HSET과 같은 단일 키 명령에는 더 짧은 제한 시간을 사용합니다.
**참고**
다음 예시에서 구성된 제한 시간은 최대 20바이트 길이의 키와 값으로 SET/GET 명령을 실행한 테스트용입니다. 명령이 복잡하거나 키와 값이 크면 처리 시간이 더 오래 걸릴 수 있습니다. 애플리케이션의 사용 사례에 따라 제한 시간을 설정해야 합니다.
```
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
SocketOptions socketOptions = SocketOptions.builder()
.connectTimeout(CONNECT_TIMEOUT)
.build();
class DynamicClusterTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.CLUSTER)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration defaultCommandTimeout;
private final Duration metaCommandTimeout;
DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(
new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
```
# 예: 클러스터 모드에 대한 Lettuce 구성, TLS 활성화됨
**참고**
다음 예시의 제한 시간은 최대 20바이트 길이의 키와 값으로 SET/GET 명령을 실행한 테스트용입니다. 명령이 복잡하거나 키와 값이 크면 처리 시간이 더 오래 걸릴 수 있습니다. 애플리케이션의 사용 사례에 따라 제한 시간을 설정해야 합니다.
```
// Set DNS cache TTL
public void setJVMProperties() {
java.security.Security.setProperty("networkaddress.cache.ttl", "10");
}
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
// Create RedisURI from the cluster configuration endpoint
clusterConfigurationEndpoint = // TODO: add your cluster configuration endpoint
final RedisURI redisUriCluster =
RedisURI.Builder.redis(clusterConfigurationEndpoint)
.withPort(6379)
.withSsl(true)
.build();
// Configure the client's resources
ClientResources clientResources = DefaultClientResources.builder()
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100, TimeUnit.MILLISECONDS)) // 100 millisecond base
.dnsResolver(new DirContextDnsResolver())
.build();
// Create a cluster client instance with the URI and resources
RedisClusterClient redisClusterClient =
RedisClusterClient.create(clientResources, redisUriCluster);
// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
class DynamicClusterTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.CLUSTER)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration metaCommandTimeout;
private final Duration defaultCommandTimeout;
DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
// Configure the topology refreshment options
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
// Configure the socket options
final SocketOptions socketOptions =
SocketOptions.builder()
.connectTimeout(CONNECT_TIMEOUT)
.keepAlive(true)
.build();
// Configure the client's options
final ClusterClientOptions clusterClientOptions =
ClusterClientOptions.builder()
.topologyRefreshOptions(topologyOptions)
.socketOptions(socketOptions)
.autoReconnect(true)
.timeoutOptions(timeoutOptions)
.nodeFilter(it ->
! (it.is(RedisClusterNode.NodeFlag.FAIL)
|| it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL)
|| it.is(RedisClusterNode.NodeFlag.NOADDR)))
.validateClusterNodeMembership(false)
.build();
redisClusterClient.setOptions(clusterClientOptions);
// Get a connection
final StatefulRedisClusterConnection connection =
redisClusterClient.connect();
// Get cluster sync/async commands
RedisAdvancedClusterCommands sync = connection.sync();
RedisAdvancedClusterAsyncCommands async = connection.async();
```
# 예: 클러스터 모드에 대한 Lettuce 구성 비활성화됨, TLS 활성화됨
**참고**
다음 예시의 제한 시간은 최대 20바이트 길이의 키와 값으로 SET/GET 명령을 실행한 테스트용입니다. 명령이 복잡하거나 키와 값이 크면 처리 시간이 더 오래 걸릴 수 있습니다. 애플리케이션의 사용 사례에 따라 제한 시간을 설정해야 합니다.
```
// Set DNS cache TTL
public void setJVMProperties() {
java.security.Security.setProperty("networkaddress.cache.ttl", "10");
}
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
// Create RedisURI from the primary/reader endpoint
clusterEndpoint = // TODO: add your node endpoint
RedisURI redisUriStandalone =
RedisURI.Builder.redis(clusterEndpoint).withPort(6379).withSsl(true).withDatabase(0).build();
ClientResources clientResources =
DefaultClientResources.builder()
.dnsResolver(new DirContextDnsResolver())
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100,
TimeUnit.MILLISECONDS)) // 100 millisecond base
.build();
// Use a dynamic timeout for commands, to avoid timeouts during
// slow operations.
class DynamicTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration metaCommandTimeout;
private final Duration defaultCommandTimeout;
DynamicTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(new DynamicTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
final SocketOptions socketOptions =
SocketOptions.builder().connectTimeout(CONNECT_TIMEOUT).keepAlive(true).build();
ClientOptions clientOptions =
ClientOptions.builder().timeoutOptions(timeoutOptions).socketOptions(socketOptions).build();
RedisClient redisClient = RedisClient.create(clientResources, redisUriStandalone);
redisClient.setOptions(clientOptions);
```
## 듀얼 스택 클러스터에 선호되는 프로토콜 구성(Valkey 및 Redis OSS)
클러스터 모드가 활성화된 Valkey 또는 Redis OSS 클러스터의 경우, 클라이언트가 클러스터 내 노드에 연결하는 데 사용할 프로토콜을 IP Discovery 파라미터로 제어할 수 있습니다. IP Discovery 파라미터는 IPv4 또는 IPv6로 설정할 수 있습니다.
Valkey 또는 Redis OSS 클러스터의 경우, IP Discovery 파라미터가 [cluster slots ()](https://valkey.io/commands/cluster-slots/), [cluster shards ()](https://valkey.io/commands/cluster-shards/), [cluster nodes ()](https://valkey.io/commands/cluster-nodes/) 출력에 사용되는 IP 프로토콜을 설정합니다. 이러한 명령은 클라이언트가 클러스터 토폴로지를 검색하는 데 사용됩니다. 클라이언트는 이들 명령 내의 IP를 사용하여 클러스터 내 다른 노드에 연결합니다.
IP Discovery를 변경해도 연결된 클라이언트는 가동 중지되지 않습니다. 하지만 변경 사항이 전파되려면 다소 시간이 소요됩니다. Valkey 또는 Redis OSS 클러스터에 변경 사항이 완전히 전파된 시점을 확인하려면 `cluster slots`의 출력을 모니터링하면 됩니다. 클러스터 슬롯 명령에서 반환된 모든 노드가 새 프로토콜이 있는 IP를 보고하면, 변경 사항이 완전히 전파된 것입니다.
Redis-Py 사용 예제:
```
cluster = RedisCluster(host="xxxx", port=6379)
target_type = IPv6Address # Or IPv4Address if changing to IPv4
nodes = set()
while len(nodes) == 0 or not all((type(ip_address(host)) is target_type) for host in nodes):
nodes = set()
# This refreshes the cluster topology and will discovery any node updates.
# Under the hood it calls cluster slots
cluster.nodes_manager.initialize()
for node in cluster.get_nodes():
nodes.add(node.host)
self.logger.info(nodes)
time.sleep(1)
```
Lettuce 사용 예제:
```
RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create("xxxx", 6379));
Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4
Set nodes;
do {
// Check for any changes in the cluster topology.
// Under the hood this calls cluster slots
clusterClient.refreshPartitions();
Set nodes = new HashSet<>();
for (RedisClusterNode node : clusterClient.getPartitions().getPartitions()) {
nodes.add(node.getUri().getHost());
}
Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
try {
return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
} catch (UnknownHostException ignored) {}
return false;
}));
```
# 클라이언트 모범 사례(Memcached)
ElastiCache for Memcached 클러스터를 사용한 일반적인 시나리오의 모범 사례를 알아봅니다.
**Topics**
+ [효율적인 로드 밸런싱을 위해 ElastiCache 클라이언트 구성(Memcached)](BestPractices.LoadBalancing.md)
+ [Memcached를 사용하여 검증된 클라이언트](network-type-validated-clients-memcached.md)
+ [듀얼 스택 클러스터에 선호되는 프로토콜 구성(Memcached)](network-type-configuring-dual-stack-memcached.md)
# 효율적인 로드 밸런싱을 위해 ElastiCache 클라이언트 구성(Memcached)
**참고**
이 섹션의 내용은 노드 기반 다중 노드 Memcached 클러스터에 적용됩니다.
여러 ElastiCache Memcached 노드를 효과적으로 사용하려면 캐시 키를 노드에 분산시킬 수 있어야 합니다. *n* 노드 사용 클러스터를 로드 밸런스하는 간단한 방법은 객체 키의 해시를 계산하고 *n*: `hash(key) mod n`으로 결과를 모드하는 것입니다. 결과 값(0\$1*n*–1)은 객체가 배치되는 노드의 수입니다.
노드 수(*n*)가 일정하면 이 방법이 간편하고 효과적입니다. 하지만 클러스터에서 노드를 추가하거나 제거할 때마다 이동할 키의 수는 *(n - 1) / n*입니다. 여기서 *n*은 새로운 노드 수입니다. 따라서 이 방법을 사용하면 많은 키가 이동하며 특히 노드 수가 커질수록 다량의 초기 캐시가 누락됩니다. 1개에서 2개로 노드를 조정하면 이동할 키는 (2-1)/2(50%)가 되는 것이 모범 사례입니다. 9개에서 10개로 노드를 조정하면 이동할 키는 (10-1)/10(90%)가 됩니다. 트래픽의 스파이크로 인해 확장하는 경우 캐시가 대량으로 누락되는 상황을 방지할 필요가 없습니다. 캐시가 대량으로 누락되면 데이터베이스에 대한 히트가 발생하지만 이미 트래픽의 스파이크로 인해 오버로드되어 있습니다.
이 문제의 해결 방법은 일관적 해싱입니다. 일관적 해싱에는 클러스터에서 노드가 추가되거나 제거될 때마다 이동할 키의 수가 대략 *1/n*(여기서 *n*은 새로운 노드 수)인 알고리즘이 사용됩니다. 1개에서 2개로 노드를 조정하면 이동할 키는 1/2(50%)이 되는 것이 최악의 경우입니다. 9개에서 10개로 노드를 조정하면 이동할 키는 1/10(10%)가 됩니다.
사용자는 다중 노드 클러스터에 사용되는 해시 알고리즘을 제어합니다. 일관적 해싱을 사용하도록 클라이언트를 구성하는 것이 좋습니다. 일관적 해싱을 구현하는 데 자주 사용되는 언어로 여러 Memcached 클라이언트 라이브러리가 제공됩니다. 사용할 라이브러리의 설명서에서 일관적 해싱 지원 여부와 그 구현 방법을 참조하세요.
Java, PHP 또는 .NET으로 작업하는 경우 Amazon ElastiCache 클라이언트 라이브러리 중 하나를 사용하는 것이 좋습니다.
## Java를 사용한 일관적 해싱
ElastiCache Memcached Java 클라이언트는 일관적 해싱 기능이 내장된 오픈 소스 spymemcached Java 클라이언트를 기반으로 합니다. 일관적 해싱을 구현하는 KetamaConnectionFactory 클래스가 라이브러리에 포함되어 있습니다. 기본적으로 spymemcached에서는 일관적 해싱이 해제됩니다.
자세한 내용은 [KetamaConnectionFactory](https://github.com/RTBHOUSE/spymemcached/blob/master/src/main/java/net/spy/memcached/KetamaConnectionFactory.java)에서 KetamaConnectionFactory 설명서를 참조하세요.
## Memcached와 함께 PHP를 사용한 일관된 해싱
ElastiCache Memcached PHP 클라이언트는 기본 제공 Memcached PHP 라이브러리 주변의 래퍼입니다. 기본적으로 Memcached PHP 라이브러리에서는 일관적 해싱이 해제됩니다.
다음 코드를 사용하여 일관적 해싱을 설정하세요.
```
$m = new Memcached();
$m->setOption(Memcached::OPT_DISTRIBUTION, Memcached::DISTRIBUTION_CONSISTENT);
```
또한 php.ini 파일에서 `memcached.sess_consistent_hash`를 설정할 수도 있습니다.
자세한 내용은 [http://php.net/manual/en/memcached.configuration.php](http://php.net/manual/en/memcached.configuration.php)에서 Memcached PHP의 런타임 구성 설명서를 참조하세요. 특히 `memcached.sess_consistent_hash` 파라미터에 유의하시기 바랍니다.
## Memcached와 함께 .NET을 사용한 일관된 해싱
ElastiCache Memcached .NET 클라이언트는 Enyim Memcached 주변의 래퍼입니다. 기본적으로 Enyim Memcached 클라이언트에서는 일관적 해싱이 설정됩니다.
자세한 내용은 [https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration\$1user-content-memcachedlocator](https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration#user-content-memcachedlocator)에 있는 `memcached/locator` 설명서를 참조하세요.
# Memcached를 사용하여 검증된 클라이언트
다음 클라이언트는 Memcached에 대해 지원되는 모든 네트워크 유형 구성에서 작동한다고 특별 검증되었습니다.
검증된 클라이언트:
+ [AWS ElastiCache Cluster Client Memcached for Php](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php) – [버전 \$13.6.2](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php/tree/v3.2.0)
+ [AWS ElastiCache Cluster Client Memcached for Java](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-java) – Github상 최신 마스터
# 듀얼 스택 클러스터에 선호되는 프로토콜 구성(Memcached)
Memcached 클러스터의 경우, 클라이언트가 클러스터 내 노드에 연결하는 데 사용할 프로토콜을 IP Discovery 파라미터로 제어할 수 있습니다. IP Discovery 파라미터는 IPv4 또는 IPv6로 설정할 수 있습니다.
IP Discovery 파라미터는 config get 클러스터 출력에 사용되는 IP 프로토콜을 제어합니다. 그러면 ElastiCache for Memcached 클러스터의 자동 검색을 지원하는 클라이언트가 사용하는 IP 프로토콜이 결정됩니다.
IP Discovery를 변경해도 연결된 클라이언트는 가동 중지되지 않습니다. 하지만 변경 사항이 전파되려면 다소 시간이 소요됩니다.
Java의 경우 `getAvailableNodeEndPoints` 출력을, Php의 경우 `getServerList` 출력을 모니터링합니다. 이들 함수의 출력에서, 업데이트된 프로토콜을 사용하는 클러스터 내 모든 노드에 해당하는 IP를 보고하면, 변경 사항이 완전히 전파된 것입니다.
Java 예제:
```
MemcachedClient client = new MemcachedClient(new InetSocketAddress("xxxx", 11211));
Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4
Set nodes;
do {
nodes = client.getAvailableNodeEndPoints().stream().map(NodeEndPoint::getIpAddress).collect(Collectors.toSet());
Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
try {
return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
} catch (UnknownHostException ignored) {}
return false;
}));
```
Php 예제:
```
$client = new Memcached;
$client->setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE);
$client->addServer("xxxx", 11211);
$nodes = [];
$target_ips_count = 0;
do {
# The PHP memcached client only updates the server list if the polling interval has expired and a
# command is sent
$client->get('test');
$nodes = $client->getServerList();
sleep(1);
$target_ips_count = 0;
// For IPv4 use FILTER_FLAG_IPV4
$target_ips_count = count(array_filter($nodes, function($node) { return filter_var($node["ipaddress"], FILTER_VALIDATE_IP, FILTER_FLAG_IPV6); }));
} while (count($nodes) !== $target_ips_count);
```
IP Discovery가 업데이트되기 전에 생성된 기존 클라이언트 연결은 업데이트 전의 프로토콜을 사용하여 연결됩니다. 클러스터 검색 명령의 출력에서 변경 사항이 감지되면, 검증된 모든 클라이언트가 새 IP 프로토콜을 사용하여 자동으로 클러스터에 재연결됩니다. 하지만, 클라이언트 구현에 따라 달라질 수 있습니다.
## TLS 활성화 듀얼 스택 ElastiCache 클러스터
ElastiCache 클러스터에 TLS가 활성화된 경우, 클러스터 검색 함수 (Redis용 `cluster slots`, `cluster shards` 및 `cluster nodes`) 또는 Memcached용 `config get cluster`는 IP 대신 호스트 이름을 반환합니다. IP 대신 호스트 이름을 사용하여 ElastiCache 클러스터에 연결하고 TLS 핸드셰이크를 수행합니다. 따라서 클라이언트가 IP Discovery 파라미터의 영향을 받지 않습니다. TLS 활성화 클러스터의 경우, IP Discovery 파라미터는 선호 IP 프로토콜에 영향을 끼치지 않습니다. 대신 클라이언트가 DNS 호스트 이름을 확인할 때 어떤 IP 프로토콜을 선호하는지에 따라, 사용되는 IP 프로토콜이 결정됩니다.
**Java 클라이언트**
IPv4와 IPv6를 모두 지원하는 Java 환경에서 연결할 때, Java는 기본적으로 이전 버전과의 호환성을 위해 IPv6보다 IPv4를 선호합니다. 하지만 JVM 인수를 통해 IP 프로토콜 기본 설정을 구성할 수 있습니다. IPv4를 선호하려면 JVM에 `-Djava.net.preferIPv4Stack=true`를, IPv6를 선호하려면 `-Djava.net.preferIPv6Stack=true`를 설정합니다. `-Djava.net.preferIPv4Stack=true`를 설정하면 JVM이 더 이상 IPv6 연결을 만들지 않습니다. **Valkey 또는 Redis OSS의 경우 여기에는 다른 비-Valkey 및 비-Redis OSS 애플리케이션에 대한 애플리케이션이 포함됩니다.**
**호스트 수준 기본 설정**
일반적으로 클라이언트 또는 클라이언트 런타임에 IP 프로토콜 기본 설정을 위한 구성 옵션이 제공되지 않으면, DNS 확인을 수행할 때 IP 프로토콜은 호스트의 구성을 기반으로 작동합니다. 기본적으로, 대부분의 호스트는 IPv4보다 IPv6를 선호하지만 이 기본 설정은 호스트 수준에서 구성할 수 있습니다. 이는 ElastiCache 클러스터에 대한 요청뿐만 아니라 해당 호스트로부터의 모든 DNS 요청에 영향을 끼칩니다.
**Linux 호스트**
Linux의 경우, `gai.conf` 파일을 수정하여 IP 프로토콜 기본 설정을 구성할 수 있습니다. `gai.conf` 파일은 `/etc/gai.conf`에서 찾을 수 있습니다. 지정된 `gai.conf`가 없으면 예제를 `/usr/share/doc/glibc-common-x.xx/gai.conf`에서 찾을 수 있는데, 이를 `/etc/gai.conf`에 복사하면 기본 구성의 주석을 제거할 수 있습니다. ElastiCache 클러스터에 연결할 때 IPv4를 선호하도록 구성을 업데이트하려면 해당 클러스터 IP를 포괄한 CIDR 범위의 우선 순위를 업데이트하여 기본 IPv6 연결의 우선 순위보다 높게 설정하면 됩니다. IPv6 연결의 우선 순위는 기본적으로 40입니다. 예를 들어, 클러스터가 CIDR이 172.31.0.0:0/16인 서브넷에 위치할 때는 아래 구성으로 인해 클라이언트는 해당 클러스터에 IPv4 연결을 선호하게 됩니다.
```
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label fc00::/7 6
label 2001:0::/32 7
label ::ffff:172.31.0.0/112 8
#
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
#
# precedence
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
precedence ::1/128 50
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 10
precedence ::ffff:172.31.0.0/112 100
```
`gai.conf`에 대한 자세한 내용은 [Linux 기본 페이지](https://man7.org/linux/man-pages/man5/gai.conf.5.html)에서 확인할 수 있습니다.
**Windows 호스트**
Windows 호스트의 프로세스도 비슷합니다. Windows 호스트의 경우, `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`을 실행할 수 있습니다. 이는 Linux 호스트에서 `gai.conf` 파일을 수정할 때와 효과가 동일합니다.
이렇게 하면, 지정된 CIDR 범위에 IPv6 연결보다 IPv4 연결을 선호하도록 기본 설정 정책이 업데이트됩니다. 예를 들어, 클러스터가 CIDR이 172.31.0.0:0/16인 서브넷에 위치할 때 `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15`를 실행하면 다음 우선 순위 테이블로 인해 클라이언트는 해당 클러스터에 IPv4 연결을 선호하게 됩니다.
```
C:\Users\Administrator>netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
100 15 ::ffff:172.31.0.0:0/112
20 4 ::ffff:0:0/96
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
```
# Valkey 및 Redis OSS에 대한 예약된 메모리 관리
예약된 메모리는 비데이터 사용을 위해 구분된 메모리입니다. 백업 또는 장애 조치를 수행할 때 클러스터의 데이터가 .rdb 파일에 작성되는 동안 Valkey 및 Redis OSS에서는 사용 가능한 메모리를 사용하여 클러스터에 쓰기 작업을 기록합니다. 모든 쓰기에 사용 가능한 메모리를 충분히 확보하지 못하면 프로세스가 실패합니다. 아래에서 ElastiCache for Redis OSS에 대한 예약된 메모리를 관리하기 위한 옵션과 이러한 옵션을 적용하는 방법에 대한 정보를 찾을 수 있습니다.
**Topics**
+ [필요한 예약된 메모리의 양](#redis-memory-management-need)
+ [예약된 메모리를 관리하기 위한 파라미터](#redis-memory-management-parameters)
+ [예약된 메모리 관리 파라미터 지정](#redis-reserved-memory-management-change)
## 필요한 예약된 메모리의 양
Redis OSS 2.8.22 이전 버전을 실행하고 있는 경우 Redis OSS 2.8.22 이후 버전을 실행하는 것보다 백업 및 장애 조치를 위해 더 많은 메모리를 예약해야 합니다. 이러한 요구 사항은 ElastiCache for Redis OSS가 백업 프로세스를 구현하는 방법이 다르기 때문입니다. 경험상, 2.8.22 이전 버전의 Redis OSS 오버헤드에 대해서는 노드 유형 `maxmemory` 값의 절반을 예약하고 Redis OSS 버전 2.8.22 이후에 대해서는 1/4을 예약합니다.
ElastiCache가 백업 및 복제 프로세스를 구현하는 방법이 다르기 때문에 일반적으로 `reserved-memory-percent` 파라미터를 사용하여 노드 유형 `maxmemory` 값의 25%를 예약하는 것이 좋습니다. 이 값은 기본값이며 대부분의 경우에 권장됩니다.
버스트 가능한 마이크로 및 작은 인스턴스 유형이 `maxmemory` 한도 근처에서 작동하는 경우 스왑 사용량이 발생할 수 있습니다. 백업, 복제 및 트래픽이 많은 동안 이러한 인스턴스 유형의 운영 안정성을 개선하려면 작은 인스턴스 유형의 경우 `reserved-memory-percent` 파라미터 값을 최대 30%, 마이크로 인스턴스 유형의 경우 최대 50% 늘리는 것이 좋습니다.
데이터 계층화가 있는 ElastiCache 클러스터에서 쓰기가 많은 워크로드의 경우 `reserved-memory-percent`를 노드 사용 가능한 메모리의 최대 50%까지 늘리는 것이 좋습니다.
자세한 내용은 다음 자료를 참조하세요.
+ [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)
+ [동기화 및 백업 구현 방법](Replication.Redis.Versions.md)
+ [ElastiCache의 데이터 계층화](data-tiering.md)
## 예약된 메모리를 관리하기 위한 파라미터
2017년 3월 16일부터 Amazon ElastiCache에서는 Valkey 또는 Redis OSS 메모리 관리를 위해 상호 배타적인 파라미터 두 개, 즉 `reserved-memory`와 `reserved-memory-percent`를 제공합니다. 이 두 파라미터는 Valkey 또는 Redis OSS 배포의 일부가 아닙니다.
ElastiCache 고객이 된 시점에 따라, 이러한 파라미터 중 하나 또는 다른 파라미터가 기본 메모리 관리 파라미터입니다. 새 Valkey 또는 Redis OSS 클러스터 또는 복제 그룹을 생성하고 기본 파라미터 그룹을 사용할 때 이 파라미터가 적용됩니다.
+ 2017년 3월 16일 이전에 시작한 고객의 경우 기본 파라미터 그룹을 사용하여 Redis OSS 클러스터 또는 복제 그룹을 생성할 때 메모리 관리 파라미터가 `reserved-memory`입니다. 이 경우 0바이트의 메모리가 예약됩니다.
+ 2017년 3월 16일 이후에 시작된 고객의 경우 기본 파라미터 그룹을 사용하여 Valkey 또는 Redis OSS 클러스터 또는 복제 그룹을 생성할 때 메모리 관리 파라미터는 `reserved-memory-percent`입니다. 이 경우 노드 `maxmemory` 값의 25%가 비데이터 용도로 예약됩니다.
두 개의 Valkey 또는 Redis OSS 메모리 관리 파라미터를 읽은 후에는 기본이 아니거나 기본이 아닌 값을 가진 파라미터를 사용하는 것이 좋습니다. 이 경우, 다른 예약된 메모리 관리 파라미터로 변경할 수 있습니다.
이 파라미터의 값을 변경하려면 사용자 정의 파라미터 그룹을 생성하고 기본 설정 메모리 관리 파라미터 및 값을 사용하도록 수정할 수 있습니다. 그다음부터는 Valkey 또는 Redis OSS 클러스터나 복제 그룹을 새로 생성할 때마다 이 사용자 지정 파라미터 그룹을 사용할 수 있습니다. 기존 클러스터나 복제 그룹의 경우 사용자 지정 파라미터 그룹을 사용하도록 수정할 수 있습니다.
자세한 내용은 다음 자료를 참조하세요.
+ [예약된 메모리 관리 파라미터 지정](#redis-reserved-memory-management-change)
+ [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md)
+ [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md)
+ [ElastiCache 클러스터 수정](Clusters.Modify.md)
+ [복제 그룹 수정](Replication.Modify.md)
### reserved-memory 파라미터
2017년 3월 16일 이전에는 모든 ElastiCache for Redis OSS 예약된 메모리 관리가 `reserved-memory` 파라미터를 사용하여 수행되었습니다. `reserved-memory`의 기본값은 0입니다. 이 기본값은 Valkey 또는 Redis OSS 오버헤드에 대해 메모리를 예약하지 않으며, Valkey 또는 Redis OSS가 모든 노드의 메모리를 데이터로 사용하는 것을 허용합니다.
백업 및 장애 조치를 위해 충분한 메모리를 사용할 수 있도록 `reserved-memory`를 변경할 경우 사용자 지정 파라미터 그룹을 생성해야 합니다. 이 사용자 지정 파라미터 그룹에서 `reserved-memory`를 클러스터에 대해 실행 중인 Valkey 또는 Redis OSS 버전과 클러스터의 노드 유형에 적합한 값으로 설정합니다. 자세한 내용은 [필요한 예약된 메모리의 양](#redis-memory-management-need) 섹션을 참조하세요.
파라미터 `reserved-memory`는 ElastiCache에만 해당되며 일반 Redis OSS 배포의 일부가 아닙니다.
다음 절차는 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 클러스터의 메모리를 관리하는 방법을 보여줍니다.
**reserved-memory를 사용하여 메모리를 예약하려면**
1. 실행 중인 엔진 버전과 일치하는 파라미터 그룹 패밀리를 지정하는 사용자 지정 파라미터 그룹을 생성합니다. 예를 들어 `redis2.8` 파라미터 그룹 패밀리를 지정합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 섹션을 참조하세요.
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name redis6x-m3xl \
--description "Redis OSS 2.8.x for m3.xlarge node type" \
--cache-parameter-group-family redis6.x
```
1. Valkey 또는 Redis OSS 오버헤드를 위해 예약해야 하는 메모리의 바이트 수를 계산합니다. `maxmemory`에서 노드 유형에 대한 [Redis OSS 노드 유형별 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) 값을 찾을 수 있습니다.
1. `reserved-memory` 파라미터가 이전 단계에서 계산된 바이트 수가 되도록 사용자 지정 파라미터 그룹을 수정합니다. 다음 AWS CLI 예제에서는 2.8.22 이전 버전의 Redis OSS를 실행하고 있으며 노드의 `maxmemory` 절반을 예약한다고 가정합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=7130316800"
```
각 노드 유형에는 다른 `maxmemory` 값이 있으므로 사용할 각 노드 유형에 대해 별도의 사용자 지정 파라미터 그룹이 필요합니다. 따라서 각 노드 유형에는 `reserved-memory`에 대해 서로 다른 값이 필요합니다.
1. Redis OSS 클러스터나 복제 그룹을 수정하여 사용자 지정 파라미터 그룹을 사용하도록 합니다.
다음 CLI 예제에서는 ` my-redis-cluster` 클러스터를 수정하여 즉시 시작되는 사용자 지정 파라미터 그룹 `redis28-m3xl`을 사용하도록 합니다. 자세한 내용은 [ElastiCache 클러스터 수정](Clusters.Modify.md) 섹션을 참조하세요.
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
다음 CLI 예제에서는 복제 그룹 `my-redis-repl-grp`를 수정하여 즉시 시작되는 사용자 지정 파라미터 그룹 `redis28-m3xl`을 사용하도록 합니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하세요.
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
### reserved-memory-percent 파라미터
2017년 3월 16일에 Amazon ElastiCache는 `reserved-memory-percent` 파라미터를 도입했으며, ElastiCache for Redis OSS의 모든 버전에 사용할 수 있도록 했습니다. `reserved-memory-percent`의 목적은 모든 클러스터에 대해 예약된 메모리 관리를 간소화하는 것입니다. 노드 유형과 상관없이 클러스터의 예약된 메모리를 관리하기 위해 각 파라미터 그룹 패밀리에 대해 단일 파라미터 그룹(예: `redis2.8`)을 보유할 수 있도록 하여 이를 수행합니다. `reserved-memory-percent`에 대한 기본값은 25(25%)입니다.
파라미터 `reserved-memory-percent`는 ElastiCache에만 해당되며 일반 Redis OSS 배포의 일부가 아닙니다.
클러스터가 r6gd 패밀리의 노드 유형을 사용하고 있고 메모리 사용량이 75%에 도달하는 경우 데이터 계층화가 자동으로 트리거됩니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
**reserved-memory-percent를 사용하여 메모리를 예약하려면**
`reserved-memory-percent`를 사용하여 ElastiCache for Redis OSS클러스터에 대한 메모리를 관리하려면 다음 중 하나를 수행하세요.
+ Redis OSS 2.8.22 이상을 실행 중이면 클러스터에 기본 파라미터 그룹을 할당합니다. 기본 25%가 적절합니다. 그렇지 않은 경우 다음 설명된 단계에 따라 값을 변경합니다.
+ Redis OSS 2.8.22 이전 버전을 실행하고 있는 경우 `reserved-memory-percent`의 기본 25%보다 더 많은 메모리를 예약해야 할 수 있습니다. 이렇게 하려면 다음 절차를 사용하세요.
**reserved-memory-percent의 백분율 값을 변경하려면**
1. 실행 중인 엔진 버전과 일치하는 파라미터 그룹 패밀리를 지정하는 사용자 지정 파라미터 그룹을 생성합니다. 예를 들어 `redis2.8` 파라미터 그룹 패밀리를 지정합니다. 기본 파라미터 그룹을 수정할 수 없으므로 사용자 지정 파라미터 그룹이 필요합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 섹션을 참조하세요.
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name redis28-50 \
--description "Redis OSS 2.8.x 50% reserved" \
--cache-parameter-group-family redis2.8
```
`reserved-memory-percent`는 노드의 `maxmemory`%로 메모리를 예약하므로 각 노드 유형에 대해 사용자 지정 파라미터 그룹이 필요하지 않습니다.
1. `reserved-memory-percent`가 50(50%)이 되도록 사용자 지정 파라미터 그룹을 수정합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-50 \
--parameter-name-values "ParameterName=reserved-memory-percent, ParameterValue=50"
```
1. Redis OSS 2.8.22 이전 버전을 실행하는 Redis OSS 클러스터나 복제 그룹에 대해 이 사용자 지정 파라미터 그룹을 사용합니다.
다음 CLI 예제에서는 Redis OSS 클러스터 `my-redis-cluster`를 수정하여 즉시 시작되는 사용자 지정 파라미터 그룹 `redis28-50`을 사용하도록 합니다. 자세한 내용은 [ElastiCache 클러스터 수정](Clusters.Modify.md) 섹션을 참조하세요.
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
다음 CLI 예제에서는 Redis OSS 복제 그룹 `my-redis-repl-grp`를 수정하여 즉시 시작되는 사용자 지정 파라미터 그룹 `redis28-50`을 사용하도록 합니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하세요.
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
## 예약된 메모리 관리 파라미터 지정
2017년 3월 16일 현재 ElastiCache 고객이었던 사용자의 경우 예약된 메모리 관리 기본 파라미터는 예약된 메모리가 영(0) 바이트인 `reserved-memory`입니다. 2017년 3월 16일을 지난 시점에 ElastiCache 고객이 된 사용자의 경우 예약된 메모리 관리 기본 파라미터는 노드의 메모리 중 25%가 예약된 `reserved-memory-percent`입니다. 이것은 ElastiCache for Redis OSS 클러스터 또는 복제 그룹을 생성한 시점에 상관없이 적용됩니다. 그러나 예약된 메모리 관리 파라미터를 AWS CLI 또는 ElastiCache API를 사용해 변경할 수 있습니다.
파라미터 `reserved-memory` 및 `reserved-memory-percent`는 함께 사용할 수 없습니다. 파라미터 그룹에는 항상 한 개의 파라미터가 있으며 둘 다 있을 수 없습니다. 파라미터 그룹을 수정하여 파라미터 그룹에서 예약된 메모리 관리에 사용할 파라미터를 변경할 수 있습니다. 기본 파라미터 그룹을 수정할 수 없으므로 파라미터 그룹은 사용자 지정 파라미터 그룹이어야 합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 섹션을 참조하세요.
**reserved-memory-percent를 지정하려면**
`reserved-memory-percent`를 예약된 메모리 관리 파라미터로 사용하려면 `modify-cache-parameter-group` 명령어를 사용하여 사용자 지정 파라미터 그룹을 수정해야 합니다. `parameter-name-values` 파라미터를 사용하여 `reserved-memory-percent` 및 해당 값을 지정합니다.
다음 CLI 예제는 예약된 메모리를 관리하기 위해 `redis32-cluster-on`를 사용하도록 사용자 지정 파라미터 그룹 `reserved-memory-percent`을 수정합니다. 예약된 메모리 관리를 위해 파라미터 그룹에서 `ParameterValue` 파라미터를 사용할 수 있도록 `ParameterName`에 값을 지정해야 합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-cluster-on \
--parameter-name-values "ParameterName=reserved-memory-percent, ParameterValue=25"
```
**reserved-memory를 지정하려면**
`reserved-memory`를 예약된 메모리 관리 파라미터로 사용하려면 `modify-cache-parameter-group` 명령어를 사용하여 사용자 지정 파라미터 그룹을 수정해야 합니다. `parameter-name-values` 파라미터를 사용하여 `reserved-memory` 및 해당 값을 지정합니다.
다음 CLI 예제는 예약된 메모리를 관리하기 위해 `redis32-m3xl`를 사용하도록 사용자 지정 파라미터 그룹 `reserved-memory`을 수정합니다. 예약된 메모리 관리를 위해 파라미터 그룹에서 `ParameterValue` 파라미터를 사용할 수 있도록 `ParameterName`에 값을 지정해야 합니다. 엔진 버전이 2.8.22보다 더 새로운 버전이므로 값을 `3565158400`의 `cache.m3.xlarge` 중 25퍼센트에 해당하는 `maxmemory`으로 설정했습니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=3565158400"
```
# Valkey 및 Redis OSS 노드 기반 클러스터 사용 시 모범 사례
다중 AZ 사용, 충분한 메모리 확보, 클러스터 크기 조정, 가동 중지 시간 최소화는 모두 Valkey 또는 Redis OSS에서 노드 기반 클러스터로 작업할 때 염두에 두어야 할 유용한 개념입니다. 여러 모범 사례를 검토하고 따르도록 하세요.
**Topics**
+ [다중 AZ로 가동 중지 시간 최소화](multi-az.md)
+ [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)
+ [온라인 클러스터 크기 조정](best-practices-online-resharding.md)
+ [유지 관리 중 가동 중지 최소화](BestPractices.MinimizeDowntime.md)
# 다중 AZ로 가동 중지 시간 최소화
ElastiCache Valkey 또는 Redis OSS가 프라이머리 노드를 대체해야 하는 여러 가지 경우가 있습니다. 이러한 경우에는 특정 유형의 계획적인 유지 관리 및 드물지만 프라이머리 노드나 가용 영역에 장애가 발생하는 경우가 포함됩니다.
이러한 교체로 인해 클러스터에 약간의 가동 중지가 발생하지만 다중 AZ를 활성화한 경우 가동 중지 시간이 최소화됩니다. 기본 노드의 역할은 자동으로 읽기 전용 복제본 중 하나로 장애 조치됩니다. ElastiCache가 이 장애 조치를 투명하게 처리하기 때문에 새로운 기본 노드를 생성하고 프로비저닝할 필요가 없습니다. 이 장애 조치 및 복제본 승격을 통해 승격이 완료되는 즉시 새 기본 노드에 작성을 재개할 수 있습니다.
다중 AZ 및 가동 중지 시간 최소화에 대한 자세한 내용은 [Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 ElastiCache의 가동 중지 시간 최소화](AutoFailover.md) 섹션을 참조하세요.
# 충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성
**Valkey 7.2 이상 및 Redis OSS 버전 2.8.22 이상의 스냅샷 및 동기화**
Valkey는 스냅샷 및 동기화를 기본적으로 지원합니다. Redis OSS 2.8.22에는 동기화 및 저장을 수행하는 동안 스왑 사용량 증가 없이 애플리케이션 사용에 추가 메모리를 할당할 수 있는 forkless 저장 프로세스가 도입되었습니다. 자세한 내용은 [동기화 및 백업 구현 방법](Replication.Redis.Versions.md) 섹션을 참조하세요.
**버전 2.8.22 이전의 Redis OSS 스냅샷 및 동기화**
ElastiCache for Redis OSS를 사용하여 작업할 때 다음과 같이 많은 경우에 Redis OSS가 백그라운드 쓰기 명령을 직접 호출합니다.
+ 백업을 위해 스냅샷을 생성하는 경우
+ 복제 그룹에서 기본을 사용하여 복제본을 동기화하는 경우
+ Redis OSS에 AOF(append-only file) 기능을 활성화하는 경우.
+ 복제본을 기본으로 승격하는 경우(기본/복제본 동기화 발생)
Redis OSS에서 백그라운드 쓰기 프로세스를 실행할 때마다 사용 가능한 메모리가 충분해야 프로세스 오버헤드를 감당할 수 있습니다. 사용 가능한 메모리를 충분히 확보하지 못하면 프로세스가 실패합니다. 그러므로 Redis OSS 클러스터를 생성할 때 메모리가 충분한 노드 인스턴스 유형을 선택해야 합니다.
## Valkey 및 Redis OSS를 사용하는 백그라운드 쓰기 프로세스 및 메모리 사용
백그라운드 쓰기 프로세스가 호출될 때마다 Valkey와 Redis OSS는 해당 프로세스를 포크합니다(이러한 엔진은 단일 스레드입니다). 포크 하나가 Redis OSS .rdb 스냅샷 파일에서 데이터를 디스크에 계속 씁니다. 나머지 포크가 모든 읽기 및 쓰기 작업을 처리합니다. 스냅샷이 특정 시점 스냅샷이 되도록 모든 데이터 업데이트 및 추가가 데이터 영역과 별도의 사용 가능한 메모리 영역에 기록됩니다.
사용 가능한 메모리가 충분하여 데이터가 계속 디스크에 쓰여지는 동안 모든 쓰기 작업을 기록할 수 있으면 메모리 부족 문제가 발생하지 않습니다. 다음과 같은 경우에 해당되며 메모리 부족 문제가 생기기 쉽습니다.
+ 애플리케이션이 여러 쓰기 작업을 수행하여 새로운 데이터나 업데이트된 데이터를 저장하기 위해 사용 가능한 메모리가 대량으로 필요합니다.
+ 새로운 데이터나 업데이트된 데이터를 쓸 사용 가능한 메모리가 거의 없습니다.
+ 디스크에 계속 쓰기 위해 시간이 오래 걸리는 큰 데이터세트가 있어 많은 쓰기 작업이 필요합니다.
다음 다이어그램에서는 백그라운드 쓰기 프로세스를 실행할 때의 메모리 사용량을 보여줍니다.
![\[이미지: 백그라운드 쓰기 도중 메모리 사용량 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-bgsaveMemoryUseage.png)
백업이 성능에 미치는 영향에 대한 정보는 [노드 기반 클러스터 백업이 성능에 미치는 영향](backups.md#backups-performance) 섹션을 참조하세요.
Valkey 및 Redis OSS에서 스냅샷을 수행하는 방법에 대한 자세한 내용은 [http://valkey.io](http://valkey.io)를 참조하세요.
리전 및 가용 영역에 대한 자세한 내용은 [ElastiCache에 대한 리전 및 가용 영역 선택](RegionsAndAZs.md) 섹션을 참조하세요.
## 백그라운드 쓰기를 실행할 때 메모리 부족 방지
`BGSAVE` 또는 `BGREWRITEAOF`와 같은 백그라운드 쓰기 프로세스를 호출할 때마다 프로세스가 실패하지 않도록 하려면 프로세스 중에 쓰기 작업에 사용되는 것보다 많은 메모리가 있어야 합니다. 최악의 시나리오는 백그라운드 쓰기 작업 중에 모든 레코드가 업데이트되고 일부 새로운 레코드가 캐시에 추가되는 것입니다. 따라서 2.8.22 이전의 Redis OSS 버전에서는 `reserved-memory-percent`를 50(50%)으로 설정하고 Valkey 및 모든 Redis OSS 버전 2.8.22 이상에서는 25(25%)로 설정하는 것이 좋습니다.
`maxmemory` 값은 데이터 및 작업 오버헤드에 사용할 수 있는 메모리를 나타냅니다. 기본 파라미터 그룹에서 `reserved-memory` 파라미터를 수정할 수 없으므로 클러스터의 사용자 지정 파라미터 그룹을 생성해야 합니다. `reserved-memory`의 기본값은 0이며 Redis OSS가 데이터에 모든 *maxmemory*를 소비할 수 있어 백그라운드 쓰기 프로세스와 같은 다른 용도로 사용할 수 있는 메모리가 거의 없을 수 있음을 의미합니다. 노드 인스턴스 유형에 따른 `maxmemory` 값은 [Redis OSS 노드 유형별 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) 섹션을 참조하세요.
`reserved-memory` 파라미터를 사용하여 상자에서 사용하는 메모리 양을 줄일 수도 있습니다.
ElastiCache의 Valkey 및 Redis 관련 파라미터에 대한 자세한 내용은 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
파라미터 그룹 생성 및 수정에 대한 정보는 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 및 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
# 온라인 클러스터 크기 조정
*리샤딩*에는 클러스터에(서) 샤드 또는 노드를 추가 및 제거하고 샤드 간에 키 공간을 재분산하는 작업이 수반됩니다. 따라서 클러스터에 대한 로드, 메모리 사용률 및 데이터의 전체 크기 등과 같은 여러 가지 요인이 리샤딩 작업에 영향을 미칩니다. 최상의 성능을 구현하기 위해서는 균일한 워크로드 패턴 분산을 위한 전반적인 클러스터 모범 사례를 따르는 것이 좋습니다. 또한 다음 단계를 수행하는 것이 좋습니다.
리샤딩을 시작하기 전에 다음 작업을 수행하는 것이 좋습니다.
+ **애플리케이션 테스트** - 가능한 경우, 준비 환경에서 리샤딩 중 애플리케이션 동작을 테스트합니다.
+ **확장 문제는 초기에 알리기** - 리샤딩은 컴퓨팅 집약적인 작업입니다. 이 때문에 리샤딩 중에는 CPU 사용률을 멀티 코어 인스턴스의 경우, 80% 미만으로, 싱글 코어 인스턴스의 경우에는 50% 미만으로 유지하는 것이 좋습니다. 애플리케이션에서 규모 조정 문제 관찰을 시작하기 전에 ElastiCache for Redis OSS 지표를 모니터링한 다음 샤딩을 다시 시작합니다. `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` 및 `BytesUsedForCacheItems` 지표를 추적하면 유용합니다.
+ **스케일 인 전 충분한 여유 메모리를 사용할 수 있는지 확인** - 확장하는 경우, 샤드에서 제거하려는 사용 중인 메모리의 1.5배가 넘는 여유 메모리가 샤드에 있는지 확인합니다.
+ **사용량이 적은 시간에 리샤딩 시작** - 이 사례를 적용하면 리샤딩 작업 중 클라이언트에서 지연 시간과 처리량에 미치는 영향을 줄일 수 있습니다. 또한 슬롯 재분산에 더 많은 리소스를 사용할 수 있기 때문에 리샤딩을 더욱 빠르게 완료할 수 있습니다.
+ **클라이언트 제한 시간 동작 검토** - 일부 클라이언트에서는 온라인 클러스터 크기 조정 중 지연 시간이 더 길어지는 경우를 관찰할 수 있습니다. 제한 시간을 좀 더 길게 설정해 클라이언트 라이브러리를 구성하면 서버에 대한 로드가 더욱 큰 상황에서도 시스템에서 연결할 시간을 가질 수 있습니다. 일부 경우에 서버에 대해 많은 수의 연결을 열 수 있습니다. 이 경우 지수 백오프를 추가해 로직을 다시 연결합니다. 이렇게 하면 동시에 서버에 연결하는 새로운 연결이 급격하게 증가하는 것을 방지할 수 있습니다.
+ **모든 샤드에 함수 로드** - 클러스터를 스케일 아웃할 때, ElastiCache는 (임의로 선택된) 기존 노드 중 하나에 로드된 함수를 새 노드에 자동으로 복제합니다. 클러스터에 Valkey 7.2 이상 또는 Redis OSS 7.0 이상이 설치되어 있고 애플리케이션이 [함수](https://valkey.io/topics/functions-intro/)를 사용하는 경우, 모든 함수를 모든 샤드에 로드해야 스케일 아웃으로 인해 클러스터가 샤드마다 다른 함수로 종결되는 상황을 방지할 수 있습니다.
리샤딩 후에는 다음 내용에 유념하세요.
+ 대상 샤드에 사용 가능한 메모리가 부족한 경우에는 부분적인 확장만 가능했을 수 있습니다. 이러한 결과가 발생하면 필요한 경우, 사용 가능한 메모리를 검토한 후 작업을 다시 시도하세요. 대상 샤드의 데이터는 삭제되지 않습니다.
+ 리샤딩 작업 중에는 Lua 스크립트 내에서 `FLUSHALL`과 `FLUSHDB` 명령이 지원되지 않습니다. Redis OSS 6 이전에는 마이그레이션 중인 슬롯에서 작동하는 경우 `BRPOPLPUSH` 명령이 지원되지 않습니다.
# 유지 관리 중 가동 중지 최소화
클러스터 모드 구성은 관리 또는 비관리 작업 중에도 최고의 가용성을 제공합니다. 클러스터 탐색 엔드포인트에 연결되는 클러스터 모드 지원 클라이언트를 사용하는 것이 좋습니다. 클러스터 모드가 비활성화된 경우 모든 쓰기 작업에 기본 엔드포인트를 사용하는 것이 좋습니다.
읽기 활동의 경우 애플리케이션은 클러스터의 어떤 노드에도 연결할 수 있습니다. 기본 엔드포인트와 달리, 노드 엔드포인트는 특정 엔드포인트로 확인됩니다. 복제본을 추가하거나 삭제하는 것과 같이 클러스터를 변경하면 애플리케이션에서 노드 엔드포인트를 업데이트해야 합니다. 따라서 클러스터 모드를 비활성화한 경우 읽기 작업에 리더 엔드포인트를 사용하는 것이 좋습니다.
클러스터에 AutoFailover가 활성화되어 있는 경우, 프라이머리 노드가 변경될 수 있습니다. 따라서, 애플리케이션은 노드의 역할을 확인하고 모든 읽기 엔드포인트를 업데이트해야 합니다. 이렇게 하면 기본에 큰 로드가 발생하지 않도록 하는 데 도움이 됩니다. AutoFailover가 비활성화된 경우 노드의 역할이 변경되지 않습니다. 그러나 AutoFailover가 활성화된 클러스터에 비해 관리되거나 관리되지 않는 작업의 가동 중지 시간이 더 깁니다.
노드를 사용할 수 없으면 읽기 중단이 발생할 수 있으므로 읽기 요청을 단일 읽기 전용 복제본 노드로 보내지 않습니다. 프라이머리에서 읽기 전용으로 대체하거나, 적어도 2개 이상의 읽기 전용 복제본을 마련하여 유지 관리 중 읽기 중단이 일어나지 않도록 합니다.
# Memcached에 대한 캐싱 전략
다음 항목에서는 Memcached 캐시를 채우고 유지 관리하기 위한 전략을 확인할 수 있습니다.
캐시를 채우고 유지 관리하기 위해 구현하려는 전략은 캐싱되는 데이터의 유형과 해당 데이터에 대한 액세스 패턴에 따라 달라집니다. 예를 들어, 게임 사이트와 새 이야기 추세의 상위 10개 리더보드에 대해 동일한 전략을 사용하려고 하지 않을 수 있습니다. 이 섹션의 나머지 부분에서는 일반적인 캐시 유지 관리 전략, 이에 대한 장점 및 단점에 대해 살펴봅니다.
**Topics**
+ [읽기 전용 복제본](#Strategies.ReadReplicas)
+ [지연 로딩](#Strategies.LazyLoading)
+ [라이트-스루](#Strategies.WriteThrough)
+ [TTL 추가](#Strategies.WithTTL)
+ [관련 주제](#Strategies.SeeAlso)
## 읽기 전용 복제본
복제본을 생성하고 기본 캐시 노드 대신 복제본에서 읽어 ElastiCache 서버리스 캐시의 성능을 크게 개선할 수 있는 경우가 많습니다. 자세한 내용은 [읽기 전용 복제본 사용 모범 사례](ReadReplicas.md)을 참조하세요.
## 지연 로딩
이름에서 알 수 있듯이 *지연 로딩*은 필요할 때에만 데이터를 캐시에 로드하는 캐싱 전략입니다. 다음 설명과 같이 작동합니다.
Amazon ElastiCache는 액세스하는 애플리케이션과 데이터 스토어(데이터베이스) 사이에 위치하는 인 메모리 키/값 저장소입니다. 애플리케이션에서 데이터를 요청할 때마다 ElastiCache 캐시에 먼저 요청합니다. 데이터가 캐시에 있으며 최신 상태인 경우 ElastiCache가 데이터를 애플리케이션에 반환합니다. 데이터가 캐시에 없거나 만료된 경우 애플리케이션에서 데이터 스토어에 데이터를 요청합니다. 데이터 스토어에서 데이터를 애플리케이션에 반환합니다. 다음으로 애플리케이션은 스토어에서 수신한 데이터를 캐시에 씁니다. 이렇게 하면 다음에 요청이 있을 때 데이터를 더 빨리 검색할 수 있습니다.
*캐시 적중률*은 데이터가 캐시에 있고 만료되지 않은 경우에 발생합니다.
1. 애플리케이션은 캐시에서 데이터를 요청합니다.
1. 캐시는 애플리케이션으로 데이터를 반환합니다.
*캐시 누락*은 데이터가 캐시에 없거나 만료된 경우에 발생합니다.
1. 애플리케이션은 캐시에서 데이터를 요청합니다.
1. 캐시에 데이터가 요청되지 않으므로 `null`을 반환합니다.
1. 애플리케이션은 데이터베이스에 데이터를 요청하고 수신합니다.
1. 애플리케이션은 새 데이터로 캐시를 업데이트합니다.
### 지연 로딩의 장점 및 단점
지연 로딩의 장점은 다음과 같습니다.
+ 요청된 데이터만 캐싱됩니다.
대부분의 데이터가 요청되지 않으므로 지연 로딩은 요청되지 않은 데이터가 있는 캐시를 채우지 않습니다.
+ 노드 장애가 애플리케이션에 치명적인 영향을 주지 않습니다.
노드 장애가 발생하여 새로운 빈 노드로 대체될 경우 애플리케이션에서는 지연 시간 증가를 통해 계속 작동합니다. 새 노드에 대한 요청이 발생하면, 각 캐시가 누락될 때마다 데이터베이스 쿼리가 생성됩니다. 동시에 데이터 복사본이 캐시에 추가되어 이후의 요청이 캐시에서 검색됩니다.
지연 로딩의 단점은 다음과 같습니다.
+ 캐시 누락 패널티가 있습니다. 각 캐시 누락은 세 개의 이동으로 나타납니다.
1. 캐시에서 데이터에 대한 초기 요청
1. 데이터에 대한 데이터베이스의 쿼리
1. 캐시에 데이터 작성
이러한 누락으로 인해 애플리케이션으로 데이터를 가져오는 것이 눈에 띄게 지연될 수 있습니다.
+ 기한 경과된 데이터
캐시 누락 시에만 데이터를 캐시에 쓰면, 캐시의 데이터가 기한이 경과할 수 있습니다. 이 결과는 데이터베이스에서 데이터가 변경될 때 캐시에 대한 업데이트가 없기 때문에 발생합니다. 이 문제를 해결하려면 [라이트-스루](#Strategies.WriteThrough) 및 [TTL 추가](#Strategies.WithTTL) 전략을 사용할 수 있습니다.
### 지연 로딩 유사 코드 예제
다음은 지연 로딩 로직의 의사(pseudo) 코드 예제입니다.
```
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record == null)
customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
cache.set(customer_id, customer_record)
return customer_record
```
이 예제의 경우, 데이터를 갖는 애플리케이션 코드는 다음과 같습니다.
```
customer_record = get_customer(12345)
```
## 라이트-스루
라이트-스루 전략은 데이터베이스에 데이터를 작성할 때마다 데이터를 추가하거나 캐시의 데이터를 업데이트합니다.
### 라이트-스루의 장점 및 단점
라이트-스루의 장점은 다음과 같습니다.
+ 캐시의 데이터가 기한 경과되지 않습니다.
캐시의 데이터는 데이터베이스에 쓰일 때마다 업데이트되므로 항상 최신 상태입니다.
+ 쓰기 패널티 vs. 읽기 패널티
모든 쓰기에는 다음 2개의 이동이 수반됩니다.
1. 캐시에 쓰기
1. 데이터베이스에 쓰기
이로 인해 프로세스에 지연 시간이 추가됩니다. 즉, 최종 사용자는 일반적으로 데이터를 검색할 때보다 데이터를 업데이트할 때 지연 시간에 더 관대합니다. 업데이트는 더 많이 작동하므로 오래 걸릴 수 있다는 고유한 생각이 있습니다.
라이트-스루의 단점은 다음과 같습니다.
+ 누락된 데이터
노드 장애 또는 확장으로 인해 새 노드를 스핀업하면 데이터가 누락됩니다. 이 데이터는 데이터베이스에 추가되거나 업데이트될 때까지 계속 누락됩니다. 라이트-스루로 [지연 로딩](#Strategies.LazyLoading)을 구현하여 이 문제를 최소화할 수 있습니다.
+ 캐시 이탈
대부분의 데이터는 절대 읽히지 않으며 이는 리소스 낭비입니다. [TTL(Time to Live) 값을 추가](#Strategies.WithTTL)하면 낭비되는 공간을 최소화할 수 있습니다.
### 라이트-스루 의사 코드 예제
다음은 라이트-스루 로직의 의사(pseudo) 코드 예제입니다.
```
// *****************************************
// function that saves a customer's record.
// *****************************************
save_customer(customer_id, values)
customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
cache.set(customer_id, customer_record)
return success
```
이 예제의 경우, 데이터를 갖는 애플리케이션 코드는 다음과 같습니다.
```
save_customer(12345,{"address":"123 Main"})
```
## TTL 추가
지연 로딩은 기한 경과 데이터에 대해 허용되지만 빈 노드로 인해 실패하지 않습니다. 라이트-스루는 데이터를 항상 최신 상태로 유지하지만, 빈 노드로 인해 실패할 수 있으며 불필요한 데이터로 캐시를 채울 수 있습니다. 각 쓰기에 TTL(Time to Live) 값을 추가하면 각 전략의 이점을 얻을 수 있습니다. 동시에 추가 데이터로 캐시를 복잡하게 만들지 않을 수 있습니다.
*TTL(Time To Live)*은 키가 만료될 때까지의 시간(초)을 지정하는 정수 값입니다. Valkey 또는 Redis OSS는 이 값에 대해 초 또는 밀리초를 지정할 수 있습니다. Memcached는 초 단위로 이 값을 지정합니다. 애플리케이션에서 만료된 키를 읽으려고 하면 키가 없는 것으로 처리됩니다. 데이터베이스가 키에 대해 쿼리되고 캐시가 업데이트됩니다. 이는 값이 기한 경과가 아님을 보장하지 않습니다. 그러나 데이터가 너무 기간 경과되지 않도록 방지하며, 경우에 따라 캐시의 값이 데이터베이스에서 새로 고침되어야 합니다.
자세한 내용은 [Valkey 및 Redis OSS 명령](https://valkey.io/commands) 또는 [Memcached `set` 명령](https://www.tutorialspoint.com/memcached/memcached_set_data.htm)을 참조하세요.
### TTL 의사 코드 예제
다음 코드는 TTL을 통한 라이트-스루 로직의 의사(pseudo) 코드 예제입니다.
```
// *****************************************
// function that saves a customer's record.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and future reads will have to query the database.
// *****************************************
save_customer(customer_id, values)
customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
cache.set(customer_id, customer_record, 300)
return success
```
다음은 TTL을 통한 지연 로딩 로직의 의사(pseudo) 코드 예제입니다.
```
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and subsequent reads will have to query the database.
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record != null)
if (customer_record.TTL < 300)
return customer_record // return the record and exit function
// do this only if the record did not exist in the cache OR
// the TTL was >= 300, i.e., the record in the cache had expired.
customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
cache.set(customer_id, customer_record, 300) // update the cache
return customer_record // return the newly retrieved record and exit function
```
이 예제의 경우, 데이터를 갖는 애플리케이션 코드는 다음과 같습니다.
```
save_customer(12345,{"address":"123 Main"})
```
```
customer_record = get_customer(12345)
```
## 관련 주제
+ [인 메모리 데이터 스토어](elasticache-use-cases.md#elasticache-use-cases-data-store)
+ [엔진 및 버전 선택](SelectEngine.md)
+ [ElastiCache 규모 조정](Scaling.md)
# ElastiCache에서 노드 기반 클러스터 관리
ElastiCache는 서버리스 캐시와 노드 기반 클러스터의 두 가지 배포 옵션을 제공합니다. 각각 고유한 기능과 요구 사항이 있습니다.
이 섹션에는 노드 기반 클러스터를 관리하는 데 도움이 되는 항목이 포함되어 있습니다.
**참고**
이러한 주제는 ElastiCache 서버리스에는 적용되지 않습니다.
**Topics**
+ [오토 스케일링 Valkey 및 Redis OSS 클러스터](AutoScaling.md)
+ [클러스터 모드 수정](modify-cluster-mode.md)
+ [글로벌 데이터 스토어를 사용하여AWS리전 간 복제](Redis-Global-Datastore.md)
+ [고가용성을 위한 복제 그룹 사용](Replication.md)
+ [ElastiCache 클러스터 유지 관리](maintenance-window.md)
+ [ElastiCache 파라미터 그룹을 사용해 엔진 파라미터 구성](ParameterGroups.md)
# 오토 스케일링 Valkey 및 Redis OSS 클러스터
## 사전 조건
ElastiCache 오토 스케일링은 다음으로 제한됩니다.
+ Valkey 7.2 이상을 실행하거나 Redis OSS 6.0 이상을 실행하는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터
+ Valkey 7.2 이상을 실행하거나 Redis OSS 7.0.7 이상을 실행하는 데이터 계층화(클러스터 모드 활성화됨) 클러스터
+ 인스턴스 크기 - Large, XLarge, 2XLarge
+ 인스턴스 유형 패밀리 - R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn
+ ElastiCache에서의 오토 스케일링은 글로벌 데이터 저장소, Outposts 또는 Local Zones에서 실행되는 클러스터에는 지원되지 않습니다.
## Valkey 또는 Redis OSS를 사용하는 ElastiCache 오토 스케일링을 사용하여 자동으로 용량 관리
Valkey 또는 Redis OSS를 사용한 ElastiCache 오토 스케일링은 ElastiCache 서비스에서 원하는 샤드 또는 복제본을 자동으로 늘리거나 줄일 수 있는 기능입니다. ElastiCache는 Application Auto Scaling 서비스를 활용하여이 기능을 제공합니다. 자세한 내용은 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) 섹션을 참조하세요. 자동 조정을 사용하려면 할당한 CloudWatch 지표 및 대상 값을 사용하는 조정 정책을 정의하고 적용합니다. ElastiCache 오토 스케일링은 정책을 사용하여 실제 워크로드에 대한 응답으로 인스턴스 수를 늘리거나 줄입니다.
AWS Management Console를 사용하여 사전 정의된 지표를 기반으로 조정 정책을 적용할 수 있습니다. `predefined metric`이 열거 형식으로 정의되어 이를 코드의 이름별로 지정하거나AWS Management Console에서 사용할 수 있습니다.AWS Management Console을 사용하여 선택하는 경우에는 사용자 지정 지표를 사용할 수 없습니다. 또는AWS CLI또는 Application Auto Scaling API를 사용하여 사전 정의 또는 사용자 지정 지표를 기반으로 조정 정책을 적용할 수 있습니다.
ElastiCache for Valkey 및 Redis OSS는 다음 차원에 대한 크기 조정을 지원합니다.
+ **샤드** - 수동 온라인 리샤딩과 유사하게 클러스터에서 샤드를 자동으로 추가/제거합니다. 이 경우 ElastiCache 오토 스케일링이 사용자를 대신해 크기 조정을 트리거합니다.
+ **복제본** - 수동 복제본 증가/감소 작업과 유사하게 클러스터에서 복제본을 자동으로 추가/제거합니다. ElastiCache for Valkey 및 Redis OSS는 클러스터의 모든 샤드에서 균등하게 복제본을 추가/제거합니다.
ElastiCache for Valkey 및 Redis OSS는 다음과 같은 유형의 Auto Scaling 정책을 지원합니다.
+ [대상 추적 조정 정책](AutoScaling-Scaling-Policies-Target.md) - 특정 지표에 대한 대상 값을 기준으로 서비스가 실행하는 샤드/복제본의 수를 늘리거나 줄입니다. 이 과정은 온도 조절기를 사용하여 집안 온도를 유지하는 방법과 비슷합니다. 사용자가 온도를 선택하면 나머지는 모두 온도 조절기에서 자동으로 수행됩니다.
+ [ 애플리케이션의 예약된 조정입니다. ](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) - ElastiCache for Valkey 및 Redis OSS Auto Scaling은 날짜 및 시간을 기준으로 서비스가 실행하는 샤드/복제본의 수를 늘리거나 줄일 수 있습니다.
![\[ElastiCache for Valkey 및 Redis OSS의 오토 스케일링 이미지\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/Auto-scaling.png)
다음은 앞의 그림에 소개된 ElastiCache for Valkey 및 Redis OSS Auto Scaling 프로세스를 요약한 단계입니다.
1. 복제 그룹에 대한 ElastiCache 오토 스케일링 정책을 생성합니다.
1. ElastiCache Auto Scaling이 사용자를 대신하여 CloudWatch 경보 쌍을 생성합니다. 각 쌍은 지표의 상한값과 하한값을 나타냅니다. 클러스터의 실제 사용률이 일정한 시간 동안 목표 사용률을 벗어나면 이러한 CloudWatch 경보가 트리거됩니다. 콘솔에서 경보를 볼 수 있습니다.
1. 구성된 지표 값이 특정 기간의 목표 사용률을 초과하는 경우(또는 목표에 미달하는 경우), CloudWatch가 오토 스케일링을 호출하여 크기 조정 정책을 평가하는 경보를 트리거합니다.
1. ElastiCache Auto Scaling은 클러스터 용량을 조정하는 수정 요청을 발행합니다.
1. ElastiCache는 이 수정 요청을 처리하고 목표 사용률에 근접하도록 클러스터 샤드/복제본 용량을 동적으로 늘리거나 줄입니다.
ElastiCache Auto Scaling의 작동 방식을 알아보기 위해 `UsersCluster`라는 클러스터가 있다고 가정합니다. `UsersCluster`의 CloudWatch 지표를 모니터링하여 트래픽이 가장 높을 때 클러스터에 필요한 최대 샤드 수와 트래픽이 가장 낮을 때 필요한 최소 샤드 수를 결정합니다. 또한 `UsersCluster` 클러스터의 CPU 사용률에 대한 목표 값을 결정합니다. ElastiCache 오토 스케일링에서는 목표 추적 알고리즘을 사용하여 `UsersCluster`의 프로비저닝된 샤드 수를 필요에 따라 조절함으로써 사용률이 목표 값 안팎으로 유지되도록 합니다.
**참고**
크기 조정에는 상당한 시간이 소요될 수 있으며 샤드가 재분배되려면 추가적인 클러스터 리소스가 필요합니다. ElastiCache Auto Scaling은 실제 워크로드가 일정 시간(분) 동안 높게(또는 낮게) 유지되는 경우에 한해 리소스 설정을 수정합니다. 오토 스케일링의 목표 추적 알고리즘은 목표 사용률을 장기적으로 사용자가 선택한 값 안팎으로 유지되도록 합니다.
# Auto Scaling 정책
스케일링 정책에는 다음과 같은 구성 요소가 있습니다.
+ 대상 지표 - ElastiCache for Valkey 및 Redis OSS Auto Scaling에서 조정 시기 및 규모를 결정하는 데 사용하는 CloudWatch 지표입니다.
+ 최소 및 최대 용량 - 크기 조정에 사용할 최소 및 최대 샤드 또는 복제본 수입니다.
**중요**
Auto Scaling 정책을 생성하는 동안 현재 용량이 구성된 최대 용량보다 크면 정책을 생성하면서 MaxCapacity로 축소됩니다. 마찬가지로 현재 용량이 구성된 최소 용량보다 작으면 MinCapacity로 확장됩니다.
+ 휴지 기간 - 축소 또는 확장 활동이 완료되고 다른 확장 활동이 시작되기 전의 시간(초 단위)입니다.
+ 서비스 연결 역할 – 특정 AWS 서비스에 연결된 AWS Identity and Access Management(IAM) 역할입니다. 서비스 연결 역할에는 서비스가 다른 AWS 서비스를 자동으로 호출하기 위해 필요한 모든 권한이 포함됩니다. ElastiCache Auto Scaling은 자동으로 이 역할(`AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG`)을 생성합니다.
+ 스케일 인 활동 활성화 또는 비활성화 - 정책의 스케일 인 활동을 활성화하거나 비활성화할 수 있는 기능입니다.
**Topics**
+ [Auto Scaling을 위한 대상 지표](#AutoScaling-TargetMetric)
+ [최소 및 최대 용량](#AutoScaling-MinMax)
+ [휴지 기간](#AutoScaling-Cooldown)
+ [스케일 인 활동 활성화 또는 비활성화](#AutoScaling-enable-disable-scale-in)
## Auto Scaling을 위한 대상 지표
이 유형의 정책에서는 미리 정의된 지표나 사용자 지정 지표 및 지표의 대상 값이 대상 추적 조정 정책 구성에 지정됩니다. ElastiCache for Valkey 및 Redis OSS Auto Scaling은 조정 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 조정 조절을 계산합니다. 조정 정책은 필요에 따라 샤드/복제본을 추가하거나 제거하여 지표를 지정한 대상 값으로 또는 대상 값에 가깝게 유지합니다. 대상 추적 조정 정책은 지표를 대상 값에 가깝게 유지하는 것 외에도 워크로드 변화로 인한 지표의 변동에 따라 조정되기도 합니다. 이 정책은 클러스터의 사용 가능한 샤드/복제본 수의 급격한 변동을 최소화하기도 합니다.
미리 정의된 평균 `ElastiCachePrimaryEngineCPUUtilization` 지표가 사용되는 조정 정책을 예로 든다면, 그러한 정책이 CPU 사용률을 70%의 지정된 사용률(퍼센트)로 또는 그에 가깝게 유지할 수 있습니다.
**참고**
클러스터마다 대상 지표에 대해 Auto Scaling 정책을 하나씩만 생성할 수 있습니다.
## 최소 및 최대 용량
**샤드**
ElastiCache for Valkey 및 Redis OSS Auto Scaling에 의해 조정될 수 있는 최대 샤드 수를 지정할 수 있습니다. 이 값은 250보다 작거나 같아야 하며 최소값은 1입니다. 오토 스케일링에 의해 관리되는 최소 샤드 수를 지정할 수도 있습니다. 이 값은 최소 1이어야 하고, 최대 샤드 수(250)에 지정된 값과 동일하거나 그보다 작아야 합니다.
**복제본**
ElastiCache for Valkey 및 Redis OSS Auto Scaling에 의해 관리되는 최대 복제본 수를 지정할 수 있습니다. 이 값은 5보다 작거나 같아야 합니다. 오토 스케일링에서 관리할 최소 복제본 수를 지정할 수도 있습니다. 이 값은 최소 1이어야 하고, 최대 복제본 수(5)에 지정된 값과 동일하거나 그보다 작아야 합니다.
일반 트래픽에서 필요한 샤드/복제본의 최소 및 최대 수를 결정하려면 모델에 대한 예상 트래픽 레이트를 이용해 Auto Scaling 구성을 테스트합니다.
**참고**
ElastiCache Auto Scaling 정책은 정의된 최대 크기에 도달할 때까지 또는 서비스 한도가 적용될 때까지 클러스터 용량을 늘립니다. 한도 증가를 요청하려면 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 참조하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택하세요.
**중요**
트래픽이 없는 경우 축소가 발생합니다. 변형의 트래픽이 0이 되는 경우 ElastiCache가 자동으로 지정된 최소 인스턴스 수로 축소됩니다.
## 휴지 기간
클러스터의 조정에 영향을 미치는 휴지 기간을 추가하여 대상 추적 조정 정책의 응답성을 조정할 수 있습니다. 휴지 기간은 기간이 만료될 때까지 후속 스케일 인 또는 스케일 아웃 요청을 차단합니다. 이렇게 하면 스케일 인 요청에 대한 ElastiCache for Valkey 및 Redis OSS 클러스터의 샤드/복제본 삭제 및 스케일 아웃 요청에 대한 샤드/복제본 생성의 속도가 느려집니다. 다음과 같은 휴지 기간을 지정할 수 있습니다.
+ 스케일 인 활동은 클러스터에 있는 샤드/복제본 수를 줄입니다. 스케일 인 휴지 기간은 스케일 인 활동이 완료되고 다른 스케일 인 활동이 시작되기 전의 시간을 초 단위로 지정합니다.
+ 스케일 아웃 활동은 클러스터에 있는 샤드/복제본 수를 늘립니다. 스케일 아웃 휴지 기간은 스케일 아웃 활동이 완료되고 다른 스케일 아웃 활동이 시작되기 전의 시간을 초 단위로 지정합니다.
스케일 인 또는 스케일 아웃 휴지 기간을 지정하지 않은 경우 스케일 인의 기본값은 600초이고 스케일 아웃의 기본값은 900초입니다.
## 스케일 인 활동 활성화 또는 비활성화
정책의 스케일 인 활동을 활성화하거나 비활성화할 수 있습니다. 스케일 인 활동을 활성화하면 조정 정책을 통해 샤드/복제본을 삭제할 수 있습니다. 스케일 인 활동이 활성화되면 조정 정책의 스케일 인 휴지 기간이 스케일 인 활동에 적용됩니다. 스케일 인 활동을 비활성화하면 조정 정책을 통해 샤드/복제본을 삭제할 수 없습니다.
**참고**
조정 정책이 필요에 따라 ElastiCache 샤드 또는 복제본을 생성할 수 있도록 스케일 아웃 활동이 항상 활성화됩니다.
## 오토 스케일링에 필요한 IAM 권한
ElastiCache for Valkey 및 Redis OSS Auto Scaling은 ElastiCache, CloudWatch 및 Application Auto Scaling API의 조합을 통해 작동합니다. 클러스터는 ElastiCache를 통해 생성 및 업데이트되고, 경보는 CloudWatch를 통해 생성되고, 규모 조정 정책은 Application Auto Scaling을 통해 생성됩니다. ElastiCache 오토 스케일링 설정에 액세스하는 IAM 사용자에게는 클러스터 생성 및 업데이트에 대한 표준 IAM 권한에 더해 동적 크기 조정을 지원하는 서비스에 대한 적절한 권한이 있어야 합니다. 이 최신 정책에서는 작업 `elasticache:ModifyCacheCluster`와 함께 Memcached 수직적 스케일링에 대한 지원을 추가했습니다. IAM 사용자에게는 다음 예제 정책에 나온 태스크를 수행할 수 있는 권한이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-autoscaling:*",
"elasticache:DescribeReplicationGroups",
"elasticache:ModifyReplicationGroupShardConfiguration",
"elasticache:IncreaseReplicaCount",
"elasticache:DecreaseReplicaCount",
"elasticache:DescribeCacheClusters",
"elasticache:DescribeCacheParameters",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"cloudwatch:PutMetricAlarm",
"cloudwatch:DisableAlarmActions",
"cloudwatch:EnableAlarmActions",
"iam:CreateServiceLinkedRole",
"sns:CreateTopic",
"sns:Subscribe",
"sns:Get*",
"sns:List*"
],
"Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster"
}
]
}
```
------
## 서비스 연결 역할
ElastiCache for Valkey 및 Redis OSS Auto Scaling 서비스에는 클러스터 및 CloudWatch 경보를 설명할 수 있는 권한과 사용자를 대신하여 ElastiCache 대상 용량을 수정할 수 있는 권한이 필요합니다. 클러스터에 오토 스케일링을 활성화하면 `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG`라는 서비스 연결 역할이 생성됩니다. 이 서비스 연결 역할은 ElastiCache 오토 스케일링에 정책에 대한 경보를 설명하고, 플릿의 현재 용량을 모니터링하고, 플릿의 용량을 수정할 수 있는 권한을 부여합니다. 서비스 연결 역할은 ElastiCache 오토 스케일링의 기본 역할입니다. 자세한 내용은 Application Auto Scaling 사용 설명서의 [ElastiCache for Redis OSS Auto Scaling에 대한 서비스 연결 역할](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)을 참조하세요.
## Auto Scaling 모범 사례
Auto Scaling에 등록하기 전에 다음 작업을 수행하는 것이 좋습니다.
1. **하나의 추적 지표만 사용** - 클러스터에 CPU 또는 데이터 사용량이 많은 워크로드가 있는지 확인하고 해당하는 사전 정의된 지표를 사용하여 크기 조정 정책을 정의합니다.
+ 엔진 CPU: `ElastiCachePrimaryEngineCPUUtilization`(샤드 차원) 또는 `ElastiCacheReplicaEngineCPUUtilization`(복제본 차원)
+ 데이터베이스 사용: `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` 이 크기 조정 정책은 클러스터에서 maxmemory-policy를 noeviction으로 설정한 경우에 가장 잘 작동합니다.
클러스터에서 측정기준당 여러 정책을 사용하지 않는 것이 좋습니다. ElastiCache for Valkey 및 Redis OSS Auto Scaling은 대상 추적 정책 중 하나라도 스케일 아웃할 준비가 된 경우 확장 가능한 대상을 스케일 아웃하지만, 모든 대상 추적 정책(스케일 인 부분이 활성화됨)이 스케일 인할 준비가 된 경우에만 스케일 인합니다. 여러 정책이 조정 가능한 대상에 스케일 아웃 또는 인을 동시에 지시하는 경우 대상은 스케일 인과 스케일 아웃 모두에 대해 가장 큰 용량을 제공하는 정책에 따라 조정합니다.
1. **대상 추적을 위한 사용자 지정 지표** - Auto Scaling은 정책에 대해 선택한 지표의 변화에 비례하는 스케일 아웃/인에 가장 적합하므로 대상 추적에 사용자 지정 지표를 사용할 경우 주의해야 합니다. 이와 같이 크기 조정 작업에 비례하여 변경되지 않는 지표가 정책 생성에 사용되는 경우 가용성이나 비용에 영향을 줄 수 있는 지속적인 스케일 아웃 또는 스케일 인 작업이 발생할 수 있습니다.
데이터 계층화 클러스터(r6gd 패밀리 인스턴스 유형)의 경우 크기 조정에 메모리 기반 지표를 사용하지 마세요.
1. **예약된 조정(Scheduled Scaling)** - 워크로드가 결정적인지(특정 시간에 상한/하한에 도달) 확인되면 예약 조정을 사용하고 필요에 따라 대상 용량을 구성하는 것이 좋습니다. 대상 추적은 비결정적 워크로드와 필요한 대상 지표에 따라 더 많은 리소스가 필요할 때 스케일 아웃되고 더 적은 리소스가 필요할 때 스케일 인되는 방식으로 작동하는 클러스터에 가장 적합합니다.
1. **스케일 인 사용 중지(Disable Scale-In)** - 지표의 급속한 증가/감소는 연속적인 스케일 아웃/인 변동을 트리거할 수 있으므로 대상 추적의 자동 크기 조정은 워크로드가 점진적으로 증가/감소하는 클러스터에 가장 적합합니다. 이러한 변동을 방지하기 위해 스케일 인을 사용 중지한 상태로 시작하고 나중에 언제든지 필요에 따라 수동으로 스케일 인할 수 있습니다.
1. **애플리케이션 테스트(Test your application)** - 예상 최소/최대 워크로드를 사용하여 애플리케이션을 테스트하여 가용성 문제를 방지하기 위한 조정 정책을 생성하는 동안 클러스터에 필요한 최소, 최대 샤드/복제본의 절대 수를 확인하는 것이 좋습니다. 자동 크기 조정은 대상에 구성된 최대 임계값까지 스케일 아웃하고 최소 임계값까지 스케일 인할 수 있습니다.
1. **대상 값 정의(Defining Target Value)** - 4주간의 클러스터 사용률에 대한 해당 CloudWatch 지표를 분석하여 대상 값 임계값을 확인할 수 있습니다. 어떤 값을 선택할지 잘 모르는 경우 지원되는 최소 사전 정의 지표 값으로 시작하는 것이 좋습니다.
1. 대상 추적의 자동 크기 조정은 샤드/복제본 측정기준에서 워크로드가 균일하게 분산된 클러스터에 가장 적합합니다. 균일하게 분산되지 않으면 다음과 같은 결과가 발생할 수 있습니다.
+ 사용량이 많은 몇 개의 샤드/복제본에서 워크로드의 급격한 증가/감소로 인해 필요하지 않을 때 조정이 발생할 수 있습니다.
+ 사용량이 많은 샤드/복제본이 있어도 전체 평균이 대상에 가깝기 때문에 필요할 때 조정이 발생하지 않을 수 있습니다.
**참고**
클러스터를 스케일 아웃할 때, ElastiCache는 (임의로 선택된) 기존 노드 중 하나에 로드된 함수를 새 노드에 자동으로 복제합니다. 클러스터에 Valkey 또는 Redis OSS 7.0 이상이 설치되어 있고 애플리케이션이 [함수](https://valkey.io/topics/functions-intro/)를 사용하는 경우, 모든 함수를 모든 샤드에 로드해야 스케일 아웃으로 인해 클러스터가 샤드마다 다른 함수로 종결되는 상황을 방지할 수 있습니다.
자동 크기 조정에 등록한 후에는 다음 사항에 주의하세요.
+ 자동 크기 조정의 지원되는 구성에 제한이 있으므로 자동 크기 조정에 등록된 복제 그룹의 구성을 변경하지 않는 것이 좋습니다. 예를 들어, 다음과 같습니다.
+ 인스턴스 유형을 지원되지 않는 유형으로 수동으로 수정합니다.
+ 복제 그룹을 글로벌 데이터 스토어에 연결합니다.
+ `ReservedMemoryPercent` 파라미터를 변경합니다.
+ 정책 생성 중에 구성된 최소/최대 용량을 초과하여 샤드/복제본을 수동으로 늘리거나 줄입니다.
# 샤드에 Auto Scaling 사용
ElastiCache 오토 스케일링을 사용하면 Valkey 또는 Redis OSS 엔진에서 추적 및 예약 정책을 사용할 수 있습니다.
다음은 대상 추적 및 예약된 정책에 대한 세부 정보와 AWS Management Console AWS CLI 및 API를 사용하여 이를 적용하는 방법을 제공합니다.
**Topics**
+ [대상 추적 조정 정책](AutoScaling-Scaling-Policies-Target.md)
+ [조정 정책 추가](AutoScaling-Scaling-Adding-Policy-Shards.md)
+ [확장 가능 목표 등록](AutoScaling-Scaling-Registering-Policy-CLI.md)
+ [조정 정책 정의](AutoScaling-Scaling-Defining-Policy-API.md)
+ [스케일 인 활동 비활성화](AutoScaling-Scaling-Disabling-Scale-in.md)
+ [조정 정책 적용](AutoScaling-Scaling-Applying-a-Scaling-Policy.md)
+ [조정 정책 편집](AutoScaling-Scaling-Editing-a-Scaling-Policy.md)
+ [조정 정책 삭제](AutoScaling-Scaling-Deleting-a-Scaling-Policy.md)
+ [Auto Scaling 정책을 위한 CloudFormation 사용](AutoScaling-with-Cloudformation-Shards.md)
+ [예약된 조정](AutoScaling-with-Scheduled-Scaling-Shards.md)
# 대상 추적 조정 정책
대상 추적 조정 정책을 사용하는 경우 지표를 선택하고 목표 값을 설정합니다. ElastiCache for Valkey 및 Redis OSS Auto Scaling은 조정 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 조정 조절을 계산합니다. 조정 정책은 필요에 따라 샤드를 추가하거나 제거하여 지표를 지정한 대상 값으로 또는 대상 값에 가깝게 유지합니다. 대상 추적 조정 정책은 지표를 목표 값에 가깝게 유지하는 것 외에도 로드 패턴의 변화로 인한 지표 변동에 따라 반응하여 플릿의 용량이 갑작스럽게 바뀌는 것을 최소화합니다.
목표 값이 구성되어 있으며 미리 정의된 평균 `ElastiCachePrimaryEngineCPUUtilization` 지표가 사용되는 조정 정책을 예로 든다면, 이러한 정책은 CPU 사용률을 지정된 목표 값에 근접하게 유지할 수 있습니다.
## 사전 정의된 지표
사전 정의된 지표는 해당 CloudWatch 지표의 특정 이름, 차원 및 통계(`average`)를 참조하는 구조입니다. Auto Scaling 정책은 클러스터에 대해 다음 사전 정의된 지표 중 하나를 정의합니다.
****
| 사전 정의된 지표 유형 | CloudWatch 지표 이름 | CloudWatch 지표 차원 | 부적격 인스턴스 유형 |
| --- | --- | --- | --- |
| ElastiCachePrimaryEngineCPUUtilization | `EngineCPUUtilization` | ReplicationGroupId, 역할 = 프라이머리 | 없음 |
| ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage | `DatabaseCapacityUsageCountedForEvictPercentage` | Valkey 또는 Redis OSS 복제 그룹 지표 | 없음 |
| ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage | `DatabaseMemoryUsageCountedForEvictPercentage` | Valkey 또는 Redis OSS 복제 그룹 지표 | R6gd |
데이터 계층형 인스턴스 유형은 데이터를 메모리와 SSD 모두에 저장하므로 `ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage`를 사용할 수 없습니다. 데이터 계층형 인스턴스의 예상 사용 사례는 100% 메모리를 사용하고 필요에 따라 SSD를 가득 채우는 것입니다.
## 샤드의 Auto Scaling 기준
서비스에서 사전 정의된 지표가 목표 설정보다 크거나 같음을 감지하면 자동으로 샤드 용량을 증가시킵니다. ElastiCache for Valkey 및 Redis OSS는 두 개의 숫자(목표 기준 변동 백분율 및 현재 샤드 수의 20%) 중 더 큰 수만큼 클러스터 샤드를 스케일 아웃합니다. 스케일 인의 경우 ElastiCache는 전체 지표 값이 정의된 목표의 75% 미만인 경우가 아니면 자동으로 스케일 인하지 않습니다.
스케일 아웃 예제로, 샤드가 50개 있다고 가정합니다.
+ 목표가 30% 위반되면 ElastiCache는 30%만큼 스케일 아웃하여 클러스터당 65개의 샤드를 유지합니다.
+ 목표가 10% 위반되면 ElastiCache는 기본적으로 최솟값인 20%만큼 스케일 아웃하여 클러스터당 60개의 샤드를 유지합니다.
스케일 인 예제로, 목표 값을 60%로 선택했다고 가정합니다. ElastiCache는 지표가 45%(목표 60%보다 25% 아래)보다 작거나 같아질 때까지 자동으로 스케일 인하지 않습니다.
## Auto Scaling 고려 사항
다음 사항에 유의하세요.
+ 대상 추적 조정 정책은 지정한 지표가 목표 값을 초과할 때 한해서 확장을 수행해야 합니다. 대상 추적 조정 정책에서는 지정한 지표가 목표 값보다 작을 때 확장할 수 없습니다. ElastiCache for Valkey 및 Redis OSS는 클러스터에 있는 기존 샤드의 목표 편차 최솟값인 20%만큼 샤드를 스케일 아웃합니다.
+ 대상 추적 조정 정책에서는 지정한 지표에 데이터가 부족할 때 조정을 수행하지 않습니다. 데이터가 부족하다고 해서 사용량이 낮은 것으로 해석하지 않기 때문에 축소를 수행하지 않습니다.
+ 목표 값과 실제 지표 데이터 포인트 사이에는 차이가 발생할 수 있습니다. 이것은 ElastiCache Auto Scaling이 추가하거나 제거할 용량을 결정할 때마다 항상 반올림 또는 내림을 통해 어림짐작으로 동작하기 때문입니다. 이는 용량을 부족하게 추가하거나 너무 많이 제거하는 일을 방지하기 위해서입니다.
+ 애플리케이션 가용성을 보장하기 위해 서비스는 지표에 비례하여 가능한 한 빠르게 스케일 아웃하지만, 스케일 인은 훨씬 보수적으로 수행합니다.
+ 각각 다른 지표를 사용한다는 전제하에 다수의 대상 추적 조정 정책을 ElastiCache for Valkey 및 Redis OSS 클러스터에 구성할 수 있습니다. ElastiCache Auto Scaling은 항상 가용성을 우선시하므로, 대상 추적 정책이 스케일 아웃 또는 스케일 인을 허용하는지에 따라 그 동작이 달라집니다. 대상 추적 정책 중 하나라도 확장을 허용할 경우 서비스를 확장하지만, 모든 대상 추적 정책(축소 부분이 활성화됨)이 축소를 허용하는 경우에만 서비스를 축소합니다.
+ ElastiCache Auto Scaling의 대상 추적 조정 정책에서 관리되는 CloudWatch 경보는 편집하거나 삭제하지 마세요. 조정 정책을 삭제하면 ElastiCache 오토 스케일링에서 경보가 자동으로 삭제됩니다.
+ ElastiCache 오토 스케일링은 클러스트 샤드를 사용자가 수동으로 수정하는 것도 허용합니다. 이러한 수동 조정은 조정 정책에 연결된 기존의 CloudWatch 경보에는 영향을 주지 않지만 이러한 CloudWatch 경보를 트리거하는 지표에 영향을 줄 수 있습니다.
+ Auto Scaling으로 관리되는 이러한 CloudWatch 경보는 클러스터의 모든 샤드에 대한 AVG 지표를 통해 정의됩니다. 따라서 사용량이 많은 샤드가 있으면 다음 시나리오 중 하나가 발생할 수 있습니다.
+ CloudWatch 경보를 트리거하는 몇 개의 사용량이 많은 샤드에 대한 로드로 인해 필요하지 않을 때 조정이 발생합니다.
+ 경보에 영향을 미치는 모든 샤드에서 집계된 AVG는 정책을 위반하지 않기 때문에 필요할 때 조정이 발생하지 않습니다.
+ 클러스터당 노드에 대한 ElastiCache의 기본 제한은 계속 적용됩니다. 따라서 Auto Scaling을 선택할 때 최대 노드 수가 기본 제한보다 클 것으로 예상되는 경우 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)에서 한도 향상을 요청하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택합니다.
+ VPC에서 스케일 아웃 중에 필요한 충분한 수의 ENI(탄력적 네트워크 인터페이스)를 사용할 수 있는지 확인합니다. 자세한 내용은 [탄력적 네트워크 인터페이스](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html)를 참조하세요.
+ EC2에서 사용할 수 있는 용량이 충분하지 않은 경우 ElastiCache 오토 스케일링은 조정하지 않고 용량을 사용할 수 있게 될 때까지 지연됩니다.
+ 스케일 인 중에 ElastiCache for Redis OSS Auto Scaling은 직렬화 후 크기가 256MB 이상인 항목이 있는 슬롯이 포함된 샤드를 제거하지 않습니다.
+ 스케일 인 중에 결과 샤드 구성에서 사용할 수 있는 메모리가 충분하지 않으면 샤드를 제거하지 않습니다.
# 조정 정책 추가
AWS Management Console을 사용하여 조정 정책을 추가할 수 있습니다.
**ElastiCache for Valkey 및 Redis OSS 클러스터에 Auto Scaling 정책을 추가하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다(클러스터 이름 왼쪽에 있는 버튼이 아닌 클러스터 이름 선택).
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **동적 크기 조정 추가(add dynamic scaling)**를 선택합니다.
1. **정책 이름**에 정책 이름을 입력합니다.
1. **조정 가능 차원**에서 **샤드**를 선택합니다.
1. 대상 지표로 다음 중 하나를 선택합니다.
+ **기본 CPU 사용률** - 평균 CPU 사용률을 기반으로 정책을 생성합니다.
+ **메모리** - 평균 데이터베이스 메모리를 기반으로 정책을 생성합니다.
+ **용량** - 평균 데이터베이스 용량 사용률을 기반으로 정책을 생성합니다. 용량 지표에는 데이터 계층형 인스턴스의 메모리 및 SSD 사용률과 기타 모든 인스턴스 유형의 메모리 사용률이 포함됩니다.
1. 목표값으로 35 이상 70 이하의 값을 선택합니다. Auto Scaling은 ElastiCache 샤드 전체에서 선택한 대상 지표에 대해 이 값을 유지합니다.
+ **프라이머리 CPU 사용률**: 프라이머리 노드의 `EngineCPUUtilization` 지표에 대한 대상 값을 유지합니다.
+ **메모리**: `DatabaseMemoryUsageCountedForEvictPercentage` 지표의 목표 값을 유지합니다.
+ **용량**: `DatabaseCapacityUsageCountedForEvictPercentage` 지표의 목표 값을 유지합니다.
클러스터 샤드가 추가되거나 제거되어 지정한 값에 가깝게 지표가 유지됩니다.
1. (선택 사항) 콘솔에서는 스케일 인 또는 스케일 아웃 휴지 기간이 지원되지 않습니다. 휴지 기간 값을 수정하려면 AWS CLI를 사용합니다.
1. **최소 용량**에 ElastiCache 오토 스케일링 정책에 따라 유지해야 할 최소 샤드 수를 입력합니다.
1. **최대 용량**에 ElastiCache 오토 스케일링 정책에 따라 유지해야 할 최대 샤드 수를 입력합니다. 이 값은 250보다 작거나 같아야 합니다.
1. **생성(Create)**을 선택합니다.
# 확장 가능 목표 등록
ElastiCache for Valkey 및 Redis OSS 클러스터에서 Auto Scaling을 사용하려면 먼저 ElastiCache Auto Scaling에 클러스터를 등록합니다. 그렇게 하려면 해당 클러스터에 적용할 크기 조정 차원 및 한계를 정의합니다. ElastiCache 오토 스케일링은 클러스터 샤드 수를 나타내는 확장 가능한 차원 `elasticache:replication-group:NodeGroups`에 따라 클러스터를 조정합니다.
** 사용AWS CLI**
ElastiCache for Valkey 및 Redis OSS 클러스터를 등록하려면 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령과 다음 파라미터를 사용합니다.
+ `--service-namespace` - 이 값을 로 설정하세요.`elasticache`
+ `--resource-id` – 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 `ReplicationGroup`이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ `--scalable-dimension` - 이 값을 로 설정하세요.`elasticache:replication-group:NodeGroups`
+ `--max-capacity ` – ElastiCache 오토 스케일링에 의해 관리되는 최대 샤드 수입니다. `--min-capacity`, `--max-capacity` 및 클러스터의 샤드 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
+ `--min-capacity ` – ElastiCache 오토 스케일링에 의해 관리되는 최소 샤드 수입니다. `--min-capacity`, `--max-capacity` 및 클러스터의 샤드 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
**Example**
다음 예제에서는 이름이 `myscalablecluster`인 ElastiCache 클러스터를 등록합니다. 등록은 1개에서 10개까지 샤드를 포함하도록 클러스터 크기를 동적으로 조정해야 함을 나타냅니다.
Linux, macOS, Unix의 경우:
```
aws application-autoscaling register-scalable-target \
--service-namespace elasticache \
--resource-id replication-group/myscalablecluster \
--scalable-dimension elasticache:replication-group:NodeGroups \
--min-capacity 1 \
--max-capacity 10 \
```
Windows의 경우:
```
aws application-autoscaling register-scalable-target ^
--service-namespace elasticache ^
--resource-id replication-group/myscalablecluster ^
--scalable-dimension elasticache:replication-group:NodeGroups ^
--min-capacity 1 ^
--max-capacity 10 ^
```
**API 사용**
ElastiCache 클러스터를 등록하려면 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령과 다음 파라미터를 사용합니다.
+ ServiceNamespace - 이 값을 elasticache로 설정합니다.
+ ResourceID – ElastiCache 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ ScalableDimension - 이 값을 `elasticache:replication-group:NodeGroups`로 설정합니다.
+ MinCapacity – ElastiCache 오토 스케일링에 의해 관리되는 최소 샤드 수입니다. --min-capacity, --max-capacity 및 클러스터의 복제본 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
+ MaxCapacity – ElastiCache 오토 스케일링에 의해 관리되는 최대 샤드 수입니다. --min-capacity, --max-capacity 및 클러스터의 복제본 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
**Example**
다음 예제에서는 Application Auto Scaling API를 사용하여 이름이 `myscalablecluster`인 ElastiCache 클러스터를 등록합니다. 이 등록은 1개에서 5개까지 복제본을 포함하도록 클러스터 크기를 동적으로 조정해야 함을 나타냅니다.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"MinCapacity": 1,
"MaxCapacity": 5
}
```
# 조정 정책 정의
대상 추적 조정 정책 구성은 지표와 대상 값이 정의되어 있는 JSON 블록으로 나타냅니다. 텍스트 파일에 JSON 블록으로 조정 정책 구성을 저장할 수 있습니다. AWS CLI 또는 Application Auto Scaling API를 호출할 때 이 텍스트 파일을 사용합니다. 정책 구성 구문에 대한 자세한 정보는 Application Auto Scaling API 참조의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.
대상 추적 조정 정책 구성을 정의하기 위해 다음과 같은 옵션을 사용할 수 있습니다.
**Topics**
+ [미리 정의된 지표 사용](#AutoScaling-Scaling-Predefined-Metric)
+ [사용자 지정 지표 사용](#AutoScaling-Scaling-Custom-Metric)
+ [휴지 기간 사용](#AutoScaling-Scaling-Cooldown-periods)
## 미리 정의된 지표 사용
미리 정의된 지표를 사용하여 ElastiCache Auto Scaling의 대상 추적에서 작동하는 ElastiCache for Valkey 및 Redis OSS 클러스터에 대한 대상 추적 조정 정책을 신속하게 정의할 수 있습니다.
현재 ElastiCache는 NodeGroup 오토 스케일링에서 다음과 같이 미리 정의된 지표를 지원합니다.
+ **ElastiCachePrimaryEngineCPUUtilization** – 클러스터의 모든 프라이머리 노드에 대한 CloudWatch의 `EngineCPUUtilization` 지표 평균 값입니다.
+ **ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage** – 클러스터의 모든 프라이머리 노드에 대한 CloudWatch의 `DatabaseMemoryUsageCountedForEvictPercentage` 지표 평균 값입니다.
+ **ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage** – 클러스터의 모든 프라이머리 노드에 대한 CloudWatch의 `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` 지표 평균 값입니다.
`EngineCPUUtilization`, `DatabaseMemoryUsageCountedForEvictPercentage` 및 `DatabaseCapacityUsageCountedForEvictPercentage` 지표에 대한 자세한 정보는 [CloudWatch 지표를 사용한 사용량 모니터링](CacheMetrics.md) 섹션을 참조하세요. 조정 정책에서 미리 정의된 지표를 사용하려면 조정 정책을 위한 대상 추적 구성을 생성합니다. 미리 정의된 지표의 `PredefinedMetricSpecification` 및 해당 지표의 대상 값에 대한 TargetValue를 이 구성에 포함해야 합니다.
**Example**
다음 예제에서는 ElastiCache for Valkey 및 Redis OSS 클러스터의 대상 추적 조정을 위한 일반적인 정책 구성을 설명합니다. 이 구성에서 `ElastiCachePrimaryEngineCPUUtilization` 미리 정의된 지표는 해당 클러스터에 있는 모든 프라이머리 노드에 대해 평균 CPU 사용률 40%를 기반으로 클러스터를 조정하는 데 사용됩니다.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
```
## 사용자 지정 지표 사용
사용자 지정 지표를 사용하여 사용자 지정 요구 사항에 맞는 대상 추적 조정 정책을 정의할 수 있습니다. 조정에 따라 변경되는 모든 ElastiCache 지표를 기반으로 사용자 지정 지표를 정의할 수 있습니다. 일부 ElastiCache 지표를 대상 추적에 사용할 수 있습니다. 지표는 유효한 사용량 수치로서 인스턴스의 사용량을 설명해야 합니다. 클러스터에 있는 샤드 수에 따라 지표 값이 증가하거나 줄어들어야 합니다. 지표 데이터를 사용하여 샤드 수를 비례적으로 확장 또는 축소하려면 이 비례적인 증가나 감소가 필요합니다.
**Example**
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 사용자 지정 지표는 `my-db-cluster`라는 클러스터의 모든 샤드에 대해 평균 CPU 사용률 50%를 기반으로 ElastiCache for Redis OSS 클러스터를 조정합니다.
```
{
"TargetValue": 50,
"CustomizedMetricSpecification":
{
"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{
"Name": "ReplicationGroup","Value": "my-db-cluster"
},
{
"Name": "Role","Value": "PRIMARY"
}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
## 휴지 기간 사용
`ScaleOutCooldown`에 초 단위로 값을 지정하여 클러스터를 확장하기 위한 휴지 기간을 추가할 수 있습니다. 마찬가지로 `ScaleInCooldown`에 초 단위로 값을 추가하여 클러스터를 축소하기 위한 휴지 기간을 추가할 수 있습니다. 자세한 내용은 Application Auto Scaling API 참조의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 `ElastiCachePrimaryEngineCPUUtilization` 미리 정의된 지표는 해당 클러스터에 있는 모든 프라이머리 노드에 대해 평균 CPU 사용률 40%를 기반으로 ElastiCache for Redis OSS 클러스터를 조정하는 데 사용됩니다. 구성에서는 스케일 인 휴지 기간 10분과 스케일 아웃 휴지 기간 5분을 제공합니다.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
# 스케일 인 활동 비활성화
축소 활동을 비활성화하여 대상 추적 조정 정책 구성에서 클러스터를 축소하지 않도록 할 수 있습니다. 스케일 인 활동을 비활성화하면 조정 정책에서 필요에 따라 샤드를 생성할 수 있지만 삭제할 수는 없습니다.
`DisableScaleIn`에 부울 값을 지정하여 클러스터에 대한 스케일 인 활동을 활성화하거나 비활성화할 수 있습니다. 자세한 내용은 Application Auto Scaling API 참조의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 `ElastiCachePrimaryEngineCPUUtilization` 미리 정의된 지표는 해당 클러스터에 있는 모든 프라이머리 노드에 대해 평균 CPU 사용률 40%를 기반으로 ElastiCache for Valkey 및 Redis OSS 클러스터를 조정합니다. 구성에서는 조정 정책의 스케일 인 활동을 비활성화합니다.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
# 조정 정책 적용
ElastiCache for Valkey 및 Redis OSS Auto Scaling으로 클러스터를 등록하고 조정 정책을 정의한 후 등록된 클러스터에 조정 정책을 적용합니다. 조정 정책을 ElastiCache for Redis OSS 클러스터에 적용하려면 AWS CLI 또는 Application Auto Scaling API를 사용할 수 있습니다.
## AWS CLI를 사용하여 조정 정책 적용
ElastiCache for Valkey 및 Redis OSS 클러스터에 조정 정책을 적용하려면 다음 파라미터와 함께 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 명령을 사용합니다.
+ **--policy-name** – 조정 정책의 이름입니다.
+ **--policy-type** – 이 값을 `TargetTrackingScaling`으로 설정합니다.
+ **--resource-id** – 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 `ReplicationGroup`이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ **--service-namespace** – 이 값을 `elasticache`로 설정합니다.
+ **--scalable-dimension** – 이 값을 `elasticache:replication-group:NodeGroups`로 설정합니다.
+ **--target-tracking-scaling-policy-configuration** – 클러스터에 사용할 대상 추적 조정 정책 구성입니다.
다음 예제에서는 ElastiCache Auto Scaling을 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 ElastiCache for Valkey 및 Redis OSS 클러스터에 적용합니다. 이를 위해 `config.json`이라는 파일에 저장된 정책 구성을 사용합니다.
Linux, macOS 또는 Unix의 경우는 다음과 같습니다.
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups \
--target-tracking-scaling-policy-configuration file://config.json
```
Windows의 경우:
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups ^
--target-tracking-scaling-policy-configuration file://config.json
```
## API를 사용하여 조정 정책 적용
ElastiCache for Valkey 및 Redis OSS 클러스터에 조정 정책을 적용하려면 다음 파라미터와 함께 [PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) AWS CLI 명령을 사용합니다.
+ **--policy-name** – 조정 정책의 이름입니다.
+ **--resource-id** – 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 `ReplicationGroup`이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ **--service-namespace** – 이 값을 `elasticache`로 설정합니다.
+ **--scalable-dimension** – 이 값을 `elasticache:replication-group:NodeGroups`로 설정합니다.
+ **--target-tracking-scaling-policy-configuration** – 클러스터에 사용할 대상 추적 조정 정책 구성입니다.
다음 예제에서는 ElastiCache Auto Scaling을 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 ElastiCache 클러스터에 적용합니다. `ElastiCachePrimaryEngineCPUUtilization` 사전 정의 지표를 기반으로 하는 정책 구성을 사용합니다.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
}
```
# 조정 정책 편집
AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 편집할 수 있습니다.
## AWS Management Console을 사용하여 조정 정책 편집
**ElastiCache for Valkey 및 Redis OSS 클러스터에 대한 Auto Scaling 정책을 편집하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 적절한 엔진을 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다(클러스터 이름 왼쪽에 있는 버튼이 아닌 클러스터 이름 선택).
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **조정 정책(Scaling policies)**에서 변경할 자동 크기 조정 정책 왼쪽에 있는 버튼을 선택한 다음 **수정(Modify)**을 선택합니다.
1. 정책을 필요에 따라 변경합니다.
1. **수정**을 선택합니다.
## AWS CLI 및 API를 사용하여 조정 정책 편집
크기 조정 정책을 적용하는 것과 같은 방식으로 AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 편집할 수 있습니다.
+ AWS CLI를 사용할 때는 `--policy-name` 파라미터에서 편집할 정책의 이름을 지정하세요. 변경할 파라미터의 새로운 값을 지정합니다.
+ Application Auto Scaling API를 사용할 때는 `PolicyName` 파라미터에서 편집하려는 정책의 이름을 지정하세요. 변경할 파라미터의 새로운 값을 지정합니다.
자세한 내용은 [조정 정책 적용](AutoScaling-Scaling-Applying-a-Scaling-Policy.md) 섹션을 참조하세요.
# 조정 정책 삭제
AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 삭제할 수 있습니다.
## AWS Management Console을 사용하여 조정 정책 삭제
**ElastiCache for Redis OSS 클러스터의 Auto Scaling 정책을 삭제하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 자동 크기 조정 정책을 편집할 클러스터를 선택합니다(클러스터 이름 왼쪽에 있는 버튼이 아닌 클러스터 이름 선택).
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **조정 정책(Scaling policies)**에서 자동 크기 조정 정책을 선택한 후 **삭제(Delete)**를 선택합니다.
## AWS CLI을 사용하여 조정 정책 삭제
ElastiCache for Valkey 및 Redis OSS 클러스터에 대한 조정 정책을 삭제하려면 다음 파라미터와 함께 [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI 명령을 사용합니다.
+ **--policy-name** – 조정 정책의 이름입니다.
+ **--resource-id** – 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 `ReplicationGroup`이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ **--service-namespace** – 이 값을 `elasticache`로 설정합니다.
+ **--scalable-dimension** – 이 값을 `elasticache:replication-group:NodeGroups`로 설정합니다.
다음 예제에서는 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 클러스터에서 삭제합니다.
Linux, macOS, Unix의 경우:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups
```
Windows의 경우:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups
```
## API를 사용하여 조정 정책 삭제
ElastiCache for Valkey 및 Redis OSS 클러스터에 대한 조정 정책을 삭제하려면 다음 파라미터와 함께 [DeleteScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI 명령을 사용합니다.
+ **--policy-name** – 조정 정책의 이름입니다.
+ **--resource-id** – 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 `ReplicationGroup`이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ **--service-namespace** – 이 값을 `elasticache`로 설정합니다.
+ **--scalable-dimension** – 이 값을 `elasticache:replication-group:NodeGroups`로 설정합니다.
다음 예제에서는 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 클러스터에서 삭제합니다.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups"
}
```
# Auto Scaling 정책을 위한 CloudFormation 사용
이 코드 조각은 대상 추적 정책을 생성하고 [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) 리소스를 사용하여 [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) 리소스에 적용하는 방법을 보여줍니다. [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) 및 [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) 내장 함수를 사용하여 동일한 템플릿에 지정된 `AWS::ElastiCache::ReplicationGroup` 리소스의 논리적 이름으로 `ResourceId` 속성을 구성합니다.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:NodeGroups'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCachePrimaryEngineCPUUtilization
TargetValue: 40
```
# 예약된 조정
일정을 기반으로 조정을 수행하면 수요에 따른 로드 변경에 맞게 애플리케이션을 조정할 수 있습니다. 예약된 조정을 사용하려면 ElastiCache for Valkey 및 Redis OSS가 특정 시간에 조정 작업을 수행하도록 하는 예약된 작업을 생성할 수 있습니다. 예약된 작업을 생성할 때, 기존 클러스터, 규모 조정 활동이 발생해야 할 시점, 최소 용량 및 최대 용량을 지정할 수 있습니다. 규모를 한 번만 조정하거나 반복되는 일정으로 조정하도록 예약된 작업을 생성할 수 있습니다.
이미 존재하는 클러스터에 대한 예약된 작업만 생성할 수 있습니다. 클러스터를 생성하는 동시에 예약된 작업을 생성할 수는 없습니다.
예약된 작업 생성, 관리 및 삭제와 관련된 용어에 대한 자세한 내용은 [예약된 작업 생성, 관리 및 삭제에 일반적으로 사용되는 명령](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)을 참조하세요.
**반복되는 일정으로 생성하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다.
1. **작업** 드롭다운 목록에서 **Auto Scaling 정책 관리**를 선택합니다.
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **Auto Scaling 정책** 섹션에서 **조정 정책 추가** 대화 상자가 나타납니다. **예약된 조정**을 선택합니다.
1. **정책 이름**에 정책 이름을 입력합니다.
1. **조정 가능 차원**에서 **샤드**를 선택합니다.
1. **대상 샤드**에서 값을 선택합니다.
1. **반복**에서 **반복**을 선택합니다.
1. **빈도**에서 해당하는 값을 선택합니다.
1. **시작일** 및 **시작 시간**에서 정책이 시행될 시간을 선택합니다.
1. **정책 추가**를 선택합니다.
**1회성 예약된 작업을 생성하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다.
1. **작업** 드롭다운 목록에서 **Auto Scaling 정책 관리**를 선택합니다.
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **Auto Scaling 정책** 섹션에서 **조정 정책 추가** 대화 상자가 나타납니다. **예약된 조정**을 선택합니다.
1. **정책 이름**에 정책 이름을 입력합니다.
1. **조정 가능 차원**에서 **샤드**를 선택합니다.
1. **대상 샤드**에서 값을 선택합니다.
1. **반복**에서 **한 번**을 선택합니다.
1. **시작일** 및 **시작 시간**에서 정책이 시행될 시간을 선택합니다.
1. **종료일**에서 정책이 시행되는 기한을 선택합니다.
1. **정책 추가**를 선택합니다.
**예약된 작업을 삭제하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다.
1. **작업** 드롭다운 목록에서 **Auto Scaling 정책 관리**를 선택합니다.
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **Auto Scaling 정책** 섹션에서 Auto Scaling 정책을 선택한 다음 **작업** 메뉴에서 **삭제**를 선택합니다.
**를 사용하여 예약된 조정을 관리하려면 AWS CLI**
다음과 같은 애플리케이션 자동 크기 조정 API를 사용합니다.
+ [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-action.html)
+ [describe-scheduled-actions](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-scheduled-actions.html)
+ [delete-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scheduled-action.html)
## CloudFormation을 사용하여 예약된 작업 생성
이 코드 조각은 대상 추적 정책을 생성하고 [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) 리소스를 사용하여 [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) 리소스에 적용하는 방법을 보여줍니다. [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) 및 [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) 내장 함수를 사용하여 동일한 템플릿에 지정된 `AWS::ElastiCache::ReplicationGroup` 리소스의 논리적 이름으로 `ResourceId` 속성을 구성합니다.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
```
# 복제본에 Auto Scaling 사용
ElastiCache 복제 그룹은 단일 논리적 노드로 작동하도록 하나 이상의 캐시를 설정할 수 있습니다.
다음은 대상 추적 및 예약된 정책에 대한 세부 정보와 AWS Management Console AWS CLI 및 API를 사용하여 이를 적용하는 방법을 제공합니다.
# 대상 추적 조정 정책
대상 추적 조정 정책을 사용하는 경우 지표를 선택하고 목표 값을 설정합니다. ElastiCache for Valkey 및 Redis OSS Auto Scaling은 조정 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 조정 조절을 계산합니다. 조정 정책은 필요에 따라 모든 샤드에서 균등하게 복제본을 추가하거나 제거하여 지표를 지정한 대상 값으로 또는 대상 값에 가깝게 유지합니다. 대상 추적 조정 정책은 지표를 목표 값에 가깝게 유지하는 것 외에도 로드 패턴의 변화로 인한 지표 변동에 따라 반응하여 플릿의 용량이 갑작스럽게 바뀌는 것을 최소화합니다.
## 복제본에 대한 Auto Scaling 기준
Auto Scaling 정책은 클러스터에 대해 다음과 같은 사전 정의된 지표를 정의합니다.
`ElastiCacheReplicaEngineCPUUtilization`: ElastiCache가 오토 스케일링 작업을 트리거하는 데 사용하는 모든 복제본에서 집계된 AVG EngineCPU 사용률 임계값입니다. 사용률 목표를 35%에서 70% 사이로 설정할 수 있습니다.
서비스에서 `ElastiCacheReplicaEngineCPUUtilization` 지표가 목표 설정보다 크거나 같음을 감지하면 자동으로 샤드 전체에서 복제본을 증가시킵니다. ElastiCache는 2개의 숫자(목표 및 한 복제본 기준 변동 백분율) 중 더 큰 수만큼 클러스터 복제본을 스케일 아웃합니다. 스케일 인의 경우 ElastiCache는 전체 지표 값이 정의된 목표의 75% 미만인 경우가 아니면 자동으로 스케일 인하지 않습니다.
스케일 아웃 예제로, 샤드가 5개 있고 각각 복제본 1개가 있다고 가정합니다.
목표가 30% 위반되면 ElastiCache for Valkey 및 Redis OSS는 모든 샤드에서 복제본 1개(max(0.3, 기본값 1))씩 스케일 아웃합니다. 결과적으로 5개 샤드 각각이 복제본 2개를 갖게 됩니다.
스케일 인 예제로, 목표 값을 60%로 선택했다고 가정합니다. ElastiCache for Valkey 및 Redis OSS는 지표가 45%(목표 60%보다 25% 아래)보다 작거나 같아질 때까지 자동으로 스케일 인하지 않습니다.
### Auto Scaling 고려 사항
다음 사항에 유의하세요.
+ 대상 추적 조정 정책은 지정한 지표가 목표 값을 초과할 때 한해서 확장을 수행해야 합니다. 대상 추적 조정 정책에서는 지정한 지표가 목표 값보다 작을 때 확장할 수 없습니다. ElastiCache for Valkey 및 Redis OSS는 클러스터의 모든 샤드에서 기존 복제본의 최댓값(목표에서 반올림된 % 편차, 기본값 1)까지 복제본을 스케일 아웃합니다.
+ 대상 추적 조정 정책에서는 지정한 지표에 데이터가 부족할 때 조정을 수행하지 않습니다. 데이터가 부족하다고 해서 사용량이 낮은 것으로 해석하지 않기 때문에 축소를 수행하지 않습니다.
+ 목표 값과 실제 지표 데이터 포인트 사이에는 차이가 발생할 수 있습니다. 이것은 ElastiCache Auto Scaling이 추가하거나 제거할 용량을 결정할 때마다 항상 반올림 또는 내림을 통해 어림짐작으로 동작하기 때문입니다. 이는 용량을 부족하게 추가하거나 너무 많이 제거하는 일을 방지하기 위해서입니다.
+ 애플리케이션 가용성을 보장하기 위해 서비스는 지표에 비례하여 가능한 한 빠르게 스케일 아웃하지만, 스케일 인은 클러스터의 전체 샤드에서 복제본 1개의 최대 스케일 인을 사용하여 비교적 점진적으로 진행됩니다.
+ 각각 다른 지표를 사용한다는 전제 하에 다수의 대상 추적 조정 정책을 ElastiCache for Valkey 및 Redis OSS 클러스터에 구성할 수 있습니다. 오토 스케일링은 항상 가용성을 우선시하므로, 대상 추적 정책이 스케일 아웃 또는 스케일 인을 허용하는지에 따라 그 동작이 달라집니다. 대상 추적 정책 중 하나라도 확장을 허용할 경우 서비스를 확장하지만, 모든 대상 추적 정책(축소 부분이 활성화됨)이 축소를 허용하는 경우에만 서비스를 축소합니다.
+ ElastiCache Auto Scaling의 대상 추적 조정 정책에서 관리되는 CloudWatch 경보는 편집하거나 삭제하지 마세요. 조정 정책을 삭제하거나 클러스터를 삭제하면 오토 스케일링에서 경보가 자동으로 삭제됩니다.
+ ElastiCache Auto Scaling은 샤드 전체에서 복제본을 사용자가 수동으로 수정하는 것도 허용합니다. 이러한 수동 조정은 조정 정책에 연결된 기존의 CloudWatch 경보에는 영향을 주지 않지만 이러한 CloudWatch 경보를 트리거하는 지표에 영향을 줄 수 있습니다.
+ Auto Scaling으로 관리되는 이러한 CloudWatch 경보는 클러스터의 모든 샤드에 대한 AVG 지표를 통해 정의됩니다. 따라서 사용량이 많은 샤드가 있으면 다음 시나리오 중 하나가 발생할 수 있습니다.
+ CloudWatch 경보를 트리거하는 몇 개의 사용량이 많은 샤드에 대한 로드로 인해 필요하지 않을 때 조정이 발생합니다.
+ 경보에 영향을 미치는 모든 샤드에서 집계된 AVG는 정책을 위반하지 않기 때문에 필요할 때 조정이 발생하지 않습니다.
+ 클러스터당 노드에 대한 ElastiCache의 기본 제한은 계속 적용됩니다. 따라서 Auto Scaling을 선택할 때 최대 노드 수가 기본 제한보다 클 것으로 예상되는 경우 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)에서 한도 향상을 요청하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택합니다.
+ VPC에서 스케일 아웃 중에 필요한 충분한 수의 ENI(탄력적 네트워크 인터페이스)를 사용할 수 있는지 확인합니다. 자세한 내용은 [탄력적 네트워크 인터페이스](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html)를 참조하세요.
+ EC2에서 사용할 수 있는 용량이 충분하지 않은 경우 ElastiCache Auto Scaling은 용량을 사용할 수 있을 때까지 또는 클러스터를 충분한 용량이 있는 인스턴스 유형으로 수동으로 수정할 때까지 스케일 아웃하지 않습니다.
+ ElastiCache Auto Scaling은 클러스터의 `ReservedMemoryPercent`가 25% 미만인 복제본의 조정을 지원하지 않습니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 섹션을 참조하세요.
# 조정 정책 추가
AWS Management Console을 사용하여 조정 정책을 추가할 수 있습니다.
**AWS Management Console을 사용하여 조정 정책 추가**
ElastiCache for Valkey 및 Redis OSS에 오토 스케일링 정책을 추가하는 방법
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다(클러스터 이름 왼쪽에 있는 버튼이 아닌 클러스터 이름 선택).
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **동적 크기 조정 추가(add dynamic scaling)**를 선택합니다.
1. **조정 정책(Scaling policies)**에서 **동적 크기 조정 추가(Add dynamic scaling)**를 선택합니다.
1. **정책 이름**에 정책 이름을 입력합니다.
1. **조정 가능 차원**의 대화 상자에서 **복제본**을 선택합니다.
1. 목표 값에 ElastiCache 복제본에서 유지하려는 CPU 사용률의 평균 백분율을 입력합니다. 이 값은 >=35 및 <=70이어야 합니다. 클러스터 복제본이 추가되거나 제거되어 지정한 값에 가깝게 지표가 유지됩니다.
1. (선택 사항) 콘솔에서는 스케일 인 또는 스케일 아웃 휴지 기간이 지원되지 않습니다. 휴지 기간 값을 수정하려면 AWS CLI를 사용합니다.
1. **최소 용량**에 ElastiCache Auto Scaling 정책에 따라 유지해야 할 최소 복제본 수를 입력합니다.
1. **최대 용량**에 ElastiCache Auto Scaling 정책에 따라 유지해야 할 최대 복제본 수를 입력합니다. 이 값은 >=5이어야 합니다.
1. **생성(Create)**을 선택합니다.
# 확장 가능 목표 등록
미리 정의된 지표나 사용자 지정 지표를 기반으로 조정 정책을 적용할 수 있습니다. 이를 위해 AWS CLI 또는 Application Auto Scaling API를 사용할 수 있습니다. 첫 번째 단계는 Auto Scaling을 사용하여 ElastiCache for Valkey 및 Redis OSS 복제 그룹을 등록하는 것입니다.
클러스터에서 ElastiCache Auto Scaling을 사용하려면 먼저 ElastiCache Auto Scaling을 사용하여 클러스터를 등록해야 합니다. 그렇게 하려면 해당 클러스터에 적용할 크기 조정 차원 및 한계를 정의합니다. ElastiCache Auto Scaling은 샤드당 클러스터 복제본 수를 나타내는 확장 가능한 차원 `elasticache:replication-group:Replicas`에 따라 클러스터를 조정합니다.
**CLI 사용**:
ElastiCache 클러스터를 등록하려면 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령과 다음 파라미터를 사용합니다.
+ --service-namespace – 이 값을 elasticache로 설정합니다.
+ --resource-id – ElastiCache 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ --scalable-dimension – 이 값을 로 설정합니다`elasticache:replication-group:Replicas`
+ --min-capacity – ElastiCache Auto Scaling에 의해 관리되는 최소 복제본 수입니다. --min-capacity, --max-capacity 및 클러스터의 복제본 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
+ --max-capacity – ElastiCache Auto Scaling에 의해 관리되는 최대 복제본 수입니다. --min-capacity, --max-capacity 및 클러스터의 복제본 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
**Example**
다음 예제에서는 이름이 `myscalablecluster`인 ElastiCache 클러스터를 등록합니다. 등록은 1개에서 5개까지 복제본을 포함하도록 클러스터 크기를 동적으로 조정해야 함을 나타냅니다.
Linux, macOS, Unix의 경우:
```
aws application-autoscaling register-scalable-target \
--service-namespace elasticache \
--resource-id replication-group/myscalablecluster \
--scalable-dimension elasticache:replication-group:Replicas \
--min-capacity 1 \
--max-capacity 5 \
```
Windows의 경우:
```
aws application-autoscaling register-scalable-target ^
--service-namespace elasticache ^
--resource-id replication-group/myscalablecluster ^
--scalable-dimension elasticache:replication-group:Replicas ^
--min-capacity 1 ^
--max-capacity 5 ^
```
**API 사용**
ElastiCache 클러스터를 등록하려면 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령과 다음 파라미터를 사용합니다.
+ ServiceNamespace - 이 값을 elasticache로 설정합니다.
+ ResourceID – ElastiCache 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ ScalableDimension - 이 값을 `elasticache:replication-group:Replicas`로 설정합니다.
+ MinCapacity – ElastiCache Auto Scaling에 의해 관리되는 최소 복제본 수입니다. --min-capacity, --max-capacity 및 클러스터의 복제본 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
+ MaxCapacity – ElastiCache Auto Scaling에 의해 관리되는 최대 복제본 수입니다. --min-capacity, --max-capacity 및 클러스터의 복제본 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](AutoScaling-Policies.md#AutoScaling-MinMax) 섹션을 참조하세요.
**Example**
다음 예제에서는 Application 오토 스케일링 API를 사용하여 이름이 `myscalablecluster`인 클러스터를 등록합니다. 이 등록은 1개에서 5개까지 복제본을 포함하도록 클러스터 크기를 동적으로 조정해야 함을 나타냅니다.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"MinCapacity": 1,
"MaxCapacity": 5
}
```
# 조정 정책 정의
대상 추적 조정 정책 구성은 지표와 대상 값이 정의되어 있는 JSON 블록으로 나타냅니다. 텍스트 파일에 JSON 블록으로 조정 정책 구성을 저장할 수 있습니다. AWS CLI 또는 Application Auto Scaling API를 호출할 때 이 텍스트 파일을 사용합니다. 정책 구성 구문에 대한 자세한 정보는 *Application Auto Scaling API 참조*의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.
대상 추적 조정 정책 구성을 정의하기 위해 다음과 같은 옵션을 사용할 수 있습니다.
**Topics**
+ [미리 정의된 지표 사용](#AutoScaling-Predefined-Metric)
+ [조정 정책 편집](AutoScaling-Editing-Policy.md)
+ [조정 정책 삭제](AutoScaling-Deleting-Policy.md)
+ [Auto Scaling 정책을 위한 CloudFormation 사용](AutoScaling-with-Cloudformation.md)
+ [예약된 조정](AutoScaling-with-Scheduled-Scaling-Replicas.md)
## 미리 정의된 지표 사용
대상 추적 조정 정책 구성은 지표와 대상 값이 정의되어 있는 JSON 블록으로 나타냅니다. 텍스트 파일에 JSON 블록으로 조정 정책 구성을 저장할 수 있습니다. AWS CLI 또는 Application Auto Scaling API를 호출할 때 이 텍스트 파일을 사용합니다. 정책 구성 구문에 대한 자세한 정보는 *Application Auto Scaling API 참조*의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.
대상 추적 조정 정책 구성을 정의하기 위해 다음과 같은 옵션을 사용할 수 있습니다.
**Topics**
+ [미리 정의된 지표 사용](#AutoScaling-Predefined-Metric)
+ [사용자 지정 지표 사용](#AutoScaling-Custom-Metric)
+ [휴지 기간 사용](#AutoScaling-Using-Cooldowns)
+ [스케일 인 활동 비활성화](#AutoScaling-Disabling-Scalein)
+ [ElastiCache for Valkey 및 Redis OSS 클러스터에 조정 정책 적용](#AutoScaling-Applying-Policy)
### 미리 정의된 지표 사용
미리 정의된 지표를 사용하여 ElastiCache Auto Scaling의 대상 추적에서 작동하는 ElastiCache for Valkey 및 Redis OSS 클러스터에 대한 대상 추적 조정 정책을 신속하게 정의할 수 있습니다. 현재 ElastiCache는 ElastiCache 복제본 오토 스케일링에서 다음과 같이 미리 정의된 지표를 지원합니다.
`ElastiCacheReplicaEngineCPUUtilization` – 클러스터의 모든 복제본에 대한 CloudWatch의 EngineCPUUtilization 지표 평균 값입니다. CloudWatch의 집계된 지표 값은 필요한 ReplicationGroupId 및 Role Replica에 대한 ElastiCache `ReplicationGroupId, Role`에서 찾을 수 있습니다.
조정 정책에서 미리 정의된 지표를 사용하려면 조정 정책을 위한 대상 추적 구성을 생성합니다. 미리 정의된 지표의 `PredefinedMetricSpecification` 및 해당 지표의 대상 값에 대한 `TargetValue`를 이 구성에 포함해야 합니다.
### 사용자 지정 지표 사용
사용자 지정 지표를 사용하여 사용자 지정 요구 사항에 맞는 대상 추적 조정 정책을 정의할 수 있습니다. 조정에 따라 변경되는 모든 ElastiCache for Valkey 및 Redis OSS 지표를 기반으로 사용자 지정 지표를 정의할 수 있습니다. 일부 ElastiCache 지표를 대상 추적에 사용할 수 있습니다. 지표는 유효한 사용량 수치로서 인스턴스의 사용량을 설명해야 합니다. 클러스터에 있는 복제본 수에 비례하여 지표 값이 증가하거나 줄어들어야 합니다. 지표 데이터를 사용하여 복제본 수를 비례적으로 늘리거나 줄이려면 이 비례적인 증가나 감소가 필요합니다.
**Example**
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 사용자 지정 지표는 `my-db-cluster`라는 클러스터의 모든 복제본에 대해 평균 CPU 사용률 50%를 기반으로 클러스터를 조정합니다.
```
{"TargetValue": 50,
"CustomizedMetricSpecification":
{"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{"Name": "ReplicationGroup","Value": "my-db-cluster"},
{"Name": "Role","Value": "REPLICA"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
### 휴지 기간 사용
`ScaleOutCooldown`에 초 단위로 값을 지정하여 클러스터를 확장하기 위한 휴지 기간을 추가할 수 있습니다. 마찬가지로 `ScaleInCooldown`에 초 단위로 값을 추가하여 클러스터를 축소하기 위한 휴지 기간을 추가할 수 있습니다. `ScaleInCooldown` 및 `ScaleOutCooldown`에 대한 자세한 내용은 *Application Auto Scaling API 참조*의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요. 다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 `ElastiCacheReplicaEngineCPUUtilization`미리 정의된 지표는 해당 클러스터의 모든 복제본에서 40%의 평균 CPU 사용률을 기준으로 클러스터를 조정하는 데 사용됩니다. 구성에서는 스케일 인 휴지 기간 10분과 스케일 아웃 휴지 기간 5분을 제공합니다.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
### 스케일 인 활동 비활성화
스케일 인 활동을 비활성화하여 대상 추적 조정 정책 구성에서 ElastiCache for Valkey 및 Redis OSS 클러스터를 축소하지 않도록 할 수 있습니다. 스케일 인 활동을 비활성화하면 조정 정책에서 필요에 따라 복제본을 추가할 수 있지만 삭제할 수는 없습니다.
`DisableScaleIn`에 부울 값을 지정하여 클러스터에 대한 스케일 인 활동을 활성화하거나 비활성화할 수 있습니다. `DisableScaleIn`에 대한 자세한 내용은 *Application Auto Scaling API 참조*의 [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.
**Example**
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 `ElastiCacheReplicaEngineCPUUtilization` 미리 정의된 지표는 해당 클러스터에 있는 모든 복제본에 대해 평균 CPU 사용률 40%를 기반으로 클러스터를 조정합니다. 구성에서는 조정 정책의 스케일 인 활동을 비활성화합니다.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
### ElastiCache for Valkey 및 Redis OSS 클러스터에 조정 정책 적용
ElastiCache for Valkey 및 Redis OSS Auto Scaling으로 클러스터를 등록하고 조정 정책을 정의한 후 등록된 클러스터에 조정 정책을 적용합니다. 조정 정책을 ElastiCache for Valkey 및 Redis OSS 클러스터에 적용하려면 AWS CLI 또는 Application Auto Scaling API를 사용할 수 있습니다.
** 사용AWS CLI**
ElastiCache for Valkey 및 Redis OSS 클러스터에 조정 정책을 적용하려면 다음 파라미터와 함께 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용합니다.
+ --policy-name – 조정 정책의 이름입니다.
+ --policy-type – 이 값을 으로 설정합니다`TargetTrackingScaling`
+ --resource-id – 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ --service-namespace – 이 값을 elasticache로 설정합니다.
+ --scalable-dimension – 이 값을 `elasticache:replication-group:Replicas`로 설정합니다.
+ --target-tracking-scaling-policy-configuration – 클러스터에 사용할 대상 추적 조정 정책 구성입니다.
**Example**
다음 예제에서는 ElastiCache Auto Scaling을 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 클러스터에 적용합니다. 이를 위해 `config.json`이라는 파일에 저장된 정책 구성을 사용합니다.
Linux, macOS 또는 Unix의 경우는 다음과 같습니다.
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
--target-tracking-scaling-policy-configuration file://config.json
```
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
Windows의 경우:
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:Replicas ^
--target-tracking-scaling-policy-configuration file://config.json
```
**API 사용**
Application Auto Scaling API를 사용하여 ElastiCache 클러스터에 조정 정책을 적용하려면 다음 파라미터와 함께 [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) Application Auto Scaling API 작업을 사용합니다.
+ PolicyName – 조정 정책의 이름입니다.
+ PolicyType – 이 값을 `TargetTrackingScaling`으로 설정합니다.
+ ResourceID – 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 ElastiCache for Redis OSS 클러스터의 이름입니다.
+ ServiceNamespace - 이 값을 elasticache로 설정합니다.
+ ScalableDimension - 이 값을 `elasticache:replication-group:Replicas`로 설정합니다.
+ TargetTrackingScalingPolicyConfiguration – 클러스터에 사용할 대상 추적 조정 정책 구성입니다.
**Example**
다음 예제에서는 ElastiCache Auto Scaling을 사용하여 `scalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 클러스터에 적용합니다. `ElastiCacheReplicaEngineCPUUtilization` 사전 정의 지표를 기반으로 하는 정책 구성을 사용합니다.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
}
}
}
```
# 조정 정책 편집
AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 편집할 수 있습니다.
**AWS Management Console을 사용하여 조정 정책 편집**
AWS Management Console을 사용하여 미리 정의된 지표 유형이 있는 정책을 편집할 수 있습니다.
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 정책을 추가할 클러스터를 선택합니다(클러스터 이름 왼쪽에 있는 버튼이 아닌 클러스터 이름 선택).
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **조정 정책(Scaling policies)**에서 변경할 자동 크기 조정 정책 왼쪽에 있는 버튼을 선택한 다음 **수정(Modify)**을 선택합니다.
1. 정책을 필요에 따라 변경합니다.
1. **수정**을 선택합니다.
1. 정책을 변경합니다.
1. **수정**을 선택합니다.
**AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책 편집 **
스케일링 정책을 적용하는 것과 같은 방식으로 AWS CLI 또는 Application Auto Scaling API를 사용하여 스케일링 정책을 편집할 수 있습니다.
+ Application Auto Scaling API를 사용할 때는 `PolicyName` 파라미터에서 편집하려는 정책의 이름을 지정하세요. 변경할 파라미터의 새로운 값을 지정합니다.
자세한 내용은 [ElastiCache for Valkey 및 Redis OSS 클러스터에 조정 정책 적용](AutoScaling-Defining-Policy.md#AutoScaling-Applying-Policy) 섹션을 참조하세요.
# 조정 정책 삭제
AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 삭제할 수 있습니다.
**AWS Management Console을 사용하여 조정 정책 삭제**
AWS Management Console을 사용하여 미리 정의된 지표 유형이 있는 정책을 편집할 수 있습니다.
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 Amazon ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 자동 크기 조정 정책을 삭제할 클러스터를 선택합니다.
1. **Auto Scaling 정책** 탭을 선택합니다.
1. **조정 정책(Scaling policies)**에서 자동 크기 조정 정책을 선택한 후 **삭제(Delete)**를 선택합니다.
**AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책 삭제 **
AWS CLI 또는 Application 오토 스케일링 API를 사용하여 ElastiCache 클러스터에서 크기 조정 정책을 삭제할 수 있습니다.
** CLI**
ElastiCache for Valkey 및 Redis OSS 클러스터에서 조정 정책을 삭제하려면 다음 파라미터와 함께 [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) 명령을 사용합니다.
+ --policy-name – 조정 정책의 이름입니다.
+ --resource-id – 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ --service-namespace – 이 값을 elasticache로 설정합니다.
+ --scalable-dimension – 이 값을 `elasticache:replication-group:Replicas`로 설정합니다.
**Example**
다음 예제에서는 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 ELC; 클러스터에서 삭제합니다.
Linux, macOS, Unix의 경우:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
```
Windows의 경우:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:Replicas ^
```
**API**.
ElastiCache for Valkey 및 Redis OSS 클러스터에서 조정 정책을 삭제하려면 다음 파라미터와 함께 [DeleteScalingPolicy](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html) Application Auto Scaling API 작업을 사용합니다.
+ PolicyName – 조정 정책의 이름입니다.
+ ResourceID – 클러스터의 리소스 식별자입니다. 이 파라미터의 경우 리소스 유형은 ReplicationGroup이고 고유 식별자는 `replication-group/myscalablecluster`와 같은 클러스터의 이름입니다.
+ ServiceNamespace - 이 값을 elasticache로 설정합니다.
+ ScalableDimension - 이 값을 `elasticache:replication-group:Replicas`로 설정합니다.
다음 예제에서는 Application 오토 스케일링 API를 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 클러스터에서 삭제합니다.
```
POST / HTTP/1.1
>>>>>>> mainline
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas"
}
```
# Auto Scaling 정책을 위한 CloudFormation 사용
이 코드 조각은 예약된 작업을 생성하고 [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) 리소스를 사용하여 [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) 리소스에 적용하는 방법을 보여줍니다. [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) 및 [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) 내장 함수를 사용하여 동일한 템플릿에 지정된 `AWS::ElastiCache::ReplicationGroup` 리소스의 논리적 이름으로 `ResourceId` 속성을 구성합니다.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:Replicas'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCacheReplicaEngineCPUUtilization
TargetValue: 40
```
# 예약된 조정
일정을 기반으로 조정을 수행하면 수요에 따른 로드 변경에 맞게 애플리케이션을 조정할 수 있습니다. 예약된 조정을 사용하려면 ElastiCache for Valkey 및 Redis OSS가 특정 시간에 조정 작업을 수행하도록 하는 예약된 작업을 생성할 수 있습니다. 예약된 작업을 생성할 때, 기존 ElastiCache 클러스터, 규모 조정 활동이 발생해야 할 시점, 최소 용량 및 최대 용량을 지정할 수 있습니다. 규모를 한 번만 조정하거나 반복되는 일정으로 조정하도록 예약된 작업을 생성할 수 있습니다.
이미 존재하는 ElastiCache 클러스터에 대한 예약된 작업만 생성할 수 있습니다. 클러스터를 생성하는 동시에 예약된 작업을 생성할 수는 없습니다.
예약된 작업 생성, 관리 및 삭제와 관련된 용어에 대한 자세한 내용은 [예약된 작업 생성, 관리 및 삭제에 일반적으로 사용되는 명령](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)을 참조하세요.
**1회성 예약된 작업을 생성하려면**
샤드 차원과 유사합니다. [예약된 조정](AutoScaling-with-Scheduled-Scaling-Shards.md) 섹션을 참조하세요.
**예약된 작업 삭제**
샤드 차원과 유사합니다. [예약된 조정](AutoScaling-with-Scheduled-Scaling-Shards.md) 섹션을 참조하세요.
**를 사용하여 예약된 조정을 관리하려면 AWS CLI**
다음과 같은 애플리케이션 자동 크기 조정 API를 사용합니다.
+ [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)
+ [describe-scheduled-actions](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scheduled-actions.html)
+ [delete-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scheduled-action.html)
## CloudFormation을 사용하여 Auto Scaling 정책 생성
이 코드 조각은 예약된 작업을 생성하고 [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) 리소스를 사용하여 [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) 리소스에 적용하는 방법을 보여줍니다. [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) 및 [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) 내장 함수를 사용하여 동일한 템플릿에 지정된 `AWS::ElastiCache::ReplicationGroup` 리소스의 논리적 이름으로 `ResourceId` 속성을 구성합니다.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
```
# 클러스터 모드 수정
Valkey 및 Redis OSS는 샤딩 및 복제를 지원하는 분산형 인 메모리 데이터베이스입니다. ElastiCache Valkey 및 Redis OSS 클러스터는 데이터를 여러 노드로 분할할 수 있는 분산 구현입니다. ElastiCache for Redis OSS 클러스터에는 클러스터 모드 활성화(CME)와 클러스터 모드 비활성화(CMD)라는 두 가지 작동 모드가 있습니다. CME에서 Valkey 및 Redis OSS 엔진은 여러 샤드와 노드가 있는 분산 데이터베이스로 작동하지만 CMD에서 Valkey 및 Redis OSS는 단일 노드로 작동합니다.
CMD에서 CME로 마이그레이션하려면 다음 조건을 충족해야 합니다.
**중요**
클러스터 모드 구성은 클러스터 모드 비활성화에서 클러스터 모드 활성화로만 변경할 수 있습니다. 이 구성은 되돌릴 수 없습니다.
+ 클러스터에는 데이터베이스 0에만 키가 있을 수 있습니다.
+ 애플리케이션은 클러스터 프로토콜을 사용할 수 있고 구성 엔드포인트를 사용하는 Valkey 또는 Redis OSS 클라이언트를 사용해야 합니다.
+ 최소 1개의 복제본이 있는 클러스터에서 자동 장애 조치를 활성화해야 합니다.
+ 마이그레이션에 필요한 최소 엔진 버전은 Valkey 7.2 이상 또는 Redis OSS 7.0 이상입니다.
CMD에서 CME로 마이그레이션하려면 클러스터 모드 구성을 클러스터 모드 비활성화에서 클러스터 모드 활성화로 변경해야 합니다. 이는 마이그레이션 프로세스 중에 클러스터 가용성을 보장하는 2단계 절차입니다.
**참고**
파라미터 그룹에 클러스터 지원 구성을 제공해야 합니다. 즉, 클러스터 지원 파라미터는 `yes`로 설정되어 있어야 합니다. 기본 파라미터 그룹을 사용하는 경우 ElastiCache for Redis OSS는 클러스터 지원 구성이 있는 해당 기본 파라미터 그룹을 자동으로 선택합니다. 클러스터 지원 파라미터 값은 CMD 클러스터의 경우 `no`로 설정됩니다. 클러스터가 호환 모드로 이동하면 수정 작업의 일부로 클러스터 지원 파라미터 값이 `yes`로 업데이트됩니다.
자세한 내용은 [ElastiCache 파라미터 그룹을 사용해 엔진 파라미터 구성](ParameterGroups.md) 섹션을 참조하세요.
1. **준비** – 테스트 CME 클러스터를 만들고 스택이 CME 클러스터와 함께 작동할 준비가 되었는지 확인합니다. ElastiCache for Redis OSS는 준비 상태를 확인할 방법이 없습니다. 자세한 내용은 [Valkey 또는 Redis OSS용 클러스터 생성](Clusters.Create.md) 섹션을 참조하세요.
1. **기존 CMD 클러스터 구성을 클러스터 모드 호환으로 수정** – 이 모드에서는 단일 샤드가 배포되며 ElastiCache for Redis OSS는 단일 노드로도 작동하지만 단일 샤드 클러스터로도 작동합니다. 호환 모드란 클라이언트 애플리케이션이 두 프로토콜 중 하나를 사용하여 클러스터와 통신할 수 있음을 의미합니다. 이 모드에서는 Valkey 또는 Redis OSS 클러스터 프로토콜 및 구성 엔드포인트를 사용하도록 애플리케이션을 재구성해야 합니다. Valkey 또는 Redis OSS 클러스터 모드를 클러스터 모드 호환으로 변경하려면 아래 단계를 따르세요.
**참고**
호환 모드에서는 크기 조정 및 엔진 버전과 같은 다른 수정 작업이 클러스터에 허용되지 않습니다. 또한 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 요청 내에서 클러스터 모드 파라미터를 정의할 때는 파라미터(`cacheParameterGroupName` 제외)를 수정할 수 없습니다.
1. AWS Management Console을 사용할 때 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하여 클러스터 모드를 **호환 가능**으로 설정합니다.
1. API를 사용하여 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)을 참조하고 `ClusterMode` 파라미터를 `compatible`로 업데이트하세요.
1. AWS CLI를 사용하여 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)을 참조하고 `cluster-mode` 파라미터를 `compatible`로 업데이트하세요.
Valkey 또는 Redis OSS 클러스터 모드를 클러스터 모드 호환으로 변경한 후 [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) API는 ElastiCache for Redis OSS 클러스터 구성 엔드포인트를 반환합니다. 클러스터 구성 엔드포인트는 애플리케이션이 클러스터에 연결하는 데 사용할 수 있는 단일 엔드포인트입니다. 자세한 내용은 [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md) 섹션을 참조하세요.
1. **클러스터 구성을 클러스터 모드활성화로 수정** – 클러스터 모드가 클러스터 모드 호환으로 설정되면 두 번째 단계는 클러스터 모드 활성화로 클러스터 구성을 수정하는 것입니다. 이 모드에서는 단일 샤드가 실행되고 고객은 이제 클러스터 크기를 조정하거나 다른 클러스터 구성을 수정할 수 있습니다.
클러스터 모드를 활성화로 변경하려면 아래 단계를 따릅니다.
시작하기 전에 Valkey 또는 Redis OSS 클라이언트가 클러스터 프로토콜을 사용하도록 마이그레이션되었고 클러스터의 구성 엔드포인트가 사용 중이 아닌지 확인하세요.
1. AWS Management Console을 사용할 때 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하여 클러스터 모드를 **활성화됨**으로 설정합니다.
1. API를 사용하여 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)을 참조하고 `ClusterMode` 파라미터를 `enabled`로 업데이트하세요.
1. AWS CLI를 사용하여 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)을 참조하고 `cluster-mode` 파라미터를 `enabled`로 업데이트하세요.
클러스터 모드를 활성화로 변경하면 엔드포인트가 Valkey 또는 Redis OSS 클러스터 사양에 따라 구성됩니다. [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) API는 클러스터 모드 파라미터를 `enabled` 및 이제 애플리케이션에서 클러스터에 연결하는 데 사용할 수 있는 클러스터 엔드포인트로 반환합니다.
클러스터 모드가 활성화로 변경되면 클러스터 엔드포인트가 변경된다는 점에 유의하세요. 새 엔드포인트로 애플리케이션을 업데이트해야 합니다.
또한 클러스터 모드 호환에서 클러스터 모드 비활성화(CMD)로 되돌리고 원래 구성을 보존하도록 선택할 수 있습니다.
**클러스터 모드 호환에서 클러스터 모드 비활성화로 클러스터 구성을 수정합니다.**
1. AWS Management Console을 사용할 때 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하여 클러스터 모드를 **비활성화됨**으로 설정합니다.
1. API를 사용하여 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)을 참조하고 `ClusterMode` 파라미터를 `disabled`로 업데이트하세요.
1. AWS CLI를 사용하여 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)을 참조하고 `cluster-mode` 파라미터를 `disabled`로 업데이트하세요.
클러스터 모드를 비활성화로 변경한 후 [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) API는 클러스터 모드 파라미터를 `disabled`로 반환합니다.
# 글로벌 데이터 스토어를 사용하여AWS리전 간 복제
**참고**
글로벌 데이터 저장소는 현재 노드 기반 클러스터에만 사용할 수 있습니다.
글로벌 데이터 스토어 기능을 사용하면AWS리전 간 완전 관리형, 빠르고 안정적이며 안전한 Valkey 또는 Redis OSS 클러스터 복제 작업을 수행할 수 있습니다. 이 기능을 사용하면 리전 간 읽기 전용 복제본 클러스터를 생성하여AWS리전 간 지연 시간이 짧은 읽기 및 재해 복구를 활성화할 수 있습니다.
다음 섹션에서는 글로벌 데이터 스토어로 작업하는 방법에 대한 설명을 찾을 수 있습니다.
**Topics**
+ [개요](#Redis-Global-Data-Stores-Overview)
+ [사전 조건 및 제한 사항](Redis-Global-Datastores-Getting-Started.md)
+ [글로벌 데이터 스토어 사용(콘솔)](Redis-Global-Datastores-Console.md)
+ [글로벌 데이터 저장소 사용(CLI)](Redis-Global-Datastores-CLI.md)
## 개요
각 *글로벌 데이터 스토어*는 서로 복제하는 하나 이상의 클러스터 모음입니다.
글로벌 데이터 스토어는 다음과 같이 구성됩니다.
+ **기본(활성) 클러스터** - 기본 클러스터는 글로벌 데이터 스토어 내의 모든 클러스터에 복제되는 쓰기를 허용합니다. 기본 클러스터는 읽기 요청도 허용합니다.
+ **보조(수동) 클러스터** - 보조 클러스터는 읽기 요청만 허용하고 기본 클러스터에서 데이터 업데이트를 복제합니다. 보조 클러스터는 기본 클러스터와 다른AWS리전에 있어야 합니다.
ElastiCache에서 글로벌 데이터 저장소를 생성하면 ElastiCache for Valkey 및 Redis OSS에서 기본 클러스터에서 보조 클러스터로 데이터를 자동으로 복제합니다. Valkey 또는 Redis OSS 데이터를 복제해야 하는AWS리전을 선택한 다음 해당AWS리전에 보조 클러스터를 생성합니다. 그런 다음 ElastiCache는 두 클러스터 간의 자동 비동기식 데이터 복제를 설정하고 관리합니다.
Valkey 또는 Redis OSS용 글로벌 데이터 저장소를 사용하면 다음과 같은 이점을 얻을 수 있습니다.
+ **지리적 성능** - 추가AWS리전에 원격 복제본 클러스터를 설정하고 이들 간에 데이터를 동기화하면 해당AWS리전의 데이터 액세스 지연 시간을 줄일 수 있습니다. 글로벌 데이터 스토어는AWS리전 간에 지연 시간이 짧은 지리로컬 읽기를 제공하여 애플리케이션의 응답성을 높이는 데 도움이 될 수 있습니다.
+ **재해 복구** - 글로벌 데이터 스토어의 기본 클러스터에서 성능 저하가 발생하는 경우 보조 클러스터를 새 기본 클러스터로 승격할 수 있습니다. 보조 클러스터가 포함된 모든AWS리전에 연결하여이 작업을 수행할 수 있습니다.
다음 다이어그램은 글로벌 데이터 스토어가 작동하는 방식을 보여줍니다.
![\[글로벌 데이터 스토어\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/Global-DataStore.png)
# 사전 조건 및 제한 사항
글로벌 데이터 스토어를 시작하기 전에 다음 사항에 유의하세요.
+ 글로벌 데이터 저장소는 다음 AWS 리전에서 지원됩니다.
+ **아프리카** - 케이프타운
+ **아시아 태평양** - 홍콩, 하이데라바드, 자카르타, 말레이시아, 멜버른, 뭄바이, 오사카, 서울, 싱가포르, 시드니, 태국, 도쿄
+ **캐나다** - 캐나다 중부 및 캐나다 서부(캘거리)
+ **중국** - 베이징 및 닝샤
+ **유럽** - 프랑크푸르트, 런던, 아일랜드, 밀라노, 파리, 스페인, 스톡홀름, 취리히
+ **AWS GovCloud** - 미국 서부 및 미국 동부
+ **이스라엘** - 텔아비브
+ **중동** - 바레인 및 UAE
+ **미국** - 동부(버지니아 북부 및 오하이오) 및 미국 서부(캘리포니아 북부 및 오리건)
+ **남아메리카** - 멕시코(중부) 및 상파울루
+ 글로벌 데이터 스토어의 모든 클러스터(기본 및 보조)에는 동일한 수의 프라이머리 노드, 노드 유형, 엔진 버전 및 샤드 수(클러스터 모드가 활성화된 경우)가 있어야 합니다. 글로벌 데이터 스토어의 각 클러스터에는 해당 클러스터에 대한 로컬 읽기 트래픽을 수용하기 위해 다른 수의 읽기 복제본이 있을 수 있습니다.
기존 단일 노드 클러스터를 사용하려는 경우 복제를 활성화해야 합니다.
+ 글로벌 데이터 저장소는 크기가 큰 인스턴스 이상에서 지원됩니다.
+ 한 AWS 리전의 기본 클러스터에서 최대 두 개의 다른 AWS 리전의 보조 클러스터로 복제를 설정할 수 있습니다.
**참고**
중국(베이징) 리전과 중국(닝샤) 리전은 예외로, 두 리전 간에서만 복제가 실행될 수 있습니다.
+ VPC 클러스터에서만 글로벌 데이터 스토어로 작업할 수 있습니다. 자세한 내용은 [Amazon VPC에 있는 ElastiCache 캐시에 액세스하기 위한 액세스 패턴](elasticache-vpc-accessing.md) 섹션을 참조하세요. EC2-Classic을 사용하는 경우 글로벌 데이터 스토어가 지원되지 않습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [EC2-Classic](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-classic-platform.html)을 참조하세요.
**참고**
현재 [ElastiCache에서 로컬 영역 사용](Local_zones.md)에서 글로벌 데이터 스토어를 사용할 수 없습니다.
+ ElastiCache는 한 AWS 리전에서 다른 리전으로 자동 장애 조치를 지원하지 않습니다. 필요한 경우 보조 클러스터를 수동으로 승격할 수 있습니다. 문제 해결 예는 [보조 클러스터를 기본 클러스터로 승격](Redis-Global-Datastores-Console.md#Redis-Global-Datastores-Console-Promote-Secondary)을(를) 참조하세요.
+ 기존 데이터에서 부트스트랩하려면 기존 클러스터를 기본 클러스터로 사용하여 글로벌 데이터 스토어를 생성합니다. 기존 클러스터를 보조 클러스터로 추가하는 것은 지원하지 않습니다. 클러스터를 보조 클러스터로 추가하는 프로세스로 데이터가 지워져 데이터가 손실될 수 있습니다.
+ 파라미터 업데이트는 글로벌 데이터 스토어에 속한 클러스터의 로컬 파라미터 그룹을 수정할 때 모든 클러스터에 적용됩니다.
+ 리전 클러스터를 수직(확장 및 축소) 및 수평(확장 및 축소)으로 확장할 수 있습니다. 글로벌 데이터 스토어를 수정하여 클러스터를 조정할 수 있습니다. 그러면 글로벌 데이터 스토어의 모든 리전 클러스터가 중단 없이 확장됩니다. 자세한 내용은 [ElastiCache 규모 조정](Scaling.md) 섹션을 참조하세요.
+ 글로벌 데이터 저장소는 [저장된 데이터 암호화](at-rest-encryption.md), [전송 중 데이터 암호화](in-transit-encryption.md), [AUTH](auth.md)를 지원합니다.
+ 글로벌 데이터 저장소는 인터넷 프로토콜 버전 6(IPv6)을 지원하지 않습니다.
+ 글로벌 데이터 스토어는 AWS KMS 키를 지원합니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [AWS key management service concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)를 참조하세요.
**참고**
글로벌 데이터 스토어는 다음 규정에 따라 [pub/sub 메시지](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-use-cases.html#elasticache-for-redis-use-cases-messaging)를 지원합니다.
클러스터 모드가 비활성화된 경우 pub/sub가 완전히 지원됩니다. 기본 AWS 리전의 기본 클러스터에 게시된 이벤트는 보조 AWS 리전으로 전파됩니다.
클러스터 모드가 활성화된 경우 다음 사항이 적용됩니다.
키스페이스에 없는 게시된 이벤트의 경우 동일한 AWS 리전의 구독자만 이벤트를 수신합니다.
게시된 키스페이스 이벤트의 경우 모든 AWS 리전의 구독자가 이벤트를 수신합니다.
# 글로벌 데이터 스토어 사용(콘솔)
콘솔을 사용하여 글로벌 데이터 스토어를 생성하려면 다음 2단계 프로세스를 수행합니다.
1. 기존 클러스터를 사용하거나 새 클러스터를 생성하여 기본 클러스터를 생성합니다. 엔진은 Valkey 7.2 이상 또는 Redis OSS 5.0.6 이상이어야 합니다.
1. Valkey 7.2 이상 또는 Redis OSS 5.0.6 이상을 사용하여 서로 다른 AWS 리전에 최대 2개의 보조 클러스터를 추가합니다.
다음 절차에서는 Valkey 또는 Redis OSS용 글로벌 데이터 저장소를 생성하고 ElastiCache 콘솔을 사용하여 다른 작업을 수행하는 방법에 대해 설명합니다.
**Topics**
+ [기존 클러스터를 사용하여 글로벌 데이터 스토어 생성](#Redis-Global-Datastores-Console-Create-Primary)
+ [새 기본 클러스터를 사용하여 새 글로벌 데이터 스토어 생성](#Redis-Global-Datastores-Create-From-Scratch)
+ [글로벌 데이터 스토어 세부 정보 보기](#Redis-Global-Datastores-Console-Details)
+ [글로벌 데이터 스토어에 리전 추가](#Redis-Global-Datastores-Console-Create-Secondary)
+ [글로벌 데이터 스토어 수정](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
+ [보조 클러스터를 기본 클러스터로 승격](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [글로벌 데이터 스토어에서 리전 제거](#Redis-Global-Datastore-Console-Remove-Region)
+ [글로벌 데이터 스토어 삭제](#Redis-Global-Datastores-Console-Delete-GlobalDatastore)
## 기존 클러스터를 사용하여 글로벌 데이터 스토어 생성
이 시나리오에서는 기존 클러스터를 사용하여 새 글로벌 데이터 스토어의 기본 클러스터 역할을 합니다. 그런 다음 별도의 AWS 리전에 보조 읽기 전용 클러스터를 생성합니다. 이 보조 클러스터는 기본 클러스터에서 자동 및 비동기 업데이트를 받습니다.
**중요**
기존 클러스터는 Valkey 7.2 이상 또는 Redis OSS 5.0.6 이상의 엔진을 사용해야 합니다.
**기존 클러스터를 사용하여 글로벌 데이터 스토어를 생성하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택한 다음 **글로벌 데이터 저장소 생성**을 선택합니다.
1. **기본 클러스 설정** 페이지에서 다음 작업을 수행합니다.
+ **글로벌 데이터 저장소 정보** 필드에 새 글로벌 데이터 저장소의 이름을 입력합니다.
+ (선택 사항) **설명** 값을 입력합니다.
1. **리전 클러스터**에서 **기존 리전 클러스터 사용**을 선택합니다.
1. **기존 클러스터**에서 사용하려는 기존 클러스터를 선택합니다.
1. 다음 옵션을 그대로 유지하세요. 기본 클러스터 구성과 일치하도록 미리 채워져 있으므로 변경할 수 없습니다.
+ 엔진 버전
+ 노드 유형
+ 파라미터 그룹
**참고**
ElastiCache는 제공된 파라미터 그룹의 값에서 새 파라미터 그룹을 자동으로 생성하고 새 파라미터 그룹을 클러스터에 적용합니다. 글로벌 데이터 스토어의 파라미터를 수정하려면 이 새 파라미터 그룹을 사용합니다. 자동 생성된 각 파라미터 그룹은 하나의 클러스터에만 연결되므로 하나의 글로벌 데이터 스토어에만 연결됩니다.
+ 샤드 수
+ 저장된 데이터 암호화 - 디스크에 저장된 데이터 암호화를 활성화합니다. 자세한 내용은 [저장된 데이터 암호화](at-rest-encryption.md)를 참조하세요.
**참고**
**고객 관리형 AWS KMS 키**를 선택하고 키를 선택하여 다른 암호화 키를 제공할 수 있습니다. 자세한 내용은 [고객 관리형 AWS KMS 키 사용](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)을 참조하세요.
+ 전송 중 데이터 암호화 – 전송 데이터 암호화를 활성화합니다. 자세한 내용은 [전송 중 데이터 암호화](in-transit-encryption.md)를 참조하세요. Valkey 7.2 이상 및 Redis OSS 6.0 이상의 경우 전송 중 데이터 암호화를 활성화하면 다음 **액세스 제어** 옵션 중 하나를 지정하라는 메시지가 표시됩니다.
+ **액세스 제어 안 함** – 기본 설정입니다. 이 옵션은 제한하지 않는다는 의미입니다.
+ **사용자 그룹 액세스 제어 목록** - 사용 가능한 작업에 대한 사용자 및 권한 집합이 정의된 사용자 그룹을 선택합니다. 자세한 내용은 [콘솔 및 CLI를 사용하여 사용자 그룹 관리](Clusters.RBAC.md#User-Groups) 섹션을 참조하세요.
+ **AUTH 기본 사용자** – Valkey 또는 Redis OSS 서버의 인증 메커니즘입니다. 자세한 정보는 [AUTH](auth.md)를 참조하세요.
1. (선택 사항) 필요에 따라 나머지 보조 클러스터 설정을 업데이트합니다. 기본 클러스터와 동일한 값으로 미리 채워지지만 해당 클러스터에 대한 특정 요구 사항을 충족하도록 업데이트할 수 있습니다.
+ Port
+ 복제본 개수
+ Subnet Group
+ 기본 가용 영역
+ 보안 그룹
+ 고객 관리형(AWS KMS 키)
+ AUTH 토큰
+ 자동 백업 활성화
+ 백업 보존 기간
+ 백업 기간
+ 유지 관리 기간
+ SNS 알림에 대한 주제
1. **생성(Create)**을 선택합니다. 이렇게 하면 글로벌 데이터 스토어의 상태가 **생성 중**으로 설정됩니다. 기본 클러스터가 글로벌 데이터 스토어에 연결되고 보조 클러스터가 **연결 중(Associating)** 상태가 된 후 상태가 **수정 중(Modifying)**으로 전환됩니다.
기본 클러스터 및 보조 클러스터가 글로벌 데이터 스토어와 연결되면 상태가 **사용 가능**으로 변경됩니다. 이 시점에서 읽기 및 쓰기를 허용하는 기본 클러스터와 기본 클러스터에서 복제된 읽기를 허용하는 보조 클러스터가 있습니다.
페이지가 업데이트되어 클러스터가 글로벌 데이터 저장소의 일부인지 여부를 나타냅니다.
+ **글로벌 데이터 스토어** - 클러스터가 속한 글로벌 데이터 스토어의 이름입니다.
+ **글로벌 데이터 스토어 역할** - 클러스터의 역할(기본 또는 보조)입니다.
다른 AWS 리전에 보조 클러스터를 최대 1개까지 추가할 수 있습니다. 자세한 내용은 [글로벌 데이터 스토어에 리전 추가](#Redis-Global-Datastores-Console-Create-Secondary) 섹션을 참조하세요.
## 새 기본 클러스터를 사용하여 새 글로벌 데이터 스토어 생성
새 클러스터를 사용하여 글로벌 데이터 스토어를 생성하도록 선택한 경우 다음 절차를 따르십시오.
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택한 다음 **글로벌 데이터 저장소 생성**을 선택합니다.
1. **기본 클러스터 설정(Primary cluster settings)**에서 다음을 수행합니다.
1. **클러스터 모드(Cluster mode)**에서 **사용 설정됨(Enabled)** 또는 **사용 중지됨(Disabled)**을 선택합니다.
1. **글로벌 데이터 스토어 정보(Global Datastore info)**에 **이름(Name)** 값을 입력합니다. ElastiCache는 이 접미사를 사용하여 글로벌 데이터 스토어의 고유한 이름을 생성합니다. 여기에서 지정하는 접미사를 사용하여 글로벌 데이터 저장소를 검색할 수 있습니다.
1. (선택 사항) **글로벌 데이터 스토어 설명**에 값을 입력합니다.
1. **리전 클러스터(Regional cluster)**에서 다음을 수행합니다.
1. **리전(Region)**의 경우 사용 가능한 AWS 리전을 선택합니다.
1. **새 리전 클러스터 생성(Create new regional cluster)** 또는 **기존 리전 클러스터 사용(Use existing regional cluster)**을 선택합니다.
1. **새 리전 클러스터 생성(Create new regional cluster)**을 선택한 경우 **클러스터 정보(Cluster info)**에서 클러스터의 이름과 설명(선택 사항)을 입력합니다.
1. **위치(Location)**에서 **다중 AZ(Multi-AZ)** 및 **자동 장애 조치(Auto-failover)**의 기본 설정을 수락하는 것이 좋습니다.
1. **클러스터 설정(Cluster settings)**에서 다음을 수행합니다.
1. **엔진 버전(Engine version)**의 경우 사용 가능한 버전(5.0.6 이상)을 선택합니다.
1. **포트(Port)**의 경우 기본 포트인 6379를 사용합니다. 다른 포트를 사용해야 하는 경우 포트 번호를 입력합니다.
1. **파라미터 그룹**에서 파라미터 그룹을 선택하거나 새 파라미터 그룹을 만듭니다. 파라미터 그룹은 클러스터의 런타임 파라미터를 제어합니다. 파라미터 그룹에 대한 자세한 정보는 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 및 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 섹션을 참조하세요.
**참고**
파라미터 그룹을 선택하여 엔진 구성 값을 설정하면 해당 파라미터 그룹이 글로벌 데이터 스토어의 모든 클러스터에 적용됩니다. **파라미터 그룹** 페이지에서 yes/no **글로벌** 속성은 파라미터 그룹이 글로벌 데이터 스토어의 일부인지 여부를 나타냅니다.
1. **노드 유형**에서 아래쪽 화살표(![\[Downward-pointing triangle icon, typically used to indicate a dropdown menu.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-DnArrow.png))를 선택합니다. **노드 유형 변경** 대화 상자에서 원하는 노드 유형의 **인스턴스 패밀리** 값을 선택합니다. 그런 다음 이 클러스터에 사용할 노드 유형을 선택한 다음 **저장**을 선택합니다.
자세한 정보는 [노드 크기 선택](CacheNodes.SelectSize.md) 섹션을 참조하세요.
r6gd 노드 유형을 선택하는 경우 데이터 계층화가 자동으로 사용 설정됩니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
1. Valkey 또는 Redis OSS(클러스터 모드 사용 중지됨) 클러스터를 생성하는 경우
**복제본 개수(Number of replicas)**의 경우 이 클러스터에 대해 원하는 복제본 개수를 선택합니다.
1. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 생성하는 경우
1. **샤드 수**에서 이 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에 사용할 샤드(파티션/노드 그룹) 수를 선택합니다.
일부 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 버전의 경우 클러스터의 샤드 수를 동적으로 변경할 수 있습니다.
+ **Redis OSS 3.2.10 이상** - 클러스터에서 Redis OSS 3.2.10 이상 버전을 실행하는 경우 클러스터의 샤드 수를 동적으로 변경할 수 있습니다. 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) 섹션을 참조하세요.
+ **다른 Redis OSS 버전** - 클러스터에서 버전 3.2.10 이전의 Redis OSS 버전을 실행하는 경우 다른 방법이 있습니다. 이 경우 클러스터의 샤드 수를 변경하려면 새 샤드 수로 새 클러스터를 만듭니다. 자세한 내용은 [백업에서 새 캐시로 복원](backups-restoring.md) 섹션을 참조하세요.
1. **샤드당 복제본**에서 각 샤드에 포함할 읽기 전용 복제본 노드 수를 선택합니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에는 다음과 같은 제한 사항이 있습니다.
+ 다중 AZ를 활성화한 경우 샤드당 복제본이 하나 이상 있어야 합니다.
+ 콘솔을 사용하여 클러스터를 생성할 때 샤드마다 복제본 수가 동일합니다.
+ 샤드당 읽기 전용 복제본 수가 고정되어 변경할 수 없습니다. 샤드(API/CLI: 노드 그룹)당 복제본 수를 늘리거나 줄이려면 새로운 복제본 수로 새 클러스터를 생성해야 합니다. 자세한 내용은 [자습서: 외부에서 생성된 백업으로 새로운 노드 기반 클러스터 시드](backups-seeding-redis.md) 섹션을 참조하세요.
1. **서브넷 그룹 설정(Subnet group settings)**에서 이 클러스터에 적용할 서브넷을 선택합니다. ElastiCache는 기본 IPv4 서브넷 그룹을 제공하거나 선택하여 새 서브넷 그룹을 생성할 수 있습니다. IPv6의 경우 IPv6 CIDR 블록이 있는 서브넷 그룹을 생성해야 합니다. **듀얼 스택**을 선택한 경우 검색 IP 유형으로 IPv6 또는 IPv4 중에 선택해야 합니다.
자세한 정보는 [VPC에서 서브넷 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)을 참조하세요.
1. **가용 영역 배치(Availability zone placements)**의 경우 다음 두 가지 옵션이 있습니다.
+ **기본 설정 없음** – ElastiCache에서 가용 영역을 선택합니다.
+ **가용 영역 지정** – 각 클러스터의 가용 영역을 지정합니다.
가용 영역을 지정하도록 선택한 경우 샤드에 있는 각 클러스터에 대해 목록에서 가용 영역을 선택합니다.
자세한 내용은 [ElastiCache에 대한 리전 및 가용 영역 선택](RegionsAndAZs.md) 섹션을 참조하세요.
![\[이미지: Keyspaces 및 가용 영역 지정\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-ClusterOn-Slots-AZs.png)
*Keyspaces 및 가용 영역 지정*
1. **다음(Next)**을 선택합니다.
1. **고급 Valkey 및 Redis OSS 설정**에서
1. **보안(Security)**의 경우
1. 데이터를 암호화하려면 다음과 같은 옵션이 있습니다.
+ **저장된 데이터 암호화** - 디스크에 저장된 데이터 암호화를 활성화합니다. 자세한 정보는 [저장된 데이터 암호화](at-rest-encryption.md)를 참조하세요.
**참고**
**고객 관리형 AWS KMS 키**를 선택하고 키를 선택하여 다른 암호화 키를 제공하는 옵션이 있습니다. 자세한 정보는 [AWS KMS에서 고객 관리형 키 사용](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)을 참조하세요.
+ **전송 중 데이터 암호화** – 전송 데이터 암호화를 활성화합니다. 자세한 정보는 [전송 중 데이터 암호화](in-transit-encryption.md)를 참조하세요. Valkey 7.2 이상 및 Redis OSS 6.0 이상의 경우 전송 중 암호화를 활성화하면 다음 **액세스 제어** 옵션 중 하나를 지정하라는 메시지가 표시됩니다.
+ **액세스 제어 안 함** – 기본 설정입니다. 이 옵션은 클러스터에 대한 사용자 액세스를 제한하지 않는다는 의미입니다.
+ **사용자 그룹 액세스 제어 목록** - 클러스터에 액세스할 수 있는 사용자 집합이 정의된 사용자 그룹을 선택합니다. 자세한 내용은 [콘솔 및 CLI를 사용하여 사용자 그룹 관리](Clusters.RBAC.md#User-Groups) 섹션을 참조하세요.
+ **AUTH 기본 사용자** – Valkey 또는 Redis OSS 서버의 인증 메커니즘입니다. 자세한 정보는 [AUTH](auth.md)를 참조하세요.
+ **AUTH** – Valkey 또는 Redis OSS 서버의 인증 메커니즘입니다. 자세한 정보는 [AUTH](auth.md)를 참조하세요.
**참고**
버전 3.2.10을 제외한 3.2.6 이상의 Redis OSS 버전의 경우 AUTH가 유일한 옵션입니다.
1. **보안 그룹**에서 이 클러스터에 사용할 보안 그룹을 선택합니다. *보안 그룹*은 클러스터에 대한 네트워크 액세스를 제어하는 방화벽 역할을 합니다. VPC의 기본 보안 그룹을 사용하거나 새 보안 그룹을 만들 수 있습니다.
보안 그룹에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [VPC의 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)을 참조하세요.
1. 정기적인 자동 백업을 예약할 경우 **Enable automatic backups(자동 백업 활성화)**를 선택한 후 자동으로 삭제되기 전에 각 자동 백업을 보존할 기간(일)을 입력합니다. 정기적인 자동 백업을 예약하지 않으려면 [**Enable automatic backups**] 확인란의 선택을 취소합니다. 어떤 경우든 수동 백업을 항상 생성할 수 있습니다.
백업 및 복원에 대한 자세한 정보는 [스냅샷 및 복원](backups.md) 섹션을 참조하세요.
1. (선택 사항) 유지 관리 기간을 지정합니다. *유지 관리 기간*은 ElastiCache가 클러스터의 시스템 유지 관리를 예약하는 시간이며 일반적으로 매주 한 시간입니다. ElastiCache에서 유지 관리 기간의 요일과 시간을 선택하도록 허용하거나(*기본 설정 없음*) 요일 시간 및 기간을 직접 선택할 수 있습니다(*유지 관리 기간 지정*). *유지 관리 기간 지정*을 선택할 경우 목록에서 유지 관리 기간의 *시작 요일*, *시작 시간* 및 *기간*을 선택합니다. 모든 시간은 UCT 시간입니다.
자세한 내용은 [ElastiCache 클러스터 유지 관리](maintenance-window.md) 섹션을 참조하세요.
1. (선택 사항) **로그**의 경우:
+ **로그 형식**에서 **텍스트** 또는 **JSON**을 선택합니다.
+ **대상 유형(Destination Type)**에서 **CloudWatch Logs** 또는 **Kinesis Firehose**를 선택합니다.
+ **로그 대상**에서 **새로 생성**을 선택하고 CloudWatch Logs 로그 그룹 이름이나 Firehose 스트림 이름을 입력하거나 **기존 항목 선택**을 선택한 다음 CloudWatch Logs 로그 그룹 이름이나 Firehose 스트림 이름을 선택합니다.
1. **태그(Tags)**의 경우 클러스터 및 기타 ElastiCache 리소스 관리를 돕기 위해 태그 형식으로 각 리소스에 고유한 메타데이터를 할당할 수 있습니다. 자세한 정보는 [ElastiCache 리소스에 태그 지정](Tagging-Resources.md) 섹션을 참조하세요.
1. 입력 및 선택한 내용을 모두 검토한 다음 필요한 내용을 수정합니다. 준비가 되면 **다음**을 선택합니다.
1. 이전 단계에서 클러스터를 구성한 후 이제 보조 클러스터 세부 정보를 구성합니다.
1. **리전 클러스터(Regional cluster)**에서 클러스터가 있는 AWS 리전을 선택합니다.
1. **클러스터 정보(Cluster info)**에 클러스터의 이름과 설명(선택 사항)을 입력합니다.
1. 다음 옵션은 기본 클러스터 구성과 일치하도록 미리 채워지며 변경할 수 없습니다.
+ 위치
+ 엔진 버전
+ 인스턴스 유형
+ 노드 유형
+ 샤드 수
+ 파라미터 그룹
**참고**
ElastiCache는 제공된 파라미터 그룹의 값에서 새 파라미터 그룹을 자동으로 생성하고 새 파라미터 그룹을 클러스터에 적용합니다. 글로벌 데이터 스토어의 파라미터를 수정하려면 이 새 파라미터 그룹을 사용합니다. 자동 생성된 각 파라미터 그룹은 하나의 클러스터에만 연결되므로 하나의 글로벌 데이터 스토어에만 연결됩니다.
+ 저장된 데이터 암호화 - 디스크에 저장된 데이터 암호화를 활성화합니다. 자세한 내용은 [저장된 데이터 암호화](at-rest-encryption.md)를 참조하세요.
**참고**
**고객 관리형 AWS KMS 키**를 선택하고 키를 선택하여 다른 암호화 키를 제공할 수 있습니다. 자세한 내용은 [고객 관리형 AWS KMS 키 사용](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)을 참조하세요.
+ 전송 중 데이터 암호화 – 전송 데이터 암호화를 활성화합니다. 자세한 내용은 [전송 중 데이터 암호화](in-transit-encryption.md)를 참조하세요. Valkey 7.2 이상 및 Redis OSS 6.4 이상의 경우 전송 중 암호화를 활성화하면 다음 **액세스 제어** 옵션 중 하나를 지정하라는 메시지가 표시됩니다.
+ **액세스 제어 안 함** – 기본 설정입니다. 이 옵션은 클러스터에 대한 사용자 액세스를 제한하지 않는다는 의미입니다.
+ **사용자 그룹 액세스 제어 목록** - 클러스터에 액세스할 수 있는 사용자 집합이 정의된 사용자 그룹을 선택합니다. 자세한 내용은 [콘솔 및 CLI를 사용하여 사용자 그룹 관리](Clusters.RBAC.md#User-Groups) 섹션을 참조하세요.
+ **AUTH 기본 사용자** – Valkey 또는 Redis OSS 서버의 인증 메커니즘입니다. 자세한 정보는 [AUTH](auth.md)를 참조하세요.
**참고**
전송 중 암호화가 먼저 지원되기 시작한 4.0.2 버전과 6.0.4 버전 사이에 있는 Redis OSS 버전의 경우 AUTH가 유일한 옵션입니다.
나머지 보조 클러스터 설정은 기본 클러스터와 동일한 값으로 미리 채워지지만, 다음은 해당 클러스터에 대한 특정 요구 사항을 충족하도록 업데이트할 수 있습니다.
+ Port
+ 복제본 개수
+ Subnet Group
+ 기본 가용 영역
+ 보안 그룹
+ 고객 관리형(AWS KMS 키)
+ AUTH 토큰
+ 자동 백업 활성화
+ 백업 보존 기간
+ 백업 기간
+ 유지 관리 기간
+ SNS 알림에 대한 주제
1. **생성(Create)**을 선택합니다. 이렇게 하면 글로벌 데이터 스토어의 상태가 **생성 중**으로 설정됩니다. 기본 클러스터 및 보조 클러스터가 글로벌 데이터 스토어와 연결되면 상태가 **사용 가능**으로 변경됩니다. 읽기 및 쓰기를 허용하는 기본 클러스터와 기본 클러스터에서 복제된 읽기를 허용하는 보조 클러스터가 있습니다.
또한 페이지가 업데이트되어 클러스터가 다음을 포함하여 글로벌 데이터 저장소의 일부인지 여부를 나타냅니다.
+ **글로벌 데이터 스토어** - 클러스터가 속한 글로벌 데이터 스토어의 이름입니다.
+ **글로벌 데이터 스토어 역할** - 클러스터의 역할(기본 또는 보조)입니다.
다른 AWS 리전에 보조 클러스터를 최대 1개까지 추가할 수 있습니다. 자세한 내용은 [글로벌 데이터 스토어에 리전 추가](#Redis-Global-Datastores-Console-Create-Secondary) 섹션을 참조하세요.
## 글로벌 데이터 스토어 세부 정보 보기
기존 글로벌 데이터 저장소의 세부 정보를 보고 **글로벌 데이터 저장소** 페이지에서 수정할 수도 있습니다.
**글로벌 데이터 스토어 세부 정보를 보려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택한 다음 사용 가능한 글로벌 데이터 저장소를 선택합니다.
그러면 다음 글로벌 데이터 스토어 속성을 검사할 수 있습니다.
+ **글로벌 데이터 스토어 이름:** 글로벌 데이터 스토어의 이름입니다.
+ **설명:** 글로벌 데이터 스토어에 대한 설명입니다.
+ **상태:** 옵션은 다음과 같습니다.
+ 생성 중
+ [Modifying]
+ Available
+ 삭제 중
+ 기본 전용 - 이 상태는 글로벌 데이터 스토어에 기본 클러스터만 포함되어 있음을 나타냅니다. 모든 보조 클러스터가 삭제되거나 성공적으로 생성되지 않습니다.
+ **클러스터 모드:** 활성화되거나 비활성화됩니다.
+ **엔진 버전:** 글로벌 데이터 저장소를 실행하는 Valkey 또는 Redis OSS 엔진 버전입니다.
+ **인스턴스 노드 유형:** 글로벌 데이터 스토어에 사용되는 노드 유형입니다.
+ **미사용 데이터 암호화:** 활성화되거나 비활성화됩니다.
+ **전송 중 데이터 암호화:** 활성화되거나 비활성화됩니다.
+ **AUTH:** 활성화되거나 비활성화됩니다.
글로벌 데이터 스토어를 다음과 같이 변경할 수 있습니다.
+ [글로벌 데이터 스토어에 리전 추가](#Redis-Global-Datastores-Console-Create-Secondary)
+ [글로벌 데이터 스토어에서 리전 제거](#Redis-Global-Datastore-Console-Remove-Region)
+ [보조 클러스터를 기본 클러스터로 승격](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [글로벌 데이터 스토어 수정](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
글로벌 데이터 스토어 페이지에는 글로벌 데이터 스토어를 구성하는 개별 클러스터와 각각에 해당하는 다음 속성도 나열됩니다.
+ **리전** - 클러스터가 저장된 AWS 리전입니다.
+ **역할** - 기본 또는 보조입니다.
+ **클러스터 이름** - 클러스터의 이름입니다.
+ **상태** - 옵션은 다음과 같습니다.
+ **연결 중** - 클러스터가 글로벌 데이터 스토어에 연결되는 중입니다.
+ **연관됨** - 클러스터가 글로벌 데이터 스토어에 연결되어 있습니다.
+ **연결 해제 중** - 글로벌 데이터 스토어 이름을 사용하여 글로벌 데이터 스토어에서 보조 클러스터를 제거하는 중입니다. 이후에는 보조 클러스터가 더 이상 기본 클러스터에서 업데이트를 수신하지 않지만 해당 AWS 리전에서 독립 실행형 클러스터로 유지됩니다.
+ **연결 해제됨** - 보조 클러스터가 글로벌 데이터 스토어에서 제거되었으며 이제 AWS 리전에서 독립 실행형 클러스터가 되었습니다.
+ **글로벌 데이터 스토어 지연** - 글로벌 데이터 스토어에 보조 AWS 리전당 하나의 값을 표시합니다. 보조 리전의 프라이머리 노드와 기본 리전의 프라이머리 노드 간의 지연입니다. 클러스터 모드가 활성화된 Valkey 또는 Redis OSS의 경우 지연은 샤드 간의 최대 지연(초)을 나타냅니다.
## 글로벌 데이터 스토어에 리전 추가
기존 글로벌 데이터 스토어에 최대 하나의 AWS 리전을 추가할 수 있습니다. 이 시나리오에서는 기본 클러스터로부터 자동 및 비동기 업데이트를 수신하는 별도의 AWS 리전에 읽기 전용 클러스터를 생성합니다.
**글로벌 데이터 스토어에 AWS 리전을 추가하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택한 다음 기존 글로벌 데이터 저장소를 선택합니다.
1. **리전 클러스터 추가**를 선택하고 보조 클러스터가 상주할 AWS 리전을 선택합니다.
1. **클러스터 정보**에서 클러스터의 **이름**에 대한 값과 필요에 따라 **설명**에 값을 입력합니다.
1. 다음 옵션을 그대로 유지하세요. 기본 클러스터 구성과 일치하도록 미리 채워져 있으므로 변경할 수 없습니다.
+ 엔진 버전
+ 인스턴스 유형
+ 노드 유형
+ 샤드 수
+ 파라미터 그룹
**참고**
ElastiCache는 제공된 파라미터 그룹의 값에서 새 파라미터 그룹을 자동으로 생성하고 새 파라미터 그룹을 클러스터에 적용합니다. 글로벌 데이터 스토어의 파라미터를 수정하려면 이 새 파라미터 그룹을 사용합니다. 자동 생성된 각 파라미터 그룹은 하나의 클러스터에만 연결되므로 하나의 글로벌 데이터 스토어에만 연결됩니다.
+ 저장된 데이터 암호화
**참고**
**고객 관리형 AWS KMS 키**를 선택하고 키를 선택하여 다른 암호화 키를 제공할 수 있습니다.
+ 전송 중 암호화
+ AUTH
1. (선택 사항) 나머지 보조 클러스터 설정을 업데이트합니다. 기본 클러스터와 동일한 값으로 미리 채워지지만 해당 클러스터에 대한 특정 요구 사항을 충족하도록 업데이트할 수 있습니다.
+ Port
+ 복제본 개수
+ Subnet Group
+ 기본 가용 영역
+ 보안 그룹
+ 고객 관리형 AWS KMS 키)
+ AUTH 토큰
+ 자동 백업 활성화
+ 백업 보존 기간
+ 백업 기간
+ 유지 관리 기간
+ SNS 알림에 대한 주제
1. **추가**를 선택합니다.
## 글로벌 데이터 스토어 수정
리전 클러스터의 속성을 수정할 수 있습니다. 보조 클러스터를 기본 클러스터로 승격하는 경우를 제외하고 글로벌 데이터 스토어에서는 하나의 수정 작업만 진행 중일 수 있습니다. 자세한 내용은 [보조 클러스터를 기본 클러스터로 승격](#Redis-Global-Datastores-Console-Promote-Secondary) 섹션을 참조하세요.
**글로벌 데이터 스토어를 수정하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택한 다음 **글로벌 데이터 저장소 이름**에 글로벌 데이터 저장소를 선택합니다.
1. **수정**을 선택하고 다음 옵션 중에서 선택합니다.
+ **설명 수정** - 글로벌 데이터 스토어에 대한 설명을 업데이트합니다.
+ **엔진 버전 수정** - Valkey 7.2 이상 또는 Redis OSS 5.0.6 이상만 사용할 수 있습니다.
+ **노드 유형 수정** - 리전 클러스터를 수직(확장 및 축소) 및 수평(확장 및 축소)으로 확장합니다. 옵션에는 R5 및 M5 노드 패밀리가 포함됩니다. 노드 유형에 대한 자세한 내용은 [지원되는 노드 유형](CacheNodes.SupportedTypes.md) 섹션을 참조하세요.
+ **자동 장애 조치 수정** - 자동 장애 조치를 활성화하거나 비활성화합니다. 장애 조치를 활성화하고 리전 클러스터의 프라이머리 노드가 예기치 않게 종료된 경우 ElastiCache는 리전 복제본 중 하나로 장애 조치합니다. 자세한 내용은 [자동 장애 조치](AutoFailover.md)를 참조하세요.
클러스터 모드가 활성화된 Valkey 또는 Redis OSS 클러스터의 경우:
+ **샤드 추가** - 추가할 샤드 수를 입력하고 선택적으로 하나 이상의 가용 영역을 지정합니다.
+ **샤드 삭제** - 각 AWS 리전에서 삭제할 샤드를 선택합니다.
+ **샤드 재분배** - 슬롯 분포를 재분배하여 클러스터의 기존 샤드 간에 균일한 분포를 보장합니다.
글로벌 데이터 스토어의 파라미터를 수정하려면 글로벌 데이터 스토어에 대한 멤버 클러스터의 파라미터 그룹을 수정합니다. ElastiCache는 자동으로 이 변경 사항을 해당 글로벌 데이터 스토어 내의 모든 클러스터에 적용합니다. 해당 클러스터의 파라미터 그룹을 수정하려면 Valkey 또는 Redis OSS 콘솔 또는 [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) API 작업을 사용합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요. 글로벌 데이터 스토어 내에 포함된 클러스터의 파라미터 그룹을 수정하면 해당 글로벌 데이터 스토어 내의 모든 클러스터에 적용됩니다.
전체 파라미터 그룹 또는 특정 파라미터를 재설정하려면 [ResetCacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ResetCacheParameterGroup.html) API 작업을 사용합니다.
## 보조 클러스터를 기본 클러스터로 승격
기본 클러스터 또는 AWS 리전을 사용할 수 없게 되거나 성능 문제가 발생하면 보조 클러스터를 기본 클러스터로 승격할 수 있습니다. 다른 수정이 진행 중이더라도 언제든지 승격이 허용됩니다. 또한 여러 승력을 병렬로 실행할 수 있으며 글로벌 데이터 스토어가 최종적으로 하나의 기본 클러스터가 됩니다. 여러 보조 클러스터를 동시에 승격하는 경우 ElastiCache에서 궁극적으로 하나의 클러스터가 기본 클러스터가 되는 것을 보장하지 않습니다.
**보조 클러스터를 기본 클러스터로 승격하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택합니다.
1. 세부 정보를 보려면 글로벌 데이터 스토어 이름을 선택합니다.
1. **보조** 클러스터를 선택합니다.
1. **기본 클러스터로 승격**을 선택합니다.
그러면 ` Promoting a region to primary will make the cluster in this region as read/writable. Are you sure you want to promote the secondary cluster to primary?` 경고와 함께 결정을 확인하라는 메시지가 표시됩니다.
`The current primary cluster in primary region will become secondary and will stop accepting writes after this operation completes. Please ensure you update your application stack to direct traffic to the new primary region.`
1. 승력을 계속하려면 **확인**을 선택하고 그렇지 않으면 **취소**를 선택합니다.
확인하려면 글로벌 데이터 스토어가 **수정 중** 상태로 전환되어 승격이 완료될 때까지 사용할 수 없습니다.
## 글로벌 데이터 스토어에서 리전 제거
다음 절차를 사용하여 글로벌 데이터 스토어에서 AWS 리전을 제거할 수 있습니다.
**글로벌 데이터 스토어에서 AWS 리전을 제거하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택합니다.
1. 글로벌 데이터 스토어를 선택합니다.
1. 제거할 **리전**을 선택합니다.
1. **리전 제거**를 선택합니다.
**참고**
이 옵션은 보조 클러스터에만 사용할 수 있습니다.
그러면 ` Removing the region will remove your only available cross region replica for the primary cluster. Your primary cluster will no longer be set up for disaster recovery and improved read latency in remote region. Are you sure you want to remove the selected region from the global datastore?` 경고와 함께 결정을 확인하라는 메시지가 표시됩니다.
1. 승력을 계속하려면 **확인**을 선택하고 그렇지 않으면 **취소**를 선택합니다.
확인을 선택하면 AWS 리전이 제거되고 보조 클러스터는 더 이상 복제 업데이트를 수신하지 않습니다.
## 글로벌 데이터 스토어 삭제
글로벌 데이터 스토어를 삭제하려면 먼저 모든 보조 클러스터를 제거합니다. 자세한 내용은 [글로벌 데이터 스토어에서 리전 제거](#Redis-Global-Datastore-Console-Remove-Region) 섹션을 참조하세요. 이렇게 하면 글로벌 데이터 스토어가 **기본 전용** 상태로 유지됩니다.
**글로벌 데이터 스토어를 삭제하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **글로벌 데이터 저장소**를 선택합니다.
1. **글로벌 데이터 스토어 이름**에서 삭제할 글로벌 데이터 스토어를 선택한 다음 **삭제**를 선택합니다.
그러면 `Are you sure you want to delete this Global Datastore?` 경고와 함께 결정을 확인하라는 메시지가 표시됩니다.
1. **삭제**를 선택합니다.
글로벌 데이터 스토어가 **삭제 중** 상태로 전환됩니다.
# 글로벌 데이터 저장소 사용(CLI)
AWS Command Line Interface(AWS CLI)를 사용하면 명령줄에서 여러 AWS 서비스를 관리하고 스크립트를 통해 자동화할 수 있습니다. 임시(일회성) 작업에 AWS CLI를 사용할 수 있습니다.
## AWS CLI 다운로드 및 구성
AWS CLI는 Windows, macOS 또는 Linux에서 실행됩니다. 다음 절차에 따라 다운로드 및 구성합니다.
**CLI를 다운로드, 설치 및 구성하려면**
1. [AWS Command Line Interface](https://aws.amazon.com/cli) 웹 페이지에서 AWS CLI를 다운로드합니다.
1. *AWS Command Line Interface 사용 설명서*의 AWS CLI 설치 및 AWS CLI 구성 지침을 따릅니다.
## 글로벌 데이터 스토어에 AWS CLI 사용
글로벌 데이터 스토어를 사용하려면 다음 CLI 작업을 사용합니다.
+ [create-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-global-replication-group.html)
```
aws elasticache create-global-replication-group \
--global-replication-group-id-suffix my global datastore \
--primary-replication-group-id sample-repl-group \
--global-replication-group-description an optional description of the global datastore
```
Amazon ElastiCache는 글로벌 데이터 스토어를 생성할 때 자동으로 ID에 접두사를 적용합니다. AWS 리전에는 고유한 접두사가 있습니다. 예를 들어 미국 서부(캘리포니아 북부) 리전에서 생성된 글로벌 데이터 스토어 ID는 사용자가 제공한 접미사 이름과 함께 ‘virxk’로 시작합니다. 접미사는 자동으로 생성된 접두사와 결합되어 여러 리전에서 글로벌 데이터 스토어 이름의 고유성을 보장합니다.
다음 표에는 AWS 리전 및 해당 글로벌 데이터 스토어 ID 접두사가 나와 있습니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/Redis-Global-Datastores-CLI.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html) - 이 작업을 사용하여 글로벌 데이터 스토어의 이름을 `--global-replication-group-id` 파라미터에 제공하여 글로벌 데이터 스토어에 대한 보조 클러스터를 생성합니다.
```
aws elasticache create-replication-group \
--replication-group-id secondary replication group name \
--replication-group-description “Replication group description" \
--global-replication-group-id global datastore name
```
이 작업을 호출하고 `--global-replication-group-id` 값으로 전달하면 ElastiCache 에서 다음 파라미터에 대한 글로벌 복제 그룹의 기본 복제 그룹에서 값을 추론합니다. 다음 파라미터에 대한 값을 전달하지 마십시오.
`"PrimaryClusterId",`
`"AutomaticFailoverEnabled",`
` "NumNodeGroups",`
` "CacheParameterGroupName",`
` "CacheNodeType",`
` "Engine",`
` "EngineVersion",`
` "CacheSecurityGroupNames",`
` "EnableTransitEncryption",`
` "AtRestEncryptionEnabled",`
` "SnapshotArns",`
` "SnapshotName"`
+ [describe-global-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-global-replication-groups.html)
```
aws elasticache describe-global-replication-groups \
--global-replication-group-id my global datastore \
--show-member-info an optional parameter that returns a list of the primary and secondary clusters that make up the global datastore
```
+ [modify-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-global-replication-group.html)
```
aws elasticache modify-global-replication-group \
--global-replication-group-id my global datastore \
--automatic-failover-enabled \
--cache-node-type node type \
--cache-parameter-group-name parameter group name \
--engine-version engine version \
-—apply-immediately \
--global-replication-group-description description
```
**ElastiCache GlobalDataStore를 위한 Redis에서 OSS Valkey로 교차 엔진 업그레이드**
콘솔, API 또는 CLI를 사용하여 기존 Redis OSS 글로벌 복제 그룹을 Valkey로 업그레이드할 수 있습니다.
기존 Redis OSS 글로벌 복제 그룹이 있는 경우 modify-global-replication-group API를 사용하여 새 엔진 및 엔진 버전을 지정하여 Valkey로 업그레이드할 수 있습니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--apply-immediately \
--engine-version 8.0
```
Windows의 경우:
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--apply-immediately ^
--engine-version 8.0
```
업그레이드하려는 기존 Redis OSS 글로벌 복제 그룹에 사용자 지정 캐시 파라미터 그룹이 적용된 경우 요청에서 사용자 지정 Valkey 캐시 파라미터 그룹도 전달해야 합니다. 입력 Valkey 사용자 지정 파라미터 그룹은 기존 Redis OSS 사용자 지정 파라미터 그룹과 동일한 Redis OSS 정적 파라미터 값을 가져야 합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--engine-version 8.0 \
--apply-immediately \
--cache-parameter-group-name myParamGroup
```
Windows의 경우:
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--apply-immediately ^
--cache-parameter-group-name myParamGroup
```
+ [delete-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-global-replication-group.html)
```
aws elasticache delete-global-replication-group \
--global-replication-group-id my global datastore \
--retain-primary-replication-group defaults to true
```
+ [disassociate-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/disassociate-global-replication-group.html)
```
aws elasticache disassociate-global-replication-group \
--global-replication-group-id my global datastore \
--replication-group-id my secondary cluster \
--replication-group-region the AWS Region in which the secondary cluster resides
```
+ [failover-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/failover-global-replication-group.html)
```
aws elasticache failover-replication-group \
--global-replication-group-id my global datastore \
--primary-region The AWS Region of the primary cluster \
--primary-replication-group-id The name of the global datastore, including the suffix.
```
+ [increase-node-groups-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-node-groups-in-global-replication-group.html)
```
aws elasticache increase-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
```
+ [decrease-node-groups-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-node-groups-in-global-replication-group.html)
```
aws elasticache decrease-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
```
+ [rebalance-shards-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/rebalance-slots-in-global-replication-group.html)
```
aws elasticache rebalance-shards-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name
```
도움말을 사용하여 사용 가능한 모든 ElastiCache for Valkey 및 Redis OSS용 명령을 나열합니다.
```
aws elasticache help
```
도움말을 사용하면 특정 명령을 설명하고 그 사용법에 대해 자세히 알아볼 수도 있습니다.
```
aws elasticache create-global-replication-group help
```
# 고가용성을 위한 복제 그룹 사용
단일 노드 Amazon ElastiCache Valkey 또는 Redis OSS 클러스터는 제한된 데이터 보호 서비스(AOF)를 사용할 수 있는 인 메모리 개체입니다. 어떤 이유로든 클러스터에 장애가 발생하면 클러스터의 모든 데이터가 손실됩니다. 그러나 Valkey 또는 Redis OSS 엔진을 실행 중인 경우 2\$16개의 노드를 복제본이 있는 클러스터로 그룹화할 수 있습니다. 이 복제본에서는 1\$15개의 읽기 전용 노드에 해당 그룹의 단일 읽기/쓰기 프라이머리 노드에 대한 복제본 데이터가 포함됩니다. 이 시나리오에서는 어떤 이유로든 한 노드에 장애가 발생해도 데이터가 모두 손실되지는 않습니다. 왜냐하면 한 노드가 하나 이상의 다른 노드에 복제되어 있기 때문입니다. 복제 지연 시간으로 인해 기본 읽기/쓰기 노드가 실패할 경우 일부 데이터가 손실될 수 있습니다.
다음 그래픽에 나와 있는 대로 복제 구조는 Valkey 또는 Redis OSS 클러스터 내에 포함된 샤드(API/CLI에서는 *노드 그룹*이라고 함) 내에 포함되어 있습니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터는 항상 단일 샤드를 포함합니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터는 클러스터의 데이터가 샤드에 분할된 최대 500개의 샤드를 포함할 수 있습니다. 하나의 클러스터당 최대 90개의 노드로 구성된 더 많은 수의 샤드와 더 적은 수의 복제본을 가진 클러스터를 생성할 수 있습니다. 이 클러스터 구성은 90개의 샤드 및 0개의 복제본부터 15개의 샤드 및 5개의 복제본까지 해당될 수 있으며, 이는 허용되는 최대 복제본 수입니다.
노드 또는 샤드 제한을 클러스터당 ElastiCache for Valkey의 경우 최대 500개까지, ElastiCache 엔진 버전 5.0.6 또는 Redis OSS의 경우 그 이상을 사용하여 늘릴 수 있습니다. 예를 들어 83개 샤드(샤드당 기본 1개와 복제본 5개)에서 500개 샤드(기본 1개와 복제본 없음) 범위의 500개 노드 클러스터를 구성하도록 선택할 수 있습니다. 증가를 수용할 수 있는 IP 주소가 충분한지 확인해야 합니다. 서브넷 그룹에 있는 서브넷의 CIDR 범위가 너무 작거나 서브넷을 샤드로 분할하여 다른 클러스터에서 과도하게 사용되는 것과 같은 일반적인 함정에 유의합니다. 자세한 내용은 [서브넷 그룹 생성](SubnetGroups.Creating.md) 섹션을 참조하세요.
5.0.6 이하의 버전에서 한도는 클러스터당 250개입니다.
한도 증가를 요청하려면 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 참조하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택하세요.
![\[이미지: Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 샤드 1개와 복제본 노드 0~5개가 포함\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 샤드 1개와 복제본 노드 0\$15개가 포함*
복제본이 있는 클러스터에 다중 AZ가 활성화되어 있고 프라이머리 노드에 장애가 발생하면 프라이머리 노드가 읽기 전용 복제본으로 장애 조치됩니다. 복제본 노드의 데이터가 비동기적으로 업데이트되기 때문에 복제본 노드를 업데이트할 때 지연 시간으로 인해 일부 데이터가 손실될 수 있습니다. 자세한 내용은 [Valkey 또는 Redis OSS 실행 시 장애 완화](disaster-recovery-resiliency.md#FaultTolerance.Redis) 섹션을 참조하세요.
**Topics**
+ [Valkey 및 Redis OSS 복제 이해](Replication.Redis.Groups.md)
+ [복제: Valkey 및 Redis OSS 클러스터 모드 비활성화됨과 활성화됨](Replication.Redis-RedisCluster.md)
+ [Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 ElastiCache의 가동 중지 시간 최소화](AutoFailover.md)
+ [동기화 및 백업 구현 방법](Replication.Redis.Versions.md)
+ [Valkey 또는 Redis OSS 복제 그룹 생성](Replication.CreatingRepGroup.md)
+ [복제 그룹의 세부 정보 보기](Replication.ViewDetails.md)
+ [복제 그룹 엔드포인트 찾기](Replication.Endpoints.md)
+ [복제 그룹 수정](Replication.Modify.md)
+ [복제 그룹 삭제](Replication.DeletingRepGroup.md)
+ [복제본 수 변경](increase-decrease-replica-count.md)
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 대해 읽기 전용 복제본을 기본으로 승격](Replication.PromoteReplica.md)
# Valkey 및 Redis OSS 복제 이해
Redis OSS는 다음과 같은 2가지 방법으로 복제를 구현합니다.
+ 각 노드에 클러스터의 모든 데이터를 포함하고 있는 샤드 1개가 있음 - Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)
+ 데이터가 최대 500개 샤드로 분할되어 있음 - Valkey 또는 Redis OSS(클러스터 모드 활성화됨)
복제 그룹의 각 샤드에는 읽기/쓰기 기본 노드 하나와 최대 5개의 읽기 전용 복제본 노드가 있습니다. 하나의 클러스터당 최대 90개의 노드로 구성된 더 많은 수의 샤드와 더 적은 수의 복제본을 가진 클러스터를 생성할 수 있습니다. 이 클러스터 구성은 90개의 샤드 및 0개의 복제본부터 15개의 샤드 및 5개의 복제본까지 해당될 수 있으며, 이는 허용되는 최대 복제본 수입니다.
Redis OSS 엔진 버전이 5.0.6 이상인 경우 노드 또는 샤드 한도를 클러스터당 최대 500까지 늘릴 수 있습니다. 예를 들어 83개 샤드(샤드당 기본 1개와 복제본 5개)에서 500개 샤드(기본 1개와 복제본 없음) 범위의 500개 노드 클러스터를 구성하도록 선택할 수 있습니다. 증가를 수용할 수 있는 IP 주소가 충분한지 확인해야 합니다. 서브넷 그룹에 있는 서브넷의 CIDR 범위가 너무 작거나 서브넷을 샤드로 분할하여 다른 클러스터에서 과도하게 사용되는 것과 같은 일반적인 함정에 유의합니다. 자세한 내용은 [서브넷 그룹 생성](SubnetGroups.Creating.md) 섹션을 참조하세요.
5.0.6 이하의 버전에서 한도는 클러스터당 250개입니다.
한도 증가를 요청하려면 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 참조하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택하세요.
**Topics**
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)](#Replication.Redis.Groups.Classic)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)](#Replication.Redis.Groups.Cluster)
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 단일 샤드가 있으며 이 샤드 내에는 노드 모음이 있습니다. 이 모음은 하나의 기본 읽기/쓰기 노드와 최대 5개의 보조 읽기 전용 복제본 노드로 구성됩니다. 각 읽기 전용 복제본은 클러스터의 기본 노드에서 가져온 데이터 사본을 유지합니다. 비동기식 복제 메커니즘은 읽기 전용 복제본이 기본 노드와 동기화되어 있는 상태를 유지하는 데 사용됩니다. 애플리케이션은 클러스터의 모든 노드로부터 읽을 수 있습니다. 애플리케이션은 기본 노드에만 쓸 수 있습니다. 읽기 전용 복제본은 읽기 처리량을 높이고 노드에 장애가 발생할 경우 데이터 손실을 방지합니다.
![\[이미지: 단일 샤드 및 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*단일 샤드 및 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터*
복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 사용하여 솔루션을 ElastiCache에 맞게 조정하여 읽기 집약적인 애플리케이션을 처리하거나 동일한 클러스터에서 동시에 읽는 많은 수의 클라이언트를 지원할 수 있습니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 모든 노드는 같은 리전에 있어야 합니다.
읽기 전용 복제본을 클러스터에 추가하면 기본 노드에 있는 모든 데이터가 새 노드로 복사됩니다. 이 시점부터 기본 노드에 데이터를 쓸 때마다 변경 사항이 모든 읽기 전용 복제본에 비동기식으로 전파됩니다.
내결함성을 개선하고 기록 가동 중지 시간을 단축하려면 복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에 대해 자동 장애 조치가 포함된 다중 AZ를 활성화합니다. 자세한 내용은 [Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 ElastiCache의 가동 중지 시간 최소화](AutoFailover.md) 섹션을 참조하세요.
기본 노드의 역할과 복제본 중 하나의 역할을 서로 교환함으로써 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 내 노드의 역할을 변경할 수 있습니다. 성능 튜닝을 위해 이런 방식을 선택할 수 있습니다. 예를 들어, 쓰기 작업이 많은 웹 애플리케이션의 경우 네트워크 지연 시간이 가장 짧은 노드를 선택할 수 있습니다. 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 대해 읽기 전용 복제본을 기본으로 승격](Replication.PromoteReplica.md) 섹션을 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨)
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터는 1\$1500개의 샤드(API/CLI: 노드 그룹)로 구성됩니다. 각 샤드에는 읽기/쓰기 기본 노드 및 최대 5개의 읽기 전용 복제본 노드가 있습니다. 이 구성은 90개의 샤드 및 0개의 복제본부터 15개의 샤드 및 5개의 복제본까지 해당될 수 있으며, 이는 허용되는 최대 복제본 수입니다.
엔진 버전이 Valkey 7.2 이상 또는 Redis OSS 5.0.6 이상인 경우 노드 또는 샤드 제한을 클러스터당 최대 500개까지 늘릴 수 있습니다. 예를 들어 83개 샤드(샤드당 기본 1개와 복제본 5개)에서 500개 샤드(기본 1개와 복제본 없음) 범위의 500개 노드 클러스터를 구성하도록 선택할 수 있습니다. 증가를 수용할 수 있는 IP 주소가 충분한지 확인해야 합니다. 서브넷 그룹에 있는 서브넷의 CIDR 범위가 너무 작거나 서브넷을 샤드로 분할하여 다른 클러스터에서 과도하게 사용되는 것과 같은 일반적인 함정에 유의합니다. 자세한 내용은 [서브넷 그룹 생성](SubnetGroups.Creating.md) 섹션을 참조하세요.
5.0.6 이하의 버전에서 한도는 클러스터당 250개입니다.
한도 증가를 요청하려면 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 참조하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택하세요.
샤드의 각 읽기 전용 복제본은 샤드의 기본 노드에서 가져온 데이터 사본을 유지합니다. 비동기식 복제 메커니즘은 읽기 전용 복제본이 기본 노드와 동기화되어 있는 상태를 유지하는 데 사용됩니다. 애플리케이션은 클러스터의 모든 노드로부터 읽을 수 있습니다. 애플리케이션은 기본 노드에만 쓸 수 있습니다. 읽기 전용 복제본은 읽기 확장성을 개선하고 데이터 손실을 방지합니다. 데이터는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 샤드 간에 파티셔닝됩니다.
애플리케이션은 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 *구성 엔드포인트*를 사용하여 클러스터의 노드와 연결합니다. 자세한 내용은 [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md) 섹션을 참조하세요.
![\[이미지: 다중 샤드 및 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-RedisClusters.png)
*다중 샤드 및 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터*
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 모든 노드는 같은 리전에 있어야 합니다. 내결함성을 개선하기 위해 해당 리전 내의 여러 가용 영역에서 기본 노드와 읽기 전용 복제본을 모두 프로비저닝할 수 있습니다.
현재 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 기능에는 몇 가지 제한이 있습니다.
+ 복제본 노드는 수동으로 기본 노드로 승격할 수 없습니다.
# 복제: Valkey 및 Redis OSS 클러스터 모드 비활성화됨과 활성화됨
Valkey 7.2 및 Redis OSS 버전 3.2부터는 서로 다른 두 클러스터(API/CLI의 경우 복제 그룹) 유형 중 하나를 생성할 수 있습니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 최대 5개의 읽기 전용 복제본 노드가 있는 단일 샤드(API/CLI의 경우 노드 그룹)가 항상 있습니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에는 각각 읽기 전용 복제본 노드가 1\$15개인 샤드가 최대 500개 있습니다.
![\[이미지: Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 및 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-NodeGroups.png)
*Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 및 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터*
다음 표에는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터와 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 중요한 차이점이 요약되어 있습니다.
**Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 및 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 비교**
| Feature | Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) | Valkey 또는 Redis OSS(클러스터 모드 활성화됨) |
| --- | --- | --- |
| 수정 가능 | 예. 복제본 노드 추가/삭제 및 노드 유형 확장을 지원합니다. | 제한. 자세한 내용은 [ElastiCache용 버전 관리](VersionManagement.md) 및 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) 섹션을 참조하세요. |
| 데이터 파티셔닝 | 아니요 | 예 |
| 샤드 | 1 | 1\$1500 |
| 읽기 전용 복제본 | 0\$15 복제본이 없으며 노드에 장애가 발생하면 전체 데이터가 손실됩니다. | 샤드당 0\$15개.복제본이 없으며 노드에 장애가 발생하면 전체 데이터가 손실됩니다. |
| Multi-AZ | 예, 최소 1개의 복제본이 있어야 합니다.선택 사항입니다. 기본적으로 활성화되어 있습니다. | 예선택 사항입니다. 기본적으로 활성화되어 있습니다. |
| 스냅샷(백업) | 예, 단일 .rdb 파일을 생성합니다. | 예, 각 샤드에 고유한 .rdb 파일을 생성합니다. |
| 복원 | 예, Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에서 단일 .rdb 파일을 사용합니다. | 예, Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 단일 .rdb 파일을 사용합니다. |
| 지원되는 버전 | 모든 Valkey 및 Redis OSS 버전 | 모든 Valkey 버전 및 Redis OSS 3.2 이상 |
| 엔진 업그레이드 가능 여부 | 예, 하지만 몇 가지 제약이 있습니다. 자세한 내용은 [ElastiCache용 버전 관리](VersionManagement.md) 섹션을 참조하세요. | 예, 하지만 몇 가지 제약이 있습니다. 자세한 내용은 [ElastiCache용 버전 관리](VersionManagement.md) 섹션을 참조하세요. |
| 암호화 | 버전 3.2.6(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 및 4.0.10 이상. | 버전 3.2.6(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 및 4.0.10 이상. |
| HIPAA 적격 | 버전 3.2.6(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 및 4.0.10 이상. | 버전 3.2.6(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 및 4.0.10 이상. |
| PCI DSS 준수 | 버전 3.2.6(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 및 4.0.10 이상. | 버전 3.2.6(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 및 4.0.10 이상. |
| 온라인 리샤딩 | N/A | 버전 3.2.10(EOL 예정, [Redis OSS 버전 수명 종료 일정](engine-versions.md#deprecated-engine-versions) 참조) 이상. |
## 어떤 클러스터를 선택해야 합니까?
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 중에서 선택할 때는 다음 사항을 고려하세요.
+ **조정과 파티셔닝** - 비즈니스 요구는 변화합니다. 최고 수요가 발생할 때를 대비하거나 수요가 변화함에 따라 조정해야 합니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)는 규모 조정을 지원합니다. 복제본 노드를 추가하거나 삭제하여 읽기 용량을 조정하거나 더 큰 노드 유형까지 확장하여 용량을 조정할 수 있습니다. 이 두 작업은 모두 시간이 소요됩니다. 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 복제본 노드 규모 조정](Scaling.RedisReplGrps.md) 섹션을 참조하세요.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨)는 최대 500개의 노드 그룹으로 데이터 분할을 지원합니다. 비즈니스에 변경이 필요할 때마다 샤드 수를 동적으로 변경할 수 있습니다. 파티셔닝의 이점 중 하나는 로드를 더 많은 엔드포인트로 분산시켜 최고 수요가 발생할 때 액세스 병목 현상을 줄이는 것입니다. 또한 데이터가 여러 서버에 분산될 수 있으므로 더 큰 데이터 세트를 수용할 수 있습니다. 파티션 규모 조정에 대한 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) 섹션을 참조하세요.
+ **노드 크기와 노드 수** - Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 샤드가 하나만 있기 때문에 노드 유형이 클러스터의 모든 데이터와 필요한 오버헤드를 수용할 수 있을 만큼 충분히 커야 합니다. 반면 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 사용하면 데이터를 여러 샤드에 파티셔닝할 수 있기 때문에 데이터가 더 필요해도 노드 유형이 더 작을 수 있습니다. 자세한 내용은 [노드 크기 선택](CacheNodes.SelectSize.md) 섹션을 참조하세요.
+ **읽기와 쓰기** - 클러스터의 기본 로드가 데이터를 읽는 애플리케이션인 경우 읽기 전용 복제본을 추가하고 삭제하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 조정할 수 있습니다. 그러나 5개 읽기 전용 복제본의 최대치가 있습니다. 클러스터의 로드가 주로 쓰기 작업인 경우 여러 샤드가 있는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 추가 쓰기 엔드포인트가 유용할 수 있습니다.
어떤 유형의 클러스터를 구현하도록 선택하든 현재와 미래의 요구에 적합한 노드 유형을 선택해야 합니다.
# Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 ElastiCache의 가동 중지 시간 최소화
ElastiCache for Valkey 및 Redis OSS가 프라이머리 노드를 대체해야 하는 여러 가지 경우가 있습니다. 이러한 경우에는 특정 유형의 계획적인 유지 관리 및 드물지만 프라이머리 노드나 가용 영역에 장애가 발생하는 경우가 포함됩니다.
이러한 교체로 인해 클러스터에 약간의 가동 중지가 발생하지만 다중 AZ를 활성화한 경우 가동 중지 시간이 최소화됩니다. 프라이머리 노드의 역할은 자동으로 읽기 전용 복제본 중 하나로 장애 조치됩니다. ElastiCache가 이 장애 조치를 투명하게 처리하기 때문에 새로운 프라이머리 노드를 생성하고 프로비저닝할 필요가 없습니다. 이 장애 조치 및 복제본 승격을 통해 승격이 완료되는 즉시 새 프라이머리 노드에 작성을 재개할 수 있습니다.
또한 ElastiCache는 승격된 복제본의 DNS(Domain Name Service) 이름을 전파합니다. 이렇게 하면 애플리케이션이 기본 엔드포인트에 쓰는 경우 애플리케이션에서 엔드포인트를 변경할 필요가 없기 때문입니다. 개별 엔드포인트를 읽을 경우 기본으로 승격된 복제본의 읽기 엔드포인트를 새 복제본의 엔드포인트로 변경해야 합니다.
계획된 노드 교체의 경우, 유지 관리 업데이트 또는 셀프 서비스 업데이트로 인해 시작되었으며 다음 사항에 유의하세요.
+ Valkey 및 Redis OSS 클러스터의 경우, 클러스터에서 들어오는 쓰기 요청을 처리하는 중에 계획된 노드 교체가 완료됩니다.
+ 다중 AZ가 활성화되어 5.0.6 이상 엔진에서 실행 중인 Valkey 및 Redis OSS 클러스터 모드 비활성화 클러스터의 경우, 클러스터에서 들어오는 쓰기 요청을 처리하는 중에 계획된 노드 교체가 완료됩니다.
+ 다중 AZ가 활성화되어 4.0.10 이하 엔진에서 실행 중인 Valkey 및 Redis OSS 클러스터 모드 비활성화 클러스터의 경우, DNS 업데이트와 관련하여 짧은 쓰기 중단이 발생할 수 있습니다. 이 중단은 최대 몇 초가 걸릴 수 있습니다. 이 프로세스는 다중 AZ를 활성화하지 않은 경우 발생하는, 새 프라이머리 노드를 다시 생성하고 프로비저닝하는 것보다 훨씬 빠릅니다.
ElastiCache 관리 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 다중 AZ를 활성화할 수 있습니다.
Valkey 또는 Redis OSS 클러스터(API 및 CLI의 복제 그룹)의 ElastiCache 다중 AZ를 활성화하면 내결함성이 개선됩니다. 특히 클러스터의 읽기/쓰기 기본 클러스터 노드에 접속할 수 없거나 어떤 이유로든 실패하는 경우에 특히 그렇습니다. 다중 AZ는 각 샤드에 둘 이상의 노드가 있는 Valkey 및 Redis OSS 클러스터에서만 지원됩니다.
**Topics**
+ [다중 AZ 활성화](#AutoFailover.Enable)
+ [다중 AZ 응답이 있는 장애 시나리오](#AutoFailover.Scenarios)
+ [자동 장애 조치 테스트](#auto-failover-test)
+ [다중 AZ에 대한 제한 사항](#AutoFailover.Limitations)
## 다중 AZ 활성화
ElastiCache 콘솔, AWS CLI CLI 또는 ElastiCache API를 사용하여 클러스터(API 또는 CLI, 복제 그룹)를 생성하거나 수정하면 다중 AZ를 활성화할 수 있습니다.
사용 가능한 읽기 전용 복제본이 하나 이상 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에서만 다중 AZ를 활성화할 수 있습니다. 읽기 전용 복제본이 없는 클러스터는 고가용성 또는 내결함성을 제공하지 않습니다. 복제하여 클러스터를 생성에 대한 정보는 [Valkey 또는 Redis OSS 복제 그룹 생성](Replication.CreatingRepGroup.md)을 참조하세요. 복제하여 있는 클러스터에 읽기 전용 복제본 추가에 대한 정보는 [Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 추가(클러스터 모드 비활성화됨)](Replication.AddReadReplica.md)를 참조하세요.
**Topics**
+ [다중 AZ 활성화(콘솔)](#AutoFailover.Enable.Console)
+ [다중 AZ 활성화(AWS CLI)](#AutoFailover.Enable.CLI)
+ [다중 AZ 활성화(ElastiCache API)](#AutoFailover.Enable.API)
### 다중 AZ 활성화(콘솔)
새 Valkey 또는 Redis OSS 클러스터를 생성하거나 기존 클러스터를 복제하여 수정할 때 ElastiCache 콘솔을 사용하여 다중 AZ를 활성화할 수 있습니다.
다중 AZ는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 기본적으로 활성화되어 있습니다.
**중요**
ElastiCache는 클러스터에 모든 샤드의 프라이머리 노드에서 다른 가용 영역에 있는 복제본이 하나 이상 포함된 경우에만 다중 AZ를 자동으로 활성화합니다.
#### ElastiCache 콘솔을 사용하여 클러스터를 생성할 때 다중 AZ 활성화
이 프로세스에 대한 자세한 내용은 [Valkey(클러스터 모드 비활성화됨) 클러스터 생성(콘솔)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)을 참조하세요. 복제본이 하나 이상 있어야 하고 다중 AZ를 활성화해야 합니다.
#### 기존 클러스터에서 다중 AZ 활성화(콘솔)
이 프로세스에 대한 자세한 내용은 클러스터 수정 [ElastiCache AWS Management Console 사용](Clusters.Modify.md#Clusters.Modify.CON)섹션을 참조하세요.
### 다중 AZ 활성화(AWS CLI)
다음 코드 예제에서는 AWS CLI를 사용하여 복제 그룹 `redis12`에 대해 다중 AZ를 활성화합니다.
**중요**
복제 그룹 `redis12`가 이미 존재해야 하며 사용할 수 있는 읽기 전용 복제본이 하나 이상 있어야 합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id redis12 \
--automatic-failover-enabled \
--multi-az-enabled \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id redis12 ^
--automatic-failover-enabled ^
--multi-az-enabled ^
--apply-immediately
```
이 명령의 JSON 출력은 다음과 같습니다.
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "One shard, two nodes",
"NodeGroups": [
{
"Status": "modifying",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "redis12",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabling",
"MultiAZ": "enabled",
"SnapshotWindow": "07:00-08:00",
"SnapshottingClusterId": "redis12-002",
"MemberClusters": [
"redis12-001",
"redis12-002"
],
"PendingModifiedValues": {}
}
}
```
자세한 내용은 *AWS CLI 명령 참조*의 다음 항목을 참조하세요.
+ [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ *AWS CLI 명령 참조*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)
### 다중 AZ 활성화(ElastiCache API)
다음 코드 예제에서는 ElastiCache API를 사용하여 복제 그룹 `redis12`에 대해 다중 AZ를 활성화합니다.
**참고**
이 예제를 사용하려면 복제 그룹 `redis12`가 이미 존재해야 하며 사용할 수 있는 읽기 전용 복제본이 하나 이상 있어야 합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&AutoFailover=true
&MultiAZEnabled=true
&ReplicationGroupId=redis12
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=
```
자세한 내용은*ElastiCache API 참조*에서 다음 주제들을 참조하세요.
+ [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html):
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html):
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
## 다중 AZ 응답이 있는 장애 시나리오
다중 AZ를 도입하기 전에 ElastiCache는 장애가 발생한 노드를 재생성하고 재프로비저닝하여 클러스터의 장애가 발생한 노드를 탐지해 교체했습니다. 다중 AZ를 활성화하면 장애가 발생한 프라이머리 노드가 복제 지연이 가장 짧은 복제본으로 장애 조치됩니다. 선택한 복제본이 자동으로 승격되기 때문에 새 프라이머리 노드를 생성하고 프로비저닝하는 것보다 훨씬 빠릅니다. 이 프로세스는 보통 클러스터에 다시 작성하려면 몇 초 정도 소요됩니다.
다중 AZ가 활성화된 경우 ElastiCache가 프라이머리 노드의 상태를 지속적으로 모니터링합니다. 프라이머리 노드에 장애가 발생하면 장애 유형에 따라 다음 작업 중 하나가 수행됩니다.
**Topics**
+ [프라이머리 노드에만 장애가 발생한 경우의 장애 시나리오](#AutoFailover.Scenarios.PrimaryOnly)
+ [프라이머리 노드 및 일부 읽기 전용 복제본에 장애가 발생한 경우의 장애 시나리오](#AutoFailover.Scenarios.PrimaryAndReplicas)
+ [전체 클러스터에 장애가 발생한 경우의 장애 시나리오](#AutoFailover.Scenarios.AllFail)
### 프라이머리 노드에만 장애가 발생한 경우의 장애 시나리오
프라이머리 노드에 장애가 발생하면 복제 지연 시간이 가장 짧은 읽기 전용 복제본을 프라이머리 노드로 승격시킵니다. 그러면 대체 읽기 전용 복제본이 생성되어 장애가 발생한 프라이머리 노드와 동일한 가용 영역에 프로비저닝됩니다.
프라이머리 노드에만 장애가 발생한 경우 ElastiCache 다중 AZ는 다음 작업을 수행합니다.
1. 장애가 발생한 프라이머리 노드는 오프라인 상태로 전환됩니다.
1. 복제 지연 시간이 가장 짧은 읽기 전용 복제본을 기본으로 승격시킵니다.
승격 프로세스가 완료되는 즉시 쓰기를 재개할 수 있으며 일반적으로 몇 초 정도 소요됩니다. 애플리케이션이 기본 엔드포인트에 쓰는 경우 쓰기 또는 읽기에 대한 엔드포인트를 변경할 필요가 없습니다. ElastiCache가 승격된 복제본의 DNS 이름을 전파합니다.
1. 대체 읽기 전용 복제본을 시작하고 프로비저닝합니다.
장애가 발생한 프라이머리 노드가 있는 가용 영역에서 대체 읽기 전용 복제본을 시작하여 노드 배포를 유지합니다.
1. 복제본이 새 프라이머리 노드와 동기화됩니다.
새 복제본을 사용할 수 있게 되면 다음 효과에 유의하세요.
+ **기본 엔드포인트** - 새 프라이머리 노드의 DNS 이름이 기본 엔드포인트로 전파되므로 애플리케이션을 변경할 필요가 없습니다.
+ **읽기 엔드포인트** - 리더 엔드포인트는 새 복제본 노드를 가리키도록 자동으로 업데이트됩니다.
클러스터의 엔드포인트를 찾는 방법에 대한 정보는 다음 항목을 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 엔드포인트 찾기(콘솔)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(ElastiCache API)](Endpoints.md#Endpoints.Find.API.ReplGroups)
### 프라이머리 노드 및 일부 읽기 전용 복제본에 장애가 발생한 경우의 장애 시나리오
기본 복제본 및 하나 이상의 복제본에 장애가 발생하면 지연 시간이 가장 짧은 사용 가능한 복제본이 기본 클러스터로 승격됩니다. 또한 기본으로 승격된 복제본 및 장애가 발생한 노드로 새로운 읽기 전용 복제본이 동일 가용 영역에 생성되고 프로비저닝됩니다.
프라이머리 노드와 일부 읽기 전용 복제본에 장애가 발생한 경우 ElastiCache 다중 AZ는 다음 작업을 수행합니다.
1. 장애가 발생한 프라이머리 노드 및 읽기 전용 복제본이 오프라인 상태로 전환됩니다.
1. 복제 지연 시간이 가장 짧은 사용 가능한 복제본을 프라이머리 노드로 승격시킵니다.
승격 프로세스가 완료되는 즉시 쓰기를 재개할 수 있으며 일반적으로 몇 초 정도 소요됩니다. 애플리케이션이 기본 엔드포인트에 쓰는 경우 쓰기에 대한 엔드포인트를 변경할 필요가 없습니다. ElastiCache가 승격된 복제본의 DNS 이름을 전파합니다.
1. 교체용 복제본을 생성하고 프로비저닝합니다.
장애가 발생한 노드의 가용 영역에서 교체용 복제본을 생성하여 노드 배포를 유지합니다.
1. 모든 클러스터가 새 프라이머리 노드와 동기화됩니다.
새 노드를 사용할 수 있게 되면 애플리케이션을 다음과 같이 변경합니다.
+ **기본 엔드포인트** - 애플리케이션을 변경하지 마십시오. 새 프라이머리 노드의 DNS 이름이 기본 엔드포인트로 전파됩니다.
+ **읽기 엔드포인트** - 읽기 엔드포인트는 새 복제본 노드를 가리키도록 자동으로 업데이트됩니다.
복제 그룹의 엔드포인트를 찾는 방법에 대한 정보는 다음 항목을 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 엔드포인트 찾기(콘솔)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(ElastiCache API)](Endpoints.md#Endpoints.Find.API.ReplGroups)
### 전체 클러스터에 장애가 발생한 경우의 장애 시나리오
모든 것에 장애가 발생하면 모든 노드를 동일한 가용 영역에 원본 노드로 재생성하고 프로비저닝합니다.
이 시나리오에서는 클러스터의 모든 노드에 장애가 발생하여 클러스터의 모든 데이터가 손실됩니다. 이는 거의 발생하지 않습니다.
전체 클러스터에 장애가 발생한 경우 ElastiCache 다중 AZ는 다음 작업을 수행합니다.
1. 장애가 발생한 프라이머리 노드 및 읽기 전용 복제본이 오프라인 상태로 전환됩니다.
1. 대체 프라이머리 노드를 생성하고 프로비저닝합니다.
1. 교체용 복제본을 생성하고 프로비저닝합니다.
장애가 발생한 노드의 가용 영역에서 대체를 생성하여 노드 배포를 유지합니다.
전체 클러스터에 장애가 발생했으므로 데이터가 손실되고 모든 새 노드가 콜드를 시작합니다.
각각의 교체 노드에는 교체하는 노드와 동일한 엔드포인트가 있기 때문에 애플리케이션에서 엔드포인트를 변경할 필요가 없습니다.
복제 그룹의 엔드포인트를 찾는 방법에 대한 정보는 다음 항목을 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 엔드포인트 찾기(콘솔)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(ElastiCache API)](Endpoints.md#Endpoints.Find.API.ReplGroups)
내결함성 수준을 높이려면 다른 가용 영역에 프라이머리 노드 및 읽기 전용 복제본을 생성하는 것이 좋습니다.
## 자동 장애 조치 테스트
자동 장애 조치를 활성화한 후에는 ElastiCache 콘솔, AWS CLI 및 ElastiCache API를 사용하여 이를 테스트할 수 있습니다.
테스트 시 다음 사항에 유의하세요.
+ 이 작업을 통해 24시간 동안 최대 15개의 샤드(ElastiCache API 및 AWS CLI의 경우 노드 그룹)에서 자동 장애 조치를 테스트할 수 있습니다.
+ 다른 클러스터(API 및 CLI의 복제 그룹이라고 함)에 있는 샤드에서 이 작업을 동시에 호출할 수 있습니다.
+ 경우에 따라 동일한 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹의 서로 다른 샤드에서 이 작업을 여러 번 호출할 수 있습니다. 이러한 경우 후속 호출이 이루어지기 전에 첫 번째 노드 교체가 완료되어야 합니다.
+ 노드 교체가 완료되었는지 확인하려면 Amazon ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 이벤트를 점검합니다. 발생 순서대로 나열되어 있는 아래 목록에서 다음과 같은 자동 장애 조치 관련 이벤트를 찾습니다.
1. 복제 그룹 메시지: `Test Failover API called for node group `
1. 캐시 클러스터 메시지: `Failover from primary node to replica node completed`
1. 복제 그룹 메시지: `Failover from primary node to replica node completed`
1. 캐시 클러스터 메시지: `Recovering cache nodes `
1. 캐시 클러스터 메시지: `Finished recovery for cache nodes `
자세한 내용은 다음 자료를 참조하세요.
+ *ElastiCache 사용 설명서*의 [ElastiCache 이벤트 보기](ECEvents.Viewing.md)
+ *ElastiCache API 참조*의 [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)
+ *AWS CLI 명령 참조*의 [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html)
+ 이 API는 ElastiCache 장애 조치의 경우 애플리케이션의 동작을 테스트하도록 설계되었습니다. 클러스터 문제를 해결하기 위해 장애 조치를 시작하는 운영 도구로 설계되지 않았습니다. 또한 대규모 운영 이벤트와 같은 특정 조건에서는 AWS가 이 API를 차단할 수 있습니다.
**Topics**
+ [AWS Management Console을 사용하여 자동 장애 조치 테스트](#auto-failover-test-con)
+ [AWS CLI를 사용하여 자동 장애 조치 테스트](#auto-failover-test-cli)
+ [ElastiCache API를 사용하여 자동 장애 조치 테스트](#auto-failover-test-api)
### AWS Management Console을 사용하여 자동 장애 조치 테스트
다음 절차에 따라 콘솔로 자동 장애 조치를 테스트합니다.
**자동 장애 조치를 테스트하려면**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택합니다.
1. 클러스터 목록에서 테스트할 클러스터 왼쪽에 있는 확인란을 선택합니다. 이 클러스터에는 읽기 전용 복제본 노드가 하나 이상 있어야 합니다.
1. [**Details**] 영역에서 이 클러스터가 다중 AZ 활성 상태인지 확인합니다. 해당 클러스터가 다중 AZ 활성 상태가 아닌 경우 다른 클러스터를 선택하거나 다중 AZ를 활성화하도록 이 클러스터를 수정합니다. 자세한 내용은 [ElastiCache AWS Management Console 사용](Clusters.Modify.md#Clusters.Modify.CON) 섹션을 참조하세요.
![\[이미지: 다중 AZ가 활성화된 클러스터의 세부 정보 영역\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)의 경우 클러스터 이름을 선택합니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨)의 경우 다음을 수행합니다.
1. 클러스터의 이름을 선택합니다.
1. [**Shards**] 페이지에서 장애 조치를 테스트할 샤드(API 및 CLI의 노드 그룹이라고 함)에 대해 샤드 이름을 선택합니다.
1. 노드 페이지에서 [**Failover Primary**]를 선택합니다.
1. 프라이머리 노드를 장애 조치하려면 [**Continue**]를 선택하고 작업을 취소하여 프라이머리 노드를 장애 조치하지 않으려면 [**Cancel**]을 선택합니다.
장애 조치 프로세스 중에 콘솔은 노드 상태를 계속해서 *사용 가능*으로 표시합니다. 장애 조치 테스트 진행률을 추적하려면 콘솔 탐색 창에서 [**Events**]를 선택합니다. [**Events**] 탭에서 장애 조치의 시작(`Test Failover API called`) 및 완료(`Recovery completed`)를 나타내는 이벤트를 주시합니다.
### AWS CLI를 사용하여 자동 장애 조치 테스트
AWS CLI 작업 `test-failover`를 사용하여 모든 다중 AZ가 활성화된 클러스터에서 자동 장애 조치를 테스트할 수 있습니다.
**파라미터**
+ `--replication-group-id` - 필수입니다. 테스트할 복제 그룹(콘솔, 클러스터)입니다.
+ `--node-group-id` - 필수입니다. 자동 장애 조치를 테스트할 노드 그룹의 이름입니다. 24시간 동안 최대 15개의 노드 그룹을 테스트할 수 있습니다.
다음 예제에서는 AWS CLI를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `redis00`의 노드 그룹 `redis00-0003`에 대한 자동 장애 조치를 테스트합니다.
**Example 자동 장애 조치 테스트**
Linux, macOS, Unix의 경우:
```
aws elasticache test-failover \
--replication-group-id redis00 \
--node-group-id redis00-0003
```
Windows의 경우:
```
aws elasticache test-failover ^
--replication-group-id redis00 ^
--node-group-id redis00-0003
```
이전 명령의 출력은 다음과 같습니다.
```
{
"ReplicationGroup": {
"Status": "available",
"Description": "1 shard, 3 nodes (1 + 2 replicas)",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ClusterEnabled": false,
"ReplicationGroupId": "redis1x3",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotWindow": "11:30-12:30",
"SnapshottingClusterId": "redis1x3-002",
"MemberClusters": [
"redis1x3-001",
"redis1x3-002",
"redis1x3-003"
],
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
장애 조치 진행률을 추적하려면 AWS CLI `describe-events` 작업을 사용하세요.
자세한 내용은 다음 자료를 참조하세요.
+ *AWS CLI 명령 참조*의 [test-failover](https://docs.aws.amazon.com/cli/latest/reference/elasticache/test-failover.html)
+ *AWS CLI 명령 참조*의 [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html)
### ElastiCache API를 사용하여 자동 장애 조치 테스트
ElastiCache API 작업 `TestFailover`를 사용하여 다중 AZ가 활성화된 모든 클러스터에서 자동 장애 조치를 테스트할 수 있습니다.
**파라미터**
+ `ReplicationGroupId` - 필수입니다. 테스트할 복제 그룹(콘솔, 클러스터)입니다.
+ `NodeGroupId` - 필수입니다. 자동 장애 조치를 테스트할 노드 그룹의 이름입니다. 24시간 동안 최대 15개의 노드 그룹을 테스트할 수 있습니다.
다음 예제에서는 복제 그룹(콘솔, 클러스터에서) `redis00-0003`의 노드 그룹 `redis00`에 대한 자동 장애 조치를 테스트합니다.
**Example 자동 장애 조치 테스트**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=TestFailover
&NodeGroupId=redis00-0003
&ReplicationGroupId=redis00
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=
```
장애 조치 진행률을 추적하려면 ElastiCache `DescribeEvents` API 작업을 사용하세요.
자세한 내용은 다음 자료를 참조하세요.
+ *ElastiCache API 참조*의 [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
+ *ElastiCache API 참조*의 [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)
## 다중 AZ에 대한 제한 사항
다중 AZ에 대한 다음 제한 사항에 유의하세요.
+ 다중 AZ는 Valkey 및 Redis OSS 버전 2.8.6 이상에서 지원됩니다.
+ 다중 AZ는 T1 노드 유형에서는 지원되지 않습니다.
+ Valkey 및 Redis OSS 복제는 비동기식입니다. 따라서 프라이머리 노드를 복제본으로 장애 조치하면 복제 지연으로 인해 소량의 데이터가 손실될 수 있습니다.
기본으로 승격할 복제본을 선택할 때 ElastiCache는 최소 복제 지연 시간으로 복제본을 선택합니다. 즉, 가장 최신 복제본을 선택합니다. 이로써 손실 데이터 양을 최소화할 수 있습니다. 복제 지연 시간이 가장 짧은 복제본은 실패한 프라이머리 노드와 같은 가용 영역에 있을 수도 있고 다른 가용 영역에 있을 수도 있습니다.
+ 클러스터 모드가 비활성화된 Valkey 또는 Redis OSS 클러스터에서 읽기 전용 복제본을 기본 복제본으로 수동으로 승격하는 경우 다중 AZ 및 자동 장애 조치가 비활성화된 경우에만 이 작업을 수행할 수 있습니다. 읽기 전용 복제본을 기본으로 승격하려면 다음 단계를 따릅니다.
1. 클러스터에서 다중 AZ를 비활성화합니다.
1. 클러스터에서 자동 장애 조치를 비활성화합니다. 이 작업은 콘솔을 통해 복제 그룹의 **자동 장애 조치** 확인란을 선택 취소하여 수행할 수 있습니다. 또한 AWS CLI를 통해 `ModifyReplicationGroup` 작업을 호출할 때 `AutomaticFailoverEnabled` 속성을 `false`로 설정하여 이렇게 할 수 있습니다.
1. 읽기 전용 복제본을 기본으로 승격합니다.
1. 다중 AZ를 다시 활성화합니다.
+ ElastiCache for Redis OSS 다중 AZ와 AOF(Append-Only File)는 함께 사용할 수 없습니다. 하나를 활성화하면 다른 하나를 활성화할 수 없습니다.
+ 노드 장애는 드물지만 전체 가용 영역에 장애가 발생하는 경우로 인해 발생할 수 있습니다. 이 경우 장애가 발생한 기본 서버를 대체하는 복제본은 가용 영역이 백업된 경우에만 생성됩니다. 예를 들어, AZ-a에 프라이머리 노드가 있고 AZ-b 및 AZ-c에 복제본이 있는 복제 그룹을 가정해 보겠습니다. 프라이머리 노드에 문제가 발생하면 복제 지연 시간이 가장 짧은 사용 가능한 복제본을 프라이머리 노드로 승격시킵니다. 그런 다음 ElastiCache는 AZ-a가 백업되어 사용할 수 있는 경우에만 AZ-a(장애가 발생한 기본이 있는 위치)에 새 복제본을 생성합니다.
+ 고객이 실행한 기본 재부팅은 자동 장애 조치를 트리거하지 않습니다. 다른 재부팅 및 장애는 자동 장애 조치를 트리거합니다.
+ 기본을 재부팅하는 경우 온라인 상태가 되면 데이터가 지워집니다. 읽기 전용 복제본은 기본 클러스터가 지워진 것을 확인하면 데이터 복제본을 지우기 때문에 데이터가 손실됩니다.
+ 읽기 전용 복제본이 승격된 후 다른 복제본은 새 기본 복제본과 동기화됩니다. 초기 동기화 후 복제본의 콘텐츠가 삭제되고 새 기본 복제본의 데이터가 동기화됩니다. 이 동기화 프로세스로 인해 복제본에 액세스할 수 없는 잠깐 중단이 발생합니다. 또한 이 동기화 프로세스로 인해 복제본과 동기화되는 동안 기본에 임시 로드가 증가합니다. 이 동작은 Valkey 및 Redis OSS의 기본 동작이며 ElastiCache 다중 AZ에 고유하지 않습니다. 이 동작에 대한 자세한 내용은 Valkey 웹 사이트의 [복제](http://valkey.io/topics/replication)를 참조하세요.
**중요**
Valkey 7.2.6 이상 또는 Redis OSS 버전 2.8.22 이상에서는 외부 복제본을 만들 수 없습니다.
2.8.22 이전의 Redis OSS 버전에서는 다중 AZ가 활성화된 ElastiCache 클러스터에 외부 복제본을 연결하지 않는 것이 좋습니다. 이 지원되지 않는 구성으로 ElastiCache가 장애 조치 및 복구를 제대로 수행하지 못하는 문제를 유발할 수 있습니다. 외부 복제본을 ElastiCache 클러스터에 연결하려면 연결하기 전에 다중 AZ가 활성화되지 않았는지 확인합니다.
# 동기화 및 백업 구현 방법
지원되는 모든 버전의 Valkey 또는 Redis OSS는 기본 클러스터와 복제본 클러스터 간의 백업 및 동기화를 지원합니다. 그러나 백업 및 동기화가 구현되는 방식은 버전에 따라 다릅니다.
## Redis OSS 버전 2.8.22 이상
버전 2.8.22 이상에서 Redis OSS 복제는 두 가지 방법 중 하나를 선택합니다. 자세한 내용은 [Redis OSS 2.8.22 이전 버전](#Replication.Redis.Earlier2-8-22) 및 [스냅샷 및 복원](backups.md)(을)를 참조하세요.
포크 없는 프로세스 중 쓰기 로드가 많으면 변경 사항이 너무 많이 누적되어 성공적인 스냅샷을 방해하는 일이 발생하지 않도록 클러스터에 대한 쓰기가 지연됩니다.
## Redis OSS 2.8.22 이전 버전
2.8.22 이전 버전의 Redis OSS 백업 및 동기화는 3단계 프로세스입니다.
1. 포크하고 백그라운드 프로세스에서 클러스터 데이터를 디스크에 직렬화합니다. 그러면 특정 시점 스냅샷이 생성됩니다.
1. 포그라운드에서 *클라이언트 출력 버퍼*에 변경 로그를 누적합니다.
**중요**
변경 로그가 *클라이언트 출력 버퍼* 크기를 초과하면 백업 또는 동기화가 실패합니다. 자세한 내용은 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md) 섹션을 참조하세요.
1. 마지막으로 캐시 데이터와 변경 로그를 순서대로 복제본 클러스터에 전송합니다.
# Valkey 또는 Redis OSS 복제 그룹 생성
복제본 노드가 있는 클러스터를 생성하기 위한 다음과 같은 옵션이 있습니다. 한 옵션은 프라이머리 노드로 사용되는 복제본이 있는 클러스터와 연결이 안된 사용 가능한 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터가 이미 있을 때 적용됩니다. 다른 옵션은 클러스터와 읽기 전용 복제본으로 기본 노드를 생성해야할 때 적용됩니다. 현재는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 처음부터 생성해야 합니다.
**옵션 1: [기존 클러스터를 사용하여 복제 그룹 생성](Replication.CreatingReplGroup.ExistingCluster.md)**
기존 단일 노드 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 활용하려면 이 옵션을 사용합니다. 이 기존 노드를 새 클러스터의 기본 노드로 지정하고 클러스터에 1개\$15개의 읽기 전용 복제본을 개별적으로 추가합니다. 기존 클러스터가 활성 상태인 경우 읽기 복제본은 생성되는 대로 해당 클러스터와 동기화됩니다. [기존 클러스터를 사용하여 복제 그룹 생성](Replication.CreatingReplGroup.ExistingCluster.md)을(를) 참조하세요.
기존 클러스터를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 생성할 수 없습니다. ElastiCache 콘솔을 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(API/CLI: 복제 그룹)를 생성하려면 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 생성(콘솔)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) 섹션을 참조하세요.
**옵션 2: [처음부터 Valkey 또는 Redis OSS 복제 그룹 생성](Replication.CreatingReplGroup.NoExistingCluster.md)**
클러스터의 프라이머리 노드로 사용하는 가용 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터가 없거나 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 생성하고 싶은 경우 이 옵션을 사용합니다. [처음부터 Valkey 또는 Redis OSS 복제 그룹 생성](Replication.CreatingReplGroup.NoExistingCluster.md)을(를) 참조하세요.
# 기존 클러스터를 사용하여 복제 그룹 생성
다음 절차에서는 클러스터를 최신 버전의 Valkey로 업그레이드하는 데 필요한 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 단일 노드 클러스터에 복제 그룹을 추가합니다. 가동 중지 시간과 데이터 손실이 전혀 없는 인플레이스 절차입니다. 단일 노드 클러스터에 대한 복제 그룹을 생성하면 클러스터의 노드가 새 클러스터의 프라이머리 노드가 됩니다. 새 클러스터의 프라이머리 노드로 사용할 수 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터가 없는 경우 [처음부터 Valkey 또는 Redis OSS 복제 그룹 생성](Replication.CreatingReplGroup.NoExistingCluster.md) 섹션을 참조하세요.
사용 가능한 클러스터는 기존 단일 노드 Valkey 또는 Redis OSS 클러스터입니다. 현재 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에서는 사용 가능한 단일 노드 클러스터를 사용하여 복제본이 있는 클러스터를 생성할 수 없습니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 생성하려면 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 생성(콘솔)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON) 섹션을 참조하세요.
## 기존 클러스터를 사용하여 복제 그룹 생성(콘솔)
[ElastiCache AWS Management Console사용](Clusters.AddNode.md#Clusters.AddNode.CON) 항목을 참조하세요.
## 사용 가능한 Valkey 또는 Redis OSS 클러스터를 사용하여 복제 그룹 생성(AWS CLI)
AWS CLI를 사용할 때 프라이머리 노드에 대해 사용 가능한 Valkey 또는 Redis OSS 캐시 클러스터를 사용하는 경우 읽기 전용 복제본이 있는 복제 그룹을 생성하는 두 단계가 있습니다.
를 사용하는AWS CLI경우 사용 가능한 독립 실행형 노드를 클러스터의 프라이머리 노드로 지정`--primary-cluster-id`하고 CLI 명령를 사용하여 클러스터에서 원하는 노드 수를 지정하는 복제 그룹을 생성합니다`create-replication-group`. 다음 파라미터를 포함합니다.
**--replication-group-id**
생성하는 복제 그룹의 이름입니다. 이 파라미터의 값은 추가되는 노드의 이름을 지정하는 기준으로 사용되는데, `--replication-group-id` 끝에 3자리 일련 번호가 추가됩니다. 예를 들어 `sample-repl-group-001`입니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**--replication-group-description**
복제 그룹에 대한 설명입니다.
**--num-node-groups**
이 클러스터에 있는 노드의 수. 이 값에는 프라이머리 노드가 포함됩니다. 이 파라미터의 최대값은 6입니다.
**--primary-cluster-id**
이 복제 그룹의 프라이머리 노드가 될 사용 가능한 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 노드의 이름입니다.
다음 명령은 사용 가능한 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 `redis01`을 복제 그룹의 프라이머리 노드로 사용해 복제 그룹 `sample-repl-group`을 생성합니다. 이렇게 하면 읽기 전용 복제본인 새 노드 2개가 생성됩니다. `redis01`의 설정(즉, 파라미터 그룹, 보안 그룹, 노드 유형, 엔진 버전 등)은 복제 그룹의 모든 노드에 적용됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "demo cluster with replicas" \
--num-cache-clusters 3 \
--primary-cluster-id redis01
```
Windows의 경우:
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "demo cluster with replicas" ^
--num-cache-clusters 3 ^
--primary-cluster-id redis01
```
사용할 수 있는 추가 정보 및 파라미터는AWS CLI주제를 참조하세요[create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
**다음으로 복제 그룹에 읽기 전용 복제본을 추가합니다.**
복제 그룹이 생성된 후 `create-cache-cluster` 명령을 사용하여 해당 복제 그룹에 1\$15개의 읽기 전용 복제본을 추가하여 다음 파라미터를 포함해야 합니다.
**--cache-cluster-id**
복제 그룹에 추가하는 클러스터의 이름입니다.
클러스터 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**--replication-group-id**
이 클러스터를 추가하는 복제 그룹의 이름입니다.
`--cache-cluster-id` 파라미터 값만 변경하여 복제 그룹에 추가할 각 읽기 전용 복제본마다 이 명령을 반복합니다.
**참고**
복제 그룹에는 읽기 전용 복제본이 최대 5개로 제한됩니다. 읽기 전용 복제본 5개가 이미 있는 복제 그룹에 읽기 전용 복제본을 추가하려고 하면 작업이 실패합니다.
다음 코드는 읽기 전용 복제본 `my-replica01`을 복제 그룹 `sample-repl-group`에 추가합니다. 기본 클러스터의 설정(즉, 파라미터 그룹, 보안 그룹, 노드 유형 등)은 복제 그룹에 추가될 때 노드에도 적용됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-replica01 \
--replication-group-id sample-repl-group
```
Windows의 경우:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-replica01 ^
--replication-group-id sample-repl-group
```
이 명령의 출력은 다음과 같습니다.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "00:00-01:00",
"SnapshottingClusterId": "redis01",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"redis01"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
자세한 내용은 다음AWS CLI주제를 참조하세요.
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)
## 독립형 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에 복제본 추가(ElastiCache API)
ElastiCache API를 사용하는 경우 사용 가능한 독립형 노드를 클러스터의 프라이머리 노드인 `PrimaryClusterId`로 지정하고, CLI 명령 `CreateReplicationGroup`을 사용해 클러스터에 필요한 노드 수를 지정해 복제 그룹을 생성합니다. 다음 파라미터를 포함합니다.
**ReplicationGroupId**
생성하는 복제 그룹의 이름입니다. 이 파라미터의 값은 추가되는 노드의 이름을 지정하는 기준으로 사용되는데, `ReplicationGroupId` 끝에 3자리 일련 번호가 추가됩니다. 예를 들어 `sample-repl-group-001`입니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**ReplicationGroupDescription**
복제본이 있는 클러스터에 대한 설명입니다.
**NumCacheClusters**
이 클러스터에 있는 노드의 수. 이 값에는 프라이머리 노드가 포함됩니다. 이 파라미터의 최대값은 6입니다.
**PrimaryClusterId**
이 클러스터의 프라이머리 노드가 될 사용 가능한 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 이름입니다.
다음 명령은 사용 가능한 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 `redis01`을 복제 그룹의 프라이머리 노드로 사용해 복제본 `sample-repl-group`으로 클러스터를 생성합니다. 이렇게 하면 읽기 전용 복제본인 새 노드 2개가 생성됩니다. `redis01`의 설정(즉, 파라미터 그룹, 보안 그룹, 노드 유형, 엔진 버전 등)은 복제 그룹의 모든 노드에 적용됩니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&Engine=redis
&EngineVersion=6.0
&ReplicationGroupDescription=Demo%20cluster%20with%20replicas
&ReplicationGroupId=sample-repl-group
&PrimaryClusterId=redis01
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 ElastiCache APL 주제를 참조하세요.
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
**다음으로 복제 그룹에 읽기 전용 복제본을 추가합니다.**
복제 그룹이 생성된 후 `CreateCacheCluster` 작업을 사용하여 해당 복제 그룹에 1\$15개의 읽기 전용 복제본을 추가하여 다음 파라미터를 포함해야 합니다.
**CacheClusterId**
복제 그룹에 추가하는 클러스터의 이름입니다.
클러스터 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**ReplicationGroupId**
이 클러스터를 추가하는 복제 그룹의 이름입니다.
`CacheClusterId` 파라미터 값만 변경하여 복제 그룹에 추가할 각 읽기 전용 복제본마다 이 작업을 반복합니다.
다음 코드는 읽기 전용 복제본 `myReplica01`을 복제 그룹 `myReplGroup`에 추가합니다. 기본 클러스터의 설정(즉, 파라미터 그룹, 보안 그룹, 노드 유형 등)은 복제 그룹에 추가될 때 노드에도 적용됩니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReplica01
&ReplicationGroupId=myReplGroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2015-02-02
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=[your-access-key-id]/20150202/us-west-2/elasticache/aws4_request
&X-Amz-Date=20150202T170651Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=[signature-value]
```
사용할 파라미터에 대한 자세한 내용은 ElastiCache API 항목 [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html)를 참조하세요.
# 처음부터 Valkey 또는 Redis OSS 복제 그룹 생성
다음에 기존 Valkey 또는 Redis OSS 클러스터를 기본으로 사용하지 않고 Valkey 또는 Redis OSS 복제 그룹을 생성하는 방법이 나와 있습니다. ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 처음부터 생성할 수 있습니다.
계속하기 전에 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 생성할지 아니면 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 생성할지를 결정합니다. 결정에 대한 지침은 [복제: Valkey 및 Redis OSS 클러스터 모드 비활성화됨과 활성화됨](Replication.Redis-RedisCluster.md)를 참조하세요.
**Topics**
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 새로 생성](Replication.CreatingReplGroup.NoExistingCluster.Classic.md)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에서 복제 그룹을 처음부터 새로 생성](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md)
# Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 새로 생성
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 생성할 수 있습니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에는 항상 하나의 노드 그룹, 하나의 기본 클러스터 및 최대 5개의 읽기 전용 복제본이 있습니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹은 데이터 파티셔닝을 지원하지 않습니다.
**참고**
노드/샤드 한도는 클러스터당 최대 500개로 늘릴 수 있습니다. 제한을 높이도록 요청하려면 [AWS 서비스 제한](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)을 참조하고 요청에 인스턴스 유형을 포함하세요.
처음부터 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 만들려면 다음 방법 중 하나를 수행합니다.
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 새로 생성(AWS CLI)
다음 절차에서는 AWS CLI를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 생성합니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 생성할 때 AWS CLI `create-replication-group` 명령을 한 번만 호출하여 복제 그룹과 해당 노드를 모두 생성합니다. 다음 파라미터를 포함합니다.
**--replication-group-id**
생성하는 복제 그룹의 이름입니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**--replication-group-description**
복제 그룹에 대한 설명입니다.
**--num-cache-clusters**
이 복제 그룹, 기본 및 읽기 전용 복제본과 함께 생성하려는 노드의 수입니다.
다중 AZ(`--automatic-failover-enabled`)를 활성화하는 경우 `--num-cache-clusters`의 값은 2 이상이어야 합니다.
**--cache-node-type**
복제 그룹에 있는 각 노드의 노드 유형입니다.
ElastiCache는 다음 노드 유형을 지원합니다. 일반적으로, 현재 세대 유형은 이전 세대의 동급 제품에 비해 더 많은 메모리와 컴퓨팅 파워를 더 저렴하게 제공합니다.
각 노드 유형의 성능 세부 정보에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
**- 데이터 계층화 지원**
r6gd 노드 유형을 사용하는 경우 이 파라미터를 설정합니다. 데이터 계층화를 원하지 않는 경우 `--no-data-tiering-enabled`를 설정합니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
**--cache-parameter-group**
엔진 버전에 해당하는 파라미터 그룹을 지정합니다. Redis OSS 3.2.4 이상을 실행하는 경우 `default.redis3.2` 파라미터 그룹 또는 `default.redis3.2`에서 파생된 파라미터 그룹을 지정하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 생성합니다. 자세한 내용은 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
**--network-type**
`ipv4`, `ipv6`, `dual-stack` 중 하나입니다. 듀얼 스택을 선택한 경우, `--IpDiscovery` 파라미터를 `ipv4` 또는 `ipv6`로 설정해야 합니다.
**--엔진**
redis
**--engine-version**
다양한 기능 세트를 사용하려면 최신 엔진 버전을 선택합니다.
`-00`*\$1*을 복제 그룹 이름 뒤에 붙이면 복제 그룹 이름에서 노드 이름이 파생됩니다. 예를 들어, 복제 그룹 이름 `myReplGroup`을 사용하는 경우 기본 이름은 `myReplGroup-001`이 되고, 읽기 전용 복제본 이름은 `myReplGroup-002`에서 `myReplGroup-006` 사이가 됩니다.
이 복제 그룹에서 전송 중 데이터 암호화 또는 미사용 데이터 암호화를 활성화하려면 `--transit-encryption-enabled` 또는 `--at-rest-encryption-enabled` 파라미터 중 하나 또는 둘 다를 추가하고 다음 조건을 충족해야 합니다.
+ 복제 그룹에서 3.2.6 또는 4.0.10 버전 Redis OSS를 실행하고 있어야 합니다.
+ 복제 그룹은 Amazon VPC에 생성되어야 합니다.
+ 또한 `--cache-subnet-group` 파라미터도 포함해야 합니다.
+ 또한 이 복제 그룹에서 작업을 수행하는 데 필요한 AUTH 토큰(암호)에 고객이 지정한 문자열 값이 있는 `--auth-token` 파라미터도 포함해야 합니다.
다음 작업은 세 개의 노드(기본 한 개와 복제본 두 개)가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 `sample-repl-group`을 생성합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "Demo cluster with replicas" \
--num-cache-clusters 3 \
--cache-node-type cache.m4.large \
--engine redis
```
Windows의 경우:
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "Demo cluster with replicas" ^
--num-cache-clusters 3 ^
--cache-node-type cache.m4.large ^
--engine redis
```
이 명령의 출력은 다음과 같습니다.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "disabled",
"SnapshotWindow": "01:30-02:30",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"sample-repl-group-003"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
사용하려는 파라미터에 대한 자세한 내용은 AWS CLI 항목 [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)를 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 새로 생성(ElastiCache API)
다음 절차에서는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 생성합니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 처음부터 생성할 때 ElastiCache API `CreateReplicationGroup` 작업을 한 번만 호출하여 복제 그룹과 해당 노드를 모두 생성합니다. 다음 파라미터를 포함합니다.
**ReplicationGroupId**
생성하는 복제 그룹의 이름입니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**ReplicationGroupDescription**
복제 그룹에 대한 설명입니다.
**NumCacheClusters**
이 복제 그룹, 기본 및 읽기 전용 복제본과 함께 생성하려는 총 노드 수입니다.
다중 AZ(`AutomaticFailoverEnabled=true`)를 활성화하는 경우 `NumCacheClusters`의 값은 2 이상이어야 합니다.
**CacheNodeType**
복제 그룹에 있는 각 노드의 노드 유형입니다.
ElastiCache는 다음 노드 유형을 지원합니다. 일반적으로, 현재 세대 유형은 이전 세대의 동급 제품에 비해 더 많은 메모리와 컴퓨팅 파워를 더 저렴하게 제공합니다.
각 노드 유형의 성능 세부 정보에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
**- 데이터 계층화 지원**
r6gd 노드 유형을 사용하는 경우 이 파라미터를 설정합니다. 데이터 계층화를 원하지 않는 경우 `--no-data-tiering-enabled`를 설정합니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
**CacheParameterGroup**
엔진 버전에 해당하는 파라미터 그룹을 지정합니다. Redis OSS 3.2.4 이상을 실행하는 경우 `default.redis3.2` 파라미터 그룹 또는 `default.redis3.2`에서 파생된 파라미터 그룹을 지정하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 생성합니다. 자세한 내용은 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
**--network-type**
`ipv4`, `ipv`, `dual-stack` 중 하나입니다. 듀얼 스택을 선택한 경우, `--IpDiscovery` 파라미터를 `ipv4` 또는 `ipv6`로 설정해야 합니다.
**엔진**
redis
**EngineVersion**
6.0
`-00`*\$1*을 복제 그룹 이름 뒤에 붙이면 복제 그룹 이름에서 노드 이름이 파생됩니다. 예를 들어, 복제 그룹 이름 `myReplGroup`을 사용하는 경우 기본 이름은 `myReplGroup-001`이 되고, 읽기 전용 복제본 이름은 `myReplGroup-002`에서 `myReplGroup-006` 사이가 됩니다.
이 복제 그룹에서 전송 중 데이터 암호화 또는 미사용 데이터 암호화를 활성화하려면 `TransitEncryptionEnabled=true` 또는 `AtRestEncryptionEnabled=true` 파라미터 중 하나 또는 둘 다를 추가하고 다음 조건을 충족해야 합니다.
+ 복제 그룹에서 3.2.6 또는 4.0.10 버전 Redis OSS를 실행하고 있어야 합니다.
+ 복제 그룹은 Amazon VPC에 생성되어야 합니다.
+ 또한 `CacheSubnetGroup` 파라미터도 포함해야 합니다.
+ 또한 이 복제 그룹에서 작업을 수행하는 데 필요한 AUTH 토큰(암호)에 고객이 지정한 문자열 값이 있는 `AuthToken` 파라미터도 포함해야 합니다.
다음 작업은 세 개의 노드(기본 한 개와 복제본 두 개)가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 `myReplGroup`을 생성합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParameterGroup=default.redis6.x
&Engine=redis
&EngineVersion=6.0
&NumCacheClusters=3
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
사용할 파라미터에 대한 자세한 내용은 ElastiCache API 항목 [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)을 참조하세요.
# Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에서 복제 그룹을 처음부터 새로 생성
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(API/CLI: *복제 그룹*)를 생성할 수 있습니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹에는 1\$1500개의 샤드(API/CLI의 경우 노드 그룹), 각 샤드의 프라이머리 노드 1개 및 각 샤드의 최대 5개의 읽기 전용 복제본이 있습니다. 하나의 클러스터당 최대 90개의 노드로 구성된 더 많은 수의 샤드와 더 적은 수의 복제본을 가진 클러스터를 생성할 수 있습니다. 이 클러스터 구성은 90개의 샤드 및 0개의 복제본부터 15개의 샤드 및 5개의 복제본까지 해당될 수 있으며, 이는 허용되는 최대 복제본 수입니다.
Valkey 또는 Redis OSS 엔진 버전이 5.0.6 이상인 경우 노드 또는 샤드 한도를 클러스터당 최대 500까지 늘릴 수 있습니다. 예를 들어 83개 샤드(샤드당 기본 1개와 복제본 5개)에서 500개 샤드(기본 1개와 복제본 없음) 범위의 500개 노드 클러스터를 구성하도록 선택할 수 있습니다. 증가를 수용할 수 있는 IP 주소가 충분한지 확인해야 합니다. 서브넷 그룹에 있는 서브넷의 CIDR 범위가 너무 작거나 서브넷을 샤드로 분할하여 다른 클러스터에서 과도하게 사용되는 것과 같은 일반적인 함정에 유의합니다. 자세한 내용은 [서브넷 그룹 생성](SubnetGroups.Creating.md) 섹션을 참조하세요.
5.0.6 이하의 버전에서 한도는 클러스터당 250개입니다.
한도 증가를 요청하려면 [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 참조하고 한도 유형을 **인스턴스 유형별 클러스터당 노드**로 선택하세요.
**Topics**
+ [ElastiCache 콘솔 사용](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
+ [처음부터 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 만들기(AWS CLI)](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에서 복제 그룹을 처음부터 새로 생성(ElastiCache API)](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.API)
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 생성(콘솔)
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 생성하려면 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 생성(콘솔)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)를 참조하세요. **클러스터 모드 활성화(스케일 아웃)**에서 클러스터 모드를 활성화하고 두 개 이상의 샤드와 한 개의 복제본 노드를 지정합니다.
## 처음부터 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 만들기(AWS CLI)
다음 절차에서는 AWS CLI를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 생성합니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 처음부터 생성할 때 AWS CLI `create-replication-group` 명령을 한 번만 호출하여 복제 그룹과 해당 노드를 모두 생성합니다. 다음 파라미터를 포함합니다.
**--replication-group-id**
생성하는 복제 그룹의 이름입니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**--replication-group-description**
복제 그룹에 대한 설명입니다.
**--cache-node-type**
복제 그룹에 있는 각 노드의 노드 유형입니다.
ElastiCache는 다음 노드 유형을 지원합니다. 일반적으로, 현재 세대 유형은 이전 세대의 동급 제품에 비해 더 많은 메모리와 컴퓨팅 파워를 더 저렴하게 제공합니다.
각 노드 유형의 성능 세부 정보에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
**- 데이터 계층화 지원**
r6gd 노드 유형을 사용하는 경우 이 파라미터를 설정합니다. 데이터 계층화를 원하지 않는 경우 `--no-data-tiering-enabled`를 설정합니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
**--cache-parameter-group**
`default.redis6.x.cluster.on` 파라미터 그룹 또는 `default.redis6.x.cluster.on`에서 파생된 파라미터 그룹을 지정하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 생성합니다. 자세한 내용은 [Redis OSS 6.x 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x) 섹션을 참조하세요.
**--엔진**
redis
**--engine-version**
3.2.4
**--num-node-groups**
이 복제 그룹의 노드 그룹 수입니다. 유효한 값은 1\$1500입니다.
노드/샤드 한도는 클러스터당 최대 500개로 늘릴 수 있습니다. 한도 증가를 요청하는 방법에 대한 지침은 [AWS 서비스 제한](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)을 참조하고 한도 유형을 '인스턴스 유형별 클러스터당 노드’로 선택하세요.
**--replicas-per-node-group**
각 노드 그룹의 복제본 노드 수입니다. 유효한 값은 0\$15입니다.
**--network-type**
`ipv4`, `ipv`, `dual-stack` 중 하나입니다. 듀얼 스택을 선택한 경우, `--IpDiscovery` 파라미터를 `ipv4` 또는 `ipv6`로 설정해야 합니다.
이 복제 그룹에서 전송 중 데이터 암호화 또는 미사용 데이터 암호화를 활성화하려면 `--transit-encryption-enabled` 또는 `--at-rest-encryption-enabled` 파라미터 중 하나 또는 둘 다를 추가하고 다음 조건을 충족해야 합니다.
+ 복제 그룹에서 3.2.6 또는 4.0.10 버전 Redis OSS를 실행하고 있어야 합니다.
+ 복제 그룹은 Amazon VPC에 생성되어야 합니다.
+ 또한 `--cache-subnet-group` 파라미터도 포함해야 합니다.
+ 또한 이 복제 그룹에서 작업을 수행하는 데 필요한 AUTH 토큰(암호)에 고객이 지정한 문자열 값이 있는 `--auth-token` 파라미터도 포함해야 합니다.
다음 작업은 세 개의 노드 그룹/샤드(--num-node-groups)가 있는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 `sample-repl-group`을 생성합니다. 이 복제 그룹은 각각 3개의 노드, 즉 프라이머리 노드 1개와 읽기 전용 복제본 2개(--replicas-per-node-group)로 구성됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "Demo cluster with replicas" \
--num-node-groups 3 \
--replicas-per-node-group 2 \
--cache-node-type cache.m4.large \
--engine redis \
--security-group-ids SECURITY_GROUP_ID \
--cache-subnet-group-name SUBNET_GROUP_NAME>
```
Windows의 경우:
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "Demo cluster with replicas" ^
--num-node-groups 3 ^
--replicas-per-node-group 2 ^
--cache-node-type cache.m4.large ^
--engine redis ^
--security-group-ids SECURITY_GROUP_ID ^
--cache-subnet-group-name SUBNET_GROUP_NAME>
```
앞에 나온 명령은 다음 출력을 생성합니다.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "enabled",
"SnapshotWindow": "05:30-06:30",
"MemberClusters": [
"sample-repl-group-0001-001",
"sample-repl-group-0001-002",
"sample-repl-group-0001-003",
"sample-repl-group-0002-001",
"sample-repl-group-0002-002",
"sample-repl-group-0002-003",
"sample-repl-group-0003-001",
"sample-repl-group-0003-002",
"sample-repl-group-0003-003"
],
"PendingModifiedValues": {}
}
}
```
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제본 그룹을 처음부터 생성할 때 2개의 노드 그룹(콘솔의 경우 샤드)을 구성하는 다음 예제와 같이 `--node-group-configuration` 파라미터를 사용하여 클러스터의 각 샤드를 구성할 수 있습니다. 첫 번째 샤드에는 2개의 노드(기본 1개, 읽기 전용 복제본 1개)가 있습니다. 두 번째 샤드에는 세 개의 노드(기본 한 개와 읽기 전용 복제본 두 개)가 있습니다.
**--node-group-configuration**
각 노드 그룹의 구성입니다. `--node-group-configuration` 파라미터는 다음 필드로 구성됩니다.
+ `PrimaryAvailabilityZone` - 이 노드 그룹의 프라이머리 노드가 있는 가용 영역입니다. 이 파라미터가 생략되면 ElastiCache는 프라이머리 노드의 가용 영역을 선택합니다.
**예:** us-west-2a.
+ `ReplicaAvailabilityZones` - 읽기 전용 복제본이 있는 가용 영역의 쉼표로 구분된 목록입니다. 이 목록의 가용 영역 수는 `ReplicaCount` 값과 일치해야 합니다. 이 파라미터가 생략되면 ElastiCache는 복제본 노드의 가용 영역을 선택합니다.
**예:** "us-west-2a,us-west-2b,us-west-2c"
+ `ReplicaCount` - 이 노드 그룹의 복제본 노드 수입니다.
+ `Slots` - 노드 그룹의 키스페이스를 지정하는 문자열입니다. 문자열 형식은 `startKey-endKey`입니다. 이 파라미터가 생략되면 ElastiCache는 키를 노드 그룹 간에 균등하게 할당합니다.
**예:** "0-4999"
다음 작업은 2개의 노드 그룹/샤드(`--num-node-groups`)가 있는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 `new-group`을 생성합니다. 위 예제와 달리 각 노드 그룹은 다른 노드 그룹(`--node-group-configuration`)과 다르게 구성됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-replication-group \
--replication-group-id new-group \
--replication-group-description "Sharded replication group" \
--engine redis \
--snapshot-retention-limit 8 \
--cache-node-type cache.m4.medium \
--num-node-groups 2 \
--node-group-configuration \
"ReplicaCount=1,Slots=0-8999,PrimaryAvailabilityZone='us-east-1c',ReplicaAvailabilityZones='us-east-1b'" \
"ReplicaCount=2,Slots=9000-16383,PrimaryAvailabilityZone='us-east-1a',ReplicaAvailabilityZones='us-east-1a','us-east-1c'"
```
Windows의 경우:
```
aws elasticache create-replication-group ^
--replication-group-id new-group ^
--replication-group-description "Sharded replication group" ^
--engine redis ^
--snapshot-retention-limit 8 ^
--cache-node-type cache.m4.medium ^
--num-node-groups 2 ^
--node-group-configuration \
"ReplicaCount=1,Slots=0-8999,PrimaryAvailabilityZone='us-east-1c',ReplicaAvailabilityZones='us-east-1b'" \
"ReplicaCount=2,Slots=9000-16383,PrimaryAvailabilityZone='us-east-1a',ReplicaAvailabilityZones='us-east-1a','us-east-1c'"
```
앞에 나온 작업은 다음 출력을 생성합니다.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Sharded replication group",
"ReplicationGroupId": "rc-rg",
"SnapshotRetentionLimit": 8,
"AutomaticFailover": "enabled",
"SnapshotWindow": "10:00-11:00",
"MemberClusters": [
"rc-rg-0001-001",
"rc-rg-0001-002",
"rc-rg-0002-001",
"rc-rg-0002-002",
"rc-rg-0002-003"
],
"PendingModifiedValues": {}
}
}
```
사용할 파라미터에 대한 자세한 내용은 AWS CLI 주제 [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)를 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에서 복제 그룹을 처음부터 새로 생성(ElastiCache API)
다음 절차에서는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 생성합니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 처음부터 생성할 때 ElastiCache API `CreateReplicationGroup` 작업을 한 번만 호출하여 복제 그룹과 해당 노드를 모두 생성합니다. 다음 파라미터를 포함합니다.
**ReplicationGroupId**
생성하는 복제 그룹의 이름입니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 명명 제약 조건은 다음과 같습니다.
+ 1\$140자의 영숫자 또는 하이픈으로 구성되어야 합니다.
+ 문자로 시작해야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
**ReplicationGroupDescription**
복제 그룹에 대한 설명입니다.
**NumNodeGroups**
이 복제 그룹과 함께 생성할 노드 그룹 수입니다. 유효한 값은 1\$1500입니다.
**ReplicasPerNodeGroup**
각 노드 그룹의 복제본 노드 수입니다. 유효한 값은 1\$15입니다.
**NodeGroupConfiguration**
각 노드 그룹의 구성입니다. `NodeGroupConfiguration` 파라미터는 다음 필드로 구성됩니다.
+ `PrimaryAvailabilityZone` - 이 노드 그룹의 프라이머리 노드가 있는 가용 영역입니다. 이 파라미터가 생략되면 ElastiCache는 프라이머리 노드의 가용 영역을 선택합니다.
**예:** us-west-2a.
+ `ReplicaAvailabilityZones` - 읽기 전용 복제본이 있는 가용 영역 목록입니다. 이 목록의 가용 영역 수는 `ReplicaCount` 값과 일치해야 합니다. 이 파라미터가 생략되면 ElastiCache는 복제본 노드의 가용 영역을 선택합니다.
+ `ReplicaCount` - 이 노드 그룹의 복제본 노드 수입니다.
+ `Slots` - 노드 그룹의 키스페이스를 지정하는 문자열입니다. 문자열 형식은 `startKey-endKey`입니다. 이 파라미터가 생략되면 ElastiCache는 키를 노드 그룹 간에 균등하게 할당합니다.
**예:** "0-4999"
**CacheNodeType**
복제 그룹에 있는 각 노드의 노드 유형입니다.
ElastiCache는 다음 노드 유형을 지원합니다. 일반적으로, 현재 세대 유형은 이전 세대의 동급 제품에 비해 더 많은 메모리와 컴퓨팅 파워를 더 저렴하게 제공합니다.
각 노드 유형의 성능 세부 정보에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
**- 데이터 계층화 지원**
r6gd 노드 유형을 사용하는 경우 이 파라미터를 설정합니다. 데이터 계층화를 원하지 않는 경우 `--no-data-tiering-enabled`를 설정합니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 섹션을 참조하세요.
**CacheParameterGroup**
`default.redis6.x.cluster.on` 파라미터 그룹 또는 `default.redis6.x.cluster.on`에서 파생된 파라미터 그룹을 지정하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 생성합니다. 자세한 내용은 [Redis OSS 6.x 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x) 섹션을 참조하세요.
**--network-type**
`ipv4`, `ipv`, `dual-stack` 중 하나입니다. 듀얼 스택을 선택한 경우, `--IpDiscovery` 파라미터를 `ipv4` 또는 `ipv6`로 설정해야 합니다.
**엔진**
redis
**EngineVersion**
6.0
이 복제 그룹에서 전송 중 데이터 암호화 또는 미사용 데이터 암호화를 활성화하려면 `TransitEncryptionEnabled=true` 또는 `AtRestEncryptionEnabled=true` 파라미터 중 하나 또는 둘 다를 추가하고 다음 조건을 충족해야 합니다.
+ 복제 그룹에서 3.2.6 또는 4.0.10 버전 Redis OSS를 실행하고 있어야 합니다.
+ 복제 그룹은 Amazon VPC에 생성되어야 합니다.
+ 또한 `CacheSubnetGroup` 파라미터도 포함해야 합니다.
+ 또한 이 복제 그룹에서 작업을 수행하는 데 필요한 AUTH 토큰(암호)에 고객이 지정한 문자열 값이 있는 `AuthToken` 파라미터도 포함해야 합니다.
줄바꿈은 가독성을 높이기 위해 추가되었습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParemeterGroup=default.redis6.xcluster.on
&Engine=redis
&EngineVersion=6.0
&NumNodeGroups=3
&ReplicasPerNodeGroup=2
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
사용할 파라미터에 대한 자세한 내용은 ElastiCache API 항목 [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)을 참조하세요.
# 복제 그룹의 세부 정보 보기
복제 그룹의 세부 정보를 보려는 경우가 있습니다. ElastiCache 콘솔, ElastiCache용 AWS CLI 또는 ElastiCache API를 사용할 수 있습니다. 콘솔 프로세스는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)와 Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 따라 다릅니다.
**Contents**
+ [복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 보기](Replication.ViewDetails.Redis.md)
+ [ElastiCache 콘솔 사용](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CON)
+ [AWS CLI 사용](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CLI)
+ [ElastiCache API 사용](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.API)
+ [복제 그룹 보기: Valkey 또는 Redis OSS(클러스터 모드 활성화)](Replication.ViewDetails.RedisCluster.md)
+ [ElastiCache 콘솔 사용](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CON)
+ [AWS CLI 사용](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CLI)
+ [ElastiCache API 사용](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.API)
+ [복제 그룹의 세부 정보 보기(AWS CLI)](Replication.ViewDetails.CLI.md)
+ [복제 그룹의 세부 정보 보기(ElastiCache API)](Replication.ViewDetails.API.md)
# 복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 보기
ElastiCache 콘솔, ElastiCache용 AWS CLI 또는 ElastiCache API를 사용하여 복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터(API/CLI: *복제 그룹*)의 세부 정보를 볼 수 있습니다.
**Contents**
+ [ElastiCache 콘솔 사용](#Replication.ViewDetails.Redis.CON)
+ [AWS CLI 사용](#Replication.ViewDetails.Redis.CLI)
+ [ElastiCache API 사용](#Replication.ViewDetails.Redis.API)
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 보기(콘솔)
ElastiCache 콘솔을 사용하여 복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 세부 정보를 보는 방법은 [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 세부 정보 보기(콘솔)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.Redis) 항목을 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 보기(AWS CLI)
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 세부 정보를 표시하는 AWS CLI 예제에 대한 내용은 [복제 그룹의 세부 정보 보기(AWS CLI)](Replication.ViewDetails.CLI.md) 섹션을 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 보기(ElastiCache API)
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 세부 정보를 표시하는 ElastiCache API 예제에 대한 내용은 [복제 그룹의 세부 정보 보기(ElastiCache API)](Replication.ViewDetails.API.md) 섹션을 참조하세요.
# 복제 그룹 보기: Valkey 또는 Redis OSS(클러스터 모드 활성화)
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 보기(콘솔)
ElastiCache 콘솔을 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 세부 정보를 보는 방법은 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 세부 정보 보기(콘솔)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.RedisCluster) 섹션을 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 보기(AWS CLI)
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹의 세부 정보를 표시하는 ElastiCache CLI 예제에 대한 내용은 [복제 그룹의 세부 정보 보기(AWS CLI)](Replication.ViewDetails.CLI.md) 섹션을 참조하세요.
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 보기(ElastiCache API)
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹의 세부 정보를 표시하는 ElastiCache API 예제에 대한 내용은 [복제 그룹의 세부 정보 보기(ElastiCache API)](Replication.ViewDetails.API.md) 섹션을 참조하세요.
# 복제 그룹의 세부 정보 보기(AWS CLI)
AWS CLI `describe-replication-groups` 명령을 사용하여 복제 그룹의 세부 정보를 볼 수 있습니다. 목록을 구체화하려면 다음과 같은 선택적 파라미터를 사용합니다. 파라미터가 생략되면 최대 100개의 복제 그룹에 대한 세부 정보가 반환됩니다.
**선택 사항 파라미터**
+ `--replication-group-id` - 이 파라미터를 사용하여 지정한 복제 그룹의 세부 정보를 나열합니다. 지정한 복제 그룹의 노드 그룹이 둘 이상인 경우 결과가 노드 그룹별로 그룹화되어 반환됩니다.
+ `--max-items` - 이 파라미터를 사용하여 나열된 복제 그룹 수를 제한합니다. `--max-items`의 값은 20 이상 또는 100 이하여야 합니다.
**Example**
다음 코드는 최대 100개의 복제 그룹에 대한 세부 정보를 나열합니다.
```
aws elasticache describe-replication-groups
```
다음 코드는 `sample-repl-group`의 세부 정보를 나열합니다.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
다음 코드는 `sample-repl-group`의 세부 정보를 나열합니다.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
다음 코드는 최대 25개의 복제 그룹에 대한 세부 정보를 나열합니다.
```
aws elasticache describe-replication-groups --max-items 25
```
이 작업의 출력은 다음과 같습니다(JSON 형식).
```
{
"ReplicationGroups": [
{
"Status": "available",
"Description": "test",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-001.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-002.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-003.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "rg-name.1abc4d.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "rg-name",
"AutomaticFailover": "enabled",
"SnapshottingClusterId": "rg-name-002",
"MemberClusters": [
"rg-name-001",
"rg-name-002",
"rg-name-003"
],
"PendingModifiedValues": {}
},
{
... some output omitted for brevity
}
]
}
```
자세한 내용은 ElastiCache용 AWS CLI 항목 [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html)를 참조하세요.
# 복제 그룹의 세부 정보 보기(ElastiCache API)
AWS CLI `DescribeReplicationGroups` 작업을 사용하여 복제의 세부 정보를 볼 수 있습니다. 목록을 구체화하려면 다음과 같은 선택적 파라미터를 사용합니다. 파라미터가 생략되면 최대 100개의 복제 그룹에 대한 세부 정보가 반환됩니다.
**선택 사항 파라미터**
+ `ReplicationGroupId` - 이 파라미터를 사용하여 지정한 복제 그룹의 세부 정보를 나열합니다. 지정한 복제 그룹의 노드 그룹이 둘 이상인 경우 결과가 노드 그룹별로 그룹화되어 반환됩니다.
+ `MaxRecords` - 이 파라미터를 사용하여 나열된 복제 그룹 수를 제한합니다. `MaxRecords`의 값은 20 이상 또는 100 이하여야 합니다. 기본값은 100입니다.
**Example**
다음 코드는 최대 100개의 복제 그룹에 대한 세부 정보를 나열합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
다음 코드는 `myReplGroup`의 세부 정보를 나열합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
다음 코드는 클러스터 최대 25개의 세부 정보를 나열합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 정보는 ElastiCache API 참조 항목 을 참조하세요[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)
# 복제 그룹 엔드포인트 찾기
애플리케이션은 복제 그룹에 있는 어떤 노드에도 연결할 수 있습니다. 단, 애플리케이션에 해당 노드에 대한 DNS 엔드포인트 및 포트 번호가 있어야 합니다. 실행 중인 복제 그룹이 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)인지, 아니면 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹인지에 따라 관심을 갖게 되는 엔트포인트가 달라집니다.
**Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)**
복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 세 가지 유형의 엔드포인트(*기본 엔드포인트*, *리더 엔드포인트* 및 *노드 엔드포인트*)가 있습니다. 기본 엔드포인트는 항상 클러스터의 프라이머리 노드로 확인되는 DNS 이름입니다. 기본 엔드포인트는 읽기 전용 복제본을 기본 역할로 승격하는 것과 같은 클러스터 변경의 영향을 받지 않습니다. 쓰기 활동의 경우 애플리케이션을 기본 엔드포인트에 연결하는 것이 좋습니다.
리더 엔드포인트는 ElastiCache 클러스터의 모든 읽기 전용 복제본 간에 엔드포인트에 대한 수신 연결을 고르게 분할합니다. 애플리케이션이 연결을 생성하는 시기 또는 애플리케이션에서 연결을 다시 사용하는 방법과 같은 추가 요소가 트래픽 분산을 결정합니다. 리더 엔드포인트는 복제본이 추가 또는 제거되는 클러스터의 변경 사항을 실시간으로 반영합니다. ElastiCache for Redis OSS 클러스터의 여러 읽기 전용 복제본을 다양한 AWS 가용 영역(AZ)에 두어 리더 엔드포인트의 가용성을 높일 수 있습니다.
**참고**
리더 엔드포인트는 로드 밸런서가 아닙니다. 라운드 로빈 방식으로 복제본 노드 중 하나의 IP 주소로 확인되는 DNS 레코드입니다.
읽기 활동의 경우 애플리케이션은 클러스터의 어떤 노드에도 연결할 수 있습니다. 기본 엔드포인트와 달리, 노드 엔드포인트는 특정 엔드포인트로 확인됩니다. 복제본을 추가하거나 삭제하는 것과 같이 클러스터를 변경하면 애플리케이션에서 노드 엔드포인트를 업데이트해야 합니다.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨)**
복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 엔드포인트 구조는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 엔드포인트 구조와 다릅니다. 왜냐하면 이러한 클러스터에는 여러 샤드(API/CLI의 경우 노드 그룹)가 있으며 이는 프라이머리 노드도 여러 개임을 의미하기 때문입니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에는 클러스터의 모든 기본 엔드포인트 및 노드 엔드포인트를 "아는" *구성 엔드포인트*가 있습니다. 애플리케이션은 이 구성 엔드포인트에 연결됩니다. 애플리케이션이 클러스터의 구성 엔드포인트에서 쓰거나 읽을 때마다 백그라운드에서 Valkey 또는 Redis OSS는 키가 속하는 샤드와 해당 샤드에서 사용할 엔드포인트를 확인합니다. 이 모든 것이 애플리케이션에 매우 투명하게 진행됩니다.
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 클러스터의 엔드포인트를 찾을 수 있습니다.
**복제 그룹 엔드포인트 찾기**
복제 그룹의 엔드포인트를 찾으려면 다음 항목 중 하나를 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 엔드포인트 찾기(콘솔)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에 대한 엔드포인트 찾기(콘솔)](Endpoints.md#Endpoints.Find.RedisCluster)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey 또는 Redis OSS 복제 그룹의 엔드포인트 찾기(ElastiCache API)](Endpoints.md#Endpoints.Find.API.ReplGroups)
# 복제 그룹 수정
**중요한 제약**
현재, ElastiCache는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹 수정을 제한적으로 지원하고 있습니다. 예를 들면 API 작업 `ModifyReplicationGroup`(CLI의 경우 `modify-replication-group`)을 사용하여 엔진 버전을 변경할 수 있습니다. API 작업 [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)(CLI의 경우 [https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html))을 통해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드(노드 그룹) 수를 수정할 수 있습니다. 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) 단원을 참조하십시오.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 다른 부분을 수정하려면 변경 사항을 통합하는 새 클러스터를 사용해 클러스터를 새로 만들어야 합니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 및 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 및 복제 그룹을 최신 엔진 버전으로 업그레이드할 수 있습니다. 하지만 기존의 클러스터 또는 복제 그룹을 삭제하고 새로 만들지 않는 한 이전 엔진 버전으로 다운그레이드할 수 없습니다. 자세한 내용은 [ElastiCache용 버전 관리](VersionManagement.md) 단원을 참조하십시오.
아래 예와 같이 콘솔, [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) API 또는 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) CLI 명령을 사용하여 클러스터 모드 비활성화를 사용하는 기존 ElastiCache for Valkey 또는 Redis OSS 클러스터를 클러스터 모드 활성화를 사용하도록 업그레이드할 수 있습니다. 또는 [클러스터 모드 수정](modify-cluster-mode.md)의 단계를 따를 수 있습니다.
ElastiCache 콘솔, 또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 ElastiCache. AWS CLI현재 ElastiCache에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹에 대한 제한된 수의 수정을 지원합니다. 다른 수정의 경우에는 현재 복제 그룹의 백업을 생성한 후 해당 백업을 사용해 새 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 시드해야 합니다.
**Topics**
+ [사용 AWS Management Console](#Replication.Modify.CON)
+ [사용 AWS CLI](#Replication.Modify.CLI)
+ [ElastiCache API 사용](#Replication.Modify.API)
## 사용 AWS Management Console
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 수정하는 방법에 대해서는 [ElastiCache 클러스터 수정](Clusters.Modify.md) 섹션을 참조하세요.
## 사용 AWS CLI
다음은 `modify-replication-group` 명령의 AWS CLI 예입니다. 동일한 명령을 사용하여 복제 그룹을 수정할 수 있습니다.
**기존 Valkey 또는 Redis OSS 복제 그룹에서 다중 AZ 활성화:**
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--multi-az-enabled = true
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--multi-az-enabled
```
**클러스터 모드를 비활성화에서 활성화로 수정:**
클러스터 모드를 *비활성화*에서 *활성화*로 수정하려면 먼저 클러스터 모드를 *호환*으로 설정해야 합니다. 호환 모드를 사용하면 클러스터 모드를 활성화한 상태와 클러스터 모드를 비활성화한 상태 모두에서 Valkey 또는 Redis OSS 클라이언트를 연결할 수 있습니다. 클러스터 모드 활성화를 사용하도록 모든 Valkey 또는 Redis OSS 클라이언트를 마이그레이션한 후 클러스터 모드 구성을 완료하고 클러스터 모드를 *활성화*로 설정할 수 있습니다.
Linux, macOS, Unix의 경우:
클러스터 모드를 *호환*으로 설정합니다.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cache-parameter-group-name myParameterGroupName \
--cluster-mode compatible
```
클러스터 모드를 *활성화*로 설정합니다.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cluster-mode enabled
```
Windows의 경우:
클러스터 모드를 *호환*으로 설정합니다.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cache-parameter-group-name myParameterGroupName ^
--cluster-mode compatible
```
클러스터 모드를 *활성화*로 설정합니다.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cluster-mode enabled
```
명령에 AWS CLI `modify-replication-group` 대한 자세한 내용은 *ElastiCache for Redis OSS 사용 설명서*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 또는 [클러스터 모드 수정]()을 참조하세요.
## ElastiCache API 사용
다음 ElastiCache API 작업은 기존 Valkey 또는 Redis OSS 복제 그룹에서 다중 AZ를 활성화합니다. 동일한 작업을 사용하여 복제 그룹을 수정할 수 있습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&AutomaticFailoverEnabled=true
&Mutli-AZEnabled=true
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
ElastiCache API `ModifyReplicationGroup` 작업에 대한 자세한 내용은 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 섹션을 참조하세요.
# 복제 그룹 삭제
복제본이 있는 클러스터(API/CLI에서는 *복제 그룹*이라고 함)이 더 이상 필요하지 않으면 삭제할 수 있습니다. 복제 그룹을 삭제할 때 ElastiCache는 해당 그룹의 노드를 모두 삭제합니다.
작업을 시작한 후에는 중단하거나 취소할 수 없습니다.
**주의**
ElastiCache for Redis OSS 클러스터를 삭제하는 경우 수동 스냅샷은 유지됩니다. 클러스터를 삭제하기 전에 최종 스냅샷을 생성할 수 있는 옵션도 있습니다. 자동 캐시 스냅샷은 보존되지 않습니다.
최종 스냅샷을 생성하려면 `CreateSnapshot` 권한이 필요합니다. 이 권한이 없으면 API 호출이 실패하고 `Access Denied` 예외가 발생합니다.
## 복제 그룹 삭제(콘솔)
복제본이 있는 클러스터를 삭제하려면 [ElastiCache에서 클러스터 삭제](Clusters.Delete.md)를 참조하세요.
## 복제 그룹 삭제(AWS CLI)
[delete-replication-group](https://docs.aws.amazon.com/AmazonElastiCache/latest/CommandLineReference/CLIReference-cmd-DeleteReplicationGroup.html) 명령을 사용해 복제 그룹을 삭제합니다.
```
aws elasticache delete-replication-group --replication-group-id my-repgroup
```
결정을 확인하라는 메시지가 나타납니다. 즉시 작업을 시작하려면 [*y*](예)를 입력합니다. 프로세스가 시작되면 되돌릴 수 없습니다.
```
After you begin deleting this replication group, all of its nodes will be deleted as well.
Are you sure you want to delete this replication group? [Ny]y
REPLICATIONGROUP my-repgroup My replication group deleting
```
## 복제 그룹 삭제(ElastiCache API)
[DeleteReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteReplicationGroup.html) 파라미터를 사용하여 `ReplicationGroup`을 호출하세요.
**Example**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteReplicationGroup
&ReplicationGroupId=my-repgroup
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
**참고**
`RetainPrimaryCluster` 파라미터를 `true`로 설정하면 모든 읽기 전용 복제본이 삭제되지만 기본 클러스터는 보존됩니다.
# 복제본 수 변경
AWS Management Console, AWS CLI 또는 ElastiCache API를 사용해 Valkey 또는 Redis OSS 복제 그룹의 읽기 전용 복제본 수를 동적으로 늘리거나 줄일 수 있습니다. 복제 그룹이 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹인 경우 복제본 수를 늘리거나 줄일 샤드(노드 그룹)를 선택할 수 있습니다.
복제 그룹의 복제본 수를 동적으로 변경하려면 다음 표에서 상황에 맞는 작업을 선택하세요.
| 수행 방법 | Valkey 또는 Redis OSS(클러스터 모드 활성화됨)의 경우 | Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)의 경우 |
| --- | --- | --- |
| 복제본 추가 | [샤드의 복제본 수 늘리기](increase-replica-count.md) | [샤드의 복제본 수 늘리기](increase-replica-count.md) [Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 추가(클러스터 모드 비활성화됨)](Replication.AddReadReplica.md) |
| 복제본 삭제 | [샤드의 복제본 수 줄이기](decrease-replica-count.md) | [샤드의 복제본 수 줄이기](decrease-replica-count.md) [Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 삭제(클러스터 모드 비활성화됨)](Replication.RemoveReadReplica.md) |
# 샤드의 복제본 수 늘리기
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 샤드 또는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 복제본 수를 최대 5개까지 늘릴 수 있습니다. AWS Management Console, AWS CLI 또는 ElastiCache API를 사용해 늘릴 수 있습니다.
**Topics**
+ [AWS Management Console 사용](#increase-replica-count-con)
+ [AWS CLI 사용](#increase-replica-count-cli)
+ [ElastiCache API 사용](#increase-replica-count-api)
## AWS Management Console 사용
다음 절차는 콘솔을 사용해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹의 복제본 수를 늘립니다.
**샤드의 복제본 수를 늘리는 방법**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택한 후 복제본을 추가할 복제 그룹의 이름을 선택합니다.
1. 복제본을 추가할 각 샤드의 상자를 선택합니다.
1. **복제본 추가**를 선택합니다.
1. **샤드에 복제본 추가** 페이지를 완료합니다.
+ **새 복제본/샤드 수**에 선택한 모든 샤드에 있도록 하려는 복제본 수를 입력합니다. 이 값은 **샤드당 현재 복제본 수**보다 크거나 같아야 하며 5보다 작거나 같아야 합니다. 최소한 두 개의 복제본을 사용하는 것이 좋습니다.
+ **가용 영역**에서 **기본 설정 없음**을 선택하여 ElastiCache가 각각의 새 복제본에 대해 가용 영역을 지정하게 하거나 **가용 영역 지정**을 선택하여 각각의 새 복제본에 대해 가용 영역을 선택합니다.
**가용 영역 지정**를 선택할 경우 목록을 사용해 각각의 새 복제본에 대해 가용 영역을 지정하세요.
1. **추가**를 선택하여 복제본을 추가하거나 **취소**를 선택하여 작업을 취소합니다.
## AWS CLI 사용
Valkey 또는 Redis OSS 샤드의 복제본 수를 늘리려면 다음 파라미터와 함께 `increase-replica-count` 명령을 사용합니다.
+ `--replication-group-id` - 필수입니다. 복제본 수를 늘리려는 복제 그룹을 식별합니다.
+ `--apply-immediately` 또는 `--no-apply-immediately` – 필수입니다. 복제본 수를 즉시 늘릴 것인지(`--apply-immediately`) 아니면 다음 번 유지 관리 기간에 늘릴 것인지(`--no-apply-immediately`) 지정합니다. 현재 `--no-apply-immediately`는 지원되지 않습니다.
+ `--new-replica-count` – 선택 사항입니다. 완료된 경우 원하는 복제본 노드의 수를 최대 5개까지 지정합니다. 노드 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹만 있거나 모든 노드 그룹에 동일한 수의 복제본을 포함하려는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 대해 이 파라미터를 사용합니다. 이 값이 노드 그룹의 현재 복제본 수보다 크지 않은 경우 호출이 실패하고 예외가 발생합니다.
+ `--replica-configuration` – 선택 사항입니다. 각 노드 그룹에 대해 독립적으로 복제본 수와 가용 영역을 설정할 수 있도록 합니다. 각 노드 그룹을 독립적으로 구성하려는 경우 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹에 대해 이 파라미터를 사용하세요.
`--replica-configuration`에는 다음의 선택 멤버 3개가 있습니다.
+ `NodeGroupId` - 구성하는 노드 그룹의 4자리 ID입니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 경우 샤드 ID는 항상 `0001`입니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 노드 그룹(샤드)의 ID를 찾으려면 [샤드 ID 찾기](Shards.md#shard-find-id) 섹션을 참조하세요.
+ `NewReplicaCount` - 이 작업이 끝날 때 이 노드 그룹에 둘 복제본의 수입니다. 값은 현재 복제본 수보다 커야 하며, 최대 5개까지입니다. 이 값이 노드 그룹의 현재 복제본 수보다 크지 않은 경우 호출이 실패하고 예외가 발생합니다.
+ `PreferredAvailabilityZones` - 복제 그룹의 노드가 있을 가용 영역을 지정하는 `PreferredAvailabilityZone` 문자열의 목록입니다. `PreferredAvailabilityZone` 값의 수는 프라이머리 노드를 고려하여 `NewReplicaCount`에 1을 더한 값과 같아야 합니다. 이 `--replica-configuration` 멤버가 생략되면 ElastiCache for Redis는 각각의 새 복제본에 대해 가용 영역을 선택합니다.
**중요**
호출에 `--new-replica-count` 또는 `--replica-configuration` 파라미터를 포함해야 하지만, 둘 다 포함해서는 안 됩니다.
**Example**
다음은 복제 그룹 `sample-repl-group`의 복제본 수를 3으로 늘리는 예입니다. 예제가 완료되면 각 노드 그룹에 복제본 3개가 있습니다. 단일 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 그룹이든 여러 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹이든 관계없이 이 숫자가 적용됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--new-replica-count 3 \
--apply-immediately
```
Windows의 경우:
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 3 ^
--apply-immediately
```
다음은 복제 그룹 `sample-repl-group`의 복제본 수를 지정된 2개의 노드 그룹에 대해 지정된 값으로 늘리는 예입니다. 여러 노드 그룹이 있는 경우 이는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹입니다. 선택적 `PreferredAvailabilityZones`를 지정할 때 나열된 가용 영역 수는 `NewReplicaCount`에 1 이상을 더한 값과 같아야 합니다. 이러한 접근 방식은 `NodeGroupId`에서 식별한 그룹에 대한 프라이머리 노드를 설명합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--replica-configuration \
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c,us-east-1b \
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c,us-east-1c \
--apply-immediately
```
Windows의 경우:
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--replica-configuration ^
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c,us-east-1b ^
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c,us-east-1c \
--apply-immediately
```
CLI를 사용하여 복제본 수를 늘리는 것에 대한 자세한 내용은 *Amazon ElastiCache 명령줄 레퍼런스*의 [increase-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-replica-count.html)를 참조하세요.
## ElastiCache API 사용
Valkey 또는 Redis OSS 샤드의 복제본 수를 늘리려면 다음 파라미터와 함께 `IncreaseReplicaCount` 작업을 사용합니다.
+ `ReplicationGroupId` - 필수입니다. 복제본 수를 늘리려는 복제 그룹을 식별합니다.
+ `ApplyImmediately` - 필수입니다. 복제본 수를 즉시 늘릴 것인지(`ApplyImmediately=True`) 아니면 다음 번 유지 관리 기간에 늘릴 것인지(`ApplyImmediately=False`) 지정합니다. 현재 `ApplyImmediately=False`는 지원되지 않습니다.
+ `NewReplicaCount` – 선택 사항입니다. 완료된 경우 원하는 복제본 노드의 수를 최대 5개까지 지정합니다. 노드 그룹이 하나만 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 대해 또는 모든 노드 그룹에 동일한 수의 복제본이 있도록 하려는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹에 대해 이 파라미터를 사용합니다. 이 값이 노드 그룹의 현재 복제본 수보다 크지 않은 경우 호출이 실패하고 예외가 발생합니다.
+ `ReplicaConfiguration` – 선택 사항입니다. 각 노드 그룹에 대해 독립적으로 복제본 수와 가용 영역을 설정할 수 있도록 합니다. 각 노드 그룹을 독립적으로 구성하려는 경우 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹에 대해 이 파라미터를 사용하세요.
`ReplicaConfiguraion`에는 다음의 선택 멤버 3개가 있습니다.
+ `NodeGroupId` - 구성하는 노드 그룹의 4자리 ID입니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 경우 노드 그룹(샤드) ID는 항상 `0001`입니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 노드 그룹(샤드)의 ID를 찾으려면 [샤드 ID 찾기](Shards.md#shard-find-id) 섹션을 참조하세요.
+ `NewReplicaCount` - 이 작업이 끝날 때 이 노드 그룹에 둘 복제본의 수입니다. 값은 현재 복제본 수보다 커야 하며 최대 5개까지입니다. 이 값이 노드 그룹의 현재 복제본 수보다 크지 않은 경우 호출이 실패하고 예외가 발생합니다.
+ `PreferredAvailabilityZones` - 복제 그룹의 노드가 있을 가용 영역을 지정하는 `PreferredAvailabilityZone` 문자열의 목록입니다. `PreferredAvailabilityZone` 값의 수는 프라이머리 노드를 고려하여 `NewReplicaCount`에 1을 더한 값과 같아야 합니다. 이 `ReplicaConfiguration` 멤버가 생략되면 ElastiCache for Redis는 각각의 새 복제본에 대해 가용 영역을 선택합니다.
**중요**
호출에 `NewReplicaCount` 또는 `ReplicaConfiguration` 파라미터를 포함해야 하지만, 둘 다 포함해서는 안 됩니다.
**Example**
다음은 복제 그룹 `sample-repl-group`의 복제본 수를 3으로 늘리는 예입니다. 예제가 완료되면 각 노드 그룹에 복제본 3개가 있습니다. 단일 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 그룹이든 여러 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹이든 관계없이 이 숫자가 적용됩니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=3
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
다음은 복제 그룹 `sample-repl-group`의 복제본 수를 지정된 2개의 노드 그룹에 대해 지정된 값으로 늘리는 예입니다. 여러 노드 그룹이 있는 경우 이는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹입니다. 선택적 `PreferredAvailabilityZones`를 지정할 때 나열된 가용 영역 수는 `NewReplicaCount`에 1 이상을 더한 값과 같아야 합니다. 이러한 접근 방식은 `NodeGroupId`에서 식별한 그룹에 대한 프라이머리 노드를 설명합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1c
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=3
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-east-1c
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
API를 사용하여 복제본 수를 늘리는 것에 대한 자세한 내용은 *Amazon ElastiCache API 참조*의 [IncreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_IncreaseReplicaCount.html)를 참조하세요.
# 샤드의 복제본 수 줄이기
Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 샤드 또는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 복제 그룹의 복제본 수를 줄일 수 있습니다.
+ Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)의 경우 다중 AZ가 활성화된 경우 1로, 활성화되지 않은 경우 0으로 복제본 수를 줄일 수 있습니다.
+ Valkey 또는 Redis OSS(클러스터 모드 활성화됨)의 경우 복제본 수를 0으로 줄일 수 있습니다. 그러나 프라이머리 노드가 실패할 경우 복제본으로 장애 조치를 수행할 수 없습니다.
AWS Management Console, AWS CLI 또는 ElastiCache API를 사용해 노드 그룹(샤드) 또는 복제 그룹의 복제본 수를 줄일 수 있습니다.
**Topics**
+ [AWS Management Console 사용](#decrease-replica-count-con)
+ [AWS CLI 사용](#decrease-replica-count-cli)
+ [ElastiCache API 사용](#decrease-replica-count-api)
## AWS Management Console 사용
다음 절차는 콘솔을 사용해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹의 복제본 수를 줄입니다.
**Valkey 또는 Redis OSS 샤드의 복제본 수 줄이는 방법**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey** 또는 **Redis OSS**를 선택한 후 복제본을 삭제할 복제 그룹의 이름을 선택합니다.
1. 복제본 노드를 제거할 각 샤드의 상자를 선택합니다.
1. **Delete replicas(복제본 삭제)**를 선택합니다.
1. **Delete Replicas from Shards(샤드에서 복제본 삭제)** 페이지를 완료합니다.
1. **New number of replicas/shard(새 복제본/샤드 수)**에 선택한 샤드에 있도록 하려는 복제본 수를 입력합니다. 이 숫자는 1보다 크거나 같아야 합니다. 샤드마다 최소한 두 개의 복제본을 사용하는 것이 좋습니다.
1. **삭제**를 선택하여 복제본을 삭제하거나 **취소**를 선택하여 작업을 취소합니다.
**중요**
삭제할 복제본 노드를 지정하지 않으면 ElastiCache for Redis OSS에서 삭제할 복제본 노드를 자동으로 선택합니다. 이렇게 하는 동안 ElastiCache for Redis OSS는 복제 그룹의 다중 AZ 아키텍처를 유지하고, 프라이머리 노드를 사용하여 최소 복제 지연 시간으로 복제본을 유지하려고 시도합니다.
복제 그룹의 프라이머리 노드는 삭제할 수 없습니다. 프라이머리 노드를 삭제하도록 지정하면 작업이 실패하고, 프라이머리 노드가 삭제되도록 선택되었음을 나타내는 오류 이벤트가 발생합니다.
## AWS CLI 사용
Valkey 또는 Redis OSS 샤드의 복제본 수를 줄이려면 다음 파라미터와 함께 `decrease-replica-count` 명령을 사용합니다.
+ `--replication-group-id` - 필수입니다. 복제본 수를 줄이려는 복제 그룹을 식별합니다.
+ `--apply-immediately` 또는 `--no-apply-immediately` – 필수입니다. 복제본 수를 즉시 줄일 것인지(`--apply-immediately`) 아니면 다음 번 유지 관리 기간에 줄일 것인지(`--no-apply-immediately`) 지정합니다. 현재 `--no-apply-immediately`는 지원되지 않습니다.
+ `--new-replica-count` – 선택 사항입니다. 원하는 복제본 노드의 수를 지정합니다. `--new-replica-count`의 값은 유효해야 하며, 노드 그룹의 현재 복제본 수보다 작아야 합니다. 허용된 최소값은 [샤드의 복제본 수 줄이기](#decrease-replica-count) 섹션을 참조하세요. `--new-replica-count`의 값이 이 요구 사항을 충족하지 않는 경우 호출이 실패합니다.
+ `--replicas-to-remove` – 선택 사항입니다. 제거할 복제본 노드를 지정하는 노드 ID 목록을 포함합니다.
+ `--replica-configuration` – 선택 사항입니다. 각 노드 그룹에 대해 독립적으로 복제본 수와 가용 영역을 설정할 수 있도록 합니다. 각 노드 그룹을 독립적으로 구성하려는 경우 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹에 대해 이 파라미터를 사용하세요.
`--replica-configuration`에는 다음의 선택 멤버 3개가 있습니다.
+ `NodeGroupId` - 구성하는 노드 그룹의 4자리 ID입니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 경우 샤드 ID는 항상 `0001`입니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 노드 그룹(샤드)의 ID를 찾으려면 [샤드 ID 찾기](Shards.md#shard-find-id) 섹션을 참조하세요.
+ `NewReplicaCount` - 선택적 파라미터로, 원하는 복제본 노드의 수를 지정합니다. `NewReplicaCount`의 값은 유효해야 하며, 노드 그룹의 현재 복제본 수보다 작아야 합니다. 허용된 최소값은 [샤드의 복제본 수 줄이기](#decrease-replica-count) 섹션을 참조하세요. `NewReplicaCount`의 값이 이 요구 사항을 충족하지 않는 경우 호출이 실패합니다.
+ `PreferredAvailabilityZones` - 복제 그룹의 노드가 있는 가용 영역을 지정하는 `PreferredAvailabilityZone` 문자열의 목록입니다. `PreferredAvailabilityZone` 값의 수는 프라이머리 노드를 고려하여 `NewReplicaCount`에 1을 더한 값과 같아야 합니다. 이 `--replica-configuration` 멤버가 생략되면 ElastiCache for Redis는 각각의 새 복제본에 대해 가용 영역을 선택합니다.
**중요**
`--new-replica-count`, `--replicas-to-remove` 또는 `--replica-configuration` 파라미터 중 하나만 포함해야 합니다.
**Example**
다음은 `--new-replica-count`를 사용해 복제 그룹 `sample-repl-group`의 복제본 수를 1로 줄이는 예입니다. 예제가 완료되면 각 노드 그룹에 복제본 1개가 있습니다. 단일 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 그룹이든 여러 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹이든 관계없이 이 숫자가 적용됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache decrease-replica-count
--replication-group-id sample-repl-group \
--new-replica-count 1 \
--apply-immediately
```
Windows의 경우:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 1 ^
--apply-immediately
```
다음은 노드 그룹에서 지정된 복제본 2개(`sample-repl-group` 및 `0001`)를 제거하여 복제 그룹 `0003`의 복제본 수를 줄이는 예입니다.
Linux, macOS, Unix의 경우:
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replicas-to-remove 0001,0003 \
--apply-immediately
```
Windows의 경우:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replicas-to-remove 0001,0003 \
--apply-immediately
```
다음은 `--replica-configuration`을 사용해 복제 그룹 `sample-repl-group`의 복제본 수를 지정된 2개의 노드 그룹에 대해 지정된 값으로 줄이는 예입니다. 여러 노드 그룹이 있는 경우 이는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹입니다. 선택적 `PreferredAvailabilityZones`를 지정할 때 나열된 가용 영역 수는 `NewReplicaCount`에 1 이상을 더한 값과 같아야 합니다. 이러한 접근 방식은 `NodeGroupId`에서 식별한 그룹에 대한 프라이머리 노드를 설명합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replica-configuration \
NodeGroupId=0001,NewReplicaCount=1,PreferredAvailabilityZones=us-east-1a,us-east-1c \
NodeGroupId=0003,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
--apply-immediately
```
Windows의 경우:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replica-configuration ^
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c ^
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
--apply-immediately
```
CLI를 사용하여 복제본 수를 줄이는 것에 대한 자세한 내용은 *Amazon ElastiCache 명령줄 레퍼런스*의 [decrease-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-replica-count.html)를 참조하세요.
## ElastiCache API 사용
Valkey 또는 Redis OSS 샤드의 복제본 수를 줄이려면 다음 파라미터와 함께 `DecreaseReplicaCount` 작업을 사용합니다.
+ `ReplicationGroupId` - 필수입니다. 복제본 수를 줄이려는 복제 그룹을 식별합니다.
+ `ApplyImmediately` - 필수입니다. 복제본 수를 즉시 줄일 것인지(`ApplyImmediately=True`) 아니면 다음 번 유지 관리 기간에 줄일 것인지(`ApplyImmediately=False`) 지정합니다. 현재 `ApplyImmediately=False`는 지원되지 않습니다.
+ `NewReplicaCount` – 선택 사항입니다. 원하는 복제본 노드의 수를 지정합니다. `NewReplicaCount`의 값은 유효해야 하며, 노드 그룹의 현재 복제본 수보다 작아야 합니다. 허용된 최소값은 [샤드의 복제본 수 줄이기](#decrease-replica-count) 섹션을 참조하세요. `--new-replica-count`의 값이 이 요구 사항을 충족하지 않는 경우 호출이 실패합니다.
+ `ReplicasToRemove` – 선택 사항입니다. 제거할 복제본 노드를 지정하는 노드 ID 목록을 포함합니다.
+ `ReplicaConfiguration` – 선택 사항입니다. 각 노드 그룹에 대해 독립적으로 복제본 수와 가용 영역을 설정할 수 있도록 허용하는 노드 그룹의 목록을 포함합니다. 각 노드 그룹을 독립적으로 구성하려는 경우 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹에 대해 이 파라미터를 사용하세요.
`ReplicaConfiguraion`에는 다음의 선택 멤버 3개가 있습니다.
+ `NodeGroupId` - 구성하는 노드 그룹의 4자리 ID입니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 경우 노드 그룹 ID는 항상 `0001`입니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 노드 그룹(샤드)의 ID를 찾으려면 [샤드 ID 찾기](Shards.md#shard-find-id) 섹션을 참조하세요.
+ `NewReplicaCount` - 이 작업이 끝날 때 이 노드 그룹에 둘 복제본의 수입니다. 값은 현재 복제본 수보다 작아야 하며, 다중 AZ가 활성화된 경우 최소 1 또는 자동 장애 조치가 있는 다중 AZ가 활성화되지 않은 경우 0까지 줄입니다. 이 값이 노드 그룹의 현재 복제본 수보다 작지 않은 경우 호출이 실패하고 예외가 발생합니다.
+ `PreferredAvailabilityZones` - 복제 그룹의 노드가 있는 가용 영역을 지정하는 `PreferredAvailabilityZone` 문자열의 목록입니다. `PreferredAvailabilityZone` 값의 수는 프라이머리 노드를 고려하여 `NewReplicaCount`에 1을 더한 값과 같아야 합니다. 이 `ReplicaConfiguration` 멤버가 생략되면 ElastiCache for Redis는 각각의 새 복제본에 대해 가용 영역을 선택합니다.
**중요**
`NewReplicaCount`, `ReplicasToRemove` 또는 `ReplicaConfiguration` 파라미터 중 하나만 포함해야 합니다.
**Example**
다음은 `NewReplicaCount`를 사용해 복제 그룹 `sample-repl-group`의 복제본 수를 1로 줄이는 예입니다. 예제가 완료되면 각 노드 그룹에 복제본 1개가 있습니다. 단일 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 그룹이든 여러 노드 그룹의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 그룹이든 관계없이 이 숫자가 적용됩니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=1
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
다음은 노드 그룹에서 지정된 복제본 2개(`sample-repl-group` 및 `0001`)를 제거하여 복제 그룹 `0003`의 복제본 수를 줄이는 예입니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicasToRemove.ReplicaToRemove.1=0001
&ReplicasToRemove.ReplicaToRemove.2=0003
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
다음은 `ReplicaConfiguration`을 사용해 복제 그룹 `sample-repl-group`의 복제본 수를 지정된 2개의 노드 그룹에 대해 지정된 값으로 줄이는 예입니다. 여러 노드 그룹이 있는 경우 이는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹입니다. 선택적 `PreferredAvailabilityZones`를 지정할 때 나열된 가용 영역 수는 `NewReplicaCount`에 1 이상을 더한 값과 같아야 합니다. 이러한 접근 방식은 `NodeGroupId`에서 식별한 그룹에 대한 프라이머리 노드를 설명합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=1
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1c
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
API를 사용하여 복제본 수를 줄이는 것에 대한 자세한 내용은 *Amazon ElastiCache API 참조*의 [DecreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DecreaseReplicaCount.html)를 참조하세요.
# Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 추가(클러스터 모드 비활성화됨)
다음 주제의 정보는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에만 적용됩니다.
읽기 트래픽이 증가함에 따라 이러한 읽기를 더 많은 노드로 분산시켜 어느 한 노드에 대한 읽기 압력을 줄이려고 할 수 있습니다. 이 주제에서는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에 읽기 전용 복제본을 추가하는 방법을 확인할 수 있습니다.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹은 최대 5개의 읽기 전용 복제본을 가질 수 있습니다. 읽기 전용 복제본 5개가 이미 있는 복제 그룹에 읽기 전용 복제본을 추가하려고 하면 작업이 실패합니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹에 복제본을 추가하는 방법에 대한 자세한 내용은 다음을 참조하세요.
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md)
+ [샤드의 복제본 수 늘리기](increase-replica-count.md)
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 읽기 전용 복제본을 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에 추가할 수 있습니다.
**관련 주제**
+ [ElastiCache 클러스터에 노드 추가](Clusters.AddNode.md)
+ [복제 그룹에 읽기 전용 복제본 추가(AWS CLI)](#Replication.AddReadReplica.CLI)
+ [API를 사용해 복제 그룹에 읽기 전용 복제본 추가](#Replication.AddReadReplica.API)
## 복제 그룹에 읽기 전용 복제본 추가(AWS CLI)
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 읽기 전용 복제본을 추가하려면 `--replication-group-id` 파라미터와 함께 AWS CLI `create-cache-cluster` 명령을 사용해 클러스터(노드)를 추가할 복제 그룹을 지정합니다.
다음 예제에서는 `my-read replica`클러스터를 생성하고 해당 클러스터를 `my-replication-group` 복제 그룹에 추가합니다. 읽기 전용 복제본의 노드 유형, 파라미터 그룹, 보안 그룹, 유지 관리 기간 및 기타 설정이 `my-replication-group`의 다른 노드와 동일해집니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-read-replica \
--replication-group-id my-replication-group
```
Windows의 경우:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-read-replica ^
--replication-group-id my-replication-group
```
CLI를 사용해 읽기 전용 복제본을 추가하는 것에 대한 자세한 내용은 *Amazon ElastiCache 명령줄 레퍼런스*의 [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html) 섹션을 참조하세요.
## API를 사용해 복제 그룹에 읽기 전용 복제본 추가
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 읽기 전용 복제본을 추가하려면 `ReplicationGroupId` 파라미터와 함께 ElastiCache `CreateCacheCluster` 작업을 사용해 클러스터(노드)를 추가할 복제 그룹을 지정합니다.
다음 예제에서는 `myReadReplica`클러스터를 생성하고 해당 클러스터를 `myReplicationGroup` 복제 그룹에 추가합니다. 읽기 전용 복제본의 노드 유형, 파라미터 그룹, 보안 그룹, 유지 관리 기간 및 기타 설정이 `myReplicationGroup`의 다른 노드와 동일해집니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReadReplica
&ReplicationGroupId=myReplicationGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
API를 사용해 읽기 전용 복제본을 추가하는 것에 대한 자세한 내용은 *Amazon ElastiCache API 참조*의 [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html) 섹션을 참조하세요.
# Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 삭제(클러스터 모드 비활성화됨)
다음 주제의 정보는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에만 적용됩니다.
Valkey 또는 Redis OSS 복제 그룹에서 읽기 트래픽이 변경되면 읽기 전용 복제본을 추가하거나 제거하려고 할 수 있습니다. 복제 그룹에서 노드를 제거하는 것은 클러스터를 삭제하는 것과 동일하지만 다음과 같은 제한이 있습니다.
+ 복제 그룹에서 기본을 제거할 수 없습니다. 기본을 삭제하려면 다음을 수행하세요.
1. 읽기 전용 복제본을 기본으로 승격합니다. 기본으로 읽기 전용 복제본 승격에 대한 자세한 내용은 [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 대해 읽기 전용 복제본을 기본으로 승격](Replication.PromoteReplica.md)을 참조하세요.
1. 이전 기본을 삭제합니다. 이 메서드에 대한 제한 사항은 다음 요점을 참조하세요.
+ 복제 그룹에서 다중 AZ가 활성화된 경우 이 복제 그룹에서 마지막 읽기 전용 복제본을 제거할 수 없습니다. 이 경우 다음과 같이 합니다.
1. 복제 그룹을 수정하여 다중 AZ를 비활성화합니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하세요.
1. 읽기 전용 복제본을 삭제합니다.
ElastiCache 콘솔, ElastiCache용 AWS CLI 또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에서 읽기 전용 복제본을 제거할 수 있습니다.
Valkey 또는 Redis OSS 복제 그룹의 클러스터 삭제에 대한 지침은 다음을 참조하세요.
+ [사용AWS Management Console](Clusters.Delete.md#Clusters.Delete.CON)
+ [AWS CLI를 사용하여 ElastiCache 클러스터 삭제](Clusters.Delete.md#Clusters.Delete.CLI)
+ [ElastiCache API 사용](Clusters.Delete.md#Clusters.Delete.API)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md)
+ [샤드의 복제본 수 줄이기](decrease-replica-count.md)
# Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에 대해 읽기 전용 복제본을 기본으로 승격
다음 주제의 정보는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹에만 적용됩니다.
AWS Management Console, AWS CLI 또는 ElastiCache API를 사용해 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 읽기 전용 복제본을 기본으로 승격할 수 있습니다. 자동 장애 조치가 포함된 다중 AZ가 복제 그룹에서 활성화되어 있는 동안에는 읽기 전용 복제본을 기본으로 승격할 수 없습니다. 다중 AZ가 활성화된 복제 그룹에서 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제본을 기본으로 승격하려면 다음을 수행하세요.
1. 다중 AZ를 비활성하도록 복제 그룹을 수정합니다(수정할 때 모든 클러스터가 동일 가용 영역에 있을 필요는 없음). 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하세요.
1. 읽기 전용 복제본을 기본으로 승격합니다.
1. 다중 AZ를 다시 활성화하도록 복제 그룹을 수정합니다.
Redis OSS 2.6.13 이전 버전을 실행하는 복제 그룹에서는 다중 AZ를 사용할 수 없습니다.
## AWS Management Console 사용
다음 절차에서는 콘솔을 사용해 복제본 노드를 기본 노드로 승격합니다.
**읽기 전용 복제본을 기본으로 승격하려면(콘솔)**
1. AWS Management Console에 로그인하고[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 승격하려는 복제본이 다중 AZ가 활성화된 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 멤버이면 계속 진행하기 전에 복제 그룹을 수정하여 다중 AZ를 비활성화해야 합니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하세요.
1. **Valkey** 또는 **Redis OSS**를 선택한 후 클러스터 목록에서 수정할 복제 그룹을 선택합니다. 이 복제 그룹은 "Clustered Redis" 엔진이 아닌 "Redis" 엔진에서 실행되어야 하며, 2개 이상의 노드가 있어야 합니다.
1. 노드 목록에서 기본으로 승격할 복제본 노드를 선택한 후 **작업**에서 **Promote(승격)**를 선택합니다.
1. **Promote Read Replica(읽기 전용 복제본 승격)** 대화 상자에서 다음을 수행합니다.
1. **Apply Immediately(즉시 적용)**에서 **예**를 선택하여 읽기 전용 복제본을 즉시 승격하거나 **아니요**를 선택하여 클러스터의 다음 번 유지 관리 기간에 승격합니다.
1. [**Promote**]를 선택하여 읽기 전용 복제본을 승격하거나 [**Cancel**]을 선택하여 작업을 취소합니다.
1. 승격 프로세스를 시작하기 전에 클러스터에 다중 AZ가 활성화된 경우 복제 그룹의 상태가 **사용 가능**으로 될 때까지 기다린 후 클러스터를 수정하여 다중 AZ를 재활성화합니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 섹션을 참조하세요.
## AWS CLI 사용
복제 그룹에 다중 AZ가 활성화되어 있으면 읽기 전용 복제본을 기본으로 승격할 수 없습니다. 일부 경우에 승격하려는 복제본은 다중 AZ가 활성화되어 있는 복제 그룹의 일원일 수 있습니다. 이러한 경우 계속하기 전에 다중 AZ를 비활성화하도록 복제 그룹을 수정해야 합니다. 수정할 때 모든 클러스터가 동일 가용 영역에 있을 필요는 없습니다. 복제 그룹 수정에 대한 자세한 내용은 [복제 그룹 수정](Replication.Modify.md)을 참조하세요.
다음 AWS CLI 명령은 복제 그룹 `sample-repl-group`을 수정하여 읽기 전용 복제본 `my-replica-1`을 복제 그룹의 기본으로 만듭니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id sample-repl-group \
--primary-cluster-id my-replica-1
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id sample-repl-group ^
--primary-cluster-id my-replica-1
```
복제 그룹 수정에 대한 자세한 내용은 *Amazon ElastiCache 명령줄 레퍼런스*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 섹션을 참조하세요.
## ElastiCache API 사용
복제 그룹에 다중 AZ가 활성화되어 있으면 읽기 전용 복제본을 기본으로 승격할 수 없습니다. 일부 경우에 승격하려는 복제본은 다중 AZ가 활성화되어 있는 복제 그룹의 일원일 수 있습니다. 이러한 경우 계속하기 전에 다중 AZ를 비활성화하도록 복제 그룹을 수정해야 합니다. 수정할 때 모든 클러스터가 동일 가용 영역에 있을 필요는 없습니다. 복제 그룹 수정에 대한 자세한 내용은 [복제 그룹 수정](Replication.Modify.md)을 참조하세요.
다음 ElastiCache API 업은 읽기 전용 복제본 `myReplica-1`을 복제 그룹의 기본으로 만드는 복제 그룹 `myReplGroup`을 수정합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ReplicationGroupId=myReplGroup
&PrimaryClusterId=myReplica-1
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
복제 그룹 수정에 대한 자세한 내용은 *Amazon ElastiCache API 참조*의 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 섹션을 참조하세요.
# ElastiCache 클러스터 유지 관리
모든 클러스터에는 시스템 변경 내용이 적용되는 주 단위 유지 관리 기간이 있습니다. Valkey 및 Redis OSS를 사용하면 복제 그룹에 동일한 주간 유지 관리 기간이 적용됩니다. 클러스터나 복제 그룹을 생성 또는 수정할 때 원하는 유지 관리 기간을 지정하지 않으면 ElastiCache가 임의로 선택한 요일에 리전의 유지 관리 기간 내에서 60분의 유지 관리 기간을 지정합니다.
리전별로 8시간 블록 시간 중에서 60분 유지 관리 시간이 임의로 선택됩니다. 다음 표는 기본 유지 관리 기간이 할당된 각 리전별 시간 블록 목록입니다. 리전의 유지 관리 기간 블록 외부에서 원하는 유지 관리 기간을 선택할 수 있습니다.
| 리전 코드 | 리전 이름 | 리전 유지 관리 기간 |
| --- | --- | --- |
| ap-northeast-1 | Asia Pacific (Tokyo) Region | 13:00\$121:00 UTC |
| ap-northeast-2 | Asia Pacific (Seoul) Region | 12:00\$120:00 UTC |
| ap-northeast-3 | Asia Pacific (Osaka) Region | 12:00\$120:00 UTC |
| ap-southeast-3 | Asia Pacific (Jakarta) Region | 14:00\$122:00 UTC |
| ap-south-1 | Asia Pacific (Mumbai) Region | 17:30\$11:30 UTC |
| ap-southeast-1 | Asia Pacific (Singapore) Region | 14:00\$122:00 UTC |
| cn-north-1 | 중국(베이징) 리전 | 14:00\$122:00 UTC |
| cn-northwest-1 | 중국(닝샤) 리전 | 14:00\$122:00 UTC |
| ap-east-1 | Asia Pacific (Hong Kong) Region | 13:00\$121:00 UTC |
| ap-southeast-2 | 아시아 태평양(시드니) 리전 | 12:00\$120:00 UTC |
| eu-west-3 | EU(파리) 리전 | 23:59\$107:29 UTC |
| af-south-1 | 아프리카(케이프타운) 리전 | 13:00\$121:00 UTC |
| eu-central-1 | Europe (Frankfurt) Region | 23:00\$107:00 UTC |
| eu-west-1 | Europe (Ireland) Region | 22:00\$106:00 UTC |
| eu-west-2 | Europe (London) Region | 23:00\$107:00 UTC |
| me-south-1 | Middle East (Bahrain) Region | 13:00\$121:00 UTC |
| me-central-1 | 중동(UAE) 리전 | 13:00\$121:00 UTC |
| eu-south-1 | Europe (Milan) Region | 21:00–05:00 UTC |
| sa-east-1 | 남아메리카(상파울루) 리전 | 01:00\$109:00 UTC |
| us-east-1 | 미국 동부(버지니아 북부) 리전 | 03:00\$111:00 UTC |
| us-east-2 | US East (Ohio) Region | 04:00\$112:00 UTC |
| us-gov-west-1 | AWS GovCloud (US) region | 06:00\$114:00 UTC |
| us-west-1 | US West (N. California) Region | 06:00\$114:00 UTC |
| us-west-2 | US West (Oregon) Region | 06:00\$114:00 UTC |
**클러스터 또는 복제 그룹의 유지 관리 기간 변경**
유지 관리 기간은 사용률이 가장 낮은 시간에 할당되어야 하므로 수시로 수정되어야 할 수 있습니다. 클러스터나 복제 그룹을 수정하여 요청한 유지 관리 활동이 이루어지는 기간을 최대 24시간까지 지정할 수 있습니다. 이 시간 동안 사용자가 요청한 지연된 또는 대기 중인 클러스터 수정이 발생합니다.
**참고**
AWS Management Console을 사용하여 노드 유형 수정 및/또는 엔진 업그레이드를 즉시 적용하려면 **지금 적용** 상자를 선택합니다. 그러지 않으면 이러한 수정 사항은 다음 예약된 유지 관리 기간에 적용됩니다. API를 사용하려면 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 또는 [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html)를 참조하세요.
**추가 정보**
유지 관리 기간 및 노드 대체에 대한 자세한 내용은 다음을 참조하세요.
+ [ElastiCache 유지 관리](https://aws.amazon.com/elasticache/elasticache-maintenance/) - 유지 관리 및 노드 교체에 대한 FAQ
+ [노드 대체(Memcached)](CacheNodes.NodeReplacement-mc.md) - Memcached에 대한 노드 교체 관리
+ [ElastiCache 클러스터 수정](Clusters.Modify.md) - 클러스터의 유지 관리 기간 변경
+ [노드 대체(Valkey 및 Redis OSS)](CacheNodes.NodeReplacement.md) - 노드 교체 관리
+ [복제 그룹 수정](Replication.Modify.md) - 복제 그룹의 유지 관리 기간 변경
# ElastiCache 파라미터 그룹을 사용해 엔진 파라미터 구성
Amazon ElastiCache는 파라미터를 사용하여 노드 및 클러스터의 런타임 속성을 제어합니다. 일반적으로 최신 엔진 버전에는 새로운 기능을 기원하는 추가 파라미터가 포함됩니다. Memcached 파라미터 표는 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached) 섹션을 참조하세요. Valkey 및 Redis OSS 파라미터 표는 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
`maxmemory`와 같은 일부 파라미터 값은 엔진 및 노드 유형에 의해 결정됩니다. 노드 유형별 Memcached 파라미터 값의 표는 [Memcached 노드 유형별 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached.NodeSpecific) 섹션을 참조하세요. 노드 유형별 Valkey 및 Redis OSS 파라미터 값의 표는 [Redis OSS 노드 유형별 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) 섹션을 참조하세요.
**참고**
Memcached 특정 파라미터 목록은 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached)를 참조하세요.
**Topics**
+ [ElastiCache의 파라미터 관리](ParameterGroups.Management.md)
+ [ElastiCache의 캐시 파라미터 그룹 티어](ParameterGroups.Tiers.md)
+ [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md)
+ [이름으로 ElastiCache 파라미터 그룹 나열](ParameterGroups.ListingGroups.md)
+ [ElastiCache 파라미터 그룹 값 나열](ParameterGroups.ListingValues.md)
+ [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md)
+ [ElastiCache 파라미터 그룹 삭제](ParameterGroups.Deleting.md)
+ [엔진별 파라미터](ParameterGroups.Engine.md)
# ElastiCache의 파라미터 관리
더욱 쉬운 파라미터 관리를 위해 ElastiCache 파라미터를 명명된 파라미터 그룹으로 그룹화합니다. 파라미터 그룹은 시작하는 동안 엔진 소프트웨어에 전달되는 파라미터의 특정 값 조합을 나타냅니다. 이 값은 각 노드의 엔진 프로세서가 런타임에 작동하는 방식을 결정합니다. 특정 파라미터 그룹의 파라미터 값은 해당 파라미터가 속한 클러스터와 상관없이 그룹과 연결된 모든 노드에 적용됩니다.
클러스터 성능을 미세 조정하려면 일부 파라미터 값을 수정하거나 클러스터의 파라미터 그룹을 변경할 수 있습니다.
+ 기본 파라미터 그룹을 수정하거나 삭제할 수 없습니다. 사용자 지정 파라미터 값이 필요하면 사용자 지정 파라미터 그룹을 생성해야 합니다.
+ Memcached의 경우, 파라미터 그룹 패밀리와 할당할 클러스터는 호환 가능해야 합니다. 예를 들어 클러스터에서 Memcached 버전 1.4.8을 실행 중이라면 Memcached 1.4 패밀리의 기본 또는 사용자 지정 파라미터 그룹만 사용할 수 있습니다.
Redis OSS의 경우, 파라미터 그룹 패밀리와 할당할 클러스터는 호환 가능해야 합니다. 예를 들어 클러스터에서 Redis OSS 버전 3.2.10을 실행 중이라면 Redis OSS 3.2 패밀리의 기본 또는 사용자 지정 파라미터 그룹만 사용할 수 있습니다.
+ 클러스터의 파라미터 그룹을 변경하면 조건부로 수정 가능한 파라미터의 값이 현재 및 새 파라미터 그룹에서 동일해야 합니다.
+ Memcached의 경우, 클러스터의 파라미터를 변경하면 변경 사항이 클러스터에 즉시 적용됩니다. 이는 클러스터의 파라미터 그룹 자체에서 변경하든 파라미터 값을 클러스터의 파라미터 그룹 내에서 변경하든 마찬가지입니다. 특정 파라미터 변경 사항이 적용되는 시점을 확인하려면 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached)에 대한 테이블의 **변경 적용** 열을 참조하세요. 클러스터의 노드 재부팅에 관한 자세한 정보는 [클러스터 재부팅](Clusters.html#Rebooting)을 참조하세요.
+ Redis OSS의 경우, 클러스터의 파라미터를 변경하면 변경 사항은 다음에 나와 있는 예외를 제외하고, 클러스터 노드가 재부팅된 즉시 또는 그 이후에 클러스터에 적용됩니다. 이는 클러스터의 파라미터 그룹 자체에서 변경하든 파라미터 값을 클러스터의 파라미터 그룹 내에서 변경하든 마찬가지입니다. 특정 파라미터 변경 사항이 적용되는 시점을 확인하려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis)에 대한 테이블의 **변경 적용** 열을 참조하세요.
Valkey 또는 Redis OSS 노드 재부팅에 대한 자세한 내용은 [노드 재부팅](nodes.rebooting.md) 섹션을 참조하세요.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 파라미터 변경**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 다음 파라미터를 변경하는 경우 다음 확인 단계를 따르십시오.
activerehashing
데이터베이스
클러스터의 수동 백업을 만듭니다. [수동 백업 지원](backups-manual.md) 섹션을 참조하세요.
클러스터를 삭제합니다. [클러스터 삭제](Clusters.html#Delete)를 참조하세요.
변경한 파라미터 그룹 및 백업을 사용해 클러스터를 저장하여 새로운 클러스터를 시드합니다. [백업에서 새 캐시로 복원](backups-restoring.md) 섹션을 참조하세요.
다른 파라미터를 변경한 경우에는 필요하지 않습니다.
+ 파라미터 그룹을 Valkey 및 Redis OSS 글로벌 데이터 저장소와 연결할 수 있습니다. *글로벌 데이터 스토어*는 AWS 리전에 걸쳐 있는 하나 이상의 클러스터 모음입니다. 이 경우 파라미터 그룹은 글로벌 데이터 스토어를 구성하는 모든 클러스터에서 공유됩니다. 기본 클러스터의 파라미터 그룹에 대한 모든 수정 사항은 글로벌 데이터 스토어의 나머지 모든 클러스터에 복제됩니다. 자세한 내용은 [글로벌 데이터 스토어를 사용하여AWS리전 간 복제](Redis-Global-Datastore.md) 섹션을 참조하세요.
다음 위치를 보면 파라미터 그룹이 글로벌 데이터 스토어의 일부인지 확인할 수 있습니다.
+ ElastiCache 콘솔의 **파라미터 그룹** 페이지에 있는 yes/no **글로벌** 특성
+ [CacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CacheParameterGroup.html) API 작업의 yes/no `IsGlobal` 속성
# ElastiCache의 캐시 파라미터 그룹 티어
Amazon ElastiCache에는 다음과 같이 세 가지 캐시 파라미터 그룹 티어가 있습니다.
![\[이미지: Amazon ElastiCache 파라미터 그룹 티어\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-ParameterGroups-Tiers.png)
*Amazon ElastiCache 파라미터 그룹 티어*
**전역 기본값**
해당 리전의 모든 Amazon ElastiCache 고객을 위한 최상위 루트 파라미터 그룹입니다.
전역 기본 캐시 파라미터 그룹:
+ ElastiCache용으로 예약되어 있으며 고객이 사용할 수 없습니다.
**고객 기본값**
고객의 사용을 위해 생성된 전역 기본 캐시 파라미터 그룹의 사본입니다.
고객 기본 캐시 파라미터 그룹:
+ ElastiCache가 생성하고 소유합니다.
+ 고객이 이 캐시 파라미터 그룹에서 지원하는 엔진 버전을 실행 중인 모든 클러스터의 캐시 파라미터 그룹으로 사용할 수 있습니다.
+ 고객이 편집할 수 없습니다.
**고객 소유**
고객 기본 캐시 파라미터 그룹의 사본입니다. 고객 소유 캐시 파라미터 그룹은 고객이 캐시 파라미터 그룹을 생성할 때마다 만들어집니다.
고객 소유 캐시 파라미터 그룹:
+ 고객이 생성하고 소유합니다.
+ 고객의 호환 가능한 모든 클러스터에 할당할 수 있습니다.
+ 고객이 사용자 지정 캐시 파라미터 그룹을 생성하기 위해 수정할 수 있습니다.
모든 파라미터 값을 수정할 수 있는 것은 아닙니다. Memcached 값에 대한 자세한 내용은 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached) 섹션을 참조하십시오. Valkey 및 Redis OSS 값에 대한 자세한 내용은 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
# ElastiCache 파라미터 그룹 생성
기본값에서 변경하려는 파라미터 값이 하나 이상이면 새 파라미터 그룹을 생성해야 합니다. ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 파라미터 그룹을 생성할 수 있습니다.
## ElastiCache 파라미터 그룹 생성(콘솔)
다음 절차는 ElastiCache 콘솔을 사용하여 파라미터 그룹을 생성하는 방법을 보여줍니다.
**ElastiCache 콘솔을 사용하여 파라미터 그룹을 생성하려면**
1. AWS Management Console에 로그인하고[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 사용 가능한 모든 파라미터 목록을 표시하려면 왼쪽 탐색 창에서 [**Parameter Groups**]를 선택합니다.
1. 파라미터 그룹을 생성하려면 [**Create Parameter Group**]을 선택합니다.
**파라미터 그룹 생성** 화면이 나타납니다.
1. [**Family**] 목록에서 파라미터 그룹의 템플릿이 될 파라미터 그룹 패밀리를 선택합니다.
*memcached1.4* 또는 *redis3.2* 같은 파라미터 그룹 패밀리는 파라미터 그룹의 실제 파라미터와 초기 값을 정의합니다. 파라미터 그룹 패밀리는 클러스터의 엔진 및 버전과 일치해야 합니다.
1. [**Name**] 상자에 파라미터 그룹의 고유 이름을 입력합니다.
클러스터를 생성하거나 클러스터의 파라미터 그룹을 수정할 때 그 이름으로 파라미터 그룹을 선택합니다. 그러므로 이름은 파라미터 그룹의 패밀리를 식별할 수 있고 정보를 알 수 있는 것이 좋습니다.
파라미터 그룹 명명 제약 조건은 다음과 같습니다.
+ ASCII 문자로 시작해야 합니다.
+ ASCII 문자, 숫자 및 하이픈만 포함할 수 있습니다.
+ 1-255자여야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
1. [**Description**] 상자에 파라미터 그룹에 대한 설명을 입력합니다.
1. 파라미터 그룹을 생성하려면 [**Create**]를 선택합니다.
파라미터 그룹을 생성하지 않고 프로세스를 종료하려면 [**Cancel**]을 선택합니다.
1. 파라미터 그룹을 생성하면 패밀리의 기본값이 부여됩니다. 기본값을 변경하려면 파라미터 그룹을 수정해야 합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
## ElastiCache 파라미터 그룹 생성(AWS CLI)
AWS CLI를 사용하여 파라미터 그룹을 생성하려면 이 파라미터와 함께 `create-cache-parameter-group` 명령을 사용합니다.
+ `--cache-parameter-group-name` - 파라미터 그룹의 이름입니다.
파라미터 그룹 명명 제약 조건은 다음과 같습니다.
+ ASCII 문자로 시작해야 합니다.
+ ASCII 문자, 숫자 및 하이픈만 포함할 수 있습니다.
+ 1-255자여야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
+ `--cache-parameter-group-family` - 파라미터 그룹의 엔진 및 버전 패밀리입니다.
+ `--description` - 사용자가 정의한 파라미터 그룹에 대한 설명입니다.
**Example**
다음 예제에서는 memcached1.4를 템플릿으로 사용하여 *myMem14*라는 파라미터 그룹을 생성합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--cache-parameter-group-family memcached1.4 \
--description "My first parameter group"
```
Windows의 경우:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--cache-parameter-group-family memcached1.4 ^
--description "My first parameter group"
```
이 명령의 출력은 다음과 유사해야 합니다.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
}
```
**Example**
다음 예제에서는 redis2.8 패밀리를 템플릿으로 사용하여 *myRed28*이라는 파라미터 그룹을 생성합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myRed28 \
--cache-parameter-group-family redis2.8 \
--description "My first parameter group"
```
Windows의 경우:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myRed28 ^
--cache-parameter-group-family redis2.8 ^
--description "My first parameter group"
```
이 명령의 출력은 다음과 유사해야 합니다.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
}
```
파라미터 그룹을 생성하면 패밀리의 기본값이 부여됩니다. 기본값을 변경하려면 파라미터 그룹을 수정해야 합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
[자세한 내용은 `create-cache-parameter-group` 단원을 참조하세요.](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-parameter-group.html)
## ElastiCache 파라미터 그룹 생성(ElastiCache API)
ElastiCache API를 사용하여 파라미터 그룹을 생성하려면 이 파라미터와 함께 `CreateCacheParameterGroup` 작업을 사용합니다.
+ `ParameterGroupName` - 파라미터 그룹의 이름입니다.
파라미터 그룹 명명 제약 조건은 다음과 같습니다.
+ ASCII 문자로 시작해야 합니다.
+ ASCII 문자, 숫자 및 하이픈만 포함할 수 있습니다.
+ 1-255자여야 합니다.
+ 하이픈 2개가 연속될 수 없습니다.
+ 끝에 하이픈이 올 수 없습니다.
+ `CacheParameterGroupFamily` - 파라미터 그룹의 엔진 및 버전 패밀리입니다. 예를 들어 `memcached1.4`입니다.
+ `CacheParameterGroupFamily` - 파라미터 그룹의 엔진 및 버전 패밀리입니다. 예를 들어 `redis2.8`입니다.
+ `Description` - 사용자가 정의한 파라미터 그룹에 대한 설명입니다.
**Example**
다음 예제에서는 memcached1.4를 템플릿으로 사용하여 *myMem14*라는 파라미터 그룹을 생성합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=memcached1.4
&CacheParameterGroupName=myMem14
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 다음과 유사해야 합니다.
```
myMem14memcached1.4My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
**Example**
다음 예제에서는 redis2.8 패밀리를 템플릿으로 사용하여 *myRed28*이라는 파라미터 그룹을 생성합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=redis2.8
&CacheParameterGroupName=myRed28
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 다음과 유사해야 합니다.
```
myRed28redis2.8My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
파라미터 그룹을 생성하면 패밀리의 기본값이 부여됩니다. 기본값을 변경하려면 파라미터 그룹을 수정해야 합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 섹션을 참조하세요.
[자세한 내용은 `CreateCacheParameterGroup` 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html)
# 이름으로 ElastiCache 파라미터 그룹 나열
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 파라미터 그룹을 나열할 수 있습니다.
## 이름별로 파라미터 그룹 목록 조회(콘솔)
다음 절차에서는 ElastiCache 콘솔을 사용하여 파라미터 그룹 목록을 보는 방법을 설명합니다.
**ElastiCache 콘솔을 사용하여 파라미터 그룹을 나열하려면**
1. AWS Management Console에 로그인하고[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 사용 가능한 모든 파라미터 목록을 표시하려면 왼쪽 탐색 창에서 [**Parameter Groups**]를 선택합니다.
## 이름으로 ElastiCache 파라미터 그룹 나열(AWS CLI)
AWS CLI를 사용하여 파라미터 그룹의 목록을 생성하려면 `describe-cache-parameter-groups` 명령을 사용합니다. 파라미터 그룹의 이름을 입력하면 그 파라미터 그룹만 나열됩니다. 파라미터 그룹의 이름을 입력하지 않으면 최대 `--max-records`개의 파라미터 그룹이 나열됩니다. 두 경우 모두 파라미터 그룹의 이름, 패밀리 및 설명이 나열됩니다.
**Example**
다음 샘플 코드에는 *myMem14* 파라미터 그룹이 나열되어 있습니다.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myMem14
```
Windows의 경우:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myMem14
```
이 명령의 출력은 파라미터 그룹의 이름, 패밀리 및 설명을 나열하는 것과 같습니다.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
]
}
```
**Example**
다음 샘플 코드에는 *myRed28* 파라미터 그룹이 나열되어 있습니다.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed28
```
Windows의 경우:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed28
```
이 명령의 출력은 파라미터 그룹의 이름, 패밀리 및 설명을 나열하는 것과 같습니다.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
]
}
```
**Example**
다음 샘플 코드에는 Redis OSS 엔진 버전 5.0.6 이상에서 실행되는 파라미터 그룹에 대한 파라미터 그룹 *myRed56*이 나열됩니다. 파라미터 그룹이 [글로벌 데이터 스토어를 사용하여AWS리전 간 복제](Redis-Global-Datastore.md)의 일부인 경우 출력에서 반환되는 `IsGlobal` 속성 값은 `Yes`가 됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed56
```
Windows의 경우:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed56
```
이 명령의 출력은 파라미터 그룹의 이름, 패밀리, isGlobal 및 설명을 나열하는 것과 같습니다.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed56",
"CacheParameterGroupFamily": "redis5.0",
"Description": "My first parameter group",
"IsGlobal": "yes"
}
]
}
```
**Example**
다음 샘플 코드는 최대 10개의 파라미터 그룹을 나열합니다.
```
aws elasticache describe-cache-parameter-groups --max-records 10
```
이 명령의 JSON 출력은 각 파라미터 그룹의 이름, 패밀리, 설명 및 redis5.6의 경우 파라미터 그룹이 글로벌 데이터 스토어(IsGlobal)의 일부인지 여부를 나열하는 것과 같습니다.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "custom-redis32",
"CacheParameterGroupFamily": "redis3.2",
"Description": "custom parameter group with reserved-memory > 0"
},
{
"CacheParameterGroupName": "default.memcached1.4",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "Default parameter group for memcached1.4"
},
{
"CacheParameterGroupName": "default.redis2.6",
"CacheParameterGroupFamily": "redis2.6",
"Description": "Default parameter group for redis2.6"
},
{
"CacheParameterGroupName": "default.redis2.8",
"CacheParameterGroupFamily": "redis2.8",
"Description": "Default parameter group for redis2.8"
},
{
"CacheParameterGroupName": "default.redis3.2",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Default parameter group for redis3.2"
},
{
"CacheParameterGroupName": "default.redis3.2.cluster.on",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Customized default parameter group for redis3.2 with cluster mode on"
},
{
"CacheParameterGroupName": "default.redis5.6.cluster.on",
"CacheParameterGroupFamily": "redis5.0",
"Description": "Customized default parameter group for redis5.6 with cluster mode on",
"isGlobal": "yes"
},
]
}
```
[자세한 내용은 `describe-cache-parameter-groups` 단원을 참조하세요.](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameter-groups.html)
## 이름으로 ElastiCache 파라미터 그룹 나열(ElastiCache API)
ElastiCache API를 사용하여 파라미터 그룹의 목록을 생성하려면 `DescribeCacheParameterGroups` 작업을 사용합니다. 파라미터 그룹의 이름을 입력하면 그 파라미터 그룹만 나열됩니다. 파라미터 그룹의 이름을 입력하지 않으면 최대 `MaxRecords`개의 파라미터 그룹이 나열됩니다. 두 경우 모두 파라미터 그룹의 이름, 패밀리 및 설명이 나열됩니다.
**Example**
다음 샘플 코드에는 *myMem14* 파라미터 그룹이 나열되어 있습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 각 파라미터 그룹의 이름, 패밀리 및 설명을 나열하는 것과 같습니다.
```
myMem14memcached1.4My custom Memcached 1.4 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
다음 샘플 코드는 최대 10개의 파라미터 그룹을 나열합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&MaxRecords=10
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 각 파라미터 그룹의 이름, 패밀리, 설명 및 redis5.6의 경우 파라미터 그룹이 글로벌 데이터 스토어(IsGlobal)의 일부인지 여부를 나열하는 것과 같습니다.
```
myRedis28redis2.8My custom Redis 2.8 parameter groupmyMem14memcached1.4My custom Memcached 1.4 parameter groupmyRedis56redis5.0My custom redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
다음 샘플 코드에는 *myRed28* 파라미터 그룹이 나열되어 있습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 각 파라미터 그룹의 이름, 패밀리 및 설명을 나열하는 것과 같습니다.
```
myRed28redis2.8My custom Redis 2.8 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
다음 샘플 코드에는 *myRed56* 파라미터 그룹이 나열되어 있습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed56
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 각 파라미터 그룹의 이름, 패밀리, 설명 및 파라미터 그룹이 글로벌 데이터 스토어(IsGlobal)의 일부인지 여부를 나열하는 것과 같습니다.
```
myRed56redis5.0My custom Redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
[자세한 내용은 `DescribeCacheParameterGroups` 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html)
# ElastiCache 파라미터 그룹 값 나열
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 파라미터 및 파라미터 그룹의 값을 나열할 수 있습니다.
## ElastiCache 파라미터 그룹 값 나열(콘솔)
다음 절차에서는 ElastiCache 콘솔을 사용하여 파라미터 및 파라미터 그룹의 값을 나열하는 방법을 보여줍니다.
**ElastiCache 콘솔을 사용하여 파라미터 그룹의 파라미터 및 그 값을 나열하려면**
1. AWS Management Console에 로그인하고[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 사용 가능한 모든 파라미터 목록을 표시하려면 왼쪽 탐색 창에서 [**Parameter Groups**]를 선택합니다.
1. 파라미터 그룹의 이름 왼쪽에 있는 확인란을 선택하여 파라미터 및 값을 나열할 파라미터 그룹을 선택합니다.
파라미터 및 그 값이 화면 하단에 나열됩니다. 파라미터의 수가 많으면 위아래로 스크롤하여 원하는 파라미터를 찾습니다.
## 파라미터 그룹 값 나열(AWS CLI)
AWS CLI를 사용하여 파라미터 그룹의 파라미터 및 그 값을 나열하려면 `describe-cache-parameters` 명령을 사용합니다.
**Example**
다음 샘플 코드에는 *myMem14* 파라미터 그룹의 모든 Memcached 파라미터 및 그 값이 나열되어 있습니다.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myMem14
```
Windows의 경우:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myMem14
```
**Example**
다음 샘플 코드는 *myRedis28* 파라미터 그룹의 모든 파라미터 및 그 값을 나열합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myRedis28
```
Windows의 경우:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myRed28
```
[자세한 내용은 `describe-cache-parameters` 단원을 참조하세요.](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameters.html)
## 파라미터 그룹 값 나열(ElastiCache API)
ElastiCache API를 사용하여 파라미터 그룹의 파라미터 및 그 값을 나열하려면 `DescribeCacheParameters` 작업을 사용합니다.
**Example**
다음 샘플 코드에는 *myMem14* 파라미터 그룹의 모든 Memcached 파라미터가 나열되어 있습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 다음과 유사합니다. 응답이 잘렸습니다.
```
integersystemfalseThe maximum configurable amount of memory to use to store items, in megabytes.1000cache.c1.medium6000cache.c1.xlarge7100cache.m1.large1300cache.m1.small
...output omitted...
6d355589-af49-11e0-97f9-279771c4477e
```
**Example**
다음 샘플 코드에는 *myRed28* 파라미터 그룹의 모든 파라미터가 나열되어 있습니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
이 작업의 응답은 다음과 유사합니다. 응답이 잘렸습니다.
```
integersystemfalseThe maximum configurable amount of memory to use to store items, in megabytes.1000cache.c1.medium6000cache.c1.xlarge7100cache.m1.large1300cache.m1.small
...output omitted...
6d355589-af49-11e0-97f9-279771c4477e
```
[자세한 내용은 `DescribeCacheParameters` 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html)
# ElastiCache 파라미터 그룹 수정
**중요**
어떤 기본 파라미터 그룹도 수정할 수 없습니다.
파라미터 그룹의 일부 파라미터 값을 수정할 수 있습니다. 이 파라미터 값은 파라미터 그룹과 연결된 클러스터에 적용됩니다. 변경한 파라미터 값이 파라미터 그룹에 적용되는 시점에 관한 자세한 내용은 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 및 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached) 섹션을 참조하세요.
## 파라미터 그룹 수정(콘솔)
다음 절차는 ElastiCache 콘솔을 사용하여 `cluster-enabled` 파라미터 값을 변경하는 방법을 보여줍니다. 동일한 절차를 통해 모든 파라미터 값을 변경할 수 있습니다.
**ElastiCache 콘솔을 사용하여 파라미터 값을 변경하려면**
1. AWS Management Console에 로그인하고[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 사용 가능한 모든 파라미터 목록을 표시하려면 왼쪽 탐색 창에서 [**Parameter Groups**]를 선택합니다.
1. 파라미터 그룹의 이름 왼쪽에 있는 확인란을 선택하여 수정할 파라미터 그룹을 선택합니다.
파라미터 그룹의 파라미터가 화면 하단에 나열됩니다. 모든 파라미터를 보려면 목록 페이지를 탐색해야 할 수도 있습니다.
1. 파라미터를 하나 이상 수정하려면 [**Edit Parameters**]를 선택합니다.
1. **파라미터 그룹 편집:** 화면에서 왼쪽 및 오른쪽 화살표로 스크롤하여 `binding_protocol` 파라미터를 찾은 다음 **값** 열에 `ascii`를 입력합니다.
1. **변경 사항 저장(Save Changes)**을 선택합니다.
1. Memcached의 경우, 변경한 파라미터의 이름을 찾으려면 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached) 섹션을 참조하세요. *다시 시작한 후* 파라미터에 변경 사항이 발생하면 이 파라미터 그룹을 사용하는 모든 클러스터를 재부팅합니다. 자세한 내용은 [클러스터 재부팅](Clusters.html#Rebooting)을 참조하세요.
1. Valkey 및 Redis OSS를 사용하여 변경한 파라미터의 이름을 찾으려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터가 있고 다음 파라미터를 변경한 경우 클러스터에서 노드를 재부팅해야 합니다.
+ activerehashing
+ 데이터베이스
자세한 내용은 [노드 재부팅](nodes.rebooting.md)을 참조하세요.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 파라미터 변경**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 다음 파라미터를 변경하는 경우 다음 확인 단계를 따르십시오.
activerehashing
데이터베이스
Redis OSS를 사용하면 클러스터의 수동 백업을 연결할 수 있습니다. [수동 백업 지원](backups-manual.md) 섹션을 참조하세요.
클러스터를 삭제합니다. [클러스터 삭제](Clusters.html#Delete)를 참조하세요.
변경한 파라미터 그룹 및 백업을 사용해 클러스터를 복원하여 새로운 클러스터를 시드합니다. [백업에서 새 캐시로 복원](backups-restoring.md) 섹션을 참조하세요.
다른 파라미터를 변경한 경우에는 필요하지 않습니다.
## 파라미터 그룹 수정(AWS CLI)
AWS CLI를 사용하여 파라미터 값을 변경하려면 `modify-cache-parameter-group` 명령을 사용합니다.
**Example**
Memcached를 사용하여 변경하려는 파라미터의 이름과 허용되는 값을 찾으려면 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached) 섹션을 참조하세요.
다음 예제 코드에서는 `myMem14` 파라미터 그룹에서 두 파라미터 *chunk\$1size* 및 *chunk\$1size\$1growth\$1fact*의 값을 설정합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--parameter-name-values \
ParameterName=chunk_size,ParameterValue=96 \
ParameterName=chunk_size_growth_fact,ParameterValue=1.5
```
Windows의 경우:
```
aws elasticache modify-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--parameter-name-values ^
ParameterName=chunk_size,ParameterValue=96 ^
ParameterName=chunk_size_growth_fact,ParameterValue=1.5
```
이 명령의 출력은 다음과 같습니다.
```
{
"CacheParameterGroupName": "myMem14"
}
```
**Example**
Valkey 및 Redis OSS를 사용하여 변경하려는 파라미터의 이름과 허용되는 값을 찾으려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
다음 예제 코드에서는 `myredis32-on-30` 파라미터 그룹에서 두 파라미터 *reserved-memory-percent* 및 *cluster-enabled*의 값을 설정합니다. *reserved-memory-percent*를 `30`(30%)로, *cluster-enabled*를 `yes`로 설정해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(복제 그룹)에 해당 파라미터 그룹을 사용할 수 있도록 합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name myredis32-on-30 \
--parameter-name-values \
ParameterName=reserved-memory-percent,ParameterValue=30 \
ParameterName=cluster-enabled,ParameterValue=yes
```
Windows의 경우:
```
aws elasticache modify-cache-parameter-group ^
--cache-parameter-group-name myredis32-on-30 ^
--parameter-name-values ^
ParameterName=reserved-memory-percent,ParameterValue=30 ^
ParameterName=cluster-enabled,ParameterValue=yes
```
이 명령의 출력은 다음과 같습니다.
```
{
"CacheParameterGroupName": "my-redis32-on-30"
}
```
[자세한 내용은 `modify-cache-parameter-group` 단원을 참조하세요.](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-parameter-group.html)
변경한 파라미터의 이름을 찾으려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터가 있고 다음 파라미터를 변경한 경우 클러스터에서 노드를 재부팅해야 합니다.
+ activerehashing
+ 데이터베이스
자세한 내용은 [노드 재부팅](nodes.rebooting.md)을 참조하세요.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 파라미터 변경**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 다음 파라미터를 변경하는 경우 다음 확인 단계를 따르십시오.
activerehashing
데이터베이스
클러스터의 수동 백업을 만듭니다. [수동 백업 지원](backups-manual.md) 섹션을 참조하세요.
클러스터를 삭제합니다. [클러스터 삭제](Clusters.html#Delete)를 참조하세요.
변경한 파라미터 그룹 및 백업을 사용해 클러스터를 복원하여 새로운 클러스터를 시드합니다. [백업에서 새 캐시로 복원](backups-restoring.md) 섹션을 참조하세요.
다른 파라미터를 변경한 경우에는 필요하지 않습니다.
## 파라미터 그룹 수정(ElastiCache API)
ElastiCache API를 사용하여 파라미터 그룹의 파라미터 값을 변경하려면 `ModifyCacheParameterGroup` 작업을 사용합니다.
**Example**
Memcached를 사용하여 변경하려는 파라미터의 이름과 허용되는 값을 찾으려면 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached) 섹션을 참조하세요.
다음 예제 코드에서는 `myMem14` 파라미터 그룹에서 두 파라미터 *chunk\$1size* 및 *chunk\$1size\$1growth\$1fact*의 값을 설정합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myMem14
&ParameterNameValues.member.1.ParameterName=chunk_size
&ParameterNameValues.member.1.ParameterValue=96
&ParameterNameValues.member.2.ParameterName=chunk_size_growth_fact
&ParameterNameValues.member.2.ParameterValue=1.5
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
**Example**
Valkey 및 Redis OSS를 사용하여 변경하려는 파라미터의 이름과 허용되는 값을 찾으려면 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 섹션을 참조하세요.
다음 예제 코드에서는 `myredis32-on-30` 파라미터 그룹에서 두 파라미터 *reserved-memory-percent* 및 *cluster-enabled*의 값을 설정합니다. *reserved-memory-percent*를 `30`(30%)로, *cluster-enabled*를 `yes`로 설정해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(복제 그룹)에 해당 파라미터 그룹을 사용할 수 있도록 합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myredis32-on-30
&ParameterNameValues.member.1.ParameterName=reserved-memory-percent
&ParameterNameValues.member.1.ParameterValue=30
&ParameterNameValues.member.2.ParameterName=cluster-enabled
&ParameterNameValues.member.2.ParameterValue=yes
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
[자세한 내용은 `ModifyCacheParameterGroup` 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html)
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터가 있고 다음 파라미터를 변경한 경우 클러스터에서 노드를 재부팅해야 합니다.
+ activerehashing
+ 데이터베이스
자세한 내용은 [노드 재부팅](nodes.rebooting.md) 섹션을 참조하세요.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 파라미터 변경**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 다음 파라미터를 변경하는 경우 다음 확인 단계를 따르십시오.
activerehashing
데이터베이스
클러스터의 수동 백업을 만듭니다. [수동 백업 지원](backups-manual.md) 섹션을 참조하세요.
클러스터를 삭제합니다. [ElastiCache에서 클러스터 삭제](Clusters.Delete.md) 섹션을 참조하세요.
변경한 파라미터 그룹 및 백업을 사용해 클러스터를 복원하여 새로운 클러스터를 시드합니다. [백업에서 새 캐시로 복원](backups-restoring.md) 섹션을 참조하세요.
다른 파라미터를 변경한 경우에는 필요하지 않습니다.
# ElastiCache 파라미터 그룹 삭제
ElastiCache 콘솔, AWS CLI 또는 ElastiCache API를 사용하여 사용자 지정 파라미터 그룹을 삭제할 수 있습니다.
파라미터 그룹이 클러스터와 연결된 경우 삭제할 수 없습니다. 또한 기본 파라미터 그룹도 삭제할 수 없습니다.
## 파라미터 그룹 삭제(콘솔)
다음 절차는 ElastiCache 콘솔을 사용하여 파라미터 그룹을 삭제하는 방법을 보여줍니다.
**ElastiCache 콘솔을 사용하여 파라미터 그룹을 삭제하려면**
1. AWS Management Console에 로그인하고[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 사용 가능한 모든 파라미터 목록을 표시하려면 왼쪽 탐색 창에서 [**Parameter Groups**]를 선택합니다.
1. 파라미터 그룹의 이름 왼쪽에 있는 확인란을 선택하여 삭제할 파라미터 그룹을 선택합니다.
[**Delete**] 버튼이 활성화됩니다.
1. **삭제**를 선택합니다.
[**Delete Parameter Groups**] 확인 화면이 나타납니다.
1. 파라미터 그룹을 삭제하려면 [**Delete Parameter Groups**] 확인 화면에서 [**Delete**]를 추가합니다.
파라미터 그룹을 유지하려면 [**Cancel**]을 선택합니다.
## 파라미터 그룹 삭제(AWS CLI)
AWS CLI를 사용하여 파라미터 그룹을 삭제하려면 `delete-cache-parameter-group` 명령을 사용합니다. 삭제할 파라미터 그룹의 경우 `--cache-parameter-group-name`으로 지정된 파라미터 그룹에는 클러스터를 연결할 수 없으며 기본 파라미터 그룹이 될 수도 없습니다.
다음 샘플 코드에서는 *myMem14* 파라미터 그룹을 삭제합니다.
**Example**
Linux, macOS, Unix의 경우:
```
aws elasticache delete-cache-parameter-group \
--cache-parameter-group-name myRed28
```
Windows의 경우:
```
aws elasticache delete-cache-parameter-group ^
--cache-parameter-group-name myRed28
```
[자세한 내용은 `delete-cache-parameter-group` 단원을 참조하세요.](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-parameter-group.html)
## 파라미터 그룹 삭제(ElastiCache API)
ElastiCache API를 사용하여 파라미터 그룹을 삭제하려면 `DeleteCacheParameterGroup` 작업을 사용합니다. 삭제할 파라미터 그룹의 경우 `CacheParameterGroupName`으로 지정된 파라미터 그룹에는 클러스터를 연결할 수 없으며 기본 파라미터 그룹이 될 수도 없습니다.
**Example**
Memcached를 사용하는 경우 다음 샘플 코드는 *myMem14* 파라미터 그룹을 삭제합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
**Example**
다음 샘플 코드에서는 *myRed28* 파라미터 그룹을 삭제합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
[자세한 내용은 `DeleteCacheParameterGroup` 단원을 참조하세요.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html)
# 엔진별 파라미터
**Valkey 및 Redis OSS**
대부분의 Valkey 8 파라미터는 Redis OSS 7.1 파라미터와 호환됩니다. Valkey 7.2 파라미터는 Redis OSS 7 파라미터와 동일합니다.
Valkey 또는 Redis OSS 클러스터에 파라미터 그룹을 지정하지 않으면 엔진 버전에 적절한 기본 파라미터 그룹이 사용됩니다. 기본 파라미터 그룹에서는 어떤 파라미터 값도 변경할 수 없습니다. 그러나 조건부로 수정 가능한 파라미터 값이 두 파라미터 그룹에서 동일하면 언제든지 사용자 지정 파라미터 그룹을 생성하고 클러스터에 할당할 수 있습니다. 자세한 내용은 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 단원을 참조하십시오.
**Topics**
+ [Valkey 및 Redis OSS 파라미터](#ParameterGroups.Redis)
+ [Memcached 특정 파라미터](#ParameterGroups.Memcached)
## Valkey 및 Redis OSS 파라미터
**Topics**
+ [Valkey 8.2 파라미터 변경 사항](#ParameterGroups.Valkey.8.2)
+ [Valkey 8.1 파라미터 변경 사항](#ParameterGroups.Valkey.8.1)
+ [Valkey 8.0 파라미터 변경 사항](#ParameterGroups.Valkey.8)
+ [Valkey 7.2 및 Redis OSS 7 파라미터 변경 사항](#ParameterGroups.Redis.7)
+ [Redis OSS 6.x 파라미터 변경 사항](#ParameterGroups.Redis.6-x)
+ [Redis OSS 5.0.3 파라미터 변경 사항](#ParameterGroups.Redis.5-0-3)
+ [Redis OSS 5.0.0 파라미터 변경 사항](#ParameterGroups.Redis.5.0)
+ [Redis OSS 4.0.10 파라미터 변경 사항](#ParameterGroups.Redis.4-0-10)
+ [Redis OSS 3.2.10 파라미터 변경 사항](#ParameterGroups.Redis.3-2-10)
+ [Redis OSS 3.2.6 파라미터 변경 사항](#ParameterGroups.Redis.3-2-6)
+ [Redis OSS 3.2.4 파라미터 변경 사항](#ParameterGroups.Redis.3-2-4)
+ [Redis OSS 2.8.24(확장) 추가 파라미터](#ParameterGroups.Redis.2-8-24)
+ [Redis OSS 2.8.23(확장) 추가 파라미터](#ParameterGroups.Redis.2-8-23)
+ [Redis OSS 2.8.22(확장) 추가 파라미터](#ParameterGroups.Redis.2-8-22)
+ [Redis OSS 2.8.21 추가 파라미터](#ParameterGroups.Redis.2-8-21)
+ [Redis OSS 2.8.19 추가 파라미터](#ParameterGroups.Redis.2-8-19)
+ [Redis OSS 2.8.6 추가 파라미터](#ParameterGroups.Redis.2-8-6)
+ [Redis OSS 2.6.13 파라미터](#ParameterGroups.Redis.2-6-13)
+ [Redis OSS 노드 유형별 파라미터](#ParameterGroups.Redis.NodeSpecific)
### Valkey 8.2 파라미터 변경 사항
**파라미터 그룹 패밀리:** valkey8
**참고**
Valkey 8.2 파라미터 변경 사항은 Valkey 8.1에 적용되지 않습니다.
Valkey 8.0 이상의 파라미터 그룹은 Redis OSS 7.2.4와 호환되지 않습니다.
Valkey 8.2에서는 서버리스 캐시에 다음 명령을 사용할 수 없습니다. `commandlog`, `commandlog get`, `commandlog len`, `commandlog help` 및 `commandlog reset.`
**Valkey 8.2의 새 파라미터 그룹**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| search-fanout-target-mode(8.2에 추가됨) | 기본값: 클라이언트 유형: 문자열 수정 가능 여부: 예 변경 적용: 즉시 | search-fanout-target-mode 구성 파라미터는 Valkey 클러스터 환경의 노드 간에 검색 쿼리가 분산되는 방식을 제어합니다. 이 설정은 클라이언트 유형 또는 READONLY 상태에 관계없이 모든 클러스터 노드에 검색 쿼리를 무작위로 배포하여 최대 처리량을 최적화하는 ‘처리량’과 프라이머리 노드에만 비READONLY 클라이언트를 라우팅하여 클라이언트 연결 특성을 존중하는 ‘클라이언트’, 복제본 노드에만 복제본 연결의 READONLY 클라이언트, 모든 노드에 무작위로 기본 연결의 READONLY 클라이언트의 두 값을 허용합니다. 기본 동작은 '클라이언트' 모드입니다. 즉, 시스템은 쿼리 라우팅 결정을 위해 클라이언트 연결 유형 및 READONLY 상태를 준수합니다. 최대 클러스터 리소스 사용률이 필요한 대용량 검색 워크로드의 경우 처리량 모드를 사용하고, 읽기/쓰기 구분을 유지하고 애플리케이션 수준 READONLY 연결 패턴을 준수하려는 경우 클라이언트 모드를 사용합니다. |
| search-default-timeout-ms | 기본값: 50000 허용되는 값: 1\$160000 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 기본 Valkey 검색 쿼리 제한 시간(밀리초)입니다. |
| search-enable-partial-results | 기본값: yes 허용되는 값: yes, no 유형: boolean 수정 가능 여부: 예 변경 적용: 즉시 | Valkey 검색에 대한 쿼리 실패 동작을 구성합니다. 활성화하면 하나 이상의 샤드에서 제한 시간이 발생하면 검색 쿼리가 부분 결과를 반환합니다. 비활성화하면 샤드 제한 시간으로 인해 전체 검색 쿼리가 실패하고 오류가 반환됩니다. |
### Valkey 8.1 파라미터 변경 사항
**파라미터 그룹 패밀리:** valkey8
**참고**
Valkey 8.1 파라미터 변경 사항은 Valkey 8.0에 적용되지 않습니다.
Valkey 8.0 이상의 파라미터 그룹은 Redis OSS 7.2.4와 호환되지 않습니다.
Valkey 8.1에서는 서버리스 캐시에 다음 명령을 사용할 수 없습니다. `commandlog`, `commandlog get`, `commandlog len`, `commandlog help` 및 `commandlog reset.`
**Valkey 8.1의 새 파라미터 그룹**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| commandlog-large-request-max-len(8.1에 추가됨) | 기본값: 1048576 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | Valkey 명령 로그 기능으로 기록할 요청의 최대 크기입니다. |
| commandlog-large-request-max-len(8.1에 추가됨) | 기본값: 128 허용되는 값: 0\$11024 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 요청에 대한 Valkey 명령 로그의 최대 길이입니다. |
| commandlog-reply-larger-than(8.1에 추가됨) | 기본값: 1048576 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | Valkey 명령 로그 기능으로 기록할 응답의 최대 크기입니다. |
| commandlog-large-reply-max-len(8.1에 추가됨) | 기본값: 128 허용되는 값: 0\$11024 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 응답에 대한 Valkey 명령 로그의 최대 길이입니다. |
### Valkey 8.0 파라미터 변경 사항
**파라미터 그룹 패밀리:** valkey8
**참고**
Redis OSS 7.2.4는 Valkey 8 이상의 파라미터 그룹과 호환되지 않습니다.
**Valkey 8.0의 특정 파라미터 변경 사항**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| repl-backlog-size | 기본값: 10485760 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 프라이머리 노드 백로그 버퍼의 크기(바이트)입니다. 백로그는 프라이머리 노드의 데이터에 대한 업데이트를 레코딩하는 데 사용됩니다. 읽기 전용 복제본이 기본에 연결되면 프라이머리 노드를 따라잡기 위해 백로그에서 데이터를 적용하는 부분적 동기화(psync)를 수행하려고 시도합니다. psync가 실패하면 전체 동기화가 필요합니다. 이 파라미터의 최소값은 16384입니다. 참고: Redis OSS 2.8.22부터 이 파라미터는 기본 클러스터와 읽기 전용 복제본에 적용됩니다. |
| maxmemory-samples | 기본값: 3 허용되는 값: 1\$164 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | LRU(가장 오랫동안 사용되지 않음) 및 TTL(Time To Live) 계산의 경우 파라미터는 확인할 키의 샘플 크기를 나타냅니다. 기본적으로 Redis OSS는 키 3개를 선택하고 가장 최근에 사용한 키를 사용합니다. |
**Valkey 8.0의 새 파라미터 그룹**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| extended-redis-compatibility | 허용되는 값: yes, no 기본값: yes 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | 확장 Redis OSS 호환성 모드를 사용하면 Valkey 서체가 Redis OSS 7.2로 설정됩니다. 도구 또는 클라이언트에 문제가 있는 경우에만 이 기능을 활성화합니다. 고객 대면 영향: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
**Valkey 8.0에서 파라미터 그룹 제거**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| lazyfree-lazy-eviction | 허용되는 값: yes, no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | 제거 시 비동기식 삭제를 수행합니다. |
| lazyfree-lazy-expire | 허용되는 값: yes, no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | 키 만료 시 비동기식 삭제를 수행합니다. |
| lazyfree-lazy-server-del | 허용되는 값: yes, no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | 값을 업데이트하는 명령에 대해 비동기식 삭제를 수행합니다. |
| lazyfree-lazy-server-del | 기본값: 아니요 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 값이 yes로 설정되면 DEL 명령이 UNLINK 명령과 동일하게 작동합니다. |
| replica-lazy-flush | 기본값: yes 유형: boolean 수정 가능 여부: 아니요 이전 이름: slave-lazy-flush | 복제본 동기화 동안 비동기식 flushDB를 수행합니다. |
### Valkey 7.2 및 Redis OSS 7 파라미터 변경 사항
**파라미터 그룹 패밀리:** valkey7
Valkey 7.2 기본 파라미터 그룹은 다음과 같습니다.
+ `default.valkey7` – 이 파라미터 그룹 또는 Valkey(클러스터 모드 비활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
+ `default.valkey7.cluster.on` – 이 파라미터 그룹 또는 Valkey(클러스터 모드 활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
**파라미터 그룹 패밀리:** redis7
Redis OSS 7 기본 파라미터 그룹은 다음과 같습니다.
+ `default.redis7` – 이 파라미터 그룹 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
+ `default.redis7.cluster.on` – 이 파라미터 그룹 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
**특정 파라미터 변경 사항**
Redis OSS 7에 추가된 파라미터는 다음과 같습니다. Valkey 7.2는 이러한 파라미터도 지원합니다.
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| cluster-allow-pubsubshard-when-down | 허용되는 값: `yes`, `no` 기본값: `yes` 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 기본값인 yes로 설정하면 클러스터가 다운된 상태에서, 슬롯을 소유하고 있다고 판단되는 한 노드가 pubsub 샤드 트래픽을 처리할 수 있습니다. |
| cluster-preferred-endpoint-type | 허용되는 값: `ip`, `tls-dynamic` 기본값: `tls-dynamic` 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 이 값은 MOVED/ASKING 요청에 어떤 엔드포인트가 반환될지와 `CLUSTER SLOTS` 및 `CLUSTER SHARDS`에 대한 엔드포인트 필드를 제어합니다. 값이 ip로 설정되면 노드는 자신의 IP 주소를 광고합니다. 값이 tls-dynamic으로 설정되면 전송 중 암호화가 활성되어 있을 때는 노드가 호스트 이름을 광고하고 그렇지 않을 때는 IP 주소를 광고합니다. |
| latency-tracking | 허용되는 값: `yes`, `no` 기본값: `no` 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | yes로 설정하면 명령별 지연 시간을 추적하고 `INFO` 지연 시간 통계 명령을 통해 백분위수 분포 내보내기를 활성화하며, `LATENCY` 명령을 통해 지연 시간 분포(히스토그램)를 누적 집계합니다. |
| hash-max-listpack-entries | 허용되는 값: `0+` 기본값: `512` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 데이터세트를 압축하기 위한 해시 항목 최대 개수입니다. |
| hash-max-listpack-value | 허용되는 값: `0+` 기본값: `64` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 데이터세트를 압축하기 위한 최대 해시 항목의 임곗값입니다. |
| zset-max-listpack-entries | 허용되는 값: `0+` 기본값: `128` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 데이터세트를 압축하기 위한 정렬된 세트 항목 최대 개수입니다. |
| zset-max-listpack-value | 허용되는 값: `0+` 기본값: `64` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 데이터세트를 압축하기 위한 정렬된 최대 세트 항목의 임곗값입니다. |
Redis OSS 7에서 변경된 파라미터는 다음과 같습니다.
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| activerehashing | 수정 가능: `no`. Redis OSS 7에서는 이 파라미터가 기본적으로 숨겨져 있고 활성화되어 있습니다. 비활성화하려면 [지원 사례](https://console.aws.amazon.com/support/home)를 생성해야 합니다. | 수정 가능 여부는 '예'였습니다. |
Redis OSS 7에서 제거된 파라미터는 다음과 같습니다.
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| hash-max-ziplist-entries | 허용되는 값: `0+` 기본값: `512` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 작은 해시 인코딩을 표현하는 데 `ziplist` 대신 `listpack` 사용 |
| hash-max-ziplist-value | 허용되는 값: `0+` 기본값: `64` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 작은 해시 인코딩을 표현하는 데 `ziplist` 대신 `listpack` 사용 |
| zset-max-ziplist-entries | 허용되는 값: `0+` 기본값: `128` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 작은 해시 인코딩을 표현하는 데 `ziplist` 대신 `listpack` 사용. |
| zset-max-ziplist-value | 허용되는 값: `0+` 기본값: `64` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 작은 해시 인코딩을 표현하는 데 `ziplist` 대신 `listpack` 사용. |
| list-max-ziplist-size | 허용되는 값: 기본값: `-2` 유형: 정수 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 내부 목록 노드당 허용되는 항목 개수입니다. |
### Redis OSS 6.x 파라미터 변경 사항
**파라미터 그룹 패밀리:** redis6.x
Redis OSS 6.x 기본 파라미터 그룹은 다음과 같습니다.
+ `default.redis6.x` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
+ `default.redis6.x.cluster.on` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
**참고**
Redis OSS 엔진 버전 6.2에서 r6gd 노드 패밀리가 [ElastiCache의 데이터 계층화](data-tiering.md)의 정보를 통해 사용하도록 도입된 경우 *noeviction*, *volatile-lru* 및 *allkeys-lru* 최대 메모리 정책은 r6gd 노드 유형을 통해 지원됩니다.
자세한 내용은 [ElastiCache for Redis OSS 버전 6.2(향상된 버전)](engine-versions.md#redis-version-6.2) 및 [ElastiCache for Redis OSS 버전 6.0(향상된 버전)](engine-versions.md#redis-version-6.0) 섹션을 참조하세요.
Redis OSS 6.x에 추가된 파라미터는 다음과 같습니다.
| 세부 정보 | 설명 |
| --- | --- |
| acl-pubsub-default (added in 6.2) | 허용되는 값: `resetchannels`, `allchannels` 기본값: `allchannels` 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터에 연결된 기존 Redis OSS 사용자에게는 계속해서 기존 권한이 있습니다. 사용자를 업데이트하거나 클러스터를 재부팅하여 기존 Redis OSS 사용자를 업데이트합니다. | 이 클러스터에 배포된 ACL 사용자의 기본 pubsub 채널 권한입니다. |
| cluster-allow-reads-when-down (added in 6.0) | 기본값: 아니요 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | yes로 설정하면 노드가 기본 그룹의 쿼럼에 도달할 수 없는 경우에도 Redis OSS(클러스터 모드 활성화됨) 복제 그룹이 읽기 명령을 계속 처리합니다. 기본값인 no로 설정하면 복제 그룹이 모든 명령을 거부합니다. 노드 그룹이 3개 미만인 클러스터를 사용하거나 애플리케이션에서 기한 경과 읽기를 안전하게 처리할 수 있는 경우 이 값을 yes로 설정하는 것이 좋습니다. |
| tracking-table-max-keys (added in 6.0) | 기본값: 1,000,000 유형: 숫자 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 클라이언트 측 캐싱을 지원하기 위해 Redis OSS는 어떤 클라이언트가 어떤 키에 액세스했는지 확인하는 추적을 지원합니다. 추적된 키가 수정되면 무효화 메시지가 모든 클라이언트에 전송되어 키의 캐시된 값이 더 이상 유효하지 않음을 알립니다. 이 값을 사용하면 이 테이블의 상한을 지정할 수 있습니다. 이 파라미터 값을 초과하면 클라이언트가 임의로 무효화 메시지를 전송합니다. 이 값은 충분한 수의 키를 계속 추적하면서 메모리 사용을 제한하도록 조정해야 합니다. 메모리 부족 조건에서도 키가 무효화됩니다. |
| acllog-max-len (added in 6.0) | 기본값: 128 유형: 숫자 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 이 값은 ACL 로그의 최대 항목 수에 해당합니다. |
| active-expire-effort (added in 6.0) | 기본값: 1 유형: 숫자 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | Redis OSS는 두 가지 메커니즘을 사용하여 유지 시간(TTL)이 초과된 키를 삭제합니다. 하나는 키가 액세스되고 만료된 것으로 확인된 경우입니다. 다른 하나는 정기적인 작업이 키를 샘플링하고 유지 시간(TTL)이 초과된 키를 만료시키는 경우입니다. 이 파라미터는 Redis OSS가 정기 작업에서 항목을 만료시키는 데 사용하는 작업량을 정의합니다. 기본값 1은 만료된 키의 10% 이상이 메모리에 남아 있지 않도록 합니다. 또한 총 메모리의 25% 이상을 소비하지 않도록 시스템에 대기 시간을 추가합니다. 이 값을 최대 10까지 늘려 키 만료에 사용되는 작업량을 늘릴 수 있습니다. CPU 사용량이 늘어나고 대기 시간이 길어진다는 단점이 있습니다. 높은 메모리 사용량과 CPU 사용률 증가를 허용할 수 있는 경우가 아니면 1의 값을 사용하는 것이 좋습니다. |
| lazyfree-lazy-user-del (added in 6.0) | 기본값: 아니요 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 값이 yes로 설정되면 `DEL` 명령이 `UNLINK` 명령과 동일하게 작동합니다. |
Redis OSS 6.x에서 제거된 파라미터는 다음과 같습니다.
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| lua-replicate-commands | 허용되는 값: yes/no 기본값: yes 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | Lua 스크립트에서 항상 Lua 효과 복제를 활성화하거나 활성화하지 않음 |
### Redis OSS 5.0.3 파라미터 변경 사항
**파라미터 그룹 Family:** redis5.0
Redis OSS 5.0 기본 파라미터 그룹
+ `default.redis5.0` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
+ `default.redis5.0.cluster.on` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
**Redis OSS 5.0.3에 추가된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| rename-commands | 기본값: 없음 유형: 문자열 수정 가능 여부: 예 변경 적용: 클러스터의 모든 노드에 즉시 적용됨 | 이름 변경된 Redis OSS 명령의 목록(공백으로 구분)입니다. 다음은 이름 변경에 사용할 수 있는 제한된 명령의 목록입니다. `APPEND AUTH BITCOUNT BITFIELD BITOP BITPOS BLPOP BRPOP BRPOPLPUSH BZPOPMIN BZPOPMAX CLIENT CLUSTER COMMAND DBSIZE DECR DECRBY DEL DISCARD DUMP ECHO EVAL EVALSHA EXEC EXISTS EXPIRE EXPIREAT FLUSHALL FLUSHDB GEOADD GEOHASH GEOPOS GEODIST GEORADIUS GEORADIUSBYMEMBER GET GETBIT GETRANGE GETSET HDEL HEXISTS HGET HGETALL HINCRBY HINCRBYFLOAT HKEYS HLEN HMGET HMSET HSET HSETNX HSTRLEN HVALS INCR INCRBY INCRBYFLOAT INFO KEYS LASTSAVE LINDEX LINSERT LLEN LPOP LPUSH LPUSHX LRANGE LREM LSET LTRIM MEMORY MGET MONITOR MOVE MSET MSETNX MULTI OBJECT PERSIST PEXPIRE PEXPIREAT PFADD PFCOUNT PFMERGE PING PSETEX PSUBSCRIBE PUBSUB PTTL PUBLISH PUNSUBSCRIBE RANDOMKEY READONLY READWRITE RENAME RENAMENX RESTORE ROLE RPOP RPOPLPUSH RPUSH RPUSHX SADD SCARD SCRIPT SDIFF SDIFFSTORE SELECT SET SETBIT SETEX SETNX SETRANGE SINTER SINTERSTORE SISMEMBER SLOWLOG SMEMBERS SMOVE SORT SPOP SRANDMEMBER SREM STRLEN SUBSCRIBE SUNION SUNIONSTORE SWAPDB TIME TOUCH TTL TYPE UNSUBSCRIBE UNLINK UNWATCH WAIT WATCH ZADD ZCARD ZCOUNT ZINCRBY ZINTERSTORE ZLEXCOUNT ZPOPMAX ZPOPMIN ZRANGE ZRANGEBYLEX ZREVRANGEBYLEX ZRANGEBYSCORE ZRANK ZREM ZREMRANGEBYLEX ZREMRANGEBYRANK ZREMRANGEBYSCORE ZREVRANGE ZREVRANGEBYSCORE ZREVRANK ZSCORE ZUNIONSTORE SCAN SSCAN HSCAN ZSCAN XINFO XADD XTRIM XDEL XRANGE XREVRANGE XLEN XREAD XGROUP XREADGROUP XACK XCLAIM XPENDING GEORADIUS_RO GEORADIUSBYMEMBER_RO LOLWUT XSETID SUBSTR` |
자세한 내용은 [ElastiCache for Redis OSS 버전 5.0.6(향상된 버전)](engine-versions.md#redis-version-5-0.6) 단원을 참조하십시오.
### Redis OSS 5.0.0 파라미터 변경 사항
**파라미터 그룹 Family:** redis5.0
Redis OSS 5.0 기본 파라미터 그룹
+ `default.redis5.0` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
+ `default.redis5.0.cluster.on` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
**Redis OSS 5.0에 추가된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| stream-node-max-bytes | 허용되는 값: 0\$1 기본값: 4096 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | 스트림 데이터 구조는 내부에 여러 항목을 인코딩하는 노드의 기수 트리입니다. 이 구성을 사용하여 기수 트리에서 단일 노드의 최대 크기를 바이트로 지정합니다. 0으로 설정하면 트리 노드의 크기는 무제한입니다. |
| stream-node-max-entries | 허용되는 값: 0\$1 기본값: 100 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | 스트림 데이터 구조는 내부에 여러 항목을 인코딩하는 노드의 기수 트리입니다. 이 구성을 사용하여 새 노드 항목을 추가할 때 새 노드로 전환하기 전에 단일 노드에 포함할 수 있는 최대 항목 수를 지정합니다. 0으로 설정하면 트리 노드의 항목 수는 무제한입니다. |
| active-defrag-max-scan-fields | 허용되는 값: 1\$11000000 기본값: 1000 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | 기본 사전 스캔에서 처리될 최대 set/hash/zset/list 필드 수 |
| lua-replicate-commands | 허용되는 값: yes/no 기본값: yes 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | Lua 스크립트에서 항상 Lua 효과 복제를 활성화하거나 활성화하지 않음 |
| replica-ignore-maxmemory | 기본값: yes 유형: boolean 수정 가능 여부: 아니요 | 복제본이 프라이머리 노드와 독립적인 항목을 유지하여 maxmemory 설정을 무시하는지 결정합니다. |
Redis OSS는 커뮤니티 피드백에 따라 엔진 버전 5.0에서 여러 파라미터의 이름을 변경했습니다. 자세한 내용은 [What's New in Redis OSS 5?](https://aws.amazon.com/redis/Whats_New_Redis5/)를 참조하세요. 다음 표에는 새 이름 및 이러한 이름이 이전 버전과 매핑되는 방법이 나와 있습니다.
**Redis OSS 5.0에서 이름이 변경된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| replica-lazy-flush | 기본값: yes 유형: boolean 수정 가능 여부: 아니요 이전 이름: slave-lazy-flush | 복제본 동기화 동안 비동기식 flushDB를 수행합니다. |
| client-output-buffer-limit-replica-hard-limit | 기본값: 값은 [Redis OSS 노드 유형별 파라미터](#ParameterGroups.Redis.NodeSpecific)를 참조하세요. 유형: 정수 수정 가능 여부: 아니요 이전 이름: client-output-buffer-limit-slave-hard-limit | Redis OSS 읽기 전용 복제본: 클라이언트의 출력 버퍼가 특정 바이트 수에 도달하면 클라이언트가 연결 해제됩니다. |
| client-output-buffer-limit-replica-soft-limit | 기본값: 값은 [Redis OSS 노드 유형별 파라미터](#ParameterGroups.Redis.NodeSpecific)를 참조하세요. 유형: 정수 수정 가능 여부: 아니요 이전 이름: client-output-buffer-limit-slave-soft-limit | Redis OSS 읽기 전용 복제본: 클라이언트의 출력 버퍼가 특정 바이트 수에 도달하면 클라이언트가 연결 해제됩니다. 그러나 이러한 조건은 client-output-buffer-limit-replica-soft-seconds의 경우에만 지속됩니다. |
| client-output-buffer-limit-replica-soft-seconds | 기본값: 60 유형: 정수 수정 가능 여부: 아니요 이전 이름: client-output-buffer-limit-slave-soft-seconds | Redis OSS 읽기 전용 복제본: 클라이언트의 출력 버퍼가 client-output-buffer-limit-replica-soft-limit 바이트에 해당 시간(초)보다 오래 유지되면 클라이언트가 연결 해제됩니다. |
| replica-allow-chaining | 기본값: 아니요 유형: 문자열 수정 가능 여부: 아니요 이전 이름: slave-allow-chaining | Redis OSS가 자체 읽기 전용 복제본을 가질 수 있는지를 결정합니다. |
| min-replicas-to-write | 기본값: 0 유형: 정수 수정 가능 여부: 예 이전 이름: min-slaves-to-write 변경 적용: 즉시 | 프라이머리 노드가 클러스터에서 쓰기를 허용하기 위해 사용 가능해야 하는 최소 읽기 전용 복제본 수입니다. 사용 가능한 복제본 수가 이 수보다 떨어지면 프라이머리 노드는 더 이상 쓰기 요청을 허용하지 않습니다. 이 파라미터 또는 min-replicas-max-lag가 0이면 사용 가능한 복제본이 없어도 프라이머리 노드가 항상 쓰기 요청을 허용합니다. |
| min-replicas-max-lag | 기본값: 10 유형: 정수 수정 가능 여부: 예 이전 이름: min-slaves-max-lag 변경 적용: 즉시 | 프라이머리 노드가 읽기 전용 복제본에서 핑 요청을 수신해야 하는 시간(초)입니다. 이 시간까지 프라이머리 노드가 핑을 수신하지 않으면 복제본을 더 이상 사용할 수 없는 것으로 간주합니다. 사용 가능한 복제본 수가 min-replicas-to-write 아래로 떨어지면 기본 복제본이 해당 시점에서 쓰기 허용을 중지합니다. 이 파라미터 또는 min-replicas-to-write가 0이면 사용 가능한 복제본이 없어도 프라이머리 노드가 항상 쓰기 요청을 허용합니다. |
| close-on-replica-write | 기본값: yes 유형: boolean 수정 가능 여부: 예 이전 이름: close-on-slave-write 변경 적용: 즉시 | 활성화하면 읽기 전용 복제본에 작성을 시도하는 클라이언트의 연결이 끊어집니다. |
**Redis OSS 5.0에서 제거된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| repl-timeout | 기본값: 60 수정 가능 여부: 아니요 | 이 버전에서는 파라미터를 사용할 수 없습니다. |
### Redis OSS 4.0.10 파라미터 변경 사항
**파라미터 그룹 패밀리:** redis4.0
Redis OSS 4.0.x 기본 파라미터 그룹
+ `default.redis4.0` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
+ `default.redis4.0.cluster.on` – 이 파라미터 그룹 또는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 및 복제 그룹으로부터 파생된 파라미터 그룹을 사용합니다.
**Redis OSS 4.0.10에서 변경된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| maxmemory-policy | 허용되는 값: `allkeys-lru`, `volatile-lru`, **allkeys-lfu**, **volatile-lfu**, `allkeys-random`, `volatile-random`, `volatile-ttl`, `noeviction` 기본값: volatile-lru 유형: 문자열 수정 가능 여부: 예 변경 사항 적용: 즉시 | maxmemory-policy버전 2.6.13에는 섹션이 추가되었습니다. 4.0.10에는 새로 허용된 두 개의 값이 추가되었습니다. allkeys-lfu는 근사 LFU를 사용하여 모든 키를 제거하고 volatile-lfu는 근사 LFU를 사용하여 키 중 만료 설정이 있는 키를 제거합니다. 버전 6.2에서는 데이터 계층화에 사용하기 위해 r6gd 노드 패밀리를 제공한 경우 noeviction,volatile-lru 및 allkeys-lru 최대 메모리 정책만 r6gd 노드 유형을 통해 지원됩니다. |
**Redis OSS 4.0.10에 추가된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- |--- |--- |
| **비동기 삭제 파라미터** |
| --- |
| lazyfree-lazy-eviction | 허용되는 값: yes/no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | Performs an asynchronous delete on evictions. |
| lazyfree-lazy-expire | 허용되는 값: yes/no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | Performs an asynchronous delete on expired keys. |
| lazyfree-lazy-server-del | 허용되는 값: yes/no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | Performs an asynchronous delete for commands which update values. |
| slave-lazy-flush | 허용되는 값: N/A 기본값: 아니요 유형: boolean 수정 가능 여부: 아니요 Changes take place: N/A | Performs an asynchronous flushDB during slave sync. |
| **LFU 파라미터** |
| --- |
| lfu-log-factor | 허용되는 값: 0보다 큰 모든 정수 기본값: 10 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Set the log factor, which determines the number of key hits to saturate the key counter. |
| lfu-decay-time | 허용되는 값: 모든 정수 기본값: 1 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | The amount of time in minutes to decrement the key counter. |
| **활성 조각 모음 파라미터** |
| --- |
| activedefrag | 허용되는 값: yes/no 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 사항 적용: 즉시 | 활성 조각 모음 파라미터가 활성화됩니다. Valkey 및 Redis OSS 버전 7.0 이상에서는이 설정에 관계없이 운영상 필요한 경우 자동으로 조각 모음을 수행할AWS수 있습니다. |
| active-defrag-ignore-bytes | 허용되는 값: 10485760\$1104857600 기본값: 104857600 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Minimum amount of fragmentation waste to start active defrag. |
| active-defrag-threshold-lower | 허용되는 값: 1\$1100 기본값: 10 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Minimum percentage of fragmentation to start active defrag. |
| active-defrag-threshold-upper | 허용되는 값: 1\$1100 기본값: 100 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Maximum percentage of fragmentation at which we use maximum effort. |
| active-defrag-cycle-min | 허용되는 값: 1\$175 기본값: 25 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Minimal effort for defrag in CPU percentage. |
| active-defrag-cycle-max | 허용되는 값: 1\$175 기본값: 75 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Maximal effort for defrag in CPU percentage. |
| **클라이언트 출력 버퍼 파라미터** |
| --- |
| client-query-buffer-limit | 허용되는 값: 1048576\$11073741824 기본값: 1073741824 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Max size of a single client query buffer. |
| proto-max-bulk-len | 허용되는 값: 1048576\$1536870912 기본값: 536870912 유형: 정수 수정 가능 여부: 예 변경 사항 적용: 즉시 | Max size of a single element request. |
### Redis OSS 3.2.10 파라미터 변경 사항
**파라미터 그룹 패밀리:** redis3.2
ElastiCache for Redis OSS 3.2.10의 경우 지원되는 추가 파라미터가 없습니다.
### Redis OSS 3.2.6 파라미터 변경 사항
**파라미터 그룹 패밀리:** redis3.2
Redis OSS 3.2.6의 경우 지원되는 추가 파라미터가 없습니다.
### Redis OSS 3.2.4 파라미터 변경 사항
**파라미터 그룹 패밀리:** redis3.2
Redis OSS 3.2.4부터 기본 파라미터 그룹이 2개 있습니다.
+ `default.redis3.2` – Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹을 생성하고 Redis OSS 3.2.4의 추가 기능을 계속 사용하려면 Redis OSS 3.2.4를 실행할 때 이 파라미터 그룹 또는 그로부터 파생된 파라미터 그룹을 지정합니다.
+ `default.redis3.2.cluster.on` - Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹을 생성하려면 파라미터 그룹 또는 그로부터 파생된 파라미터 그룹을 지정합니다.
**Topics**
+ [Redis OSS 3.2.4의 새 파라미터](#ParameterGroups.Redis.3-2-4.New)
+ [Redis OSS 3.2.4(확장)에서 변경된 파라미터](#ParameterGroups.Redis.3-2-4.Changed)
#### Redis OSS 3.2.4의 새 파라미터
**파라미터 그룹 패밀리:** redis3.2
Redis OSS 3.2.4의 경우 다음과 같은 추가 파라미터가 지원됩니다.
****
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| list-max-ziplist-size | 기본값: -2 유형: 정수 수정 가능 여부: 아니요 | 목록은 공간을 절약하기 위해 특별한 방법으로 인코딩됩니다. 내부 목록 노드 당 허용되는 항목 수는 요소의 최대 수 또는 최대 고정 크기로 지정할 수 있습니다. 최대 고정 크기의 경우 -5\$1-1을 사용합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| list-compress-depth | 기본값: 0 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 목록을 압축할 수도 있습니다. 압축 깊이는 압축에서 제외할 목록 각 측면의 퀵리스트 집리스트 노드 수입니다. 목록의 헤드와 테일은 빠른 푸시 및 팝 작업을 위해 항상 압축하지 않습니다. 설정: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| cluster-enabled | 기본값: 아니요/예 \$1 유형: 문자열 수정 가능 여부: 아니요 | 클러스터 모드(yes)의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹인지 비클러스터 모드(no)의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹인지를 나타냅니다. 클러스터 모드의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 복제 그룹은 최대 500개의 노드 그룹에 데이터를 분할할 수 있습니다. \$1 Redis OSS 3.2.*x*에는 기본 파라미터 그룹 2개가 있습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html). |
| cluster-require-full-coverage | 기본값: 아니요 유형: boolean 수정 가능 여부: 예 변경 적용: 즉시 | `yes`로 설정했을 때 클러스터 모드의 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 노드는 확인되지 않은 해시 슬롯을 하나 이상 감지하면 더 이상 쿼리를 허용하지 않습니다(사용할 수 있는 노드가 없는 경우). 클러스터가 부분적으로 가동 중지되면 클러스터를 사용할 수 없게 됩니다. 모든 슬롯이 다시 확인되는 즉시 자동으로 사용할 수 있게 됩니다. 그러나 때로는 확인된 일부 키스페이스의 쿼리를 계속해서 허용하는 작업 중인 클러스터의 하위 세트가 필요합니다. 이렇게 하려면 `cluster-require-full-coverage` 옵션을 `no`로 설정합니다. |
| hll-sparse-max-bytes | 기본값: 3000 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | HyperLogLog 스파스 표현 바이트 제한입니다. 제한은 16바이트 헤더를 포함합니다. 스파스 표현을 사용하는 HyperLogLog가 이 제한을 초과하면 밀도가 높은 표현으로 변환됩니다. 그 시점에서는 밀도가 높은 표현이 메모리 효율을 높이기 때문에 16000보다 큰 값은 권장하지 않습니다. 스파스 인코딩이 너무 많은 O(N)인 PFADD를 너무 느리게 하지 않고 공간 효율적인 인코딩의 이점을 얻으려면 값을 약 3000까지로 하는 것이 좋습니다. CPU의 문제가 아니라 공백이 있고 데이터세트가 0\$115000 범위의 카디널리티(cardinality)를 가진 많은 HyperLogLog로 구성되어 있으면 값을 10000까지 올릴 수 있습니다. |
| reserved-memory-percent | 기본값: 25 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 비데이터 사용을 위해 예약된 노드의 메모리 비율입니다. 기본적으로 Redis OSS 데이터 공간은 노드의 메모리를 모두 소진할 때까지 증가합니다. 이 경우 과도한 메모리 페이징으로 인해 노드 성능이 저하될 수 있습니다. 메모리를 예약하면 페이징 양을 줄일 수 있도록 Redis OSS가 아닌 용도로 사용 가능한 메모리 일부를 구분하여 설정할 수 있습니다. 이 파라미터는 ElastiCache에 고유하며 표준 Redis OSS 배포의 일부가 아닙니다. 자세한 내용은 `reserved-memory` 및 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 섹션을 참조하세요. |
#### Redis OSS 3.2.4(확장)에서 변경된 파라미터
**파라미터 그룹 패밀리:** redis3.2
Redis OSS 3.2.4에서는 다음 파라미터가 변경되었습니다.
****
| 이름 | 세부 정보 | 변경 |
| --- | --- | --- |
| activerehashing | 수정 가능 여부: 파라미터 그룹이 클러스터와 연결되어 있지 않은 경우 yes. 그렇지 않으면 아니요입니다. | 수정 가능 여부는 '아니요'였습니다. |
| databases | 수정 가능 여부: 파라미터 그룹이 클러스터와 연결되어 있지 않은 경우 yes. 그렇지 않으면 아니요입니다. | 수정 가능 여부는 '아니요'였습니다. |
| appendonly | 기본값: 꺼짐 수정 가능 여부: 아니요 | 이전 Redis OSS 버전에서 업그레이드하려면 먼저 `appendonly`를 해제해야 합니다. |
| appendfsync | 기본값: 꺼짐 수정 가능 여부: 아니요 | 이전 Redis OSS 버전에서 업그레이드하려면 먼저 `appendfsync`를 해제해야 합니다. |
| repl-timeout | 기본값: 60 수정 가능 여부: 아니요 | 현재 기본값을 60으로 수정할 수 없습니다. |
| tcp-keepalive | 기본값: 300 | 기본값은 0입니다. |
| list-max-ziplist-entries | | 파라미터를 더 이상 사용할 수 없습니다. |
| list-max-ziplist-value | | 파라미터를 더 이상 사용할 수 없습니다. |
### Redis OSS 2.8.24(확장) 추가 파라미터
**파라미터 그룹 패밀리:** redis2.8
Redis OSS 2.8.24의 경우 지원되는 추가 파라미터가 없습니다.
### Redis OSS 2.8.23(확장) 추가 파라미터
**파라미터 그룹 패밀리:** redis2.8
Redis OSS 2.8.23의 경우 다음과 같은 추가 파라미터가 지원됩니다.
****
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| close-on-slave-write | 기본값: yes 유형: 문자열(yes/no) 수정 가능 여부: 예 변경 적용: 즉시 | 활성화하면 읽기 전용 복제본에 작성을 시도하는 클라이언트의 연결이 끊어집니다. |
#### close-on-slave-write의 작동 방식
Amazon ElastiCache가 `close-on-slave-write` 파라미터를 도입하여 읽기 복제본을 기본으로 승격시켜 프라이머리 노드 및 읽기 복제본 노드의 역할을 바꾸면 클러스터가 응답하는 방법을 보다 세부적으로 제어할 수 있도록 합니다.
![\[이미지: close-on-replica-write, 정상 작동 중\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-01.png)
다중 AZ가 활성화된 복제 그룹 장애 조치 이외의 다른 이유로 읽기 전용 복제본 클러스터가 기본으로 승격되면 클라이언트는 엔드포인트 A에 계속 쓰려고 시도합니다. 그러나 엔드포인트 A가 읽기 전용 복제본의 엔드포인트이기 때문에 쓰기가 실패합니다. ElastiCache가 `close-on-replica-write`를 도입하기 전에 Redis OSS의 동작이며 `close-on-replica-write`를 비활성화한 경우의 동작입니다.
![\[이미지: close-on-slave-write, 쓰기 실패\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-02.png)
`close-on-replica-write`를 활성화하면 클라이언트가 읽기 전용 복제본에 쓰기를 시도할 때마다 클러스터와의 클라이언트 연결이 종료됩니다. 애플리케이션 논리가 연결 해제를 감지하고 DNS 테이블을 확인한 다음 이제 기본 엔드포인트(엔드포인트 B)에 다시 연결합니다.
![\[이미지: close-on-slave-write, 새 기본 클러스터에 쓰기\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-03.png)
#### close-on-replica-write를 비활성화할 때
`close-on-replica-write`를 비활성화했는데 장애가 발생한 클러스터에 쓴 경우 `close-on-replica-write`를 비활성화하는 이유는 무엇일까요?
앞서 언급했듯이 `close-on-replica-write`를 활성화하면 클라이언트가 읽기 전용 복제본에 쓰기를 시도할 때마다 클러스터와의 클라이언트 연결이 종료됩니다. 노드에 새로운 연결을 설정하는 것은 시간이 소요됩니다. 따라서 복제본에 대한 쓰기 요청의 결과로 연결을 끊고 다시 연결하면 동일한 연결을 통해 제공되는 읽기 요청의 지연 시간에도 영향을 미칩니다. 새로운 연결이 설정될 때까지 이 영향이 그대로 유지됩니다. 애플리케이션이 특별히 읽기 중심이거나 지연 시간에 매우 민감한 경우, 읽기 성능이 저하되지 않도록 클라이언트 연결을 유지하는 것이 좋습니다.
### Redis OSS 2.8.22(확장) 추가 파라미터
**파라미터 그룹 패밀리:** redis2.8
Redis OSS 2.8.22의 경우 지원되는 추가 파라미터가 없습니다.
**중요**
Redis OSS 버전 2.8.22부터 `repl-backlog-size`가 기본 클러스터와 복제본 클러스터에 적용됩니다.
Redis OSS 버전 2.8.22부터 `repl-timeout` 파라미터를 지원하지 않습니다. 변경된 경우 `appendonly`와 같이 ElastiCache는 기본값(60초)으로 덮어씁니다.
다음 파라미터는 더 이상 지원되지 않습니다.
+ *appendonly*
+ *appendfsync*
+ *repl-timeout*
### Redis OSS 2.8.21 추가 파라미터
**파라미터 그룹 패밀리:** redis2.8
Redis OSS 2.8.21의 경우 지원되는 추가 파라미터가 없습니다.
### Redis OSS 2.8.19 추가 파라미터
**파라미터 그룹 패밀리:** redis2.8
Redis OSS 2.8.19의 경우 지원되는 추가 파라미터가 없습니다.
### Redis OSS 2.8.6 추가 파라미터
**파라미터 그룹 패밀리:** redis2.8
Redis OSS 2.8.6의 경우 다음과 같은 추가 파라미터가 지원됩니다.
****
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| min-slaves-max-lag | 기본값: 10 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 프라이머리 노드가 읽기 전용 복제본에서 핑 요청을 수신해야 하는 시간(초)입니다. 이 시간까지 프라이머리 노드가 핑을 수신하지 않으면 복제본을 더 이상 사용할 수 없는 것으로 간주합니다. 사용 가능한 복제본 수가 min-slaves-to-write 아래로 떨어지면 기본 복제본이 해당 시점에서 쓰기 허용을 중지합니다. 이 파라미터 또는 min-slaves-to-write가 0이면 사용 가능한 복제본이 없어도 프라이머리 노드가 항상 쓰기 요청을 허용합니다. |
| min-slaves-to-write | 기본값: 0 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 프라이머리 노드가 클러스터에서 쓰기를 허용하기 위해 사용 가능해야 하는 최소 읽기 전용 복제본 수입니다. 사용 가능한 복제본 수가 이 수보다 떨어지면 프라이머리 노드는 더 이상 쓰기 요청을 허용하지 않습니다. 이 파라미터 또는 min-slaves-max-lag가 0이면 사용 가능한 복제본이 없어도 프라이머리 노드가 항상 쓰기 요청을 허용합니다. |
| notify-keyspace-events | 기본값: (빈 문자열) 유형: 문자열 수정 가능 여부: 예 변경 적용: 즉시 | Redis OSS가 클라이언트에 알릴 수 있는 키스페이스 이벤트 유형입니다. 각 이벤트 유형은 한 글자로 표현됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) 이러한 이벤트 유형을 자유롭게 조합할 수 있습니다. 예를 들어, *AKE*는 Redis OSS가 모든 이벤트 유형의 알림을 게시할 수 있음을 의미합니다. 오류 메시지가 발생할 수 있으므로 위에 나열된 문자 이외의 다른 문자로 시도하지 마십시오. 기본적으로 이 파라미터는 빈 문자열로 설정되어 있습니다. 즉, 키스페이스 이벤트 알림이 비활성화되어 있습니다. |
| repl-backlog-size | 기본값: 1048576 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 프라이머리 노드 백로그 버퍼의 크기(바이트)입니다. 백로그는 프라이머리 노드의 데이터에 대한 업데이트를 레코딩하는 데 사용됩니다. 읽기 전용 복제본이 기본에 연결되면 프라이머리 노드를 따라잡기 위해 백로그에서 데이터를 적용하는 부분적 동기화(`psync`)를 수행하려고 시도합니다. `psync`가 실패하면 전체 동기화가 필요합니다. 이 파라미터의 최소값은 16384입니다. Redis OSS 2.8.22부터 이 파라미터는 기본 클러스터와 읽기 전용 복제본에 적용됩니다. |
| repl-backlog-ttl | 기본값: 3600 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 프라이머리 노드가 백로그 버퍼를 보관할 시간(초)입 니다. 마지막 복제본 노드가 연결 해제된 시점부터 백로그의 데이터는 `repl-backlog-ttl`이 만료될 때 까지 그대로 유지됩니다. 이 시간 안에 복제본이 프라이머리 노드에 연결되지 않으면 기본이 백로그 버퍼를 해제합니다. 결국 복제본이 다시 연결되면 기본과 전체 동기화를 수행해야 합니다. 파라미터를 0으로 설정하면 백로그 버퍼가 절대 해제되지 않습니다. |
| repl-timeout | 기본값: 60 유형: 정수 수정 가능 여부: 예 변경 적용: 즉시 | 다음에 대한 제한 시간(초)을 나타냅니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
### Redis OSS 2.6.13 파라미터
**파라미터 그룹 패밀리:** redis2.6
Redis OSS 2.6.13은 ElastiCache가 지원하는 Redis OSS 초기 버전이었습니다. 다음은 ElastiCache가 지원하는 Redis OSS 2.6.13 파라미터를 보여주는 표입니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html)
**참고**
Redis OSS 2.6.13 클러스터의 파라미터 그룹을 지정하지 않으면 기본 파라미터 그룹(`default.redis2.6`)이 사용됩니다. 기본 파라미터 그룹의 파라미터 값은 변경할 수 없지만 언제든지 사용자 지정 파라미터 그룹을 생성하고 클러스터에 할당할 수 있습니다.
### Redis OSS 노드 유형별 파라미터
대부분의 파라미터는 단일 값을 갖지만 일부 파라미터는 사용하는 노드 유형에 따라 다양한 값을 갖습니다. 다음 표에는 각 노드 유형에 대한 `maxmemory`, `client-output-buffer-limit-slave-hard-limit` 및 `client-output-buffer-limit-slave-soft-limit` 파라미터의 기본값이 나와 있습니다. `maxmemory`의 값은 노드에서 데이터 및 다른 용도에 사용할 수 있는 최대 바이트 수입니다. 자세한 내용은 [사용할 수 있는 메모리](https://aws.amazon.com/premiumsupport/knowledge-center/available-memory-elasticache-redis-node/)를 참조하세요.
**참고**
`maxmemory` 파라미터는 수정할 수 없습니다.
| 노드 유형 | Maxmemory | Client-output-buffer-limit-slave-hard-limit | Client-output-buffer-limit-slave-soft-limit |
| --- | --- | --- | --- |
| cache.t1.micro | 142606336 | 14260633 | 14260633 |
| cache.t2.micro | 581959680 | 58195968 | 58195968 |
| cache.t2.small | 1665138688 | 166513868 | 166513868 |
| cache.t2.medium | 3461349376 | 346134937 | 346134937 |
| cache.t3.micro | 536870912 | 53687091 | 53687091 |
| cache.t3.small | 1471026299 | 147102629 | 147102629 |
| cache.t3.medium | 3317862236 | 331786223 | 331786223 |
| cache.t4g.micro | 536870912 | 53687091 | 53687091 |
| cache.t4g.small | 1471026299 | 147102629 | 147102629 |
| cache.t4g.medium | 3317862236 | 331786223 | 331786223 |
| cache.m1.small | 943718400 | 94371840 | 94371840 |
| cache.m1.medium | 3093299200 | 309329920 | 309329920 |
| cache.m1.large | 7025459200 | 702545920 | 702545920 |
| cache.m1.xlarge | 14889779200 | 1488977920 | 1488977920 |
| cache.m2.xlarge | 17091788800 | 1709178880 | 1709178880 |
| cache.m2.2xlarge | 35022438400 | 3502243840 | 3502243840 |
| cache.m2.4xlarge | 70883737600 | 7088373760 | 7088373760 |
| cache.m3.medium | 2988441600 | 309329920 | 309329920 |
| cache.m3.large | 6501171200 | 650117120 | 650117120 |
| cache.m3.xlarge | 14260633600 | 1426063360 | 1426063360 |
| cache.m3.2xlarge | 29989273600 | 2998927360 | 2998927360 |
| cache.m4.large | 6892593152 | 689259315 | 689259315 |
| cache.m4.xlarge | 15328501760 | 1532850176 | 1532850176 |
| cache.m4.2xlarge | 31889126359 | 3188912636 | 3188912636 |
| cache.m4.4xlarge | 65257290629 | 6525729063 | 6525729063 |
| cache.m4.10xlarge | 166047614239 | 16604761424 | 16604761424 |
| cache.m5.large | 6854542746 | 685454275 | 685454275 |
| cache.m5.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m5.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m5.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m5.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m5.24xlarge | 337500562842 | 33750056284 | 33750056284 |
| cache.m6g.large | 6854542746 | 685454275 | 685454275 |
| cache.m6g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m6g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m6g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m6g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m6g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m6g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c1.xlarge | 6501171200 | 650117120 | 650117120 |
| cache.r3.large | 14470348800 | 1468006400 | 1468006400 |
| cache.r3.xlarge | 30513561600 | 3040870400 | 3040870400 |
| cache.r3.2xlarge | 62495129600 | 6081740800 | 6081740800 |
| cache.r3.4xlarge | 126458265600 | 12268339200 | 12268339200 |
| cache.r3.8xlarge | 254384537600 | 24536678400 | 24536678400 |
| cache.r4.large | 13201781556 | 1320178155 | 1320178155 |
| cache.r4.xlarge | 26898228839 | 2689822883 | 2689822883 |
| cache.r4.2xlarge | 54197537997 | 5419753799 | 5419753799 |
| cache.r4.4xlarge | 108858546586 | 10885854658 | 10885854658 |
| cache.r4.8xlarge | 218255432090 | 21825543209 | 21825543209 |
| cache.r4.16xlarge | 437021573120 | 43702157312 | 43702157312 |
| cache.r5.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r5.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r5.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r5.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r5.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r5.24xlarge | 682485973811 | 68248597381 | 68248597381 |
| cache.r6g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r6g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r6g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r6g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r6g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r6g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r6g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.r6gd.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r6gd.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r6gd.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r6gd.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r6gd.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r6gd.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.r7g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r7g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r7g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r7g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r7g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r7g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r7g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.m7g.large | 6854542746 | 685454275 | 685454275 |
| cache.m7g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m7g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m7g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m7g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m7g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m7g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c7gn.large | 3317862236 | 1403718103 | 1403718103 |
| cache.c7gn.xlarge | 6854542746 | 2826184970 | 2826184970 |
| cache.c7gn.2xlarge | 13891921715 | 5671118356 | 5671118356 |
| cache.c7gn.4xlarge | 27966669210 | 11360986522 | 11360986522 |
| cache.c7gn.8xlarge | 56116178125 | 22500037523 | 22500037523 |
| cache.c7gn.12xlarge | 84357985997 | 34120634655 | 34120634655 |
| cache.c7gn.16xlarge | 113609865216 | 45000075046 | 45000075046 |
**참고**
현재 세대의 모든 인스턴스 유형은 기본적으로 Amazon Virtual Private Cloud VPC에서 생성됩니다.
T1 인스턴스는 다중 AZ를 지원하지 않습니다.
T1 및 T2 인스턴스는 Redis OSS AOF를 지원하지 않습니다.
Redis OSS 구성 변수 `appendonly` 및 `appendfsync`는 Redis OSS 버전 2.8.22 이상에서 지원되지 않습니다.
## Memcached 특정 파라미터
**Memcached**
Memcached 클러스터에 파라미터 그룹을 지정하지 않으면 엔진 버전에 적절한 기본 파라미터 그룹이 사용됩니다. 기본 파라미터 그룹에서는 어떤 파라미터 값도 변경할 수 없습니다. 그러나 사용자 지정 파라미터 그룹을 생성하여 언제든지 클러스터에 할당할 수 있습니다. 자세한 내용은 [ElastiCache 파라미터 그룹 생성](ParameterGroups.Creating.md) 단원을 참조하십시오.
**Topics**
+ [Memcached 1.6.17 변경 사항](#ParameterGroups.Memcached.1.6.17)
+ [Memcached 1.6.6 추가 파라미터](#ParameterGroups.Memcached.1-6-6)
+ [Memcached 1.5.10 파라미터 변경](#ParameterGroups.Memcached.1-5-10)
+ [Memcached 1.4.34 추가 파라미터](#ParameterGroups.Memcached.1-4-34)
+ [Memcached 1.4.33 추가 파라미터](#ParameterGroups.Memcached.1-4-33)
+ [Memcached 1.4.24 추가 파라미터](#ParameterGroups.Memcached.1-4-24)
+ [Memcached 1.4.14 추가 파라미터](#ParameterGroups.Memcached.1-4-14)
+ [Memcached 1.4.5 지원 파라미터](#ParameterGroups.Memcached.1-4-5)
+ [Memcached 연결 오버헤드](#ParameterGroups.Memcached.Overhead)
+ [Memcached 노드 유형별 파라미터](#ParameterGroups.Memcached.NodeSpecific)
### Memcached 1.6.17 변경 사항
Memcached 1.6.17부터는 `lru_crawler`, `lru`, `slabs` 관리 명령을 더 이상 지원하지 않습니다. 이러한 변경으로 인해 런타임에 명령을 통해 `lru_crawler`를 활성화하거나 비활성화할 수 없습니다. 사용자 지정 파라미터 그룹을 수정하여 `lru_crawler`를 활성화하거나 비활성화하세요.
### Memcached 1.6.6 추가 파라미터
Memcached 1.6.6은 추가 파라미터를 지원하지 않습니다.
**파라미터 그룹 패밀리:** memcached1.6
### Memcached 1.5.10 파라미터 변경
Memcached 1.5.10은 다음과 같은 추가 파라미터가 지원됩니다.
**파라미터 그룹 Family:** memcached1.5
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| no\$1modern | 기본값: 1 유형: boolean 수정 가능 여부: 예 허용된 값: 0,1 변경 적용: 시작 시 | `slab_reassign`, `lru_maintainer_thread`, `lru_segmented` 및 `maxconns_fast` 명령을 비활성화하기 위한 별칭입니다. Memcached 1.5 이상을 사용하는 경우, `no_modern`는 해시 알고리즘도 `jenkins`로 설정합니다. 또한 Memcached 1.5.10를 사용하는 경우 `inline_ascii_reponse`는 파라미터 `parallelly`로 제어됩니다. 즉, `no_modern`이 비활성화되면 `inline_ascii_reponse`가 비활성화됩니다. Memcached 엔진 1.5.16부터 `inline_ascii_response` 파라미터가 더 이상 적용되지 않으므로 `no_modern`을 활성화하거나 비활성화해도 `inline_ascii_reponse`에 영향을 주지 않습니다. `no_modern`이 비활성화되면 `slab_reassign`, `lru_maintainer_thread`, `lru_segmented`, `maxconns_fast`가 활성화됩니다. `slab_automove` 및 `hash_algorithm` 파라미터는 SWITCH 파라미터가 아니므로 파라미터 그룹의 구성을 기반으로 설정됩니다. `no_modern`을 비활성화하고 `modern`으로 되돌리려면 사용자 지정 파라미터 그룹을 구성하여 이 파라미터를 비활성화한 다음 재부팅해야 변경 사항을 적용할 수 있습니다. 이 파라미터의 기본 구성 값은 2021년 8월 20일 현재 0에서 1로 변경되었습니다. 업데이트된 기본값은 2021년 8월 20일 이후 각 리전의 새로운 ElastiCache 사용자에 의해 자동으로 선택됩니다. 2021년 8월 20일 이전의 해당 리전에서는 기존 ElastiCache 사용자가 사용자 지정 파라미터 그룹을 수동으로 수정해야 이 새로운 변경 사항이 적용됩니다. |
| inline\$1ascii\$1resp | 기본값: 0 유형: boolean 수정 가능 여부: 예 허용된 값: 0,1 변경 적용: 시작 시 | 최대 24바이트를 사용하여 항목 내 `VALUE` 응답의 수치를 저장합니다. ASCII `get`, `faster` 세트의 속도가 약간 느려집니다. |
Memcached 1.5.10의 경우 다음과 같은 파라미터가 제거됩니다.
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| expirezero\$1does\$1not\$1evict | 기본값: 0 유형: boolean 수정 가능 여부: 예 허용된 값: 0,1 변경 적용: 시작 시 | 이 버전에서는 이제 지원하지 않습니다. |
| modern | 기본값: 1 유형: boolean 수정 가능 여부: 예(`no_modern`으로 설정하는 경우 재시작해야 함) 허용된 값: 0,1 변경 적용: 시작 시 | 이 버전에서는 이제 지원하지 않습니다. 이 버전부터는 시작할 때마다 항상 또는 재시작 시 기본적으로 `no-modern`이 활성화됩니다. |
### Memcached 1.4.34 추가 파라미터
Memcached 1.4.34는 추가 파라미터를 지원하지 않습니다.
**파라미터 그룹 패밀리:** memcached1.4
### Memcached 1.4.33 추가 파라미터
For Memcached 1.4.33은 다음과 같은 추가 파라미터가 지원됩니다.
**파라미터 그룹 패밀리:** memcached1.4
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| modern | 기본값: enabled 유형: boolean 수정 가능 여부: 예 변경 적용: 시작 시 | 여러 기능의 별칭입니다. `modern`을 활성화하는 것은 murmur3 해시 알고리즘을 사용하고 다음 명령을 사용하는 것과 같습니다. `slab_reassign`, `slab_automove`, `lru_crawler`, `lru_maintainer`, `maxconns_fast` 및 `hash_algorithm=murmur3` |
| watch | 기본값: enabled 유형: boolean 수정 가능 여부: 예 변경 적용: 즉시 사용자가 `watcher_logbuf_size` 및 `worker_logbuf_size` 한도에 도달하면 로그가 삭제될 수 있습니다. | 로그 가져오기, 제거 또는 변형. 예를 들어 사용자가 `watch`를 켜면 `get`, `set`, `delete` 또는 `update` 발생 시 로그를 볼 수 있습니다. |
| idle\$1timeout | 기본값: 0(비활성화) 유형: 정수 수정 가능 여부: 예 변경 적용: 시작 시 | 종료하라는 메시지가 표시되기 전에 클라이언트가 유휴 상태로 있을 수 있는 최소 시간(초)입니다. 값의 범위는 0\$186400입니다. |
| track\$1sizes | 기본값: 비활성화 유형: boolean 수정 가능 여부: 예 변경 적용: 시작 시 | 슬래브 그룹이 소비한 크기를 표시합니다. `track_sizes`를 활성화하면 `stats sizes_enable`을 실행할 필요 없이 `stats sizes`를 실행할 수 있습니다. |
| watcher\$1logbuf\$1size | 기본값: 256(KB) 유형: 정수 수정 가능 여부: 예 변경 적용: 시작 시 | `watch` 명령은 Memcached에 대한 스트림 로깅을 켭니다. 그러나 로깅 버퍼가 가득 찰 정도로 제거, 변형 또는 가져오기 비율이 높은 경우 `watch`에서 로그를 삭제할 수 있습니다. 이러한 상황에서 사용자는 로그 손실을 줄이기 위해 버퍼 크기를 늘릴 수 있습니다. |
| worker\$1logbuf\$1size | 기본값: 64(KB) 유형: 정수 수정 가능 여부: 예 변경 적용: 시작 시 | `watch` 명령은 Memcached에 대한 스트림 로깅을 켭니다. 그러나 버퍼가 가득 찰 정도로 제거, 변형 또는 가져오기 비율이 높으면 `watch`는 로그를 삭제할 수 있습니다. 이러한 상황에서 사용자는 로그 손실을 줄이기 위해 버퍼 크기를 늘릴 수 있습니다. |
| slab\$1chunk\$1max | 기본값: 524288(바이트) 유형: 정수 수정 가능 여부: 예 변경 적용: 시작 시 | 슬래브의 최대 크기를 지정합니다. 슬래브 크기를 작게 설정하면 메모리를 더 효율적으로 사용합니다. `slab_chunk_max`보다 큰 항목은 여러 슬래브로 분할됩니다. |
| lru\$1crawler metadump [all\$11\$12\$13] | 기본값: 비활성화 유형: boolean 수정 가능 여부: 예 변경 적용: 즉시 | lru\$1crawler를 활성화하면 이 명령이 모든 키를 덤프합니다. `all\|1\|2\|3` - 모든 슬래브 또는 특정 슬래브 수 지정 |
### Memcached 1.4.24 추가 파라미터
Memcached 1.4.24는 다음과 같은 추가 파라미터가 지원됩니다.
**파라미터 그룹 패밀리:** memcached1.4
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| disable\$1flush\$1all | 기본값: 0(비활성화) 유형: boolean 수정 가능 여부: 예 변경 적용: 시작 시 | flush\$1all을 비활성화하려면 파라미터(`-F`)를 추가합니다. 프로덕션 인스턴스에서 전체 플러시를 실행할 수 없는 경우에 유용합니다. 값은 0, 1(값이 0일 때 사용자가 `flush_all`을 수행할 수 있음)입니다. |
| hash\$1algorithm | 기본값: jenkins 유형: 문자열 수정 가능 여부: 예 변경 적용: 시작 시 | 사용할 해시 알고리즘입니다. 허용되는 값은 murmur3 및 jenkins입니다. |
| lru\$1crawler | 기본값: 0(비활성화) 유형: boolean 수정 가능 여부: 예 변경 적용: 재시작 후 런타임 시 명령줄에서 `lru_crawler`를 일시적으로 활성화할 수 있습니다. 자세한 내용은 설명 열을 참조하세요. | 만료된 항목의 슬래브 클래스를 삭제합니다. 백그라운드에서 실행되는 영향이 적은 프로세스입니다. 현재는 수동 명령을 사용하여 크롤링을 시작해야 합니다. 일시적으로 활성화하려면 명령줄에서 `lru_crawler enable`을 실행합니다. `lru_crawler 1,3,5`는 슬래브 클래스 1, 3 및 5를 크롤링하여 freelist에 추가할 만료 항목을 찾습니다. 값: 0,1 명령줄에서 `lru_crawler`를 활성화하면 명령줄에서 비활성화하거나 다음에 재부팅될 때까지 크롤러가 활성화됩니다. 영구적으로 활성화하려면 파라미터 값을 수정해야 합니다. 자세한 내용은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md) 단원을 참조하십시오. |
| lru\$1maintainer | 기본값: 0(비활성화) 유형: boolean 수정 가능 여부: 예 변경 적용: 시작 시 | 용량에 도달할 때 LRU 간에 항목을 셔플링한 백그라운드 스레드입니다. 값: 0, 1 |
| expirezero\$1does\$1not\$1evict | 기본값: 0(비활성화) 유형: boolean 수정 가능 여부: 예 변경 적용: 시작 시 | `lru_maintainer`와 함께 사용하면 만료 시간이 0인 항목을 제거할 수 없게 합니다. 기타 제거할 수 있는 항목에 사용 가능한 메모리를 밀어낼 수 있습니다. `lru_maintainer`를 무시하도록 설정할 수 있습니다. |
### Memcached 1.4.14 추가 파라미터
Memcached 1.4.14는 다음과 같은 추가 파라미터가 지원됩니다.
**파라미터 그룹 패밀리:** memcached1.4
**Memcached 1.4.14에 추가된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| config\$1max | 기본값: 16 유형: 정수 수정 가능 여부: 아니요 | ElastiCache 구성 항목의 최대 수입니다. |
| config\$1size\$1max | 기본값: 65536 유형: 정수 수정 가능 여부: 아니요 | 구성 항목의 최대 크기(바이트)입니다. |
| hashpower\$1init | 기본값: 16 유형: 정수 수정 가능 여부: 아니요 | ElastiCache 해시 테이블의 처음 크기이며 2의 거듭 제곱으로 표시됩니다. 기본값은 16(2^16) 또는 65536 키입니다. |
| maxconns\$1fast | 기본값: 0(false) 유형: 부울 수정 가능 여부: 예 변경 적용: 재시작 후 | 최대 연결 한도에 도달했을 때 새 연결 요청을 처리하는 방식을 변경합니다. 이 파라미터를 0으로 설정하면 새 연결이 백로그 대기열에 추가되고 다른 연결이 끊길 때까지 대기합니다. 파라미터를 1로 설정하면 ElastiCache가 클라이언트에 오류를 전송하고 즉시 연결을 끊습니다. |
| slab\$1automove | 기본값: 0 유형: 정수 수정 가능 여부: 예 변경 적용: 재시작 후 | 슬래브 오토무브 알고리즘을 조정합니다. 이 파라미터를 0(영)으로 설정하면 오토무브 알고리즘이 비활성화됩니다. 1로 설정하면 ElastiCache가 자동으로 슬래브를 이동하는 데 느리고 보수적인 접근 방식을 취합니다. 2로 설정하면 제거할 때마다 ElastiCache가 적극적으로 슬래브를 이동합니다. (이 모드는 테스트 목적을 제외하고는 권장되지 않음) |
| slab\$1reassign | 기본값: 0(false) 유형: 부울 수정 가능 여부: 예 변경 적용: 재시작 후 | 슬래브 재할당을 활성화하거나 비활성화합니다. 이 파라미터를 1로 설정하면 "슬래브 재할당" 명령을 사용하여 메모리를 수동으로 재할당할 수 있습니다. |
### Memcached 1.4.5 지원 파라미터
**파라미터 그룹 패밀리:** memcached1.4
Memcached 1.4.5는 다음과 같은 파라미터를 지원합니다.
**Memcached 1.4.5에 추가된 파라미터**
| 이름 | 세부 정보 | 설명 |
| --- | --- | --- |
| backlog\$1queue\$1limit | 기본값: 1024 유형: 정수 수정 가능 여부: 아니요 | 백 로그 대기열 제한입니다. |
| binding\$1protocol | 기본값: 자동 유형: 문자열 수정 가능 여부: 예 변경 적용: 재시작 후 | 바인딩 프로토콜입니다.허용 가능한 값은 `ascii` 및 `auto`입니다. `binding_protocol`의 값을 수정하는 방법에 대한 지침은 [ElastiCache 파라미터 그룹 수정](ParameterGroups.Modifying.md)을 참조하세요. |
| cas\$1disabled | 기본값: 0(false) 유형: 부울 수정 가능 여부: 예 변경 적용: 재시작 후 | 1(true)이면 확인 및 설정(CAS) 작업이 비활성화되고 저장된 항목이 CAS가 활성화된 경우보다 8바이트 적게 소비합니다. |
| chunk\$1size | 기본값: 48 유형: 정수 수정 가능 여부: 예 변경 적용: 재시작 후 | 가장 작은 항목의 키, 값 및 플래그에 할당할 공간의 최소 크기(바이트)입니다. |
| chunk\$1size\$1growth\$1factor | 기본값: 1.25 유형: float 수정 가능 여부: 예 변경 적용: 재시작 후 | 연속된 Memcached 청크 크기를 제어하는 성장 인자입니다. 각 청크는 이전 청크보다 chunk\$1size\$1growth\$1factor배 더 큽니다. |
| error\$1on\$1memory\$1exhausted | 기본값: 0(false) 유형: 부울 수정 가능 여부: 예 변경 적용: 재시작 후 | 1(true)이면 항목을 저장할 메모리가 없으면 Memcached가 항목을 제거하는 대신 오류를 반환합니다. |
| large\$1memory\$1pages | 기본값: 0(false) 유형: Boolean 수정 가능 여부: 아니요 | 1(true)이면 ElastiCache가 더 큰 메모리 페이지를 사용하고자 합니다. |
| lock\$1down\$1paged\$1memory | 기본값: 0(false) 유형: Boolean 수정 가능 여부: 아니요 | 1(true)이면 ElastiCache가 페이징된 모든 메모리를 잠급니다. |
| max\$1item\$1size | 기본값: 1048576 유형: 정수 수정 가능 여부: 예 변경 적용: 재시작 후 | 클러스터에 저장할 수 있는 가장 큰 항목의 크기(바이트)입니다. |
| max\$1simultaneous\$1connections | 기본값: 65000 유형: 정수 수정 가능 여부: 아니요 | 최대 동시 연결 수입니다. |
| maximize\$1core\$1file\$1limit | 기본값: 0(false) 유형: Boolean 수정 가능: 변경 적용: 재시작 후 | 1(true)이면 ElastiCache가 핵심 파일 제한을 최대화합니다. |
| memcached\$1connections\$1overhead | 기본값: 100 유형: 정수 수정 가능 여부: 예 변경 적용: 재시작 후 | Memcached 연결 및 기타 오버헤드에 예약된 메모리 양입니다. 이 파라미터에 대한 자세한 정보는 [Memcached 연결 오버헤드](#ParameterGroups.Memcached.Overhead)를 참조하세요. |
| requests\$1per\$1event | 기본값: 20 유형: 정수 수정 가능 여부: 아니요 | 지정된 연결의 이벤트 당 최대 요청 수입니다. 이 제한은 리소스 결핍을 막기 위해 필요합니다. |
### Memcached 연결 오버헤드
각 노드에서 항목을 저장하는 데 사용할 수 있는 메모리는 `max_cache_memory` 파라미터에 저장된 해당 노드의 총 사용 가능한 메모리에서 `memcached_connections_overhead` 파라미터에 저장된 연결에 사용하는 메모리와 기타 오버헤드를 뺀 값입니다. 예를 들어, `cache.m1.small` 유형의 노드에는 1300MB의 `max_cache_memory`가 있습니다. 기본 `memcached_connections_overhead` 값이 100MB이면 Memcached 프로세스는 항목을 저장하는 데 1200MB를 사용할 수 있습니다.
`memcached_connections_overhead` 파라미터의 기본값은 대부분의 사용 사례를 충족시키지만 연결 오버헤드에 필요한 할당량은 요청 빈도, 페이로드 크기 및 연결 수를 비롯한 여러 요소에 따라 달라질 수 있습니다.
애플리케이션에 맞게 `memcached_connections_overhead` 값을 변경할 수 있습니다. 예를 들어, `memcached_connections_overhead` 파라미터 값을 높이면 항목을 저장하는 데 사용할 수 있는 메모리 양이 줄어들어 연결 오버헤드에 더 큰 버퍼가 제공됩니다. `memcached_connections_overhead` 파라미터 값을 줄이면 항목을 저장하는 데 더 많은 메모리를 사용할 수 있지만 스왑 사용량 및 성능 저하 위험이 높아질 수 있습니다. 스왑 사용량이 늘고 성능 저하가 발생하면 `memcached_connections_overhead` 파라미터 값을 늘립니다.
**중요**
`cache.t1.micro` 노드 유형의 경우 `memcached_connections_overhead` 값은 다음과 같이 결정됩니다.
클러스터가 기본 파라미터 그룹을 사용하면 ElastiCache는 `memcached_connections_overhead` 값을 13MB로 설정합니다.
클러스터가 사용자가 직접 생성한 파라미터 그룹을 사용하면 `memcached_connections_overhead` 값을 원하는 대로 설정할 수 있습니다.
### Memcached 노드 유형별 파라미터
대부분의 파라미터는 단일 값을 갖지만 일부 파라미터는 사용하는 노드 유형에 따라 다양한 값을 갖습니다. 다음 표에는 각 노드 유형에 대한 `max_cache_memory` 및 `num_threads` 파라미터의 기본값이 나와 있습니다. 이 파라미터의 값은 수정할 수 없습니다.
| 노드 유형 | max\$1cache\$1memory(MB) | num\$1threads |
| --- | --- | --- |
| cache.t1.micro | 213 | 1 |
| cache.t2.micro | 555 | 1 |
| cache.t2.small | 1588 | 1 |
| cache.t2.medium | 3301 | 2 |
| cache.t3.micro | 512 | 2 |
| cache.t3.small | 1402 | 2 |
| cache.t3.medium | 3364 | 2 |
| cache.t4g.micro | 512 | 2 |
| cache.t4g.small | 1402 | 2 |
| cache.t4g.medium | 3164 | 2 |
| cache.m1.small | 1301 | 1 |
| cache.m1.medium | 3350 | 1 |
| cache.m1.large | 7100 | 2 |
| cache.m1.xlarge | 14600 | 4 |
| cache.m2.xlarge | 33800 | 2 |
| cache.m2.2xlarge | 30412 | 4 |
| cache.m2.4xlarge | 68000 | 16 |
| cache.m3.medium | 2850 | 1 |
| cache.m3.large | 6200 | 2 |
| cache.m3.xlarge | 13600 | 4 |
| cache.m3.2xlarge | 28600 | 8 |
| cache.m4.large | 6573 | 2 |
| cache.m4.xlarge | 11496 | 4 |
| cache.m4.2xlarge | 30412 | 8 |
| cache.m4.4xlarge | 62234 | 16 |
| cache.m4.10xlarge | 158355 | 40 |
| cache.m5.large | 6537 | 2 |
| cache.m5.xlarge | 13248 | 4 |
| cache.m5.2xlarge | 26671 | 8 |
| cache.m5.4xlarge | 53516 | 16 |
| cache.m5.12xlarge | 160900 | 48 |
| cache.m5.24xlarge | 321865 | 96 |
| cache.m6g.large | 6537 | 2 |
| cache.m6g.xlarge | 13248 | 4 |
| cache.m6g.2xlarge | 26671 | 8 |
| cache.m6g.4xlarge | 53516 | 16 |
| cache.m6g.8xlarge | 107000 | 32 |
| cache.m6g.12xlarge | 160900 | 48 |
| cache.m6g.16xlarge | 214577 | 64 |
| cache.c1.xlarge | 6600 | 8 |
| cache.r3.large | 13800 | 2 |
| cache.r3.xlarge | 29100 | 4 |
| cache.r3.2xlarge | 59600 | 8 |
| cache.r3.4xlarge | 120600 | 16 |
| cache.r3.8xlarge | 120600 | 32 |
| cache.r4.large | 12590 | 2 |
| cache.r4.xlarge | 25652 | 4 |
| cache.r4.2xlarge | 51686 | 8 |
| cache.r4.4xlarge | 103815 | 16 |
| cache.r4.8xlarge | 208144 | 32 |
| cache.r4.16xlarge | 416776 | 64 |
| cache.r5.large | 13387 | 2 |
| cache.r5.xlarge | 26953 | 4 |
| cache.r5.2xlarge | 54084 | 8 |
| cache.r5.4xlarge | 108347 | 16 |
| cache.r5.12xlarge | 325400 | 48 |
| cache.r5.24xlarge | 650869 | 96 |
| cache.r6g.large | 13387 | 2 |
| cache.r6g.xlarge | 26953 | 4 |
| cache.r6g.2xlarge | 54084 | 8 |
| cache.r6g.4xlarge | 108347 | 16 |
| cache.r6g.8xlarge | 214577 | 32 |
| cache.r6g.12xlarge | 325400 | 48 |
| cache.r6g.16xlarge | 429154 | 64 |
| cache.c7gn.large | 3164 | 2 |
| cache.c7gn.xlarge | 6537 | 4 |
| cache.c7gn.2xlarge | 13248 | 8 |
| cache.c7gn.4xlarge | 26671 | 16 |
| cache.c7gn.8xlarge | 53516 | 32 |
| cache.c7gn.12xlarge | 325400 | 48 |
| cache.c7gn.16xlarge | 108347 | 64 |
**참고**
모든 T2 인스턴스는 Amazon Virtual Private Cloud(Amazon VPC)에서 생성됩니다.
# EC2 인스턴스 및 ElastiCache 캐시 자동 연결
ElastiCache 콘솔을 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 ElastiCache 캐시 간의 연결 설정을 간소화할 수 있습니다. 캐시는 프라이빗 서브넷에 있고, EC2 인스턴스는 VPC 내의 퍼블릭 서브넷에 있는 경우가 많습니다. EC2 인스턴스의 SQL 클라이언트를 사용하여 ElastiCache 캐시에 연결할 수 있습니다. EC2 인스턴스는 프라이빗 ElastiCache 캐시에 액세스하는 웹 서버 또는 애플리케이션을 실행할 수도 있습니다.
![\[EC2 인스턴스 및 ElastiCache 캐시를 자동으로 연결합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ec2-elasticache-connect-network_diagram.png)
**Topics**
+ [EC2 인스턴스와의 자동 연결성](#ec2-elc-connect-overview)
+ [연결된 컴퓨팅 리소스 보기](#ec2-elc-connect-viewing)
## EC2 인스턴스와의 자동 연결성
EC2 인스턴스와 ElastiCache 캐시 간의 연결을 설정하면 ElastiCache는 EC2 인스턴스 및 ElastiCache 캐시에 대한 VPC 보안 그룹을 자동으로 구성합니다.
다음은 EC2 인스턴스를 ElastiCache 캐시에 연결하기 위한 요구 사항입니다.
+ EC2 인스턴스는 ElastiCache 캐시와 동일한 VPC에 있어야 합니다.
EC2 인스턴스가 동일한 VPC에 없는 경우 콘솔은 EC2 인스턴스를 생성하기 위한 링크를 제공합니다.
+ 연결을 설정하는 사용자는 다음 Amazon EC2 작업을 수행할 수 있는 권한이 있어야 합니다. 이러한 권한은 일반적으로 생성 시 EC2 계정에 추가됩니다. EC2 권한에 대한 자세한 내용은 [Amazon EC2 리소스를 위해 필요한 권한 부여](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html) 섹션을 참조하세요.
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeSecurityGroups`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
EC2 인스턴스에 대한 연결을 설정하면 ElastiCache는 다음 테이블에 설명된 대로 ElastiCache 캐시 및 EC2 인스턴스와 연결된 보안 그룹의 현재 구성을 기반으로 조치를 취합니다.
****
| 현재 ElastiCache 보안 그룹 구성 | 현재 EC2 보안 그룹 구성 | ElastiCache 작업 |
| --- | --- | --- |
| 이름이 `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하며 ElastiCache 캐시와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 포함됩니다. | `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하는 이름을 가진 EC2 인스턴스와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 ElastiCache 캐시의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙이 하나만 포함됩니다. | ElastiCache는 아무런 조치도 취하지 않습니다. EC2 인스턴스와 ElastiCache 캐시 간의 연결이 이미 자동으로 구성되었습니다. EC2 인스턴스와 ElastiCache 캐시 사이에 이미 연결이 존재하기 때문에 보안 그룹은 수정되지 않습니다. |
| 다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/compute-connection.html) | 다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/compute-connection.html) | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| 이름이 `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하며 ElastiCache 캐시와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 포함됩니다. | `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하는 이름을 가진 EC2 인스턴스와 연결된 보안 그룹이 하나 이상 있습니다. 그러나 ElastiCache는 ElastiCache 캐시와의 연결에 이러한 보안 그룹을 사용할 수 없습니다. ElastiCache는 ElastiCache 캐시의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. ElastiCache는 또한 수정된 보안 그룹을 사용할 수 없습니다. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| 이름이 `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하며 ElastiCache 캐시와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 포함됩니다. | 연결에 유효한 EC2 보안 그룹이 있지만 EC2 인스턴스와 연결되어 있지 않습니다. 이 보안 그룹의 이름이 `ec2-elasticache-${ec2InstanceId}:${cacheId}` 패턴과 일치합니다. 수정되지 않았습니다. 여기에는 ElastiCache 캐시의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙이 하나만 포함됩니다. | [ELC action: associate EC2 security group](#elc-action-associate-ec2-security-group) |
| 다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/compute-connection.html) | `ec2-elasticache-${ec2InstanceId}:${cacheId}` 패턴과 일치하는 이름을 가진 EC2 인스턴스와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 ElastiCache 캐시의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙이 하나만 포함됩니다. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
**ElastiCache 작업: 새 보안 그룹 생성**
ElastiCache는 다음 작업을 수행합니다.
+ `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나 포함됩니다. 이 보안 그룹은 ElastiCache 캐시와 연결되어 EC2 인스턴스가 캐시에 액세스할 수 있도록 허용합니다.
+ `elasticache-ec2-${cacheId}:${ec2InstanceId}` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 ElastiCache 캐시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙이 하나만 포함됩니다. 이 보안 그룹은 EC2 인스턴스와 연결되어 있으며 EC2 인스턴스가 ElastiCache 캐시에 트래픽을 보내도록 허용합니다.
**ElastiCache 작업: EC2 보안 그룹 연결**
ElastiCache는 유효한 기존 EC2 보안 그룹을 EC2 인스턴스와 연결합니다. 이 보안 그룹을 사용하면 EC2 인스턴스가 ElastiCache 캐시로 트래픽을 보낼 수 있습니다.
## 연결된 컴퓨팅 리소스 보기
AWS Management Console을 사용하여 ElastiCache 캐시에 연결된 컴퓨팅 리소스를 볼 수 있습니다. 표시되는 리소스에는 자동으로 설정된 컴퓨팅 리소스 연결이 포함됩니다. 예를 들어 캐시와 연결된 VPC 보안 그룹에 규칙을 추가하여 컴퓨팅 리소스가 캐시에 수동으로 액세스하도록 허용할 수 있습니다. 이러한 리소스는 연결된 컴퓨팅 리소스 목록에 표시되지 않습니다.
컴퓨팅 리소스를 나열하려면 EC2 인스턴스와 ElastiCache 캐시를 자동으로 연결할 때와 동일한 조건이 적용되어야 합니다.
**ElastiCache 캐시에 연결된 컴퓨팅 리소스를 보려면**
1. AWS Management Console에 로그인하고 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **캐시**를 선택한 다음 Valkey 또는 Redis OSS 캐시를 선택합니다.
1. **연결 및 보안** 탭의 **컴퓨팅 연결 설정**에서 컴퓨팅 리소스를 확인합니다.
![\[연결된 컴퓨팅 리소스.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ec2-elasticache-connected_resources.png)
# ElastiCache 규모 조정
ElastiCache 캐시의 규모를 필요에 맞게 조정할 수 있습니다. 서버리스 캐시와 노드 기반 클러스터는 다양한 규모 조정 옵션을 제공합니다.
## ElastiCache 서버리스 규모 조정
ElastiCache 서버리스는 워크로드 트래픽이 증가하거나 감소할 때 워크로드 트래픽을 자동으로 수용합니다. 각 ElastiCache 서버리스 캐시에서 ElastiCache는 CPU, 메모리 및 네트워크 등의 리소스 사용률을 지속적으로 추적합니다. 이러한 리소스가 제한되면 ElastiCache 서버리스는 애플리케이션을 가동 중지하지 않고 새 샤드를 추가하고 새 샤드에 데이터를 재배포하여 스케일 아웃합니다. 캐시 데이터 스토리지의 `BytesUsedForCache` 지표와 컴퓨팅 사용량(ECPU)의 `ElastiCacheProcessingUnits`를 모니터링하여 CloudWatch에서 캐시가 사용하는 리소스를 모니터링할 수 있습니다.
## 비용 관리를 위한 규모 조정 한도 설정
캐시 데이터 스토리지와 초당 ECPU의 최대 사용량을 모두 구성하여 캐시 비용을 제어할 수 있습니다. 이렇게 하면 캐시 사용량이 구성된 최댓값을 초과하지 않도록 할 수 있습니다.
규모 조정 최댓값을 설정하면 캐시가 최댓값에 도달할 경우 애플리케이션의 캐시 성능이 저하될 수 있습니다. 캐시 데이터 스토리지의 최댓값을 설정하고 캐시 데이터 스토리지가 최댓값에 도달하면 ElastiCache는 LRU 로직을 사용하여 Time-To-Live(TTL)가 설정된 캐시에서 데이터를 제거하기 시작합니다. 제거할 수 있는 데이터가 없는 경우 추가 데이터 쓰기를 요청하면 메모리 부족(OOM) 오류 메시지가 표시됩니다. 초당 최대 ECPU를 설정하고 워크로드의 컴퓨팅 사용률이 이 값을 초과하면 ElastiCache는 요청을 스로틀링하기 시작합니다.
`BytesUsedForCache` 또는 `ElastiCacheProcessingUnits`에 최대 한도를 설정하는 경우 최대 한도보다 낮은 값으로 CloudWatch 경보를 설정하여 캐시가 이러한 한도에 근접하게 작동할 때 알림을 받을 수 있도록 하는 것이 좋습니다. 설정한 최대 한도의 75%로 경보를 설정하는 것이 좋습니다. CloudWatch 경보를 설정하는 방법은 설명서를 참조하세요.
## ElastiCache Serverless를 사용한 사전 규모 조정
**ElastiCache 서버리스 사전 규모 조정**
예열이라고도 하는 사전 규모 조정을 사용하면 ElastiCache 캐시에 지원되는 최소 제한을 설정할 수 있습니다. 초당 ElastiCache 처리 단위(ECPUs) 또는 데이터 스토리지에 대해 이러한 최소값을 설정할 수 있습니다. 이는 예상 조정 이벤트를 준비하는 데 유용할 수 있습니다. 예를 들어 게임 회사가 새 게임이 시작되는 첫 1분 내에 로그인이 5배 증가할 것으로 예상하는 경우 이러한 상당한 사용량 증가에 대해 캐시를 준비할 수 있습니다.
ElastiCache 콘솔, CLI 또는 API를 사용하여 사전 규모 조정을 수행할 수 있습니다. ElastiCache Serverless는 60분 이내에 캐시에서 사용 가능한 ECPUs초를 업데이트하고 최소 한도 업데이트가 완료되면 이벤트 알림을 보냅니다.
**사전 규모 조정 작동 방식**
콘솔, CLI 또는 API를 통해 초당 ECPUs 또는 데이터 스토리지의 최소 한도가 업데이트되면 1시간 이내에 새 한도를 사용할 수 있습니다. ElastiCache 서버리스는 빈 캐시에서 초당 30K ECPUs를 지원하고 복제본에서 읽기 기능을 사용할 때는 초당 최대 90K ECPUs를 지원합니다. Valkey 8.0용 ElastiCache Serverless는 2\$13분마다 지원되는 초당 요청 수(RPS)를 두 배로 늘려 13분 이내에 캐시당 5M RPS에 도달할 수 있으며, 밀리초 미만의 일관된 p50 읽기 지연 시간을 제공합니다. 예정된 규모 조정 이벤트가 이 속도를 초과할 수 있다고 예상되는 경우, 최소 ECPUs/초를 최대 이벤트 최소 60분 전에 예상되는 최대 ECPUs/초로 설정하는 것이 좋습니다. 그렇지 않으면 애플리케이션의 지연 시간과 요청 스로틀링이 증가할 수 있습니다.
최소 한도 업데이트가 완료되면 ElastiCache 서버리스는 초당 새 최소 ECPUs 또는 새 최소 스토리지에 대한 측정을 시작합니다. 이는 애플리케이션이 캐시에서 요청을 실행하지 않거나 데이터 스토리지 사용량이 최소값 미만인 경우에도 발생합니다. 현재 설정에서 최소 제한을 낮추면 업데이트가 즉시 이루어지므로 ElastiCache 서버리스는 새 최소 제한에서 즉시 측정이 시작됩니다.
**참고**
최소 사용량 한도를 설정하면 실제 사용량이 최소 사용량 한도보다 낮더라도 해당 한도에 대한 요금이 부과됩니다. 최소 사용량 제한을 초과하는 ECPU 또는 데이터 스토리지 사용량에는 정규 요금이 부과됩니다. 예를 들어 초당 100,000 ECPUs의 최소 사용량 제한을 설정하면 사용량이 최소 설정보다 낮더라도 시간당 최소 미화 1.224달러( us-east-1의 ECPU 요금 사용)가 부과됩니다.
ElastiCache 서버리스는 캐시의 집계 수준에서 요청된 최소 규모를 지원합니다. 또한 ElastiCache Serverless는 슬롯당 최대 30K ECPUs/초(READONLY 연결을 사용하여 복제본에서 읽기를 사용하는 경우 90K ECPUs/초)를 지원합니다. 모범 사례로, 애플리케이션은 Valkey 또는 Redis OSS 슬롯 전반의 키 분배와 키 간 트래픽이 가능한 한 균일하게 이루어지도록 해야 합니다.
## 콘솔 및를 사용하여 조정 제한 설정AWS CLI
*AWS콘솔을 사용하여 조정 제한 설정*
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서, 수정하려는 캐시에서 실행하는 엔진을 선택합니다.
1. 선택한 엔진을 실행하는 캐시 목록이 표시됩니다.
1. 캐시 이름 왼쪽에 있는 라디오 버튼을 선택하여 수정할 캐시를 선택합니다.
1. **작업**을 선택한 다음 **수정**을 선택합니다.
1. **사용 한도**에서 적절한 **메모리** 또는 **컴퓨팅** 한도를 설정합니다.
1. 변경 사항 **미리보기**를 클릭한 다음 변경 사항 **저장**을 클릭합니다.
**를 사용하여 조정 제한 설정AWS CLI**
CLI를 사용하여 규모 조정 제한을 변경하려면 modify-serverless-cache API를 사용합니다.
**Linux**:
```
aws elasticache modify-serverless-cache --serverless-cache-name \
--cache-usage-limits 'DataStorage={Minimum=10,Maximum=100,Unit=GB}, ECPUPerSecond={Minimum=1000,Maximum=100000}'
```
**Windows**:
```
aws elasticache modify-serverless-cache --serverless-cache-name ^
--cache-usage-limits 'DataStorage={Minimum=10,Maximum=100,Unit=GB}, ECPUPerSecond={Minimum=1000,Maximum=100000}'
```
**CLI를 사용하여 규모 조정 제한 제거**
CLI를 사용하여 규모 조정 제한을 제거하려면 최소 및 최대 제한 파라미터를 0으로 설정합니다.
**Linux**:
```
aws elasticache modify-serverless-cache --serverless-cache-name \
--cache-usage-limits 'DataStorage={Minimum=0,Maximum=0,Unit=GB}, ECPUPerSecond={Minimum=0,Maximum=0}'
```
**Windows**:
```
aws elasticache modify-serverless-cache --serverless-cache-name ^
--cache-usage-limits 'DataStorage={Minimum=0,Maximum=0,Unit=GB}, ECPUPerSecond={Minimum=0,Maximum=0}'
```
# 노드 기반 클러스터 조정
애플리케이션에서 처리해야 하는 데이터의 양은 거의 정적이 아닙니다. 비즈니스가 성장하거나 수요에서 일반적인 변동을 경험할 경우, 데이터의 양이 증가하거나 감소합니다. 캐시를 자체적으로 관리할 경우 최고의 수요에 대해 충분한 하드웨어를 프로비저닝해야 하므로, 비용이 많이 들 수 있습니다. Amazon ElastiCache를 사용하면 현재 수요에 맞게 조정할 수 있어, 사용한 만큼만 요금을 지불할 수 있습니다. ElastiCache를 통해 수요에 맞게 캐시 크기를 조정할 수 있습니다.
**참고**
Valkey 또는 Redis OSS 클러스터가 하나 이상의 리전에 복제되는 경우 해당 리전은 순서대로 조정됩니다. 스케일 업 시 보조 리전은 먼저 조정된 다음 기본 리전이 조정됩니다. 스케일 다운 시 기본 리전이 먼저 조정되고 그 다음 보조 리전이 조정됩니다.
엔진 버전을 업데이트할 때 순서는 보조 리전과 그 다음 기본 리전 순입니다.
**Topics**
+ [Memcached의 클러스터의 온디맨드 스케일링](Scaling-self-designed.mem-heading.md)
+ [Memcached 클러스터의 수동 규모 조정](Scaling.Memcached.manually.md)
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 클러스터 규모 조정](scaling-redis-classic.md)
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 복제본 노드 규모 조정](Scaling.RedisReplGrps.md)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md)
# Memcached의 클러스터의 온디맨드 스케일링
ElastiCache for Memcached는AWS클라우드에서 Memcached를 배포, 운영 및 수직 확장하는 완전 관리형 인 메모리 캐싱 서비스를 제공합니다.
**온디맨드 수직적 스케일링**
수직적 스케일링을 통해 ElastiCache for Memcached는 데이터베이스 로드를 완화하여 동적 애플리케이션의 속도를 높이는 데 널리 사용되는 고성능 분산 메모리 캐싱 시스템을 제공합니다. RAM에 데이터와 객체를 저장하므로 외부 데이터 소스에서 읽을 필요가 줄어듭니다.
기존 노드 기반 클러스터와 새 클러스터에 수직적 스케일링을 적용할 수 있습니다. 이를 통해 리소스 할당의 유연성을 제공하여 사용자가 클러스터 아키텍처를 변경하지 않고도 변화하는 워크로드에 효율적으로 적응할 수 있습니다. 이러한 규모 조정 기능은 수요가 많은 기간에는 캐시 용량을 늘리고 수요가 적은 기간에는 비용을 최적화하도록 스케일 다운하여 성능을 개선합니다. 이렇게 하면 작업이 간소화되고, 리소스 요구 사항을 이동하기 위해 새 클러스터를 생성할 필요가 없으며, 트래픽 변동에 신속하게 대응할 수 있습니다. 전반적으로 Memcached 노드 기반 클러스터의 수직적 스케일링은 비용 효율성을 높이고 리소스 사용률을 개선하며 사용자가 Memcached 인스턴스 유형을 변경하도록 하는 데 도움이 될 수 있습니다. 이를 통해 사용자는 실제 애플리케이션 요구 사항에 맞게 캐싱 인프라를 더 쉽게 조정할 수 있습니다.
**참고**
노드 유형 수정은 엔진 버전이 1.5 이상인 노드 기반 Memcached 클러스터에서만 사용할 수 있습니다.
수직적 스케일링을 사용하려면 자동 검색을 활성화해야 합니다.
## 노드 기반 Memcached 클러스터에 대한 온디맨드 수직적 스케일링 설정
두 개의 파라미터가 포함된 `scale-config`를 사용하여 Memcached에 대한 온디맨드 수직적 스케일링을 구성할 수 있습니다.
1. **ScaleIntervalMinutes:** Memcached 업그레이드 프로세스 중 조정 배치 간 시간(분)
1. **ScalePercentage:** Memcached 업그레이드 프로세스 중에 동시에 규모를 조정할 노드의 백분율
**기존 Memcached 노드 유형을 CLI를 통해 수직적으로 스케일링할 수 있는 캐시로 변환**
기존 Memcached 노드 기반 클러스터를 수직적으로 스케일링할 수 있는 캐시로 변환하려면 CLI를 통해`elasticache modify-cache-cluster`를 사용할 수 있습니다.
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config \
--apply-immediately
```
**CLI를 사용하여 수직적 스케일링 설정**
CLI를 통해 노드 기반 Memcached 클러스터에 대한 수직적 스케일링을 설정하려면 `scale-config` 및 해당 파라미터 `ScalePercentage` 및 `ScaleIntervalMinutes`와 함께 `elasticache modify-cache-cluster`를 사용합니다.
+ **scale-interval-minutes:** 조정 배치 간의 시간(분)을 정의합니다. 이 설정의 범위는 2\$130분입니다. 값을 지정하지 않으면 기본값으로 5분이 적용됩니다.
+ **scale-percentage:** 각 배치에서 동시에 규모를 조정할 노드의 비율을 지정합니다. 이 설정의 범위는 10\$1100입니다. 분할 시 설정이 반올림되므로 예를 들어 결과가 49.5인 경우 50의 설정이 적용됩니다. 값을 지정하지 않으면 기본값으로 20이 적용됩니다.
이러한 구성 옵션을 사용하면 특정 요구 사항에 따라 스케일링 프로세스를 미세 조정하여 클러스터 중단을 최소화하고 스케일링 속도를 최적화할 수 있습니다. scale-config 파라미터는 Memcached 엔진 유형에만 적용되며 다른 캐시 엔진에는 무시되므로 다른 클러스터의 기존 API 사용과 이전 버전과의 호환성이 보장됩니다.
**API 직접 호출**
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config '{
"ScalePercentage": 30,
"ScaleIntervalMinutes": 2
}'
--apply-immediately
```
**결과:**
클러스터 ID와 보류 중인 변경 사항을 반환합니다.
```
{
"CacheCluster": {
"CacheNodeType": "old_insance_type",
...
...
"PendingModifiedValues": {
"CacheNodeType": "new_instance_type"
},
}
}
```
**Memcached 캐시 수직적 스케일링 설정 나열**
Memcached 캐시에 대한 조정 옵션을 검색하고 수직적 스케일링에 대한 현재 옵션을 확인할 수 있습니다.
**API 직접 호출**
```
aws elasticache list-allowed-node-type-modifications --cache-cluster-id
```
**결과: **
```
{
"ScaleUpModifications": [
"cache.x.xxxx",
"cache.x.xxxx"
],
"ScaleDownModifications": [
"cache.x.xxxx",
"cache.x.xxxx",
"cache.x.xxxx"
]
}
```
**를 사용한 Memcached의 수직 조정AWS Management Console**
다음 단계에 따라를 사용하여 노드 기반 Memcached 클러스터를 수직 확장 가능 클러스터로AWS Management Console변환합니다.
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 변환할 Memcached 클러스터를 선택합니다.
1. **수정** 탭을 선택합니다.
1. **캐시 설정** 섹션으로 이동하여 원하는 **노드 유형**을 선택합니다.
1. **변경 사항 미리 보기**를 선택하고 변경 사항을 검토합니다.
1. **수정**을 선택합니다.
## Memcached의 자동 수평적 스케일링
이제 ElastiCache는AWS Application Auto Scaling(AAS) 서비스와 통합되어 Memcached 클러스터에 대한 자동 수평 조정을 포함합니다.AWS Application Auto Scaling 서비스를 통해 조정 정책을 정의하고 사전 정의된 지표 또는 일정에 따라 필요에 따라 Memcached 클러스터의 노드 수를 자동으로 조정할 수 있습니다.
**참고**
현재 베이징 및 닝샤 리전에서는 자동 수평적 스케일링을 사용할 수 없습니다.
다음은 노드 기반 클러스터에 자동 수평적 스케일링을 수행하는 데 사용할 수 있는 방법입니다.
+ **예약된 스케일링:** 일정을 기반으로 스케일링을 수행하면 예측 가능한 로드 변경에 맞게 스케일링 일정을 설정할 수 있습니다. 예를 들어, 매주 수요일에 웹 애플리케이션에 대한 트래픽이 증가하고 목요일까지 높은 상태로 유지되다가 금요일이 줄어들기 시작합니다. Auto Scaling이 수요일에 용량을 늘리고 금요일에 용량을 줄이도록 구성할 수 있습니다.
+ **대상 추적:** 대상 추적 스케일링 정책을 사용하는 경우 스케일링 지표를 선택하고 대상 값을 설정합니다. Application Auto Scaling은 스케일링 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 스케일링 조절을 계산합니다. 스케일링 정책은 필요에 따라 용량을 추가하거나 제거하여 지표를 지정한 목푯값으로, 혹은 목표 값에 가깝게 유지합니다.
**CLI를 통해 노드 기반 Memcached 클러스터에 대한 수평적 스케일링을 설정하는 방법**
노드 기반 Memcached 클러스터를 수평적으로 스케일링하는 경우 대상 추적 정책, 예약된 정책 또는 둘 다를 사용할 수 있습니다.
1. **리소스를 확장 가능 대상으로 등록**
AWS Application Auto Scaling에서 `RegisterScalableTarget` API를 호출하여 확장 가능한 차원에 대한 대상을 등록합니다`elasticache:cache-cluster:Nodes`.
**API: ApplicationAutoScaling.RegisterScalableTarget**
입력:
```
{
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"MinCapacity": 20,
"MaxCapacity": 50
}
```
1. **대상 추적 스케일링 정책 생성**
다음으로 put 스케일링 정책 API를 직접 호출하여 리소스에 대한 대상 추적 스케일링 정책을 생성할 수 있습니다.
1. **사전 정의된 지표**
다음은 클러스터 test-cluster-1에 대해 50으로 설정된 사전 정의된 지표 ` ElastiCacheCPUUtilization`을 사용하여 캐시 노드의 차원에 따라 규모가 조정되는 정책입니다. 스케일 인을 위해 노드를 삭제하면 마지막 n개의 노드가 제거됩니다.
API: ApplicationAutoScaling.PutScalingPolicy
입력:
```
{
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 50,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ElastiCacheCPUUtilization"
},
"ScaleOutCooldown": 600,
"ScaleInCooldown": 600
},
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1"
}
```
출력:
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:012345678910:scalingPolicy:6d8972f3-efc8-437c-92d1-6270f29a66e7:resource/elasticache/cache-cluster/test-cluster-1:policyName/cpu50-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca",
"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d",
"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d"
}
]
}
```
1. **사용자 지정 지표**
Cloudwatch 지표를 기반으로 하는 사용자 지정 백분율을 사용하여 차원에 대한 스케일링 정책을 설정할 수도 있습니다.
입력:
```
{
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"CustomizedMetricSpecification": {
"Dimensions": [
{
"Name": "MyMetricDimension",
"Value": "DimensionValue"
}
],
"MetricName": "MyCustomMetric",
"Namespace": "MyNamespace",
"Statistic": "Average",
"Unit": "Percent"
},
"TargetValue": 40,
"ScaleOutCooldown": 600,
"ScaleInCooldown": 600
},
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1"
}
```
1. **예약된 작업**
특정 이벤트에 대해 스케일 아웃한 다음 이벤트 후에 스케일 인해야 하는 경우 `PutScheduledAction` API를 직접 호출하여 2개의 예약된 작업을 생성할 수 있습니다.
**정책 1: 스케일 아웃**
`--schedule` 일정의 `at` 명령은 미래의 지정된 날짜 및 시간에 한 번 실행되도록 작업을 예약합니다. 일정 필드는 rate(분, 시간, 일 등) 및 cron(cron 표현식)도 지원합니다.
지정된 날짜 및 시간이 되면 Application Auto Scaling이 `MinCapacity` 및 `MaxCapacity` 값을 업데이트합니다. Application Auto Scaling은 캐시 노드를 70으로 설정하기 위해 MinCapacity로 스케일 아웃합니다.
**API: ApplicationAutoScaling.PutScheduledAction**
입력:
```
{
"ResourceId": "elasticache:ache-cluster:test-cluster-1",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ScalableTargetAction": {
"MaxCapacity": 100,
"MinCapacity": 70
},
"Schedule": "at(2020-05-20T17:05:00)",
"ScheduledActionName": "ScalingOutScheduledAction",
"ServiceNamespace": "elasticache",
}
```
**정책 2: 스케일 인**
지정된 날짜 및 시간이 되면 Application Auto Scaling이 테이블의 `MinCapacity` 및 `MaxCapacity`를 업데이트하고 `MaxCapacity`로 스케일 인하여 캐시 노드를 60으로 돌려놓습니다.
**API: ApplicationAutoScaling.PutScheduledAction**
입력:
```
{
"ResourceId": "elasticache:cache-cluster:test-cluster-1",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ScalableTargetAction": {
"MaxCapacity": 60,
"MinCapacity": 40
},
"Schedule": "at(2020-05-21T17:05:00)",
"ScheduledActionName": "ScalingInScheduledAction",
"ServiceNamespace": "elasticache",
}
```
1. **스케일링 활동 보기**
`DescribeScalingActivities` API를 사용하여 스케일링 활동을 볼 수 있습니다.
**API: ApplicationAutoScaling.DescribeScalingActivities**
출력:
```
{
"ScalingActivities": [
{
"ScalableDimension": "elasticache:elasticache:DesiredCount",
"Description": "Setting desired count to 30.",
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ActivityId": "4d759079-a31f-4d0c-8468-504c56e2eecf",
"StartTime": 1462574194.658,
"elasticacheNamespace": "elasticache",
"EndTime": 1462574276.686,
"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
"StatusMessage": "Failed to set desired count to 30",
"StatusCode": "Failed"
},
{
"ScalableDimension": "elasticache:elasticache:DesiredCount",
"Description": "Setting desired count to 25.",
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ActivityId": "90aff0eb-dd6a-443c-889b-b809e78061c1",
"StartTime": 1462574254.223,
"elasticacheNamespace": "elasticache",
"EndTime": 1462574333.492,
"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
"StatusMessage": "Successfully set desired count to 25. Change successfully fulfilled by elasticache.",
"StatusCode": "Successful"
}
]
}
```
1. **스케일링 정책 편집/삭제**
`PutScalingPolicy` API를 다시 직접 호출하거나 `DeleteScalingPolicy` 또는 `DeleteScheduled` 작업을 직접 호출하여 정책을 편집하거나 삭제할 수 있습니다.
1. **스케일링 가능 대상 등록 취소**
`DeregisterScalableTarget` API를 통해 스케일링 가능 대상의 등록을 취소할 수 있습니다. 스케일링 가능 대상을 등록 취소하면 스케일링 정책과 이와 연결된 예약된 작업이 삭제됩니다.
**API: ApplicationAutoScaling.DeregisterScalableTarget**
입력:
```
{
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes"
}
```
1. **스케일링 정책 정리**
1. **여러 스케일링 정책**
여러 스케일링 정책을 생성할 수 있습니다. 다음은 [Auto Scaling 대상 추적](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)의 동작에 대한 주요 콜아웃입니다.
+ 각각 다른 지표를 사용한다는 전제하에 확장 가능한 대상에 대해 다수의 대상 추적 스케일링 정책을 보유할 수 있습니다.
+ Application Auto Scaling은 항상 가용성을 우선시하므로, 대상 추적 정책이 확장 또는 축소를 허용하는지에 따라 그 동작이 달라집니다. 대상 추적 정책 중 하나라도 확장을 허용할 경우 확장 가능한 대상을 확장하지만 모든 대상 추적 정책(축소 부분이 활성화됨)이 축소를 허용하는 경우에만 대상을 축소합니다.
+ 여러 정책이 확장 가능한 대상에 확장 또는 축소를 동시에 지시하는 경우 Application Auto Scaling은 축소와 확장 모두에 대해 가장 큰 용량을 제공하는 정책에 따라 조정합니다. 이로써 다양한 시나리오를 수용할 만큼 폭넓은 유연성을 발휘할 뿐만 아니라 애플리케이션 워크로드를 처리하는 데 필요한 용량을 항상 충분히 확보할 수 있습니다.
**참고**
AWS Application Auto Scaling은 조정 정책을 대기열에 추가하지 않습니다. Application Auto Scaling은 첫 번째 스케일링이 완료될 때까지 기다린 다음 휴지 상태로 전환한 다음 위의 알고리즘을 반복합니다.
**를 통해 노드 기반 Memcached 클러스터를 자동으로 수평적으로 조정AWS Management Console**
다음 단계에 따라AWS Management Console를 사용하여 기존 노드 기반 Memcached 클러스터를 수평적으로 확장 가능한 클러스터로 변환합니다.
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 변환할 Memcached 캐시를 선택합니다.
1. **자동 크기 조정** 탭으로 이동합니다.
1. **동적 크기 조정 추가** 또는 **예약된 크기 조정 추가**를 선택하여 적용할 조정 정책을 선택합니다.
1. 필요에 따라 선택한 정책의 세부 정보를 입력합니다.
1. **생성**을 클릭합니다.
# Memcached 클러스터의 수동 규모 조정
수동으로 Memcached 클러스터를 스케일 인 또는 아웃하는 것은 클러스터에서 노드를 추가 또는 제거하는 것만큼 쉽습니다. Memcached 클러스터는 1\$160개의 노드로 구성되어 있습니다.
Memcached 클러스터의 모든 노드로 데이터를 분할할 수 있으므로 더 많은 양의 메모리가 있는 노드 유형으로 스케일 업할 필요가 거의 없습니다. 그러나 Memcached 엔진이 데이터를 유지하지 않으므로 다른 노드 유형으로 조정할 경우 애플리케이션에서 채우지 않으면 새 클러스터가 비워집니다.
Memcached 클러스터를 수동으로 수직적 스케일링하려면 새 클러스터를 생성해야 합니다. Memcached 클러스터는 애플리케이션이 채울 때까지 항상 비어 있습니다.
**Memcached 클러스터 수동 규모 조정**
| 작업 | Topic |
| --- | --- |
| 확장 | [클러스터에 노드 추가](Clusters.html#AddNode) |
| 축소 | [클러스터에서 노드 삭제](Clusters.html#DeleteNode) |
| 노드 유형 변경 | [노드 기반 Memcached 클러스터를 수직으로 수동 규모 조정](#Scaling.Memcached.Vertically) |
**Topics**
+ [노드 기반 Memcached 클러스터를 수평으로 수동 규모 조정](#Scaling.Memcached.Horizontally)
+ [노드 기반 Memcached 클러스터를 수직으로 수동 규모 조정](#Scaling.Memcached.Vertically)
## 노드 기반 Memcached 클러스터를 수평으로 수동 규모 조정
Memcached 엔진은 여러 노드에 대한 데이터 분할을 지원합니다. 따라서 Memcached 클러스터는 쉽게 수평으로 조정됩니다. 수평으로 Memcached 클러스터를 조정하려면 노드를 추가 또는 제거하면 됩니다.
다음 항목은 노드를 추가 또는 제거하여 Memcached 클러스터를 스케일 아웃 또는 스케일 인하는 방법을 자세히 설명합니다.
+ [클러스터에 노드 추가](Clusters.html#AddNode)
+ [클러스터에서 노드 삭제](Clusters.html#AddNode)
Memcached 클러스터의 노드 수를 변경할 때마다 키스페이스의 일부라도 다시 매핑해야 정확한 노드에 매핑됩니다. Memcached 클러스터의 로드 밸런싱에 대한 자세한 내용은 [효율적인 로드 밸런싱을 위해 ElastiCache 클라이언트 구성(Memcached)](BestPractices.LoadBalancing.md) 섹션을 참조하세요.
Memcached 클러스터에 대해 Auto Discovery를 사용할 경우 노드를 추가 또는 제거할 때 애플리케이션에 있는 엔드포인트를 변경할 필요가 없습니다. 자동 검색에 대한 자세한 내용은 [클러스터의 노드 자동 식별(Memcached)](AutoDiscovery.md) 섹션을 참조합니다. 자동 검색을 사용하지 않을 경우 Memcached 클러스터의 노드 수를 변경할 때마다 애플리케이션에 있는 엔드포인트를 업데이트해야 합니다.
## 노드 기반 Memcached 클러스터를 수직으로 수동 규모 조정
Memcached 클러스터를 수동으로 스케일 업 또는 다운하는 경우 새 클러스터를 생성해야 합니다. Memcached 클러스터는 애플리케이션이 채울 때까지 항상 비어 있습니다.
**중요**
소형 노드 유형으로 스케일 다운할 경우 소형 노드 유형이 데이터 및 오버헤드에 적합해야 합니다. 자세한 내용은 [노드 크기 선택](CacheNodes.SelectSize.md) 단원을 참조하십시오.
**Topics**
+ [노드 기반 Memcached 클러스터를 수직으로 규모 조정(콘솔)](#Scaling.Memcached.Vertically.CON)
+ [노드 기반 Memcached 클러스터를 수직으로 규모 조정(AWS CLI)](#Scaling.Memcached.Vertically.CLI)
+ [노드 기반 Memcached 클러스터를 수직으로 규모를 조정하려면(ElastiCache API)](#Scaling.Memcached.Vertically.API)
### 노드 기반 Memcached 클러스터를 수직으로 규모 조정(콘솔)
다음 절차는AWS Management Console를 사용하여 노드 기반 Memcached 클러스터를 수직으로 조정하는 방법을 안내합니다.
1. 새 노드 유형으로 새 클러스터를 생성합니다. 자세한 내용은 [Memcached 클러스터 생성(콘솔)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached) 섹션을 참조하세요.
1. 애플리케이션에서 엔드포인트를 새 클러스터의 엔드포인트로 업데이트합니다. 자세한 내용은 [클러스터 엔드포인트 찾기(콘솔)(Memcached)](Endpoints.md#Endpoints.Find.Memcached) 단원을 참조하십시오.
1. 이전 클러스터를 삭제합니다. 자세한 내용은 [Memcached에서 새 노드 삭제](Clusters.html#Delete.CON.Memcached)를 참조하세요.
### 노드 기반 Memcached 클러스터를 수직으로 규모 조정(AWS CLI)
다음 절차는AWS CLI를 사용하여 노드 기반 Memcached 클러스터를 수직으로 조정하는 방법을 안내합니다.
1. 새 노드 유형으로 새 클러스터를 생성합니다. 자세한 내용은 [클러스터 생성(AWS CLI)](Clusters.Create.md#Clusters.Create.CLI) 단원을 참조하십시오.
1. 애플리케이션에서 엔드포인트를 새 클러스터의 엔드포인트로 업데이트합니다. 자세한 내용은 [엔드포인트 찾기(AWS CLI)](Endpoints.md#Endpoints.Find.CLI) 단원을 참조하십시오.
1. 이전 클러스터를 삭제합니다. 자세한 내용은 [AWS CLI를 사용하여 ElastiCache 클러스터 삭제](Clusters.Delete.md#Clusters.Delete.CLI) 단원을 참조하십시오.
### 노드 기반 Memcached 클러스터를 수직으로 규모를 조정하려면(ElastiCache API)
다음 절차는 ElastiCache API를 사용하여 노드 기반 Memcached 클러스터를 수직으로 규모를 조정하는 방법을 안내합니다.
1. 새 노드 유형으로 새 클러스터를 생성합니다. 자세한 내용은 [Memcached용 클러스터 생성(ElastiCache API)](Clusters.Create-mc.md#Clusters.Create.API.mem-heading) 섹션을 참조하세요.
1. 애플리케이션에서 엔드포인트를 새 클러스터의 엔드포인트로 업데이트합니다. 자세한 내용은 [엔드포인트 찾기(ElastiCache API)](Endpoints.md#Endpoints.Find.API) 단원을 참조하십시오.
1. 이전 클러스터를 삭제합니다. 자세한 내용은 [ElastiCache API 사용](Clusters.Delete.md#Clusters.Delete.API) 단원을 참조하십시오.
# Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 클러스터 규모 조정
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터는 샤드가 없는 단일 노드 클러스터이거나 샤드가 1개인 다중 노드 클러스터일 수 있습니다. 단일 노드 클러스터에서는 읽기와 쓰기에 모두 사용되는 노드 1개를 사용합니다. 다중 노드 클러스터에는 읽기/쓰기 프라이머리 노드인 노드 1개와 0\$15개의 읽기 전용 복제본 노드가 있습니다.
**Topics**
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 클러스터 규모 조정](#Scaling.RedisStandalone)
**Valkey 또는 Redis OSS 클러스터 규모 조정**
| 작업 | Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) | Valkey 또는 Redis OSS(클러스터 모드 활성화됨) |
| --- | --- | --- |
| 축소 | [ElastiCache 클러스터에서 노드 제거](Clusters.DeleteNode.md) | [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) |
| 확장 | [클러스터에 노드 추가](Clusters.html#AddNode) | [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 온라인 리샤딩](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) |
| 노드 유형 변경 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/scaling-redis-classic.html) | [노드 유형 수정하여 온라인 수직 조정](redis-cluster-vertical-scaling.md) |
| 노드 그룹의 수 변경 | Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터에는 지원되지 않음 | [Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정](scaling-redis-cluster-mode-enabled.md) |
**Contents**
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 클러스터 규모 조정](#Scaling.RedisStandalone)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업](#Scaling.RedisStandalone.ScaleUp)
+ [Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 단일 노드 클러스터 스케일 업(콘솔)](#Scaling.RedisStandalone.ScaleUp.CON)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업(AWS CLI)](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업(ElastiCache API)](#Scaling.RedisStandalone.ScaleUp.API)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운](#Scaling.RedisStandalone.ScaleDown)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)](#Scaling.RedisStandalone.ScaleDown.API)
## Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 클러스터 규모 조정
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 노드는 모든 캐시의 데이터와 Valkey 또는 Redis OSS 오버헤드를 포함할 만큼 충분히 커야 합니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터의 데이터 용량을 변경하려면 수직으로 조정해야 합니다. 대형 노드 유형으로 스케일 업하여 데이터 용량을 늘리거나 소형 노드 유형으로 스케일 다운하여 데이터 용량을 줄입니다.
ElastiCache 스케일 업 프로세스는 기존 데이터를 최대한 유지할 수 있도록 진행되며, 성공적인 Valkey 또는 Redis OSS 복제가 필요합니다. Valkey 또는 Redis OSS(클러스터 모드 사용 중지됨) 클러스터의 경우, Valkey 또는 Redis OSS에 충분한 메모리를 사용할 수 있도록 하는 것이 좋습니다.
여러 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터로 데이터를 분할할 수 없습니다. 그러나 클러스터의 읽기 용량만 늘리거나 줄여야 하는 경우 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 생성하고 읽기 전용 복제본을 추가 또는 제거할 수 있습니다. 단일 노드 Valkey 또는 Redis OSS 클러스터를 기본 클러스터로 사용하여 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 생성하려면 [Valkey(클러스터 모드 비활성화됨) 클러스터 생성(콘솔)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs) 섹션을 참조하세요.
복제본이 있는 클러스터를 생성하면 읽기 전용 복제본을 추가하여 읽기 용량을 늘릴 수 있습니다. 나중에 필요한 경우 읽기 전용 복제본을 제거하여 읽기 용량을 줄일 수 있습니다. 자세한 내용은 [읽기 용량 늘리기](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleOut) 또는 [읽기 용량 줄이기](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleIn)을 참조하세요.
읽기 용량을 조정할 수 있는 것 외에도 복제본이 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터는 다른 비즈니스 혜택을 제공합니다. 자세한 내용은 [고가용성을 위한 복제 그룹 사용](Replication.md) 단원을 참조하십시오.
**중요**
파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 조정을 시작하기 전에 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹이 있어야 합니다. 또는 `reserved-memory-percent`를 사용하고 새 클러스터에 대해 해당 파라미터 그룹을 사용하도록 사용자 지정 파라미터 그룹을 수정할 수 있습니다.
`reserved-memory-percent`를 사용할 경우에는 이렇게 하지 않아도 됩니다.
자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
**Topics**
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업](#Scaling.RedisStandalone.ScaleUp)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운](#Scaling.RedisStandalone.ScaleDown)
### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업
단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업하면 ElastiCache는 ElastiCache 콘솔,AWS CLI또는 ElastiCache API를 사용하는지 여부에 관계없이 다음 프로세스를 수행합니다.
1. 새 노드 유형이 있는 새 클러스터가 동일한 가용 영역에서 기존 클러스터로 실행됩니다.
1. 기존 클러스터의 캐시 데이터가 새 클러스터로 복사됩니다. 이 프로세스의 기간은 노드 유형 및 클러스터에 있는 데이터의 양에 따라 달라집니다.
1. 새 클러스터를 사용하여 읽기 및 쓰기를 수행합니다. 새 클러스터의 엔드포인트가 이전 클러스터의 엔드포인트와 동일하므로 애플리케이션에 있는 엔드포인트를 업데이트할 필요가 없습니다. DNS 항목이 업데이트되는 동안 프라이머리 노드의 읽기 및 쓰기가 잠깐(몇 초) 중단될 수 있습니다.
1. ElastiCache가 이전 클러스터를 삭제합니다. 이전 노드에 대한 연결이 끊어지기 때문에 이전 노드의 읽기 및 쓰기가 잠깐(몇 초) 중단될 수 있습니다.
**참고**
r6gd 노드 유형을 실행하는 클러스터의 경우 r6gd 노드 패밀리 내의 노드 크기로만 조정할 수 있습니다.
다음 표에 표시된 대로 다음 유지 관리 기간에 대해 엔진 업그레이드가 예약된 경우 Valkey 또는 Redis OSS 스케일 업 작업이 차단됩니다. 유지 관리 기간에 대한 자세한 내용은 [ElastiCache 클러스터 유지 관리](maintenance-window.md) 섹션을 참조하세요.
**차단된 Valkey 또는 Redis OSS 작업**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/scaling-redis-classic.html)
사용자를 차단하는 대기 중 작업이 있는 경우 다음 중 하나를 수행할 수 있습니다.
+ **Apply immediately** 확인란을 선택 취소하여 다음 유지 관리 기간에 대해 Valkey 또는 Redis OSS 스케일 업 작업을 예약합니다(CLI 사용: `--no-apply-immediately`, API 사용: `ApplyImmediately=false`).
+ Valkey 또는 Redis OSS 스케일 업 작업을 수행하기 위해 다음 유지 관리 기간(또는 그 이후)까지 기다립니다.
+ **즉시 적용** 확인란을 선택한 채로 이 클러스터 수정 사항에 Valkey 또는 Redis OSS 엔진 업그레이드를 추가합니다(CLI 사용: `--apply-immediately`, API 사용: `ApplyImmediately=true`). 이렇게 하면 스케일 업 작업의 차단이 해제되어 엔진 업그레이드가 즉시 수행됩니다.
ElastiCache 콘솔, 또는 ElastiCache ElastiCache API를 사용하여 단일 노드 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 확장할 수 있습니다.AWS CLI
**중요**
파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 조정을 시작하기 전에 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹이 있어야 합니다. 또는 `reserved-memory-percent`를 사용하고 새 클러스터에 대해 해당 파라미터 그룹을 사용하도록 사용자 지정 파라미터 그룹을 수정할 수 있습니다.
`reserved-memory-percent`를 사용할 경우에는 이렇게 하지 않아도 됩니다.
자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
#### Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 단일 노드 클러스터 스케일 업(콘솔)
다음 절차에서는 ElastiCache Management Console을 사용하여 단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업하는 방법에 대해 설명합니다. 이 프로세스 동안 Valkey 또는 Redis OSS 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업하려면(콘솔)**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 또는 Redis OSS 클러스터**를 선택합니다.
1. 클러스터 목록에서 스케일 업할 클러스터를 선택합니다(Clustered Valkey or Redis OSS 엔진이 아닌 Valkey or Redis OSS 엔진을 실행해야 함).
1. **수정**을 선택합니다.
1. [**Modify Cluster**] 마법사에서 다음을 수행합니다.
1. [**Node type**] 목록에서 조정할 노드 유형을 선택합니다.
1. `reserved-memory`를 사용하여 메모리를 관리할 경우 [**Parameter Group**] 목록에서 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹을 선택합니다.
1. 스케일 업 프로세스를 즉시 수행하려면 [**Apply immediately**] 상자를 선택합니다. [**Apply immediately**] 상자를 선택하지 않으면 이 클러스터의 다음 유지 관리 기간 중 스케일 업 프로세스가 수행됩니다.
1. **수정**을 선택합니다.
이전 단계에서 [**Apply immediately**]를 선택한 경우 클러스터의 상태가 *수정 중*으로 변경됩니다. 상태가 *사용 가능*으로 변경되면 수정이 완료되고 새 클러스터의 사용을 시작할 수 있습니다.
#### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업(AWS CLI)
다음 절차에서는AWS CLI를 사용하여 단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업하는 방법에 대해 설명합니다. 이 프로세스 동안 Valkey 또는 Redis OSS 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업하려면(AWS CLI)**
1. 다음 파라미터로 `list-allowed-node-type-modifications` 명령을 실행AWS CLI하여 스케일 업할 수 있는 노드 유형을 결정합니다.
+ `--cache-cluster-id`
Linux, macOS, Unix의 경우:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Windows의 경우:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
}
```
자세한 내용은 *AWS CLI참조*의 [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) 섹션을 참조하세요.
1. 명령과 다음 파라미터를 사용하여 확장할 클러스터와 새롭고 더 큰 노드 유형을 지정하여 기존 클러스터를AWS CLI`modify-cache-cluster` 수정합니다.
+ `--cache-cluster-id` - 스케일 업할 클러스터의 이름입니다.
+ `--cache-node-type` - 클러스터를 조정할 새 노드 유형입니다. 이 값은 1단계의 `list-allowed-node-type-modifications` 명령에 의해 반환되는 노드 유형 중 하나여야 합니다.
+ `--cache-parameter-group-name` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `--apply-immediately` - 스케일 업 프로세스가 즉시 적용되도록 합니다. 스케일 업 프로세스를 클러스터의 다음 유지 관리 기간으로 연기하려면 `--no-apply-immediately` 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cache-cluster \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m2-xl \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-cache-cluster ^
--cache-cluster-id my-redis-cache-cluster ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m2-xl ^
--apply-immediately
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis6.x",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "6.0",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
```
자세한 내용은 *AWS CLI참조*의 [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) 섹션을 참조하세요.
1. 를 사용한 경우 다음 파라미터와 함께 명령을 사용하여AWS CLI`describe-cache-clusters` 새 클러스터의 상태를 `--apply-immediately`확인합니다. 상태가 *사용 가능*으로 변경되면 새로운 대형 클러스터의 사용을 시작할 수 있습니다.
+ `--cache-cluster-id` - 단일 노드 Valkey 또는 Redis OSS 클러스터의 이름입니다. 모든 클러스터 대신 특정 클러스터를 설명하려면 이 파라미터를 사용하세요.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
자세한 내용은 *AWS CLI참조*의 [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) 섹션을 참조하세요.
#### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 업(ElastiCache API)
다음 절차에서는 ElastiCache API를 사용하여 단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업하는 방법에 대해 설명합니다. 이 프로세스 동안 Valkey 또는 Redis OSS 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업하려면(ElastiCache API)**
1. 다음 파라미터와 함께 ElastiCache API `ListAllowedNodeTypeModifications` 작업을 실행하여 확장할 수 있는 노드 유형을 확인합니다.
+ `CacheClusterId` - 스케일 업할 단일 노드 Valkey 또는 Redis OSS 클러스터의 이름입니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) 섹션을 참조하세요.
1. `ModifyCacheCluster` ElastiCache API 작업 및 다음 파라미터를 사용하여 스케일 업할 클러스터 및 새로운 대형 노드 유형을 지정하도록 기존 클러스터를 수정합니다.
+ `CacheClusterId` - 스케일 업할 클러스터의 이름입니다.
+ `CacheNodeType` - 클러스터를 조정할 새로운 대형 노드 유형입니다. 이 값은 이전 단계의 `ListAllowedNodeTypeModifications` 작업에 의해 반환되는 노드 유형 중 하나여야 합니다.
+ `CacheParameterGroupName` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `ApplyImmediately` - 스케일 업 프로세스가 즉시 수행되도록 하려면 `true`로 설정합니다. 스케일 업 프로세스를 클러스터의 다음 유지 관리 기간으로 연기하려면 `ApplyImmediately``=false`를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) 섹션을 참조하세요.
1. `ApplyImmediately``=true`를 사용한 경우 ElastiCache API `DescribeCacheClusters` 작업을 다음 파라미터와 함께 사용하여 새 클러스터의 상태를 확인합니다. 상태가 *사용 가능*으로 변경되면 새로운 대형 클러스터의 사용을 시작할 수 있습니다.
+ `CacheClusterId` - 단일 노드 Valkey 또는 Redis OSS 클러스터의 이름입니다. 모든 클러스터 대신 특정 클러스터를 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) 섹션을 참조하세요.
### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운
다음 섹션에서는 단일 노드 Valkey 또는 Redis OSS 클러스터를 소형 노드 유형으로 축소하는 방법을 살펴봅니다. 새 Valkey 또는 Redis OSS 클러스터의 장기적인 성공을 위해 새로운 소형 노드 유형이 모든 데이터와 Valkey 또는 Redis OSS 오버헤드를 수용할 만큼 충분히 큰지 확인하는 것이 중요합니다. 자세한 내용은 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md) 단원을 참조하십시오.
**참고**
r6gd 노드 유형을 실행하는 클러스터의 경우 r6gd 노드 패밀리 내의 노드 크기로만 조정할 수 있습니다.
**Topics**
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)](#Scaling.RedisStandalone.ScaleDown.API)
#### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)
다음 절차는 ElastiCache 콘솔을 사용하여 단일 노드 Valkey 또는 Redis OSS 클러스터를 소형 노드 유형으로 축소하는 방법을 안내합니다.
**중요**
파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 조정을 시작하기 전에 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹이 있어야 합니다. 또는 `reserved-memory-percent`를 사용하고 새 클러스터에 대해 해당 파라미터 그룹을 사용하도록 사용자 지정 파라미터 그룹을 수정할 수 있습니다.
`reserved-memory-percent`를 사용할 경우에는 이렇게 하지 않아도 됩니다.
자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
**단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 다운하려면(콘솔)**
1. 소형 노드 유형이 데이터 및 오버헤드 요구 사항에 적합한지 확인합니다.
1. 파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 새 노드 유형에 대해 올바른 메모리 양을 구분하는 사용자 지정 파라미터 그룹이 있어야 합니다.
또는 `reserved-memory-percent`를 사용하여 사용자 지정 파라미터 그룹을 수정할 수 있습니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 클러스터 목록에서 스케일 다운할 클러스터를 선택합니다. 이 클러스터는 Clustered Valkey 또는 Redis OSS 엔진이 아닌 Valkey 또는 Redis OSS 엔진을 실행해야 합니다.
1. **수정**을 선택합니다.
1. [**Modify Cluster**] 마법사에서 다음을 수행합니다.
1. [**Node type**] 목록에서 스케일 다운할 노드 유형을 선택합니다.
1. `reserved-memory`를 사용하여 메모리를 관리할 경우 [**Parameter Group**] 목록에서 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹을 선택합니다.
1. 스케일 다운 프로세스를 즉시 수행하려면 [**Apply immediately**] 확인란을 선택합니다. [**Apply immediately**] 확인란을 선택하지 않고 비워 두면 이 클러스터의 다음 유지 관리 기간 중 스케일 다운 프로세스가 수행됩니다.
1. **수정**을 선택합니다.
1. 클러스터의 상태가 *수정 중*에서 *사용 가능*으로 변경되면 클러스터가 새 노드 유형으로 조정된 것입니다. 애플리케이션에서 엔드포인트를 업데이트할 필요가 없습니다.
#### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)
다음 절차에서는AWS CLI를 사용하여 단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 다운하는 방법에 대해 설명합니다.
**단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운하려면(AWS CLI)**
1. 다음 파라미터로 `list-allowed-node-type-modifications` 명령을 실행AWS CLI하여 축소할 수 있는 노드 유형을 결정합니다.
+ `--cache-cluster-id`
Linux, macOS, Unix의 경우:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Windows의 경우:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
}
```
자세한 내용은 *AWS CLI참조*의 [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) 섹션을 참조하세요.
1. 명령과 다음 파라미터를 사용하여 스케일 다운할 클러스터와 새롭고 더 작은 노드 유형을 지정하여 기존 클러스터를AWS CLI`modify-cache-cluster` 수정합니다.
+ `--cache-cluster-id` - 스케일 다운할 클러스터의 이름입니다.
+ `--cache-node-type` - 클러스터를 조정할 새 노드 유형입니다. 이 값은 1단계의 `list-allowed-node-type-modifications` 명령에 의해 반환되는 노드 유형 중 하나여야 합니다.
+ `--cache-parameter-group-name` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `--apply-immediately` - 축소 프로세스가 즉시 적용되도록 합니다. 스케일 업 프로세스를 클러스터의 다음 유지 관리 기간으로 연기하려면 `--no-apply-immediately` 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cache-cluster \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m2-xl \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-cache-cluster ^
--cache-cluster-id my-redis-cache-cluster ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m2-xl ^
--apply-immediately
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis6,x",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "6.0",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
```
자세한 내용은 *AWS CLI참조*의 [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) 섹션을 참조하세요.
1. 를 사용한 경우 다음 파라미터와 함께 명령을 사용하여AWS CLI`describe-cache-clusters` 새 클러스터의 상태를 `--apply-immediately`확인합니다. 상태가 *사용 가능*으로 변경되면 새로운 대형 클러스터의 사용을 시작할 수 있습니다.
+ `--cache-cluster-id` - 단일 노드 Valkey 또는 Redis OSS 클러스터의 이름입니다. 모든 클러스터 대신 특정 클러스터를 설명하려면 이 파라미터를 사용하세요.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
자세한 내용은 *AWS CLI참조*의 [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) 섹션을 참조하세요.
#### 단일 노드 Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)
다음 절차에서는 ElastiCache API를 사용하여 단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 업 및 스케일 다운하는 방법에 대해 설명합니다.
**단일 노드 Valkey 또는 Redis OSS 클러스터를 스케일 다운하려면(ElastiCache API)**
1. 다음 파라미터와 함께 ElastiCache API `ListAllowedNodeTypeModifications` 작업을 실행하여 축소할 수 있는 노드 유형을 확인합니다.
+ `CacheClusterId` - 스케일 다운할 단일 노드 Valkey 또는 Redis OSS 클러스터의 이름입니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) 섹션을 참조하세요.
1. `ModifyCacheCluster` ElastiCache API 작업 및 다음 파라미터를 사용하여 스케일 업할 클러스터 및 새로운 대형 노드 유형을 지정하도록 기존 클러스터를 수정합니다.
+ `CacheClusterId` - 스케일 다운할 클러스터의 이름입니다.
+ `CacheNodeType` - 클러스터를 스케일 다운할 새롭고 더 작은 노드 유형입니다. 이 값은 이전 단계의 `ListAllowedNodeTypeModifications` 작업에 의해 반환되는 노드 유형 중 하나여야 합니다.
+ `CacheParameterGroupName` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `ApplyImmediately` - 축소 프로세스가 즉시 수행되도록 하려면 `true`로 설정합니다. 스케일 업 프로세스를 클러스터의 다음 유지 관리 기간으로 연기하려면 `ApplyImmediately``=false`를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) 섹션을 참조하세요.
1. `ApplyImmediately``=true`를 사용한 경우 ElastiCache API `DescribeCacheClusters` 작업을 다음 파라미터와 함께 사용하여 새 클러스터의 상태를 확인합니다. 상태가 *사용 가능*으로 변경되면 새롭고 더 작은 클러스터를 사용할 수 있습니다.
+ `CacheClusterId` - 단일 노드 Valkey 또는 Redis OSS 클러스터의 이름입니다. 모든 클러스터 대신 특정 클러스터를 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) 섹션을 참조하세요.
# Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)에 대한 복제본 노드 규모 조정
복제본 노드가 있는 Valkey 또는 Redis OSS 클러스터(API/CLI에서 *복제 그룹*이라고 함)는 자동 장애 조치가 활성화된 다중 AZ가 있는 복제를 통해 고가용성을 제공합니다. 복제본 노드가 있는 클러스터는 최대 6개의 Valkey 또는 Redis OSS 노드의 논리적 모음으로, 이 중 프라이머리 노드는 읽기 및 쓰기 요청을 모두 제공할 수 있습니다. 클러스터의 다른 모든 노드는 프라이머리 노드의 읽기 전용 복제본입니다. 기본에 작성된 데이터는 클러스터의 모든 읽기 전용 복제본으로 비동기식으로 복제됩니다. Valkey 또는 Redis OSS(클러스터 모드 비활성화됨)는 여러 클러스터로의 데이터 분할을 지원하지 않으므로 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹의 각 클러스터에는 전체 캐시 데이터세트가 포함됩니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터는 최대 500개 샤드로의 데이터 분할을 지원합니다.
클러스터의 데이터 용량을 변경하려면 대형 노드 유형으로 스케일 업하거나 소형 노드 유형으로 스케일 다운해야 합니다.
클러스터의 읽기 용량을 변경하려면 최대 5개의 추가 읽기 전용 복제본을 추가하거나 읽기 전용 복제본을 제거하세요.
ElastiCache 스케일 업 프로세스는 기존 데이터를 최대한 유지할 수 있도록 진행되며, 성공적인 Valkey 또는 Redis OSS 복제가 필요합니다. 복제본이 있는 Valkey 또는 Redis OSS 클러스터의 경우, Valkey 또는 Redis OSS에 충분한 메모리를 사용할 수 있도록 하는 것이 좋습니다.
**Topics**
+ [복제본이 있는 Valkey 또는 Redis OSS 클러스터 스케일 업](#Scaling.RedisReplGrps.ScaleUp)
+ [복제본이 있는 Valkey 또는 Redis OSS 클러스터 스케일 다운](#Scaling.RedisReplGrps.ScaleDown)
+ [읽기 용량 늘리기](#Scaling.RedisReplGrps.ScaleOut)
+ [읽기 용량 줄이기](#Scaling.RedisReplGrps.ScaleIn)
**관련 항목**
+ [고가용성을 위한 복제 그룹 사용](Replication.md)
+ [복제: Valkey 및 Redis OSS 클러스터 모드 비활성화됨과 활성화됨](Replication.Redis-RedisCluster.md)
+ [Valkey 및 Redis OSS와 함께 다중 AZ를 사용하여 ElastiCache의 가동 중지 시간 최소화](AutoFailover.md)
+ [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)
**Topics**
+ [복제본이 있는 Valkey 또는 Redis OSS 클러스터 스케일 업](#Scaling.RedisReplGrps.ScaleUp)
+ [복제본이 있는 Valkey 또는 Redis OSS 클러스터 스케일 다운](#Scaling.RedisReplGrps.ScaleDown)
+ [읽기 용량 늘리기](#Scaling.RedisReplGrps.ScaleOut)
+ [읽기 용량 줄이기](#Scaling.RedisReplGrps.ScaleIn)
## 복제본이 있는 Valkey 또는 Redis OSS 클러스터 스케일 업
Amazon ElastiCache는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 복제 그룹 확장에 대한 콘솔, CLI 및 API 지원을 제공합니다.
확장 프로세스가 시작되면 ElastiCache는 다음을 수행합니다.
1. 새 노드 유형을 사용하여 복제 그룹을 시작합니다.
1. 현재 프라이머리 노드에서 새 프라이머리 노드로 모든 데이터를 복사합니다.
1. 새 읽기 전용 복제본을 새 프라이머리 노드와 동기화합니다.
1. DNS 항목이 새 노드를 가리키도록 해당 항목을 업데이트합니다. 따라서 애플리케이션의 엔드포인트를 업데이트할 필요가 없습니다. Valkey 7.2 이상 또는 Redis OSS 5.0.5 이상의 경우 클러스터가 계속 온라인 상태를 유지하고 들어오는 요청을 처리하는 동안 자동 장애 조치(failover) 지원 클러스터를 조정할 수 있습니다. Redis OSS 버전 4.0.10 이하에서, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다.
1. 이전 노드(CLI/API: 복제 그룹)를 삭제합니다. 이전 노드에 대한 연결이 끊어지기 때문에 이전 노드의 읽기 및 쓰기가 잠깐(몇 초) 중단될 수 있습니다.
이 프로세스의 기간은 노드 유형 및 클러스터에 있는 데이터의 양에 따라 달라집니다.
다음 표에 표시된 대로, 클러스터의 다음 유지 관리 기간에 대해 엔진 업그레이드가 예약된 경우 Valkey 또는 Redis OSS 스케일 업 작업이 차단됩니다.
**차단된 Valkey 또는 Redis OSS 작업**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)
사용자를 차단하는 대기 중 작업이 있는 경우 다음 중 하나를 수행할 수 있습니다.
+ **Apply immediately** 확인란을 선택 취소하여 다음 유지 관리 기간에 대해 Valkey 또는 Redis OSS 스케일 업 작업을 예약합니다(CLI 사용: `--no-apply-immediately`, API 사용: `ApplyImmediately=false`).
+ Valkey 또는 Redis OSS 스케일 업 작업을 수행하기 위해 다음 유지 관리 기간(또는 그 이후)까지 기다립니다.
+ **즉시 적용** 확인란을 선택한 채로 이 클러스터 수정 사항에 Valkey 또는 Redis OSS 엔진 업그레이드를 추가합니다(CLI 사용: `--apply-immediately`, API 사용: `ApplyImmediately=true`). 이렇게 하면 스케일 업 작업의 차단이 해제되어 엔진 업그레이드가 즉시 수행됩니다.
다음 섹션에서는 ElastiCache 콘솔,AWS CLI및 ElastiCache API를 사용하여 복제본이 있는 Valkey 또는 Redis OSS 클러스터를 확장하는 방법을 설명합니다.
**중요**
파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 조정을 시작하기 전에 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹이 있어야 합니다. 또는 `reserved-memory-percent`를 사용하고 새 클러스터에 대해 해당 파라미터 그룹을 사용하도록 사용자 지정 파라미터 그룹을 수정할 수 있습니다.
`reserved-memory-percent`를 사용할 경우에는 이렇게 하지 않아도 됩니다.
자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
### 복제본을 사용하여 Valkey 또는 Redis OSS 클러스터 스케일 업(콘솔)
대형 노드 유형으로 스케일 업하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
다음 절차는 ElastiCache 콘솔을 사용하여 복제본이 있는 클러스터를 현재 노드 유형에서 새로운 대형 노드 유형으로 조정합니다. 이 프로세스 중 DNS 항목이 업데이트되는 동안 프라이머리 노드에서 다른 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다. 5.0.6 이상 버전에서 실행 중인 노드의 경우 1초 미만, 이전 버전의 경우 몇 초 동안 가동 중지가 발생할 수 있습니다.
**복제본을 사용하여 Valkey 또는 Redis OSS 클러스터를 스케일 업하려면(콘솔)**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 클러스터** 또는 **Redis OSS 클러스터**를 선택합니다.
1. 클러스터 목록에서 스케일 업할 클러스터를 선택합니다. 이 클러스터는 Clustered Valkey 또는 Redis OSS 엔진이 아닌 Valkey 또는 Redis OSS 엔진을 실행해야 합니다.
1. **수정**을 선택합니다.
1. [**Modify Cluster**] 마법사에서 다음을 수행합니다.
1. [**Node type**] 목록에서 조정할 노드 유형을 선택합니다. 모든 노드 유형을 축소할 수 있는 것은 아닙니다.
1. `reserved-memory`를 사용하여 메모리를 관리할 경우 [**Parameter Group**] 목록에서 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹을 선택합니다.
1. 스케일 업 프로세스를 즉시 수행하려면 [**Apply immediately**] 확인란을 선택합니다. [**Apply immediately**] 확인란을 선택하지 않고 비워 두면 이 클러스터의 다음 유지 관리 기간 중 스케일 업 프로세스가 수행됩니다.
1. **수정**을 선택합니다.
1. 클러스터의 상태가 *수정 중*에서 *사용 가능*으로 변경되면 클러스터가 새 노드 유형으로 조정된 것입니다. 애플리케이션에서 엔드포인트를 업데이트할 필요가 없습니다.
### Valkey 또는 Redis OSS 복제 그룹 스케일 업(AWS CLI)
다음 절차는AWS CLI를 사용하여 복제 그룹을 현재 노드 유형에서 새롭고 더 큰 노드 유형으로 조정합니다. 이 프로세스 중에 ElastiCache는 DNS 항목이 새 노드를 가리키도록 해당 항목을 업데이트합니다. 따라서 애플리케이션의 엔드포인트를 업데이트할 필요가 없습니다. Valkey 7.2 이상 또는 Redis OSS 5.0.5 이상의 경우 클러스터가 계속 온라인 상태를 유지하고 들어오는 요청을 처리하는 동안 자동 장애 조치(failover) 지원 클러스터를 조정할 수 있습니다. 버전 4.0.10 이하의 경우, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다.
대형 노드 유형으로 스케일 업하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
**Valkey 또는 Redis OSS 복제 그룹을 스케일 업하려면(AWS CLI)**
1. 다음 파라미터로AWS CLI`list-allowed-node-type-modifications` 명령을 실행하여 확장할 수 있는 노드 유형을 결정합니다.
+ `--replication-group-id` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Windows의 경우:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
이 작업의 출력은 다음과 같습니다(JSON 형식).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
```
자세한 내용은 *AWS CLI참조*의 [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) 섹션을 참조하세요.
1. 다음 파라미터와 함께 `modify-replication-group` 명령을 사용하여AWS CLI현재 복제 그룹을 새 노드 유형으로 확장합니다.
+ `--replication-group-id` - 복제 그룹의 이름입니다.
+ `--cache-node-type` - 이 복제 그룹에 있는 클러스터의 새로운 대형 노드 유형입니다. 이 값은 이전 단계의 `list-allowed-node-type-modifications` 명령에 의해 반환되는 인스턴스 유형 중 하나여야 합니다.
+ `--cache-parameter-group-name` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `--apply-immediately` - 스케일 업 프로세스가 즉시 적용되도록 합니다. 스케일 업 작업을 다음 유지 관리 기간으로 연기하려면 `--no-apply-immediately`를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id my-repl-group \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id my-repl-group ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
이 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [{
"Status": "available",
"NodeGroupMembers": [{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002"
],
"PendingModifiedValues": {}
}
}
```
자세한 내용은 *AWS CLI참조*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 섹션을 참조하세요.
1. `--apply-immediately` 파라미터를 사용한 경우 다음 파라미터와 함께 `describe-replication-group` 명령을 사용하여AWS CLI복제 그룹의 상태를 모니터링합니다. 상태가 계속 *수정 중*이면 5.0.6 이상 버전에서 실행 중인 노드의 경우 1초 미만의 가동 중지가 발생할 수 있고, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다.
+ `--replication-group-id` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-replication-groups \
--replication-group-id my-replication-group
```
Windows의 경우:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
자세한 내용은 *AWS CLI참조*에서 [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html)를 참조하세요.
### Valkey 또는 Redis OSS 복제 그룹 스케일 업(ElastiCache API)
다음 절차는 ElastiCache API를 사용하여 복제 그룹을 현재 노드 유형에서 새로운 대형 노드 유형으로 조정합니다. Valkey 7.2 이상 또는 Redis OSS 5.0.5 이상의 경우 클러스터가 계속 온라인 상태를 유지하고 들어오는 요청을 처리하는 동안 자동 장애 조치(failover) 지원 클러스터를 조정할 수 있습니다. Redis OSS 버전 4.0.10 이하의 경우, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다.
대형 노드 유형으로 스케일 업하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
**Valkey 또는 Redis OSS 복제 그룹 스케일 업하려면(ElastiCache API)**
1. 다음 파라미터와 함께 ElastiCache API `ListAllowedNodeTypeModifications` 작업을 사용하여 확장할 수 있는 노드 유형을 확인합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) 섹션을 참조하세요.
1. 다음 파라미터와 함께 `ModifyReplicationGroup` ElastiCache API 작업을 사용하여 현재 복제 그룹을 새 노드 유형으로 확장합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다.
+ `CacheNodeType` - 이 복제 그룹에 있는 클러스터의 새로운 대형 노드 유형입니다. 이 값은 이전 단계의 `ListAllowedNodeTypeModifications` 작업에 의해 반환되는 인스턴스 유형 중 하나여야 합니다.
+ `CacheParameterGroupName` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `ApplyImmediately` - 스케일 업 프로세스가 즉시 적용되도록 하려면 `true`로 설정합니다. 스케일 업 프로세스를 다음 유지 관리 기간으로 연기하려면 `ApplyImmediately``=false`를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 섹션을 참조하세요.
1. `ApplyImmediately``=true`를 사용한 경우 ElastiCache API `DescribeReplicationGroups` 작업을 다음 파라미터와 함께 사용하여 복제 그룹의 상태를 모니터링합니다. 상태가 *수정 중*에서 *사용 가능*으로 변경되면 스케일 업된 새 복제 그룹에 쓰기를 시작할 수 있습니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) 섹션을 참조하세요.
## 복제본이 있는 Valkey 또는 Redis OSS 클러스터 스케일 다운
다음 섹션에서는 복제본 노드가 있는 Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터를 소형 노드 유형으로 축소하는 방법을 살펴봅니다. 성공을 위해 새로운 소형 노드 유형이 모든 데이터와 오버헤드를 수용할 만큼 충분히 큰지 확인하는 것이 매우 중요합니다. 자세한 내용은 [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md) 단원을 참조하십시오.
**참고**
r6gd 노드 유형을 실행하는 클러스터의 경우 r6gd 노드 패밀리 내의 노드 크기로만 조정할 수 있습니다.
**중요**
파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 조정을 시작하기 전에 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹이 있어야 합니다. 또는 `reserved-memory-percent`를 사용하고 새 클러스터에 대해 해당 파라미터 그룹을 사용하도록 사용자 지정 파라미터 그룹을 수정할 수 있습니다.
`reserved-memory-percent`를 사용할 경우에는 이렇게 하지 않아도 됩니다.
자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
**Topics**
### 복제본을 사용하여 Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)
다음 절차는 ElastiCache 콘솔을 사용하여 복제본 노드가 있는 Valkey 또는 Redis OSS 클러스터를 소형 노드 유형으로 조정합니다.
**복제본 노드가 있는 Valkey 또는 Redis OSS 클러스터를 스케일 다운하려면(콘솔)**
1. 소형 노드 유형이 데이터 및 오버헤드 요구 사항에 적합한지 확인합니다.
1. 파라미터 그룹이 `reserved-memory`를 사용하여 Valkey 또는 Redis OSS 오버헤드에 대한 메모리를 구분한 경우, 새 노드 유형에 대해 올바른 메모리 양을 구분하는 사용자 지정 파라미터 그룹이 있어야 합니다.
또는 `reserved-memory-percent`를 사용하여 사용자 지정 파라미터 그룹을 수정할 수 있습니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오.
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 클러스터 목록에서 스케일 다운할 클러스터를 선택합니다. 이 클러스터는 Clustered Valkey 또는 Redis OSS 엔진이 아닌 Valkey 또는 Redis OSS 엔진을 실행해야 합니다.
1. **수정**을 선택합니다.
1. [**Modify Cluster**] 마법사에서 다음을 수행합니다.
1. [**Node type**] 목록에서 스케일 다운할 노드 유형을 선택합니다.
1. `reserved-memory`를 사용하여 메모리를 관리할 경우 [**Parameter Group**] 목록에서 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 파라미터 그룹을 선택합니다.
1. 스케일 다운 프로세스를 즉시 수행하려면 [**Apply immediately**] 확인란을 선택합니다. [**Apply immediately**] 확인란을 선택하지 않고 비워 두면 이 클러스터의 다음 유지 관리 기간 중 스케일 다운 프로세스가 수행됩니다.
1. **수정**을 선택합니다.
1. 클러스터의 상태가 *수정 중*에서 *사용 가능*으로 변경되면 클러스터가 새 노드 유형으로 조정된 것입니다. 애플리케이션에서 엔드포인트를 업데이트할 필요가 없습니다.
### Valkey 또는 Redis OSS 복제 그룹 스케일 다운(AWS CLI)
다음 절차는AWS CLI를 사용하여 복제 그룹을 현재 노드 유형에서 새롭고 더 작은 노드 유형으로 조정합니다. 이 프로세스 중에 ElastiCache는 DNS 항목이 새 노드를 가리키도록 해당 항목을 업데이트합니다. 따라서 애플리케이션의 엔드포인트를 업데이트할 필요가 없습니다. Valkey 7.2 이상 또는 Redis OSS 5.0.5 이상의 경우 클러스터가 계속 온라인 상태를 유지하고 들어오는 요청을 처리하는 동안 자동 장애 조치(failover) 지원 클러스터를 조정할 수 있습니다. 버전 4.0.10 이하의 경우, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다.
그러나 읽기 전용 복제본 클러스터에서 읽기는 계속 중단되지 않습니다.
더 작은 노드 유형으로 축소하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
**Valkey 또는 Redis OSS 복제 그룹을 스케일 다운하려면(AWS CLI)**
1. 다음 파라미터로AWS CLI`list-allowed-node-type-modifications` 명령을 실행하여 축소할 수 있는 노드 유형을 결정합니다.
+ `--replication-group-id` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Windows의 경우:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
이 작업의 출력은 다음과 같습니다(JSON 형식).
```
{
"ScaleDownModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
```
자세한 내용은 *AWS CLI참조*의 [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) 섹션을 참조하세요.
1. 다음 파라미터와 함께 `modify-replication-group` 명령을 사용하여AWS CLI현재 복제 그룹을 새 노드 유형으로 확장합니다.
+ `--replication-group-id` - 복제 그룹의 이름입니다.
+ `--cache-node-type` - 이 복제 그룹에 있는 클러스터의 새롭고 더 작은 노드 유형입니다. 이 값은 이전 단계의 `list-allowed-node-type-modifications` 명령에 의해 반환되는 인스턴스 유형 중 하나여야 합니다.
+ `--cache-parameter-group-name` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `--apply-immediately` - 스케일 업 프로세스가 즉시 적용되도록 합니다. 스케일 업 작업을 다음 유지 관리 기간으로 연기하려면 `--no-apply-immediately`를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id my-repl-group \
--cache-node-type cache.t2.small \
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id my-repl-group ^
--cache-node-type cache.t2.small ^
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
이 명령의 출력은 다음과 같습니다(JSON 형식).
```
{"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002",
],
"PendingModifiedValues": {}
}
}
```
자세한 내용은 *AWS CLI참조*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 섹션을 참조하세요.
1. `--apply-immediately` 파라미터를 사용한 경우 다음 파라미터와 함께 `describe-replication-group` 명령을 사용하여AWS CLI복제 그룹의 상태를 모니터링합니다. 상태가 *수정 중*에서 *사용 가능*으로 변경되면 축소된 새 복제 그룹에 쓰기를 시작할 수 있습니다.
+ `--replication-group-id` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache describe-replication-group \
--replication-group-id my-replication-group
```
Windows의 경우:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
자세한 내용은 *AWS CLI참조*에서 [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html)를 참조하세요.
### Valkey 또는 Redis OSS 복제 그룹 스케일 다운(ElastiCache API)
다음 절차는 ElastiCache API를 사용하여 복제 그룹을 현재 노드 유형에서 새롭고 더 작은 노드 유형으로 조정합니다. 이 프로세스 중에 ElastiCache는 DNS 항목이 새 노드를 가리키도록 해당 항목을 업데이트합니다. 따라서 애플리케이션의 엔드포인트를 업데이트할 필요가 없습니다. Valkey 7.2 이상 또는 Redis OSS 5.0.5 이상의 경우 클러스터가 계속 온라인 상태를 유지하고 들어오는 요청을 처리하는 동안 자동 장애 조치(failover) 지원 클러스터를 조정할 수 있습니다. Redis OSS 버전 4.0.10 이하에서, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다. 그러나 읽기 전용 복제본 클러스터에서 읽기는 계속 중단되지 않습니다.
더 작은 노드 유형으로 축소하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
**Valkey 또는 Redis OSS 복제 그룹 스케일 다운하려면(ElastiCache API)**
1. 다음 파라미터와 함께 ElastiCache API `ListAllowedNodeTypeModifications` 작업을 사용하여 축소할 수 있는 노드 유형을 확인합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) 섹션을 참조하세요.
1. 다음 파라미터와 함께 `ModifyReplicationGroup` ElastiCache API 작업을 사용하여 현재 복제 그룹을 새 노드 유형으로 확장합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다.
+ `CacheNodeType` - 이 복제 그룹에 있는 클러스터의 새롭고 더 작은 노드 유형입니다. 이 값은 이전 단계의 `ListAllowedNodeTypeModifications` 작업에 의해 반환되는 인스턴스 유형 중 하나여야 합니다.
+ `CacheParameterGroupName` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `ApplyImmediately` - 스케일 업 프로세스가 즉시 적용되도록 하려면 `true`로 설정합니다. 축소 프로세스를 다음 유지 관리 기간으로 연기하려면 `ApplyImmediately``=false`를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 섹션을 참조하세요.
1. `ApplyImmediately``=true`를 사용한 경우 ElastiCache API `DescribeReplicationGroups` 작업을 다음 파라미터와 함께 사용하여 복제 그룹의 상태를 모니터링합니다. 상태가 *수정 중*에서 *사용 가능*으로 변경되면 축소된 새 복제 그룹에 쓰기를 시작할 수 있습니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) 섹션을 참조하세요.
## 읽기 용량 늘리기
읽기 용량을 늘리려면 읽기 전용 복제본(최대 5개)을 Valkey 또는 Redis OSS 복제 그룹에 추가합니다.
ElastiCache 콘솔, 또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS 클러스터의 읽기 용량을 조정할 수 ElastiCache.AWS CLI자세한 내용은 [Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 추가(클러스터 모드 비활성화됨)](Replication.AddReadReplica.md) 단원을 참조하십시오.
## 읽기 용량 줄이기
읽기 용량을 줄이려면 복제본이 있는 Valkey 또는 Redis OSS 클러스터(API/CLI에서 *복제 그룹*이라고 함)에서 하나 이상의 읽기 전용 복제본을 삭제합니다. 클러스터가 자동 장애 조치가 활성화된 다중 AZ인 경우 먼저 다중 AZ를 비활성화해야 마지막 읽기 전용 복제본을 삭제할 수 있습니다. 자세한 내용은 [복제 그룹 수정](Replication.Modify.md) 단원을 참조하십시오.
자세한 내용은 [Valkey 또는 Redis OSS에 대한 읽기 전용 복제본 삭제(클러스터 모드 비활성화됨)](Replication.RemoveReadReplica.md) 단원을 참조하십시오.
# Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 규모 조정
클러스터에 대한 수요 변화에 따라 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 내 샤드 수를 변경해 성능을 향상시키거나 비용을 줄이도록 결정할 수 있습니다. 이와 같이 하려면 온라인 수평적 조정을 사용하는 것이 좋은데, 이 방법은 조정 프로세스 중에도 클러스터가 계속해서 요청을 처리하도록 하기 때문입니다.
클러스터를 다시 조정하도록 결정할 수 있는 조건은 다음과 같습니다.
+ **메모리 부족:**
클러스터의 노드에서 메모리가 부족하면 데이터를 저장 및 요청 처리에 더 많은 리소스를 사용하도록 확장을 결정할 수 있습니다.
*FreeableMemory*, *SwapUsage* 및 *BytesUsedForCache* 지표를 모니터링해 노드에서 메모리가 부족한지 확인할 수 있습니다.
+ **CPU 또는 네트워크 병목 현상:**
클러스터에서 지연 시간/처리량 문제가 발생하면 문제를 해결하기 위해 확장이 필요할 수 있습니다.
*CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections* 및 *NewConnections* 지표를 모니터링해 지연 시간 및 처리량 수준을 모니터링할 수 있습니다.
+ **클러스터가 과도하게 조정됨:**
축소와 같은 클러스터에 대한 현재 수요는 성능을 저하시키지 않고 비용을 줄입니다.
다음 *FreeableMemory*, *SwapUsage*, *BytesUsedForCache*, *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections* 및 *NewConnections* 지표를 사용하여 클러스터의 사용을 모니터링해 안전하게 스케일 인할 수 있는지 확인할 수 있습니다.
**조정의 성능 영향**
오프라인 프로세스를 사용해 조정하는 경우, 프로세스 중 상당 부분에서 클러스터가 오프라인 상태가 되기 때문에 요청을 처리할 수 없습니다. 온라인 방법을 사용해 조정하는 경우, 클러스터가 조정 작업 전체에서 계속해서 요청을 처리할 수 있음에도 불구하고 조정은 컴퓨팅 집약적인 작업이기 때문에 성능 저하가 발생합니다. 저하 정도는 일반적인 CPU 사용률과 데이터에 따라 달라집니다.
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 조정하는 방법에는 수평적 스케일링과 수직적 스케일링이라는 두 가지 방법이 있습니다.
+ 수평 확장에서는 노드 그룹(샤드)을 추가 또는 제거하여 복제 그룹 내 노드 그룹(샤드) 수를 변경할 수 있습니다. 온라인 리샤딩 프로세스를 통해 클러스터가 들어오는 요청을 계속 처리하는 동안 확장/축소할 수 있습니다.
새 클러스터에서 이전 클러스터에서와 달리 슬롯을 구성합니다. 오프라인 방법에만 해당합니다.
+ 수직 확장 - 노드 유형을 변경하여 클러스터의 크기를 조정합니다. 온라인 수직 확장을 통해 클러스터가 들어오는 요청을 계속 처리하는 동안 확장/축소할 수 있습니다.
클러스터의 크기 및 메모리 용량을 스케일 인하거나 스케일 다운하여 줄이는 경우, 새 구성에 데이터 및 Valkey 또는 Redis OSS 오버헤드가 충분한 메모리가 있는지 확인합니다.
자세한 내용은 [노드 크기 선택](CacheNodes.SelectSize.md) 단원을 참조하십시오.
**Contents**
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 오프라인 리샤딩](#redis-cluster-resharding-offline)
+ [Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 온라인 리샤딩](#redis-cluster-resharding-online)
+ [온라인 리샤딩을 사용하여 샤드 추가](#redis-cluster-resharding-online-add)
+ [온라인 리샤딩을 사용하여 샤드 제거](#redis-cluster-resharding-online-remove)
+ [샤드 제거(콘솔)](#redis-cluster-resharding-online-remove-console)
+ [샤드 제거(AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [샤드 제거(ElastiCache API)](#redis-cluster-resharding-online-remove-api)
+ [온라인 샤드 재분배](#redis-cluster-resharding-online-rebalance)
+ [온라인 샤드 재분배(콘솔)](#redis-cluster-resharding-online-rebalance-console)
+ [온라인 샤드 재분배(AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [온라인 샤드 재분배(ElastiCache API)](#redis-cluster-resharding-online-rebalance-api)
+ [노드 유형 수정하여 온라인 수직 조정](redis-cluster-vertical-scaling.md)
+ [온라인 확장](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(콘솔)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-console)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(AWS CLI)](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(ElastiCache API)](redis-cluster-vertical-scaling.md#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [온라인 축소](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-down)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-down-console)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)](redis-cluster-vertical-scaling.md#Scaling.Vertical.ScaleDown.API)
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 오프라인 리샤딩
오프라인 리샤딩 재구성의 주요 이점은 복제 그룹에서 단순히 샤드를 추가 또는 제거하는 것 이상을 할 수 있다는 점입니다. 오프라인 리샤딩 및 리밸런싱 시 복제 그룹의 샤드 수를 변경하는 것 이외에 다음을 수행할 수 있습니다.
**참고**
데이터 계층화가 활성화된 Valkey 또는 Redis OSS 클러스터에서는 오프라인 리샤딩이 지원되지 않습니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 단원을 참조하십시오.
+ 복제 그룹의 노드 유형을 변경합니다.
+ 복제 그룹의 각 노드에 대한 가용 영역을 지정합니다.
+ 최신 엔진 버전으로 업그레이드합니다.
+ 각 샤드 내 복제 노드 수를 독립적으로 지정합니다.
+ 각 샤드에 대한 키스페이스를 지정합니다.
오프라인 샤드 재구성의 주요 단점은 프로세스의 복원 부분에서 클러스터가 오프라인 상태가 되어 애플리케이션에서 엔드포인트를 업데이트할 때까지 이 상태가 지속된다는 점입니다. 클러스터가 오프라인 상태도 지속되는 기간은 클러스터 내 데이터의 양에 따라 달라집니다.
**샤드 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 오프라인 상태에서 재구성하려면**
1. 기존 Valkey 또는 Redis OSS 클러스터의 수동 백업을 생성합니다. 자세한 내용은 [수동 백업 지원](backups-manual.md) 단원을 참조하십시오.
1. 백업에서 복원해 새 클러스터를 생성합니다. 자세한 내용은 [백업에서 새 캐시로 복원](backups-restoring.md) 단원을 참조하십시오.
1. 애플리케이션에서 엔드포인트를 새 클러스터의 엔드포인트로 업데이트합니다. 자세한 내용은 [ElastiCache에서 연결 엔드포인트 찾기](Endpoints.md) 단원을 참조하십시오.
## Valkey 또는 Redis OSS(클러스터 모드 활성화됨)에 대한 온라인 리샤딩
ElastiCache Valkey 7.2 이상 또는 Redis OSS 버전 3.2.10 이상에서 온라인 리샤딩 및 샤드 리밸런싱을 사용하면 가동 중지 시간 없이 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 동적으로 확장할 수 있습니다. 이러한 접근 방식은 조정 또는 재분배 진행 중에도 클러스터에서 계속해서 요청을 처리할 수 있음을 의미합니다.
다음을 수행할 수 있습니다.
+ **스케일 아웃** - Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터(복제 그룹)에 샤드(노드 그룹)를 추가해 읽기 및 쓰기 용량을 늘립니다.
복제 그룹에 샤드를 하나 이상 추가하는 경우 각 샤드의 노드 수는 기존의 가장 작은 샤드에 있는 노드 수와 동일합니다.
+ **스케일 인** - Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 제거해 읽기 및 쓰기 용량을 줄여 비용을 절감합니다.
+ **재분배** - Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드 간에 키스페이스를 이동해 샤드 간에 키스페이스가 가급적 균일하게 분배되도록 합니다.
다음을 수행할 수 없습니다.
+ **독립적으로 샤드 구성:**
샤드의 키스페이스는 독립적으로 지정할 수 없습니다. 이렇게 하려면 오프라인 프로세스를 사용해야 합니다.
현재, ElastiCache 온라인 리샤딩 및 리밸런싱에는 다음 제한 사항이 적용됩니다.
+ 이러한 프로세스에는 Valkey 7.2 이상 또는 Redis OSS 3.2.10 이상이 필요합니다. 엔진 버전 업그레이드에 대한 자세한 내용은 [ElastiCache용 버전 관리](VersionManagement.md) 섹션을 참조하세요.
+ 슬롯 또는 키스페이스와 대용량 항목에 대한 제한 사항이 있습니다.
샤드 내 키에 대용량 항목이 포함되어 있으면 확장 또는 재분배 시 해당 키가 새 샤드로 마이그레이션되지 않습니다. 이 기능으로 인해 불균형 샤드가 발생할 수 있습니다.
샤드 내 키에 대용량 항목(직렬화 후 256MB보다 큰 항목)이 포함되어 있으면 축소 시 해당 샤드는 삭제되지 않습니다. 이 기능으로 인해 일부 샤드가 삭제되지 않을 수 있습니다.
+ 확장 시 새 샤드의 노드 수는 기존의 가장 작은 노드 수와 동일합니다.
+ 확장 시 기존의 모든 샤드에 공통된 태그는 새 샤드로 복사됩니다.
+ 글로벌 데이터 스토어 클러스터를 스케일 아웃할 때, ElastiCache는 기존 노드 중 하나에서 새 노드로 함수를 자동으로 복제하지 않습니다. 클러스터를 스케일 아웃한 후, 새 샤드에 함수를 로드하여 모든 샤드가 동일한 함수를 갖도록 하는 것이 좋습니다.
**참고**
ElastiCache for Valkey 7.2 이상 및 ElastiCache for Redis OSS 버전 7 이상: 클러스터를 스케일 아웃할 때 ElastiCache는 기존 노드 중 하나(임의로 선택됨)에 로드된 함수를 새 노드에 자동으로 복제합니다. 애플리케이션이 [함수](https://valkey.io/topics/functions-intro/)를 사용하는 경우, 모든 함수를 모든 샤드에 로드해야 스케일 아웃으로 인해 클러스터가 샤드마다 다른 함수 정의로 종결되는 상황을 방지할 수 있습니다.
자세한 내용은 [온라인 클러스터 크기 조정](best-practices-online-resharding.md) 단원을 참조하십시오.
AWS Management Console,AWS CLI및 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터를 수평적으로 조정 또는 재분배할 수 있습니다.
### 온라인 리샤딩을 사용하여 샤드 추가
AWS Management ConsoleAWS CLI또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에 샤드를 추가할 수 있습니다. Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에 샤드를 추가하면 기존 샤드의 모든 태그가 새 샤드로 복사됩니다.
**Topics**
#### 샤드 추가(콘솔)
AWS Management Console를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에 하나 이상의 샤드를 추가할 수 있습니다. 다음 절차에서는 이러한 프로세스를 설명합니다.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에 샤드를 추가하려면**
1. [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 클러스터** 또는 **Redis OSS 클러스터**를 선택합니다.
1. 샤드를 추가하고자 하는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 이름 왼쪽에 있는 상자가 아닌 클러스터의 이름을 찾아 선택합니다.
**작은 정보**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨)는 **모드** 열에 **Clustered Valkey** 또는 **Clustered Redis OSS**를 표시합니다.
1. [**Add shard**]를 선택합니다.
1. [**Number of shards to be added**]에서 이 클러스터에 추가할 샤드 수를 선택합니다.
1. [**Availability zone(s)**]에서는 [**No preference**] 또는 [**Specify availability zones**]을 선택합니다.
1. [**Specify availability zones**]를 선택한 경우 각 샤드의 각 노드에 대해 [Availability Zones] 목록에서 노드의 가용 영역을 선택합니다.
1. **추가**를 선택합니다.
#### 샤드 추가(AWS CLI)
다음 프로세스에서는AWS CLI를 사용해 샤드를 추가하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
`modify-replication-group-shard-configuration`에 다음 파라미터를 사용합니다.
**Parameters**
+ `--apply-immediately` - 필수입니다. 즉시 시작할 샤드 재구성 작업을 지정합니다.
+ `--replication-group-id` - 필수입니다. 샤드 재구성 작업을 수행할 복제 그룹(클러스터)을 지정합니다.
+ `--node-group-count` - 필수입니다. 작업 완료 시 존재할 샤드(노드 그룹) 수를 지정합니다. 샤드를 추가하는 경우 `--node-group-count`의 값은 현재 샤드 수보다 커야 합니다.
경우에 따라 `--resharding-configuration`을 사용해 복제 그룹의 각 노드에 대한 가용 영역을 지정할 수 있습니다.
+ `--resharding-configuration` – 선택 사항입니다. 복제 그룹 내에 있는 각 샤드의 개별 노드에 대한 기본 가용 영역 목록입니다. 이 파라미터는 `--node-group-count`의 값이 현재 샤드 수보다 큰 경우에만 사용합니다. 샤드 추가 시 이 파라미터를 사용하지 않으면 Amazon ElastiCache에서는 새 노드에 대해 가용 영역을 선택합니다.
다음 예에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) `my-cluster`이라는 클러스터에서 샤드 4개에 대한 키스페이스를 재구성합니다. 또한 이 예에서는 각 샤드 내 개별 노드에 대한 가용 영역을 지정합니다. 작업이 즉시 시작됩니다.
**Example - 샤드 추가**
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--resharding-configuration \
"PreferredAvailabilityZones=us-east-2a,us-east-2c" \
"PreferredAvailabilityZones=us-east-2b,us-east-2a" \
"PreferredAvailabilityZones=us-east-2c,us-east-2d" \
"PreferredAvailabilityZones=us-east-2d,us-east-2c" \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--resharding-configuration ^
"PreferredAvailabilityZones=us-east-2a,us-east-2c" ^
"PreferredAvailabilityZones=us-east-2b,us-east-2a" ^
"PreferredAvailabilityZones=us-east-2c,us-east-2d" ^
"PreferredAvailabilityZones=us-east-2d,us-east-2c" ^
--apply-immediately
```
자세한 내용은AWS CLI설명서의 [modify-replication-group-shard-configuration](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html)을 참조하세요.
#### 샤드 추가(ElastiCache API)
ElastiCache API에서 `ModifyReplicationGroupShardConfiguration` 작업을 사용해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 내 샤드를 온라인으로 재구성할 수 있습니다.
`ModifyReplicationGroupShardConfiguration`에 다음 파라미터를 사용합니다.
**Parameters**
+ `ApplyImmediately=true` - 필수입니다. 즉시 시작할 샤드 재구성 작업을 지정합니다.
+ `ReplicationGroupId` - 필수입니다. 샤드 재구성 작업을 수행할 복제 그룹(클러스터)을 지정합니다.
+ `NodeGroupCount` - 필수입니다. 작업 완료 시 존재할 샤드(노드 그룹) 수를 지정합니다. 샤드를 추가하는 경우 `NodeGroupCount`의 값은 현재 샤드 수보다 커야 합니다.
경우에 따라 `ReshardingConfiguration`을 사용해 복제 그룹의 각 노드에 대한 가용 영역을 지정할 수 있습니다.
+ `ReshardingConfiguration` – 선택 사항입니다. 복제 그룹 내에 있는 각 샤드의 개별 노드에 대한 기본 가용 영역 목록입니다. 이 파라미터는 `NodeGroupCount`의 값이 현재 샤드 수보다 큰 경우에만 사용합니다. 샤드 추가 시 이 파라미터를 사용하지 않으면 Amazon ElastiCache에서는 새 노드에 대해 가용 영역을 선택합니다.
다음 프로세스에서는 ElastiCache API를 사용해 샤드를 추가하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
**Example - 샤드 추가**
다음 예에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `my-cluster`에 노드 그룹을 추가해 작업을 완료하면 노드 그룹이 총 4개가 됩니다. 또한 이 예에서는 각 샤드 내 개별 노드에 대한 가용 영역을 지정합니다. 작업이 즉시 시작됩니다.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2a
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2b
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2a
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2c
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
자세한 내용은 ElastiCache API 참조의 [ModifyReplicationGroupShardConfiguration](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)을 참조하세요.
### 온라인 리샤딩을 사용하여 샤드 제거
AWS Management ConsoleAWS CLI또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 제거할 수 있습니다.
**Topics**
+ [샤드 제거(콘솔)](#redis-cluster-resharding-online-remove-console)
+ [샤드 제거(AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [샤드 제거(ElastiCache API)](#redis-cluster-resharding-online-remove-api)
#### 샤드 제거(콘솔)
다음 프로세스에서는AWS Management Console을 사용해 샤드를 제거하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
복제 그룹에서 노드 그룹(샤드)을 제거하기 전에 ElastiCache에서는 모든 데이터가 나머지 샤드에 맞는지 확인합니다. 데이터가 맞으면 요청된 대로 지정된 샤드가 복제 그룹에서 삭제됩니다. 데이터가 나머지 노드 그룹에 맞지 않으면 프로세스가 종료되고 복제 그룹은 요청이 작성되기 전과 동일한 노드 그룹 구성으로 남습니다.
AWS Management Console를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 하나 이상의 샤드를 제거할 수 있습니다. 복제 그룹에서 샤드를 모두 제거할 수는 없습니다. 대신 복제 그룹을 삭제해야 합니다. 자세한 내용은 [복제 그룹 삭제](Replication.DeletingRepGroup.md) 단원을 참조하십시오. 다음 절차는 샤드를 하나 이상 삭제하는 프로세스를 설명합니다.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 제거하려면**
1. [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 클러스터** 또는 **Redis OSS 클러스터**를 선택합니다.
1. 샤드를 제거하고자 하는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 이름 왼쪽에 있는 상자가 아닌 클러스터의 이름을 찾아 선택합니다.
**작은 정보**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 **샤드** 열에는 1보다 크거나 같은 값이 있습니다.
1. 샤드 목록에서 삭제하고자 하는 각 샤드의 이름 왼쪽에 있는 상자를 선택합니다.
1. [**Delete shard**]를 선택합니다.
#### 샤드 제거(AWS CLI)
다음 프로세스에서는AWS CLI을 사용해 샤드를 제거하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
**중요**
복제 그룹에서 노드 그룹(샤드)을 제거하기 전에 ElastiCache에서는 모든 데이터가 나머지 샤드에 맞는지 확인합니다. 데이터가 맞으면 요청된 대로 지정된 샤드(`--node-groups-to-remove`)가 복제 그룹에서 삭제되고 해당 샤드의 키스페이스가 나머지 샤드로 매핑됩니다. 데이터가 나머지 노드 그룹에 맞지 않으면 프로세스가 종료되고 복제 그룹은 요청이 작성되기 전과 동일한 노드 그룹 구성으로 남습니다.
AWS CLI를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 하나 이상의 샤드를 제거할 수 있습니다. 복제 그룹에서 샤드를 모두 제거할 수는 없습니다. 대신 복제 그룹을 삭제해야 합니다. 자세한 내용은 [복제 그룹 삭제](Replication.DeletingRepGroup.md) 단원을 참조하십시오.
`modify-replication-group-shard-configuration`에 다음 파라미터를 사용합니다.
**Parameters**
+ `--apply-immediately` - 필수입니다. 즉시 시작할 샤드 재구성 작업을 지정합니다.
+ `--replication-group-id` - 필수입니다. 샤드 재구성 작업을 수행할 복제 그룹(클러스터)을 지정합니다.
+ `--node-group-count` - 필수입니다. 작업 완료 시 존재할 샤드(노드 그룹) 수를 지정합니다. 샤드를 제거하는 경우 `--node-group-count`의 값은 현재 샤드 수보다 작아야 합니다.
+ `--node-groups-to-remove` - `--node-group-count`가 노드 그룹(샤드)의 현재 수보다 작은 경우에만 필요합니다. 복제 그룹에서 제거할 샤드(노드 그룹) ID 목록입니다.
다음 절차는 샤드를 하나 이상 삭제하는 프로세스를 설명합니다.
**Example - 샤드 제거**
다음 예에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `my-cluster`에서 노드 그룹 두 개를 제거해 작업을 완료하면 노드 그룹이 총 2개가 됩니다. 제거된 샤드의 키스페이스는 나머지 샤드 간에 균일하게 분배됩니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 2 \
--node-groups-to-remove "0002" "0003" \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 2 ^
--node-groups-to-remove "0002" "0003" ^
--apply-immediately
```
#### 샤드 제거(ElastiCache API)
ElastiCache API에서 `ModifyReplicationGroupShardConfiguration` 작업을 사용해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 내 샤드를 온라인으로 재구성할 수 있습니다.
다음 프로세스에서는 ElastiCache API를 사용해 샤드를 제거하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
**중요**
복제 그룹에서 노드 그룹(샤드)을 제거하기 전에 ElastiCache에서는 모든 데이터가 나머지 샤드에 맞는지 확인합니다. 데이터가 맞으면 요청된 대로 지정된 샤드(`NodeGroupsToRemove`)가 복제 그룹에서 삭제되고 해당 샤드의 키스페이스가 나머지 샤드로 매핑됩니다. 데이터가 나머지 노드 그룹에 맞지 않으면 프로세스가 종료되고 복제 그룹은 요청이 작성되기 전과 동일한 노드 그룹 구성으로 남습니다.
ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 하나 이상 제거할 수 있습니다. 복제 그룹에서 샤드를 모두 제거할 수는 없습니다. 대신 복제 그룹을 삭제해야 합니다. 자세한 내용은 [복제 그룹 삭제](Replication.DeletingRepGroup.md) 단원을 참조하십시오.
`ModifyReplicationGroupShardConfiguration`에 다음 파라미터를 사용합니다.
**Parameters**
+ `ApplyImmediately=true` - 필수입니다. 즉시 시작할 샤드 재구성 작업을 지정합니다.
+ `ReplicationGroupId` - 필수입니다. 샤드 재구성 작업을 수행할 복제 그룹(클러스터)을 지정합니다.
+ `NodeGroupCount` - 필수입니다. 작업 완료 시 존재할 샤드(노드 그룹) 수를 지정합니다. 샤드를 제거하는 경우 `NodeGroupCount`의 값은 현재 샤드 수보다 작아야 합니다.
+ `NodeGroupsToRemove` - `--node-group-count`가 노드 그룹(샤드)의 현재 수보다 작은 경우에만 필요합니다. 복제 그룹에서 제거할 샤드(노드 그룹) ID 목록입니다.
다음 절차는 샤드를 하나 이상 삭제하는 프로세스를 설명합니다.
**Example - 샤드 제거**
다음 예에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `my-cluster`에서 노드 그룹 두 개를 제거해 작업을 완료하면 노드 그룹이 총 2개가 됩니다. 제거된 샤드의 키스페이스는 나머지 샤드 간에 균일하게 분배됩니다.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=2
&ReplicationGroupId=my-cluster
&NodeGroupsToRemove.member.1=0002
&NodeGroupsToRemove.member.2=0003
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
### 온라인 샤드 재분배
AWS Management ConsoleAWS CLI또는 ElastiCache API를 사용하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 샤드를 리밸런싱할 수 있습니다.
**Topics**
+ [온라인 샤드 재분배(콘솔)](#redis-cluster-resharding-online-rebalance-console)
+ [온라인 샤드 재분배(AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [온라인 샤드 재분배(ElastiCache API)](#redis-cluster-resharding-online-rebalance-api)
#### 온라인 샤드 재분배(콘솔)
다음 프로세스에서는AWS Management Console을 사용해 샤드를 재분배하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
**Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드 간에 키스페이스를 재분배하려면**
1. [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)에서 ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 클러스터** 또는 **Redis OSS 클러스터**를 선택합니다.
1. 재분배하고자 하는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 이름 왼쪽에 있는 상자가 아닌 클러스터의 이름을 선택합니다.
**작은 정보**
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터의 **샤드** 열에는 1보다 크거나 같은 값이 있습니다.
1. [**Rebalance**]를 선택합니다.
1. 메시지가 나타나면 **Rebalance**를 선택합니다. 다음과 유사한 메시지가 표시될 수 있습니다. *Slots in the replication group are uniformly distributed. Nothing to do. (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidReplicationGroupState; Request ID: 2246cebd-9721-11e7-8d5b-e1b0f086c8cf)*. 이러한 메시지가 표시되면 [**Cancel**]을 선택합니다.
#### 온라인 샤드 재분배(AWS CLI)
`modify-replication-group-shard-configuration`에 다음 파라미터를 사용합니다.
**Parameters**
+ `-apply-immediately` - 필수입니다. 즉시 시작할 샤드 재구성 작업을 지정합니다.
+ `--replication-group-id` - 필수입니다. 샤드 재구성 작업을 수행할 복제 그룹(클러스터)을 지정합니다.
+ `--node-group-count` - 필수입니다. 클러스터 내 모드 샤드 간에 키스페이스를 재분배하려면 이 값이 현재 샤드 수와 동일해야 합니다.
다음 프로세스에서는AWS CLI을 사용해 샤드를 재분배하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
**Example - 클러스터에서 샤드 재분배**
다음 예에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `my-cluster`에서 슬롯을 재분배하여 슬롯이 가급적 균일하게 분산되도록 합니다. `--node-group-count`(`4`)의 값은 클러스터 내 현재 샤드 수입니다.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--apply-immediately
```
#### 온라인 샤드 재분배(ElastiCache API)
ElastiCache API에서 `ModifyReplicationGroupShardConfiguration` 작업을 사용해 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 내 샤드를 온라인으로 재구성할 수 있습니다.
`ModifyReplicationGroupShardConfiguration`에 다음 파라미터를 사용합니다.
**Parameters**
+ `ApplyImmediately=true` - 필수입니다. 즉시 시작할 샤드 재구성 작업을 지정합니다.
+ `ReplicationGroupId` - 필수입니다. 샤드 재구성 작업을 수행할 복제 그룹(클러스터)을 지정합니다.
+ `NodeGroupCount` - 필수입니다. 클러스터 내 모드 샤드 간에 키스페이스를 재분배하려면 이 값이 현재 샤드 수와 동일해야 합니다.
다음 프로세스에서는 ElastiCache API를 사용해 샤드를 재분배하여 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터에서 샤드를 재구성하는 방법을 설명합니다.
**Example - 클러스터 재분배**
다음 예에서는 Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터 `my-cluster`에서 슬롯을 재분배하여 슬롯이 가급적 균일하게 분산되도록 합니다. `NodeGroupCount`(`4`)의 값은 클러스터 내 현재 샤드 수입니다.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
# 노드 유형 수정하여 온라인 수직 조정
Valkey 버전 7.2 이상 또는 Redis OSS 버전 3.2.10 이상에서 온라인 수직적 스케일링을 사용하면 가동 중지 시간을 최소화하면서 Valkey 또는 Redis OSS 클러스터를 동적으로 규모를 조정할 수 있습니다. 이를 통해 Valkey 또는 Redis OSS 클러스터는 조정 중에도 요청을 처리할 수 있습니다.
**참고**
데이터 계층화 클러스터(예: r6gd 노드 유형을 사용하는 클러스터)와 데이터 계층화를 사용하지 않는 클러스터(예: r6g 노드 유형을 사용하는 클러스터) 간에는 크기 조정이 지원되지 않습니다. 자세한 내용은 [ElastiCache의 데이터 계층화](data-tiering.md) 단원을 참조하십시오.
다음을 수행할 수 있습니다.
+ **스케일 업** - Valkey 또는 Redis OSS 클러스터의 노드 유형을 더 큰 노드 유형을 사용하도록 조정하여 읽기 및 쓰기 용량을 늘립니다.
ElastiCache에서는 온라인 상태로 요청을 처리하는 동안 클러스터 크기를 동적으로 조정합니다.
+ **축소** - 더 작은 노드를 사용하도록 노드 유형을 조정하여 읽기 및 쓰기 용량을 줄입니다. 마찬가지로, ElastiCache에서는 온라인 상태로 요청을 처리하는 동안 클러스터 크기를 동적으로 조정합니다. 이 경우, 노드를 축소하여 비용을 절감할 수 있습니다.
**참고**
확장 및 축소 프로세스는 새로 선택한 노드 유형을 사용하여 클러스터를 생성하고 새 노드를 이전 노드와 동기화합니다. 원활한 확장/축소 흐름을 위해 다음을 수행합니다.
ENI(탄력적 네트워크 인터페이스) 용량이 충분한지 확인합니다. 축소된 경우, 작은 노드에 예상 트래픽을 흡수할 수 있는 충분한 메모리가 있어야 합니다.
메모리 관리 모범 사례에 대해서는 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md)를 참조합니다.
수직 확장 프로세스는 온라인 상태를 유지하도록 설계되었지만 이전 노드와 새 노드 간의 데이터 동기화에 의존합니다. 데이터 트래픽이 최소 수준일 것으로 예상되는 시간 동안 확장/축소를 시작하는 것이 좋습니다.
가능한 경우, 준비 환경에서 조정 중 애플리케이션 동작을 테스트합니다.
**Contents**
+ [온라인 확장](#redis-cluster-vertical-scaling-scaling-up)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(콘솔)](#redis-cluster-vertical-scaling-console)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(AWS CLI)](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(ElastiCache API)](#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [온라인 축소](#redis-cluster-vertical-scaling-scaling-down)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)](#redis-cluster-vertical-scaling-down-console)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)](#Scaling.Vertical.ScaleDown.API)
## 온라인 확장
**Topics**
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(콘솔)](#redis-cluster-vertical-scaling-console)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(AWS CLI)](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Valkey 또는 Redis OSS 클러스터 스케일 업(ElastiCache API)](#VeticalScaling.RedisReplGrps.ScaleUp.API)
### Valkey 또는 Redis OSS 클러스터 스케일 업(콘솔)
다음 절차에서는 ElastiCache Management Console을 사용하여 Valkey 또는 Redis OSS 클러스터를 스케일 업하는 방법에 대해 설명합니다. 이 프로세스 동안 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**Valkey 또는 Redis OSS 클러스터를 스케일 업하려면(콘솔)**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 클러스터** 또는 **Redis OSS 클러스터**를 선택합니다.
1. 클러스터 목록에서 클러스터를 선택합니다.
1. **수정**을 선택합니다.
1. [**Modify Cluster**] 마법사에서 다음을 수행합니다.
1. [**Node type**] 목록에서 조정할 노드 유형을 선택합니다. 확장하려면, 기존 노드보다 큰 노드 유형을 선택합니다.
1. 확장 프로세스를 즉시 수행하려면 **즉시 적용** 상자를 선택합니다. [**Apply immediately**] 상자를 선택하지 않으면 이 클러스터의 다음 유지 관리 기간 중 스케일 업 프로세스가 수행됩니다.
1. **수정**을 선택합니다.
이전 단계에서 [**Apply immediately**]를 선택한 경우 클러스터의 상태가 *수정 중*으로 변경됩니다. 상태가 *사용 가능*으로 변경되면 수정이 완료되고 새 클러스터의 사용을 시작할 수 있습니다.
### Valkey 또는 Redis OSS 클러스터 스케일 업(AWS CLI)
다음 절차에서는AWS CLI를 사용하여 Valkey 또는 Redis OSS 클러스터를 스케일 업하는 방법에 대해 설명합니다. 이 프로세스 동안 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**Valkey 또는 Redis OSS 클러스터를 스케일 업하려면(AWS CLI)**
1. 다음 파라미터로 `list-allowed-node-type-modifications` 명령을 실행AWS CLI하여 스케일 업할 수 있는 노드 유형을 결정합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Windows의 경우:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium",
"cache.t1.small "
],
}
```
자세한 내용은 *AWS CLI참조*의 [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) 섹션을 참조하세요.
1. 명령과 다음 파라미터를 사용하여AWS CLI`modify-replication-group` 더 큰 새 노드 유형으로 확장하도록 복제 그룹을 수정합니다.
+ `--replication-group-id` - 확장하는 복제 그룹의 이름입니다.
+ `--cache-node-type` - 클러스터를 조정할 새 노드 유형입니다. 이 값은 1단계의 `list-allowed-node-type-modifications` 명령에 의해 반환되는 노드 유형 중 하나여야 합니다.
+ `--cache-parameter-group-name` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `--apply-immediately` - 스케일 업 프로세스가 즉시 적용되도록 합니다. 스케일 업 프로세스를 클러스터의 다음 유지 관리 기간으로 연기하려면 `--no-apply-immediately` 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.m3.xlarge \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.m3.xlarge ^
--apply-immediately
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.m3.xlarge",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
```
자세한 내용은 *AWS CLI참조*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 섹션을 참조하세요.
1. 를 사용한 경우 다음 파라미터와 함께 명령을 사용하여AWS CLI`describe-cache-clusters` 클러스터의 상태를 `--apply-immediately`확인합니다. 상태가 *사용 가능*으로 변경되면 새롭고 더 큰 클러스터 노드를 사용할 수 있습니다.
### Valkey 또는 Redis OSS 클러스터 스케일 업(ElastiCache API)
다음 절차는 ElastiCache API를 사용하여 클러스터를 현재 노드 유형에서 새롭고 더 큰 노드 유형으로 조정합니다. 이 프로세스 중에 ElastiCache는 DNS 항목이 새 노드를 가리키도록 해당 항목을 업데이트합니다. 따라서 애플리케이션의 엔드포인트를 업데이트할 필요가 없습니다. Valkey 7.2 이상 Redis OSS 5.0.5 이상의 경우 클러스터가 계속 온라인 상태를 유지하고 들어오는 요청을 처리하는 동안 자동 장애 조치(failover) 지원 클러스터를 조정할 수 있습니다. Redis OSS 버전 4.0.10 이하의 경우, DNS 항목이 업데이트되는 동안 프라이머리 노드에서 이전 버전에 대한 읽기 및 쓰기가 잠깐 중단될 수 있습니다.
대형 노드 유형으로 스케일 업하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
**Valkey 또는 Redis OSS 캐시 클러스터를 스케일 업하려면(ElastiCache API)**
1. 다음 파라미터와 함께 ElastiCache API `ListAllowedNodeTypeModifications` 작업을 사용하여 확장할 수 있는 노드 유형을 확인합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) 섹션을 참조하세요.
1. 다음 파라미터와 함께 `ModifyReplicationGroup` ElastiCache API 작업을 사용하여 현재 복제 그룹을 새 노드 유형으로 확장합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다.
+ `CacheNodeType` - 이 복제 그룹에 있는 클러스터의 새로운 대형 노드 유형입니다. 이 값은 이전 단계의 `ListAllowedNodeTypeModifications` 작업에 의해 반환되는 인스턴스 유형 중 하나여야 합니다.
+ `CacheParameterGroupName` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `ApplyImmediately` - 스케일 업 프로세스가 즉시 적용되도록 하려면 `true`로 설정합니다. 스케일 업 프로세스를 다음 유지 관리 기간으로 연기하려면 `ApplyImmediately``=false`를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 섹션을 참조하세요.
1. `ApplyImmediately``=true`를 사용한 경우 ElastiCache API `DescribeReplicationGroups` 작업을 다음 파라미터와 함께 사용하여 복제 그룹의 상태를 모니터링합니다. 상태가 *수정 중*에서 *사용 가능*으로 변경되면 스케일 업된 새 복제 그룹에 쓰기를 시작할 수 있습니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) 섹션을 참조하세요.
## 온라인 축소
**Topics**
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)](#redis-cluster-vertical-scaling-down-console)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)](#Scaling.Vertical.ScaleDown.API)
### Valkey 또는 Redis OSS 클러스터 스케일 다운(콘솔)
다음 절차에서는 ElastiCache Management Console을 사용하여 Valkey 또는 Redis OSS 클러스터를 스케일 다운하는 방법에 대해 설명합니다. 이 프로세스 동안 Valkey 또는 Redis OSS 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**Valkey 또는 Redis OSS 클러스터를 스케일 다운하려면(콘솔)**
1. 에 로그인AWS Management Console하고 [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) ElastiCache 콘솔을 엽니다.
1. 탐색 창에서 **Valkey 클러스터** 또는 **Redis OSS 클러스터**를 선택합니다.
1. 클러스터 목록에서 원하는 클러스터를 선택합니다.
1. **수정**을 선택합니다.
1. [**Modify Cluster**] 마법사에서 다음을 수행합니다.
1. [**Node type**] 목록에서 조정할 노드 유형을 선택합니다. 축소하려면, 기존 노드보다 작은 노드 유형을 선택합니다. 모든 노드 유형을 축소할 수 있는 것은 아닙니다.
1. 축소 프로세스를 즉시 수행하려면 **즉시 적용** 상자를 선택합니다. **즉시 적용** 상자를 선택하지 않으면 이 클러스터의 다음 유지 관리 기간 중 축소 프로세스가 수행됩니다.
1. **수정**을 선택합니다.
이전 단계에서 [**Apply immediately**]를 선택한 경우 클러스터의 상태가 *수정 중*으로 변경됩니다. 상태가 *사용 가능*으로 변경되면 수정이 완료되고 새 클러스터의 사용을 시작할 수 있습니다.
### Valkey 또는 Redis OSS 클러스터 스케일 다운(AWS CLI)
다음 절차에서는AWS CLI를 사용하여 Valkey 또는 Redis OSS 클러스터를 스케일 다운하는 방법에 대해 설명합니다. 이 프로세스 동안 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
**Valkey 또는 Redis OSS 클러스터를 스케일 다운하려면(AWS CLI)**
1. 다음 파라미터로 `list-allowed-node-type-modifications` 명령을 실행AWS CLI하여 축소할 수 있는 노드 유형을 결정합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Windows의 경우:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small"
]
}
```
자세한 내용은 *AWS CLI참조*의 [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) 섹션을 참조하세요.
1. 명령과 다음 파라미터를 사용하여AWS CLI`modify-replication-group` 더 작은 새 노드 유형으로 축소하도록 복제 그룹을 수정합니다.
+ `--replication-group-id` - 축소하는 복제 그룹의 이름입니다.
+ `--cache-node-type` - 클러스터를 조정할 새 노드 유형입니다. 이 값은 1단계의 `list-allowed-node-type-modifications` 명령에 의해 반환되는 노드 유형 중 하나여야 합니다.
+ `--cache-parameter-group-name` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `--apply-immediately` - 스케일 업 프로세스가 즉시 적용되도록 합니다. 축소 프로세스를 클러스터의 다음 유지 관리 기간으로 연기하려면 `--no-apply-immediately` 파라미터를 사용하세요.
Linux, macOS, Unix의 경우:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.t2.micro \
--apply-immediately
```
Windows의 경우:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.t2.micro ^
--apply-immediately
```
위 명령의 출력은 다음과 같습니다(JSON 형식).
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.t2.micro",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
```
자세한 내용은 *AWS CLI참조*의 [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) 섹션을 참조하세요.
1. 를 사용한 경우 다음 파라미터와 함께 명령을 사용하여AWS CLI`describe-cache-clusters` 클러스터의 상태를 `--apply-immediately`확인합니다. 상태가 *사용 가능*으로 변경되면 새롭고 더 작은 클러스터 노드를 사용할 수 있습니다.
### Valkey 또는 Redis OSS 클러스터 스케일 다운(ElastiCache API)
다음 절차는 ElastiCache API를 사용하여 복제 그룹을 현재 노드 유형에서 새롭고 더 작은 노드 유형으로 조정합니다. 이 프로세스 동안 Valkey 또는 Redis OSS 클러스터는 가동 중지 시간을 최소화하면서 요청을 계속 처리합니다.
더 작은 노드 유형으로 축소하는 데 걸리는 시간은 노드 유형 및 현재 클러스터에 있는 데이터의 양에 따라 달라집니다.
**축소(ElastiCache API)**
1. 다음 파라미터와 함께 ElastiCache API `ListAllowedNodeTypeModifications` 작업을 사용하여 축소할 수 있는 노드 유형을 확인합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다. 모든 복제 그룹 대신 특정 복제 그룹을 설명하려면 이 파라미터를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) 섹션을 참조하세요.
1. 다음 파라미터와 함께 `ModifyReplicationGroup` ElastiCache API 작업을 사용하여 현재 복제 그룹을 새 노드 유형으로 축소합니다.
+ `ReplicationGroupId` - 복제 그룹의 이름입니다.
+ `CacheNodeType` - 이 복제 그룹에 있는 클러스터의 새롭고 더 작은 노드 유형입니다. 이 값은 이전 단계의 `ListAllowedNodeTypeModifications` 작업에 의해 반환되는 인스턴스 유형 중 하나여야 합니다.
+ `CacheParameterGroupName` - [선택 사항] `reserved-memory`를 사용하여 클러스터의 예약된 메모리를 관리할 경우 이 파라미터를 사용합니다. 새 노드 유형에 대해 올바른 메모리 양을 예약하는 사용자 지정 캐시 파라미터 그룹을 지정합니다. `reserved-memory-percent`를 사용할 경우 이 파라미터를 생략할 수 있습니다.
+ `ApplyImmediately` - 축소 프로세스가 즉시 적용되도록 하려면 `true`로 설정합니다. 축소 프로세스를 다음 유지 관리 기간으로 연기하려면 `ApplyImmediately``=false`를 사용하세요.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.t2.micro
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) 섹션을 참조하세요.
# Bloom 필터 시작하기
ElastiCache는 요소가 집합의 멤버인지 확인하기 위한 공간 효율적인 확률적 데이터 구조를 제공하는 Bloom 필터 데이터 구조를 지원합니다. Bloom 필터를 사용하면 오탐지가 발생할 수 있습니다. 필터는 요소가 집합에 추가되지 않았더라도 요소가 존재한다는 것을 잘못 나타낼 수 있습니다. 그러나 Bloom 필터를 사용하면 거짓 *부정*을 방지할 수 있습니다. 즉, 요소가 집합에 추가되었더라도 요소가 존재하지 *않는다*는 잘못된 표시입니다.
fp 비율을 조정하여 잠재적 거짓 긍정의 비율을 워크로드에 대해 선호하는 비율로 설정할 수 있습니다. 용량(Bloom 필터가 보유할 수 있는 항목 수), 크기 조정 및 크기 조정 외 속성 등을 구성할 수도 있습니다.
지원되는 엔진 버전으로 클러스터를 생성하면 블룸 데이터 유형 및 관련 명령을 자동으로 사용할 수 있습니다. `bloom` 데이터 형식은 `valkey-py`, `valkey-java` 및 `valkey-go`를 포함한 공식 Valkey 클라이언트 라이브러리의 Bloom 필터 명령 구문과 API 호환됩니다. 기존 Bloom 기반 Valkey 및 Redis OSS 애플리케이션을 ElastiCache로 쉽게 마이그레이션할 수 있습니다. 전체 명령 목록은 [Bloom 필터 명령](#SupportedCommandsBloom) 섹션을 참조하세요.
Bloom 관련 지표 `BloomFilterBasedCmds`, `BloomFilterBasedCmdsLatency`, 및 `BloomFilterBasedCmdsECPUs`는 CloudWatch에 통합되어 이 데이터 유형의 사용을 모니터링합니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md) 단원을 참조하십시오.
**참고**
Bloom 필터를 사용하려면 ElastiCache Valkey 8.1 이상에서 실행해야 합니다.
블룸 데이터 형식은 다른 비Valkey 기반 블룸 제품과 RDB 호환되지 않습니다.
## Bloom 필터 데이터 유형 개요
Bloom 필터는 요소를 추가하고 요소가 존재하는지 확인할 수 있는 공간 효율적인 확률적 데이터 구조입니다. 필터가 추가되지 않았더라도 요소가 존재함을 잘못 나타내는 경우 거짓 긍정이 발생할 수 있습니다. 그러나 Bloom 필터는 거짓 부정(추가된 경우에도 요소가 존재하지 않음을 잘못 나타냄)이 발생하지 않도록 보장합니다.
Bloom 필터의 주요 설명서 소스는 valkey.io 설명서 페이지에서 확인할 수 있습니다. 여기에는 다음 정보가 포함되어 있습니다.
+ [Bloom 필터의 일반적인 사용 사례](https://valkey.io/topics/bloomfilters/#common-use-cases-for-bloom-filters)
+ 광고/이벤트 중복 제거
+ 사기 탐지
+ 유해한 콘텐츠/스팸 필터링
+ 고유한 사용자 감지
+ [조정 Bloom 필터와 비조정 Bloom 필터의 차이점](https://valkey.io/topics/bloomfilters/#scaling-and-non-scaling-bloom-filters)
+ 조정 Bloom 필터와 비 조정 Bloom 필터 중에서 결정하는 방법
+ [Bloom 속성](https://valkey.io/topics/bloomfilters/#bloom-properties)
+ Bloom 필터의 튜닝 가능한 속성에 대해 알아봅니다. 여기에는 오탐률, 용량, 조정 및 비조정 속성 등이 포함됩니다.
+ [Bloom 명령의 성능](https://valkey.io/topics/bloomfilters/#performance)
+ [전체 Bloom 필터 통계 모니터링](https://valkey.io/topics/bloomfilters/#monitoring)
+ [대형 Bloom 필터 처리](https://valkey.io/topics/bloomfilters/#handling-large-bloom-filters)
+ Bloom 필터가 메모리 사용량 한도에 도달했는지, 원하는 용량에 도달하도록 규모를 조정할 수 있는지 확인하는 방법에 대한 권장 사항 및 세부 정보입니다.
+ [BF.INFO](https://valkey.io/commands/bf.info/) 명령을 사용하여 Bloom 필터 문서에서 사용하는 메모리 양을 구체적으로 확인할 수 있습니다.
## Bloom 크기 제한
단일 Bloom 필터 객체의 메모리 사용량은 128MB로 제한됩니다. `BF.INFO SIZE` 명령을 사용하여 Bloom 필터가 소비하는 메모리 양을 확인할 수 있습니다.
## 블룸 ACL
기존의 데이터 유형별 범주(@string, @hash 등)와 유사합니다. Bloom 명령 및 데이터에 대한 액세스 권한 관리를 단순화하기 위해 새 범주 @bloom이 추가되었습니다. 다른 기존 Valkey 또는 Redis OSS 명령은 @bloom 범주에 속하지 않습니다.
@read, @write, @fast와 같은 새로운 Bloom 명령을 포함하기 위해 업데이트된 3가지 기존 ACL 범주가 있습니다. 다음의 표는 Bloom 명령이 적절한 범주에 매핑되었음을 나타냅니다.
| Bloom 명령 | @read | @write | @fast | @bloom |
| --- | --- | --- | --- | --- |
| BF.ADD | | y | y | y |
| BF.CARD | y | | y | y |
| BF.EXISTS | y | | y | y |
| BF.INFO | y | | y | y |
| BF.INSERT | | y | y | y |
| BF.MADD | | y | y | y |
| BF.MEXISTS | y | | y | y |
| BF.RESERVE | y | | y | y |
## Bloom 필터 관련 지표
Bloom 데이터 구조와 관련된 다음 CloudWatch 지표가 제공됩니다.
| CW 지표 | 단위 | 서버리스/노드 기반 | 설명 |
| --- | --- | --- | --- |
| BloomFilterBasedCmds | 개수 | 둘 다 | 읽기 및 쓰기 명령을 포함한 총 Bloom 필터 명령 수입니다. |
| BloomFilterBasedCmdsLatency | 마이크로초 | 자체 관리형 | 읽기 및 쓰기 명령을 포함한 모든 Bloom 필터 명령의 지연 시간입니다. |
| BloomFilterBasedCmdsECPUs | 개수 | 서버리스 | 읽기 및 쓰기 명령을 포함한 모든 Bloom 필터 명령에서 사용되는 ECPU입니다. |
## Bloom 필터 명령
[Bloom 필터 명령](https://valkey.io/commands/#bloom)은 [Valkey.io](https://valkey.io/) 웹 사이트에 설명되어 있습니다. 각 명령 페이지에서는 구문, 동작, 반환 값 및 잠재적 오류 조건을 포함하여 Bloom 명령에 대한 포괄적인 개요를 제공합니다.
| 이름 | 설명 |
| --- | --- |
| [BF.ADD](https://valkey.io/commands/bf.add/) | Bloom 필터에 단일 항목을 추가합니다. 필터가 아직 없는 경우 항목이 생성됩니다. |
| [BF.CARD](https://valkey.io/commands/bf.card/) | Bloom 필터의 카디널리티를 반환합니다. |
| [BF.EXISTS](https://valkey.io/commands/bf.exists/) | Bloom 필터에 지정된 항목이 포함되어 있는지 확인합니다. |
| [BF.INFO](https://valkey.io/commands/bf.info/) | 특정 Bloom 필터의 사용 정보 및 속성을 반환합니다. |
| [BF.INSERT](https://valkey.io/commands/bf.insert/) | 항목이 0개 이상인 Bloom 필터를 생성하거나 기존 Bloom 필터에 항목을 추가합니다. |
| [BF.MADD](https://valkey.io/commands/bf.madd/) | Bloom 필터에 하나 이상의 항목을 추가합니다. |
| [BF.MEXISTS](https://valkey.io/commands/bf.mexists/) | Bloom 필터에 하나 이상의 항목이 포함되어 있는지 확인합니다. |
| [BF.RESERVE](https://valkey.io/commands/bf.reserve/) | 지정된 속성을 사용하여 빈 Bloom 필터를 생성합니다. |
**참고**
**BF.LOAD**는 ElastiCache에서 지원되지 않습니다. 이는 ElastiCache가 지원하지 않는 AOF 사용하고만 관련이 있습니다.
# Serverless에서 Watch 시작하기
ElastiCache는 `WATCH` 명령을 지원하므로 키에서 변경 사항을 모니터링하고 조건부 [트랜잭션](https://valkey.io/topics/transactions/)을 실행할 수 있습니다. 이 `WATCH` 명령은 모니터링되는 키가 수정되지 않은 경우에만 트랜잭션이 실행되도록 하여 낙관적 동시성 제어가 필요한 애플리케이션에 특히 유용합니다. 여기에는 쓰기 명령과 같은 클라이언트의 수정 사항과 만료 또는 제거와 같은 Valkey 자체의 수정 사항이 포함됩니다. 키가에 설정된 시간부터 `WATCH` 키를 받은 시간까지 수정된 경우 전체 트랜잭션`EXEC`이 중단됩니다.
ElastiCache Serverless의 경우 다음과 같은 제약 조건이 도입됩니다.
ElastiCache Serverless`WATCH`는 단일 해시 슬롯으로 범위가 지정됩니다. 즉, 동일한 해시 슬롯에 매핑되는 키만 동일한 연결로 동시에 감시할 수 있으며, 감시 명령을 따르는 트랜잭션은 동일한 해시 슬롯에서만 작동할 수 있습니다. 애플리케이션이 다른 해시 슬롯의 키를 감시하거나 감시된 키와 다른 해시 슬롯에 매핑된 키에서 작동하는 트랜잭션 명령을 실행하려고 하면 `CROSSSLOT` 오류가 반환됩니다. [해시 태그를](https://valkey.io/topics/cluster-spec/#hash-tags) 사용하여 여러 키가 동일한 해시 슬롯에 매핑되도록 할 수 있습니다.
또한 감시 키가 있는 연결 내에서 `SCAN` 명령을 실행할 수 없으며 `command not supported during watch state` 오류가 반환됩니다.
ElastiCache Serverless가 키가 수정되었는지 확실하지 않은 경우 트랜잭션이 중단됩니다(시계된 키를 터치한 것처럼). 예를 들어 슬롯이 마이그레이션되어 감시된 키를 동일한 노드에서 찾을 수 없는 경우를 예로 들 수 있습니다.
**코드 예제**
## 서로 다른 슬롯의 키에서 감시 및 작동
다음 예제에서는 감시된 키와 `SET` 명령에 지정된 키가 서로 다른 해시 슬롯에 매핑됩니다. 실행은를 반환합니다`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{011794} 1234
QUEUED
> EXEC
CROSSSLOT Keys in request don't hash to the same slot
```
## 동일한 슬롯의 키에서 감시 및 작동
다음 예제에서는의 키 세트가 변경되지 `WATCH` 않았으므로 성공적인 트랜잭션을 보여줍니다.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{005119} 1234
QUEUED
> EXEC
1) OK
```
## 서로 다른 슬롯의 감시 키
다음 예제에서는 동일한 클라이언트 연결 내에서 서로 다른 슬롯의 `WATCH` 키를 동시에 입력하려고 하면가 반환됩니다`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> WATCH bar:{123455}
CROSSSLOT Keys in request don't hash to the same slot
```
## 감시 제한
모든 클라이언트 연결은 동시에 최대 1,000개의 키를 감시할 수 있습니다.
## Watch와 관련하여 지원되는 명령
[WATCH](https://valkey.io/commands/watch/) 및 [UNWATCH](https://valkey.io/commands/unwatch/) 명령은 [Valkey.io](https://valkey.io/) 웹 사이트에 설명되어 있습니다. 구문, 동작, 반환 값 및 잠재적 오류 조건을 포함하여 명령에 대한 포괄적인 개요를 제공합니다.
# 벡터 검색 시작
Amazon ElastiCache for Valkey는 벡터 검색을 지원하므로 지연 시간이 마이크로초이고 재현율이 99%를 초과하는 수십억 개의 고차원 벡터 임베딩을 메모리에 저장, 검색 및 업데이트할 수 있습니다. ElastiCache for Valkey는 빠른 검색 및 검색을 위해 Amazon Bedrock, Amazon SageMaker, Anthropic 또는 OpenAI와 같은 인기 있는 공급자로부터 수십억 개의 고차원 벡터 임베딩을 인덱싱, 검색 및 업데이트할 수 있는 기능을 제공합니다. Amazon ElastiCache의 벡터 검색은 최대 성능과 확장성이 가장 중요한 선택 기준인 사용 사례에 적합합니다. 여기에는 시맨틱 캐싱, 검색 증강 생성, 실시간 권장 사항, 맞춤화 및 이상 탐지 작업이 포함됩니다.
벡터 검색은 다른 ElastiCache 기능과 함께 사용하여 애플리케이션을 개선할 수 있습니다. ElastiCache에 대한 벡터 검색은 Valkey 버전 8.2에서 추가 비용 없이 모든 [AWS리전](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)의 노드 기반 클러스터에서 사용할 수 있습니다. 시작하려면 ,[AWS Management Console](https://console.aws.amazon.com/elasticache/)AWS SDK 또는를 사용하여 새 Valkey 8.2 클러스터를 생성합니다AWS CLI. [가동 중지 시간 없이 몇 번의 클릭](VersionManagement.HowTo.md)만으로 이전 버전의 Valkey 또는 Redis OSS에서 Valkey 8.2로 업그레이드하여 기존 클러스터에서 벡터 검색을 사용할 수도 있습니다.
# 벡터 검색 개요
ElastiCache for Valkey는 수십억 개의 고차원 벡터 임베딩을 인덱싱, 검색 및 업데이트할 수 있는 기능을 제공합니다. 벡터 검색을 사용하면 효율적이고 확장 가능한 검색을 위해 보조 인덱스를 생성, 유지 관리 및 사용할 수 있습니다. 각 벡터 검색 작업은 단일 인덱스에 적용됩니다. 인덱스 작업은 지정된 인덱스에만 적용됩니다. 인덱스 생성 및 삭제 작업을 제외하고 언제든지 인덱스에 대해 원하는 수의 작업이 실행될 수 있습니다. 클러스터 수준에서는 여러 인덱스에 대한 여러 작업이 동시에 진행 중일 수 있습니다.
이 문서 내에서 키, 행 및 레코드라는 용어는 동일한 의미로 통용됩니다. 마찬가지로 열, 필드, 경로 및 멤버라는 용어는 통용됩니다.
`FT.CREATE` 명령을 사용하여 지정된 인덱스 유형의 키 하위 집합에 대한 인덱스를 생성할 수 있습니다. `FT.SEARCH`는 생성된 인덱스에 대한 쿼리를 수행하고 `FT.DROPINDEX`는 기존 인덱스와 모든 관련 데이터를 제거합니다. 인덱싱된 데이터를 추가, 삭제 또는 수정하기 위한 특별한 명령은 없습니다. 인덱스에 있는 키를 수정하는 기존 `HASH` 또는 `JSON` 명령은 인덱스를 자동으로 업데이트합니다.
**Topics**
+ [인덱스 및 Redis OSS 키스페이스](#indexes-keyspace)
+ [인덱스 필드 유형](#index-field-types)
+ [벡터 인덱스 알고리즘](#vector-index-algorithms)
+ [벡터 검색 보안](#vector-search-security)
## 인덱스 및 Redis OSS 키스페이스
인덱스는 Valkey OSS 키스페이스의 하위 집합을 기준으로 구성되고 유지 관리됩니다. 각 인덱스의 키스페이스는 인덱스 생성 시 제공되는 키 접두사 목록에 의해 정의됩니다. 접두사 목록은 선택 사항이며 생략하면 전체 키스페이스가 해당 인덱스에 포함됩니다. 여러 인덱스는 키스페이스의 분리되거나 중복되는 하위 집합을 제한 없이 선택할 수 있습니다.
또한 인덱스는 유형이 일치하는 키만 포함하도록 입력됩니다. 현재 인덱스는 `JSON` 및 `HASH` 유형으로만 지원됩니다. `HASH` 인덱스는 접두사 목록에 포함된 `HASH` 키만 인덱싱하고, 마찬가지로 `JSON` 인덱스는 접두사 목록에 포함된 `JSON` 키만 인덱싱합니다. 인덱스의 키스페이스 접두사 목록 내에서 지정된 유형이 없는 키는 무시되며 검색 작업에 영향을 주지 않습니다.
명령이 인덱스의 키스페이스 내에 있는 키를 수정하면 해당 인덱스가 업데이트됩니다. Valkey는 각 인덱스에 대해 선언된 필드를 자동으로 추출하고 인덱스를 새 값으로 업데이트합니다. 업데이트 프로세스에는 세 단계가 있습니다. 첫 번째 단계에서는 HASH 또는 JSON 키가 수정되고 요청 클라이언트가 차단됩니다. 두 번째 단계는 백그라운드에서 수행되며 수정된 키가 포함된 각 인덱스를 업데이트합니다. 세 번째 단계에서는 클라이언트가 차단 해제됩니다. 따라서 변형과 동일한 연결에서 수행되는 쿼리 작업의 경우 해당 변경 사항이 검색 결과에 즉시 표시됩니다.
인덱스 생성은 다단계 프로세스입니다. 첫 번째 단계는 인덱스를 정의하는 FT.CREATE 명령을 실행하는 것입니다. 생성을 성공적으로 실행하면 두 번째 단계인 채우기가 자동으로 시작됩니다. 채우기 프로세스는 백그라운드 스레드에서 실행되며 키스페이스를 스캔하여 새 인덱스의 접두사 목록 내에 있는 키를 찾습니다. 발견된 각 키는 인덱스에 추가됩니다. 결국 전체 키스페이스가 스캔되어 인덱스 생성 프로세스가 완료됩니다. 채우기 프로세스가 실행되는 동안에는 제한 없이 인덱스 키를 변경할 수 있으며 모든 키가 제대로 인덱싱될 때까지 인덱스 채우기 프로세스가 완료되지 않습니다. 인덱스를 채우는 동안 시도한 쿼리 작업은 허용되지 않으며 오류가 발생하여 종료됩니다. FT.INFO 명령은 'backfill\$1status' 필드에 채우기 프로세스 상태를 반환합니다.
## 인덱스 필드 유형
각 인덱스에는 인덱스가 생성될 때 인덱싱할 필드(열)의 위치와 함께 선언되는 특정 유형이 있습니다. `HASH` 키의 경우 위치는 `HASH` 내의 필드 이름입니다. `JSON` 키의 경우 위치는 JSON 경로 설명입니다. 키가 수정되면 선언된 필드와 관련된 데이터가 추출되고 선언된 유형으로 변환되어 인덱스에 저장됩니다. 데이터가 누락되었거나 선언된 유형으로 성공적으로 변환할 수 없는 경우 해당 필드는 인덱스에서 제외됩니다. 필드에는 다음 설명과 같이 3가지 유형이 있습니다.
+ **벡터 필드**에는 벡터 임베딩이라고도 하는 숫자 벡터가 포함됩니다. 벡터 필드를 사용하여 유사성을 측정하는 지정된 거리 지표를 기반으로 벡터를 필터링할 수 있습니다. `HASH` 인덱스의 경우 필드에 바이너리 형식(리틀 엔디안 IEEE 754)으로 인코딩된 전체 벡터가 포함되어야 합니다. `JSON` 키의 경우 경로는 숫자로 채워진 올바른 크기의 배열을 참조해야 합니다. JSON 배열을 벡터 필드로 사용하는 경우 JSON 키 내 배열의 내부 표현이 선택한 알고리즘에서 요구하는 형식으로 변환되므로 메모리 사용량과 정밀도가 줄어듭니다. 이후에 JSON 명령을 사용하여 읽기 작업을 수행하면 낮아진 정밀도 값을 출력합니다.
+ **숫자 필드**에는 단일 숫자가 포함됩니다. 숫자 필드는 범위 검색 연산자와 함께 사용할 수 있습니다. `HASH`의 경우 필드에 고정 또는 부동 소수점 숫자의 표준 형식으로 작성된 ASCII 텍스트가 포함되어야 합니다. `JSON` 필드의 경우 JSON 번호의 숫자 규칙을 따라야 합니다. 키 내 표시 형식에 관계없이 이 필드는 64비트 부동 소수점 숫자로 변환되어 인덱스 내에 저장됩니다. 기본 숫자는 정밀도 제한에 따라 부동 소수점으로 저장되므로 부동 소수점 숫자 비교에 대한 일반적인 규칙이 적용됩니다.
+ **태그 필드**에는 단일 UTF-8 문자열로 코딩된 0개 이상의 태그 값이 포함됩니다. 태그 필드를 사용하여 대소문자를 구분하거나 구분하지 않는 비교를 통해 태그 값이 동일한 쿼리를 필터링할 수 있습니다. 문자열은 선행 및 후행 공백이 제거된 구분 문자(기본값은 쉼표이지만 재정의할 수 있음)를 사용하여 태그 값으로 구문 분석됩니다. 단일 태그 필드에 원하는 수의 태그 값을 포함할 수 있습니다.
## 벡터 인덱스 알고리즘
Valkey에서는 두 가지 벡터 인덱스 알고리즘이 지원됩니다.
+ **FLAT** - FLAT 알고리즘은 인덱스의 각 벡터를 무차별 대입으로 선형 처리하여 거리 계산의 정밀도 범위 내에서 정확한 답을 산출합니다. 인덱스의 선형 처리로 인해 큰 인덱스의 경우 이 알고리즘의 실행 시간이 매우 길어질 수 있습니다. 플랫 인덱스는 더 높은 수집 속도를 지원합니다.
+ **Hierarchical Navigable Small Worlds(HSSW)** - HNSW 알고리즘은 실행 시간을 크게 줄이는 대신 가장 가까운 벡터 매치를 제공합니다. 알고리즘은 세 개의 파라미터 `M`, `EF_CONSTRUCTION`, `EF_RUNTIME`에 의해 제어됩니다. 처음 두 파라미터는 인덱스 생성 시 지정되며 변경할 수 없습니다. 이 `EF_RUNTIME` 파라미터는 인덱스 생성 시 지정되는 기본값을 갖지만 이후에 개별 쿼리 작업에서 재정의할 수 있습니다. 이 세 파라미터는 상호 작용하여 수집 및 쿼리 작업 중에 메모리와 CPU 사용량의 균형을 맞추고 정확한 KNN 검색의 근사치 품질(재현율)을 제어합니다.
HNSW에서 파라미터 M은 각 노드가 연결할 수 있는 최대 이웃 수를 제어하여 인덱스 밀도를 형성합니다. 32 이상과 같이 M이 높을수록 그래프가 더 많이 연결되어 관련 이웃에 도달하기 위한 경로가 더 많기 때문에 리콜 및 쿼리 속도가 향상됩니다. 그러나 인덱스 크기와 메모리 사용량을 늘리고 인덱싱 속도를 늦춥니다. 8 이하와 같이 M이 낮을수록 메모리 사용량이 적은 더 작고 빌드가 더 빠른 인덱스가 생성되지만 연결 수가 적기 때문에 리콜이 감소하고 쿼리가 더 오래 걸릴 수 있습니다.
파라미터 EF\$1construction은 인덱스를 빌드할 때 평가되는 후보 연결 수를 결정합니다. 400 이상과 같이 EF\$1construction이 높을수록 인덱서는 이웃을 선택하기 전에 더 많은 경로를 고려하므로 나중에 재현율과 쿼리 효율성을 모두 개선하는 그래프가 생성 중 인덱싱 속도가 느려지고 CPU 및 메모리 사용량이 늘어납니다. 64\$1120과 같은 낮은 EF\$1construction은 인덱싱 속도를 높이고 리소스 사용을 줄이지만 결과 그래프는 EF\$1runtime이 높게 설정된 경우에도 재현율을 줄이고 쿼리 속도를 늦출 수 있습니다.
마지막으로 EF\$1runtime은 쿼리 중 검색 범위를 제어하여 런타임 시 탐색할 후보 이웃 수를 제어합니다. 이 값을 높게 설정하면 재현율과 정확도가 향상되지만 쿼리 지연 시간과 CPU 사용 비용이 발생합니다. EF\$1runtime이 낮으면 쿼리가 더 빠르고 가볍지만 재현율은 줄어듭니다. M 또는 EF\$1construction과 달리이 파라미터는 인덱스 크기 또는 빌드 시간에 영향을 주지 않으므로 인덱스가 빌드된 후 재현율 대 지연 시간 균형을 조정하는 파라미터입니다.
벡터 검색 알고리즘(FLAT 및 HNSW) 모두 선택적 `INITIAL_CAP` 파라미터를 지원합니다. 이 파라미터를 지정하면 인덱스에 메모리를 사전 할당하여 메모리 관리 오버헤드를 줄이고 벡터 수집 비율을 높입니다. 플랫 인덱스는 HNSW보다 더 나은 수집 속도를 지원합니다.
HNSW와 같은 벡터 검색 알고리즘은 이전에 삽입한 벡터의 삭제 또는 덮어쓰기를 효율적으로 처리하지 못할 수 있습니다. 이러한 연산을 사용하면 인덱스 메모리가 과도하게 소모되거나 재현율이 저하될 수 있습니다. 인덱스를 다시 지정하는 것은 최적의 메모리 사용량 또는 재현율을 복원하기 위한 방법 중 하나입니다.
## 벡터 검색 보안
명령 및 데이터 액세스 모두에 대한 [Valkey 액세스 제어 목록(ACL)](https://valkey.io/topics/acl/) 보안 메커니즘이 검색 기능을 제어하도록 확장되었습니다. 개별 검색 명령의 ACL 제어가 완벽하게 지원됩니다. 새 ACL 범주 `@search`가 추가되었으며 많은 기존 범주(`@fast`, `@read`, `@write` 등)가 새 명령을 포함하도록 업데이트되었습니다. 검색 명령은 키 데이터를 수정하지 않습니다. 즉, 쓰기 액세스를 위한 기존 ACL 시스템이 보존됩니다. `HASH` 및 `JSON` 작업에 대한 액세스 규칙은 인덱스가 있더라도 수정되지 않습니다. 이러한 명령에는 여전히 일반적인 키 수준 액세스 제어가 적용됩니다.
인덱스가 있는 검색 명령의 액세스도 ACL로 제어됩니다. 액세스 확인은 키별 수준이 아닌 전체 인덱스 수준에서 수행됩니다. 즉, 사용자가 해당 인덱스의 키스페이스 접두사 목록 내에서 가능한 모든 키에 액세스할 수 있는 권한을 가진 경우에만 사용자에게 인덱스 액세스 권한이 부여됩니다. 즉, 인덱스의 실제 콘텐츠는 액세스를 제어하지 않습니다. 그보다는 접두사 목록에 정의된 인덱스의 이론상 내용이 보안 검사에 사용됩니다. 사용자에게 키에 대한 읽기 및/또는 쓰기 액세스는 있지만 가능한 해당 키가 포함된 인덱스에는 액세스할 수 없는 상황입니다. 인덱스를 만들거나 사용할 때는 키스페이스에 대한 읽기 액세스만 필요하며 쓰기 액세스 유무는 고려되지 않습니다.
# 벡터 검색 기능 및 제한
## 벡터 검색 가능 여부
Amazon ElastiCache에 대한 벡터 검색은 모든AWS리전의 노드 기반 클러스터에서 Valkey 버전 8.2로 추가 비용 없이 사용할 수 있습니다. [가동 중지 시간 없이 몇 번의 클릭](VersionManagement.HowTo.md)만으로 Valkey 버전 또는 Redis OSS에서 Valkey 8.2로 업그레이드하여 기존 클러스터에서 벡터 검색을 사용할 수도 있습니다.
벡터 검색은 현재 데이터 계층화가 있는 노드를 제외한 모든 ElastiCache 인스턴스 유형에서 사용할 수 있습니다. t2, t3 및 t4g 인스턴스에서 벡터 검색을 사용하려면 메모리 예약을 마이크로 인스턴스의 경우 50%, 스몰 인스턴스의 경우 30% 이상으로 늘려야 합니다. 자세한 내용은 [이 페이지](redis-memory-management.md)를 참조하세요.
## 파라미터 제한 사항
다음 표는 다양한 벡터 검색 항목에 대한 제한 사항을 보여줍니다.
**벡터 검색 제한**
| 항목 | 최대값 |
| --- | --- |
| 벡터의 차원 수 | 32768 |
| 만들 수 있는 인덱스 수 | 10 |
| 인덱스의 필드 수 | 50 |
| FT.SEARCH TIMEOUT절(밀리초) | 60000 |
| 인덱스당 허용되는 최대 접두사 수 | 16 |
| 태그 필드의 최대 길이 | 10000 |
| 숫자 필드의 최대 길이 | 256 |
| HNSW M 파라미터 | 2000000 |
| HNSW EF\$1CONSTRUCTION 파라미터 | 4096 |
| HNSW EF\$1RUNTIME 파라미터 | 4096 |
## 운영상의 제한 사항
### 인덱스 지속성 및 채우기
업데이트 프로세스에는 세 단계가 있습니다. 첫 번째 단계에서는 HASH 또는 JSON 키가 수정되고 요청 클라이언트가 차단됩니다. 두 번째 단계는 백그라운드에서 수행되며 수정된 키가 포함된 각 인덱스를 업데이트합니다. 세 번째 단계에서는 클라이언트가 차단 해제됩니다. 따라서 변형과 동일한 연결에서 수행되는 쿼리 작업의 경우 해당 변경 사항이 검색 결과에 즉시 표시됩니다. 그러나 키를 삽입하거나 업데이트해도 당장은 기타 클라이언트의 검색 결과에 표시되지 않습니다. 시스템 부하가 심하거나 데이터가 심하게 변경되는 기간에는 가시성 지연이 더 길어질 수 있습니다.
벡터 검색 기능은 인덱스의 정의와 인덱스의 콘텐츠를 유지합니다. 벡터 필드의 인덱스는 저장되지만 TAGS 및 NUMERIC의 인덱스는 저장되지 않습니다. 즉, 외부에서 로드할 때 다시 빌드해야 합니다(전체 동기화 또는 다시 로드). 즉, 노드를 시작하거나 다시 시작하게 하는 모든 운영 요청 또는 이벤트 중에 인덱스 정의 및 벡터 콘텐츠가 최신 스냅샷에서 복원됩니다. 이를 시작하는 데는 사용자 작업이 필요하지 않습니다. 그러나 TAGS 및 NUMERIC 인덱스의 경우 리빌드 작업은 데이터가 복원되는 즉시 채우기 작업으로 수행됩니다. 이는 시스템이 정의된 각 인덱스에 대해 FT.CREATE 명령을 자동으로 실행하는 것과 기능적으로 동일합니다. 데이터가 복원되자마자 노드를 애플리케이션 작업에 사용할 수 있지만 인덱스 채우기가 완료되지 않았을 가능성이 높습니다. 즉, 채우기 작업이 애플리케이션에 다시 표시될 수 있으며, 예를 들어 인덱스 채우기를 사용한 검색 명령은 거부될 수 있습니다.
인덱스 채우기 완료는 원본과 복제본 간에 동기화되지 않습니다. 불완전한 동기화가 애플리케이션에 예기치 않게 나타날 수 있으므로 애플리케이션에서 검색 작업을 시작하기 전에 원본과 모든 복제본에서 채우기가 완료되었는지 확인하는 것이 좋습니다.
### 규모 조정 제한
규모 조정 이벤트 중에 데이터가 마이그레이션될 때 인덱스가 채워질 수 있습니다. 이로 인해 검색 쿼리에 대한 재현율이 줄어듭니다.
### 스냅샷 가져오기/내보내기 및 실시간 마이그레이션
검색 인덱스가 있는 한 클러스터의 RDB 파일을 버전 8.2 이상의 다른 ElastiCache Valkey 클러스터로 가져올 수 있습니다. 새 클러스터는 RDB 파일을 로드할 때 인덱스 콘텐츠를 다시 빌드합니다. 그러나 RDB 파일에 검색 인덱스가 있으면 해당 데이터와 이전 버전의 Valkey와의 호환성이 제한됩니다. 벡터 검색 기능으로 정의된 검색 인덱스의 형식은 Valkey 버전 8.2 이상의 다른 ElastiCache 클러스터에서만 이해됩니다. 그러나 인덱스가 포함되지 않은 RDB 파일에는 이러한 제한이 적용되지 않습니다.
### 채우기 중 메모리 부족
Valkey OSS 쓰기 작업과 마찬가지로 인덱스 채우기에는 메모리 부족 제한이 적용됩니다. 채우기가 진행되는 동안 엔진 메모리가 가득 차면 모든 채우기가 일시 중지됩니다. 메모리를 사용할 수 있게 되면 채우기가 다시 시작됩니다. 메모리 부족으로 인해 채우기가 일시 중지된 경우 삭제하고 인덱싱할 수 있습니다.
### 트랜잭션
`FT.CREATE`, `FT.DROPINDEX`, `FT.ALIASADD`, `FT.ALIASDEL` 및 `FT.ALIASUPDATE` 명령은 트랜잭션 컨텍스트에서 실행할 수 없습니다. 즉, `MULTI/EXEC` 블록, LUA 또는 FUNCTION 스크립트 내에서는 실행할 수 없습니다.
# 적절한 구성 선택
콘솔 환경 내에서 ElastiCache는 벡터 워크로드의 메모리 및 cpu 요구 사항에 따라 올바른 인스턴스 유형을 쉽게 선택할 수 있는 방법을 제공합니다.
## 메모리 사용
메모리 소비는 벡터 수, 차원 수, M-값, 벡터가 아닌 데이터(예: 벡터에 연결된 메타데이터 또는 인스턴스에 저장된 기타 데이터)의 양을 기반으로 합니다. 필요한 총 메모리는 실제 벡터 데이터에 필요한 공간과 벡터 인덱스에 필요한 공간의 조합입니다. 벡터 데이터에 필요한 공간은 최적의 메모리 할당을 위해 `HASH` 또는 `JSON` 데이터 구조 내에 벡터를 저장하는 데 필요한 실제 용량과 가장 가까운 메모리 슬래브에 대한 오버헤드를 측정하여 계산됩니다. 각 벡터 인덱스는 이러한 데이터 구조에 저장된 벡터 데이터에 대한 참조와 인덱스에 있는 벡터의 추가 복사본을 사용합니다. 인덱스별이 추가 공간 소비를 계획하는 것이 좋습니다.
벡터 수는 데이터를 벡터로 표현하는 방법에 따라 달라집니다. 예를 들어 단일 문서를 여러 청크로 나타내도록 선택할 수 있습니다. 여기서 각 청크는 벡터를 나타냅니다. 또는 전체 문서를 단일 벡터로 나타내도록 선택할 수 있습니다. 벡터의 차원 수는 선택한 임베딩 모델에 따라 달라집니다. 예를 들어AWS Titan 임베딩 모델을 사용하기로 선택한 경우 차원 수는 1536입니다. 인스턴스 유형을 테스트하여 요구 사항에 맞는지 확인해야 합니다.
## 워크로드 규모 조정
벡터 검색은 수평, 수직 및 복제본이라는 세 가지 조정 방법을 모두 지원합니다. 용량 규모 조정 시 벡터 검색은 일반 Valkey처럼 동작합니다. 즉, 개별 노드의 메모리를 늘리거나(수직적 스케일링) 노드 수를 늘리면(수평적 스케일링) 전체 용량이 증가합니다. 클러스터 모드에서는 `FT.CREATE` 명령을 클러스터의 모든 프라이머리 노드로 전송할 수 있으며 시스템은 새 인덱스 정의를 모든 클러스터 멤버에게 자동으로 배포합니다.
그러나 성능 관점에서 벡터 검색은 일반 Valkey와 매우 다르게 동작합니다. 벡터 검색을 다중 스레드로 구현하면 추가 CPU에서 쿼리 처리량과 수집 처리량을 모두 선형으로 증가할 수 있습니다. 수평적 스케일링은 수집 처리량을 선형적으로 증가시키지만 쿼리 처리량을 줄일 수 있습니다. 추가 쿼리 처리량이 필요한 경우 복제본 또는 추가 CPU를 통해 규모를 조정해야 합니다.
# 벡터 검색 명령
다음은 벡터 검색에 지원되는 명령 목록입니다.
**Topics**
+ [FT.CREATE](vector-search-commands-ft.create.md)
+ [FT.SEARCH](vector-search-commands-ft.search.md)
+ [FT.DROPINDEX](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [FT.\$1LIST](vector-search-commands-ft.list.md)
# FT.CREATE
`FT.CREATE` 명령은 빈 인덱스를 생성하고 채우기 프로세스를 시작합니다. 각 인덱스는 여러 필드 정의로 구성됩니다. 각 필드 정의는 필드 이름, 필드 유형 및 각 인덱싱된 키 내의 경로를 지정하여 선언된 유형의 값을 찾습니다. 일부 필드 유형 정의에는 추가 하위 유형 지정자가 있습니다.
HASH 키의 인덱스의 경우 경로는 해시 멤버 이름과 동일합니다. 원하는 경우 선택적 `AS`절을 사용하여 필드의 이름을 바꿀 수 있습니다. 필드 이름을 바꾸는 것은 멤버 이름에 특수 문자가 포함된 경우에 특히 유용합니다.
JSON 키의 인덱스의 경우 경로는 선언된 유형의 데이터에 대한 JSON 경로입니다. JSON 경로에는 항상 특수 문자가 포함되어 있으므로 `AS`절이 필요합니다.
**구문**
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
| VECTOR [HNSW|FLAT] [])
| TAG [SEPARATOR ] [CASESENSITIVE]
| NUMERIC
)+
```
**(필수):** 인덱스에 지정한 이름입니다. 동일한 이름의 인덱스가 이미 있는 경우 오류가 반환됩니다.
**ON HASH \$1 JSON(선택 사항):** 지정된 유형과 일치하는 키만 이 인덱스에 포함됩니다. 생략하면 HASH가 가정됩니다.
**PREFIX (선택 사항):** 이 절을 지정하면 지정된 접두사 중 하나 이상과 동일한 바이트로 시작하는 키만 이 인덱스에 포함됩니다. 이 절을 생략하면 올바른 유형의 모든 키가 포함됩니다. 길이가 0인 접두사는 올바른 유형의 모든 키와도 일치합니다.
**필드 유형:**
+ TAG: 태그 필드는 하나 이상의 태그 값을 포함하는 문자열입니다.
+ SEPARATOR (선택 사항): 개별 태그를 구분하는 데 사용되는 `,.<>{}[]"':;!@#$%^&*()-+=~` 문자 중 하나입니다. 생략 시 기본값은 `,`입니다.
+ CASESENSITIVE(선택 사항): 있는 경우 태그 비교는 대/소문자를 구분합니다. 기본값은 태그 비교는 대/소문자를 구분하지 않는다는 것입니다.
+ NUMERIC: 숫자 필드에는 숫자가 포함됩니다.
+ VECTOR: 벡터 필드에는 벡터가 포함됩니다. 현재 HNSW(Hierarchical Navigable Small World)와 FLAT(brute force)라는 두 가지 벡터 인덱싱 알고리즘이 지원됩니다. 각 알고리즘에는 추가 속성 세트가 있으며, 그 중 몇 가지는 필수이고 나머지는 선택 사항입니다.
+ FLAT: Flat 알고리즘은 정확한 답변을 제공하지만 인덱싱된 벡터 수에 비례하여 런타임이 있으므로 대규모 데이터세트에 적합하지 않을 수 있습니다.
+ DIM (필수): 벡터의 차원 수를 지정합니다.
+ TYPE FLOAT32(필수): 데이터 형식, 현재 FLOAT32만 지원됩니다.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE](필수): 거리 알고리즘을 지정합니다.
+ INITIAL\$1CAP (선택 사항): 초기 인덱스 크기입니다.
+ HNSW: HNSW 알고리즘은 대략적인 답변을 제공하지만 FLAT보다 훨씬 빠르게 작동합니다.
+ DIM (필수): 벡터의 차원 수를 지정합니다.
+ TYPE FLOAT32(필수): 데이터 형식, 현재 FLOAT32만 지원됩니다.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE](필수): 거리 알고리즘을 지정합니다.
+ INITIAL\$1CAP (선택 사항): 초기 인덱스 크기입니다.
+ M (선택 사항): 각 계층의 그래프에 있는 각 노드에 허용되는 최대 발신 엣지 수입니다. 계층 0에서 발신 엣지의 최대 수는 2\$1M입니다. 기본값은 16이고 최댓값은 512입니다.
+ EF\$1CONSTRUCTION (선택 사항): 인덱스 생성 중에 검사되는 벡터 수를 제어합니다. 이 파라미터의 값이 높을수록 인덱스 생성 시간이 길어지는 대신 재현율이 향상됩니다. 기본값은 200입니다. 최대값은 4,096입니다.
+ EF\$1RUNTIME (선택 사항): 쿼리 작업 중에 검사할 벡터 수를 제어합니다. 기본값은 10이고 최댓값은 4096입니다. 실행하는 각 쿼리에 대해 이 파라미터 값을 설정할 수 있습니다. 값이 높을수록 쿼리 시간이 늘어나지만 쿼리 재현율은 향상됩니다.
**RESPONSE:** OK 또는 오류입니다.
# FT.SEARCH
지정된 인덱스를 검색합니다. 쿼리 표현식과 일치하는 키가 반환됩니다.
```
FT.SEARCH
[NOCONTENT]
[RETURN ( [AS ])+]
[TIMEOUT timeout]
[PARAMS []]
[LIMIT ]
```
+ (필수): 쿼리하려는 인덱스 이름입니다.
+ (필수): 쿼리 문자열입니다. 자세한 내용은 아래를 참조하세요.
+ NOCONTENT(선택 사항): 있는 경우 결과 키 이름만 반환되고 키 값은 포함되지 않습니다.
+ TIMEOUT (선택 사항): 검색 명령의 제한 시간 값을 설정할 수 있습니다. 밀리초 단위의 정수여야 합니다.
+ PARAMS ... (선택 사항): `count`는 인수 개수이며, 값 이름 페어 수의 2배입니다. 사용 세부 정보는 쿼리 문자열을 참조하세요.
+ RETURN ... (선택 사항): count는 반환할 필드 수입니다. 반환된 값의 별칭과 함께 문서에서 검색할 필드를 지정합니다. 기본적으로 NOCONTENT 옵션이 설정되지 않은 경우 모든 필드가 반환되며,이 경우 필드가 반환되지 않습니다. 개수가 0으로 설정된 경우 NOCONTENT와 동일하게 동작합니다.
+ LIMIT: : 결과의 일부를 선택할 수 있습니다. 첫 번째 개 키는 건너뛰고 최대 개 키만 포함합니다. 기본값은 LIMIT 0 10이며 최대 10개의 키를 반환합니다.
+ PARAMS: 키 값 쌍 수의 2배입니다. 파라미터 키/값 쌍은 쿼리 표현식 내에서 참조할 수 있습니다. 자세한 내용은 [벡터 검색 쿼리 표현식](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression)을 참조하세요.
+ DIALECT: (선택 사항): 언어를 지정합니다. 지원되는 유일한 언어는 2입니다.
**RESPONSE**
명령은 성공할 경우 배열을 반환하거나 오류를 반환합니다.
성공 시 응답 배열의 첫 번째 항목은 일치하는 키 수를 나타내며, 그 뒤에 일치하는 각 키에 대해 하나의 배열 항목이 표시됩니다. `LIMIT` 옵션을 지정하면 반환된 키 수만 제어되고 첫 번째 항목의 값에는 영향을 주지 않습니다.
`NOCONTENT`를 지정하면 응답의 각 항목에 일치하는 키 이름만 포함됩니다. 그렇지 않으면 각 항목에 일치하는 키 이름과 반환된 필드의 배열이 포함됩니다. 키의 결과 필드는 이름/값 페어 세트로 구성됩니다. 첫 번째 이름/값 페어는 계산된 거리를 나타냅니다. 이 페어의 이름은 벡터 이름 앞에 ‘\$1\$1’를 추가하고 뒤에 ‘\$1score’를 추가한 것이며, 값은 계산된 거리입니다. 나머지 이름/값 페어는 `RETURN` 절에서 제어하는 키의 멤버 및 값입니다.
쿼리 문자열은 다음 구문을 따릅니다.
```
=>[ KNN @ $ ]
```
위치:
+ : \$1 또는 필터 표현식입니다. \$1는 필터링이 없음을 나타내므로 인덱스 내의 모든 벡터가 검색됩니다. 필터 표현식을 제공하여 검색할 벡터의 하위 집합을 지정할 수 있습니다.
+ : 지정된 인덱스 내의 벡터 필드 이름입니다.
+ : 반환할 가장 가까운 이웃 벡터의 수입니다.
+ : 해당 값이 KNN 알고리즘에 대한 쿼리 벡터를 제공하는 PARAM 이름입니다. 이 파라미터는 리틀 엔디안 형식의 32비트 IEEE 754 바이너리 부동 소수점으로 인코딩되어야 합니다.
+ : (선택 사항) 이 특정 KNN 검색을 수정하는 키워드/값 페어 목록입니다. 현재 2개의 키워드가 지원됩니다.
+ EF\$1RUNTIME: 이 키워드에는 인덱스 생성 시 지정된 EF\$1RUNTIME의 기본값을 재정의하는 정수 값이 함께 제공됩니다.
+ AS: 이 키워드에는 결과에서 점수 필드의 이름이 되어 기본 점수 필드 이름 생성 알고리즘을 재정의하는 문자열 값이 함께 제공됩니다.
**필터 표현식**
필터 표현식은 괄호 안에 포함된 태그 및 숫자 검색 연산자의 논리적 조합으로 구성됩니다.
**태그**
태그 검색 연산자는 \$1 문자로 구분된 하나 이상의 문자열로 지정됩니다. 표시된 필드에 지정된 문자열 중 하나가 포함된 경우 키는 태그 검색 연산자를 충족합니다.
```
@:{}
or
@:{ | }
or
@:{ | | ...}
```
예를 들어 다음 쿼리는 블루 또는 블랙 또는 그린 색상의 문서를 반환합니다.
`@color:{blue | black | green}`
또 다른 예로, 다음 쿼리는 ‘hello world’ 또는 ‘hello universe’가 포함된 문서를 반환합니다.
`@description:{hello world | hello universe}`
**숫자 범위**
숫자 범위 연산자를 사용하면 지정된 시작 값과 종료 값 사이에 있는 값만 반환하도록 쿼리를 필터링할 수 있습니다. 포함 범위 쿼리와 제외 범위 쿼리가 모두 지원됩니다. 간단한 관계형 비교를 위해 \$1inf, -inf를 범위 쿼리와 함께 사용할 수 있습니다. 범위 검색 연산자의 구문은 다음과 같습니다.
```
@:[ [(] [(] ]
```
...여기서 는 숫자 또는 \$1inf 또는 -inf입니다. 선행 개방형 구문이 없는 경계는 포함되고 선행 개방형 구문이 있는 경계는 제외됩니다.
다음 표를 사용하여 쿼리 필터링에 수학 표현식을 매핑합니다.
```
min <= field <= max @field:[min max]
min < field <= max @field:[(min max]
min <= field < max @field:[min (max]
min < field < max @field:[(min (max]
field >= min @field:[min +inf]
field > min @field:[(min +inf]
field <= max @field:[-inf max]
field < max @field:[-inf (max]
field == val @field:[val val]
```
**논리 연산자**
논리 연산자를 사용하여 복잡한 쿼리를 구성하는 데 여러 태그와 숫자 검색 연산자를 사용할 수 있습니다.
**Logical AND**
Logical AND를 설정하려면 조건자 사이에 공백을 사용합니다. 예제:
`query1 query2 query3`
**Logical OR**
Logical OR을 설정하려면 조건자 사이에 공백을 사용합니다. 예제:
`query1 | query2 | query3`
**논리적 부정**
각 쿼리 앞에 `-` 문자를 추가하여 모든 쿼리를 부정할 수 있습니다. 음수 쿼리는 쿼리와 일치하지 않는 모든 항목을 반환합니다. 여기에는 필드가 없는 키도 포함됩니다.
예를 들어 @genre:\$1comedy\$1에 대한 부정 쿼리는 코미디가 아닌 모든 책과 장르 필드가 없는 모든 책을 반환합니다.
다음 쿼리는 2015년부터 2024년까지 게시되지 않았거나 연도 필드가 없는 ‘comedy’ 장르가 있는 모든 책을 반환합니다. @genre:[comedy] -@year:[2015 2024]
**연산자 우선순위**
일반적인 연산자 우선순위 규칙이 적용됩니다. 즉, 논리적 NEGATE가 우선순위가 가장 높고, 논리적 AND 다음 논리적 OR이 우선순위가 가장 낮습니다. 기본 우선순위를 재정의하려면 괄호를 사용할 수 있습니다.
*논리 연산자 결합의 예*
논리 연산자를 결합하여 복잡한 필터 표현식을 만들 수 있습니다.
다음 쿼리는 2015년부터 2024년까지 게시된 ‘comedy’ 또는 ‘horror’ 장르(AND)가 포함된 모든 책을 반환합니다. `@genre:[comedy|horror] @year:[2015 2024]`
다음 쿼리는 2015년부터 2024년까지 게시된 ‘comedy’ 또는 ‘horror’ 장르(OR)가 포함된 모든 책을 반환합니다. `@genre:[comedy|horror] | @year:[2015 2024]`
다음 쿼리는 장르 필드가 없거나 2015년부터 2024년까지 게시된 ‘comedy’와 같지 않은 장르 필드가 있는 모든 책을 반환합니다. `-@genre:[comedy] @year:[2015 2024]`
# FT.DROPINDEX
**구문**
```
FT.DROPINDEX
```
지정된 인덱스가 삭제됩니다. 해당 인덱스가 없는 경우 OK 또는 오류를 반환합니다.
+ (필수): 삭제할 인덱스의 이름입니다.
# FT.INFO
**구문**
```
FT.INFO
```
벡터 검색은 통계 및 카운터의 여러 추가 섹션으로 [FT.INFO](https://valkey.io/commands/info/) 명령을 보강합니다. SEARCH 섹션 검색을 요청하면 다음 섹션이 모두 검색됩니다.
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| index\$1name | 문자열 | 인덱스의 이름 |
| index\$1options | 문자열 | 예약. 현재 ‘0’으로 설정되어 있습니다. |
| index\$1definition | 배열 | 이러한 배열 요소의 정의는 아래를 참조하세요. |
| attributes | 속성 정보 배열 | 정의된 각 속성에 대해 이 배열의 요소 하나가 해당됩니다. 속성 정보 정의는 아래를 참조하세요. |
| num\$1docs | 정수 | 현재 인덱스에 포함된 키 수 |
| num\$1terms | 정수 | 예약. 현재 ‘0’으로 설정되어 있습니다. |
| record\$1count | 정수 | 각 속성에 대한 ‘size’ 필드의 합계입니다. |
| hash\$1indexing\$1failures | 정수 | 속성을 선언된 속성 유형으로 변환할 수 없는 횟수입니다. 이름에는 hash라고 나와 있지만 JSON 키에도 적용됩니다. |
| backfill\$1in\$1progress | 정수 | 채우기가 현재 진행 중인 경우 '1'이 되고, 그렇지 않으면 '0'이 됩니다. |
| backfill\$1percent\$1complete | 실수 | 채우기 완료 추정, [0..1] 범위의 소수입니다. |
| mutation\$1queue\$1size | 정수 | 인덱스 업데이트를 기다리는 키 수입니다. |
| recent\$1mutations\$1queue\$1delay | 정수 | 인덱스 업데이트의 지연(초) 추정치입니다. 진행 중인 업데이트가 없는 경우 0입니다. |
| state | 문자열 | 채우기 상태: ‘ready’는 채우기가 성공적으로 완료되었음을 나타냅니다. ‘backfill\$1in\$1progress’는 채우기가 진행 중임을 나타냅니다. ‘backfill\$1paused\$1by\$1oom’은 메모리 부족 조건으로 인해 채우기가 일시 중지되었음을 의미합니다. 메모리 부족 조건이 해결되면 채우기가 계속됩니다. |
index\$1definition 구조는 다음과 같이 정의된 키/값 페어의 배열입니다.
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| key\$1type | 문자열 | 문자열 'JSON' 또는 문자열 'HASH'입니다. |
| prefixes | 배열 | 배열의 각 요소는 인덱스에 대해 정의된 접두사입니다. 인덱스를 생성할 때 접두사를 지정하지 않은 경우 이 배열에는 0개의 항목이 있습니다. |
| default\$1score | 문자열 | 예약. 현재 ‘1’로 설정되어 있습니다. |
속성 정보: 속성 정보는 유형별로 다릅니다.
숫자 속성:
| Key(키) | 값 유형 | 설명 |
| --- | --- | --- |
| 식별자 | 문자열 | 키 내 속성의 위치입니다. 해시 멤버 이름 또는 JSON 경로 |
| 별칭 | 문자열 | 쿼리 설명에 사용되는 속성의 이름입니다. |
| type | 문자열 | 문자열 ‘NUMERIC’입니다. |
| size | 정수 | 이 속성에서 유효한 숫자 값이 있는 키 수입니다. |
태그 속성:
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| 식별자 | 문자열 | 키 내 속성의 위치입니다. 해시 멤버 이름 또는 JSON 경로 |
| 별칭 | 문자열 | 쿼리 설명에 사용되는 속성의 이름입니다. |
| type | 문자열 | 문자열 ‘TAG’입니다. |
| SEPARATOR | character | 인덱스가 생성될 때 정의된 구분자 문자입니다. |
| CASESENSITIVE | 해당 사항 없음 | 이 키에는 연결된 값이 없습니다. 이 옵션을 사용하여 속성을 생성한 경우에만 표시됩니다. |
| size | 정수 | 이 속성에 유효한 태그 값이 있는 키 수입니다. |
벡터 속성:
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| 식별자 | 문자열 | 키 내 속성의 위치입니다. 해시 멤버 이름 또는 JSON 경로 |
| 별칭 | 문자열 | 쿼리 설명에 사용되는 속성의 이름입니다. |
| type | 문자열 | 문자열 ‘VECTOR’입니다. |
| 인덱스 | character | 벡터 인덱스에 대한 자세한 설명은 아래를 참조하세요. |
벡터 인덱스 설명:
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| 용량 | 문자열 | 인덱스의 현재 용량 |
| 차원 | 문자열 | 각 벡터의 요소 수 |
| distance\$1metric | 문자열 | 다음 중 하나: ‘COSINE’, ‘L2’ 또는 ‘IP’ |
| size | 배열 | 벡터 인덱스에 대한 설명은 아래를 참조하세요. |
| data\$1type | 문자열 | 선언된 데이터 형식입니다. 현재는 ‘FLOAT32’만 지원됩니다. |
| 알고리즘 | 배열 | 벡터 검색 알고리즘에 대한 추가 설명입니다. |
FLAT 벡터 검색 알고리즘 설명:
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| 이름 | 문자열 | 알고리즘 이름: FLAT |
| block\$1size | number | FLAT 인덱스의 블록 크기입니다. |
HNSW 벡터 인덱스 설명:
| 키 이름 | 값 유형 | 설명 |
| --- | --- | --- |
| 이름 | 문자열 | 알고리즘 이름: HNSW |
| m | number | HNSW의 ‘M’ 파라미터 |
| ef\$1construction | number | HNSW의 ‘ef\$1construction’ 파라미터 |
| ef\$1runtime | number | HNSW에 대한 ‘ef\$1runtime’ 파라미터입니다. |
# FT.\$1LIST
모든 인덱스를 나열합니다.
**구문**
```
FT._LIST
```
현재 정의된 인덱스의 이름인 문자열 배열을 반환합니다.
# Valkey 및 Redis OSS용 JSON 시작하기
ElastiCache는 기본 JSON(JavaScript Object Notation) 형식을 지원합니다. 이는 Valkey 및 Redis OSS 클러스터 내에서 복잡한 데이터세트를 인코딩하는 간단한 스키마리스 방법입니다. 클러스터 내에서 JSON(JavaScript Object Notation) 형식을 사용하여 데이터를 저장하고 액세스하고, 직렬화 및 역직렬화를 위해 사용자 지정 코드를 관리할 필요 없이 해당 클러스터에 저장된 JSON 데이터를 업데이트할 수 있습니다.
JSON을 통해 작동하는 애플리케이션에 대해 Valkey 및 Redis OSS API 작업을 사용하는 것 외에 전체 객체를 조작할 필요 없이 JSON 문서의 특정 부분을 효율적으로 검색하고 업데이트할 수 있습니다. 이렇게 하면 성능을 개선하고 비용을 절감할 수 있습니다. [Goessner 방식](https://goessner.net/articles/JsonPath/)의 `JSONPath` 쿼리를 사용하여 JSON 문서 내용을 검색할 수도 있습니다.
지원되는 엔진 버전으로 클러스터를 생성하면 JSON 데이터 유형 및 관련 명령을 자동으로 사용할 수 있습니다. SON 모듈의 버전 2와 API 및 RDB가 호환 가능하게 되므로 기존 JSON 기반 Valkey 및 Redis OSS 애플리케이션을 ElastiCache로 쉽게 마이그레이션할 수 있습니다. 지원되는 명령에 대한 자세한 정보은 [지원되는 Valkey 및 Redis OSS 명령JSON 명령](json-list-commands.md) 섹션을 참조하세요.
JSON 관련 지표 `JsonBasedCmds` 및 `JsonBasedCmdsLatency`는 CloudWatch에 통합되어 이 데이터 유형의 사용을 모니터링합니다. 자세한 정보는 [Valkey 및 Redis OSS 지표](CacheMetrics.Redis.md) 섹션을 참조하세요.
**참고**
JSON을 사용하려면 Valkey 7.2 이상 또는 Redis OSS 6.2.6 이상을 실행해야 합니다.
**Topics**
+ [JSON 데이터 유형 개요](json-document-overview.md)
+ [지원되는 Valkey 및 Redis OSS 명령](json-list-commands.md)
# JSON 데이터 유형 개요
ElastiCache는 JSON 데이터 유형으로 작업하기 위해 다양한 Valkey 및 Redis OSS 명령을 지원합니다. 다음은 JSON 데이터 유형의 개요 및 지원되는 명령의 세부 목록입니다.
## 용어
****
| Term | 설명 |
| --- | --- |
| JSON 문서 | JSON 키의 값을 참조합니다. |
| JSON 값 | 전체 문서를 나타내는 루트를 포함하는 JSON 문서의 하위 집합을 참조합니다. 값은 컨테이너 또는 컨테이너 내의 항목일 수 있습니다. |
| JSON 요소 | JSON 값과 같습니다. |
## 지원되는 JSON 표준
JSON 형식은 [RFC 7159](https://www.ietf.org/rfc/rfc7159.txt) 및 [ECMA-404](https://www.ietf.org/rfc/rfc7159.txt) JSON 데이터 교환 표준과 호환됩니다. JSON 형식 텍스트에서 UTF-8 [유니코드](https://www.unicode.org/standard/WhatIsUnicode.html)가 지원됩니다.
## 루트 요소
루트 요소는 모든 JSON 데이터 유형일 수 있습니다. 이전 RFC 4627에서는 객체 또는 배열만 루트 값으로 허용되었습니다. RFC 7159로 업데이트한 이후 JSON 문서의 루트는 모든 JSON 데이터 유형이 될 수 있습니다.
## 문서 크기 제한
JSON 문서는 내부적으로 신속한 액세스 및 수정을 위해 최적화된 형식으로 저장됩니다. 이 형식은 일반적으로 동일한 문서의 동등하게 직렬화된 표현보다 어느 정도 더 많은 메모리를 소비하게 됩니다.
단일 JSON 문서에 의한 메모리 소비는 64MB로 제한됩니다. 이는 JSON 문자열이 아닌 메모리 내 데이터 구조의 크기입니다. `JSON.DEBUG MEMORY` 명령을 사용하여 JSON 문서가 소비하는 메모리 양을 확인할 수 있습니다.
## JSON ACL
+ 기존의 데이터 유형별 범주(@string, @hash 등)와 유사합니다. JSON 명령 및 데이터에 대한 액세스 권한 관리를 단순화하기 위해 새 범주 @json이 추가되었습니다. 다른 기존 Valkey 또는 Redis OSS 명령은 @json 범주에 속하지 않습니다. 모든 JSON 명령은 모든 키스페이스 또는 명령 제한 및 권한을 적용합니다.
+ @read, @write, @fast, @slow 및 @admin과 같은 새로운 JSON 명령을 포함하기 위해 업데이트된 다섯 가지 기존 Valkey 또는 Redis OSS ACL 범주가 있습니다. 다음의 표는 JSON 명령이 적절한 범주에 매핑되었음을 나타냅니다.
**ACL**
| JSON 명령 | @read | @write | @fast | @slow | @admin |
| --- | --- | --- | --- | --- | --- |
| JSON.ARRAPPEND | | y | y | | |
| JSON.ARRINDEX | y | | y | | |
| JSON.ARRINSERT | | y | y | | |
| JSON.ARRLEN | y | | y | | |
| JSON.ARRPOP | | y | y | | |
| JSON.ARRTRIM | | y | y | | |
| JSON.CLEAR | | y | y | | |
| JSON.DEBUG | y | | | y | y |
| JSON.DEL | | y | y | | |
| JSON.FORGET | | y | y | | |
| JSON.GET | y | | y | | |
| JSON.MGET | y | | y | | |
| JSON.NUMINCRBY | | y | y | | |
| JSON.NUMMULTBY | | y | y | | |
| JSON.OBJKEYS | y | | y | | |
| JSON.OBJLEN | y | | y | | |
| JSON.RESP | y | | y | | |
| JSON.SET | | y | | y | |
| JSON.STRAPPEND | | y | y | | |
| JSON.STRLEN | y | | y | | |
| JSON.STRLEN | y | | y | | |
| JSON.TOGGLE | | y | y | | |
| JSON.TYPE | y | | y | | |
| JSON.NUMINCRBY | | y | y | | |
## 중첩 깊이 제한
JSON 객체 또는 배열에 자체로 또 다른 JSON 객체 또는 배열인 요소가 있는 경우, 해당 내부 객체 또는 배열은 외부 객체 또는 배열 내에 '중첩'된다고 합니다. 최대 중첩 깊이 제한은 128입니다. 중첩 깊이가 128보다 큰 문서를 만들려는 시도는 오류와 함께 거부됩니다.
## 명령 구문
대부분의 명령에는 첫 번째 인수로 키 이름이 필요합니다. 일부 명령에는 path 인수도 있습니다. path 인수가 선택 사항이며 제공되지 않는 경우 기본적으로 루트로 설정됩니다.
표기법
+ 필수 인수는 각괄호로 묶습니다. 예:
+ 선택적 인수는 대괄호로 묶습니다. 예: [path]
+ 추가 선택적 인수는 줄임표('...')로 표시됩니다. 예: [json...]
## 경로 구문
Redis JSON은 다음과 같은 두 가지 종류의 경로 구문을 지원합니다.
+ **향상된 구문** - 다음의 표에 표시된 대로 [Goessner](https://goessner.net/articles/JsonPath/)에서 설명하는 JSONPath 구문을 따릅니다. 명확하게 하기 위해 표의 설명을 재정렬하고 수정했습니다.
+ **제한된 구문(Restricted syntax)** - 쿼리 기능이 제한되었습니다.
**참고**
일부 명령의 결과는 사용되는 경로 구문 유형에 민감합니다.
쿼리 경로가 '\$1'로 시작하는 경우 향상된 구문을 사용합니다. 그렇지 않으면 제한된 구문이 사용됩니다.
**향상된 구문**
****
| 기호/표현식 | 설명 |
| --- | --- |
| \$1 | 루트 요소. |
| . 또는 [] | 하위 연산자. |
| .. | 재귀 하강. |
| \$1 | 와일드카드. 객체 또는 배열의 모든 요소. |
| [] | 배열 아래 첨자 연산자. 인덱스는 0부터 시작합니다. |
| [,] | 조합 연산자. |
| [start:end:step] | 배열 조각 연산자. |
| ?() | 현재 배열 또는 객체에 필터(스크립트) 표현식을 적용합니다. |
| () | 필터 표현식. |
| @ | 처리 중인 현재 노드를 참조하는 필터 표현식에 사용됩니다. |
| == | 같음, 필터 표현식에 사용됩니다. |
| \$1= | 같지 않음, 필터 표현식에 사용됩니다. |
| > | 더 큼, 필터 표현식에 사용됩니다. |
| >= | 더 크거나 같음, 필터 표현식에 사용됩니다. |
| < | 더 작음, 필터 표현식에 사용됩니다. |
| <= | 더 작거나 같음, 필터 표현식에 사용됩니다. |
| && | 논리적 AND, 여러 필터 표현식을 결합하는 데 사용됩니다. |
| \$1\$1 | 논리적 OR, 여러 필터 표현식을 결합하는 데 사용됩니다. |
**예**
다음의 예는 추가 필드를 추가하여 수정한 [Goessner의](https://goessner.net/articles/JsonPath/) XML 데이터 예를 기반으로 구축되었습니다.
```
{ "store": {
"book": [
{ "category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95,
"in-stock": true,
"sold": true
},
{ "category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99,
"in-stock": false,
"sold": true
},
{ "category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99,
"in-stock": true,
"sold": false
},
{ "category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99,
"in-stock": false,
"sold": false
}
],
"bicycle": {
"color": "red",
"price": 19.95,
"in-stock": true,
"sold": false
}
}
}
```
****
| 경로 | 설명 |
| --- | --- |
| \$1.store.book[\$1].author | 상점에 있는 모든 책의 저자. |
| \$1..author | 모든 저자. |
| \$1.store.\$1 | 상점의 모든 구성원. |
| \$1["store"].\$1 | 상점의 모든 구성원. |
| \$1.store..price | 상점에 있는 모든 것의 가격. |
| \$1..\$1 | JSON 구조의 모든 재귀 멤버. |
| \$1..book[\$1] | 모든 책. |
| \$1..book[0] | 첫 번째 책. |
| \$1..book[-1] | 마지막 책. |
| \$1..book[0:2] | 처음 두 권의 책. |
| \$1..book[0,1] | 처음 두 권의 책. |
| \$1..book[0:4] | 인덱스 0에서 3까지의 책(끝 인덱스는 포괄적이지 않음). |
| \$1..book[0:4:2] | 인덱스 0, 2의 책. |
| \$1..book[?(@.isbn)] | ISBN 번호가 있는 모든 책. |
| \$1..book[?(@.price<10)] | 모든 책이 10달러보다 저렴합니다.. |
| '\$1..book[?(@.price < 10)]' | 모든 책이 10달러보다 저렴합니다. (경로에 공백이 포함된 경우 따옴표로 묶어야 합니다.) |
| '\$1..book[?(@["price"] < 10)]' | 모든 책이 10달러보다 저렴합니다.. |
| '\$1..book[?(@.["price"] < 10)]' | 모든 책이 10달러보다 저렴합니다.. |
| \$1..book[?(@.price>=10&&@.price<=100)] | 가격대가 10달러에서 100달러인 모든 책, 포괄적. |
| '\$1..book[?(@.price>=10 && @.price<=100)]' | 가격대가 10달러에서 100달러인 모든 책, 포괄적. (경로에 공백이 포함된 경우 따옴표로 묶어야 합니다.) |
| \$1..book[?(@.sold==true\$1\$1@.in-stock==false)] | 모든 책이 매각 또는 품절되었습니다. |
| '\$1..book[?(@.sold == true \$1\$1 @.in-stock == false)]' | 모든 책이 매각 또는 품절되었습니다. (경로에 공백이 포함된 경우 따옴표로 묶어야 합니다.) |
| '\$1.store.book[?(@.["category"] == "fiction")]' | 소설 범주의 모든 책. |
| '\$1.store.book[?(@.["category"] \$1= "fiction")]' | 비소설 범주의 모든 책. |
추가 필터 표현식의 예:
```
127.0.0.1:6379> JSON.SET k1 . '{"books": [{"price":5,"sold":true,"in-stock":true,"title":"foo"}, {"price":15,"sold":false,"title":"abc"}]}'
OK
127.0.0.1:6379> JSON.GET k1 $.books[?(@.price>1&&@.price<20&&@.in-stock)]
"[{\"price\":5,\"sold\":true,\"in-stock\":true,\"title\":\"foo\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?(@.price>1 && @.price<20 && @.in-stock)]'
"[{\"price\":5,\"sold\":true,\"in-stock\":true,\"title\":\"foo\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?((@.price>1 && @.price<20) && (@.sold==false))]'
"[{\"price\":15,\"sold\":false,\"title\":\"abc\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?(@.title == "abc")]'
[{"price":15,"sold":false,"title":"abc"}]
127.0.0.1:6379> JSON.SET k2 . '[1,2,3,4,5]'
127.0.0.1:6379> JSON.GET k2 $.*.[?(@>2)]
"[3,4,5]"
127.0.0.1:6379> JSON.GET k2 '$.*.[?(@ > 2)]'
"[3,4,5]"
127.0.0.1:6379> JSON.SET k3 . '[true,false,true,false,null,1,2,3,4]'
OK
127.0.0.1:6379> JSON.GET k3 $.*.[?(@==true)]
"[true,true]"
127.0.0.1:6379> JSON.GET k3 '$.*.[?(@ == true)]'
"[true,true]"
127.0.0.1:6379> JSON.GET k3 $.*.[?(@>1)]
"[2,3,4]"
127.0.0.1:6379> JSON.GET k3 '$.*.[?(@ > 1)]'
"[2,3,4]"
```
**제한된 구문(Restricted syntax)**
****
| 기호/표현식 | 설명 |
| --- | --- |
| . 또는 [] | 하위 연산자. |
| [] | 배열 아래 첨자 연산자. 인덱스는 0부터 시작합니다. |
**예시**
****
| 경로 | 설명 |
| --- | --- |
| .store.book[0].author | 첫 번째 책의 저자. |
| .store.book[-1].author | 마지막 책의 저자. |
| .address.city | 도시 이름. |
| ["store"]["book"][0]["title"] | 첫 번째 책의 제목. |
| ["store"]["book"][-1]["title"] | 마지막 책의 제목. |
**참고**
이 문서에 인용된 모든 [Goessner](https://goessner.net/articles/JsonPath/) 콘텐츠는 [크리에이티브 커먼즈 라이선스](https://creativecommons.org/licenses/by/2.5/)에 해당합니다.
## 일반적인 오류 접두사
각 오류 메시지에는 접두사가 있습니다. 다음은 일반적인 오류 접두사 목록입니다.
****
| Prefix | 설명 |
| --- | --- |
| ERR | 일반 오류. |
| LIMIT | 크기 제한을 초과한 경우 발생하는 오류입니다. 예: 문서 크기 제한 또는 중첩 깊이 제한이 초과되었습니다. |
| NONEXISTENT | 키 또는 경로가 존재하지 않습니다. |
| OUTOFBOUNDARIES | 배열 인덱스가 범위를 벗어났습니다. |
| SYNTAXERR | 구문 오류. |
| WRONGTYPE | 잘못된 값 유형. |
## JSON-관련 지표
다음과 같은 JSON 정보 지표가 제공됩니다.
****
| 정보 | 설명 |
| --- | --- |
| json\$1total\$1memory\$1bytes | JSON 객체에 할당되는 총 메모리. |
| json\$1num\$1documents | Valkey 또는 Redis OSS의 총 문서 수. |
핵심 지표를 쿼리하려면 다음과 같은 명령을 실행합니다.
```
info json_core_metrics
```
## ElastiCache for Valkey 및 Redis OSS가 JSON과 상호 작용하는 방법
다음의 섹션에서는 ElastiCache for Valkey 및 Redis OSS가 JSON과 상호 작용하는 방법을 설명합니다.
### 연산자 우선순위
필터링에 대한 조건식을 평가하는 경우 &&s가 먼저 평가되고 그 다음 \$1\$1s가 평가되는데, 이는 대부분의 언어에서 일반적으로 사용됩니다. 괄호 안의 연산이 먼저 실행됩니다.
### 최대 경로 중첩 제한 동작
ElastiCache for Redis OSS의 최대 경로 중첩 제한은 128입니다. 따라서 `$.a.b.c.d...`와 같은 값은 128수준까지만 도달할 수 있습니다.
### 숫자 값 처리
JSON에는 정수와 부동 소수점 숫자에 대해 별도의 데이터 유형이 없습니다. 모두 숫자라고 부릅니다.
숫자 표현:
입력 시 JSON 번호가 수신되면 해당 번호는 부호가 있는 64비트 정수 또는 64비트 IEEE 배정밀도 부동 소수점과 같은 두 개의 내부 이진 표현 중 하나로 변환됩니다. 원래 문자열 및 모든해당 서식은 보관되지 않습니다. 따라서 JSON 응답의 일부로 숫자가 출력되면 해당 숫자는 내부 이진 표현에서 일반 서식 규칙을 사용하는 인쇄 가능한 문자열로 변환됩니다. 이러한 규칙은 수신된 문자열과 다른 문자열이 생성될 수 있습니다.
산술 명령어 `NUMINCRBY`과 `NUMMULTBY`:
+ 두 숫자가 모두 정수이고 결과가 `int64`의 범위를 벗어나는 경우 자동으로 64비트 IEEE 배정밀도 부동 소수점 숫자가 됩니다.
+ 숫자 중 하나 이상이 부동 소수점인 경우 결과는 64비트 IEEE 배정밀도 부동 소수점 숫자입니다.
+ 결과가 64비트 IEEE 배정밀도 범위를 초과한 경우 명령은 `OVERFLOW` 오류를 반환합니다.
사용할 수 있는 명령의 자세한 목록은 [지원되는 Valkey 및 Redis OSS 명령JSON 명령](json-list-commands.md) 섹션을 참조하세요.
### 직접 배열 필터링
ElastiCache for Valkey 및 Redis OSS는 직접 객체 배열을 필터링합니다.
`[0,1,2,3,4,5,6]`과 같은 데이터 및 `$[?(@<4)]`와 같은 경로 쿼리, 또는 `{"my_key":[0,1,2,3,4,5,6]}`과 같은 데이터 및 `$.my_key[?(@<4)]`와 같은 경로 쿼리의 경우 ElastiCache는 두 경우 모두 [1,2,3]을 반환합니다.
### 배열 인덱싱 동작
ElastiCache for Valkey 및 Redis OSS는 배열에 대해 포지티브 및 네거티브 인덱스 모두를 허용합니다. 길이가 5인 배열의 경우 0이 첫 번째 요소, 1이 두 번째 요소를 쿼리하는 식입니다. 음수는 배열의 끝에서 시작하므로 -1은 다섯 번째 요소를 쿼리하고, -2는 네 번째 요소를 쿼리하는 식입니다.
고객의 예측 가능한 행동을 보장하려면 ElastiCache는 배열 인덱스를 반올림이나 반내림하지 않습니다. 따라서 길이가 5인 배열이 있는 경우 인덱스 5 이상 또는 -6 이하를 직접 호출하면 결과가 생성되지 않습니다.
### 엄격한 구문 평가
MemoryDB에서는 경로의 하위 집합에 유효한 경로가 포함되어 있더라도 잘못된 구문으로 JSON 경로를 허용하지 않습니다. 이는 고객에게 올바른 행동을 유지하는 것과 같습니다.
# 지원되는 Valkey 및 Redis OSS 명령
ElastiCache는 다음과 같은 Valkey 및 Redis OSS JSON 명령을 지원합니다.
**Topics**
+ [JSON.ARRAPPEND](json-arrappend.md)
+ [JSON.ARRINDEX](json-arrindex.md)
+ [JSON.ARRINSERT](json-arrinsert.md)
+ [JSON.ARRLEN](json-arrlen.md)
+ [JSON.ARRPOP](json-arrpop.md)
+ [JSON.ARRTRIM](json-arrtrim.md)
+ [JSON.CLEAR](json-clear.md)
+ [JSON.DEBUG](json-debug.md)
+ [JSON.DEL](json-del.md)
+ [JSON.FORGET](json-forget.md)
+ [JSON.GET](json-get.md)
+ [JSON.MGET](json-mget.md)
+ [JSON.MSET](json-mset.md)
+ [JSON.NUMINCRBY](json-numincrby.md)
+ [JSON.NUMMULTBY](json-nummultby.md)
+ [JSON.OBJLEN](json-objlen.md)
+ [JSON.OBJKEYS](json-objkeys.md)
+ [JSON.RESP](json-resp.md)
+ [JSON.SET](json-set.md)
+ [JSON.STRAPPEND](json-strappend.md)
+ [JSON.STRLEN](json-strlen.md)
+ [JSON.TOGGLE](json-toggle.md)
+ [JSON.TYPE](json-type.md)
# JSON.ARRAPPEND
하나 이상의 값을 경로의 배열 값에 추가합니다.
구문
```
JSON.ARRAPPEND [json ...]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
+ json(필수) - 배열에 추가할 JSON 값입니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 배열의 새 길이를 나타내는 정수 배열입니다.
+ 값이 배열이 아닌 경우 해당 반환 값은 null입니다.
+ 경로가 존재하지 않는 경우 `NONEXISTENT` 오류가 발생합니다.
경로가 제한된 구문인 경우
+ 정수, 배열의 새 길이.
+ 여러 배열 값을 선택한 경우 명령은 마지막으로 업데이트된 배열의 새 길이를 반환합니다.
+ 경로의 값이 배열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 입력 json 인수 중 하나가 유효한 JSON 문자열이 아닌 경우 `SYNTAXERR` 오류가 발생합니다.
+ 경로가 존재하지 않는 경우 `NONEXISTENT` 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRAPPEND k1 $[*] '"c"'
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> JSON.GET k1
"[[\"c\"],[\"a\",\"c\"],[\"a\",\"b\",\"c\"]]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRAPPEND k1 [-1] '"c"'
(integer) 3
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"],[\"a\",\"b\",\"c\"]]"
```
# JSON.ARRINDEX
경로의 배열에서 처음 나타나는 스칼라 JSON 값을 검색합니다.
+ 범위를 벗어난 오류는 인덱스를 배열의 시작과 끝으로 반올림하여 처리됩니다.
+ 시작 > 끝이면 -1(찾을 수 없음)을 반환합니다.
구문
```
JSON.ARRINDEX [start [end]]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
+ json-scalar(필수) - 검색 대상인 스칼라 값입니다. JSON 스칼라는 객체나 배열이 아닌 값을 참조합니다. 즉, 문자열, 숫자, 부울 및 null은 스칼라 값입니다.
+ 시작(선택 사항) - 시작 인덱스는 포괄적입니다. 제공하지 않으면 기본적으로 0으로 설정됩니다.
+ 끝(선택 사항) - 끝 인덱스는 배타적입니다. 제공되지 않은 경우 기본적으로 0으로 설정됩니다. 즉, 마지막 요소가 포함된다는 의미입니다. 0 또는 -1은 마지막 요소가 포함되었음을 의미합니다.
**반환**
경로가 향상된 구문인 경우
+ 정수 배열입니다. 각 값은 경로에 있는 배열에서 일치하는 요소의 인덱스입니다. 발견되지 않은 경우 값은 -1입니다.
+ 값이 배열이 아닌 경우 해당 반환 값은 null입니다.
경로가 제한된 구문인 경우
+ 정수이며, 일치하는 요소의 인덱스입니다. 또는 찾을 수 없는 경우 -1입니다.
+ 경로의 값이 배열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRINDEX k1 $[*] '"b"'
1) (integer) -1
2) (integer) -1
3) (integer) 1
4) (integer) 1
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.ARRINDEX k1 .children '"Tom"'
(integer) 2
```
# JSON.ARRINSERT
경로의 값 배열에서 인덱스 앞에 하나 이상의 값을 삽입합니다.
구문
```
JSON.ARRINSERT [json ...]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
+ 인덱스(필수) - 삽입된 값의 앞에 있는 배열 인덱스입니다.
+ json(필수) - 배열에 추가할 JSON 값입니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 배열의 새 길이를 나타내는 정수 배열입니다.
+ 값이 빈 배열인 경우 해당 반환 값은 null입니다.
+ 값이 배열이 아닌 경우 해당 반환 값은 null입니다.
+ 인덱스 인수가 범위를 벗어난 경우 `OUTOFBOUNDARIES` 오류가 발생합니다.
경로가 제한된 구문인 경우
+ 정수, 배열의 새 길이.
+ 경로의 값이 배열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 인덱스 인수가 범위를 벗어난 경우 `OUTOFBOUNDARIES` 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRINSERT k1 $[*] 0 '"c"'
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> JSON.GET k1
"[[\"c\"],[\"c\",\"a\"],[\"c\",\"a\",\"b\"]]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRINSERT k1 . 0 '"c"'
(integer) 4
127.0.0.1:6379> JSON.GET k1
"[\"c\",[],[\"a\"],[\"a\",\"b\"]]"
```
# JSON.ARRLEN
경로에서 배열 값의 길이를 얻습니다.
구문
```
JSON.ARRLEN [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 배열 길이를 나타내는 정수 배열입니다.
+ 값이 배열이 아닌 경우 해당 반환 값은 null입니다.
+ 문서 키가 없으면 Null입니다.
경로가 제한된 구문인 경우
+ 정수, 배열 길이.
+ 여러 객체를 선택한 경우 명령은 첫 번째 배열의 길이를 반환합니다.
+ 경로의 값이 배열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ `NONEXISTENT JSON`경로가 존재하지 않는 경우 오류가 발생합니다.
+ 문서 키가 없으면 Null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRLEN k1 $[*]
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 3
127.0.0.1:6379> JSON.SET k2 . '[[], "a", ["a", "b"], ["a", "b", "c"], 4]'
OK
127.0.0.1:6379> JSON.ARRLEN k2 $[*]
1) (integer) 0
2) (nil)
3) (integer) 2
4) (integer) 3
5) (nil)
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRLEN k1 [*]
(integer) 0
127.0.0.1:6379> JSON.ARRLEN k1 [1]
(integer) 1
127.0.0.1:6379> JSON.ARRLEN k1 [2]
(integer) 2
127.0.0.1:6379> JSON.SET k2 . '[[], "a", ["a", "b"], ["a", "b", "c"], 4]'
OK
127.0.0.1:6379> JSON.ARRLEN k2 [1]
(error) WRONGTYPE JSON element is not an array
127.0.0.1:6379> JSON.ARRLEN k2 [0]
(integer) 0
127.0.0.1:6379> JSON.ARRLEN k2 [6]
(error) OUTOFBOUNDARIES Array index is out of bounds
127.0.0.1:6379> JSON.ARRLEN k2 a.b
(error) NONEXISTENT JSON path does not exist
```
# JSON.ARRPOP
배열에서 인덱스의 요소를 제거하고 반환합니다. 빈 배열을 팝하면 null이 반환됩니다.
구문
```
JSON.ARRPOP [path [index]]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 루트로 설정됩니다.
+ 인덱스(선택 사항) - 팝업을 시작할 배열의 위치입니다.
+ 제공되지 않으면 기본적으로 마지막 요소를 의미하는 -1로 설정됩니다.
+ 음수 값은 마지막 요소의 위치를 의미합니다.
+ 경계를 벗어난 인덱스는 각각의 배열 경계로 반올림됩니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 팝된 값을 나타내는 대량 문자열 배열입니다.
+ 값이 빈 배열인 경우 해당 반환 값은 null입니다.
+ 값이 배열이 아닌 경우 해당 반환 값은 null입니다.
경로가 제한된 구문인 경우
+ 대량 문자열, 팝된 JSON 값을 나타냅니다.
+ 배열인 비어 있는 경우 null입니다.
+ 경로의 값이 배열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k1 $[*]
1) (nil)
2) "\"a\""
3) "\"b\""
127.0.0.1:6379> JSON.GET k1
"[[],[],[\"a\"]]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k1
"[\"a\",\"b\"]"
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"]]"
127.0.0.1:6379> JSON.SET k2 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k2 . 0
"[]"
127.0.0.1:6379> JSON.GET k2
"[[\"a\"],[\"a\",\"b\"]]"
```
# JSON.ARRTRIM
경로의 배열을 자르므로 하위 배열[시작, 끝] 둘 다 포괄적이 됩니다.
+ 배열이 비어 있는 경우 아무 것도 하지 않고 0을 반환합니다.
+ 시작 < 0인 경우 0으로 처리합니다.
+ 끝 >= 크기(배열의 크기)인 경우 크기-1로 처리합니다.
+ 시작 >= 크기 또는 시작 > 끝인 경우 배열을 비우고 0을 반환합니다.
구문
```
JSON.ARRTRIM
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
+ 시작(필수) - 시작 인덱스는 포괄적입니다.
+ 끝(필수) - 끝 인텍스, 포괄적입니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 배열의 새 길이를 나타내는 정수 배열입니다.
+ 값이 빈 배열인 경우 해당 반환 값은 null입니다.
+ 값이 배열이 아닌 경우 해당 반환 값은 null입니다.
+ 인덱스 인수가 범위를 벗어난 경우 `OUTOFBOUNDARIES` 오류가 발생합니다.
경로가 제한된 구문인 경우
+ 정수, 배열의 새 길이.
+ 배열인 비어 있는 경우 null입니다.
+ 경로의 값이 배열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 인덱스 인수가 범위를 벗어난 경우 `OUTOFBOUNDARIES` 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRTRIM k1 $[*] 0 1
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 2
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"],[\"a\",\"b\"],[\"a\",\"b\"]]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.ARRTRIM k1 .children 0 1
(integer) 2
127.0.0.1:6379> JSON.GET k1 .children
"[\"John\",\"Jack\"]"
```
# JSON.CLEAR
경로의 배열 또는 객체를 삭제합니다.
구문
```
JSON.CLEAR [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
+ 정수, 삭제된 컨테이너의 수입니다.
+ 삭제된 하나의 컨테이너에 대해 빈 배열 또는 객체 계정을 삭제합니다.
+ 컨테이너가 아닌 값을 삭제하면 0이 반환됩니다.
**예**
```
127.0.0.1:6379> JSON.SET k1 . '[[], [0], [0,1], [0,1,2], 1, true, null, "d"]'
OK
127.0.0.1:6379> JSON.CLEAR k1 $[*]
(integer) 7
127.0.0.1:6379> JSON.CLEAR k1 $[*]
(integer) 4
127.0.0.1:6379> JSON.SET k2 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.CLEAR k2 .children
(integer) 1
127.0.0.1:6379> JSON.GET k2 .children
"[]"
```
# JSON.DEBUG
보고서 정보 지원되는 하위 명령은 다음과 같습니다.
+ MEMORY [path] - 메모리 사용량(단위: JSON 값 바이트)을 보고합니다. 경로는 제공되지 않으면 기본적으로 root로 설정됩니다.
+ FIELDS [path] - 지정된 문서 경로의 필드 수를 보고합니다. 경로는 제공되지 않으면 기본적으로 root로 설정됩니다. 컨테이너가 아닌 각 JSON 값은 하나의 필드로 계산됩니다. 객체와 배열은 포함하는 JSON 값 각각에 대해 하나의 필드를 재귀적으로 계산합니다. 루트 컨테이너를 제외한 각 컨테이너 값은 하나의 추가 필드로 계산됩니다.
+ HELP - 명령의 도움말 메시지를 출력합니다.
구문
```
JSON.DEBUG
```
다음의 하위 명령에 따라 다릅니다.
MEMORY
+ 경로가 향상된 구문인 경우
+ 각 경로에 있는 JSON 값의 메모리 크기(바이트)를 나타내는 정수로 구성된 배열을 반환합니다.
+ Valkey 또는 Redis OSS 키가 없으면 빈 배열을 반환합니다.
+ 경로가 제한된 구문인 경우
+ 정수, 메모리 크기 및 JSON 값(단위: 바이트)을 반환합니다.
+ Valkey 또는 Redis OSS 키가 없으면 null을 반환합니다.
FIELDS
+ 경로가 향상된 구문인 경우
+ 각 경로에 있는 JSON 값의 필드 수를 나타내는 정수로 구성된 배열을 반반환합니다.
+ Valkey 또는 Redis OSS 키가 없으면 빈 배열을 반환합니다.
+ 경로가 제한된 구문인 경우
+ JSON 값의 필드 개수인 정수를 반환합니다.
+ Valkey 또는 Redis OSS 키가 없으면 null을 반환합니다.
HELP - 도움말 메시지 배열을 반환합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[1, 2.3, "foo", true, null, {}, [], {"a":1, "b":2}, [1,2,3]]'
OK
127.0.0.1:6379> JSON.DEBUG MEMORY k1 $[*]
1) (integer) 16
2) (integer) 16
3) (integer) 19
4) (integer) 16
5) (integer) 16
6) (integer) 16
7) (integer) 16
8) (integer) 50
9) (integer) 64
127.0.0.1:6379> JSON.DEBUG FIELDS k1 $[*]
1) (integer) 1
2) (integer) 1
3) (integer) 1
4) (integer) 1
5) (integer) 1
6) (integer) 0
7) (integer) 0
8) (integer) 2
9) (integer) 3
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.DEBUG MEMORY k1
(integer) 632
127.0.0.1:6379> JSON.DEBUG MEMORY k1 .phoneNumbers
(integer) 166
127.0.0.1:6379> JSON.DEBUG FIELDS k1
(integer) 19
127.0.0.1:6379> JSON.DEBUG FIELDS k1 .address
(integer) 4
127.0.0.1:6379> JSON.DEBUG HELP
1) JSON.DEBUG MEMORY [path] - report memory size (bytes) of the JSON element. Path defaults to root if not provided.
2) JSON.DEBUG FIELDS [path] - report number of fields in the JSON element. Path defaults to root if not provided.
3) JSON.DEBUG HELP - print help message.
```
# JSON.DEL
문서 키의 경로에 있는 JSON 값을 삭제합니다. 경로가 root이면 Valkey 또는 Redis OSS에서 키를 삭제하는 것과 같습니다.
구문
```
JSON.DEL [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
+ 삭제된 요소 수입니다.
+ Valkey 또는 Redis OSS 키가 없으면 0입니다.
+ JSON 경로가 잘못되었거나 존재하지 않는 경우 0입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.DEL k1 $.d.*
(integer) 3
127.0.0.1:6379> JSOn.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.DEL k1 $.e[*]
(integer) 5
127.0.0.1:6379> JSOn.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[]}"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.DEL k1 .d.*
(integer) 3
127.0.0.1:6379> JSON.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.DEL k1 .e[*]
(integer) 5
127.0.0.1:6379> JSON.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[]}"
```
# JSON.FORGET
[JSON.DEL](json-del.md)의 별칭.
# JSON.GET
하나 또는 여러 경로에서 직렬화된 JSON을 반환합니다.
구문
```
JSON.GET
[INDENT indentation-string]
[NEWLINE newline-string]
[SPACE space-string]
[NOESCAPE]
[path ...]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ INDENT/NEWLINE/SPACE(선택 사항) - 반환된 JSON 문자열(즉, "예쁜 인쇄")의 형식을 제어합니다. 각 문자열의 기본값은 빈 문자열이며, 모든 조합으로 재정의될 수 있습니다. 임의의 순서로 지정할 수 있습니다.
+ NOESCAPE - 선택 사항, 레거시 호환성을 위해 사용할 수 있으며 다른 효과는 없습니다.
+ 경로(선택 사항) - 0개 이상의 JSON 경로, 아무 것도 제공되지 않는 경우 기본적으로 루트로 설정됩니다. 경로 인수는 끝에 배치해야 합니다.
**반환**
향상된 경로 구문.
경로가 하나 지정된 경우,
+ 값의 배열의 직렬화된 문자열을 반환합니다.
+ 값을 선택하지 않은 경우 명령은 빈 배열을 반환합니다.
여러 경로가 지정된 경우,
+ 각 경로가 키인 문자열화된 JSON 객체를 반환합니다.
+ 향상된 경로 구문과 제한된 경로 구문이 혼합된 경우 결과는 향상된 구문을 따릅니다.
+ 경로가 없는 경우 해당 값은 빈 배열입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.GET k1 $.address.*
"[\"21 2nd Street\",\"New York\",\"NY\",\"10021-3100\"]"
127.0.0.1:6379> JSON.GET k1 indent "\t" space " " NEWLINE "\n" $.address.*
"[\n\t\"21 2nd Street\",\n\t\"New York\",\n\t\"NY\",\n\t\"10021-3100\"\n]"
127.0.0.1:6379> JSON.GET k1 $.firstName $.lastName $.age
"{\"$.firstName\":[\"John\"],\"$.lastName\":[\"Smith\"],\"$.age\":[27]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}}'
OK
127.0.0.1:6379> json.get k2 $..*
"[{},{\"a\":1},{\"a\":1,\"b\":2},1,1,2]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.GET k1 .address
"{\"street\":\"21 2nd Street\",\"city\":\"New York\",\"state\":\"NY\",\"zipcode\":\"10021-3100\"}"
127.0.0.1:6379> JSON.GET k1 indent "\t" space " " NEWLINE "\n" .address
"{\n\t\"street\": \"21 2nd Street\",\n\t\"city\": \"New York\",\n\t\"state\": \"NY\",\n\t\"zipcode\": \"10021-3100\"\n}"
127.0.0.1:6379> JSON.GET k1 .firstName .lastName .age
"{\".firstName\":\"John\",\".lastName\":\"Smith\",\".age\":27}"
```
# JSON.MGET
여러 문서 키의 경로에서 직렬화된 JSON을 얻습니다. 없는 키 또는 JSON 경로에 대해 null을 반환합니다.
**구문**
```
JSON.MGET [key ...]
```
+ 키(필수) - 문서 유형의 하나 이상의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
**반환**
+ 대량 문자열 배열 배열의 크기는 명령의 키 수와 같습니다. 키가 없는 경우, 경로가 문서에 없는 경우, 또는 경로가 잘못된 경우(구문 오류), 배열의 각 요소는 (a) 경로에 있는 직렬화된 JSON 또는 (b) null로 채워집니다.
+ 지정된 키 중 하나라도 있고 JSON 키가 아닌 경우 명령은 `WRONGTYPE` 오류를 반환합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021"}}'
OK
127.0.0.1:6379> JSON.SET k2 . '{"address":{"street":"5 main Street","city":"Boston","state":"MA","zipcode":"02101"}}'
OK
127.0.0.1:6379> JSON.SET k3 . '{"address":{"street":"100 Park Ave","city":"Seattle","state":"WA","zipcode":"98102"}}'
OK
127.0.0.1:6379> JSON.MGET k1 k2 k3 $.address.city
1) "[\"New York\"]"
2) "[\"Boston\"]"
3) "[\"Seattle\"]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021"}}'
OK
127.0.0.1:6379> JSON.SET k2 . '{"address":{"street":"5 main Street","city":"Boston","state":"MA","zipcode":"02101"}}'
OK
127.0.0.1:6379> JSON.SET k3 . '{"address":{"street":"100 Park Ave","city":"Seattle","state":"WA","zipcode":"98102"}}'
OK
127.0.0.1:6379> JSON.MGET k1 k2 k3 .address.city
1) "\"New York\""
2) "\"Seattle\""
3) "\"Seattle\""
```
# JSON.MSET
Valkey 버전 8.1 이상에서 지원됩니다.
여러 키의 JSON 값을 설정합니다. 작업은 원자성입니다. 모든 값이 설정되거나 아무 값도 설정되지 않습니다.
**구문**
```
JSON.MSET key path json [ key path json ... ]
```
+ 경로가 객체 멤버를 호출하는 경우
+ 상위 요소가 없는 경우, 다음 명령은 NONEXISTENT 오류를 반환합니다.
+ 상위 요소가 있지만 객체가 아닌 경우, 명령은 ERROR를 반환합니다.
+ 상위 요소가 있고 객체인 경우
+ 멤버가 없으면 상위 객체가 경로의 마지막 하위 객체인 경우에만 새 멤버는 상위 객체에 추가됩니다. 그렇지 않으면 명령은 NONEXISTENT 오류를 반환합니다.
+ 멤버가 있으면 해당 값이 JSON 값으로 대체됩니다.
+ 경로가 배열 인덱스를 호출하는 경우
+ 상위 요소가 없는 경우, 다음 명령은 NONEXISTENT 오류를 반환합니다.
+ 상위 요소가 있지만 배열이 아닌 경우, 명령은 ERROR를 반환합니다.
+ 상위 요소가 있지만 인덱스가 범위를 벗어난 경우, 명령은 OUTOFBOUNDARIES 오류를 반환합니다.
+ 상위 요소가 있고 인덱스가 유효하면 요소는 새 JSON 값으로 대체됩니다.
+ 경로가 객체 또는 배열을 호출하는 경우 값(객체 또는 배열)은 새 JSON 값으로 대체됩니다.
** 반환**
+ 단순 문자열 회신: 작업이 성공한 경우 '확인'입니다.
+ 단순 오류 응답: 작업이 실패한 경우입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.MSET k1 . '[1,2,3,4,5]' k2 . '{"a":{"a":1, "b":2, "c":3}}' k3 . '{"a": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.GET k1
"[1,2,3,4,5]"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.MSET k2 $.a.* '0' k3 $.a[*] '0'
OK
127.0.0.1:6379> JSON.GET k2
"{\"a\":{\"a\":0,\"b\":0,\"c\":0}}"
127.0.0.1:6379> JSON.GET k3
"{\"a\":[0,0,0,0,0]}"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.MSET k1 . '{"name": "John","address": {"street": "123 Main St","city": "Springfield"},"phones": ["555-1234","555-5678"]}'
OK
127.0.0.1:6379> JSON.MSET k1 .address.street '"21 2nd Street"' k1 .address.city '"New York"'
OK
127.0.0.1:6379> JSON.GET k1 .address.street
"\"21 2nd Street\""
127.0.0.1:6379> JSON.GET k1 .address.city
"\"New York\""
```
# JSON.NUMINCRBY
경로의 숫자 값을 지정된 수만큼 증가합니다.
구문
```
JSON.NUMINCRBY
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
+ 숫자(필수) - 숫자입니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 결과 값을 나타내는 대량 문자열 배열입니다.
+ 값이 숫자가 아닌 경우 해당 반환 값은 null입니다.
+ 숫자를 구문 분석할 수 없는 경우 `WRONGTYPE` 오류가 발생합니다.
+ 결과가 64비트 IEEE 배정밀도 범위를 벗어나는 경우 `OVERFLOW` 오류가 발생합니다.
+ 문서 키가 없는 경우 `NONEXISTENT`입니다.
경로가 제한된 구문인 경우
+ 결과 값을 나타내는 대량 문자열입니다.
+ 여러 값을 선택한 경우 명령은 마지막으로 업데이트된 값의 결과를 반환합니다.
+ 경로의 값이 숫자가 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 숫자를 구문 분석할 수 없는 경우 `WRONGTYPE` 오류가 발생합니다.
+ 결과가 64비트 IEEE 배정밀도 범위를 벗어나는 경우 `OVERFLOW` 오류가 발생합니다.
+ 문서 키가 없는 경우 `NONEXISTENT`입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 $.d[*] 10
"[11,12,13]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[11,12,13]}"
127.0.0.1:6379> JSON.SET k1 $ '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 $.a[*] 1
"[]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.b[*] 1
"[2]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.c[*] 1
"[2,3]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.d[*] 1
"[2,3,4]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[2,3,4]}"
127.0.0.1:6379> JSON.SET k2 $ '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k2 $.a.* 1
"[]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.b.* 1
"[2]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.c.* 1
"[2,3]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.d.* 1
"[2,3,4]"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":2,\"b\":3,\"c\":4}}"
127.0.0.1:6379> JSON.SET k3 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k3 $.a.* 1
"[null]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.b.* 1
"[null,2]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.c.* 1
"[null,null]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.d.* 1
"[2,null,4]"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":2,\"b\":\"b\",\"c\":4}}"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 .d[1] 10
"12"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[1,12,3]}"
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 .a[*] 1
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMINCRBY k1 .b[*] 1
"2"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[1,2],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMINCRBY k1 .c[*] 1
"3"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMINCRBY k1 .d[*] 1
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[2,3,4]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k2 .a.* 1
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMINCRBY k2 .b.* 1
"2"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":1,\"b\":2},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMINCRBY k2 .c.* 1
"3"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMINCRBY k2 .d.* 1
"4"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":2,\"b\":3,\"c\":4}}"
127.0.0.1:6379> JSON.SET k3 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k3 .a.* 1
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMINCRBY k3 .b.* 1
"2"
127.0.0.1:6379> JSON.NUMINCRBY k3 .c.* 1
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMINCRBY k3 .d.* 1
"4"
```
# JSON.NUMMULTBY
경로의 숫자 값을 지정된 수만큼 곱합니다.
구문
```
JSON.NUMMULTBY
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다.
+ 숫자(필수) - 숫자입니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 결과 값을 나타내는 대량 문자열 배열입니다.
+ 값이 숫자가 아닌 경우 해당 반환 값은 null입니다.
+ 숫자를 구문 분석할 수 없는 경우 `WRONGTYPE` 오류가 발생합니다.
+ 결과가 64비트 IEEE 배정밀 부동 소수점 숫자 범위를 벗어나는 경우 `OVERFLOW` 오류가 발생합니다.
+ 문서 키가 없는 경우 `NONEXISTENT`입니다.
경로가 제한된 구문인 경우
+ 결과 값을 나타내는 대량 문자열입니다.
+ 여러 값을 선택한 경우 명령은 마지막으로 업데이트된 값의 결과를 반환합니다.
+ 경로의 값이 숫자가 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 숫자를 구문 분석할 수 없는 경우 `WRONGTYPE` 오류가 발생합니다.
+ 결과가 64비트 IEEE 이중 범위를 벗어나는 경우 `OVERFLOW` 오류가 발생합니다.
+ 문서 키가 없는 경우 `NONEXISTENT`입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 $.d[*] 2
"[2,4,6]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[2,4,6]}"
127.0.0.1:6379> JSON.SET k1 $ '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 $.a[*] 2
"[]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.b[*] 2
"[2]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.c[*] 2
"[2,4]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.d[*] 2
"[2,4,6]"
127.0.0.1:6379> JSON.SET k2 $ '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k2 $.a.* 2
"[]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.b.* 2
"[2]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.c.* 2
"[2,4]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.d.* 2
"[2,4,6]"
127.0.0.1:6379> JSON.SET k3 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k3 $.a.* 2
"[null]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.b.* 2
"[null,2]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.c.* 2
"[null,null]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.d.* 2
"[2,null,6]"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 .d[1] 2
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[1,4,3]}"
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 .a[*] 2
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMMULTBY k1 .b[*] 2
"2"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[1,2],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMMULTBY k1 .c[*] 2
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,4],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMMULTBY k1 .d[*] 2
"6"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,4],\"d\":[2,4,6]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k2 .a.* 2
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMMULTBY k2 .b.* 2
"2"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":1,\"b\":2},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k2 .c.* 2
"4"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":4},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k2 .d.* 2
"6"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":4},\"d\":{\"a\":2,\"b\":4,\"c\":6}}"
127.0.0.1:6379> JSON.SET k3 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k3 .a.* 2
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMMULTBY k3 .b.* 2
"2"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":1,\"b\":\"b\",\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k3 .c.* 2
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMMULTBY k3 .d.* 2
"6"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":2,\"b\":\"b\",\"c\":6}}"
```
# JSON.OBJLEN
경로에 있는 객체 값의 키 수를 얻습니다.
구문
```
JSON.OBJLEN [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 객체 길이를 나타내는 정수 배열입니다.
+ 값이 객체가 아닌 경우 해당 반환 값은 null입니다.
+ 문서 키가 없으면 null입니다.
경로가 제한된 구문인 경우
+ 정수, 객체의 키 수입니다.
+ 여러 객체를 선택한 경우 명령은 첫 번째 객체의 길이를 반환합니다.
+ 경로의 값이 객체가 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ `NONEXISTENT JSON`경로가 존재하지 않는 경우 오류가 발생합니다.
+ 문서 키가 없으면 Null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJLEN k1 $.a
1) (integer) 0
127.0.0.1:6379> JSON.OBJLEN k1 $.a.*
(empty array)
127.0.0.1:6379> JSON.OBJLEN k1 $.b
1) (integer) 1
127.0.0.1:6379> JSON.OBJLEN k1 $.b.*
1) (nil)
127.0.0.1:6379> JSON.OBJLEN k1 $.c
1) (integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 $.c.*
1) (nil)
2) (nil)
127.0.0.1:6379> JSON.OBJLEN k1 $.d
1) (integer) 3
127.0.0.1:6379> JSON.OBJLEN k1 $.d.*
1) (nil)
2) (nil)
3) (integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 $.*
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 3
5) (nil)
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJLEN k1 .a
(integer) 0
127.0.0.1:6379> JSON.OBJLEN k1 .a.*
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.OBJLEN k1 .b
(integer) 1
127.0.0.1:6379> JSON.OBJLEN k1 .b.*
(error) WRONGTYPE JSON element is not an object
127.0.0.1:6379> JSON.OBJLEN k1 .c
(integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 .c.*
(error) WRONGTYPE JSON element is not an object
127.0.0.1:6379> JSON.OBJLEN k1 .d
(integer) 3
127.0.0.1:6379> JSON.OBJLEN k1 .d.*
(integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 .*
(integer) 0
```
# JSON.OBJKEYS
경로의 객체 값에 있는 키 이름을 얻습니다.
구문
```
JSON.OBJKEYS [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 대량 문자열 배열 각 요소는 일치하는 객체의 키 배열입니다.
+ 값이 객체가 아닌 경우 해당 반환 값은 빈 값입니다.
+ 문서 키가 없으면 null입니다.
경로가 제한된 구문인 경우
+ 대량 문자열 배열 각 요소는 객체의 키 이름입니다.
+ 여러 객체를 선택한 경우 명령은 첫 번째 객체의 키를 반환합니다.
+ 경로의 값이 객체가 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 문서 키가 없으면 Null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJKEYS k1 $.*
1) (empty array)
2) 1) "a"
3) 1) "a"
2) "b"
4) 1) "a"
2) "b"
3) "c"
5) (empty array)
127.0.0.1:6379> JSON.OBJKEYS k1 $.d
1) 1) "a"
2) "b"
3) "c"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJKEYS k1 .*
1) "a"
127.0.0.1:6379> JSON.OBJKEYS k1 .d
1) "a"
2) "b"
3) "c"
```
# JSON.RESP
Valkey 또는 Redis OSS(Redis Serialization Protocol)의 지정된 경로에 JSON 값을 반환합니다. 값이 컨테이너인 경우 응답은 RESP 배열 또는 중첩 배열입니다.
+ JSON null은 RESP Null 대량 문자열에 매핑됩니다.
+ JSON 부울 값은 각 RESP 단순 문자열에 매핑됩니다.
+ 정수는 RESP 정수에 매핑됩니다.
+ 64비트 IEEE 이중 부동 소수점 숫자는 RESP 대량 문자열에 매핑됩니다.
+ JSON 문자열은 RESP 대량 문자열에 매핑됩니다.
+ JSON 배열은 RESP 배열로 표현됩니다. 여기서 첫 번째 요소는 간단한 문자열 [이고 그 뒤에 배열의 요소가 옵니다.
+ JSON 객체는 RESP 배열로 표현됩니다. 여기서 첫 번째 요소는 간단한 문자열 \$1이고 그 뒤에 각각이 RESP 대량 문자열인 키-값 쌍이 옵니다.
구문
```
JSON.RESP [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 배열의 배열입니다. 각 배열 요소는 한 경로에 있는 값의 RESP 형식을 나타냅니다.
+ 문서 키가 없는 경우 빈 배열입니다.
경로가 제한된 구문인 경우
+ 경로에 있는 값의 RESP 형식을 나타내는 배열입니다.
+ 문서 키가 없으면 null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.RESP k1 $.address
1) 1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
127.0.0.1:6379> JSON.RESP k1 $.address.*
1) "21 2nd Street"
2) "New York"
3) "NY"
4) "10021-3100"
127.0.0.1:6379> JSON.RESP k1 $.phoneNumbers
1) 1) [
2) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "555 555-1234"
3) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
127.0.0.1:6379> JSON.RESP k1 $.phoneNumbers[*]
1) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "212 555-1234"
2) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.RESP k1 .address
1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
127.0.0.1:6379> JSON.RESP k1
1) {
2) 1) "firstName"
2) "John"
3) 1) "lastName"
2) "Smith"
4) 1) "age"
2) (integer) 27
5) 1) "weight"
2) "135.25"
6) 1) "isAlive"
2) true
7) 1) "address"
2) 1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
8) 1) "phoneNumbers"
2) 1) [
2) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "212 555-1234"
3) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
9) 1) "children"
2) 1) [
10) 1) "spouse"
2) (nil)
```
# JSON.SET
경로에 JSON 값을 설정합니다.
경로가 객체 멤버를 호출하는 경우
+ 상위 요소가 없는 경우 다음 명령은 NONEXISTENT 오류를 반환합니다.
+ 상위 요소가 있지만 객체가 아닌 경우 명령은 ERROR를 반환합니다.
+ 상위 요소가 있고 객체인 경우
+ 멤버가 없으면 상위 객체가 경로의 마지막 하위 객체인 경우에만 새 멤버는 상위 객체에 추가됩니다. 그렇지 않으면 명령은 NONEXISTENT 오류를 반환합니다.
+ 멤버가 있으면 해당 값이 JSON 값으로 대체됩니다.
경로가 배열 인덱스를 호출하는 경우
+ 상위 요소가 없는 경우 다음 명령은 NONEXISTENT 오류를 반환합니다.
+ 상위 요소가 있지만 배열이 아닌 경우 명령은 ERROR를 반환합니다.
+ 상위 요소가 있지만 인덱스가 범위를 벗어난 경우 명령은 OUTOFBOUNDARIES 오류를 반환합니다.
+ 상위 요소가 있고 인덱스가 유효하면 요소는 새 JSON 값으로 대체됩니다.
경로가 객체 또는 배열을 호출하는 경우 값(객체 또는 배열)은 새 JSON 값으로 대체됩니다.
구문
```
JSON.SET [NX | XX]
```
[NX \$1 XX] 여기에 [NX \$1 XX] 식별자 0개 또는 1개가 있을 수 있습니다..
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(필수) - JSON 경로입니다. 새 키의 경우 JSON 경로가 루트 '.' 여야 합니다.
+ NX(선택 사항) - 경로가 루트인 경우 키가 없는 경우에만 값을 설정합니다. 즉, 새 문서를 삽입합니다. 경로가 루트가 아니면 경로가 없는 경우에만 값을 설정합니다. 즉, 문서에 값을 삽입합니다.
+ XX(선택 사항) - 경로가 루트인 경우 키가 있는 경우에만 값을 설정합니다. 즉, 기존 문서를 교체합니다. 경로가 루트가 아니면 경로가 있는 경우에만 값을 설정합니다. 즉, 기존 값을 업데이트합니다.
**반환**
+ 성공 시 단순 문자열 '확인'.
+ NX 또는 XX 조건이 충족되지 않으면 null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.SET k1 $.a.* '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"a\":{\"a\":0,\"b\":0,\"c\":0}}"
127.0.0.1:6379> JSON.SET k2 . '{"a": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.SET k2 $.a[*] '0'
OK
127.0.0.1:6379> JSON.GET k2
"{\"a\":[0,0,0,0,0]}"
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"c":{"a":1, "b":2}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.SET k1 .c.a '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"c\":{\"a\":0,\"b\":2},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.SET k1 .e[-1] '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"c\":{\"a\":0,\"b\":2},\"e\":[1,2,3,4,0]}"
127.0.0.1:6379> JSON.SET k1 .e[5] '0'
(error) OUTOFBOUNDARIES Array index is out of bounds
```
# JSON.STRAPPEND
경로에서 JSON 문자열에 문자열을 추가합니다.
구문
```
JSON.STRAPPEND [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 루트로 설정됩니다.
+ json\$1string(필수) - 문자열의 JSON 표현입니다. JSON 문자열은 따옴표로 묶어야 합니다. 예: '"문자열 예"'.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 문자열의 새 길이를 나타내는 정수 배열입니다.
+ 경로의 값이 문자열이 아닌 경우 해당 반환 값은 null입니다.
+ `SYNTAXERR`입력 json 인수가 유효한 JSON 문자열이 아닌 경우 오류가 발생합니다.
+ `NONEXISTENT`경로가 없는 경우 오류가 발생합니다.
경로가 제한된 구문인 경우
+ 정수, 문자열의 새 길이입니다.
+ 여러 문자열 값을 선택한 경우 명령은 마지막으로 업데이트된 문자열의 새 길이를 반환합니다.
+ 경로의 값이 문자열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ 입력 json 인수가 유효한 JSON 문자열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ `NONEXISTENT`경로가 없는 경우 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRAPPEND k1 $.a.a '"a"'
1) (integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 $.a.* '"a"'
1) (integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 $.b.* '"a"'
1) (integer) 2
2) (nil)
127.0.0.1:6379> JSON.STRAPPEND k1 $.c.* '"a"'
1) (integer) 2
2) (integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 $.c.b '"a"'
1) (integer) 4
127.0.0.1:6379> JSON.STRAPPEND k1 $.d.* '"a"'
1) (nil)
2) (integer) 2
3) (nil)
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRAPPEND k1 .a.a '"a"'
(integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 .a.* '"a"'
(integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 .b.* '"a"'
(integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 .c.* '"a"'
(integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 .c.b '"a"'
(integer) 4
127.0.0.1:6379> JSON.STRAPPEND k1 .d.* '"a"'
(integer) 2
```
# JSON.STRLEN
경로에서 JSON 문자열 값의 길이를 얻습니다.
구문
```
JSON.STRLEN [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 문자열 값의 길이를 나타내는 정수 배열입니다.
+ 값이 문자열이 아닌 경우 해당 반환 값은 null입니다.
+ 문서 키가 없으면 null입니다.
경로가 제한된 구문인 경우
+ 정수, 문자열의 길이입니다.
+ 여러 문자열 값을 선택한 경우 명령은 첫 번째 문자열의 길이를 반환합니다.
+ 경로의 값이 문자열이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
+ `NONEXISTENT`경로가 존재하지 않는 경우 오류가 발생합니다.
+ 문서 키가 없으면 Null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRLEN k1 $.a.a
1) (integer) 1
127.0.0.1:6379> JSON.STRLEN k1 $.a.*
1) (integer) 1
127.0.0.1:6379> JSON.STRLEN k1 $.c.*
1) (integer) 1
2) (integer) 2
127.0.0.1:6379> JSON.STRLEN k1 $.c.b
1) (integer) 2
127.0.0.1:6379> JSON.STRLEN k1 $.d.*
1) (nil)
2) (integer) 1
3) (nil)
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRLEN k1 .a.a
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .a.*
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .c.*
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .c.b
(integer) 2
127.0.0.1:6379> JSON.STRLEN k1 .d.*
(integer) 1
```
# JSON.TOGGLE
경로에서 참과 거짓 사이의 부울 값을 토글합니다.
구문
```
JSON.TOGGLE [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 결과 부울 값을 나타내는 정수 배열(0 - 거짓, 1 - 참)입니다.
+ 값이 배열이 부울 값이 아닌 경우 해당 반환 값은 null입니다.
+ 문서 키가 없는 경우 `NONEXISTENT`입니다.
경로가 제한된 구문인 경우
+ 결과 부울 값을 나타내는 문자열('참'/ '거짓')입니다.
+ 문서 키가 없는 경우 `NONEXISTENT`입니다.
+ 경로의 값이 부울 값이 아닌 경우 `WRONGTYPE` 오류가 발생합니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"a":true, "b":false, "c":1, "d":null, "e":"foo", "f":[], "g":{}}'
OK
127.0.0.1:6379> JSON.TOGGLE k1 $.*
1) (integer) 0
2) (integer) 1
3) (nil)
4) (nil)
5) (nil)
6) (nil)
7) (nil)
127.0.0.1:6379> JSON.TOGGLE k1 $.*
1) (integer) 1
2) (integer) 0
3) (nil)
4) (nil)
5) (nil)
6) (nil)
7) (nil)
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . true
OK
127.0.0.1:6379> JSON.TOGGLE k1
"false"
127.0.0.1:6379> JSON.TOGGLE k1
"true"
127.0.0.1:6379> JSON.SET k2 . '{"isAvailable": false}'
OK
127.0.0.1:6379> JSON.TOGGLE k2 .isAvailable
"true"
127.0.0.1:6379> JSON.TOGGLE k2 .isAvailable
"false"
```
# JSON.TYPE
지정된 경로의 값 유형을 보고합니다.
구문
```
JSON.TYPE [path]
```
+ 키(필수) - JSON 문서 유형의 Valkey 또는 Redis OSS 키입니다.
+ 경로(선택 사항) - JSON 경로입니다. 제공하지 않으면 기본적으로 root로 설정됩니다.
**반환**
경로가 향상된 구문인 경우
+ 각 경로에서 값 유형을 나타내는 문자열 배열입니다. 유형은 \$1"null', '부울', '문자열', '숫자', '정수', '개체'및 '배열'\$1 중의 하나입니다.
+ 경로가 없는 경우 해당 값은 null입니다.
+ 문서 키가 없는 경우 빈 배열입니다.
경로가 제한된 구문인 경우
+ 문자열, 값 유형
+ 문서 키가 없으면 null입니다.
+ JSON 경로가 잘못되었거나 없는 경우 null입니다.
**예**
향상된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '[1, 2.3, "foo", true, null, {}, []]'
OK
127.0.0.1:6379> JSON.TYPE k1 $[*]
1) integer
2) number
3) string
4) boolean
5) null
6) object
7) array
```
제한된 경로 구문.
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.TYPE k1
object
127.0.0.1:6379> JSON.TYPE k1 .children
array
127.0.0.1:6379> JSON.TYPE k1 .firstName
string
127.0.0.1:6379> JSON.TYPE k1 .age
integer
127.0.0.1:6379> JSON.TYPE k1 .weight
number
127.0.0.1:6379> JSON.TYPE k1 .isAlive
boolean
127.0.0.1:6379> JSON.TYPE k1 .spouse
null
```
# ElastiCache 리소스에 태그 지정
클러스터 및 기타 ElastiCache 리소스 관리를 돕기 위해 태그 형식으로 각 리소스에 고유한 메타데이터를 할당할 수 있습니다. 태그를 사용하면 용도, 소유자 또는 환경 등 다양한 방식으로AWS리소스를 분류할 수 있습니다. 이 기능은 동일 유형의 리소스가 많을 때 유용합니다. 지정한 태그에 따라 특정 리소스를 빠르게 식별할 수 있습니다. 이 주제에서는 태그를 설명하고 태그를 생성하는 방법을 보여줍니다.
**주의**
민감한 데이터를 태그에 포함하지 않는 것이 가장 좋습니다.
## 태그 기본 사항
태그는AWS리소스에 할당하는 레이블입니다. 각 태그는 사용자가 정의하는 키와 선택적 값으로 구성됩니다. 태그를 사용하면 용도 또는 소유자별로AWS리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어, 계정의 ElastiCache 클러스터에 대해 각 인스턴스의 소유자와 사용자 그룹을 추적하는 데 도움이 되는 태그 세트를 정의할 수 있습니다.
각 리소스 유형에 대한 요건을 충족하는 태그 키 세트를 고안하는 것이 좋습니다. 일관된 태그 키 세트를 사용하면 리소스를 보다 쉽게 관리할 수 있습니다. 추가하는 태그에 따라 리소스를 검색하고 필터링할 수 있습니다. 효과적인 리소스 태그 지정 전략을 구현하는 방법에 대한 자세한 정보는 [AWS백서 태그 지정 모범 사례](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)를 참조하세요.
태그는 ElastiCache에는 의미가 없으며 엄격하게 문자열로 해석됩니다. 또한 태그는 리소스에 자동으로 배정되지 않습니다. 태그 키와 값을 편집할 수 있으며 언제든지 리소스에서 태그를 제거할 수 있습니다. 태그의 값을 `null`로 설정할 수 있습니다. 해당 리소스의 기존 태그와 동일한 키를 가진 태그를 추가하면 새 값이 이전 값을 덮어씁니다. 리소스를 삭제하면 리소스에 대한 모든 태그도 삭제됩니다. 또한 복제 그룹에서 태그를 추가하거나 삭제하면 해당 복제 그룹의 모든 노드에서 해당 태그가 추가되거나 제거됩니다.
AWS Management Console,AWS CLI및 ElastiCache API를 사용하여 태그로 작업할 수 있습니다.
IAM을 사용하는 경우AWS계정에서 태그를 생성, 편집 또는 삭제할 권한이 있는 사용자를 제어할 수 있습니다. 자세한 내용은 [리소스 수준 권한](IAM.ResourceLevelPermissions.md) 단원을 참조하십시오.
## 태그 지정이 가능한 리소스
계정에 이미 존재하는 대부분의 ElastiCache 리소스에 태그를 지정할 수 있습니다. 아래의 표에는 태그 지정을 지원하는 리소스가 나와 있습니다. 를 사용하는 경우 [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)를 사용하여 리소스에 태그를 적용할AWS Management Console수 있습니다. 일부 리소스 화면을 사용하면 리소스를 생성할 때 리소스에 대해 태그를 지정할 수 있습니다. 예를 들어 Name의 키가 있는 태그와 지정하는 값이 있습니다. 대부분의 경우, 콘솔은 리소스 생성 직후(리소스 생성 중이 아니라) 태그를 적용합니다. 콘솔은 **Name** 태그에 따라 리소스를 조직할 수 있지만 이 태그는 ElastiCache 서비스에 대한 의미가 없습니다.
또한 일부 리소스 생성 작업에서는 리소스 생성 시 리소스의 태그를 지정할 수 있습니다. 리소스 생성 도중 태그를 적용할 수 없는 경우, 리소스 생성 프로세스가 롤백됩니다. 이는 태그를 사용하여 리소스가 생성되거나 아예 리소스가 생성되지 않도록 하고 언제든 태그 지정되지 않은 리소스가 남지 않게 합니다. 생성 시 리소스에 태그를 지정하면 리소스 생성 후 사용자 지정 태그 지정 스크립트를 실행할 필요가 없습니다.
Amazon ElastiCache API,AWS CLI 또는AWS SDK를 사용하는 경우 관련 ElastiCache API 작업의 `Tags` 파라미터를 사용하여 태그를 적용할 수 있습니다. 스크립트는 다음과 같습니다.
+ `CreateServerlessCache`
+ `CreateCacheCluster`
+ `CreateReplicationGroup`
+ `CopyServerlessCacheSnapshot`
+ `CopySnapshot`
+ `CreateCacheParameterGroup`
+ `CreateCacheSecurityGroup`
+ `CreateCacheSubnetGroup`
+ `CreateServerlessCacheSnapshot`
+ `CreateSnapshot`
+ `CreateUserGroup`
+ `CreateUser`
+ `PurchaseReservedCacheNodesOffering`
다음 표에서는 태그를 지정할 수 있는 ElastiCache 리소스와 ElastiCache API,AWS CLI 또는AWS SDK를 사용하여 생성할 때 태그를 지정할 수 있는 리소스를 설명합니다.
**ElastiCache 리소스에 대한 태그 지정 지원**
| Resource | 태그 지원 | 생성 시 태그 지정 지원 |
| --- | --- | --- |
| serverlesscache | 예 | 예 |
| parametergroup | 예 | 예 |
| securitygroup | 예 | 예 |
| subnetgroup | 예 | 예 |
| replicationgroup | 예 | 예 |
| 클러스터 | 예 | 예 |
| reserved-instance | 예 | 예 |
| serverlesscachesnapshot | 예 | 예 |
| snapshot | 예 | 예 |
| user | 예 | 예 |
| usergroup | 예 | 예 |
**참고**
글로벌 데이터 스토어에는 태그를 지정할 수 없습니다.
생성 시 태그를 지원하는 ElastiCache API 작업에 IAM 정책의 태그 기반 리소스 수준 권한을 적용하여 생성 시 리소스에 태그를 지정할 수 있는 사용자와 그룹을 세밀하게 제어할 수 있습니다. 리소스를 생성하면 태그가 즉시 적용되기 때문에 생성 단계부터 리소스를 적절하게 보호할 수 있습니다. 따라서 태그를 기반으로 리소스 사용을 제어하는 리소스 수준 권한이 즉시 발효됩니다. 이에 따라 더욱 정확한 리소스 추적 및 보고가 가능합니다. 새 리소스에서 태그 지정 사용을 적용하고 리소스에서 어떤 태그 키와 값이 설정되는지 제어할 수 있습니다.
자세한 내용은 [리소스에 태그 지정 예제](#Tagging-your-resources-example) 단원을 참조하십시오.
결제를 위한 리소스 태그 지정에 대한 자세한 내용은 [비용 할당 태그를 사용하여 비용 모니터링](Tagging.md) 섹션을 참조하세요.
## 캐시 및 스냅샷에 태그 지정
태그 지정에는 요청 작업의 일부로 다음 규칙이 적용됩니다.
+ **CreateReplicationGroup**:
+ `--primary-cluster-id` 및 `--tags` 파라미터가 요청에 포함되어 있으면 요청 태그가 복제 그룹에 추가되고 복제 그룹의 모든 클러스터에 전파됩니다. 기본 클러스터에 기존 태그가 있는 경우 모든 노드에서 일관된 태그를 유지하기 위해 이러한 기존 태그를 요청 태그로 덮어씁니다.
요청 태그가 없는 경우 기본 클러스터 태그가 복제 그룹에 추가되고 모든 클러스터에 전파됩니다.
+ `--snapshot-name` 또는 `--serverless-cache-snapshot-name`이 제공된 경우:
태그가 요청에 포함되어 있으면 복제 그룹에는 해당 태그로만 태그가 지정됩니다. 요청에 태그가 포함되어 있지 않은 경우 복제 그룹에 스냅샷 태그가 추가됩니다.
+ `--global-replication-group-id`이 제공된 경우:
태그가 요청에 포함되어 있으면 요청 태그가 복제 그룹에 추가되고 모든 클러스터에 전파됩니다.
+ **CreateCacheCluster**:
+ `--replication-group-id`가 제공된 경우:
태그가 요청에 포함되어 있으면 클러스터에는 해당 태그로만 태그가 지정됩니다. 요청에 태그가 포함되어 있지 않은 경우 클러스터는 기본 클러스터의 태그 대신 복제 그룹 태그를 상속합니다.
+ `--snapshot-name`이 제공된 경우:
태그가 요청에 포함되어 있으면 클러스터에는 해당 태그로만 태그가 지정됩니다. 요청에 태그가 포함되어 있지 않은 경우 스냅샷 태그가 클러스터에 추가됩니다.
+ **CreateServerlessCache**:
+ 태그가 요청에 포함되어 있으면 요청 태그만 서버리스 캐시에 추가됩니다.
+ **CreateSnapshot**:
+ `--replication-group-id`가 제공된 경우:
태그가 요청에 포함되어 있으면 요청 태그만 스냅샷에 추가됩니다. 요청에 태그가 포함되어 있지 않은 경우 복제 그룹 태그가 스냅샷에 추가됩니다.
+ `--cache-cluster-id`가 제공된 경우:
태그가 요청에 포함되어 있으면 요청 태그만 스냅샷에 추가됩니다. 요청에 태그가 포함되어 있지 않은 경우 클러스터 태그가 스냅샷에 추가됩니다.
+ 자동 스냅샷의 경우:
태그가 복제 그룹 태그에서 전파됩니다.
+ **CreateServerlessCacheSnapshot**:
+ 태그가 요청에 포함되어 있으면 요청 태그만 서버리스 캐시 스냅샷에 추가됩니다.
+ **CopySnapshot**:
+ 태그가 요청에 포함되어 있으면 요청 태그만 스냅샷에 추가됩니다. 요청에 태그가 포함되어 있지 않은 경우 소스 스냅샷 태그가 복사된 스냅샷에 추가됩니다.
+ **CopyServerlessCacheSnapshot**:
+ 태그가 요청에 포함되어 있으면 요청 태그만 서버리스 캐시 스냅샷에 추가됩니다.
+ **AddTagsToResource** 및 **RemoveTagsFromResource**:
+ 태그는 복제 그룹에서 추가/제거되며 작업은 복제 그룹의 모든 클러스터에 전파됩니다.
**참고**
**AddTagsToResource** 및 **RemoveTagsFromResource**는 기본 파라미터 및 보안 그룹에 사용할 수 없습니다.
+ **IncreaseReplicaCount** 및 **ModifyReplicationGroupShardConfiguration**:
+ 복제 그룹에 추가된 모든 새 클러스터에는 복제 그룹과 동일한 태그가 적용됩니다.
## 태그 제한 사항
태그에 적용되는 기본 제한 사항은 다음과 같습니다.
+ 리소스당 최대 태그 수 – 50개
+ 각 리소스에 대해 각 태그 키는 고유해야 하며 각 태그 키는 하나의 값만 가질 수 있습니다.
+ 최대 키 길이는 유니코드 문자(UTF-8) 128자입니다.
+ 최대 값 길이는 유니코드 문자(UTF-8) 256자입니다.
+ ElastiCache는 태그에 모든 문자를 사용할 수 있지만, 다른 서비스에는 제한이 적용될 수 있습니다. 서비스에서 허용되는 문자는 UTF-8로 표현할 수 있는 문자, 숫자 및 공백과 특수 문자 \$1 - = . \$1 : / @입니다.
+ 태그 키와 값은 대/소문자를 구분합니다.
+ `aws:` 접두사는AWS사용을 위해 예약되어 있습니다. 태그에 이 접두사가 있는 태그 키가 있는 경우 태그의 키 또는 값을 편집하거나 삭제할 수 없습니다. `aws:` 접두사가 지정된 태그는 리소스당 태그 수 제한에 포함되지 않습니다.
태그에만 기초하여 리소스를 종료, 중지 또는 삭제할 수 없습니다. 리소스 식별자를 지정해야 합니다. 예를 들어 `DeleteMe`라는 태그 키로 태그를 지정한 스냅샷을 삭제하려면 해당 스냅샷의 리소스 식별자(예: `DeleteSnapshot`)를 지정하여 `snap-1234567890abcdef0` 작업을 사용해야 합니다.
태그를 지정할 수 있는 ElastiCache 리소스에 대한 자세한 내용은 [태그 지정이 가능한 리소스](#Tagging-your-resources) 섹션을 참조하세요.
## 리소스에 태그 지정 예제
+ 태그를 사용한 서버리스 캐시 생성. 이 예에서는 Memcached를 엔진으로 사용합니다.
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine memcached
--tags Key="Cost Center", Value="1110001" Key="project",Value="XYZ"
```
+ 서버리스 캐시에 태그 추가
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-east-1:111111222233:serverlesscache:my-cache \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ 복제 그룹에 태그 추가
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-east-1:111111222233:replicationgroup:my-rg \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ 태그를 사용하여 캐시 클러스터 생성
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ 태그를 사용하여 캐시 클러스터 생성 이 예에서는 Redis를 엔진으로 사용합니다.
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ 태그를 사용하여 서버리스 스냅샷 생성 이 예에서는 Memcached를 엔진으로 사용합니다.
```
aws elasticache create-serverless-cache-snapshot \
--serverless-cache-name testing-tags \
--serverless-cache-snapshot-name bkp-testing-tags-scs \
--tags Key="work",Value="foo"
```
+ 태그를 사용하여 스냅샷 생성
스냅샷은 현재 Redis에서만 사용할 수 있습니다. 이 경우 요청에 태그를 추가하면 복제 그룹에 태그가 포함되어 있더라도 스냅샷은 요청 태그만 받습니다.
```
aws elasticache create-snapshot \
--replication-group-id testing-tags \
--snapshot-name bkp-testing-tags-rg \
--tags Key="work",Value="foo"
```
## 태그 기반 액세스 제어 정책 예제
1. 클러스터에 Project=XYZ 태그가 있는 경우에만 클러스터에 대한 `AddTagsToResource` 작업을 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ"
}
}
}
]
}
```
------
1. 복제 그룹에 Project 및 Service 태그가 포함되어 있고 Project 및 Service의 키가 서로 다른 경우에만 복제 그룹에서 `RemoveTagsFromResource` 작업을 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:RemoveTagsFromResource",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Service": "Elasticache",
"aws:ResourceTag/Project": "XYZ"
},
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Project",
"Service"
]
}
}
}
]
}
```
------
1. Project 및 Service의 태그가 서로 다른 경우에만 모든 리소스에 대한 `AddTagsToResource` 작업을 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:*:*"
],
"Condition": {
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Service",
"Project"
]
}
}
}
]
}
```
------
1. 요청에 `Tag Project=Foo`가 있는 경우 `CreateReplicationGroup` 작업을 거부합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CreateReplicationGroup",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Foo"
}
}
}
]
}
```
------
1. 소스 스냅샷에 Project=XYZ 태그가 있고 요청 태그가 Service=ElastiCache인 경우 `CopySnapshot` 작업을 거부합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CopySnapshot",
"Resource": [
"arn:aws:elasticache:*:*:snapshot:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ",
"aws:RequestTag/Service": "Elasticache"
}
}
}
]
}
```
------
1. 요청 태그 `Project`가 누락되었거나 `Dev`, `QA` 또는 `Prod`와 같지 않은 경우 `CreateCacheCluster` 작업은 거부됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*",
"arn:aws:elasticache:*:*:securitygroup:*",
"arn:aws:elasticache:*:*:replicationgroup:*"
]
},
{
"Effect": "Deny",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"Null": {
"aws:RequestTag/Project": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:AddTagsToResource"
],
"Resource": "arn:aws:elasticache:*:*:cluster:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": [
"Dev",
"Prod",
"QA"
]
}
}
}
]
}
```
------
조건 키 관련 내용은 [조건 키 사용](IAM.ConditionKeys.md) 섹션을 참조하세요.
# 비용 할당 태그를 사용하여 비용 모니터링
Amazon ElastiCache에서 리소스에 비용 할당 태그를 추가하면 인보이스 비용을 리소스 태그 값으로 그룹화하여 비용을 추적할 수 있습니다.
ElastiCache 비용 할당 태그는 사용자가 정의하고 ElastiCache 리소스에 연결하는 키 값 페어입니다. 키와 값은 대/소문자를 구분합니다. 태그 키를 사용하여 범주를 정의할 수 있으며 태그 값은 해당 범주의 항목일 수 있습니다. 예를 들어, `CostCenter`의 태그 키와 `10010`의 태그 값을 정의하여 리소스가 10010 코스트 센터에 할당됨을 나타냅니다. `Environment`와 같은 키 및 `test` 또는 `production`과 같은 값을 사용하여 태그로 리소스를 테스트나 프로덕션에 사용되는 것으로 지정할 수도 있습니다. 리소스 관련 비용을 보다 쉽게 추적할 수 있도록 하기 위해 일관된 태그 키 세트를 사용하는 것이 좋습니다.
비용 할당 태그를 사용하여 자체 비용 구조를 반영하도록AWS청구서를 구성합니다. 이렇게 하려면 가입하여 태그 키 값이 포함된AWS계정 청구서를 가져옵니다. 그런 다음 같은 태그 키 값을 가진 리소스에 따라 결제 정보를 구성하여 리소스 비용의 합을 볼 수 있습니다. 예를 들어, 특정 애플리케이션 이름으로 여러 리소스에 태그를 지정한 다음 결제 정보를 구성하여 여러 서비스에 걸친 해당 애플리케이션의 총 비용을 볼 수 있습니다.
또한 태그를 결합하여 보다 세부적인 수준으로 비용을 추적할 수 있습니다. 예를 들어, 리전별 서비스 비용을 추적하려면 `Service` 및 `Region` 태그 키를 사용할 수 있습니다. 하나의 리소스에서 `ElastiCache` 및 `Asia Pacific (Singapore)` 값이 있을 수 있으며 다른 리소스에서 `ElastiCache` 및 `Europe (Frankfurt)` 값이 있을 수 있습니다. 리전별로 구분된 총 ElastiCache 비용을 볼 수 있습니다. 자세한 내용은 *AWS Billing사용 설명서*의 [비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)을 참조하세요.
ElastiCache 비용 할당 태그를 ElastiCache 노드 기반 클러스터에 추가할 수 있습니다. 태그를 추가, 나열, 수정, 복사 또는 제거할 때 이 작업은 지정된 클러스터에만 적용됩니다.
**ElastiCache 비용 할당 태그 특성**
+ 비용 할당 태그는 CLI 및 API 작업에서 ARN으로 지정된 ElastiCache 리소스에 적용됩니다. 리소스 유형은 "클러스터"입니다.
샘플 ARN: `arn:aws:elasticache::::`
샘플 arn: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
+ 태그 키는 태그의 필수 이름입니다. 키의 문자열 값은 1\$1128자(유니코드 문자) 사이가 될 수 있으며 `aws:`로 시작할 수 없습니다. 문자열에는 유니코드 문자, 숫자, 공백, 밑줄( \$1 ), 마침표( . ), 콜론( : ), 백슬래시( \$1 ), 등호( = ), 더하기 기호( \$1 ), 하이픈( - ), at 기호( @ ) 집합만 포함될 수 있습니다.
+ 태그 값은 태그의 선택적 값입니다. 값의 문자열 값은 1\$1256자(유니코드 문자) 사이가 될 수 있으며 `aws:`로 시작할 수 없습니다. 문자열에는 유니코드 문자, 숫자, 공백, 밑줄( \$1 ), 마침표( . ), 콜론( : ), 백슬래시( \$1 ), 등호( = ), 더하기 기호( \$1 ), 하이픈( - ), at 기호( @ ) 집합만 포함될 수 있습니다.
+ ElastiCache 리소스는 최대 50개의 태그를 보유할 수 있습니다.
+ 태그 세트의 값이 고유하지 않습니다. 예를 들어, 두 키 `Service`와 `Application`에 `ElastiCache` 값이 있는 태그 세트가 있을 수 있습니다.
AWS는 태그에 의미론적 의미를 적용하지 않습니다. 태그는 엄격히 문자열로 해석됩니다.AWS에서는 ElastiCache 리소스에 어떠한 태그도 자동으로 설정하지 않습니다.
# AWS CLI를 사용하여 비용 할당 태그 관리
AWS CLI를 사용하여 비용 할당 태그를 추가, 수정 또는 제거할 수 있습니다.
비용 할당 태그는 ElastiCache 클러스터에 적용됩니다. 태그를 지정할 클러스터는 Amazon 리소스 이름(ARN)을 사용해 지정합니다.
샘플 arn: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [AWS CLI를 사용하여 태그 나열](#Tagging.Managing.CLI.List)
+ [AWS CLI를 사용하여 태그 추가](#Tagging.Managing.CLI.Add)
+ [AWS CLI를 사용하여 태그 수정](#Tagging.Managing.CLI.Modify)
+ [AWS CLI를 사용하여 태그 제거](#Tagging.Managing.CLI.Remove)
## AWS CLI를 사용하여 태그 나열
[list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html) 작업을 사용하여 기존 ElastiCache 리소스에서 태그를 나열하는 데 AWS CLI를 사용할 수 있습니다.
다음 코드는 AWS CLI를 사용하여 us-west-2 리전에 있는 Memcached 클러스터 `my-cluster`의 태그를 나열합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Windows의 경우:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
다음 코드에서는 AWS CLI를 사용하여 us-west-2 리전에 있는 `my-cluster` 클러스터의 Valkey 또는 Redis OSS 노드 `my-cluster-001`에 태그를 나열합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Windows의 경우:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
이 작업의 출력은 다음 리소스의 모든 태그 목록과 유사합니다.
```
{
"TagList": [
{
"Value": "10110",
"Key": "CostCenter"
},
{
"Value": "EC2",
"Key": "Service"
}
]
}
```
리소스에 태그가 없으면 출력은 빈 TagList가 됩니다.
```
{
"TagList": []
}
```
자세한 내용은 ElastiCache [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html)에 대한 AWS CLI 섹션을 참조하세요.
## AWS CLI를 사용하여 태그 추가
[add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) CLI 작업을 사용하여 기존 ElastiCache 리소스에 태그를 추가하는 데 AWS CLI를 사용할 수 있습니다. 리소스에 태그 키가 없으면 키와 값이 리소스에 추가됩니다. 리소스에 이미 키가 있는 경우 해당 키와 연결된 값이 새 값으로 업데이트됩니다.
다음 코드는 AWS CLI를 사용하여 us-west-2 리전에 있는 클러스터 `my-cluster`의 노드 `my-cluster-001`에 각각 `elasticache` 및 `us-west-2` 값을 갖는 `Service` 및 `Region`키를 추가합니다.
**Memcached**
Linux, macOS, Unix의 경우:
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tags Key=Service,Value=elasticache \
Key=Region,Value=us-west-2
```
Windows의 경우:
```
aws elasticache add-tags-to-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tags Key=Service,Value=elasticache ^
Key=Region,Value=us-west-2
```
** Redis**
Linux, macOS, Unix의 경우:
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tags Key=Service,Value=elasticache \
Key=Region,Value=us-west-2
```
Windows의 경우:
```
aws elasticache add-tags-to-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tags Key=Service,Value=elasticache ^
Key=Region,Value=us-west-2
```
이 작업의 출력은 다음 작업 후 리소스의 모든 태그 목록과 유사합니다.
```
{
"TagList": [
{
"Value": "elasticache",
"Key": "Service"
},
{
"Value": "us-west-2",
"Key": "Region"
}
]
}
```
자세한 내용은 ElastiCache [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html)에 대한 AWS CLI 섹션을 참조하세요.
AWS CLI을 통해 [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html) 작업을 사용하여 새 클러스터를 생성할 때 클러스터에 태그를 추가할 수도 있습니다. ElastiCache 관리 콘솔을 사용하는 경우 클러스터를 생성할 때 태그를 추가할 수 없습니다. 클러스터가 생성된 후에는 콘솔을 사용하여 클러스터에 태그를 추가할 수 있습니다.
## AWS CLI를 사용하여 태그 수정
AWS CLI를 사용하여 ElastiCache 클러스터의 태그를 수정할 수 있습니다.
태그를 수정하려면
+ [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html)를 사용하여 새 태그 및 값을 추가하거나 기존 태그에 연결된 값을 변경합니다.
+ [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)를 사용하여 리소스에서 지정된 태그를 제거합니다.
두 작업 중 하나의 출력은 지정된 클러스터의 태그와 이 태그의 값이 나열된 목록입니다.
## AWS CLI를 사용하여 태그 제거
[remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html) 작업을 사용하여 기존 ElastiCache for Memcached 클러스터에서 태그를 제거하는 데 AWS CLI를 사용할 수 있습니다.
Memcached의 경우 다음 코드에서는 AWS CLI를 사용하여 us-west-2 리전에 있는 클러스터 `my-cluster`의 노드 `my-cluster-001`에서 `Service` 및 `Region` 키를 갖는 태그를 제거합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tag-keys PM Service
```
Windows의 경우:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tag-keys PM Service
```
Redis OSS의 경우 다음 코드에서는 AWS CLI를 사용하여 us-west-2 리전에 있는 클러스터 `my-cluster`의 노드 `my-cluster-001`에서 `Service` 및 `Region` 키를 갖는 태그를 제거합니다.
Linux, macOS, Unix의 경우:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tag-keys PM Service
```
Windows의 경우:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tag-keys PM Service
```
이 작업의 출력은 다음 작업 후 리소스의 모든 태그 목록과 유사합니다.
```
{
"TagList": []
}
```
자세한 내용은 ElastiCache [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)에 대한 AWS CLI 섹션을 참조하세요.
# ElastiCache API를 사용하여 비용 할당 태그 관리
ElastiCache API를 사용하여 비용 할당 태그를 추가, 수정 또는 제거할 수 있습니다.
비용 할당 태그는 ElastiCache for Memcached 클러스터에 적용됩니다. 태그를 지정할 클러스터는 Amazon 리소스 이름(ARN)을 사용해 지정합니다.
샘플 arn: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [ElastiCache API를 사용하여 태그 나열](#Tagging.Managing.API.List)
+ [ElastiCache API를 사용하여 태그 추가](#Tagging.Managing.API.Add)
+ [ElastiCache API를 사용하여 태그 수정](#Tagging.Managing.API.Modify)
+ [ElastiCache API를 사용하여 태그 제거](#Tagging.Managing.API.Remove)
## ElastiCache API를 사용하여 태그 나열
[ListTagsForResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListTagsForResource.html) 작업을 사용하여 기존 리소스에서 태그를 나열하는 데 ElastiCache API를 사용할 수 있습니다.
Memcached의 경우, 다음 코드는 ElastiCache API를 사용하여 us-west-2 리전에 있는 리소스 `my-cluster`의 태그를 나열합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Redis OSS의 경우, 다음 코드는 ElastiCache API를 사용하여 us-west-2 리전에 있는 리소스 `my-cluster-001`의 태그를 나열합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
## ElastiCache API를 사용하여 태그 추가
[AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) 작업을 사용하여 기존 ElastiCache 클러스터에 태그를 추가하는 데 ElastiCache API를 사용할 수 있습니다. 리소스에 태그 키가 없으면 키와 값이 리소스에 추가됩니다. 리소스에 이미 키가 있는 경우 해당 키와 연결된 값이 새 값으로 업데이트됩니다.
다음 코드는 ElastiCache API를 사용하여 각각 `elasticache` 및 `us-west-2` 값과 함께 `Service` 및 `Region` 키를 추가합니다. Memcached의 경우, 이는 리소스 `my-cluster`에 적용됩니다. Redis OSS의 경우 us-west-2 리전의 리소스 `my-cluster-001`에 적용됩니다.
**Memcached**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
** Redis**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
자세한 내용은 *Amazon ElastiCache API 참조*에서 [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) 섹션을 참조하세요.
## ElastiCache API를 사용하여 태그 수정
ElastiCache API를 사용하여 ElastiCache 클러스터의 태그를 수정할 수 있습니다.
태그 값을 수정하려면
+ [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) 작업을 사용하여 새 태그와 값을 추가하거나 기존 태그의 값을 변경합니다.
+ [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html)를 사용하여 리소스에서 태그를 제거합니다.
두 작업 중 하나의 출력은 지정된 리소스의 태그 목록과 값입니다.
[RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html)를 사용하여 리소스에서 태그를 제거합니다.
## ElastiCache API를 사용하여 태그 제거
[RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) 작업을 사용하여 기존 ElastiCache for Memcached 클러스터에서 태그를 제거하는 데 ElastiCache API를 사용할 수 있습니다.
다음 코드에서는 ElastiCache API를 사용하여 us-west-2 리전에 있는 클러스터 `my-cluster`의 `my-cluster-001` 노드에서 `Service` 및 `Region` 키를 갖는 태그를 제거합니다.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=RemoveTagsFromResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&TagKeys.member.1=Service
&TagKeys.member.2=Region
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
# 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/)
# ElastiCache를 사용한 일반적인 문제 해결 단계 및 모범 사례
다음 주제에서는 ElastiCache를 사용할 때 발생할 수 있는 오류 및 문제에 대한 문제 해결 조언을 제공합니다. 여기에 나열되지 않은 문제를 발견하는 경우 이 페이지의 피드백 버튼을 사용하여 해당 문제를 보고할 수 있습니다.
문제 해결 조언과 일반적인 지원 질문에 대한 답변은 [AWS지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/)를 참조하세요.
**Topics**
+ [연결 문제](#wwe-troubleshooting.connection)
+ [Valkey 또는 Redis OSS 클라이언트 오류](#wwe-troubleshooting.clienterrors)
+ [ElastiCache 서버리스의 지연 시간 문제 해결](#wwe-troubleshooting.latency)
+ [ElastiCache 서버리스의 스로틀링 문제 해결](#wwe-troubleshooting.throttling)
+ [지속적인 연결 문제](TroubleshootingConnections.md)
+ [관련 항목](#wwe-troubleshooting.related)
## 연결 문제
ElastiCache 캐시에 연결할 수 없는 경우 다음 중 하나를 고려하세요.
1. **TLS 사용: **ElastiCache 엔드포인트에 연결하려고 할 때 연결이 끊긴 경우 클라이언트에서 TLS를 사용하지 않을 수 있습니다. ElastiCache 서버리스를 사용하는 경우 전송 중 암호화가 항상 활성화됩니다. 클라이언트가 TLS를 사용하여 캐시에 연결하는지 확인합니다. [TLS 지원 캐시에 연결하는 방법에 대해 자세히 알아보세요](connect-tls.md).
1. **VPC:** ElastiCache 캐시는 VPC 내에서만 액세스할 수 있습니다. 캐시에 액세스하는 EC2 인스턴스와 ElastiCache 캐시가 동일한 VPC에 생성되었는지 확인합니다. 또는 EC2 인스턴스가 있는 VPC와 캐시를 생성하는 VPC 간에 [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)을 활성화해야 합니다.
1. **보안 그룹: **ElastiCache는 보안 그룹을 사용하여 캐시에 대한 액세스를 제어합니다. 다음을 고려하세요.
1. ElastiCache 캐시에서 사용하는 보안 그룹이 EC2 인스턴스에서 인바운드 액세스를 허용하는지 확인합니다. 보안 그룹에서 인바운드 규칙을 올바르게 설정하는 방법은 [여기](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)를 참조하세요.
1. ElastiCache 캐시에서 사용하는 보안 그룹이 캐시 포트에 대한 액세스를 허용하는지 확인합니다(서버리스의 경우 6379 및 6380, 노드 기반인 경우 기본적으로 6379). ElastiCache는 이러한 포트를 사용하여 Valkey 또는 Redis OSS 명령을 수락합니다. 포트 액세스를 설정하는 방법에 대한 자세한 내용은 [여기](set-up.md#elasticache-install-grant-access-VPN)에서 확인하세요.
연결이 계속 어려운 경우 다른 단계는 [지속적인 연결 문제](TroubleshootingConnections.md) 섹션을 참조하세요.
## Valkey 또는 Redis OSS 클라이언트 오류
ElastiCache 서버리스는 Valkey 또는 Redis OSS 클러스터 모드 프로토콜을 지원하는 클라이언트를 통해서만 액세스할 수 있습니다. 노드 기반 클러스터는 클러스터 구성에 따라 어느 모드에서든 클라이언트에서 액세스할 수 있습니다.
클라이언트에 오류가 발생하는 경우 다음을 고려하세요.
1. **클러스터 모드: **[SELECT](https://valkey.io/commands/select/) 명령에서 CROSSLOT 오류 또는 오류가 발생하는 경우 클러스터 프로토콜을 지원하지 않는 Valkey 또는 Redis OSS 클라이언트를 사용하여 클러스터 모드 활성화 캐시에 액세스하려고 할 수 있습니다. ElastiCache 서버리스는 Valkey 또는 Redis OSS 클러스터 프로토콜을 지원하는 클라이언트만 지원합니다. ‘클러스터 모드 비활성화’(CMD)에서 Valkey 또는 Redis OSS를 사용하려면 노드 기반 클러스터를 설계해야 합니다.
1. **CROSSLOT 오류: **`ERR CROSSLOT Keys in request don't hash to the same slot` 오류가 발생하는 경우 클러스터 모드 캐시의 동일한 슬롯에 속하지 않는 키에 액세스하려고 할 수 있습니다. ElastiCache 서버리스는 항상 클러스터 모드에서 작동합니다. 여러 키를 포함하는 다중 키 작업, 트랜잭션 또는 Lua 스크립트는 관련된 모든 키가 동일한 해시 슬롯에 있는 경우에만 허용됩니다.
Valkey 또는 Redis OSS 클라이언트 구성에 대한 추가 모범 사례는 이 [블로그 게시물](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)을 참조하세요.
## ElastiCache 서버리스의 지연 시간 문제 해결
워크로드의 지연 시간이 길면 CloudWatch `SuccessfulReadRequestLatency` 및 `SuccessfulWriteRequestLatency` 지표를 분석하여 지연 시간이 ElastiCache 서버리스와 관련이 있는지 확인할 수 있습니다. 이러한 지표는 ElastiCache 서버리스의 내부인 지연 시간을 측정합니다. 클라이언트 측 지연 시간과 클라이언트와 ElastiCache 서버리스 엔드포인트 간의 네트워크 트립 시간은 포함되지 않습니다.
**클라이언트 측 지연 시간 문제 해결**
클라이언트 측 지연 시간은 증가했지만 서버 측 지연 시간을 측정하는 ``CloudWatch `SuccessfulReadRequestLatency` 및 `SuccessfulWriteRequestLatency` 지표에는 그에 상응하는 증가가 없는 경우 다음을 고려하세요.
+ **보안 그룹이 포트 6379 및 6380에 대한 액세스를 허용하는지 확인합니다.** ElastiCache 서버리스는 기본 엔드포인트에 6379 포트를 사용하고 리더 엔드포인트에 6380 포트를 사용합니다. 일부 클라이언트는 애플리케이션이 복제본에서 읽기 기능을 사용하지 않더라도 모든 새 연결에 대해 두 포트에 대한 연결을 설정합니다. 보안 그룹에서 두 포트에 대한 인바운드 액세스를 허용하지 않으면 연결 설정이 더 오래 걸릴 수 있습니다. 포트 액세스를 설정하는 방법에 대한 자세한 내용은 [여기](set-up.md#elasticache-install-grant-access-VPN)에서 확인하세요.
**서버 측 지연 시간 문제 해결**
일부 변동성 및 간헐적 급증은 걱정할 필요가 없습니다. 그러나 `Average` 통계에서 급격한 증가가 나타나고 지속되면Health Dashboard및 Personal Health Dashboard에서 자세한 내용을 확인해야 합니다. 필요한 경우를 사용하여 지원 사례를 여는 것이 좋습니다지원.
지연 시간을 줄이기 위해 다음 모범 사례와 전략을 고려하세요.
+ **복제본에서 읽기 활성화: **애플리케이션에서 허용하는 경우 Valkey 또는 Redis OSS 클라이언트에서 “복제본에서 읽기” 기능을 활성화하여 읽기를 확장하고 지연 시간을 줄이는 것이 좋습니다. 활성화되면 ElastiCache 서버리스는 클라이언트와 동일한 가용 영역(AZ)에 있는 복제본 캐시 노드로 읽기 요청을 라우팅하려고 시도하므로 AZ 간 네트워크 지연 시간을 방지합니다. 클라이언트의 복제본에서 읽기 기능을 활성화하면 애플리케이션이 데이터의 최종 일관성을 수락한다는 의미입니다. 키에 쓴 후 읽기를 시도하는 경우 애플리케이션이 일정 시간 동안 이전 데이터를 수신할 수 있습니다.
+ **애플리케이션이 캐시와 동일한 AZ에 배포되었는지 확인합니다. **애플리케이션이 캐시와 동일한 AZ에 배포되지 않은 경우 클라이언트 측 지연 시간이 더 길어질 수 있습니다. 서버리스 캐시를 생성할 때 애플리케이션이 캐시에 액세스할 서브넷을 제공할 수 있으며 ElastiCache 서버리스는 해당 서브넷에 VPC 엔드포인트를 생성합니다. 애플리케이션이 동일한 AZ에 배포되어 있는지 확인합니다. 그렇지 않으면 애플리케이션이 캐시에 액세스할 때 AZ 사이에 홉이 발생하여 클라이언트 측 지연 시간이 길어질 수 있습니다.
+ **연결 재사용: **ElastiCache 서버리스 요청은 RESP 프로토콜을 사용하여 TLS 지원 TCP 연결을 통해 이루어집니다. 연결(구성된 경우 연결 인증 포함)을 시작하는 데 시간이 걸리므로 첫 번째 요청의 지연 시간이 일반적인 요청보다 깁니다. 이미 초기화된 연결을 통한 요청은 ElastiCache의 일관되고 짧은 지연 시간을 제공합니다. 따라서 연결 풀링을 사용하거나 기존 Valkey 또는 Redis OSS 연결을 재사용하는 것이 좋습니다.
+ **확장 속도: **ElastiCache 서버리스는 요청 속도가 증가함에 따라 자동으로 확장됩니다. ElastiCache 서버리스가 확장하는 속도보다 빠른 요청 속도가 갑자기 크게 증가하면 일정 시간 동안 지연 시간이 늘어날 수 있습니다. ElastiCache 서버리스는 일반적으로 지원되는 요청 속도를 빠르게 높일 수 있으며, 요청 속도를 두 배로 높이는 데 최대 10\$112분이 걸립니다.
+ **장기 실행 명령 검사: **Lua 스크립트 또는 대규모 데이터 구조의 명령을 포함한 일부 Valkey 또는 Redis OSS 명령이 장시간 실행될 수 있습니다. 이러한 명령을 식별하기 위해 ElastiCache는 명령 수준 지표를 게시합니다. [ElastiCache 서버리스](serverless-metrics-events-redis.md#serverless-metrics)를 사용하면 `BasedECPUs` 지표를 사용할 수 있습니다.
+ **제한된 요청: ** ElastiCache 서버리스에서 요청이 제한되면 애플리케이션에서 클라이언트 측 지연 시간이 증가할 수 있습니다. ElastiCache 서버리스에서 요청이 제한되면 `ThrottledRequests` [ElastiCache 서버리스](serverless-metrics-events-redis.md#serverless-metrics) 지표가 증가하는 것을 볼 수 있습니다. 제한된 요청 문제를 해결하려면 아래 섹션을 검토하세요.
+ **키 및 요청의 균일한 배포: **ElastiCache for Valkey 및 Redis OSS에서 슬롯당 키 또는 요청이 고르지 않게 배포되면 핫 슬롯이 발생하여 지연 시간이 늘어날 수 있습니다. ElastiCache 서버리스는 간단한 SET/GET 명령을 실행하는 워크로드에서 단일 슬롯에서 초당 최대 30,000ECPUs(복제본에서 읽기 사용 시 초당 90,000개의 ECPU)를 지원합니다. 슬롯 간 키 및 요청 배포를 평가하고 요청 속도가 이 제한을 초과하는 경우 균일한 배포를 확인하는 것이 좋습니다.
## ElastiCache 서버리스의 스로틀링 문제 해결
서비스 지향 아키텍처 및 분산 시스템에서는 다양한 서비스 구성 요소가 API 호출을 처리하는 속도를 제한하는 것을 제한이라고 합니다. 이를 통해 급증을 완화하고 구성 요소 처리량 불일치를 제어하며 예상치 못한 운영 이벤트가 발생했을 때 보다 예측 가능한 복구를 수행할 수 있습니다. ElastiCache 서버리스는 이러한 유형의 아키텍처를 위해 설계되었으며 대부분의 Valkey 또는 Redis OSS 클라이언트에는 제한된 요청에 대한 재시도가 내장되어 있습니다. 어느 정도의 제한이 애플리케이션에 반드시 문제가 되는 것은 아니지만 데이터 워크플로의 지연 시간에 민감한 부분을 지속적으로 제한하면 사용자 경험에 부정적인 영향을 미치고 시스템의 전반적인 효율성이 떨어질 수 있습니다.
ElastiCache 서버리스에서 요청이 제한되면 `ThrottledRequests` [ElastiCache 서버리스](serverless-metrics-events-redis.md#serverless-metrics) 지표가 증가하는 것을 볼 수 있습니다. 제한된 요청 수가 많을 경우 다음을 고려하세요.
+ **규모 조정 속도: **ElastiCache 서버리스는 더 많은 데이터를 수집하거나 요청 속도를 높일 때 자동으로 규모가 조정됩니다. ElastiCache 서버리스가 규모를 조정하는 속도보다 애플리케이션이 빠르게 크기 조정되는 경우 ElastiCache 서버리스가 워크로드에 맞게 규모를 조정하는 동안 요청이 제한될 수 있습니다. ElastiCache 서버리스는 일반적으로 스토리지 크기를 빠르게 늘릴 수 있으며 캐시의 스토리지 크기를 두 배로 늘리는 데 최대 10\$112분이 걸릴 수 있습니다.
+ **키 및 요청의 균일한 배포: **ElastiCache for Valkey 및 Redis OSS에서 슬롯당 키 또는 요청이 고르지 않게 배포되면 핫 슬롯이 발생할 수 있습니다. 핫 슬롯은 간단한 SET/GET 명령을 실행하는 워크로드에서 단일 슬롯에 대한 요청 속도가 초당 30,000ECPU를 초과하는 경우 요청을 스로틀링할 수 있습니다. 마찬가지로 ElastiCache for Memcached를 사용하면 요청 속도가 초당 30,000 ECPU는 경우 핫 키를 스로틀링할 수 있습니다.
+ **복제본에서 읽기: **애플리케이션에서 허용하는 경우 “복제본에서 읽기” 기능을 사용하는 것이 좋습니다. 대부분의 Valkey 또는 Redis OSS 클라이언트는 “읽기 규모 조정”을 통해 읽기를 복제본 노드로 직접 전송하도록 구성할 수 있습니다. 이 기능을 사용하면 읽기 트래픽을 조정할 수 있습니다. 또한 ElastiCache 서버리스는 복제본 요청의 읽기를 애플리케이션과 동일한 가용 영역의 노드로 자동으로 라우팅하여 지연 시간을 줄입니다. 복제본에서 읽기가 활성화되면 간단한 SET/GET 명령을 사용하여 워크로드에 대해 단일 슬롯에서 초당 최대 90,000ECPU를 달성할 수 있습니다.
# 지속적인 연결 문제
ElastiCache와의 지속적인 연결 문제를 해결하려면 다음 항목을 확인해야 합니다.
**Topics**
+ [보안 그룹](#Security_groups)
+ [네트워크 ACL](#Network_ACLs)
+ [라우팅 테이블](#Route_tables)
+ [DNS 확인](#DNS_Resolution)
+ [서버 측 진단을 사용하여 문제 식별](#Diagnostics)
+ [네트워크 연결 검증](#Connectivity)
+ [네트워크 관련 제한 사항](#Network-limits)
+ [CPU 사용량](#CPU-Usage)
+ [서버 측에서 연결이 종료되는 경우](#Connections-server)
+ [Amazon EC2 인스턴스에 대한 클라이언트 측 문제 해결](#Connections-client)
+ [단일 요청을 완료하는 데 걸리는 시간 분석](#Dissecting-time)
## 보안 그룹
보안 그룹은 ElastiCache 클라이언트(EC2 인스턴스, AWS Lambda 함수, Amazon ECS 컨테이너 등) 및 ElastiCache 캐시를 보호하는 가상 방화벽입니다. 보안 그룹은 상태 유지(stateful) 방식으로 작동합니다. 즉, 들어오거나 나가는 트래픽이 허용되면 해당 트래픽에 대한 응답이 관련 보안 그룹의 컨텍스트에서 자동으로 승인됩니다.
상태 유지 기능을 사용하려면 보안 그룹이 권한이 부여된 모든 연결을 추적해야 하며, 이렇게 추적되는 연결에는 제한이 있습니다. 이 제한에 도달하면 새 연결이 실패합니다. 클라이언트 또는 ElastiCache 측에서 이 제한에 도달했는지 여부를 확인하는 방법에 대한 도움말은 문제 해결 섹션을 참조하세요.
클라이언트 및 ElastiCache 클러스터에 단일 보안 그룹을 동시에 할당하거나 각각에 대해 개별 보안 그룹을 할당할 수 있습니다.
두 경우 모두 소스에서 ElastiCache 포트에 대한 TCP 아웃바운드 트래픽과 동일한 포트의 ElastiCache에 대한 인바운드 트래픽을 허용해야 합니다. 기본 포트는 Memcached의 경우 11211, Valkey 또는 Redis OSS의 경우 6379입니다. 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다. 이 경우 대상 보안 그룹의 인바운드 규칙만 필요합니다.
자세한 내용은 [Amazon VPC에 있는 ElastiCache 클러스터에 액세스하기 위한 액세스 패턴](elasticache-vpc-accessing.md) 섹션을 참조하세요.
## 네트워크 ACL
네트워크 액세스 제어 목록(ACL)은 무상태 규칙입니다. 트래픽이 성공하려면 양방향(인바운드 및 아웃바운드)으로 허용되어야 합니다. 네트워크 ACL은 특정 리소스가 아닌 서브넷에 할당됩니다. ElastiCache 및 클라이언트 리소스에 동일한 ACL을 할당할 수 있습니다(특히 동일한 서브넷에 있는 경우).
기본적으로 네트워크 ACL은 모든 트래픽을 허용합니다. 그러나 트래픽을 거부하거나 허용하도록 네트워크 ACL을 사용자 지정할 수 있습니다. 또한 ACL 규칙의 평가는 순차적입니다. 즉, 트래픽과 일치하는 가장 빠른 번호의 규칙이 트래픽을 허용하거나 거부합니다. Valkey 또는 Redis OSS 트래픽을 허용하는 최소 구성은 다음과 같습니다.
클라이언트 측 네트워크 ACL:
+ **인바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 1024-65535
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)
+ 허용/거부: 허용
+ **아웃바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 6379
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 IP를 사용하면 장애 조치 또는 클러스터 조정 시 문제가 발생할 수 있다는 것에 유념하세요.)
+ 허용/거부: 허용
ElastiCache 네트워크 ACL:
+ **인바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 6379
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)
+ 허용/거부: 허용
+ **아웃바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 1024-65535
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 IP를 사용하면 장애 조치 또는 클러스터 조정 시 문제가 발생할 수 있다는 것에 유념하세요.)
+ 허용/거부: 허용
자세한 내용은 [네트워크 ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)을 참조하세요.
## 라우팅 테이블
네트워크 ACL과 마찬가지로 각 서브넷에는 서로 다른 라우팅 테이블이 있을 수 있습니다. 클라이언트와 ElastiCache 클러스터가 서로 다른 서브넷에 있는 경우 각각의 라우팅 테이블에서 서로 연결할 수 있도록 허용해야 합니다.
여러 VPC, 동적 라우팅 또는 네트워크 방화벽이 관련된 복잡한 환경에서는 문제 해결이 어려울 수 있습니다. [네트워크 연결 검증](#Connectivity) 섹션을 참조하여 네트워크 설정이 적절한지 확인하세요.
## DNS 확인
ElastiCache는 DNS 이름에 기반한 서비스 엔드포인트를 제공합니다. 사용 가능한 엔드포인트는 `Configuration`, `Primary`, `Reader` 및 `Node` 엔드포인트입니다. 자세한 내용은 [연결 엔드포인트 찾기](Endpoints.md)를 참조하세요.
장애 조치 또는 클러스터 수정의 경우 엔드포인트 이름에 연결된 주소가 변경될 수 있으며 자동으로 업데이트됩니다.
사용자 지정 DNS 설정(예: VPC DNS 서비스를 사용하지 않음)은 ElastiCache에서 제공한 DNS 이름을 인식하지 못할 수 있습니다. `dig`(다음에 표시되어 있음) 또는 `nslookup` 같은 시스템 도구를 사용하여 시스템이 ElastiCache 엔드포인트를 성공적으로 확인할 수 있는지 확인합니다.
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4
```
VPC DNS 서비스를 통해 이름 확인을 강제할 수도 있습니다.
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4
```
## 서버 측 진단을 사용하여 문제 식별
ElastiCache 엔진의 CloudWatch 지표 및 런타임 정보는 연결 문제의 잠재적인 원인을 파악하기 위한 일반적인 소스 또는 정보입니다. 좋은 분석은 일반적으로 다음과 같은 항목으로 시작됩니다.
+ CPU 사용량: Valkey 및 Redis OSS는 다중 스레드 애플리케이션입니다. 그러나 각 명령의 실행은 단일(주) 스레드에서 발생합니다. 이러한 이유로 ElastiCache는 `CPUUtilization` 및 `EngineCPUUtilization` 지표를 제공합니다. `EngineCPUUtilization`은 Valkey 또는 Redis OSS 프로세스 전용 CPU 사용률을 제공하고 `CPUUtilization`은 모든 vCPU에 대한 사용량을 제공합니다. 두 개 이상의 vCPU가 있는 노드는 대개 `CPUUtilization` 및 `EngineCPUUtilization`의 값이 서로 다르며, 일반적으로 두 번째 값이 더 큽니다. 높은 `EngineCPUUtilization` 값은 많은 수의 요청이나 완료하는 데 상당한 양의 CPU 시간이 필요한 복잡한 작업으로 인해 발생할 수 있습니다. 다음을 사용하여 둘 모두를 식별할 수 있습니다.
+ 많은 수의 요청: `EngineCPUUtilization` 패턴과 일치하는 다른 지표의 증가 여부를 확인합니다. 유용한 지표는 다음과 같습니다.
+ `CacheHits` 및 `CacheMisses`: 성공한 요청 또는 캐시에서 유효한 항목을 찾지 못한 요청의 수입니다. 적중률에 비해 누락률이 높으면 애플리케이션에서 무의미한 요청에 시간과 리소스를 낭비하고 있는 것입니다.
+ `SetTypeCmds` 및 `GetTypeCmds`: `EngineCPUUtilization`과 상관 관계가 있는 이 두 지표는 `SetTypeCmds`에 의해 측정되는 쓰기 요청 또는 `GetTypeCmds`에 의해 측정되는 읽기 요청에 대한 로드가 얼마나 높은지 파악하는 데 도움이 될 수 있습니다 로드가 주로 읽기인 경우 여러 읽기 전용 복제본을 사용하면 여러 노드에 요청을 분산시켜 균형을 유지하고 프라이머리 노드를 쓰기용으로 할당할 수 있습니다. 클러스터 모드가 비활성화된 클러스터에서는 ElastiCache 리더 엔드포인트를 사용하여 애플리케이션에 추가적인 연결 구성을 생성하여 읽기 전용 복제본을 사용할 수 있습니다. 자세한 내용은 [연결 엔드포인트 찾기](Endpoints.md)를 참조하세요. 읽기 작업은 이 추가 연결에 제출되어야 합니다. 쓰기 작업은 일반적인 기본 엔드포인트를 통해 수행됩니다. 클러스터 모드가 활성화된 클러스터에서는 기본적으로 읽기 전용 복제본을 지원하는 라이브러리를 사용하는 것이 좋습니다. 올바른 플래그를 사용하면 라이브러리가 클러스터 토폴로지와 복제본 노드를 자동으로 검색하고, [READONLY](https://valkey.io/commands/readonly) Valkey 또는 Redis OSS 명령을 통해 읽기 작업을 활성화하고, 복제본에 읽기 요청을 제출할 수 있습니다.
+ 많은 수의 연결:
+ `CurrConnections` 및 `NewConnections`: `CurrConnection`은 데이터 포인트 컬렉션 순간에 설정된 연결 수이고, `NewConnections`는 이 기간에 생성된 연결 수를 보여줍니다.
연결 생성 및 처리에서는 상당한 CPU 오버헤드가 발생합니다. 또한 새 연결을 생성하는 데 필요한 TCP 3방향 핸드셰이크는 전체 응답 시간에 부정적인 영향을 미칩니다.
분당 수천 개의 `NewConnections`가 있는 ElastiCache 노드는 몇 가지 명령에 의해 연결이 생성되고 사용된다는 것을 나타내며, 이는 최적화되지 않은 것입니다. 설정된 연결을 유지하고 새 작업에 이 연결을 다시 사용하는 것이 모범 사례입니다. 이것이 가능하려면 클라이언트 애플리케이션이 연결 풀링이나 영구 연결을 지원하고 적절하게 구현해야 합니다. 연결 풀링을 사용하는 경우 `currConnections` 수에는 큰 변화가 없으며 `NewConnections`는 가능한 낮아야 합니다. Valkey 또는 Redis OSS는 작은 수의 currConnections에서 최적의 성능을 제공합니다. currConnections를 대략 수십 개나 수백 개로 유지하면 클라이언트 버퍼와 같은 개별 연결을 지원하기 위한 리소스 사용량과 연결을 제공하기 위한 CPU 사이클을 최소화할 수 있습니다.
+ 네트워크 처리량:
+ 대역폭 결정: ElastiCache 노드의 네트워크 대역폭은 노드 크기에 비례합니다. 애플리케이션마다 특성이 다르기 때문에 워크로드에 따라 결과가 달라질 수 있습니다. 예를 들어 크기가 작은 요청의 비율이 높은 애플리케이션은 네트워크 처리량보다 CPU 사용량에 더 많은 영향을 미치는 경향이 있으며, 키가 커질수록 네트워크 사용률도 높아집니다. 그러므로 제한을 보다 정확하게 이해하기 위해 실제 워크로드로 노드를 테스트하는 것이 좋습니다.
애플리케이션의 로드를 시뮬레이션하면 보다 정확한 결과를 얻을 수 있습니다. 그러나 벤치마크 도구가 제한에 대한 좋은 아이디어를 줄 수 있습니다.
+ 요청이 주로 읽기인 경우 읽기 작업에 복제본을 사용하면 프라이머리 노드의 로드가 줄어듭니다. 사용 사례가 주로 쓰기인 경우 많은 복제본을 사용하면 네트워크 사용량이 크게 늘어납니다. 프라이머리 노드에 한 바이트가 쓰여질 때마다 N바이트가 복제본으로 전송됩니다. 여기서 N은 복제본 수입니다. 쓰기 집약적인 워크로드에 대한 모범 사례는 클러스터 모드가 활성화된 ElastiCache for Redis OSS를 사용하여 여러 샤드에 걸쳐 쓰기를 분산시키거나 더 많은 네트워크 용량이 있는 노드 유형으로 스케일 업할 수 있도록 하는 것입니다.
+ CloudWatchmetrics `NetworkBytesIn` 및 `NetworkBytesOut`는 각각 노드의 들어오고 나가는 데이터의 양을 제공합니다. `ReplicationBytes`는 데이터 복제 전용 트래픽입니다.
자세한 내용은 [네트워크 관련 제한 사항](#Network-limits) 섹션을 참조하세요.
+ 복잡한 명령: Redis OSS 명령은 단일 스레드에서 제공되므로 요청이 순차적으로 제공됩니다. 단일 느린 명령은 다른 요청 및 연결에 영향을 줄 수 있으며 시간 초과로 이어질 수 있습니다. 여러 값, 키 또는 데이터 유형에 작동하는 명령을 사용할 때 신중하게 사용해야 합니다. 연결은 파라미터의 수나 입력 또는 출력 값의 크기에 따라 차단되거나 종료될 수 있습니다.
악명 높은 예는`KEYS` 명령입니다. 이 명령은 전체 키스페이스에 걸쳐 주어진 패턴을 검색하며, 실행 중에 다른 명령의 실행을 차단합니다. Redis OSS는 “Big O” 표기법을 사용하여 명령의 복잡도를 설명합니다.
Keys 명령은 O(N) 시간 복잡도를 가지며 N은 데이터베이스의 키 수입니다. 따라서 키 수가 클수록 명령 속도가 느려집니다. `KEYS`는 여러 방식으로 문제를 일으킬 수 있습니다. 검색 패턴을 사용하지 않으면 이 명령은 사용 가능한 모든 키 이름을 반환합니다. 수 천개나 수 백만 개의 항목이 있는 데이터베이스에서는 엄청난 출력이 생성되어 네트워크 버퍼가 가득 차게 됩니다.
검색 패턴을 사용하는 경우 패턴과 일치하는 키만 클라이언트로 반환됩니다. 그러나 엔진은 여전히 전체 키스페이스에 걸쳐 키를 검색하며 명령을 완료하는 데 걸리는 시간은 동일합니다.
`KEYS` 명령의 대안은 `SCAN` 명령입니다. 이 명령은 키스페이스를 반복해서 처리하고 특정 수의 항목으로 반복을 제한하여 엔진의 장기적인 차단을 방지합니다.
Scan에는 반복 블록의 크기를 설정하는 데 사용되는 `COUNT` 파라미터가 있습니다. 기본값은 10(반복당 10개 항목)입니다.
데이터베이스의 항목 수에 따라, 작은 `COUNT` 값 블록이 전체 스캔을 완료하는 데 더 많은 반복을 필요로 하며 값이 클수록 각 반복마다 엔진을 더 오래 사용할 수 있습니다. 작은 count 값은 큰 데이터베이스에서 `SCAN` 속도를 느리게 만들며, 값이 클수록 `KEYS`에서 언급한 동일한 문제가 발생할 수 있습니다.
예를 들어, `SCAN` 명령을 count 값 10으로 실행하면 1백만 개의 키가 있는 데이터베이스에서 100,000번의 반복이 필요합니다. 평균 네트워크 왕복 시간이 0.5밀리초인 경우 요청을 전송하는 데 약 50,000밀리초(50초)가 소비됩니다.
반면에 count 값이 100,0000인 경우 단일 반복으로 충분하며 요청을 전송하는 데 단지 0.5밀리초가 소비됩니다. 그러나 명령이 모든 키스페이스의 처리를 마칠 때까지 엔진이 다른 작업에 대해 완전히 차단됩니다.
`KEYS` 외에도, 올바르게 사용하지 않으면 잠재적인 문제를 일으킬 수 있는 여러 다른 명령이 있습니다. 모든 명령의 목록과 각각의 시간 복잡도를 보려면 [Valkey 및 Redis OSS 명령](https://valkey.io/commands)으로 이동하세요.
잠재적 문제의 예:
+ Lua 스크립트: Valkey 및 Redis OSS는 서버 측에서 스크립트를 실행할 수 있도록 임베디드 Lua 인터프리터를 제공합니다. Valkey 및 Redis OSS의 Lua 스크립트는 엔진 수준에서 실행되며 정의에 따라 원자적입니다. 즉, 한 스크립트가 실행되는 동안 다른 명령이나 스크립트가 실행될 수 없습니다. Lua 스크립트는 엔진에서 직접 다중 명령, 의사 결정 알고리즘, 데이터 구문 분석 등을 실행할 수 있는 길을 열어줍니다. 스크립트의 원자성과 애플리케이션을 오프로드할 수 있는 기능은 유혹적이지만 스크립트는 작은 작업에 신중하게 사용해야 합니다. ElastiCache에서 Lua 스크립트의 실행 시간은 5초로 제한됩니다. 키스페이스에 기록되지 않은 스크립트는 5초 후에 자동으로 종료됩니다. 데이터 손상 및 불일치를 방지하기 위해 스크립트 실행이 5초 내에 완료되지 않았고 실행 중에 쓰기가 있는 경우 노드가 장애 조치됩니다. [트랜잭션](https://valkey.io/topics/transactions)은 Redis OSS에서 여러 관련 키 수정 사항의 일관성을 보장하는 다른 방법입니다. 트랜잭션을 사용하면 명령 블록을 실행하여 기존 키의 수정을 감시할 수 있습니다. 트랜잭션이 완료되기 전에 감시된 키가 변경되면 모든 수정 사항이 무시됩니다.
+ 항목의 일괄 삭제: `DEL` 명령에는 삭제할 키 이름에 해당하는 파라미터 여러 개를 사용할 수 있습니다. 삭제 작업은 동기식이며 파라미터 목록이 크거나 큰 목록, 집합, 정렬된 집합 또는 해시(여러 하위 항목을 포함하는 데이터 구조)가 포함된 경우 상당한 CPU 시간을 소비합니다. 즉, 단일 키를 삭제하는 경우에도 요소가 많은 경우 상당한 시간이 걸릴 수 있습니다. `DEL`의 대안은 Redis OSS 4부터 사용할 수 있는 비동기 명령인 `UNLINK`입니다. 가능한 경우 항상 `DEL` 대신 `UNLINK`를 사용해야 합니다. ElastiCache for Redis OSS 6.x부터 `lazyfree-lazy-user-del` 파라미터를 사용하면 `DEL` 명령이 `UNLINK`(활성화된 경우)처럼 작동합니다. 자세한 내용은 [Redis OSS 6.0 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x) 섹션을 참조하세요.
+ 여러 키에 작동하는 명령: `DEL`은 이전에 여러 인수를 허용하는 명령으로 언급되었으며 실행 시간은 이에 직접적으로 비례합니다. 그러나 Redis OSS는 유사하게 작동하는 많은 다른 명령을 제공합니다. 예를 들면 `MSET` 및 `MGET`를 사용하면 한 번에 여러 문자열 키를 삽입하거나 검색할 수 있습니다. 이러한 명령을 사용하면 개별 `SET` 또는 `GET` 명령을 여러 번 사용할 때 발생하는 네트워크 대기 시간을 줄일 수 있습니다. 그러나 파라미터의 광범위한 목록은 CPU 사용량에 영향을 미칩니다.
CPU 사용률만으로는 연결 문제의 원인이라고 할 수 없지만 여러 키에 대해 하나 또는 몇 개의 명령을 처리하는 데 너무 많은 시간이 소비되면 다른 요청이 실패하고 전반적인 CPU 사용률이 높아질 수 있습니다.
키의 수와 해당 크기는 명령의 복잡도, 결과적으로 완료 시간에 영향을 미칩니다.
여러 키에 작동할 수 있는 다른 명령의 예에는 `HMGET`, `HMSET`, `MSETNX`, `PFCOUNT`, `PFMERGE`, `SDIFF`, `SDIFFSTORE`, `SINTER`, `SINTERSTORE`, `SUNION`, `SUNIONSTORE`, `TOUCH`, `ZDIFF`, `ZDIFFSTORE`, `ZINTER`, `ZINTERSTORE` 등이 있습니다.
+ 여러 데이터 유형에 작동하는 명령: Redis OSS는 데이터 유형에 관계없이 하나 이상의 키에 작동하는 명령도 제공합니다. ElastiCache for Redis OSS는 이러한 명령을 모니터링하는 `KeyBasedCmds` 지표를 제공합니다. 이 지표는 선택한 기간 동안 다음과 같은 명령의 실행을 합산합니다.
+ O(N) 복잡도:
+ `KEYS`
+ O(1)
+ `EXISTS`
+ `OBJECT`
+ `PTTL`
+ `RANDOMKEY`
+ `TTL`
+ `TYPE`
+ `EXPIRE`
+ `EXPIREAT`
+ `MOVE`
+ `PERSIST`
+ `PEXPIRE`
+ `PEXPIREAT`
+ `UNLINK (O(N)`를 사용하여 메모리를 회수합니다. 그러나 메모리 회수 작업은 분리된 스레드에서 발생하며 엔진을 차단하지 않습니다.
+ 데이터 유형에 따라 복잡도 시간이 다릅니다.
+ `DEL`
+ `DUMP`
+ `RENAME`은 복잡도가 O(1)인 명령으로 간주되지만 내부적으로 `DEL`을 실행합니다. 실행 시간은 이름이 바뀐 키의 크기에 따라 달라집니다.
+ `RENAMENX`
+ `RESTORE`
+ `SORT`
+ 큰 해시: 해시는 여러 키-값 하위 항목이 있는 단일 키를 허용하는 데이터 유형입니다. 각 해시는 4,294,967,295개 항목을 저장할 수 있으며 큰 해시에 대한 작업은 비용이 많이 들 수 있습니다. `KEYS`와 유사하게, 해시에는 O(N) 시간 복잡도를 갖는 `HKEYS` 명령이 있으며, N은 해시의 항목 수입니다. 장기 실행 명령을 방지하려면 `HKEYS` 대신 `HSCAN`을 사용해야 합니다. `HDEL`, `HGETALL`, `HMGET`, `HMSET` 및 `HVALS`는 큰 해시에서 주의해서 사용해야 하는 명령입니다.
+ 기타 빅 데이터 구조: 해시 외에도 다른 데이터 구조가 CPU 집약적일 수 있습니다. 집합, 목록, 정렬된 집합 및 Hyperloglog는 크기와 사용된 명령에 따라 처리하는 데 상당한 시간이 걸릴 수 있습니다. 이러한 명령에 대한 자세한 내용은 [Valkey 및 Redis OSS 명령](https://valkey.io/commands)을 참조하세요.
## 네트워크 연결 검증
DNS 확인, 보안 그룹, 네트워크 ACL 및 라우팅 테이블과 관련된 네트워크 구성을 검토한 후 VPC Reachability Analyzer 및 시스템 도구를 사용하여 연결을 검증할 수 있습니다.
Reachability Analyzer는 네트워크 연결을 테스트하고 모든 요구 사항 및 권한이 충족되는지 확인합니다. 아래 테스트를 수행하려면 VPC에서 사용 가능한 ElastiCache 노드 중 하나의 탄력적 네트워크 인터페이스 ID(ENI ID)가 필요합니다. 다음을 수행하여 이 ID를 찾을 수 있습니다.
1. [https://console.aws.amazon.com/ec2/v2/home?\$1NIC](https://console.aws.amazon.com/ec2/v2/home?#NIC)로 이동합니다.
1. ElastiCache 클러스터 이름 또는 이전에 DNS 유효성 검사에서 얻은 IP 주소를 기준으로 인터페이스 목록을 필터링합니다.
1. ENI ID를 적어 두거나 따로 저장하세요. 여러 인터페이스가 표시되는 경우 설명을 검토하여 해당 인터페이스가 올바른 ElastiCache 클러스터에 속하는지 확인하고 그 중 하나를 선택합니다.
1. 다음 단계를 진행합니다.
1. [https://console.aws.amazon.com/vpc/home?\$1ReachabilityAnalyzer](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer)에서 분석 경로를 생성하고 다음 옵션을 선택합니다.
+ **소스 유형**: ElastiCache 클라이언트가 Amazon EC2 인스턴스에서 실행되는 경우 **인스턴스**를 선택하고, AWS Fargate Amazon ECS와 awsvpc 네트워크, AWS Lambda 등과 같은 다른 서비스를 사용하는 경우 **네트워크 인터페이스** 및 해당 리소스 ID(EC2 인스턴스 또는 ENI ID)를 선택합니다.
+ **대상 유형**: **네트워크 인터페이스**를 선택하고 목록에서 **ElastiCache ENI**를 선택합니다.
+ **대상 포트**: ElastiCache for Redis OSS의 경우 6379 또는 ElastiCache for Memcached의 경우 11211을 입력합니다. 이러한 포트는 기본 구성으로 정의된 포트이며 이 예에서는 포트가 변경되지 않는다고 가정합니다.
+ **프로토콜**: TCP
분석 경로를 생성하고 결과를 몇 분 정도 기다립니다. 상태가 연결할 수 없음인 경우 분석 세부 정보를 열고 **분석 탐색기**에서 요청이 차단된 위치에 대한 자세한 정보를 검토합니다.
연결성 테스트가 통과되면 OS 수준에서 확인을 진행합니다.
Amazon Linux에서 ElastiCache 서비스 포트의 TCP 연결성을 검증하려면 `nmap` 패키지에서 사용할 수 있는 `Nping`을 사용하여 ElastiCache 포트에서 TCP 연결성을 테스트할 수 있을 뿐만 아니라 연결 설정에 걸리는 네트워크 왕복 시간도 얻을 수 있습니다. 다음과 같이 이 명령을 사용하여 ElastiCache 클러스터에 대한 네트워크 연결성 및 현재 대기 시간을 검증합니다.
```
$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )
Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds
```
기본적으로, `nping`은 5개의 프로브를 사이에 1초의 지연 시간을 두어 전송합니다. “-c” 옵션을 사용하여 프로브 수를 늘리고 “--delay“ 옵션을 사용하여 새 테스트를 전송하는 시간을 변경할 수 있습니다.
`nping`을 사용하는 테스트는 실패하고 *VPC Reachability Analyzer* 테스트는 통과한다면 시스템 관리자에게 가능한 호스트 기반 방화벽 규칙, 비대칭 라우팅 규칙 또는 운영 체제 수준의 다른 모든 가능한 제한을 검토하도록 요청하세요.
ElastiCache 콘솔을 통해 ElastiCache 클러스터 세부 정보에서 **전송 중 데이터 암호화**가 활성화되어 있는지 확인합니다. 전송 중 암호화가 활성화되어 있으면 다음 명령을 사용하여 TLS 세션을 설정할 수 있는지 확인합니다.
```
openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379
```
연결 및 TLS 협상이 성공하면 많은 출력이 나타날 수 있습니다. 마지막 줄에서 사용할 수 있는 반환 코드를 확인하세요. 값이 `0 (ok)`여야 합니다. openssl이 다른 값을 반환하면 [https://www.openssl.org/docs/man1.0.2/man1/verify.html\$1DIAGNOSTICS](https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS)에서 오류의 원인을 확인하세요.
모든 인프라 및 운영 체제 테스트를 통과했지만 애플리케이션이 여전히 ElastiCache에 연결할 수 없는 경우 애플리케이션 구성이 ElastiCache 설정을 준수하는지 확인합니다. 일반적인 실수는 다음과 같습니다.
+ 애플리케이션이 ElastiCache 클러스터 모드를 지원하지 않으며 ElastiCache는 클러스터 모드가 활성화되어 있습니다.
+ 애플리케이션이 TLS/SSL을 지원하지 않으며 ElastiCache는 전송 중 데이터 암호화가 활성화되어 있습니다.
+ 애플리케이션은 TLS/SSL을 지원하지만 올바른 구성 플래그 또는 신뢰할 수 있는 인증 기관이 없습니다.
## 네트워크 관련 제한 사항
+ 최대 연결 수: 동시 연결에 대한 하드 제한이 있습니다. 각 ElastiCache 노드는 모든 클라이언트에서 최대 65,000개의 동시 연결을 허용합니다. 이 제한은 CloudWatch에서 `CurrConnections` 지표를 통해 모니터링할 수 있습니다. 그러나 클라이언트에는 아웃바운드 연결에 대한 제한이 있습니다. Linux의 경우 다음 명령을 사용하여 허용된 휘발성 포트 범위를 확인하세요.
```
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
```
이전 예에서 동일한 소스에서 동일한 대상 IP(ElastiCache 노드) 및 포트로 28231개 연결이 허용됩니다. 다음 명령은 특정 ElastiCache 노드(IP 1.2.3.4)에 존재하는 연결 수를 보여 줍니다.
```
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l
```
숫자가 너무 높으면 연결 요청을 처리하는 동안 시스템에 과부하가 걸릴 수 있습니다. 연결 처리를 개선하려면 연결 풀링이나 지속적인 연결과 같은 기술을 구현하는 것이 좋습니다. 가능한 경우 항상 연결 풀을 구성하여 최대 연결 수를 수백 개로 제한합니다. 또한 문제가 발생할 경우 연결 이탈을 방지하려면 시간 초과 또는 기타 연결 예외를 처리하는 백오프 로직이 필요합니다.
+ 네트워크 트래픽 제한: 다음과 같은 [Redis OSS의 CloudWatch 지표](CacheMetrics.Redis.md)를 확인하여 ElastiCache 노드에서 발생할 수 있는 네트워크 제한을 식별합니다.
+ `NetworkBandwidthInAllowanceExceeded`/`NetworkBandwidthOutAllowanceExceeded`: 처리량이 집계된 대역폭 제한을 초과하여 형성된 네트워크 패킷입니다.
프라이머리 노드에 한 바이트가 쓰여질 때마다 N개 복제본으로 복제됩니다. 여기서 N은 복제본 수입니다. 노드 유형이 작고, 여러 개의 복제본이 있으며 많은 쓰기 요청이 있는 클러스터는 복제 백로그를 처리하지 못할 수 있습니다. 이러한 경우 확장(노드 유형 변경), 스케일 아웃(클러스터 모드가 활성화된 클러스터에 샤드 추가), 복제본 수를 줄이기 또는 쓰기 수 최소화를 수행하는 것이 모범 사례입니다.
+ `NetworkConntrackAllowanceExceeded`: 노드에 할당된 모든 보안 그룹에서 추적되는 최대 연결 수를 초과했기 때문에 형성되는 패킷입니다. 이 기간 동안 새 연결이 실패할 가능성이 높습니다.
+ `NetworkPackets PerSecondAllowanceExceeded`: 초당 최대 패킷 수를 초과했습니다. 매우 크기가 작은 요청의 비율이 높은 워크로드는 최대 대역폭 전에 이 제한에 도달할 수 있습니다.
위의 지표는 네트워크 제한에 도달한 노드를 확인하는 이상적인 방법입니다. 그러나 제한은 네트워크 지표의 안정기로 식별할 수도 있습니다.
안정기가 오랜 기간 동안 관찰되면 이후에 복제 지연, 캐시에 사용되는 바이트 수 증가, 여유 메모리 하락, 높은 스왑 및 CPU 사용량이 뒤따를 가능성이 높습니다. 또한 Amazon EC2 인스턴스에는 [ENA 드라이버 지표](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html)를 통해 추적할 수 있는 네트워크 제한이 있습니다. 향상된 네트워킹 지원과 ENA 드라이버 2.2.10 이상을 사용하는 Linux 인스턴스에서는 다음 명령을 사용하여 제한 카운터를 검토할 수 있습니다.
```
# ethtool -S eth0 | grep "allowance_exceeded"
```
## CPU 사용량
CPU 사용량 지표는 조사의 시작점이며, 다음과 같은 항목은 ElastiCache 측에서 발생할 수 있는 문제의 범위를 좁히는 데 도움이 될 수 있습니다.
+ Redis OSS SlowLogs: ElastiCache 기본 구성은 완료하는 데 10밀리초 이상 걸린 마지막 128개 명령을 유지합니다. 느린 명령의 기록은 엔진 런타임 중에 유지되며 실패나 재시작 시 손실됩니다. 목록이 128개 항목에 도달하면 새 이벤트를 위한 공간을 확보하기 위해 이전 이벤트가 제거됩니다. 느린 이벤트 목록의 크기와 느린 것으로 간주되는 실행 시간은 [사용자 지정 파라미터 그룹](ParameterGroups.md)에서 `slowlog-max-len` 및 `slowlog-log-slower-than` 파라미터를 통해 수정할 수 있습니다. 슬로우 로그 목록을 검색하려면 엔진에 대해 `SLOWLOG GET 128`을 실행합니다. 여기서 128은 마지막 128개의 느린 명령을 보고합니다. 각 항목에는 다음과 같은 필드가 있습니다.
```
1) 1) (integer) 1 -----------> Sequential ID
2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
3) (integer) 4823378 -----> Time in microseconds to complete the command.
4) 1) "keys" -------------> Command
2) "*" ----------------> Arguments
5) "1.2.3.4:57004"-> Source
```
위의 이벤트는 UTC 기준으로 12월 26일 19:26:07에 발생했고 완료하는 데 4.8초(4,823밀리초)가 걸렸으며 클라이언트 1.2.3.4에서 요청된 `KEYS` 명령에 의해 발생했습니다.
Linux에서 타임스탬프를 date 명령으로 변환할 수 있습니다.
```
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
```
Python 사용:
```
>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)
```
또는 PowerShell 사용하여 Windows에서:
```
PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime : 12/26/2020 7:26:07 PM
UtcDateTime
: 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date : 12/26/2020 12:00:00 AM
Day : 26
DayOfWeek
: Saturday
DayOfYear : 361
Hour : 19
Millisecond : 0
Minute : 26
Month
: 12
Offset : 00:00:00Ticks : 637446075670000000
UtcTicks
: 637446075670000000
TimeOfDay : 19:26:07
Year : 2020
```
짧은 시간(1분 이하) 동안 발생한 많은 느린 명령이 우려의 이유입니다. 명령의 특성과 명령을 최적화할 수 있는 방법을 검토합니다(이전 예제 참조). O(1) 시간 복잡도가 있는 명령이 자주 보고되는 경우 앞서 언급한 높은 CPU 사용량에 대한 다른 요인을 확인하세요.
+ 대기 시간 지표: ElastiCache for Redis OSS는 다양한 종류의 명령에 대한 평균 대기 시간을 모니터링하는 CloudWatch 지표를 제공합니다. 데이터 포인트는 한 범주에 속하는 명령의 총 실행 횟수를 해당 기간의 총 실행 시간으로 나누어 계산합니다. 대기 시간 지표의 결과는 여러 명령의 집계임을 이해하는 것이 중요합니다. 단일 명령을 사용하면 지표에 큰 영향을 주지 않으며 시간 초과와 같은 예기치 않은 결과가 발생할 수 있습니다. 이러한 경우 느리 로그 이벤트가 보다 정확한 정보 소스가 될 수 있습니다. 다음 목록에는 사용 가능한 대기 시간 지표와 이에 영향을 주는 각 명령이 나와 있습니다.
+ EvalBasedCmdsLatency: Lua 스크립트 명령 `eval`, `evalsha`와 관련이 있습니다.
+ GeoSpatialBasedCmdsLatency:`geodist` ,`geohash` ,`geopos` ,`georadius` ,`georadiusbymember` ,`geoadd`
+ GetTypeCmdsLatency: 데이터 유형이 관계없이 읽기 명령
+ HashBasedCmdsLatency:`hexists` ,`hget` ,`hgetall` ,`hkeys` ,`hlen` ,`hmget` ,`hvals` ,`hstrlen` ,`hdel` ,`hincrby` ,`hincrbyfloat` ,`hmset` ,`hset` ,`hsetnx`
+ HyperLogLogBasedCmdsLatency:`pfselftest` ,`pfcount` ,`pfdebug` ,`pfadd` ,`pfmerge`
+ KeyBasedCmdsLatency: 서로 다른 데이터 유형에서 작동할 수 있는 명령:`dump` ,`exists` ,`keys` ,`object` ,`pttl` ,`randomkey` ,`ttl` ,`type` ,`del` ,`expire` ,`expireat` ,`move` ,`persist` ,`pexpire` ,`pexpireat` ,`rename` ,`renamenx` ,`restoreK` ,`sort` ,`unlink`
+ ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx
+ PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe
+ SetBasedCmdsLatency:`scard` ,`sdiff` ,`sinter` ,`sismember` ,`smembers` ,`srandmember` ,`sunion` ,`sadd` ,`sdiffstore` ,`sinterstore` ,`smove` ,`spop` ,`srem` ,`sunionstore`
+ SetTypeCmdsLatency: 데이터 유형에 관계없이 쓰기 명령
+ SortedSetBasedCmdsLatency:`zcard` ,`zcount` ,`zrange` ,`zrangebyscore` ,`zrank` ,`zrevrange` ,`zrevrangebyscore` ,`zrevrank` ,`zscore` ,`zrangebylex` ,`zrevrangebylex` ,`zlexcount` ,`zadd` .`zincrby` ,`zinterstore` ,`zrem` ,`zremrangebyrank` ,`zremrangebyscore` ,`zunionstore` ,`zremrangebylex` ,`zpopmax` ,`zpopmin` ,`bzpopmin` ,`bzpopmax`
+ StringBasedCmdsLatency:`bitcount` ,`get` ,`getbit` ,`getrange` ,`mget` ,`strlen` ,`substr` ,`bitpos` ,`append` ,`bitop` ,`bitfield` ,`decr` ,`decrby` ,`getset` ,`incr` ,`incrby` ,`incrbyfloat` ,`mset` ,`msetnx` ,`psetex` ,`set` ,`setbit` ,`setex` ,`setnx` ,`setrange`
+ StreamBasedCmdsLatency:`xrange` ,`xrevrange` ,`xlen` ,`xread` ,`xpending` ,`xinfo` ,`xadd` ,`xgroup` ,`readgroup` ,`xack` ,`xclaim` ,`xdel` ,`xtrim` ,`xsetid`
+ Redis OSS 런타임 명령:
+ info commandstats: 엔진이 시작된 이후 실행된 명령, 누적 실행 횟수, 총 실행 시간 및 명령당 평균 실행 시간으로 구성된 목록을 제공합니다.
+ client list: 현재 연결된 클라이언트와 버퍼 사용량, 마지막으로 실행된 명령 등과 같은 관련 정보의 목록을 제공합니다.
+ 백업 및 복제: 2.8.22 이전 버전의 ElastiCache for Redis OSS에서는 forked 프로세스를 사용하여 백업을 생성하고 복제본과의 전체 동기화를 처리합니다. 이 방법은 쓰기 집약적인 사용 사례에서 상당한 메모리 오버헤드가 발생시킬 수 있습니다.
ElastiCache Redis OSS 2.8.22부터, AWS에 forkless 백업 및 복제 방법이 도입되었습니다. 새로운 방법은 실패를 방지하기 위해 쓰기를 지연시킬 수 있습니다. 두 방법 모두 CPU 사용률을 높일 수 있고 응답 시간이 길어지게 만들 수 있으므로 실행 중에 클라이언트 시간 초과가 발생할 수 있습니다. 백업 기간 중에 클라이언트 장애가 발생하거나 이 기간 중에 `SaveInProgress` 지표가 1이었는지 항상 확인하세요. 클라이언트 문제 또는 백업 실패의 가능성을 최소화하기 위해 사용률이 낮은 기간으로 백업 기간을 예약하는 것이 좋습니다.
## 서버 측에서 연결이 종료되는 경우
기본 ElastiCache for Redis OSS 구성은 클라이언트 연결을 무기한 유지합니다. 그러나 경우에 따라 연결 종료가 필요할 수 있습니다. 예:
+ 클라이언트 애플리케이션의 버그로 인해 연결이 손실되고 유휴 상태로 설정이 유지될 수 있습니다. 이것을 “연결 누수“라고 하며 결과적으로 `CurrConnections` 지표에서 관찰되는 설정된 연결의 수가 지속적으로 증가합니다. 이 동작으로 인해 클라이언트 또는 ElastiCache 측에서 포화가 발생할 수 있습니다. 클라이언트 측에서 즉시 수정할 수 없는 경우 일부 관리자는 ElastiCache 파라미터 그룹에 ”시간 초과“ 값을 설정합니다. 시간 초과는 유휴 연결이 지속되도록 허용된 기간(초)입니다. 클라이언트가 이 기간 동안 요청을 제출하지 않으면 엔진은 연결이 시간 초과 값에 도달하는 즉시 연결을 종료합니다. 시간 초과 값이 작으면 불필요한 연결 끊기가 발생할 수 있으며 클라이언트가 연결을 올바르게 처리하고 다시 연결해야 하므로 지연이 발생합니다.
+ 키를 저장하는 데 사용되는 메모리는 클라이언트 버퍼와 공유됩니다. 크기가 큰 요청이나 응답이 있는 느린 클라이언트는 버퍼를 처리하기 위해 상당한 양의 메모리를 요구할 수 있습니다. 기본 ElastiCache for Redis OSS 구성은 일반 클라이언트 출력 버퍼의 크기를 제한하지 않습니다. `maxmemory` 제한에 도달하면 엔진은 버퍼 사용량을 충족하기 위해 항목을 제거하려고 시도합니다. 메모리 극히 부족한 상황에서 ElastiCache for Redis OSS는 메모리를 확보하고 클러스터의 상태를 유지하기 위해 선택적으로 대용량 클라이언트 출력 버퍼를 사용하는 클라이언트의 연결을 끊을 수 있습니다.
사용자 지정 구성으로 클라이언트 버퍼의 크기를 제한할 수 있으며 이 제한에 도달한 클라이언트는 연결이 끊어집니다. 그러나 클라이언트는 예기치 않은 연결 해제를 처리할 수 있어야 합니다. 일반 클라이언트의 버퍼 크기를 처리하는 파라미터는 다음과 같습니다.
+ client-query-buffer-limit: 단일 입력 요청의 최대 크기
+ client-output-buffer-limit-normal-soft-limit: 클라이언트 연결에 대한 소프트 제한. 연결이 client-output-buffer-limit-normal-soft-seconds에 정의된 시간(초)보다 오래 소프트 제한을 초과하거나 하드 제한에 도달하는 경우 연결이 종료됩니다.
+ client-output-buffer-limit-normal-soft-seconds: 연결이 client-output-buffer-limit-normal-soft-limit을 초과하도록 허용되는 시간
+ client-output-buffer-limit-normal-hard-limit: 이 제한에 도달하는 연결은 즉시 종료됩니다.
일반 클라이언트 버퍼 외에도, 다음 옵션은 복제본 노드 및 Pub/Sub(게시/구독) 클라이언트에 대한 버퍼를 제어합니다.
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-replica-soft-seconds;
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-pubsub-soft-limit;
+ client-output-buffer-limit-pubsub-soft-seconds;
+ client-output-buffer-limit-pubsub-hard-limit;
## Amazon EC2 인스턴스에 대한 클라이언트 측 문제 해결
클라이언트 측의 로드 및 응답성은 ElastiCache에 대한 요청에도 영향을 줄 수 있습니다. 간헐적인 연결성 또는 시간 초과 문제를 해결하는 동안 EC2 인스턴스 및 운영 체제 제한을 신중하게 검토해야 합니다. 관찰할 몇 가지 핵심 사항:
+ CPU:
+ EC2 인스턴스 CPU 사용량: CPU가 포화되거나 100%에 가까워지지 않았는지 확인합니다. 기간별 분석은 CloudWatch를 통해 수행할 수 있지만 데이터 포인터의 세분성은 1분(세부 모니터링이 활성화된 경우) 또는 5분입니다.
+ [버스트 가능 EC2 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)를 사용하는 경우 CPU 크레딧 밸런스가 고갈되지 않았는지 확인하세요. 이 정보는 `CPUCreditBalance` CloudWatch 지표에서 사용할 수 있습니다.
+ 짧은 기간 동안의 높은 CPU 사용량이 CloudWatch에서 100% 사용률을 표시하지 않고 시간 초과를 발생시킬 수 있습니다. 이러한 경우에는 `top`, `ps` 및 `mpstat` 같은 운영 체제 도구를 사용하여 실시간 모니터링을 수행해야 합니다.
+ Network
+ 네트워크 처리량이 인스턴스 용량에 따라 허용 가능한 값 이하인지 확인합니다. 자세한 내용은 [Amazon EC2인스턴스 유형](https://aws.amazon.com/ec2/instance-types/) 참조
+ `ena` Enhanced Network 드라이버를 사용하는 인스턴스의 경우 [ena statistics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-ena.html#statistics-ena)에서 시간 초과 또는 제한 초과를 확인합니다. 다음 통계는 네트워크 제한 도달 상태를 확인하는 데 유용합니다.
+ `bw_in_allowance_exceeded`/`bw_out_allowance_exceeded`: 과도한 인바운드 또는 아웃바운드 처리량으로 인해 형성된 패킷 수
+ `conntrack_allowance_exceeded`: 보안 그룹 [연결 추적 제한](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#connection-tracking-throttling)으로 인해 삭제된 패킷 수. 이 제한에 도달하면 새 연결이 실패합니다.
+ `linklocal_allowance_exceeded`: 인스턴스 메타 데이터, VPC DNS를 통한 NTP에 대한 과도한 요청으로 인해 손실된 패킷 수. 이 제한은 모든 서비스에 대해 초당 1024패킷입니다.
+ `pps_allowance_exceeded`: 과도한 초당 패킷 수 비율로 인해 손실된 패킷 수. 네트워크 트래픽이 초당 수천 또는 수백만 개의 매우 작은 요청으로 구성된 경우 PPS 제한에 도달할 수 있습니다. ElastiCache 트래픽은 `GET`이 아니라 `MGET` 같이 여러 작업을 동시에 수행하는 파이프라인 또는 명령을 통해 네트워크 패킷을 효율적으로 사용하도록 최적화할 수 있습니다.
## 단일 요청을 완료하는 데 걸리는 시간 분석
+ 네트워크에서 `Tcpdump` 및 `Wireshark`(명령줄의 tshark)는 요청이 네트워크를 이동하여 ElastiCache 엔진에 도달하고 반환되는 데 걸리는 시간을 파악할 수 있는 편리한 도구입니다. 다음 예제에서는 다음과 같은 명령을 사용하여 생성한 단일 요청을 강조 표시합니다.
```
$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG
```
위의 명령과 병행하여 tcpdump가 실행 중이었고 반환되었습니다.
```
$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
> 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
```
위의 출력에서 TCP 3방향 핸드셰이크가 완료되는 데 222마이크로초(918091 - 917869)가 걸렸고 ping 명령이 제출되어 반환되는 데 173마이크로초(918295 - 918122)가 걸렸음을 확인할 수 있습니다.
요청부터 연결을 닫는 데까지 438마이크로초(918307 - 917869)가 걸렸습니다. 이러한 결과를 통해 네트워크 및 엔진 응답 시간이 양호하다고 확신할 수 있으며 조사를 다른 구성 요소에 집중할 수 있습니다.
+ 운영 체제에서 `Strace`를 사용하여 OS 수준의 시간 간격을 식별할 수 있습니다. 실제 애플리케이션의 분석에는 보다 광범위하고 전문화된 애플리케이션 프로파일러 또는 디버거를 사용하는 것이 좋습니다. 다음 예제에서는 기본 운영 체제 구성 요소가 예상대로 작동하는지 여부만 보여 주며, 예상대로 작동하지 않는 경우 추가 조사가 필요할 수 있습니다. `strace`와 함께 동일한 Redis OSS `PING` 명령을 사용하여 얻은 결과:
```
$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
(+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
(+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
(+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
(Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
(+ 0.003569) +++ exited with 0 +++
```
위의 예제에서 명령을 완료하는 데 54밀리초 이상이 걸렸습니다(752110 - 697712 = 54398마이크로초).
nc를 인스턴스화하고 이름을 확인하는 데 약 20밀리초(697712에서 717890)의 상당한 시간이 걸렸으며, 그 후에 TCP 소켓을 생성하는 데 2밀리초(745659에서 747858), 요청을 제출하고 응답을 받는 데 0.4밀리초(747858에서 748330)가 필요했습니다.
## 관련 항목
+ [ElastiCache 모범 사례 및 캐싱 전략](BestPractices.md)