翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 レンズの使用](WellArchitechtedLens.md)
+ [ElastiCache の一般的なトラブルシューティング手順とベストプラクティス](wwe-troubleshooting.md)
# スナップショットおよび復元
Valkey、Redis OSS、または Serverless Memcached を実行している Amazon ElastiCache キャッシュでは、スナップショットを作成することでデータをバックアップできます。このバックアップを使用すると、キャッシュまたはシードデータを新しいキャッシュに復元できます。バックアップは、キャッシュ内の全データとキャッシュのメタデータで構成されます。すべてのバックアップは、耐久性のあるストレージを提供する Amazon Simple Storage Service (Amazon S3) に書き込まれます。新しい Valkey、Redis OSS、または Serverless Memcached キャッシュを作成し、バックアップのデータを挿入することで、いつでもデータを復元できます。ElastiCache では、、AWS Command Line Interface(AWS CLI)AWS マネジメントコンソール、および ElastiCache API を使用してバックアップを管理できます。
キャッシュを削除する予定であり、データを保持することが重要な場合は、万一に備えることができます。そのためには、まず手動バックアップを作成し、そのステータスが *[利用可能]* であることを確認してから、キャッシュを削除します。これにより、バックアップが失敗した場合でも、キャッシュデータは引き続き使用できます。前述のベストプラクティスに従って、バックアップの作成を再試行できます。
**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、または Serverless 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)」を参照してください。
+ リードレプリカからバックアップを作成する – 複数のノードを含むノードグループで 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 コンソール、、または ElastiElastiCache API を使用して、新しいキャッシュを作成するとき、または既存のキャッシュを更新するときに、自動バックアップを有効AWS CLIまたは無効にできます。Valkey および Redis OSS の場合、**[Valkey の詳細設定]** または **[Redis OSS の詳細設定]** セクションの **[自動バックアップの有効化]** チェックボックスをオンにします。Memcached の場合、**[Memcached の詳細設定]** セクションの **[自動バックアップの有効化]** チェックボックスをオンにします。
# 手動バックアップの取得
自動バックアップに加えて、いつでも*手動*バックアップを作成できます。指定された保持期間後に自動的に削除される自動バックアップとは異なり、手動バックアップには、経過した後で自動的に削除される保持期間はありません。キャッシュを削除しても、そのキャッシュからの手動バックアップはすべて保持されます。手動バックアップを保持する必要がなくなった場合は、自分で明示的に削除する必要があります。
手動バックアップの直接的な作成に加えて、以下のいずれかの方法で手動バックアップを作成できます。
+ 「[バックアップのコピー](backups-copying.md)」ソースのバックアップが自動で作成されたか、手動で作成されたかは問題ではありません。
+ 「[最終バックアップの作成](backups-final.md)」クラスターまたはノードを削除する直前に最終バックアップを作成します。
キャッシュの手動バックアップは、AWS マネジメントコンソール、、AWS CLIまたは ElastiCache API を使用して作成できます。
クラスターモードが有効になっているレプリカとクラスターモードが無効になっているレプリカから手動バックアップを生成できます。
## 手動バックアップの作成
**キャッシュのバックアップを作成するには (コンソール)**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで、目的に応じて、**[Valkey キャッシュ]**、**[Redis OSS キャッシュ]**、または **[Memcached キャッシュ]** を選択します。
1. バックアップするキャッシュの名前の左にあるチェックボックスをオンにします。
1. **[バックアップ]** を選択します。
1. **[バックアップを作成する]** ダイアログで、**[バックアップ名]** ボックスにバックアップの名前を入力します。バックアップ元のクラスターおよびバックアップを実行した日付と時刻を示すような名前にすることをお勧めします。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
1. **[バックアップを作成]** を選択します。
クラスターのステータスが *snapshotting* に変わります。
## 手動バックアップの作成 (AWS CLI)
**を使用したサーバーレスキャッシュの手動バックアップAWS CLI**
を使用してキャッシュの手動バックアップを作成するにはAWS CLI、以下のパラメータを指定して `create-serverless-snapshot`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**
を使用してノードベースのクラスターの手動バックアップを作成するにはAWS CLI、次のパラメータを指定して `create-snapshot`AWS CLIオペレーションを使用します。
+ `--cache-cluster-id`
+ バックアップするクラスターにレプリカノードがない場合、`--cache-cluster-id` は、バックアップするクラスターの名前 (*mycluster* など) です。
+ バックアップするクラスターに 1 つ以上のレプリカノードがある場合、`--cache-cluster-id` は、バックアップに使用するクラスター内のノードの名前です。たとえば、名前は *mycluster-002* です。
このパラメータは、Valkey または Redis OSS (クラスターモードが無効) クラスターをバックアップする場合にのみ使用します。
+ `--replication-group-id` – バックアップのソースとして使用する Valkey または Redis OSS (クラスターモードが有効) クラスター (CLI/API: レプリケーショングループ) の名前。このパラメータは、Valkey または Redis OSS (クラスターモードが有効) クラスターをバックアップするときに使用します。
+ `--snapshot-name` – 作成するスナップショットの名前。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 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`。このバックアップには、1 つ以上のリードレプリカがあります。
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`。送信元を特定する `--cache-cluster-id` ではなく、`--replication-group-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
CloudFormationを使用して、 `AWS::ElastiCache::ServerlessCache`または `AWS::ElastiCache::ReplicationGroup`プロパティを使用して 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 を使用して最終バックアップを作成できます。
## 最終バックアップの作成 (コンソール)
Valkey、Memcached、または Redis OSS のサーバーレスキャッシュ、あるいは Valkey または Redis OSS のノードベースのクラスターを削除するときに、ElastiCache コンソールを使用して、最終バックアップを作成できます。
キャッシュの削除時に最終バックアップを作成するには、削除ダイアログボックスの **[バックアップを作成]** で **[はい]** を選択し、バックアップに名前を付けます。
**関連トピック**
+ [の使用AWS マネジメントコンソール](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` – バックアップの名前。
以下のコードは、最終バックアップ `bkup-20231127-final` をキャッシュ `myserverlesscache` の削除時に作成します。
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` – バックアップの名前。
以下のコードは、最終バックアップ `bkup-20150515-final` をクラスター `myRedisCluster` の削除時に作成します。
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 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` – 最終バックアップの名前。
以下のコードは、最終バックアップ `bkup-20150515-final` をレプリケーショングループ `myReplGroup` の削除時に作成します。
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 マネジメントコンソール**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで **[バックアップ]** を選択します。
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 マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. バックアップのリストを表示するには、左のナビゲーションペインから [**Backups**] を選択します。
1. バックアップのリストから、コピーするバックアップの名前の左にあるチェックボックスをオンにします。
1. **[アクション]**、**[コピー]** の順に選択します。
1. **[新しいバックアップ名]** ボックスに、新しいバックアップの名前を入力します。
1. **[コピー]** を選択します。
## サーバーレスバックアップのコピー (AWS CLI)
サーバーレスキャッシュのバックアップをコピーするには、`copy-serverless-cache-snapshot` オペレーションを使用します。
**パラメータ**
+ `--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
```
詳細については、「*AWS CLI*」の「[https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html)」を参照してください。
## ノードベースのクラスターバックアップのコピー (AWS CLI)
ノードベースのクラスターのバックアップをコピーするには、`copy-snapshot` オペレーションを使用します。
**パラメータ**
+ `--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
```
詳細については、「*AWS CLI*」の「[https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html)」を参照してください。
# バックアップのエクスポート
Amazon ElastiCache は、ElastiCache for Redis OSS バックアップの Amazon Simple Storage Service (Amazon S3) バケットへのエクスポートをサポートしています。これにより、ElastiCache の外部からバックアップにアクセスできます。ElastiCache コンソール、、AWS CLIまたは ElastiCache API を使用してバックアップをエクスポートできます。
バックアップのエクスポートは、別のAWSリージョンでクラスターを起動する必要がある場合に役立ちます。データを 1 つの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 に付与します。最初の 2 つのステップで、これを行う方法を示します。
## Amazon S3 バケットを作成する
以下の手順では、Amazon S3 コンソールを使用して、ElastiCache バックアップをエクスポートおよび保存する Amazon S3 バケットを作成します。
**Amazon S3 バケットを作成するには**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。
1. **バケットの作成** を選択します。
1. **バケットを作成する - バケット名と地域を選択する** で、以下の操作を実行します。
1. [**Bucket Name**] に Amazon S3 バケットの名前を入力します。
Amazon S3 バケットの名前は DNS に準拠している必要があります。それ以外の場合、ElastiCache はバックアップファイルにアクセスできません。DNS コンプライアンスのルールは次のとおりです。
+ 名前は、3～63 文字以内にする必要があります。
+ 名前は、ピリオド (.) で区切られた 1 つのラベルまたは一連の複数のラベルとして指定します。
+ 先頭の文字には小文字の英文字または数字を使用します。
+ 終了の文字には小文字の英文字または数字を使用します。
+ 小文字の英文字、数字、およびダッシュのみを含めます。
+ 名前は IP アドレスの形式にすることはできません (例: 192.0.2.0)。
1. **リージョン**リストから、Amazon S3 バケットのAWSリージョンを選択します。このAWSリージョンは、エクスポートする ElastiCache バックアップと同じAWSリージョンである必要があります。
1. **[作成]** を選択します。
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 マネジメントコンソールし、[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]** (許可) で、**[Access control list (ACL)]** (アクセスコントロールリスト (ACL)) を選択して、**[Edit]** (編集) を選択します。
1. 次のオプションを使用して、被付与者の正規 ID `540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353` を追加します。
+ **[Objects]** (オブジェクト): [List] (リスト)、[Write] (書き込み)
+ **[Bucket ACL]** (バケット 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 コンソールを使用してバックアップを Amazon S3 バケットにエクスポートし、ElastiCache 外部からアクセスできるようにします。Amazon S3 バケットは、ElastiCache バックアップと同じAWSリージョンにある必要があります。
**ElastiCache バックアップを Amazon S3 バケットにエクスポートするには**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. バックアップのリストを表示するには、左のナビゲーションペインから [**Backups**] を選択します。
1. バックアップのリストから、エクスポートするバックアップの名前の左にあるチェックボックスをオンにします。
1. **コピー** を選択します。
1. **バックアップのコピーを作成しますか**ダイアログボックスで、以下の設定を指定します。
1. **[新しいバックアップ名]** ボックスに、新しいバックアップの名前を入力します。
この名前は 1～1,000 文字で、UTF-8 エンコードが可能である必要があります。
ElastiCache は、ここで入力した値に、インスタンス識別子と `.rdb` を追加します。たとえば、「`my-exported-backup`」と入力した場合、ElastiCache によって `my-exported-backup-0001.rdb` が作成されます。
1. [**Target S3 Location**] リストから、バックアップをコピーする Amazon S3 バケット (「[Amazon S3 バケットを作成する](#backups-exporting-create-s3-bucket)」で作成したバケット) の名前を選択します。
**ターゲット S3 の場所**は、エクスポートプロセスを成功させるために、次のアクセス許可を持つバックアップのAWSリージョンの Amazon S3 バケットである必要があります。
+ オブジェクトアクセス – **読み取り** および **書き込み**。
+ アクセス許可 – **読み取り**
詳細については、「[Amazon S3 バケットへのアクセス権を ElastiCache に付与する](#backups-exporting-grant-access)」を参照してください。
1. **コピー** を選択します。
**注記**
S3 バケットにバックアップをエクスポートするためのアクセス許可が ElastiCache にない場合、以下のいずれかのエラーメッセージを受け取ります。「[Amazon S3 バケットへのアクセス権を ElastiCache に付与する](#backups-exporting-grant-access)」に戻り、示されたアクセス権限を追加して、バックアップのエクスポートを再試行してください。
ElastiCache has not been granted READ permissions %s on the S3 Bucket。
**解決策:** バケットで読み取りのアクセス権限を追加します。
ElastiCache has not been granted WRITE permissions %s on the S3 Bucket。
**解決策:** バケットで書き込みのアクセス権限を追加します。
ElastiCache has not been granted READ\$1ACP permissions %s on the S3 Bucket。
**解決策:** バケットで**読み取り**のアクセス権限を追加します。
バックアップを別の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 バケットにバックアップをエクスポートします。
**パラメータ**
+ `--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 バケットにバックアップをエクスポートします。
**パラメータ**
+ `--source-snapshot-name` – コピーするバックアップの名前。
+ `--target-snapshot-name` – バックアップのコピーの名前。
この名前は 1～1,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 以降、Redis OSS バージョン 5.0 から入手可能な最新バージョンまでのバージョンと互換性がある RDB ファイルをサポートしています。
**サーバーレスキャッシュにバックアップを復元するには (コンソール)**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで **[バックアップ]** を選択します。
1. バックアップのリストで、復元するバックアップ名の左にあるチェックボックスをオンにします。
1. **[アクション]** から **[復元]** を選択します。
1. 新しいサーバーレスキャッシュの名前と説明 (任意) を入力します。
1. **[作成]** をクリックして新しいキャッシュを作成し、バックアップからデータをインポートします。
## ノードベースのクラスターへのバックアップの復元 (コンソール)
**ノードベースのクラスターにバックアップを復元する方法 (コンソール)**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで **[バックアップ]** を選択します。
1. バックアップのリストで、復元元のバックアップ名の左にあるチェックボックスをオンにします。
1. **[アクション]** から **[復元]** を選択します。
1. **[ノードベースのキャッシュ]** を選択し、ノードタイプ、サイズ、シャード数、レプリカ、AZ 配置、セキュリティ設定などのクラスター設定をカスタマイズします。
1. **[作成]** を選択して新しいノードベースのクラスターを作成し、バックアップからデータをインポートします。
## サーバーレスキャッシュへのバックアップの復元 (AWS CLI)
**注記**
ElastiCache サーバーレスは、Valkey 7.2 以降、Redis OSS バージョン 5.0 から入手可能な最新バージョンまでのバージョンと互換性がある RDB ファイルをサポートしています。
**サーバーレスキャッシュにバックアップを復元するには (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 マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで、**[バックアップ]** を選択します。
[バックアップ] 画面にバックアップのリストが表示されます。
1. 削除するバックアップの名前の左にあるチェックボックスをオンにします。
1. **[削除]** をクリックします。
1. このバックアップを削除する場合は、**[バックアップの削除]** 確認画面で **[削除]** を選択します。ステータスが *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 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 バックアップデータがノードのリソースを超えていないことを確認する必要があります。例えば、2.9 GB のメモリがある cache.m3.medium ノードに、5 GB の Valkey または Redis OSS データがある .rdb ファイルをアップロードすることはできません。
バックアップが大きすぎる場合、クラスターのステータスは `restore-failed` になります。その場合は、クラスターを削除してやり直す必要があります。
ノードの種類および仕様の一覧については、「[Redis OSS のノードタイプに固有のパラメータ](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific)」および [Amazon ElastiCache 製品の特徴と詳細](https://aws.amazon.com/elasticache/details/)を参照してください。
Valkey または Redis OSS .rdb ファイルは、Amazon S3 サーバー側の暗号化 (SSE-S3) でのみ暗号化できます。詳細については、「[サーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html)」を参照してください。
以下のトピックでは、クラスターを ElastiCache for Valkey または Redis OSS の外部から 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。 .rdb ファイルへの読み込みアクセスを ElastiCache に付与する](#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。 .rdb ファイルへの読み込みアクセスを ElastiCache に付与する](#backups-seeding-redis-grant-access)
## ステップ 1: Valkey または Redis OSS バックアップを作成する
**Valkey または Redis OSS バックアップを作成して、ElastiCache for 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 ウェブサイトの「[Persistence](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 マネジメントコンソールし、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。
1. Amazon S3 バケットを作成するには、*Amazon Simple Storage Service ユーザーガイド*の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html)」の手順に従います。
Amazon S3 バケットの名前は DNS に準拠している必要があります。それ以外の場合、ElastiCache はバックアップファイルにアクセスできません。DNS コンプライアンスのルールは次のとおりです。
+ 名前は、3～63 文字以内にする必要があります。
+ 名前は、ピリオド (.) で区切られた 1 つのラベルまたは一連の複数のラベルとして指定します。
+ 先頭の文字には小文字の英文字または数字を使用します。
+ 終了の文字には小文字の英文字または数字を使用します。
+ 小文字の英文字、数字、およびダッシュのみを含めます。
+ 名前は IP アドレスの形式にすることはできません (例: 192.0.2.0)。
Amazon S3 バケットは、新しい ElastiCache for Redis OSS クラスターと同じAWSリージョンに作成する必要があります。このアプローチにより、ElastiCache が Amazon S3 から .rdb ファイルを読み取る場合のデータ転送速度が最大限に速くなります。
**注記**
データを可能な限り安全に保つには、Amazon S3 バケットに対するアクセス許可をできるだけ制限します。同時に、バケットとその内容を使用して新しい Valkey または Redis OSS クラスターをシードするためのアクセス許可を付与する必要があります。
**Amazon S3 バケットにフォルダを追加するには**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。
1. .rdb ファイルのアップロード先となるバケットの名前を選択します。
1. **Create folder** (フォルダの作成) を選択します。
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 マネジメントコンソールし、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。
1. ステップ 2 で作成した Amazon S3 バケットの名前を選択します。
1. ステップ 2 で作成したフォルダの名前を選択します。
1. **アップロード**を選択します。
1. **ファイルの追加**を選択します。
1. アップロードする 1 つまたは複数のファイルを参照して見つけ、そのファイルを選択します。複数のファイルを選択するには、Ctrl キーを押しながら各ファイル名を選択します。
1. **開く** をクリックします。
1. 正しいファイルが **[アップロード]** ダイアログボックスに表示されることを確認してから、**[アップロード]** を選択します。
.rdb ファイルへのパスを記録します。例えば、バケット名が `myBucket` で、パスが `myFolder/redis.rdb` の場合は、「`myBucket/myFolder/redis.rdb`」と入力します。新しいクラスターにこのバックアップのデータをシードする際にこのパスが必要です。
詳細については、*Amazon Simple Storage Service ユーザーガイド*の [Bucket restrictions and limitations](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) を参照してください。
## ステップ 4。 .rdb ファイルへの読み込みアクセスを ElastiCache に付与する
ここで、.rdb バックアップファイルへの読み取りアクセス権を ElastiCache に付与します。バケットがデフォルトのAWSリージョンにあるかオプトインリージョンにあるかに応じて、ElastiCache に別の方法でバックアップファイルへのアクセスを許可しますAWS。
AWS 2019 年 3 月 20 日より前に導入されたリージョンは、デフォルトで有効になっています。これらのAWSリージョンですぐに作業を開始できます。2019 年 3 月 20 日以降に導入されたアジアパシフィック (香港) および中東 (バーレーン) などのリージョンは、デフォルトで無効になっています。*AWS 全般のリファレンス* の「[AWSリージョンの管理](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)」で説明されているように、これらのリージョンを使用する前に、それらを有効にするか、オプトインする必要があります。
AWSリージョンに応じてアプローチを選択します。
+ デフォルトリージョンの場合は、「[デフォルトリージョンの .rdb ファイルへの読み取りアクセス権を ElastiCache に付与する](#backups-seeding-redis-default-region)」の手順を使用します。
+ オプトインリージョンの場合は、「[オプトインリージョンの .rdb ファイルへの ElastiCache の読み取りアクセス権を付与する](#backups-seeding-opt-in-region)」の手順を使用します。
### デフォルトリージョンの .rdb ファイルへの読み取りアクセス権を ElastiCache に付与する
AWS 2019 年 3 月 20 日より前に導入されたリージョンは、デフォルトで有効になっています。これらのAWSリージョンですぐに作業を開始できます。2019 年 3 月 20 日以降に導入されたアジアパシフィック (香港) および中東 (バーレーン) などのリージョンは、デフォルトで無効になっています。*AWS 全般のリファレンス* の「[AWSリージョンの管理](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)」で説明されているように、これらのリージョンを使用する前に、それらを有効にするか、オプトインする必要があります。
**デフォルトで有効になっているAWSリージョンのバックアップファイルへの読み取りアクセスを ElastiCache に付与するには**
1. にサインインAWS マネジメントコンソールし、[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 つがユーザーとして表示されていない場合は、以下の作業を行います。
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. **[概要]** を選択し、**[ダウンロード]** を選択します。
### オプトインリージョンの .rdb ファイルへの ElastiCache の読み取りアクセス権を付与する
AWS 2019 年 3 月 20 日より前に導入されたリージョンは、デフォルトで有効になっています。これらのAWSリージョンですぐに作業を開始できます。2019 年 3 月 20 日以降に導入されたアジアパシフィック (香港) および中東 (バーレーン) などのリージョンは、デフォルトで無効になっています。*AWS 全般のリファレンス* の「[AWSリージョンの管理](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)」で説明されているように、これらのリージョンを使用する前に、それらを有効にするか、オプトインする必要があります。
ここで、.rdb バックアップファイルへの読み取りアクセス権を ElastiCache に付与します。
**バックアップファイルへの読み込みアクセスを ElastiCache に許可するには**
1. にサインインAWS マネジメントコンソールし、[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 に付与します。
+ `Principal` に `[ "Service" : "region-full-name.elasticache-snapshot.amazonaws.com" ]` を追加します。
+ スナップショットを 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. **[Save changes]** (変更の保存) をクリックします。
### .rdb ファイルのデータで ElastiCache クラスターをシードする
これで ElastiCache クラスターを作成し、.rdb ファイルのデータと提携する準備が整いました。クラスターを作成するには、「[Valkey または Redis OSS 用のクラスターの作成](Clusters.Create.md)」または「[Valkey または Redis OSS レプリケーショングループを最初から作成する](Replication.CreatingReplGroup.NoExistingCluster.md)」の手順に従います。Valkey または Redis OSS がクラスターエンジンとして選択されていることを確認してください。
ElastiCache に、Amazon S3 にアップロードしたバックアップの場所を伝す方法は、クラスターを作成する方法によって異なります。
**.rdb ファイルのデータで ElastiCache for Redis OSS クラスターまたはレプリケーショングループをシードする**
+ **ElastiCache コンソールの使用**
**[Cluster settings]** (クラスター設定) を選択するときは、クラスターの作成方法として **[Restore from backups]** (バックアップから復元) を選択し、次に **[Backup source]** (バックアップソース) セクションで **[Source]** (ソース) として **[Other backups]** (その他のバックアップ) を選択します。**[シード 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 コンソールを参照し、[**キャッシュイベント**] を選択します。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/ja_jp/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Memcached**
Memcached では、クラスターのバージョンアップグレードを開始するには、クラスターを変更し、新しいエンジンバージョンを指定します。これを行うには、ElastiCache コンソールのAWS CLI、または ElastiCache API を使用します。
+ AWS マネジメントコンソール を使用するには、「[ElastiCache AWS マネジメントコンソール の使用](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～60 秒間のフェイルオーバーが発生することがあります。
既存の 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～60 秒長くなることがあります。
### 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/ja_jp/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 および高の評価を受けた 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 の標準サポート終了日と延長サポート終了日の詳細については、「[Redis OSS 用の ElastiCache バージョンのサポート終了スケジュール](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 標準サポート終了日を過ぎたメジャーバージョンを実行しているキャッシュを削除します。
将来、ターゲットエンジンバージョンが延長サポートに移行すると、料金が再び発生します。
例えば、Redis OSS 用の ElastiCache バージョン 4 が 2026 年 2 月 1 日に延長サポートに移行し、2027 年 1 月 1 日に v4 のキャッシュを v6 にアップグレードするとします。この場合、料金が発生するのは、Redis OSS 用の ElastiCache バージョン 4 の 11 か月間の延長サポートに対してのみです。2027 年 1 月 31 日の標準サポート終了日を過ぎた Redis OSS 用の ElastiCache バージョン 6 を引き続き実行する場合、それらのキャッシュには 2027 年 2 月 1 日から延長サポートの料金が再び発生します。
ElastiCache が ElastiCache 標準サポート終了日を過ぎたキャッシュを作成または復元しないように、ElastiCache 延長サポートの料金が発生するのを回避できます。
詳細については、「[Amazon ElastiCache 料金表](https://aws.amazon.com/elasticache/pricing/)」を参照してください。
# ElastiCache 延長サポートが適用されるバージョン
Redis オープンソースソフトウェア (OSS) バージョン 4 と 5 は、それぞれ 2020 年と 2022 年にコミュニティのサポート終了 (EOL) を迎えました。つまり、コミュニティによる追加のアップデート、バグ修正、またはセキュリティパッチのリリースが行われないということです。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 のキャッシュを Valkey と Redis OSS v6 に対応した ElastiCache にアップグレードすることを強くお勧めします。
次の表は、Amazon ElastiCache の標準サポート終了日と延長サポート終了日をまとめたものです。
**延長サポートとサポート終了 (EOL) のスケジュール**
| メジャーエンジンバージョン | 標準サポート終了日 | 延長サポート Y1 プレミアムの開始日 | 延長サポート Y2 プレミアムの開始日 | 延長サポート Y3 プレミアムの開始日 | 延長サポートの終了日とバージョンの EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 2026/1/31 | 2026/2/1 | 2027/2/1 | 2028/2/1 | 1/31/2029 |
| Redis OSS v5 | 2026/1/31 | 2026/2/1 | 2027/2/1 | 2028/2/1 | 1/31/2029 |
| Redis OSS v6 | 1/31/2027 | 2027/2/1 | 2028/2/1 | 2029/2/1 | 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 の責任と、延長サポートに関する顧客の責任は次のとおりです。
**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 クラスターが 1 つ以上のリージョンにレプリケートされている場合、エンジンバージョンはセカンダリリージョンでアップグレードされてから、プライマリリージョンでアップグレードされます。
ElastiCache for Redis OSS のバージョンは、メジャーコンポーネントとマイナーコンポーネントで構成されるセマンティックバージョンで識別されます。例えば、Redis OSS 6.2 では、メジャーバージョンは 6、マイナーバージョンは 2 です。ノードベースのクラスターを操作する場合、ElastiCache for Redis OSS は Redis OSS 6.2.1 などの PATCH コンポーネントも公開します。パッチバージョンは 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 サーバーレスキャッシュは、Valkey 用の ElastiCache バージョン 7.2 以降、Memcached 用の ElastiCache バージョン 1.6 以降、Redis OSS 用の ElastiCache 7.0 以降をサポートしています。
ノードベースの ElastiCache クラスターは、Valkey 用の ElastiCache バージョン 7.2 以降、Memcached 用の ElastiCache バージョン 1.4.5 以降、Redis OSS 用の ElastiCache 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)
+ [Valkey 用の ElastiCache バージョン 7.2.6](#valkey-version-7.2.6)
### サポートされている Valkey バージョン
サポートされている Valkey バージョンは以下のとおりです。Valkey は、Redis OSS 用の ElastiCache バージョン 7.2 で使用できるほとんどの機能をデフォルトでサポートしています。
+ 5.0.6 より前のバージョンで ElastiCache クラスターをアップグレードすることもできます。関連するプロセスは同じですが、DNS の伝播中にフェイルオーバー時間が長くなる可能性があります (30 秒～1 分)。
+ 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. バックアップを使用して、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 以降にアップグレードする場合は、アップグレードプロセス中も、プライマリクラスターは引き続きサービスリクエストを処理できます。
複数のシャードを含むクラスターおよびレプリケーショングループは、次のように処理および修正されます。
+ すべてのシャードは並行して処理されます。シャードでは、いつでも 1 つのアップグレードオペレーションのみが実行されます。
+ 各シャードでは、プライマリが処理される前にすべてのレプリカが処理されます。シャードにレプリカが少ない場合、他のシャードのレプリカが処理を終了する前に、そのシャードのプライマリが処理されることがあります。
+ すべてのシャード間で、プライマリノードはシリーズで処理されます。一度にアップグレードできるプライマリノードは 1 つだけです。
+ 現在のクラスターまたはレプリケーショングループで暗号化が有効になっている場合、暗号化をサポートしていないエンジンバージョン (3.2.6 から 3.2.10 など) にアップグレードすることはできません。
**Memcached に関する考慮事項**
ノードベースの Memcached クラスターをアップグレードする際は、次の点を考慮してください。
+ エンジンのバージョニングは、パッチの適用方法をできる限り制御できるように設計されています。ただし、ElastiCache には、システムまたはキャッシュソフトウェアに重大なセキュリティ脆弱性が発生する可能性が低い場合に、お客様に代わってクラスターにパッチを適用するための権限あります。
+ Memcached エンジンでは永続性がサポートされていないため、そのエンジンバージョンのアップグレードは常に、クラスターのすべてのキャッシュデータを消去する破壊的なプロセスです。
### Valkey 用の ElastiCache バージョン 8.2
Valkey 8.2 で導入された新機能の一部を以下に示します (ElastiCache Valkey 8.1 との比較)。
+ [ベクトル検索](vector-search.md)のネイティブサポート。数十億の高次元ベクトル埋め込みの保存、インデックス作成、検索、更新をマイクロ秒単位の低レイテンシーでメモリ内で行うことができます。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。
Valkey 8.2 リリース、ベクトル検索の導入の詳細については、「[Valkey Search](https://github.com/valkey-io/valkey-search)」を参照してください。
### Valkey 用の ElastiCache バージョン 8.1
Valkey 8.1 で導入された新機能の一部を以下に示します (ElastiCache Valkey 8.0 との比較)。
+ [新しいハッシュテーブル](https://valkey.io/blog/new-hash-table/)の実装により、メモリオーバーヘッドが減少し、一般的なキー/値のパターンのメモリ使用量が最大 20% 低下します。
+ 新しいデータ型である [Bloom フィルター](https://valkey.io/topics/bloomfilters/)のネイティブサポートにより、Set データ型を使用する場合と比較して最大 98% 少ないメモリを使用してルックアップを実行できます。
+ 新しいコマンド [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 Release Notes](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)」を参照してください
### Valkey 用の ElastiCache バージョン 8.0
Valkey 8.0 で導入された新機能の一部を以下に示します (ElastiCache Valkey 7.2.6 との比較)。
+ メモリ効率が向上し、ユーザーはアプリケーションを変更せずに 1 ノードあたり最大 20% 多くのデータを保存できます。
+ ノードベースのクラスター用に新しく導入されたスロットごとのメトリクスインフラストラクチャにより、個々のスロットのパフォーマンスとリソース使用状況を詳細に可視化できます。
+ ElastiCache Serverless for Valkey 8.0 では、サポートされる 1 秒あたりのリクエスト数 (RPS) を 2～3 分おきに 2 倍に拡張でき、キャッシュあたりの RPS は 13 分も経たないうちにゼロから 5 万 RPS に達します。p50 の読み取りレイテンシーも一貫してミリ秒未満を維持します。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。
Valkey 8 リリースの詳細については、「[Valkey 8 Release Notes](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)」を参照してください
### Valkey 用の ElastiCache バージョン 7.2.6
2024 年 10 月 10 日、Valkey 用の ElastiCacheバージョン 7.2.6 がリリースされました。7.2 で導入された新機能の一部を以下に示します (Redis OSS 用の ElastiCache バージョン 7.1 との比較)。
+ さまざまなデータ型のパフォーマンスとメモリの最適化: リストタイプキーとセットタイプキーのメモリ最適化、ソートされたセットに対するコマンドの速度最適化、クラスターモードでの複数のキーを持つコマンドのパフォーマンス最適化、pub/sub のパフォーマンス向上、SCAN、SSCAN、HSCAN、ZSCAN コマンドのパフォーマンス最適化、その他多くの小規模な最適化。
+ ZRANK コマンドと ZREVRANK コマンドの新しい WITHSCORE オプション
+ クライアントがキーの LRU/LFU に影響を与えることなくコマンドを実行するための CLIENT NO-TOUCH。
+ レプリケーションに基づいてクラスターモードでノードを論理的にグループ化するためにノードのシャード ID を返す、新しいコマンド CLUSTER MYSHARDID。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。
Valkey 用の ElastiCache バージョン 7.2 リリースの詳細については、「[Redis OSS 7.2.4 Release Notes](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES)」を参照してください (Valkey 用の ElastiCache バージョン 7.2 には、Redis OSS 用の ElastiCache バージョン 7.1 から Redis OSS 用の ElastiCache バージョン 7.2.4 までのすべての変更が含まれています)。GitHub 上の Valkey の「[Valkey 7.2 release notes](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES)」。
## Valkey 用の ElastiCache バージョン 8.2
Valkey 8.2 で導入された新機能の一部を以下に示します (ElastiCache Valkey 8.1 との比較)。
+ [ベクトル検索](vector-search.md)のネイティブサポート。数十億の高次元ベクトル埋め込みの保存、インデックス作成、検索、更新をマイクロ秒単位の低レイテンシーでメモリ内で行うことができます。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。
Valkey 8.2 リリース、ベクトル検索の導入の詳細については、「[Valkey Search](https://github.com/valkey-io/valkey-search)」を参照してください。
## Valkey 用の ElastiCache バージョン 8.1
Valkey 8.1 で導入された新機能の一部を以下に示します (ElastiCache Valkey 8.0 との比較)。
+ [新しいハッシュテーブル](https://valkey.io/blog/new-hash-table/)の実装により、メモリオーバーヘッドが減少し、一般的なキー/値のパターンのメモリ使用量が最大 20% 低下します。
+ 新しいデータ型である [Bloom フィルター](https://valkey.io/topics/bloomfilters/)のネイティブサポートにより、Set データ型を使用する場合と比較して最大 98% 少ないメモリを使用してルックアップを実行できます。
+ 新しいコマンド [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 Release Notes](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)」を参照してください
## Valkey 用の ElastiCache バージョン 8.0
Valkey 8.0 で導入された新機能の一部を以下に示します (ElastiCache Valkey 7.2.6 との比較)。
+ メモリ効率が向上し、ユーザーはアプリケーションを変更せずに 1 ノードあたり最大 20% 多くのデータを保存できます。
+ ノードベースのクラスター用に新しく導入されたスロットごとのメトリクスインフラストラクチャにより、個々のスロットのパフォーマンスとリソース使用状況を詳細に可視化できます。
+ ElastiCache Serverless for Valkey 8.0 では、サポートされる 1 秒あたりのリクエスト数 (RPS) を 2～3 分おきに 2 倍に拡張でき、キャッシュあたりの RPS は 13 分も経たないうちにゼロから 5 万 RPS に達します。p50 の読み取りレイテンシーも一貫してミリ秒未満を維持します。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。
Valkey 8 リリースの詳細については、「[Valkey 8 Release Notes](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)」を参照してください
## Valkey 用の ElastiCache バージョン 7.2.6
2024 年 10 月 10 日、Valkey 用の ElastiCacheバージョン 7.2.6 がリリースされました。7.2 で導入された新機能の一部を以下に示します (Redis OSS 用の ElastiCache バージョン 7.1 との比較)。
+ さまざまなデータ型のパフォーマンスとメモリの最適化: リストタイプキーとセットタイプキーのメモリ最適化、ソートされたセットに対するコマンドの速度最適化、クラスターモードでの複数のキーを持つコマンドのパフォーマンス最適化、pub/sub のパフォーマンス向上、SCAN、SSCAN、HSCAN、ZSCAN コマンドのパフォーマンス最適化、その他多くの小規模な最適化。
+ ZRANK コマンドと ZREVRANK コマンドの新しい WITHSCORE オプション
+ クライアントがキーの LRU/LFU に影響を与えることなくコマンドを実行するための CLIENT NO-TOUCH。
+ レプリケーションに基づいてクラスターモードでノードを論理的にグループ化するためにノードのシャード ID を返す、新しいコマンド CLUSTER MYSHARDID。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。
Valkey 用の ElastiCache バージョン 7.2 リリースの詳細については、「[Redis OSS 7.2.4 Release Notes](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES)」を参照してください (Valkey 用の ElastiCache バージョン 7.2 には、Redis OSS 用の ElastiCache バージョン 7.1 から Redis OSS 用の ElastiCache バージョン 7.2.4 までのすべての変更が含まれています)。GitHub 上の Valkey の「[Valkey 7.2 release notes](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES)」。
## サポートされる Redis OSS エンジンのバージョン
ElastiCache サーバーレスキャッシュとノードベースのクラスターは、Redis OSS バージョン 7.1 以前のすべてのバージョンをサポートしています。
+ [Redis OSS 用の ElastiCache バージョン 7.1 (拡張)](#redis-version-7.1)
**Topics**
+ [Redis OSS 用の ElastiCache バージョン 7.1 (拡張)](#redis-version-7.1)
+ [Redis OSS 用の ElastiCache バージョン 7.0 (拡張)](#redis-version-7.0)
+ [Redis OSS 用の ElastiCache バージョン 6.2 (拡張)](#redis-version-6.2)
+ [Redis OSS 用の ElastiCache バージョン 6.0 (拡張)](#redis-version-6.0)
+ [Redis OSS 用の ElastiCache バージョン 5.0.6 (拡張)](#redis-version-5-0.6)
+ [Redis OSS 用の ElastiCache バージョン 5.0.5 (廃止、バージョン 5.0.6 を使用してください)](#redis-version-5-0.5)
+ [Redis OSS 用の ElastiCache バージョン 5.0.4 (廃止、バージョン 5.0.6 を使用してください)](#redis-version-5-0.4)
+ [Redis OSS 用の ElastiCache バージョン 5.0.3 (廃止、バージョン 5.0.6 を使用してください)](#redis-version-5-0.3)
+ [Redis OSS 用の ElastiCache バージョン 5.0.0 (廃止、バージョン 5.0.6 を使用してください)](#redis-version-5-0)
+ [Redis OSS 用の ElastiCache バージョン 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)
### Redis OSS 用の ElastiCache バージョン 7.1 (拡張)
このリリースには、ワークロードのスループットを向上させ、操作のレイテンシーを低減するためのパフォーマンスの改善が含まれています。Redis OSS 用の ElastiCache バージョン 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 スレッド機能を拡張して、プレゼンテーション層のロジックも処理できるようにしました。プレゼンテーション層とは、クライアント入力を読み取るだけでなく、入力を Redis OSS バイナリコマンド形式に解析する拡張 I/O スレッドを指します。その後、これがメインスレッドに転送されて実行され、パフォーマンスが向上します。Redis OSS のメモリアクセスパターンが改善されました。多くのデータ構造操作の実行ステップをインターリーブすることで、並列メモリアクセスとメモリアクセスのレイテンシーの短縮を実現しています。Graviton3 ベースの `R7g.4xlarge` 以上で ElastiCache を実行する場合、お客様はノードあたり毎秒 100 万件を超えるリクエストを処理できます。ElastiCache for Redis OSS v7.1 のパフォーマンスが向上したことで、ElastiCache for Redis OSS v7.0 と比較してスループットが最大 100% 向上し、P99 のレイテンシーを 50% 低減できます。これらの機能強化は、CPU タイプに関係なく、物理コアが 8 個以上 (Graviton では `2xlarge`、x86 では `4xlarge`) のノードサイズで有効になり、クライアントを変更する必要がありません。
**注記**
ElastiCache v7.1 は OSS Redis OSS v7.0 と互換性があります。
### Redis OSS 用の ElastiCache バージョン 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 で、次期バージョンの Redis アクセスコントロールリスト (ACL) のサポートが追加されました。クライアントは Valkey および Redis OSS の特定のキーまたはキースペースに対して複数の権限セットを指定できるようになりました。
+ [シャードされた Pub/Sub](https://valkey.io/topics/pubsub/): ElastiCache for Valkey 7 と ElastiCache for Redis OSS 7 では、クラスターモード有効 (CME) で ElastiCache を実行する際に、Pub/Sub 機能をシャードされた方法で実行するサポートが追加されました。Pub/Sub 機能により、パブリッシャーはチャネル上の任意の数のサブスクライバーにメッセージを発行できます。チャネルは ElastiCache クラスターのシャードにバインドされるため、シャード間でチャネル情報を伝達する必要がなくなり、スケーラビリティが向上します。
+ 拡張 I/O 多重化: ElastiCache for Valkey 7 と ElastiCache for Redis OSS 7 では、拡張された I/O 多重化が導入されています。これにより、ElastiCache クラスターへの多数の同時クライアント接続がある高スループットワークロードのスループットが向上し、レイテンシーが低減されます。例えば、r6g.xlarge ノードのクラスターを使用し、5200 の同時クライアントを実行する場合、Redis OSS 用の ElastiCache バージョン 6 と比較して、スループット (1 秒あたりの読み取りおよび書き込みオペレーション) が最大 72% 向上し、P99 レイテンシーが最大 71% 減少します。
Valkey の詳細については、「[Valkey](https://valkey.io/)」を参照してください。Redis OSS 7.0 のリリースの詳細については、GitHub の Redis OSS の「[Redis OSS 7.0 Release Notes](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES)」を参照してください。
### Redis OSS 用の ElastiCache バージョン 6.2 (拡張)
ElastiCache for Redis OSS 6.2 では、8 個以上の vCPU を持つ x86 ノードタイプ、または 4 個以上の vCPU を持つ Graviton2 ノードタイプを使用した TLS 対応クラスターのパフォーマンスが向上しています。これらの機能強化では、暗号化を他の vCPUs にオフロードすることでスループットが向上し、クライアントの接続確立時間が短縮されました。Redis OSS 6.2 では、アクセスコントロールリスト (ACL) ルールを使用して Pub/Sub チャネルへのアクセスを管理することもできます。
このバージョンでは、ローカルに接続された NVMe SSD を含む、クラスターノードでのデータ階層化のサポートも導入されています。詳細については、「[ElastiCache のデータ階層化](data-tiering.md)」を参照してください。
Redis OSS エンジンバージョン 6.2.6 では、ネイティブ JavaScript Object Notation (JSON) 形式のサポートも導入されています。これは、Redis OSS クラスター内の複雑なデータセットをエンコードするシンプルでスキーマレスな方法です。JSON サポートにより、JSON 上で動作するアプリケーションのパフォーマンスと Redis OSS API を活用できます。詳細については、「[JSON の使用開始](json-gs.md)」を参照してください。また、JSON 関連のメトリクス `JsonBasedCmds` および `JsonBasedCmdsLatency` も含まれています。これらは、このデータ型の使用状況を監視するために CloudWatch に組み込まれています。詳細については、「[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 クラスターの場合、`CreateCacheCluster`、`ModifyCacheCluster`、`CreateReplicationGroup`、または `ModifyReplicationGroup` APIで `AutoMinorVersionUpgrade` パラメータを `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 Release Notes](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES)」を参照してください。
### Redis OSS 用の ElastiCache バージョン 6.0 (拡張)
Amazon ElastiCache では、Redis OSS エンジン向け ElastiCache の次のバージョンが導入されています。これには、[ロールベースのアクセスコントロールによるユーザーの認証](Clusters.RBAC.md)、クライアント側のキャッシュ、および大幅な運用上の改善が含まれます。
Redis OSS 6.0 以降、ElastiCache では、複数のパッチバージョンを提供するのではなく、Redis OSS マイナーリリースごとに 1 つのバージョンが提供されます。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 Release Notes](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES)」を参照してください。
### Redis OSS 用の ElastiCache バージョン 5.0.6 (拡張)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のバージョンが導入されています。これにはバグ修正および以下の累積更新が含まれます。
+ 特別な状況におけるエンジンの安定性の保証。
+ Hyperloglog エラー処理の強化。
+ 信頼性の高いレプリケーションを目的としたハンドシェイクコマンドの強化。
+ `XCLAIM` コマンドを使用した一貫性のあるメッセージ配信の追跡。
+ オブジェクトの `LFU ` フィールド管理の強化。
+ `ZPOP` 使用時のトランザクション管理の強化。
+ コマンドの名前を変更する機能: `rename-commands` と呼ばれるパラメータを使用すると、`FLUSHALL` や `FLUSHDB` など、誤ってデータ損失を発生させることがある、危険または処理負荷が大きい可能性がある Redis OSS コマンドの名前を変更できます。これは、オープンソース Redis OSS の名前変更コマンドの設定と似ています。ただし、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) から 2 つの重要なバグ修正をバックポートしました。以下に示します。
特定のキーの有効期限がすでに切れている場合、RESTORE が返信に一致しません。
`XCLAIM` コマンドは、間違ったエントリを返したり、プロトコルを同期解除したりすることがあります。
これらのバグ修正はどちらも Redis OSS エンジンバージョン 5.0.0 の ElastiCache for Redis OSS サポートに含まれており、将来のバージョン更新で使用されます。
詳細については、GitHub の Redis OSS の「[Redis OSS 5.0.6 Release Notes](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)」を参照してください。
### Redis OSS 用の ElastiCache バージョン 5.0.5 (廃止、バージョン 5.0.6 を使用してください)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のバージョンが導入されています。これには、計画されたすべてのオペレーション中の自動フェイルオーバークラスターの ElastiCache のオンライン構成変更が含まれます。クラスターがオンライン状態のままで着信リクエストの処理を継続する間、クラスターをスケールし、Redis OSS エンジンのバージョンをアップグレードして、パッチとメンテナンス更新を適用できるようになりました。また、バグ修正も含まれます。
詳細については、GitHub の Redis OSS の「[Redis OSS 5.0.5 Release Notes](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)」を参照してください。
### Redis OSS 用の ElastiCache バージョン 5.0.4 (廃止、バージョン 5.0.6 を使用してください)
Amazon ElastiCache では、ElastiCache でサポートされている Redis OSS エンジンの次のバージョンが導入されています。これには以下の機能強化が含まれています。
+ 特別な状況におけるエンジンの安定性の保証。
+ Hyperloglog エラー処理の強化。
+ 信頼性の高いレプリケーションを目的としたハンドシェイクコマンドの強化。
+ `XCLAIM` コマンドを使用した一貫性のあるメッセージ配信の追跡。
+ オブジェクトの `LFU ` フィールド管理の強化。
+ `ZPOP` 使用時のトランザクション管理の強化。
詳細については、GitHub の Redis OSS の「[Redis OSS 5.0.4 Release Notes](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES)」を参照してください。
### Redis OSS 用の ElastiCache バージョン 5.0.3 (廃止、バージョン 5.0.6 を使用してください)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のバージョンが導入されています。これにはバグ修正が含まれます。
### Redis OSS 用の ElastiCache バージョン 5.0.0 (廃止、バージョン 5.0.6 を使用してください)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のメジャーバージョンが導入されています。Redis OSS 用の ElastiCache バージョン 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 ノードのスナップショット時間がわずかに短縮。
### Redis OSS 用の ElastiCache バージョン 4.0.10 (拡張)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のメジャーバージョンが導入されています。Redis OSS 用の ElastiCache バージョン 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 で検索)。
+ オンライン中のメモリのデフラグメンテーションのサポート。これにより、メモリの使用が効率的になり、データに使用できるメモリが増えます。
+ 非同期フラッシュと削除のSupport。ElastiCache for Redis OSS は、`UNLINK`、`FLUSHDB` および `FLUSHALL` などのコマンドをメインスレッドとは異なるスレッドで実行することをサポートします。これにより、メモリが非同期的に解放されて、アプリケーションのパフォーマンスが上がり、レスポンス時間が短くなります。
+ 新しい Redis OSS メトリクス `ActiveDefragHits`。詳細については、「[Redis OSS のメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html)」を参照してください。
Redis OSS 用の ElastiCache バージョン 3.2.10 を実行している Redis OSS (クラスターモードが無効) ユーザーは、コンソールを使用して、オンラインアップグレードを介してクラスターをアップグレードできます。
**ElastiCache クラスターのサイズ変更と暗号化サポートの比較**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/engine-versions.html)
### 過去のサポート終了 (EOL) バージョン (3.x)
#### Redis OSS 用の ElastiCache バージョン 3.2.10 (拡張)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のメジャーバージョンが導入されています。Redis OSS 用の ElastiCache バージョン 3.2.10 (拡張) でオンラインのクラスターサイズ変更が導入されました。これにより、クラスターが受信 I/O リクエストを処理する間に、クラスターからシャードを追加または削除することができます。ElastiCache for Redis OSS 3.2.10 のユーザーは、データの暗号化機能を除き、Redis OSS の以前のバージョンのすべての機能を利用できます。この機能は現在、バージョン 3.2.6 でのみ使用できます。
**Redis OSS 用の ElastiCache バージョン 3.2.6 と 3.2.10 の比較**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/engine-versions.html)
詳細については次を参照してください:
+ [Valkey または Redis OSS (クラスターモードが有効) のオンラインリシャーディング](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [オンラインクラスターのサイズ変更](best-practices-online-resharding.md)
#### Redis OSS 用の ElastiCache バージョン 3.2.6 (拡張)
Amazon ElastiCache では、Redis OSS エンジン用の ElastiCache の次のメジャーバージョンが導入されています。Redis OSS 用の ElastiCache バージョン 3.2.6 のユーザーは、Redis OSS の以前のバージョンのすべての機能に加え、データの暗号化オプションを利用できます。詳細については次を参照してください:
+ [ElastiCache の転送時の暗号化 (TLS)](in-transit-encryption.md)
+ [ElastiCache での保管時の暗号化](at-rest-encryption.md)
+ [Amazon ElastiCache のコンプライアンス検証](elasticache-compliance.md)
#### Redis OSS 用の ElastiCache バージョン 3.2.4 (拡張)
Amazon ElastiCache バージョン 3.2.4 では、Redis OSS エンジン用の ElastiCache の次のメジャーバージョンが導入されています。ElastiCache 3.2.4 のユーザーは、以前のバージョンの Redis OSS で使用できるすべての機能に加え、*クラスターモード*または*非クラスターモード*で実行するオプションも利用できます。次の表に以下の内容がまとめてあります。
**Redis OSS 3.2.4 非クラスターモードとクラスターモードの比較**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/engine-versions.html)
**注記:**
+ [**パーティション**] – データを 2～500 のノードグループ間で分割 (シャード) (各ノードグループでレプリケーションのサポートあり)。
+ **[地理空間インデックス作成]** – Redis OSS 3.2.4 で、6 つの GEO コマンドによる地理空間インデックス作成のサポートが追加されました。詳細については、Valkey の「Commands」ページで Redis OSS GEO\$1 コマンドのドキュメント「[Commands: GEO](http://valkey.io/commands#geo)」(GEO でフィルタリング) を参照してください。
Redis OSS 3 の追加の機能については、「[Redis OSS 3.2 release notes](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES)」、「[Redis OSS 3.0 release notes](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)
#### Redis OSS 用の ElastiCache バージョン 2.8.24 (拡張)
Redis OSS バージョン 2.8.23 以降に追加された改善点には、バグ修正と不正なメモリアクセスアドレスのログ記録が含まれています。詳細については、「[Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)」を参照してください。
#### Redis OSS 用の ElastiCache バージョン 2.8.23 (拡張)
Redis OSS バージョン 2.8.22 以降に追加された改善点には、バグ修正が含まれます。詳細については、「[Redis OSS 2.8 release notes](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)」を参照してください。
#### Redis OSS 用の ElastiCache バージョン 2.8.22 (拡張)
Redis OSS バージョン 2.8.21 以降に追加された改善点には、以下が含まれます。
+ 分岐なしのバックアップと同期のサポートにより、バックアップオーバーヘッドによるメモリの割り当てを減らしてより多くのメモリをアプリケーションに割り当てることができます。詳細については、「[同期とバックアップの実装方法](Replication.Redis.Versions.md)」を参照してください。分岐なしのプロセスは、レイテンシーとスループットの両方に影響を与える場合があります。書き込みスループットが高い場合、レプリカが再同期されると、同期中はレプリカにアクセスできなくなることがあります。
+ フェイルオーバーが発生した場合、可能であれば、レプリカがフル同期ではなくプライマリとの部分同期を実行するため、レプリケーショングループはより迅速に復旧されます。さらに、プライマリとレプリカは同期中にディスクを使用しないため、速度が向上します。
+ が新しい CloudWatch メトリクスをサポート
+ `ReplicationBytes` – レプリケーショングループのプライマリクラスターがリードレプリカに送信しているバイト数。
+ `SaveInProgress` – バックグラウンド保存プロセスが実行されるかどうかを示すバイナリ値。
詳細については、「[CloudWatch メトリクスの使用状況のモニタリング](CacheMetrics.md)」を参照してください。
+ レプリケーション PSYNC 動作のいくつかの重要なバク修正。詳細については、「[Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)」を参照してください。
+ マルチ AZ レプリケーショングループのレプリケーションパフォーマンスの拡張とクラスターの安定性を維持するために、非 ElastiCache レプリカのサポートが終了しました。
+ レプリケーショングループのプライマリクラスターとレプリカ間でデータの整合性を改善するために、プライマリクラスターと無関係にレプリカでキーを削除できなくなりました。
+ Redis OSS 設定変数 `appendonly` および `appendfsync` は、Redis OSS バージョン 2.8.22 以降ではサポートされません。
+ メモリが少ない状況で、大きな出力アップロードバッファを持つクライアントはレプリカクラスターからの接続が解除されることがあります。接続が解除された場合、クライアントは再接続する必要があります。このような状況は、多くの場合 PUBSUB クライアントで発生する可能性があります。
#### Redis OSS 用の ElastiCache バージョン 2.8.21
Redis OSS バージョン 2.8.19 以降に追加された改善点には、多くのバグ修正が含まれています。詳細については、「[Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES)」を参照してください。
#### Redis OSS 用の ElastiCache バージョン 2.8.19
Redis OSS バージョン 2.8.6 以降に追加された改善点には、以下が含まれます。
+ HyperLogLog のサポート。詳細については、「[Redis OSS new data structure: HyperLogLog](http://antirez.com/news/75)」を参照してください。
+ ソートされたセットデータ型は、新しいコマンド `ZRANGEBYLEX`、`ZLEXCOUNT`、および `ZREMRANGEBYLEX` で、辞書式範囲のクエリをサポートできるようになりました。
+ プライマリノードがレプリカノードに古いデータを送信しないようにするため、バックグラウンド保存（`bgsave`）の子プロセスが中止された場合、マスター SYNC は失敗します。
+ *HyperLogLogBasedCommands* CloudWatch メトリクスがサポートされました。詳細については、「[Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)」を参照してください。
#### Redis OSS 用の ElastiCache バージョン 2.8.6
Redis OSS バージョン 2.6.13 以降に追加された改善点には、以下が含まれます。
+ リードレプリカの弾力性と耐障害性の向上。
+ 部分的な再同期のサポート。
+ 常に使用できる必要があるリードレプリカの最小数に関するユーザー定義のサポート。
+ pub/sub のフルサポートサーバー上のイベントをクライアントに通知。
+ プライマリノードの障害の自動検出と、プライマリノードからセカンダリノードへのフェイルオーバー。
#### Redis OSS 用の ElastiCache バージョン 2.6.13
Redis OSS 用の ElastiCache バージョン 2.6.13 は、Redis OSS をサポートした ElastiCache の最初のバージョンでした。Redis OSS 用の ElastiCache バージョン 2.6.13 では、マルチ AZ はサポートされません。
## Redis OSS 用の ElastiCache バージョンのサポート終了スケジュール
このセクションでは、発表された以前のメジャーバージョンのサポート終了 (EOL、End Of Life) 日を定義します。これにより、将来のバージョンとアップグレードに関する判断を行うことができます。
**注記**
Redis OSS 用の ElastiCache バージョン 5.0.0～5.0.5 は廃止されました。5.0.6 以降のバージョンを使用してください。
次の表は、ElastiCache for Redis OSS エンジンの[延長サポート](extended-support.md)のスケジュールを示しています。
**延長サポートとサポート終了 (EOL) のスケジュール**
| メジャーエンジンバージョン | 標準サポート終了日 | 延長サポート Y1 プレミアムの開始日 | 延長サポート Y2 プレミアムの開始日 | 延長サポート Y3 プレミアムの開始日 | 延長サポートの終了日とバージョンの EOL |
| --- | --- | --- | --- | --- | --- |
| 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**
+ [Memcached 用の ElastiCache バージョン 1.6.22](#memcached-version-1-6-22)
+ [Memcached 用の ElastiCache バージョン 1.6.17](#memcached-version-1-6-17)
+ [Memcached 用の ElastiCache バージョン 1.6.12](#memcached-version-1-6-12)
+ [Memcached 用の ElastiCache バージョン 1.6.6](#memcached-version-1-6-6)
+ [Memcached 用の ElastiCache バージョン 1.5.16](#memcached-version-1-5-16)
+ [Memcached 用の ElastiCache バージョン 1.5.10](#memcached-version-1-5-10)
+ [Memcached 用の ElastiCache バージョン 1.4.34](#memcached-version-1-4-34)
+ [Memcached 用の ElastiCache バージョン 1.4.33](#memcached-version-1-4-33)
+ [Memcached 用の ElastiCache バージョン 1.4.24](#memcached-version-1-4-24)
+ [Memcached 用の ElastiCache バージョン 1.4.14](#memcached-version-1-4-14)
+ [Memcached 用の ElastiCache バージョン 1.4.5](#memcached-version-1-4-5)
### Memcached 用の ElastiCache バージョン 1.6.22
Memcached 用の 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)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.6.17
Memcached 用の 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)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.6.12
Memcached 用の 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)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.6.6
Memcached 用の 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)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.5.16
Memcached 用の ElastiCache バージョン 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)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.5.10
Memcached 用の ElastiCache バージョン 1.5.10 では、以下の Memcached 機能がサポートされています。
+ 自動スラブ再分散。
+ `murmur3` アルゴリズムによる高速なハッシュテーブル参照。
+ セグメント化された LRU アルゴリズム。
+ メモリをバックグラウンドで回復するための LRU クローラ。
+ `--enable-seccomp`: コンパイル時オプション。
`no_modern` および `inline_ascii_resp` パラメータも導入されています。詳細については、「[Memcached 1.5.10 パラメータの変更](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10)」を参照してください。
Memcached 用の ElastiCache バージョン 1.4.34 以降に追加された Memcached の機能拡張には、以下が含まれます。
+ ASCII マルチ取得、CVE-2017-9951、`metadumper` の制限クロールなどの累積的修正。
+ 接続制限時に接続を閉じることにより接続管理を改善。
+ 1 MB を超えるアイテムサイズのアイテムサイズ管理を強化。
+ アイテムあたりのメモリ要件を数バイト下げることにより、パフォーマンスとメモリオーバーヘッドを改善。
詳細については、GitHub の Memcached で、「[Memcached 1.5.10 リリースノート](https://github.com/memcached/memcached/wiki/ReleaseNotes1510)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.4.34
Memcached 用の ElastiCache バージョン 1.4.34 では、バージョン 1.4.33 からの新機能の追加はありません。バージョン 1.4.34 は、通常のリリースよりも大きなバグ修正リリースです。
詳細については、GitHub の Memcached で、「[Memcached 1.4.34 リリースノート](https://github.com/memcached/memcached/wiki/ReleaseNotes1434)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.4.33
バージョン 1.4.24 以降に追加された機能拡張には、以下が含まれます。
+ 特定のスラブクラス、スラブクラスのリスト、またはすべてのスラブクラスのメタデータをダンプできる機能 詳細については、「[Memcached 1.4.31 リリースノート](https://github.com/memcached/memcached/wiki/ReleaseNotes1431)」を参照してください。
+ デフォルト値が 1 MB を超える大きなアイテムに対応 詳細については、「[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)」を参照してください。
### Memcached 用の ElastiCache バージョン 1.4.24
バージョン 1.4.14 以降に追加された機能拡張には、以下が含まれます。
+ バックグラウンドプロセスを使用した LRU (least recently used) の管理
+ ハッシュアルゴリズムとして使用する *jenkins* または *murmur3* のオプションを追加しました。
+ いくつかの新しいコマンドとパラメータ。リストについては、「[Memcached 1.4.24 で追加されたパラメータ](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24)」を参照してください。
+ 複数のバグ修正。
### Memcached 用の ElastiCache バージョン 1.4.14
バージョン 1.4.5 以降に追加された機能拡張には、以下が含まれます。
+ スラブ再分散機能の強化。
+ パフォーマンスとスケーラビリティの強化。
+ *touch* コマンドの導入により、既存の項目の有効期限を取得せずに更新する機能。
+ 自動検出—クライアントプログラムが、クラスター内のすべてのキャッシュノードを自動的に識別し、それらのすべてのノードへの接続を開始して維持する機能。
### Memcached 用の ElastiCache バージョン 1.4.5
Memcached 用の ElastiCache バージョン 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 非互換の変更用です
+ マイナーバージョンは、下位互換性のある方法で追加された新機能用です
+ パッチバージョンは、下位互換性のあるバグ修正と機能以外の変更用です
最新のパフォーマンスと安定性の向上のために、指定された **major.minor** バージョン内の最新のパッチバージョンを常に使用することをお勧めします。Redis OSS 用の ElastiCache バージョン 6.0 以降、ElastiCache では、複数のパッチバージョンを提供するのではなく、Redis OSS マイナーリリースごとに 1 つのバージョンが提供されます。ElastiCache は、実行中のクラスターのパッチバージョンを自動的に管理し、パフォーマンスの向上とセキュリティ強化を実現します。
また、ほとんどの主要な改善が古いバージョンにバックポートされないため、最新のメジャーバージョンに定期的にアップグレードすることをお勧めします。ElastiCache が新しいAWSリージョンに可用性を拡張すると、ElastiCache for Redis OSS は、その時点で新しいリージョンで最新の 2 つの **major.minor** バージョンをサポートしています。たとえば、新しいAWSリージョンが起動し、Redis OSS 用の最新の major.minor ElastiCache バージョンが **7.0** および **6.2** である場合、ElastiCache は新しいAWSリージョンで Redis OSS バージョン **7.0** および **6.2** をサポートします。ElastiCache for Redis OSS の新しい major.minor バージョンがリリースされるたびに、ElastiCache では新たにリリースされたバージョンに対するサポートが追加されます。ElastiCache のリージョンの選択について詳しくは、「[リージョンとアベイラビリティーゾーンの選択](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions)」を参照してください。
複数のメジャーバージョンまたはマイナーバージョンにまたがるアップグレードを行う場合は、次のリストを考慮してください。このリストには、時間の経過と共に Redis OSS でリリースされる動作と下位互換性のない変更が含まれています。
## Redis OSS 7.0 の動作および下位互換性のない変更
変更の詳細なリストについては、「[Redis OSS 7.0 release notes](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 release notes](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 release notes](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES)」を参照してください。
+ 許可されるデータベースの最大数は 120 万から 1 万に減少しました。デフォルト値は 16 です。パフォーマンスとメモリの懸念が見つかったため、これよりはるかに大きい値の使用はお勧めしません。
+ `AutoMinorVersionUpgrade` パラメータを yes に設定すると、ElastiCache ではセルフサービスの更新を通じてマイナーバージョンのアップグレードが管理されます。これは、セルフサービス更新キャンペーンを通じて、標準的な顧客通知チャネルを通じて処理されます。詳細については、「[ElastiCache でのセルフサービスの更新](Self-Service-Updates.md)」をご覧ください。
## Redis OSS 5.0 の動作および下位互換性のない変更
変更の詳細なリストについては、「[Redis OSS 5.0 release notes](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES)」を参照してください。
+ スクリプトは、レプリカでスクリプトを再実行するのではなく、効果によってレプリケートされます。これにより、一般にパフォーマンスは向上しますが、プライマリとレプリカの間でレプリケートされるデータ量が増える可能性があります。Redis OSS 用の ElastiCache バージョン 5.0 でのみ使用可能な以前の動作に戻すオプションがあります。
+ Redis OSS 4.0 からアップグレードする場合、LUA スクリプトの一部のコマンドは、以前のバージョンとは異なる順序で引数を返します。Redis OSS 4.0 では、Redis OSS は応答を確定的にするために一部の応答を辞書順に並べますが、スクリプトが操作の影響によって複製される場合、この並べ替えは適用されません。
+ Redis OSS 5.0.3 以降、ElastiCache for Redis OSS は、いくつかの IO 作業を 4 個以上の VCPU を持つインスタンスタイプのバックグラウンドコアにオフロードします。これにより、Redis OSS のパフォーマンス特性が変更され、一部のメトリクスの値が変更される可能性があります。詳細については、「[モニタリングすべきメトリクス](CacheMetrics.WhichShouldIMonitor.md)」を参照して、監視するメトリクスを変更する必要があるかどうかを理解してください。
## Redis OSS 4.0 の動作および下位互換性のない変更
変更の詳細なリストについては、「[Redis OSS 4.0 release notes](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES)」を参照してください。
+ スローログは、クライアント名とアドレスという追加の 2 つの引数をログに記録するようになりました。この変更は、3 つの値を含む各スローログエントリに明示的に依存しない限り、下位互換性があります。
+ `CLUSTER NODES` コマンドは、わずかに異なる形式を返すようになりましたが、これには下位互換性がありません。クライアントは、クラスタ内に存在するノードについて学習するためにこのコマンドを使用するのではなく、`CLUSTER SLOTS` を使用することをお勧めします。
## 過去の EOL
### Redis OSS 3.2 の動作および下位互換性のない変更
変更の詳細なリストについては、「[Redis OSS 3.2 release notes](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES)」を参照してください。
+ このバージョンでは、注意すべき互換性の変更はありません。
詳細については、「[Redis OSS 用の ElastiCache バージョンのサポート終了スケジュール](engine-versions.md#deprecated-engine-versions)」を参照してください。
### Redis OSS 2.8 の動作および下位互換性のない変更
変更の詳細なリストについては、「[Redis OSS 2.8 release notes](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 を返していました。
+ `STORE` オプションが使用されていない場合、`ALPHA` 付きの `SORT` はローカル照合ロケールに従ってソートされるようになりました。
詳細については、「[Redis OSS 用の ElastiCache バージョンのサポート終了スケジュール](engine-versions.md#deprecated-engine-versions)」を参照してください。
# ノードベースのクラスターを使用する際のアップグレードに関する考慮事項
**注記**
次の考慮事項は、ノードベースのクラスターをアップグレードする場合にのみ適用されます。ElastiCache サーバーレスには適用されません。
**Valkey と Redis OSS に関する考慮事項**
Valkey または Redis OSS のノードベースのクラスターをアップグレードする場合は、次の点を考慮してください。
+ エンジンのバージョニングは、パッチの適用方法をできる限り制御できるように設計されています。ただし、ElastiCache には、システムまたはキャッシュソフトウェアに重大なセキュリティ脆弱性が発生する可能性が低い場合に、お客様に代わってクラスターにパッチを適用するための権限あります。
+ Valkey 用の ElastiCache バージョン 7.2 以降および Redis OSS 用の ElastiCache バージョン 6.0 以降、ElastiCache では、複数のパッチバージョンを提供するのではなく、マイナーリリースごとに 1 つのバージョンが提供されます。
+ Redis OSS エンジンバージョン 5.0.6 以降では、最小限のダウンタイムでクラスターバージョンをアップグレードできます。このクラスターは、アップグレード中のすべての読み取りと、数秒かかるフェイルオーバー操作中を除き、ほとんどすべてのアップグレード中の書き込みに対応します。
+ 5.0.6 より前のバージョンで ElastiCache クラスターをアップグレードすることもできます。関連するプロセスは同じですが、DNS の伝播中にフェイルオーバー時間が長くなる可能性があります (30 秒～1 分)。
+ 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. バックアップを使用して、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 以降にアップグレードする場合は、アップグレードプロセス中も、プライマリクラスターは引き続きサービスリクエストを処理できます。
複数のシャードを含むクラスターおよびレプリケーショングループは、次のように処理および修正されます。
+ すべてのシャードは並行して処理されます。シャードでは、いつでも 1 つのアップグレードオペレーションのみが実行されます。
+ 各シャードでは、プライマリが処理される前にすべてのレプリカが処理されます。シャードにレプリカが少ない場合、他のシャードのレプリカが処理を終了する前に、そのシャードのプライマリが処理されることがあります。
+ すべてのシャード間で、プライマリノードはシリーズで処理されます。一度にアップグレードできるプライマリノードは 1 つだけです。
+ 現在のクラスターまたはレプリケーショングループで暗号化が有効になっている場合、暗号化をサポートしていないエンジンバージョン (3.2.6 から 3.2.10 など) にアップグレードすることはできません。
**Memcached に関する考慮事項**
ノードベースの Memcached クラスターをアップグレードする際は、次の点を考慮してください。
+ エンジンのバージョニングは、パッチの適用方法をできる限り制御できるように設計されています。ただし、ElastiCache には、システムまたはキャッシュソフトウェアに重大なセキュリティ脆弱性が発生する可能性が低い場合に、お客様に代わってクラスターにパッチを適用するための権限あります。
+ 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 サーバーレスを使用している場合や、リードレプリカ (ノードベースのクラスター) をプロビジョニングしている場合は、読み取りをレプリカに転送してスケーラビリティを向上し、レイテンシーを軽減させます。レプリカからの読み取りには、プライマリとの結果整合性があります。
ノードベースのクラスターでは、読み取りリクエストの転送先を単一のリードレプリカに限定しないでください。そのノードで障害が起きると、一時的に読み取りができなくなる可能性があります。読み取りリクエストを少なくとも 2 つのリードレプリカに転送するか、1 つのレプリカとプライマリに転送するようにクライアントを設定してください。
ElastiCache サーバーレスでは、レプリカポート (6380) からの読み取りは、可能な限りクライアントのローカルアベイラビリティーゾーンに転送されるため、取得レイテンシーが軽減されます。障害発生時には、自動的に他のノードにフォールバックします。
+ **コストの高いコマンドを避ける** – `KEYS` や `SMEMBERS` コマンドのような、計算コストが高いオペレーションや入出力量の多いオペレーションを避けてください。これらのオペレーションでは、クラスターへの負荷が増えてクラスターのパフォーマンスに影響するため、これらを避けるアプローチをお勧めします。代わりに、`SCAN` コマンドおよび `SSCAN` コマンドを使用します。
+ **Lua のベストプラクティスに従う** – 長時間実行する Lua スクリプトを避け、常に Lua スクリプトで使用されているキーを前に宣言します。Lua スクリプトがクロススロットコマンドを使用していないことを確認するために、この方法をお勧めします。Lua スクリプトで使用されるキーが同じスロットに属していることを確認します。
+ **シャードされた pub/sub を使用する** — 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 サーバーレスでのレプリカからの読み取りの使用
ElastiCache サーバーレスは、異なる整合性要件に対して 2 つの異なるエンドポイントを提供します。2 つのエンドポイントは同じ DNS 名を使用しますが、ポートは異なります。レプリカからの読み取りポートを使用するには、[VPC のセキュリティグループとネットワークアクセスコントロールリストを設定](set-up.md#elasticache-install-grant-access-VPN)して、クライアントアプリケーションから両方のポートへのアクセスを許可する必要があります。
**プライマリエンドポイント (ポート 6379)**
+ 即時整合性を必要とするオペレーションに使用する
+ 最新データの読み取りを保証する
+ 重要なトランザクションと書き込みオペレーションに最適
+ 書き込みオペレーションに必要
+ 例: `test-12345.serverless.use1.cache.amazonaws.com:6379`
**レイテンシー最適化エンドポイント (ポート 6380)**
+ 結果整合性を許容できる読み取りオペレーション用に最適化
+ 可能な場合、ElastiCache サーバーレスは読み取りリクエストをクライアントのローカルのアベイラビリティーゾーン内にあるレプリカノードに自動的にルーティングします。この最適化により、異なるアベイラビリティーゾーンのノードからデータを取得する際に発生する追加のネットワーク遅延を回避し、レイテンシーを低減することができます。
+ ElastiCache サーバーレスは、ローカルノードが利用できない場合、他のゾーンの利用可能なノードを自動的に選択します。
+ 例: `test-12345.serverless.use1.cache.amazonaws.com:6380`
+ Glide や Lettuce などのクライアントは、レプリカからの読み取り設定が指定された場合、自動的に読み取りを検出して、レイテンシー最適化エンドポイントにルーティングします。クライアントがルーティング設定をサポートしていない場合 (例: valkey-java や古いバージョンの jedis)、レプリカから読み取るための適切なポートとクライアント設定を定義する必要があります。
## ElastiCache サーバーレスでのリードレプリカへの接続 - Valkey と Glide
次のコードスニペットは、Valkey glide ライブラリで ElastiCache サーバーレスのレプリカからの読み取りを設定する方法を示しています。レプリカからの読み取りにポートを指定する必要はありませんが、ルーティング設定 `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`
ノードの状態に関する情報を返します。サーバーレスキャッシュでは、クライアントに公開されている 1 つの仮想「シャード」に関する状態を返します。
[詳細はこちら](https://valkey.io/commands/cluster-info/)
+ `CLUSTER KEYSLOT`
キーのハッシュスロットを返します。
[詳細はこちら](https://valkey.io/commands/cluster-keyslot/)
+ `CLUSTER MYID`
ノードの ID を返します。サーバーレスキャッシュでは、クライアントに公開されている 1 つの仮想「シャード」に関する状態を返します。
[詳細はこちら](https://valkey.io/commands/cluster-myid/)
+ `CLUSTER NODES`
ノードのクラスター構成を返します。サーバーレスキャッシュでは、クライアントに公開されている 1 つの仮想「シャード」に関する状態を返します。
[詳細はこちら](https://valkey.io/commands/cluster-nodes/)
+ `CLUSTER REPLICAS`
マスターノードのレプリカノードを一覧表示します。サーバーレスキャッシュでは、クライアントに公開されている 1 つの仮想「シャード」に関する状態を返します。
[詳細はこちら](https://valkey.io/commands/cluster-replicas/)
+ `CLUSTER SHARDS`
クラスタースロットとシャードのマッピングを返します。サーバーレスキャッシュでは、クライアントに公開されている 1 つの仮想「シャード」に関する状態を返します。
[詳細はこちら](https://valkey.io/commands/cluster-shards/)
+ `CLUSTER SLOTS`
クラスタースロットとノードのマッピングを返します。サーバーレスキャッシュでは、クライアントに公開されている 1 つの仮想「シャード」に関する状態を返します。
[詳細はこちら](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`
1 つまたは複数のキーを削除します。
[詳細はこちら](https://valkey.io/commands/del/)
+ `DUMP`
キーに格納されている値をシリアル化して返します。
[詳細はこちら](https://valkey.io/commands/dump/)
+ `EXISTS`
1 つまたは複数のキーが存在するかどうかを判定します。
[詳細はこちら](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`
1 つまたは複数のキーを非同期的に削除します。
[詳細はこちら](https://valkey.io/commands/unlink/)
**地理空間コマンド**
+ `GEOADD`
地理空間インデックスに 1 つまたは複数のメンバーを追加します。キーが存在しない場合はキーが作成されます。
[詳細はこちら](https://valkey.io/commands/geoadd/)
+ `GEODIST`
地理空間インデックスの 2 つのメンバー間の距離を返します。
[詳細はこちら](https://valkey.io/commands/geodist/)
+ `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`
1 つまたは複数のフィールドとその値をハッシュから削除します。フィールドが残っていない場合はハッシュを削除します。
[詳細はこちら](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`
ハッシュから 1 つまたは複数のランダムフィールドを返します。
[詳細はこちら](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`
1 つまたは複数の HyperLogLog 値を 1 つのキーにマージします。
[詳細はこちら](https://valkey.io/commands/pfmerge/)
**リストコマンド**
+ `BLMOVE`
リストから要素を取り出し、別のリストにプッシュして返します。要素が利用可能になるまでブロックします。最後の要素を移動した場合はリストを削除します。
[詳細はこちら](https://valkey.io/commands/blmove/)
+ `BLMPOP`
複数のリストのうちの 1 つから最初の要素を取り出します。要素が利用可能になるまでブロックします。最後の要素を取り出した場合はリストを削除します。
[詳細はこちら](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`
1 つまたは複数の要素をリストの先頭に追加します。キーが存在しない場合は、キーを作成します。
[詳細はこちら](https://valkey.io/commands/lpush/)
+ `LPUSHX`
リストが存在する場合のみ、1 つまたは複数の要素をリストの先頭に追加します。
[詳細はこちら](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`
1 つまたは複数の要素をリストに追加します。キーが存在しない場合は、キーを作成します。
[詳細はこちら](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`
サーバー側 Lua スクリプトを SHA1 ダイジェストで実行します。
[詳細はこちら](https://valkey.io/commands/evalsha/)
+ `EVALSHA_RO`
読み取り専用のサーバー側 Lua スクリプトを SHA1 ダイジェストで実行します。
[詳細はこちら](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 クラスターを使用する場合、すべてのキーをフラッシュするには、クライアントがすべてのプライマリにフラッシュコマンドを送信する必要があります。ElastiCache Serverless for Valkey と ElastiCache Serverless for Redis OSS は、基盤となるクラスタートポロジを抽象化するため、動作が異なります。その結果、ElastiCache Serverless では、`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`
1 つ、複数、またはすべてのコマンドに関するドキュメンタリー情報を返します。
[詳細はこちら](https://valkey.io/commands/command-docs/)
+ `COMMAND GETKEYS`
任意のコマンドからキー名を抽出します。
[詳細はこちら](https://valkey.io/commands/command-getkeys/)
+ `COMMAND GETKEYSANDFLAGS`
任意のコマンドのキー名とアクセスフラグを抽出します。
[詳細はこちら](https://valkey.io/commands/command-getkeysandflags/)
+ `COMMAND INFO`
1 つ、複数、またはすべてのコマンドに関する情報を返します。
[詳細はこちら](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`
集合に 1 つまたは複数のメンバーを追加します。キーが存在しない場合は、キーを作成します。
[詳細はこちら](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`
集合か 1 つまたは複数のメンバーをランダムに削除して返します。最後のメンバーを取り出した場合は集合を削除します。
[詳細はこちら](https://valkey.io/commands/spop/)
+ `SRANDMEMBER`
集合から 1 つまたは複数のメンバーをランダムに取得します。
[詳細はこちら](https://valkey.io/commands/srandmember/)
+ `SREM`
集合から 1 つまたは複数のメンバーを削除します。最後のメンバーを削除した場合は集合を削除します。
[詳細はこちら](https://valkey.io/commands/srem/)
+ `SSCAN`
集合のメンバーを反復処理します。
[詳細はこちら](https://valkey.io/commands/sscan/)
+ `SUNION`
複数の集合の和を返します。
[詳細はこちら](https://valkey.io/commands/sunion/)
+ `SUNIONSTORE`
複数の集合の和をキーに格納します。
[詳細はこちら](https://valkey.io/commands/sunionstore/)
**ソート対象集合コマンド**
+ `BZMPOP`
1 つまたは複数のソート対象集合からメンバーをスコアによって削除して返します。メンバーが使用可能になるまでブロックします。最後の要素を取り出した場合はソート対象集合を削除します。
[詳細はこちら](https://valkey.io/commands/bzmpop/)
+ `BZPOPMAX`
1 つまたは複数のソート対象集合からスコアの最も高いメンバーを削除して返します。メンバーが使用可能になるまでブロックします。最後の要素を取り出した場合はソート対象集合を削除します。
[詳細はこちら](https://valkey.io/commands/bzpopmax/)
+ `BZPOPMIN`
1 つまたは複数のソート対象集合からスコアの最も低いメンバーを削除して返します。メンバーが使用可能になるまでブロックします。最後の要素を取り出した場合はソート対象集合を削除します。
[詳細はこちら](https://valkey.io/commands/bzpopmin/)
+ `ZADD`
ソート対象集合に 1 つまたは複数のメンバーを追加するか、メンバーのスコアを更新します。キーが存在しない場合は、キーを作成します。
[詳細はこちら](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`
1 つまたは複数のソート対象集合から最高スコアまたは最低スコアのメンバーを削除して返します。最後のメンバーを取り出した場合はソート対象集合を削除します。
[詳細はこちら](https://valkey.io/commands/zmpop/)
+ `ZMSCORE`
ソート対象集合内の 1 つまたは複数のメンバーのスコアを返します。
[詳細はこちら](https://valkey.io/commands/zmscore/)
+ `ZPOPMAX`
1 つまたは複数のソート対象集合から最高スコアのメンバーを削除して返します。最後のメンバーを取り出した場合はソート対象集合を削除します。
[詳細はこちら](https://valkey.io/commands/zpopmax/)
+ `ZPOPMIN`
1 つまたは複数のソート対象集合から最低スコアのメンバーを削除して返します。最後のメンバーを取り出した場合はソート対象集合を削除します。
[詳細はこちら](https://valkey.io/commands/zpopmin/)
+ `ZRANDMEMBER`
ソート対象集合から 1 つまたは複数のランダムなメンバーを返します。
[詳細はこちら](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`
ソート対象集合から 1 つまたは複数のメンバーを削除します。すべてのメンバーを削除した場合、ソート対象集合を削除します。
[詳細はこちら](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`
1 つまたは複数のキーの文字列値をアトミックに返します。
[詳細はこちら](https://valkey.io/commands/mget/)
+ `MSET`
1 つまたは複数のキーの文字列値をアトミックに作成または変更します。
[詳細はこちら](https://valkey.io/commands/mset/)
+ `MSETNX`
1 つまたは複数のキーについて、どのキーも存在しない場合にのみ、その文字列値をアトミックに変更します。
[詳細はこちら](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 に制限されています。
+ 遅延した `flush_all` コマンドは `CLIENT_ERROR` で拒否されます。
+ エンジンを設定したり、エンジンの状態やログに関する内部情報を公開したりする次のようなコマンドはサポートされていません。
+ `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 パラメータが設定されています。
****
| 名前 | Details | 説明 |
| --- | --- | --- |
| acl-pubsub-default | `allchannels` | キャッシュ上の ACL ユーザーの、デフォルトの Pubsub チャネルのアクセス許可。 |
| client-output-buffer-limit | `normal 0 0 0` `pubsub 32mb 8mb 60` | 通常のクライアントにはバッファ制限はありません。PUB/SUB クライアントが 32 MiB のバックログに違反したり、8MiB のバックログに 60 秒間違反したりすると、接続が切断されます。 |
| client-query-buffer-limit | 1 GiB | 単一のクライアントクエリバッファのサイズ上限。さらに、クライアントは 3,999 個を超える引数でリクエストを発行することはできません。 |
| cluster-allow-pubsubshard-when-down | yes | これにより、キャッシュが部分的にダウンしていても、キャッシュは Pubsub トラフィックを処理できます。 |
| cluster-allow-reads-when-down | yes | これにより、キャッシュが部分的にダウンしていても、キャッシュは read トラフィックを処理できます。 |
| cluster-enabled | yes | サーバーレスキャッシュはすべてクラスターモードが有効になっているため、データを複数のバックエンドシャードに透過的にパーティション化できます。すべてのスロットは、単一の仮想ノードが所有するものとしてクライアントに表示されます。 |
| cluster-require-full-coverage | no | キースペースが部分的にダウンした場合 (つまり、少なくとも 1 つのハッシュスロットにアクセスできなくなった場合)、キャッシュはキースペースのうちまだカバーされている部分のクエリを受け付け続けます。キースペース全体は常に cluster slots 内の 1 つの仮想ノードによって「カバー」されます。 |
| 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 が設定されているアイテムは、キャッシュのメモリ制限に達すると、least-recently-used (LRU) の推定に従って削除されます。 |
| notify-keyspace-events | (空の文字列) | キースペースイベントは現在、サーバーレスキャッシュではサポートされていません。 |
| port | プライマリポート: 6379 読み取りポート: 6380 | サーバーレスキャッシュは、同じホスト名の 2 つのポートをアドバタイズします。プライマリポートは書き込みと読み取りを許可し、読み取りポートは READONLY コマンドを使用して低レイテンシーで最終的に一貫性のある読み取りを可能にします。 |
| proto-max-bulk-len | 512 MiB | 1 つの要素リクエストのサイズ上限。 |
| timeout | 0 | クライアントは特定のアイドル時に強制的に切断されることはありませんが、負荷分散のために定常状態では切断される場合があります。 |
さらに、次の制限があります。
****
| 名前 | Details | 説明 |
| --- | --- | --- |
| キャッシュあたりのサイズ | 5,000 GiB | サーバーレスキャッシュごとに保存できるデータの最大量。 |
| スロットあたりのサイズ | 32 GiB | 単一の Valkey または Redis OSS ハッシュスロットのサイズ上限。クライアントが 1 つの Valkey または Redis OSS スロットにこれよりも多くのデータを設定しようとすると、そのスロットのエビクションポリシーがトリガーされ、削除可能なキーがない場合はメモリ不足 (OOM) エラーが表示されます。 |
| キャッシュあたりの ECPU | 15,000,000 ECPU/秒 | ElastiCache 処理ユニット (ECPU) メトリクス。リクエストによって消費される ECPU の数は、要した vCPU 時間と転送されるデータの量によって異なります。 |
| スロットあたりの ECPU | 30,000～90,000 ECPU/秒 | READONLY 接続を使用してレプリカからの読み取りを使用する場合、スロットあたり最大 30,000 ECPU/秒または 90,000 ECPU/秒。 |
| リクエストあたりの引数 | 3,999 | リクエストあたりの引数の最大数。リクエストごとにこれ以上の引数を送信するクライアントはエラーを受け取ります。 |
| キー名の長さ | 4 KiB | 単一の Valkey または Redis OSS キーまたはチャネル名のサイズ上限。クライアントがこれよりも大きいキーを参照すると、エラーが発生します。 |
| Lua スクリプトのサイズ | 4 MiB | 単一の 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 Database Blog のブログ記事「[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.リリース](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;
```
このコードは、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) などのさまざまな言語でいくつも確認されています。
サーバーレスキャッシュでは、アドバタイズされるクラスタートポロジが静的であり、書き込みエンドポイントと読み取りエンドポイントの 2 つのエントリで構成されるため、こうした問題の多くは自動的に軽減されます。また、キャッシュエンドポイントを使用する場合、クラスター検出が自動的に複数のノードに分散されます。ただし、以下の推奨事項は引き続き有効です。
接続リクエストや検出リクエストが殺到した場合の影響を軽減するために、以下の対応を推奨します。
+ クライアントアプリケーションからの同時着信接続数を制限するために、有限サイズのクライアント接続プールを実装する。
+ タイムアウトによりクライアントがサーバーから切断された場合は、エクスポネンシャルバックオフとジッター(揺らぎ) を加えて再試行する。これにより、複数のクライアントが同時にサーバーに負荷をかける事態を阻止できます。
+ 「[ElastiCache での接続エンドポイントの検索](Endpoints.md)」のガイドを参考にして、クラスターエンドポイントを検索し、クラスター検出を実行する。これにより、クラスター内のハードコーディングされたいくつかのシードノードにアクセスする代わりに、検出の負荷をクラスター内のすべてのノード (最大 90 個) 間で分散できます。
redis-py、PHPRedis、Lettuce におけるエクスポネンシャルバックオフの再試行ロジックのコード例を以下に紹介します。
**バックオフロジックのサンプル 1: redis-py**
redis-py には、障害の発生直後に 1 回再試行する再試行メカニズムが組み込まれています。このメカニズムは、[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 回 (回数設定は不可) 再試行する再試行メカニズムが組み込まれています。試行間隔の遅延を設定できます (2 回目以降にジッターを加えます)。詳細については、[こちらのサンプルコード](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 には、[エクスポネンシャルバックオフとジッター](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 は 200 超のコマンドをサポートしており、その中には、Lua スクリプトを実行するコマンドもあります。ただし、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 スクリプトを避け、実稼働前の環境でスクリプトをテストしてください。
**ステルス書き込みを行う Lua スクリプト**
Valkey または Redis OSS が `maxmemory` を上回っても、Lua スクリプトが引き続き Valkey または Redis OSS に新しいデータを書き込むケースがいくつかあります。
+ Valkey または Redis OSS サーバーが `maxmemory` を下回っている場合にスクリプトが開始し、そのスクリプト内に複数の書き込みオペレーションが含まれている。
+ スクリプトの最初の書き込みコマンドはメモリを消費しないが (DEL など)、後続の複数の書き込みオペレーションがメモリを消費する。
+ Valkey または Redis OSS サーバーで `noeviction` 以外の適切なエビクションポリシーを設定することで、この問題を軽減できます。これにより、Redis OSS は Lua スクリプトの合間にアイテムを削除し、メモリを解放できます。
# 大きな複合アイテムの保存 (Valkey および Redis OSS)
状況によっては、アプリケーションが大きな複合アイテム (マルチ GB のハッシュデータセットなど) を Valkey または Redis OSS に保存することがあります。これは、Valkey または Redis OSS でパフォーマンスの問題が生じやすくなるため、原則としては推奨されません。例えば、クライアントは HGETALL コマンドを実行して、マルチ GB のハッシュコレクション全体を取得できます。この場合、クライアントの出力バッファに大きなアイテムがバッファリングされ、Valkey または Redis OSS サーバーに多大なメモリ負荷がかかる可能性があります。また、クラスターモードでのスロット移行では、ElastiCache はシリアル化されたサイズが 256 MB を超えるアイテムを含むスロットを移行しません。
大きいアイテムの問題を解決するために、以下の点を推奨します。
+ 大きな複合アイテムは複数の小さなアイテムに分割する。例えば、大きなハッシュコレクションを、そのコレクションを適切に反映したキー名スキームを使用して (アイテムのコレクションを識別する共通のプレフィックスをキー名に付けるなど)、個々のキーと値のフィールドに分割します。同じコレクション内の複数のフィールドにアトミックにアクセスする必要がある場合は、MGET コマンドを使用して、同一コマンドで複数のキーと値のペアを取得できます。
+ どの方法を検討しても大きなコレクションデータセットを分割できない場合は、コレクション全体ではなく、コレクション内のデータのサブセットを操作するコマンドを使用してみる。マルチ GB のコレクション全体を同一コマンドでアトミックに取得しなければならないようなユースケースは避けてください。ハッシュコレクションに対して HGETALL の代わりに HGET コマンドや HMGET コマンドを使用することが、その一例です。
# Lettuce クライアント設定 (Valkey および Redis OSS)
このセクションでは、推奨される Java と Lettuce の設定オプションと、それらを ElastiCache クラスターに適用する方法について説明します。
このセクションの推奨事項は、Lettuce バージョン 6.2.2 でテスト済みです。
**Topics**
+ [例: TLS が有効な場合のクラスターモードの Lettuce の設定](BestPractices.Clients-lettuce-cme.md)
+ [例: TLS が有効でクラスターモードが無効な場合の Lettuce の設定](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 名を使用するため、5～10 秒の低い TTL 値で JVM を設定することをお勧めします。これにより、ノードの IP アドレスが変更されたときに、アプリケーションは DNS エントリに対して再度クエリを実行することで、リソースの新しい IP アドレスを取得し、使用できるようになります。
一部の Java 設定では JVM のデフォルトの TTL が設定されるため、JVM が再起動されるまで、DNS エントリが更新されることはありません。
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 以降の使用をお勧めします。
**エンドポイント**。
クラスターモードが有効なクラスターを使用している場合は、`redisUri` をクラスター設定エンドポイントに設定します。この URI の DNS ルックアップは、クラスターで使用可能なすべてのノードのリストを返し、クラスターの初期化中にそれらのノードの 1 つにランダムに解決されます。トポロジ更新の仕組みの詳細については、このトピックで後述する「*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 を true に設定して使用するのが最適です。そうしないと、1 つの問題のあるシードノードからトポロジビューを取得すると、一部のシャードのプライマリノードに障害が発生していると見なされ、このプライマリノードは除外され、スロットがカバーされなくなります。(DynamicRefreshSources が true の場合に) 複数のシードノードが存在すると、この問題が発生する可能性が低くなります。これは、新しく昇格したプライマリとのフェイルオーバー後に、少なくとも一部のシードノードでトポロジビューを更新する必要があるためです。
**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--) が true の場合にのみ有効になります。有効にすると、クライアントは古い接続を閉じて新しい接続をバックグラウンドで作成できます。これにより、コマンドのランタイムに失敗した接続を処理する必要が減ります。
[dynamicRefreshResources](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#dynamicRefreshSources-boolean-) を有効にします。小規模なクラスターでは DynamicRefreshResources を有効にし、大規模なクラスターでは無効にすることをお勧めします。DynamicRefreshResources を使用すると、提供されたシードノード (クラスター構成エンドポイントなど) からクラスターノードを検出できます。検出されたすべてのノードを、クラスタートポロジを更新するためのソースとして使用します。
動的更新を使用すると、検出されたすべてのノードにクラスタートポロジを照会し、最も正確なクラスタービューを選択しようと試みます。false に設定すると、最初のシードノードのみがトポロジ検出のソースとして使用され、クライアント数は最初のシードノードについてのみ取得されます。無効になっている場合、クラスター設定エンドポイントが障害の発生したノードに解決されたとき、クラスタービューを更新しようとすると失敗し、例外が発生します。このシナリオは、障害が発生したノードのエントリがクラスター設定エンドポイントから削除されるまでに時間がかかるときに発生する可能性があります。そのため、設定エンドポイントは、障害が発生したノードに短期間ランダムに解決できます。
ただし、有効にすると、クラスタービューから受信したすべてのクラスターノードを使用して、現在のビューについてクエリを実行します。障害が発生したノードをそのビューから除外するので、トポロジ更新は成功します。ただし、dynamicRefreshSources が true の場合、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();
```
**Timeouts **
コマンドのタイムアウトよりも低い接続タイムアウト値を使用してください。Lettuce はレイジー接続確立を使用します。そのため、接続タイムアウトがコマンドタイムアウトよりも大きい場合、Lettuce が異常なノードへの接続を試みてコマンドのタイムアウトが常に超過すると、トポロジ更新後に障害が一定期間持続する可能性があります。
異なるコマンドに対しては動的コマンドタイムアウトを使用してください。コマンドの想定期間に基づいてコマンドタイムアウトを設定することをお勧めします。例えば、FLUSHDB、FLUSHALL、KEYS、SMEMBERS、Lua スクリプトなど、複数のキーを反復処理するコマンドにはタイムアウトを長く設定します。SET、GET、HSET など、1 つのキーコマンドではタイムアウトを短くします。
**注記**
次の例で設定されているタイムアウトは、最大 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();
```
# 例: TLS が有効な場合のクラスターモードの Lettuce の設定
**注記**
次の例のタイムアウトは、最大 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();
```
# 例: TLS が有効でクラスターモードが無効な場合の Lettuce の設定
**注記**
次の例のタイムアウトは、最大 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 クラスターでは、IP 検出パラメータを使用して、クライアントがクラスター内のノードに接続するために使用するプロトコルを制御できます。IP 検出パラメータは、IPv4 または IPv6 に設定できます。
Valkey または Redis クラスターの場合、IP 検出パラメータは、[クラスタースロット ()](https://valkey.io/commands/cluster-slots/)、[クラスターシャード ()](https://valkey.io/commands/cluster-shards/)、[クラスターノード ()](https://valkey.io/commands/cluster-nodes/) の出力で使用される IP プロトコルを設定します。これらのコマンドは、クライアントがクラスタートポロジを検出するために使用されます。クライアントは、これらのコマンドの IP を使用して、クラスター内の他のノードに接続します。
IP 検出を変更しても、接続しているクライアントのダウンタイムは発生しません。ただし、変更が反映されるまで時間がかかる場合があります。Valkey または Redis クラスターに変更が完全に伝播されたかどうかを判断するには、`cluster slots` の出力をモニタリングします。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～*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` を有効にすることをお勧めします。
詳細については、Memcached PHP の実行時設定に関するドキュメント ([http://php.net/manual/en/memcached.configuration.php](http://php.net/manual/en/memcached.configuration.php)) を参照してください。特に、`memcached.sess_consistent_hash` パラメータについて参照してください。
## Memcached で .NET を使用したコンシステントハッシュ
ElastiCache Memcached .NET クライアントは、Enyim Memcached のラッパーです。デフォルトでは、Enyim Memcached クライアントによって、整合性のあるハッシュが有効になります。
詳細については、`memcached/locator` のドキュメント ([https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration\$1user-content-memcachedlocator](https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration#user-content-memcachedlocator)) を参照してください。
# 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 検出パラメータを使用して、クライアントがクラスター内のノードに接続するために使用するプロトコルを制御できます。IP 検出パラメータは、IPv4 または IPv6 に設定できます。
IP 検出パラメータは、config get クラスター出力で使用される IP プロトコルを制御します。これにより、ElastiCache for Memcached クラスターの自動検出をサポートするクライアントで使用される IP プロトコルが決まります。
IP 検出を変更しても、接続しているクライアントのダウンタイムは発生しません。ただし、変更が反映されるまで時間がかかる場合があります。
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 検出が更新される前に作成された既存のクライアント接続は、引き続き古いプロトコルを使用して接続されます。クラスター検出コマンドの出力で変更が検出されると、検証されたすべてのクライアントは新しい IP プロトコルを使用してクラスターに自動的に再接続します。ただし、これはクライアントの実装によって異なります。
## TLS が有効なデュアルスタック ElastiCache クラスター
ElastiCache クラスターで TLS が有効になっている場合、クラスター検出関数 (Redis の場合は `cluster slots`、`cluster shards`、`cluster nodes`) または Memcached の場合は `config get cluster` は、IP ではなくホスト名を返します。次に、IP の代わりにホスト名を使用して ElastiCache クラスターに接続し、TLS ハンドシェイクを実行します。つまり、クライアントは IP 検出パラメータの影響を受けません。TLS が有効なクラスターでは、IP 検出パラメータは優先 IP プロトコルに影響しません。代わりに、使用する IP プロトコルは、DNS ホスト名を解決する際にクライアントがどの IP プロトコルを使用するかによって決まります。
**Java クライアント**
IPv4 と IPv6 の両方をサポートする Java 環境から接続する場合、後方互換性のために Java はデフォルトで IPv6 よりも IPv4 を優先します。ただし、IP プロトコルプリファレンスは JVM 引数を使用して設定できます。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 接続を優先するように優先設定ポリシーが更新されます。例えば、クラスターが 172.31.0.0:0/16 CIDR のサブネット内にあると仮定した場合、`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 の予約済みメモリを管理する
予約メモリは、nondata 用に確保されるメモリです。バックアップまたはフェイルオーバーを実行すると、Valkey および Redis OSS は、クラスターのデータが .rdb ファイルに書き込まれている間、クラスターへの書き込みオペレーションを記録するために使用可能なメモリを使用します。すべての書き込みに十分なメモリが使用可能できない場合、プロセスは失敗します。以下では、ElastiCache for Redis OSS の予約メモリを管理するためのオプションと、それらのオプションを適用する方法について説明します。
**Topics**
+ [予約メモリはどれくらい必要ですか。](#redis-memory-management-need)
+ [予約メモリを管理するパラメータ](#redis-memory-management-parameters)
+ [予約メモリ管理パラメータの指定](#redis-reserved-memory-management-change)
## 予約メモリはどれくらい必要ですか。
2.8.22 より前の Redis OSS バージョンを実行している場合、Redis OSS 2.8.22 以降を実行する場合より多くのメモリをバックアップとフェイルオーバーのために確保します。この要件は、ElastiCache for Redis OSS がバックアッププロセスを実装する方法の違いによるものです。目安として、2.8.22 より前のバージョンの Redis OSS オーバーヘッドではノードタイプの `maxmemory` 値の半分を、Redis OSS バージョン 2.8.22 以降では 4 分の 1 を確保します。
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 には `reserved-memory` と `reserved-memory-percent` という、Valkey または Redis OSS メモリを管理するための 2 つの相互に排他的なパラメータがあります。これらのパラメータのいずれも 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% がデータ以外の目的で予約されます。
2 つの 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)
### 予約メモリのパラメータ
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 クラスターのメモリを管理する方法を示します。
**予約メモリを使用してメモリを予約するには**
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
```
### 予約メモリパーセントパラメータ
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 パーセントで十分です。そうでない場合、次のステップを実行して、値を変更します。
+ 2.8.22 より前の Redis OSS のバージョンを実行している場合、`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. 2.8.22 より前の Redis OSS のバージョンを実行している Redis OSS クラスターまたはレプリケーショングループに対して、このカスタムパラメータグループを使用します。
次の CLI の例では、カスタムパラメータグループ `redis28-50` をすぐに使用するように Redis OSS クラスター `my-redis-cluster` を変更します。詳細については、「[ElastiCache クラスターの変更](Clusters.Modify.md)」を参照してください。
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
次の CLI の例では、カスタムパラメータグループ `redis28-50` をすぐに使用するように Redis OSS レプリケーショングループ `my-redis-repl-grp` を変更します。詳細については、「[レプリケーショングループの変更](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 ユーザーだった場合、デフォルトの予約済みメモリ管理パラメータは `reserved-memory` であり、予約されるメモリはゼロ (0) バイトです。2017 年 3 月 16 日よりも後に ElastiCache ユーザーになった場合、デフォルトの予約済みメモリ管理パラメータは `reserved-memory-percent` であり、ノードのメモリの 25 パーセントが予約されます。これは、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` を変更します。パラメータグループが予約メモリ管理に `ParameterName` パラメータを使用するには、`ParameterValue` に値を割り当てる必要があります。詳細については、「[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` を変更します。パラメータグループが予約メモリ管理に `ParameterName` パラメータを使用するには、`ParameterValue` に値を割り当てる必要があります。エンジンバージョンは 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 で分岐なしの保存プロセスが導入されました。これにより、同期および保存中にスワップを使用することなく、アプリケーションにより多くのメモリを割り当てて使用することができます。詳細については、「[同期とバックアップの実装方法](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 は常にそのプロセスを生成 (フォーク) します (これらのエンジンはシングルスレッドであることを思い出してください)。1 つのフォークがデータをディスクの Redis OSS .rdb スナップショットファイルに永続化します。もう 1 つのフォークは、すべての読み取りと書き込みのオペレーションを処理します。スナップショットがポイントインタイムスナップショットであることを保証するために、すべてのデータの更新と追加が、データ領域とは別の使用可能なメモリ領域に書き込まれます。
データをディスクに保持しながら、すべての書き込みオペレーションを記録するのに十分なメモリが使用できる限り、メモリ不足の問題は発生しません。次のいずれかに該当する場合は、メモリ不足の問題が発生する可能性があります。
+ アプリケーションで頻繁に書き込みオペレーションが実行され、新しいデータや更新されたデータを受け入れるために使用可能なメモリが大量に必要になる。
+ 新しいデータや更新されたデータを書き込むために使用できるメモリが少なすぎる。
+ ディスクに永続化するのに長時間かかる大規模なデータセットがあり、大量の書き込みオペレーションが必要になる。
次の図は、バックグラウンド書き込みプロセス実行時のメモリの使用を示しています。
![\[イメージ: バックグラウンド書き込み中のメモリ使用の図。\]](http://docs.aws.amazon.com/ja_jp/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` のようなバックグラウンド書き込みプロセスが呼び出されると、プロセスの失敗を防ぐためには、処理中の書き込みオペレーションが消費する量以上のメモリが必要となります。最悪のシナリオでは、バックグラウンド書き込みオペレーション中にすべてのレコードが更新され、新しいレコードがキャッシュに追加されます。そのため、Redis OSS バージョン 2.8.22 より前の場合は、`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/)を使用している場合は、スケールアウトする前に、クラスターがシャードにより異なる関数定義にならないように、すべての関数をすべてのシャードに読み込むことをお勧めします。
リシャーディング後は、以下の点に注意してください:
+ ターゲットのシャードで十分なメモリが利用できない場合、スケールインが部分的に成功している可能性があります。そのような結果が生じた場合、必要に応じて使用可能なメモリを確認し、オペレーションを再試行してください。ターゲットのシャードのデータは削除されません。
+ `FLUSHALL` および `FLUSHDB` コマンドは、リシャーディング操作中の Lua スクリプト内ではサポートされません。Redis OSS 6 より前では、移行中のスロットで動作する `BRPOPLPUSH` コマンドはサポートされていません。
# メンテナンス中のダウンタイムを最小限に抑える
クラスターモード設定を使用して、マネージド型またはアンマネージド型のオペレーション中に可用性を最大限に高めることができます。クラスター検出エンドポイントに接続するクラスターモードがサポートされるクライアントを使用することをお勧めします。クラスターモードを無効にした場合は、すべての書き込みオペレーションにプライマリエンドポイントを使用することをお勧めします。
読み取りアクティビティの場合、アプリケーションはクラスター内のいずれのノードにも接続できます。プライマリエンドポイントとは異なり、ノードエンドポイントは特定のエンドポイントに解決されます。レプリカの追加または削除など、クラスターに変更を加えた場合は、アプリケーションでノードエンドポイントを更新する必要があります。このため、クラスターモードを無効にする場合は、読み取りアクティビティにリーダーエンドポイントを使用することをお勧めします。
クラスターで自動フェイルオーバーが有効になっている場合、プライマリノードが変更される可能性があります。したがって、アプリケーションでノードのロールを確認し、すべての読み取りエンドポイントを更新する必要があります。これにより、プライマリに大きな負荷がかかっていないことを確認できます。自動フェイルオーバーを無効にしても、ノードのロールは変わりません。ただし、自動フェイルオーバーが有効になっているクラスターと比較して、マネージド型またはアンマネージド型のオペレーションのダウンタイムは長くなります。
読み取りリクエストの転送先を単一のリードレプリカノードに限定しないでください。そのノードが使用できなくなると、読み取りが停止する可能性があります。メンテナンス中の読み取り中断を回避するには、プライマリからの読み取れるようにフォールバックするか、少なくとも 2 つのリードレプリカを用意してください。
# Memcached のキャッシュ戦略
以下のトピックでは、Memcached キャッシュを設定および維持するための戦略について説明します。
キャッシュするデータとデータへのアクセスパターンに基づいて、キャッシュを入力し維持するために実装する戦略とは何か。たとえば、ゲームサイトやトレンドのニュースのランキングトップ 10 で同じ同じ戦略は使用したくないでしょう。このセクションの後半では、一般的なキャッシュのメンテナンス戦略、利点および欠点について説明します。
**Topics**
+ [リードレプリカ](#Strategies.ReadReplicas)
+ [遅延読み込み](#Strategies.LazyLoading)
+ [書き込みスルー](#Strategies.WriteThrough)
+ [TTL の追加](#Strategies.WithTTL)
+ [関連トピック](#Strategies.SeeAlso)
## リードレプリカ
多くの場合、レプリカを作成し、プライマリキャッシュノードの代わりにそこから読み取ることで、ElastiCache サーバーレスキャッシュのパフォーマンスを大幅に向上させることができます。詳細については、「[リードレプリカの使用に関するベストプラクティス](ReadReplicas.md)」を参照してください。
## 遅延読み込み
その名前が示すようため、[*遅延読み込み*] は、必要なときにのみキャッシュにデータを読み込むキャッシュ戦略です。これは、以下で説明するように動作します。
Amazon ElastiCacheは、インメモリ key-value ストアで、アプリケーションとアプリケーションがアクセスするデータストア (データベース) 間にあります。アプリケーションがデータをリクエストする場合は、常に ElastiCache キャッシュに最初にリクエストを行います。データがキャッシュにあり最新である場合、ElastiCache はアプリケーションにデータを返します。データがキャッシュにない場合、または期限が切れている場合は、アプリケーションはデータストアからのデータをリクエストします。その後、データストアはアプリケーションにデータを返します。次に、アプリケーションは、ストアから受信したデータをキャッシュに書き込みます。このようにして、次回リクエストされたときに、より迅速に取得できます。
[*キャッシュヒット*] は、データがキャッシュにあり、期限切れでない場合に発生します。
1. アプリケーションは、キャッシュに対してデータをリクエストします。
1. キャッシュはアプリケーションにデータを返します。
[*キャッシュミス*] は、データがキャッシュにないか、期限切れの場合に発生します。
1. アプリケーションは、キャッシュに対してデータをリクエストします。
1. キャッシュにはリクエストされたデータがないため、`null` を返します。
1. アプリケーションはデータベースに対してデータをリクエストし、取得します。
1. アプリケーションは、新しいデータでキャッシュを更新します。
### 遅延読み込みの利点と欠点
遅延読み込みの利点は次のとおりです。
+ リクエストされたデータのみをキャッシュします。
ほとんどのデータがリクエストされないため、遅延読み込みではデータでキャッシュがいっぱいになることを回避できます。
+ ノード障害は、アプリケーションにとって致命的ではありません。
ノードで障害が発生して新しい空のノードに置き換えられた場合、アプリケーションはレイテンシーが長くなっても機能し続けます。新規ノードへのリクエストが行われると、それぞれのキャッシュミスにより、データベースのクエリが行われます。同時に、後続のリクエストがキャッシュからデータを取得できるように、データコピーがキャッシュに追加されます。
遅延読み込みの欠点は次のとおりです。
+ キャッシュミスのペナルティがあります。1 回のキャッシュのミスで 3 回のトリップ:
1. キャッシュに対する最初のデータリクエスト
1. データベースへのデータクエリ
1. キャッシュにデータを書き込む
これらのミスにより、アプリケーションによるデータの取得に相当な遅延が発生する可能性があります。
+ 古いデータ。
キャッシュミスがある場合にのみデータがキャッシュに書き込まれる場合は、キャッシュ内のデータが古くなる可能性があります。この結果は、データベースのデータが変更されたときに、キャッシュへの更新がないために発生します。この問題に対処するには、[書き込みスルー](#Strategies.WriteThrough) および [TTL の追加](#Strategies.WithTTL) 戦略を使用できます。
### 遅延読み込み擬似コードの例
次のコードは、遅延読み込みロジックの擬似コードの例です。
```
// *****************************************
// 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)
```
## 書き込みスルー
書き込みスルー戦略では、データがデータベースに書き込まれると常にデータを追加するか、キャッシュのデータを更新します。
### 書き込みスルーの利点と欠点
書き込みスルーの利点は次のとおりです。
+ キャッシュのデータが古くなりません。
キャッシュにデータベースにデータが書き込まれるたびにキャッシュのデータが更新されるため、キャッシュのデータが常に最新の状態になります。
+ 書き込みペナルティ対読み取りペナルティ。
1 回の書き込みで 2 回のトリップ:
1. キャッシュへの書き込み
1. データベースへの書き込み
レイテンシーをプロセスに追加します。つまり、エンドユーザーは一般的に、データの取得時よりもデータの更新時のレイテンシーに対して寛容です。更新は作業量が大きく時間がかかるのが常です。
書き込みスルーの欠点は次のとおりです。
+ 欠落データ。
ノード障害またはスケールアウトにより、新規ノードをスピンアップすると、データが欠落しています。このデータは、データベースで追加または更新されるまで失われ続けます。これを最小限に抑えるには、[[遅延読み込み](#Strategies.LazyLoading)] を書き込みスルーで指定します。
+ キャッシュの変動。
ほとんどのデータは読み込まれないため、これはリソース浪費です。[[有効期限 (TTL) の値を追加する](#Strategies.WithTTL)] を使用すると、無駄なスペースを最小限に抑えることができます。
### 書き込みスルー擬似コードの例
以下は、書き込みスルーロジックの擬似コードの例です。
```
// *****************************************
// 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) の値を追加することで、それぞれの戦略のメリットが得られます。同時に、過剰なデータでキャッシュがいっぱいになる事態が避けられます。
*[有効期限 (TTL)]* は、キーの有効期限までの秒数を指定する整数値です。Valkey または Redis OSS では、この値の秒またはミリ秒を指定できます。Memcached は、この値を秒単位で指定します。アプリケーションが期限切れのキーを読み込もうとすると、キーが見つからないものとして処理されます。データベースにキーについてクエリされ、キャッシュが更新されます。このアプローチは、値が古くなっていないことを保証するものではありません。ただし、これはデータが古くなりすぎることを防ぎ、キャッシュの値がデータベースから時々更新されることを必要とします。
詳細については、「[Valkey and Redis OSS commands](https://valkey.io/commands)」または「[Memcached `set` commands](https://www.tutorialspoint.com/memcached/memcached_set_data.htm)」を参照してください。
### TTL 擬似コードの例
以下は、TTL のある書き込みスルーロジックの擬似コードの例です。
```
// *****************************************
// 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 のある遅延読み込みロジックの擬似コードの例です。
```
// *****************************************
// 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 には、サーバーレスキャッシュとノードベースのクラスターという 2 つのデプロイオプションがあります。それぞれに独自の機能と要件があります。
このセクションでは、ノードベースのクラスターの管理に役立つトピックを紹介します。
**注記**
これらのトピックは、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 マネジメントコンソールを適用できます。`predefined metric` は列挙型で定義されるため、それをコード内に名前で指定するか、AWS マネジメントコンソールで使用できます。カスタムのメトリクスは、AWS マネジメントコンソールを使用した選択には使用できません。または、AWS CLIまたは Application Auto Scaling API を使用して、事前定義されたメトリクスまたはカスタムメトリクスに基づいてスケーリングポリシーを適用することもできます。
ElastiCache for Valkey と ElastiCache for Redis OSS は、次のディメンションのスケーリングをサポートします。
+ [**シャード**] — 手動オンラインリシャーディングと同様に、クラスター内のシャードを自動的に追加/削除します。この場合、ElastiCache の自動スケーリングはユーザーに代わってスケーリングをトリガーします。
+ [**レプリカ**] – 手動によるレプリカの増加/減少オペレーションと同様に、クラスター内のレプリカを自動的に追加/削除します。ElastiCache for Valkey と ElastiCache for Redis OSS の 自動スケーリングは、クラスター内のすべてのシャードにわたって均一にレプリカを追加/削除します。
ElastiCache for Valkey と ElastiCache for Redis OSS は、次のタイプの自動スケーリングポリシーをサポートします。
+ [ターゲット追跡スケーリングポリシー](AutoScaling-Scaling-Policies-Target.md) – 特定のメトリクスのターゲット値に基づいて、サービスが実行するシャード/レプリカの数を増減させます。これはサーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、後はサーモスタットがすべてを実行します。
+ [ アプリケーションのスケジュールされたスケーリング。 ](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)– ElastiCache for Valkey と ElastiCache for Redis OSS の自動スケーリングでは、日付と時刻に基づいて、サービスが実行するシャード/レプリカの数を増減させることができます。
![\[ElastiCache for Valkey と ElastiCache for Redis OSS の自動スケーリングの画像\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/Auto-scaling.png)
次のステップは、前の図に示された ElastiCache for Valkey と ElastiCache for Redis OSS の自動スケーリングのプロセスをまとめたものです。
1. レプリケーショングループ用の ElastiCache の Auto Scaling ポリシーを作成します。
1. ElastiCache の自動スケーリングは、ユーザーに代わって CloudWatch アラームのペアを作成します。各ペアはメトリクスの上限と下限を示します。CloudWatch アラームは、クラスターの実際の使用率が一定期間ターゲット使用率を逸脱したときにトリガーされます。コンソールでアラームを表示できます。
1. 設定したメトリクスの値が特定の期間にターゲット使用率を超える (または下回る) と、CloudWatch は、自動スケーリング呼び出してスケーリングポリシーを評価するアラームをトリガーします。
1. ElastiCache の自動スケーリングは、クラスター容量を調整するための変更リクエストを発行します。
1. ElastiCache は変更リクエストを処理してクラスターのシャード/レプリカの容量を動的に増減し、ターゲット使用率に近づけます。
ElastiCache の自動スケーリングの仕組みを理解するため、`UsersCluster` という名前のクラスターがあると仮定します。`UsersCluster` の CloudWatch メトリックスをモニタリングすることで、トラフィックがピークのときにクラスターが必要とする最大シャードを決定し、トラフィックが最小ポイントにあるときに最小シャードを決定します。また、`UsersCluster` クラスターの CPU 使用率のターゲット値を決定します。ElastiCache の自動スケーリングは、ターゲット追跡アルゴリズムを使用して、`UsersCluster` のプロビジョンされたシャードが必要に応じて調整され、使用率がターゲット値またはその近くに留まるようにします。
**注記**
スケーリングにはかなりの時間がかかることがあり、シャードを再調整するために余分なクラスターリソースが必要になります。ElastiCache の自動スケーリングは、実際のワークロードの増減が数分間維持された場合にのみ、リソース設定を変更します。自動スケーリングターゲット追跡アルゴリズムは、長期にわたってターゲット使用率を選択した値の付近に維持しようとします。
# Auto Scaling ポリシー
スケーリングポリシーには、次のコンポーネントがあります。
+ ターゲットメトリクス – Valkey と Redis OSS に対応した ElastiCache Auto Scaling で、スケールするタイミングと量を判断するために使用される CloudWatch のメトリクス。
+ 最小容量と最大容量 – スケーリングに使用されるシャードまたはレプリカの最小数および最大数。
**重要**
Auto Scaling ポリシーの作成中に、現在の容量が設定された最大容量よりも大きい場合、ポリシーの作成時に maxCapacity にスケールインします。同様に、現在の容量が設定された最少容量よりも小さい場合は、最小容量にスケールアウトします。
+ クールダウン期間 – スケールインまたはスケールアウトアクティビティが完了してから別のスケールアウトアクティビティが開始されるまでの時間 (秒)。
+ サービスにリンクされたロール — AWS Identity and Access Management (IAM) ロールは、特定の AWS サービスにリンクされています。サービスにリンクされたロールは、ユーザーに代わってサービスから AWS の他のサービスを呼び出すために必要なすべてのアクセス許可を備えています。ElastiCache の Auto Scaling は、ユーザーに代わって、この `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG` というロールを自動的に生成します。
+ スケールインアクティビティの有効化または無効化 - ポリシーに対してスケールインアクティビティを有効化または無効化できます。
**Topics**
+ [Auto Scaling のターゲットメトリックス](#AutoScaling-TargetMetric)
+ [最小容量と最大容量](#AutoScaling-MinMax)
+ [クールダウン期間](#AutoScaling-Cooldown)
+ [スケールインアクティビティの有効化または無効化](#AutoScaling-enable-disable-scale-in)
## Auto Scaling のターゲットメトリックス
このタイプのポリシーでは、ターゲット追跡スケーリングポリシー設定で、事前定義されたメトリクスまたはカスタムメトリクスとそのメトリクスのターゲット値を指定します。Valkey と Redis OSS に対応した ElastiCache Auto Scaling は、スケーリングポリシーをトリガーする CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するため、必要に応じてシャード/レプリカを追加または削除します。メトリクスをターゲット値に近い値に維持することに加えて、ターゲット追跡スケーリングポリシーは、変化するワークロードによるメトリクスの変動に適応します。そのようなポリシーは、クラスターに使用可能なシャード/レプリカ数の急速な変動の最小化もします。
たとえば、事前定義された平均 `ElastiCachePrimaryEngineCPUUtilization` メトリクスを使用するスケーリングポリシーを考慮してください。そのようなポリシーは、70 パーセントなどの指定された使用率に、またはそれに近い割合に CPU 使用率を維持できます。
**注記**
各クラスターについては、各ターゲットメトリクスに対して 1 つの Auto Scaling ポリシーのみを作成できます。
## 最小容量と最大容量
**シャード**
Valkey と Redis OSS に対応した ElastiCache の自動スケーリングでスケールできるシャードの最大数を指定できます。この値は、250 以下で、最小 1 である必要があります。自動スケーリングで管理するシャードの最小数も指定できます。この値は 1 以上で、最大シャードで指定された値である 250 以下である必要があります。
**レプリカ**
Valkey と Redis OSS に対応した ElastiCache の自動スケーリングで管理されるレプリカの最大数を指定できます。この値は、1 以下にする必要があります。自動スケーリングが管理するレプリカの最小数も指定できます。この値は 1 以上で、最大レプリカで指定された値である 5 以下である必要があります。
通常のトラフィックに必要なシャード/レプリカの最小数と最大数を決定するには、モデルに対するトラフィックの予想レートで Auto Scaling の設定をテストします。
**注記**
ElastiCache の自動スケーリングポリシーは、定義した最大サイズに達するまで、またはサービス制限が適用されるまで、クラスター容量を増加させます。この制限の拡大をリクエストするには、「[AWS のサービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照し、制限タイプとして [**Nodes per cluster per instance type (インスタンスタイプごとのクラスターあたりのノード)**] を選択します。
**重要**
トラフィックがないときにスケールインする バリアントのトラフィックがゼロになった場合、ElastiCache は、指定されたインスタンスの最小数に自動的にスケールインします。
## クールダウン期間
クラスターのスケールインやスケールアウトに影響するクールダウン期間を追加することで、ターゲット追跡スケーリングポリシーの応答性を調整できます。クールダウン期間を設定すると、その期間が過ぎるまでその後のスケールインやスケールアウトのリクエストがブロックされます。これにより、スケールインリクエストのための Valkey と Redis OSS に対応した ElastiCache クラスターにおけるシャード/レプリカの削除、およびスケールアウトリクエストのためのシャード/レプリカの作成が遅れます。以下のクールダウン期間を指定できます。
+ スケールインアクティビティは、クラスターのシャード/レプリカ数を減らします。スケールインのクールダウン期間は、スケールインアクティビティが完了してから別のスケールインアクティビティが開始されるまでの時間 (秒) を指定します。
+ スケールアウトアクティビティは、クラスターのシャード/レプリカ数を増やします。スケールアウトのクールダウン期間は、スケールアウトアクティビティが完了してから別のスケールアウトアクティビティが開始されるまでの時間 (秒) を指定します。
スケールインやスケールアウトのクールダウン期間が指定されない場合、スケールアウトのデフォルトは 600 秒で、スケールインのデフォルトは 900 秒です。
## スケールインアクティビティの有効化または無効化
ポリシーに対してスケールインアクティビティを有効化または無効化できます。スケールインアクティビティを有効にすると、スケーリングポリシーはシャード/レプリカを削除できます。スケールインアクティビティが有効な場合、スケーリングポリシーのスケールインのクールダウン期間がスケールインアクティビティに適用されます。スケールインアクティビティを無効にすると、スケーリングポリシーはシャード/レプリカを削除できなくなります。
**注記**
必要に応じてスケーリングポリシーで ElastiCache のシャード/レプリカを作成できるように、スケールアウトアクティビティを常に有効にしておきます。
## 自動スケーリングに必要な IAM のアクセス許可
ElastiCache for Valkey と ElastiCache for Redis OSS の自動スケーリングは、ElastiCache、CloudWatch、および Application Auto Scaling API を組み合わせることで可能になります。クラスターは ElastiCache で作成および更新され、アラームは CloudWatch で作成され、スケーリングポリシーは Application Auto Scaling で作成されます。クラスターの作成および更新のための標準の IAM アクセス許可に加えて、ElastiCache の自動スケーリング設定にアクセスする 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 と ElastiCache for Redis OSS の自動スケーリングサービスでは、クラスターと CloudWatch のアラームを記述するためのアクセス許可と、ユーザーに代わって ElastiCache のターゲット容量を変更するためのアクセス許可も必要です。クラスターの自動スケーリングを有効にすると、`AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG` という名前のサービスリンクロールが作成されます。このサービスリンクロールは、ElastiCache の自動スケーリングに対して、ポリシーのアラームの記述、フリートの現容量のモニタリング、およびフリートの容量変更を行うためのアクセス許可を付与します。サービスリンクロールは、ElastiCache の自動スケーリングのデフォルトロールです。詳細については、「Application Auto Scaling ユーザーガイド」の「[ElastiCache for Redis OSS の自動スケーリングのサービスにリンクされたロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。
## Auto Scaling のベストプラクティス
Auto Scaling に登録する前に、以下のことをお勧めします。
1. **追跡メトリクスを 1 つだけ使用** — クラスターに CPU 負荷の高いワークロードまたはデータ集約型のワークロードがあるかどうかを識別し、対応する定義済みメトリックを使用してスケーリングポリシーを定義します。
+ エンジン CPU: `ElastiCachePrimaryEngineCPUUtilization` (シャードディメンション) または `ElastiCacheReplicaEngineCPUUtilization` (レプリカディメンション)
+ データベースの使用状況: `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` このスケーリングポリシーは、クラスターで maxmemory-policy が noeviction に設定されている場合に最適です。
クラスターの 1 つのディメンションでポリシーが複数にならないようお勧めします。ElastiCache for Valkey と ElastiCache for Redis OSS の自動スケーリングでは、ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、スケーラブルなターゲットがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分が有効) でスケールインする準備ができている場合のみスケールインされます。複数のポリシーによって、スケーラブルなターゲットが同時にスケールアウトまたはスケールインするように指示される場合、Auto Scaling は、スケールインとスケールアウトの両方で最大の容量を提供するポリシーに基づいてスケールします。
1. **ターゲット追跡のカスタマイズされたメトリクス** — Target Tracking 用にカスタマイズされたメトリクスを使用する場合は注意が必要です。Auto Scaling は、ポリシー用に選択されたメトリクスの変更に比例してスケールアウトするのに最適です。スケーリングアクションに比例して変更されないメトリクスがポリシーの作成に使用されると、可用性やコストに影響する可能性のあるスケールアウトまたはスケールインアクションが継続する可能性があります。
データ階層化クラスター (r6gd ファミリーのインスタンスタイプ) では、スケーリングにメモリベースのメトリクスを使用しないでください。
1. **スケジュールに基づくスケーリング** — ワークロードが確定的 (特定の時点で高/低に達する) であることが判明した場合は、スケジュールされたスケーリングを使用し、必要に応じてターゲット容量を設定することをお勧めします。ターゲット追跡は、非決定的なワークロードや、必要なターゲットメトリクスでクラスターを操作する場合に最適です。これにより、より多くのリソースが必要な場合はスケールアウトし、必要な場合はスケールインします。
1. **スケールインを無効化する** — ターゲット追跡での Auto Scaling は、ワークロードが徐々に増減するクラスターに最適です。メトリクスのスパイク/ディップが連続するスケールアウト/イン振動を引き起こす可能性があるためです。このような振動を避けるために、スケールインを無効にして開始し、後でいつでも必要に応じて手動でスケールインすることができます。
1. **アプリケーションをテスト** — 可用性の問題を回避するために、スケーリングポリシーを作成しながら、クラスターに必要な最小/最大シャード/レプリカの絶対値を決定するために、最小/最大ワークロードを推定してアプリケーションをテストすることをお勧めします。Auto Scaling は Max にスケールアウトし、ターゲットに設定された最小しきい値にスケールインできます。
1. **ターゲット値の定義** — 4 週間のクラスター使用率の対応する CloudWatch メトリクスを分析し、目標値のしきい値を決定できます。選択する値が不明な場合は、サポートされる最小定義メトリクス値から開始することをお勧めします。
1. ターゲット追跡での AutoScaling は、シャード/レプリカのディメンション間でワークロードが均一に分散されるクラスターに最適です。不均一な分布を持つと、次のことが可能になります。
+ いくつかのホットシャード/レプリカでワークロードの急増/減少が原因で、必要のない場合のスケーリング。
+ ホットシャード/レプリカがあるにもかかわらず、全体的な平均ターゲットに近いために必要なときにスケーリングされません。
**注記**
クラスターをスケールアウトすると、ElastiCache は (ランダムに選択された) 既存のノードのいずれかにロードされた関数を新しいノードに自動的にレプリケートします。クラスターに Valkey または Redis OSS 7.0 以上があり、アプリケーションで[関数](https://valkey.io/topics/functions-intro/)を使用している場合は、スケールアウトする前に、クラスターがシャードにより異なる関数定義にならないように、すべての関数をすべてのシャードに読み込むことをお勧めします。
AutoScaling に登録したら、以下の点に注意してください。
+ Auto Scaling でサポートされる設定には制限があるため、Auto Scaling に登録されているレプリケーショングループの設定を変更しないことをお勧めします。次に例を示します。
+ インスタンスタイプをサポートされていないタイプに手動で変更します。
+ レプリケーショングループをグローバルデータストアに関連付けます。
+ `ReservedMemoryPercent` パラメータの変更。
+ ポリシーの作成時に設定された Min/Max 容量を超えるシャード/レプリカを手動で増減します。
# シャードでの Auto Scaling の使用
ElastiCache の AutoScaling では、Valkey または Redis OSS エンジンで追跡ポリシーとスケジュールされたポリシーを使用できます。
以下では、ターゲット追跡とスケジュールされたポリシーの詳細と、AWS マネジメントコンソール 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)
# ターゲット追跡スケーリングポリシー
ターゲット追跡スケーリングポリシーで、メトリクスを選択してターゲット値を設定します。Valkey と Redis OSS に対応した ElastiCache 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 基準
事前定義されたメトリクスが Target 設定以上であることを検出した場合、シャードの容量が自動的に増加します。Valkey と Redis OSS に対応した ElastiCache は、2 つの数字 (ターゲットからの変動率と現在のシャードの 20%) のうち、大きいほうの数字に等しい数だけクラスターシャードをスケールアウトします。スケールインの場合、全体的なメトリクス値が定義されたターゲットの 75% を下回らない限り、ElastiCache は自動スケールインしません。
スケールアウトの例では、50個のシャードを持っている場合
+ ターゲットが 30% 超えた場合、ElastiCache は 30% スケールアウトするため、クラスターあたり 65 個のシャードになります。
+ ターゲットが 10% 超えた場合、ElastiCache はデフォルトで最小値 20% スケールアウトするため、クラスターあたり 60 個のシャードになります。
スケールインの例で、ターゲット値として 60% を選択した場合、ElastiCache は、メトリクスが 45% 以下 (ターゲットの 60% を 25% 下回る状態) になるまでは自動スケールインしません。
## Auto Scaling に関する考慮事項
次の考慮事項に注意が必要です。
+ ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、スケールアウトする必要があると見なされます。指定されたメトリクスがターゲット値を下回っている場合、ターゲットの追跡スケーリングポリシーを使用してスケールアウトすることはできません。Valkey と Redis OSS に対応した ElastiCache は、クラスター内の既存のシャードのターゲットについて最小偏差の 20% 分だけシャードをスケールアウトします。
+ 指定されたメトリクスに十分なデータがない場合、ターゲットの追跡スケーリングポリシーによってスケールされません。不十分なデータの使用率は低いと解釈されないため、スケールインされません。
+ ターゲット値と実際のメトリクスデータポイント間にギャップが発生する場合があります。これは、ElastiCache の Auto Scaling が追加または削除する容量を決定するときに、その数を切り上げまたは切り捨てて常に控えめに動作するためです。これにより、不十分な容量を追加したり、必要以上に容量を削除することを防ぎます。
+ アプリケーションの可用性を高めるために、サービスのスケールアウトはメトリクスに比例して可能な限り高速に行われますが、スケールインはより抑制されています。
+ それぞれが異なるメトリクスを使用していれば、Valkey と Redis OSS に対応した ElastiCache クラスターに対して複数のターゲット追跡スケーリングポリシーを設定できます。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（Elastic Network Interfaces）が使用可能であることを確認します。詳細については、「[Elastic Network Interface](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html)」を参照してください。
+ EC2 の容量が十分にない場合、ElastiCache の自動スケーリングは、容量が利用可能になるまで、スケールせず、遅延します。
+ スケールイン中の ElastiCache for Redis OSS Auto Scaling では、シリアル化後のアイテムサイズが 256 MB を超えるスロットを持つシャードは削除されません。
+ スケールイン中に、結果として得られるシャード設定で利用可能なメモリが不足している場合、シャードは削除されません。
# スケーリングポリシーの追加
AWS マネジメントコンソール を使用してスケーリングポリシーを追加できます。
**Valkey と Redis OSS に対応した Auto Scaling ポリシーを ElastiCache クラスターに追加する方法**
1. AWS マネジメントコンソールにサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. ポリシーを追加するクラスターを選択します (クラスター名の左にあるボタンではなく、クラスター名を選択)。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. **[add dynamic scaling]** (動的なスケーリングを追加) を選択します。
1. [**Policy Name**] で、ポリシーの名前を入力します。
1. [**スケーラブルなディメンション**] で、[**シャード**] を選択します。
1. ターゲットメトリクスには、以下のいずれかを選択します。
+ 平均 CPU 使用率に基づいてポリシーを作成するための [** プライマリ CPU 使用率**]。
+ データベース平均メモリに基づいてポリシーを作成するための [**メモリ**]。
+ データベース平均メモリに基づいてポリシーを作成するための **[容量]**。容量メトリクスには、データ階層化インスタンスのメモリと SSD の使用率、および他のすべてのインスタンスタイプのメモリ使用率が含まれます。
1. 目標値は、35 以上、70 以下の値を選択します。Auto Scaling は、選択したターゲットメトリクスについて、ElastiCache シャード全体でこの値を維持します。
+ **プライマリCPU使用率**: プライマリノードの `EngineCPUUtilization` メトリクスの目標値を維持します。
+ **メモリ**: `DatabaseMemoryUsageCountedForEvictPercentage` メトリクスの目標値を維持します。
+ **容量**は `DatabaseCapacityUsageCountedForEvictPercentage` メトリクスの目標値を維持し、
クラスターシャードが追加または削除され、メトリクスが指定された値に近い値に維持されます。
1. (オプション) スケールインまたはスケールアウトのクールダウン期間は、コンソールからはサポートされていません。AWS CLI を使用して、クールダウン値を変更します。
1. **[最小容量]** では、ElastiCache の Auto Scaling ポリシーが維持する必要があるシャードの最小数を入力します。
1. **[最大容量]** では、ElastiCache の Auto Scaling ポリシーが維持する必要があるシャードの最大数を入力します。この値は、250 以下にする必要があります。
1. **[Create]** (作成) を選択します。
# スケーラブルなターゲットの登録
Valkey と Redis OSS に対応した ElastiCache クラスターで Auto Scaling を使用可能にする前に、クラスターを ElastiCache の自動スケーリングに登録します。これは、そのクラスターに適用するスケーリングのディメンションと制限を定義するためです。ElastiCache の自動スケーリングは、クラスターを、クラスターシャードの数を表す `elasticache:replication-group:NodeGroups` スケーラブルディメンションに沿って動的にスケールします。
** の使用AWS CLI**
Valkey と Redis OSS に対応した ElastiCache クラスターを登録するには、次のパラメータを指定して [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**
以下の例では、`myscalablecluster` という名前の ElastiCache クラスターをアプリケーションの Auto Scaling API に登録します。この登録は、クラスターが 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 または アプリケーションの 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 のターゲット追跡で動作する Valkey と Redis OSS に対応した ElastiCache クラスターのターゲット追跡スケーリングポリシーを迅速に定義できます。
現在、ElastiCache は、NodeGroup Auto Scaling で次の定義済みメトリクスをサポートしています。
+ **ElastiCachePrimaryEngineCPUUtilization** — クラスター内のすべてのプライマリノードでの CloudWatch の `EngineCPUUtilization` メトリクスの平均値。
+ **ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage** — クラスター内のすべてのプライマリノードでの CloudWatch の `DatabaseMemoryUsageCountedForEvictPercentage` メトリクスの平均値。
+ **ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage** — クラスター内のすべてのプライマリノードでの CloudWatch の `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` メトリクスの平均値。
`EngineCPUUtilization` と `DatabaseMemoryUsageCountedForEvictPercentage`、および `DatabaseCapacityUsageCountedForEvictPercentage` メトリクスの詳細については、「[CloudWatch メトリクスの使用状況のモニタリング](CacheMetrics.md)」を参照してください。スケーリングポリシーで事前定義メトリクスを使用するには、スケーリングポリシーのターゲット追跡構成を作成します。この設定は、事前定義メトリクスの `PredefinedMetricSpecification` と、そのメトリクスのターゲット値の TargetValue が含まれている必要があります。
**Example**
次の例では、Valkey と Redis OSS に対応した ElastiCache クラスターのターゲット追跡スケーリングの一般的なポリシー設定について説明します。この設定では、`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` の値を秒単位で追加して、クラスターをスケールインするためのクールダウン期間を追加することができます。詳細については、アプリケーション Auto Scaling API リファレンスの「[TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)」を参照してください。
次の例では、スケーリングポリシーのターゲット追跡設定について説明します。この設定では、`ElastiCachePrimaryEngineCPUUtilization` 事前定義メトリクスを使用して、ElastiCache for Redis OSS クラスターのすべてのプライマリノードでの平均 CPU 使用率 40% に基づいてそのクラスターが調整されます。この構成では、10 分間のスケールインのクールダウン期間と 5 分間のスケールアウトのクールダウン期間が提供されます。
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
# スケールインアクティビティの無効化
スケールインアクティビティを無効にすることにより、クラスターでターゲット追跡スケーリングポリシー設定がスケーリングされないように指定できます。スケールインアクティビティを無効にすると、スケーリングポリシーによってシャードが削除されることなく、スケーリングポリシーによって必要に応じて作成されます。
`DisableScaleIn` のブール値を指定して、クラスターのアクティビティのスケールを有効または無効にすることができます。詳細については、アプリケーション Auto Scaling API リファレンスの「[TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)」を参照してください。
次の例では、スケーリングポリシーのターゲット追跡設定について説明します。この設定では、`ElastiCachePrimaryEngineCPUUtilization` 事前定義メトリクスは、そのクラスターの全プライマリノードでの平均 CPU 使用率 40% に基づいて、Valkey と Redis OSS に対応した ElastiCache クラスターを調整します。この設定では、スケーリングポリシーのスケールインアクティビティが無効になります。
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
# スケーリングポリシーの適用
クラスターを Valkey と Redis OSS に対応した ElastiCache の自動スケーリングに登録し、スケーリングポリシーを定義した後、登録されたクラスターにスケーリングポリシーを適用します。ElastiCache for Redis OSS クラスターにスケーリングポリシーを適用するには、AWS CLI または Application Auto Scaling API を使用できます。
## AWS CLI を使用したスケーリングポリシーの適用
スケーリングポリシーを Valkey と Redis OSS に対応した ElastiCache クラスターに適用するには、次のパラメータを指定して [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** — クラスターに使用するターゲット追跡スケーリングポリシー設定。
次の例では、`myscalablepolicy` というターゲット追跡スケーリングポリシーを、`myscalablecluster` という名前の Valkey と Redis OSS に対応した ElastiCache クラスターに ElastiCache の自動スケーリングを使用して適用します。そのためには、`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 を使用したスケーリングポリシーの適用
スケーリングポリシーを Valkey と Redis OSS に対応した ElastiCache クラスターに適用するには、次のパラメータを指定して [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** — クラスターに使用するターゲット追跡スケーリングポリシー設定。
次の例では、`myscalablepolicy` というターゲット追跡スケーリングポリシーを、`myscalablecluster` という名前の ElastiCache クラスターに 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 マネジメントコンソール、AWS CLI、または アプリケーションの Auto Scaling API を使用してスケーリングポリシーを編集できます。
## AWS マネジメントコンソール を使用したスケーリングポリシーの編集
**Valkey と Redis OSS に対応した ElastiCache クラスターの Auto Scaling ポリシーを編集する方法**
1. AWS マネジメントコンソールにサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、適切なエンジンを選択します。
1. ポリシーを追加するクラスターを選択します (クラスター名の左にあるボタンではなく、クラスター名を選択)。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. **[Scaling policies]** (スケーリングポリシー) で、変更する Auto Scaling ポリシーの左にあるボタンを選択して、**[Modify]** (変更) を選択します。
1. ポリシーに必要な変更を行います。
1. **[Modify]** (変更) を選択します。
## AWS CLI または API を使用したスケーリングポリシーの編集
AWS CLI または アプリケーションの Auto Scaling API を使用して、スケーリングポリシーを適用するのと同じ方法でスケーリングポリシーを編集できます。
+ AWS CLI を使用する場合は、編集するポリシーの名前を `--policy-name` パラメータで指定します。変更するパラメータの新しい値を指定します。
+ アプリケーションの Auto Scaling API を使用する場合は、編集するポリシーの名前を `PolicyName` パラメータで指定します。変更するパラメータの新しい値を指定します。
詳細については、「[スケーリングポリシーの適用](AutoScaling-Scaling-Applying-a-Scaling-Policy.md)」を参照してください。
# スケーリングポリシーの削除
AWS マネジメントコンソール、AWS CLI、または アプリケーションの Auto Scaling API を使用してスケーリングポリシーを削除できます。
## AWS マネジメントコンソール を使用したスケーリングポリシーの削除
**ElastiCache for Redis OSS クラスターの Auto Scaling ポリシーを削除するには**
1. AWS マネジメントコンソールにサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. Auto Scaling ポリシーを編集するクラスターを選択します (クラスター名の左にあるボタンではなく、クラスター名を選択)。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. **[Scaling policies]** (スケーリングポリシー) で、Auto Scaling ポリシーを選択してから **[Delete]** (削除) を選択します。
## AWS CLI を使用したスケーリングポリシーの削除
Valkey と Redis OSS に対応した ElastiCache クラスターのスケーリングポリシーを削除するには、次のパラメータを指定して [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 を使用したスケーリングポリシーの削除
スケーリングポリシーを Valkey と Redis OSS に対応した ElastiCache クラスターから削除するには、次のパラメータを指定して [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
```
# スケジュールされたスケーリング
スケジュールに基づくスケーリングにより、予想可能な需要の変化に応じてアプリケーションを拡張することができます。スケジュールに基づくスケーリングを使用するには、指定された時間にスケーリングアクティビティを行うよう Valkey と Redis OSS に対応した ElastiCache に指示する、スケジュールされたアクションを作成します。スケジュールされたアクションを作成する際、既存のクラスターを指定して、スケーリングアクティビティが起こるタイミング、最小容量、最大容量を指定できます。スケジュールされたアクションは、一度だけスケールする、または定期的なスケジュールに従ってスケールするものを作成できます。
スケジュールされたアクションは、既存のクラスターに対してのみ作成できます。スケジュールされたアクションは、クラスターの作成と同時に作成することはできません。
スケジュールされたアクションの作成、管理、削除に関する用語の詳細については、「[スケジュールされたアクションの作成、管理、削除に一般的に使用されるコマンド](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)」を参照してください。
**定期的なスケジュールで作成するには**
1. AWS マネジメントコンソール にサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. ポリシーを追加するクラスターを選択します。
1. [**アクション**] ドロップダウンから [**Auto Scaling ポリシーを管理する**] を選択します。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. [**Auto Scaling ポリシー**] セクションで、[**スケーリングポリシーの追加**] ダイアログボックスが表示されます。[**スケジュールされたスケーリング**] を選択します。
1. [**Policy Name**] では、このポリシー名を入力します。
1. [**スケーラブルディメンション**] では、[**シャード**] を選択します。
1. [**ターゲットシャード**] では、値を選択します。
1. [**繰り返し**] では、**繰り返し**] を選択します。
1. [**頻度**]では、それぞれの値を選択します。
1. [**開始日**] および [**開始時間**] では、ポリシーが有効になる時刻を選択します。
1. [**Add policy**] を選択します。
**1 回のスケジュールされたアクションを作成するには**
1. AWS マネジメントコンソール にサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. ポリシーを追加するクラスターを選択します。
1. [**アクション**] ドロップダウンから [**Auto Scaling ポリシーを管理する**] を選択します。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. [**Auto Scaling ポリシー**] セクションで、[**スケーリングポリシーの追加**] ダイアログボックスが表示されます。[**スケジュールされたスケーリング**] を選択します。
1. [**Policy Name**] では、このポリシー名を入力します。
1. [**スケーラブルディメンション**] では、[**シャード**] を選択します。
1. [**ターゲットシャード**] では、値を選択します。
1. [**繰り返し**] では、[**1 回**] を選択します。
1. [**開始日**] および [**開始時間**] では、ポリシーが有効になる時刻を選択します。
1. **終了日**では、ポリシーが有効になるときの日付を選択します。
1. [**Add policy**] を選択します。
**スケジュールされたアクションを削除するには**
1. AWS マネジメントコンソール にサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. ポリシーを追加するクラスターを選択します。
1. [**アクション**] ドロップダウンから [**Auto Scaling ポリシーを管理する**] を選択します。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. [**Auto Scaling Policies (Auto Scaling ポリシー)**] セクションで Auto Scaling ポリシーを選択してから、[**Actions (アクション)**] メニューから [**Delete (削除)**] を選択します。
** を使用してスケジュールされたスケーリングを管理するには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 レプリケーショングループは、単一の論理ノードとして機能するように 1 つ以上のキャッシュを設定できます。
以下では、ターゲット追跡とスケジュールされたポリシーの詳細と、AWS マネジメントコンソール AWS CLI および API を使用してそれらを適用する方法を説明します。
# ターゲット追跡スケーリングポリシー
ターゲット追跡スケーリングポリシーで、メトリクスを選択してターゲット値を設定します。Valkey と Redis OSS に対応した ElastiCache AutoScaling は、スケーリングポリシーをトリガーする CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整値を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するため、必要に応じてすべてのシャードで均一にレプリカを追加または削除します。ターゲットの追跡スケーリングポリシーは、メトリクスをターゲット値近くに維持することに加えて、負荷パターンの変動によるメトリクスの変動に合わせて調整し、フリートの容量の急速な変動を最小化します。
## レプリカの Auto Scaling 基準
Auto Scaling ポリシーでは、クラスターの次の事前定義されたメトリクスを定義します。
`ElastiCacheReplicaEngineCPUUtilization`: ElastiCache が auto-scaling オペレーションをトリガーするために使用する、すべてのレプリカで集計された AVG EngineCPU 使用率のしきい値。使用率ターゲットは 35 パーセントから 70 パーセントの間で設定できます。
サービスが `ElastiCacheReplicaEngineCPUUtilization` メトリクスが Target 設定以上であることを検出した場合、シャードでレプリカを自動的に増加させます。ElastiCache は、ターゲットからの変動率と 1 つのレプリカの 2 つの数字のうち、大きい方の数に等しい数だけクラスターレプリカをスケールアウトします。スケールインの場合、全体的なメトリクス値が定義されたターゲットの 75% を下回らない限り、ElastiCache は自動スケールインしません。
スケールアウトの例では、それぞれ 5 つのシャードと 1 つのレプリカがある場合:
ターゲットを 30% 超過した場合、Valkey と Redis OSS に対応した ElastiCache はすべてのシャードにわたって 1 つのレプリカ (max(0.3, default 1)) でスケールアウトし、その結果、それぞれ 2 つのレプリカを持つ 5 つのシャードになります。
スケールインの例では、ターゲット値として 60% を選択した場合、Valkey と Redis OSS に対応した ElastiCache は、メトリクスが 45% 以下 (ターゲットの 60% を 25% 下回る) になるまで自動スケールインしません。
### Auto Scaling に関する考慮事項
次の考慮事項に注意が必要です。
+ ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、スケールアウトする必要があると見なされます。指定されたメトリクスがターゲット値を下回っている場合、ターゲットの追跡スケーリングポリシーを使用してスケールアウトすることはできません。Valkey と Redis OSS に対応した ElastiCache は、クラスター内のすべてのシャードで既存のレプリカの最大値 (ターゲットからの偏差 % を四捨五入した値、デフォルト 1) でレプリカをスケールアウトします。
+ 指定されたメトリクスに十分なデータがない場合、ターゲットの追跡スケーリングポリシーによってスケールされません。不十分なデータは低い使用率として解釈されないため、スケールインされません。
+ ターゲット値と実際のメトリクスデータポイント間にギャップが発生する場合があります。これは、ElastiCache の Auto Scaling が追加または削除する容量を決定するときに、その数を切り上げまたは切り捨てて常に控えめに動作するためです。これにより、不十分な容量を追加したり、必要以上に容量を削除することを防ぎます。
+ アプリケーションの可用性を高めるために、サービスのスケールアウトはメトリクスに比例して可能な限り高速に行われますが、スケールインはより緩やかで、クラスター内のシャードで 1 個のレプリカの最大スケールインで行われます。
+ それぞれが異なるメトリクスを使用していれば、Valkey と Redis OSS に対応した ElastiCache クラスターに対して複数のターゲット追跡スケーリングポリシーを設定できます。自動スケーリングの目的は常に可用性を優先することであるため、その動作は、ターゲット追跡ポリシーがスケールアウトまたはスケールインの準備ができているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分が有効) でスケールインする準備ができている場合にのみスケールインされます。
+ ターゲットの追跡スケーリングポリシーのために 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（Elastic Network Interfaces）が使用可能であることを確認します。詳細については、「[Elastic Network Interface](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 マネジメントコンソール を使用してスケーリングポリシーを追加できます。
**AWS マネジメントコンソール を使用したスケーリングポリシーの追加**
Valkey と Redis OSS に対応した ElastiCache に自動スケーリングポリシーを追加する方法
1. AWS マネジメントコンソールにサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. ポリシーを追加するクラスターを選択します (クラスター名の左にあるボタンではなく、クラスター名を選択)。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. **[add dynamic scaling]** (動的なスケーリングを追加) を選択します。
1. **[Scaling policies]** (スケーリングポリシー) の下で、**[Add dynamic scaling]** (動的なスケーリングを追加) を選択します。
1. [**Policy Name**] では、このポリシー名を入力します。
1. [**スケーラブルディメンション**] では、ダイアログボックスから [**レプリカ**] を選択します。
1. ターゲット値では、ElastiCache レプリカで維持する CPU 使用率の平均パーセンテージを入力します。この値は、>=35 かつ <=70 である必要があります。クラスターレプリカが追加または削除され、メトリクスが指定された値に近い値に維持されます。
1. (オプション) スケールインまたはスケールアウトのクールダウン期間は、コンソールからはサポートされていません。AWS CLI を使用して、クールダウン値を変更します。
1. **[最小容量]** に、ElastiCache の Auto Scaling ポリシーが維持する必要があるシャードの最小数を入力します。
1. **[最大容量]** に、ElastiCache の Auto Scaling ポリシーが維持する必要があるシャードの最大数を入力します。この値は、>=5 である必要があります。
1. **[Create]** (作成) を選択します。
# スケーラブルなターゲットの登録
事前定義されたメトリクスまたはカスタムメトリクスに基づいて、スケーリングポリシーを適用できます。そのためには、AWS CLI または アプリケーションの Auto Scaling API を使用します。最初のステップでは、Valkey と Redis OSS に対応した ElastiCache レプリケーショングループを Auto Scaling に登録します。
ElastiCache の自動スケーリングをクラスターで使用可能にする前に、クラスターを ElastiCache の自動スケーリングに登録する必要があります。これは、そのクラスターに適用するスケーリングのディメンションと制限を定義するためです。ElastiCache の自動スケーリングは、シャードあたりのクラスターレプリカの数を表す `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 の自動スケーリングで管理するレプリカの最小数。—min-capacity、—max-capacity、およびクラスター内のレプリカ数の関係については、「[最小容量と最大容量](AutoScaling-Policies.md#AutoScaling-MinMax)」を参照してください。
+ --max-capacity – ElastiCache の自動スケーリングで管理するレプリカの最大数。—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 の自動スケーリングで管理するレプリカの最小数。—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` という名前のクラスターを登録します。この登録は、クラスターが 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 または アプリケーションの 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 または アプリケーションの 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)
+ [Valkey と Redis OSS に対応した ElastiCache クラスターへのスケーリングポリシーの適用](#AutoScaling-Applying-Policy)
### 事前定義メトリクスの使用
定義済みのメトリクスを使用することにより、ElastiCache Auto Scaling のターゲット追跡で動作する Valkey と Redis OSS に対応した ElastiCache クラスターのターゲット追跡スケーリングポリシーを迅速に定義できます。現在、ElastiCache は、ElastiCache レプリカの自動スケーリングで次の定義済みメトリクスをサポートしています。
`ElastiCacheReplicaEngineCPUUtilization` — すべてのレプリカクラスターでの CloudWatch の EngineCPUUtilization メトリクスの平均値。必要な ReplicationGroupId とロールレプリカに対する集約されたメトリクス値は、CloudWatch の ElastiCache `ReplicationGroupId, Role` で確認できます。
スケーリングポリシーで事前定義メトリクスを使用するには、スケーリングポリシーのターゲット追跡構成を作成します。この設定は、事前定義メトリクスの `PredefinedMetricSpecification` と、そのメトリクスのターゲット値の `TargetValue` が含まれている必要があります。
### カスタムメトリクスの使用
カスタムメトリクスを使用することで、カスタム要件を満たすターゲット追跡スケーリングポリシーを定義できます。スケーリングに比例して変化する、Valkey と Redis OSS に対応した ElastiCache メトリクスに基づいて、カスタムメトリクスを定義することができます。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` 事前定義メトリクスを使用して、そのクラスター内の全レプリカでの平均 CPU 使用率 40% に基づいてクラスターが調整されます。この設定では、10 分間のスケールインのクールダウン期間と 5 分間のスケールアウトのクールダウン期間が提供されます。
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
### スケールインアクティビティの無効化
スケールインアクティビティを無効にすることにより、ターゲット追跡スケーリングポリシー設定が Valkey と Redis OSS に対応した ElastiCache クラスターでスケールインされないようにできます。スケールインアクティビティを無効にすると、スケーリングポリシーによってレプリカが削除されることなく、スケーリングポリシーによって必要に応じて追加されます。
`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
}
```
### Valkey と Redis OSS に対応した ElastiCache クラスターへのスケーリングポリシーの適用
クラスターを Valkey と Redis OSS に対応した ElastiCache の自動スケーリングに登録し、スケーリングポリシーを定義した後、登録されたクラスターにスケーリングポリシーを適用します。Valkey と Redis OSS に対応した ElastiCache クラスターにスケーリングポリシーを適用するには、AWS CLI または Application Auto Scaling API を使用できます。
** の使用AWS CLI**
スケーリングポリシーを Valkey と Redis OSS に対応した ElastiCache クラスターに適用するには、次のパラメータを指定して [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 に設定します。
+ —scalle-dimension — この値は `elasticache:replication-group:Replicas` に設定します。
+ --target-tracking-scaling-policy-configuration — クラスターに使用するターゲット追跡スケーリングポリシー設定。
**Example**
次の例では、`myscalablepolicy` というターゲット追跡スケーリングポリシーを、`myscalablecluster` という名前のクラスターに ElastiCache の自動スケーリングを使用して適用します。そのためには、`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 を使用する**
アプリケーションの Auto Scaling API を使用してスケーリングポリシーを ElastiCache クラスターに適用するには、以下のパラメータを指定して、[PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) アプリケーションの Auto Scaling API オペレーションを使用します。
+ PolicyName – スケーリングポリシーの名前。
+ PolicyType — この値は `TargetTrackingScaling` に設定します。
+ ResourceID — クラスターのリソース識別子。このパラメータでは、リソースタイプは ReplicationGroup で、一意の識別子は ElastiCache for Redis OSS クラスターの名前 (`replication-group/myscalablecluster` など) です。
+ ServiceNamespace – この値は elasticache に設定します。
+ ScalableDimension — この値は `elasticache:replication-group:Replicas` に設定します。
+ TargetTrackingScalingPolicyConfiguration — クラスターに使用するターゲット追跡スケーリングポリシー設定。
**Example**
次の例では、`scalablepolicy` というターゲット追跡スケーリングポリシーを、`myscalablecluster` という名前のクラスターに ElastiCache の自動スケーリングを使用して適用します。`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 マネジメントコンソール、AWS CLI、または アプリケーションの Auto Scaling API を使用してスケーリングポリシーを編集できます。
**AWS マネジメントコンソール を使用したスケーリングポリシーの編集**
AWS マネジメントコンソール を使用して、事前定義されたメトリクスタイプのポリシーのみを編集できます。
1. AWS マネジメントコンソール にサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. ポリシーを追加するクラスターを選択します (クラスター名の左にあるボタンではなく、クラスター名を選択)。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. **[Scaling policies]** (スケーリングポリシー) で、変更する Auto Scaling ポリシーの左にあるボタンを選択して、**[Modify]** (変更) を選択します。
1. ポリシーに必要な変更を行います。
1. **[Modify]** (変更) を選択します。
1. ポリシーを変更します。
1. **[Modify]** (変更) を選択します。
**AWS CLI または アプリケーションの Auto Scaling API を使用したスケーリングポリシーの編集**
AWS CLI または アプリケーションの Auto Scaling API を使用して、スケーリングポリシーを適用するのと同じ方法でスケーリングポリシーを編集できます。
+ アプリケーションの Auto Scaling API を使用する場合は、編集するポリシーの名前を `PolicyName` パラメータで指定します。変更するパラメータの新しい値を指定します。
詳細については、「[Valkey と Redis OSS に対応した ElastiCache クラスターへのスケーリングポリシーの適用](AutoScaling-Defining-Policy.md#AutoScaling-Applying-Policy)」を参照してください。
# スケーリングポリシーの削除
AWS マネジメントコンソール、AWS CLI、または アプリケーションの Auto Scaling API を使用してスケーリングポリシーを削除できます。
**AWS マネジメントコンソール を使用したスケーリングポリシーの削除**
AWS マネジメントコンソール を使用して、事前定義されたメトリクスタイプのポリシーのみを編集できます。
1. AWS マネジメントコンソール にサインインして、Amazon ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. Auto Scaling ポリシーを削除するクラスターを選択します。
1. [**Auto Scaling ポリシー**] タブを選択します。
1. **[Scaling policies]** (スケーリングポリシー) で、Auto Scaling ポリシーを選択してから **[Delete]** (削除) を選択します。
**AWS CLI または アプリケーションの Auto Scaling API を使用したスケーリングポリシーの削除**
AWS CLI または Application Auto Scaling API を使用して、ElastiCache クラスターからスケーリングポリシーを削除できます。
** CLI**
スケーリングポリシーを Valkey と Redis OSS に対応した ElastiCache クラスターから削除するには、次のパラメータを指定して [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 に設定します。
+ —scalle-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**。
スケーリングポリシーを Valkey と Redis OSS に対応した ElastiCache クラスターから削除するには、次のパラメータを指定して [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 Auto Scaling 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
```
# スケジュールされたスケーリング
スケジュールに基づくスケーリングにより、予想可能な需要の変化に応じてアプリケーションを拡張することができます。スケジュールに基づくスケーリングを使用するには、指定された時間にスケーリングアクティビティを行うよう Valkey と Redis OSS に対応した ElastiCache に指示する、スケジュールされたアクションを作成します。スケジュールされたアクションを作成するときに、既存の 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) の 2 つのオペレーションモードがあります。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 クラスターを作成し、スタックがそのクラスターで動作する準備ができていることを確認します。ElastiCache for Redis OSS には、準備が整っていることを確認する方法はありません。詳細については、「[Valkey または Redis OSS 用のクラスターの作成](Clusters.Create.md)」を参照してください。
1. **既存の CMD クラスター設定をクラスターモード互換に変更** – このモードでは、1 つのシャードがデプロイされ、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 マネジメントコンソールを使用し、「[レプリケーショングループの変更](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 マネジメントコンソールを使用し、「[レプリケーショングループの変更](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 マネジメントコンソールを使用し、「[レプリケーショングループの変更](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リージョン間のレプリケーション
**注記**
グローバルデータストアは現在、ノードベースのクラスターでのみ使用できます。
Global Datastore 機能を使用すると、AWSリージョン間でフルマネージド型、高速、信頼性が高く、安全な Valkey または Redis OSS クラスターレプリケーションを操作できます。この機能を使用すると、クロスリージョンリードレプリカクラスターを作成して、AWSリージョン間で低レイテンシーの読み取りとディザスタリカバリを有効にできます。
次のセクションでは、Global Datastore の操作方法について説明します。
**Topics**
+ [概要:](#Redis-Global-Data-Stores-Overview)
+ [前提条件と制限](Redis-Global-Datastores-Getting-Started.md)
+ [Global Datastore の使用 (コンソール)](Redis-Global-Datastores-Console.md)
+ [Global Datastore の使用 (CLI)](Redis-Global-Datastores-CLI.md)
## 概要:
各 *Global Datastore* は、互いにレプリケートする 1 つ以上のクラスターの集合です。
Global datastore は、次のもので構成されます。
+ [**プライマリ (アクティブ) クラスター**] – プライマリクラスターは、Global Datastore 内のすべてのクラスターにレプリケートされる書き込みを受け入れます。プライマリクラスターは、読み込みリクエストも受け入れます。
+ [**セカンダリ (パッシブ) クラスター**] – セカンダリクラスターは、読み取りリクエストのみを受け入れ、プライマリクラスターからのデータ更新をレプリケートします。セカンダリクラスターは、プライマリクラスターとは異なるAWSリージョンに存在する必要があります。
ElastiCache for Valkey または ElastiCache for Redis OSS でグローバルデータストアを作成すると、プライマリクラスターからセカンダリクラスターにデータが自動的にレプリケートされます。Valkey または Redis OSS データをレプリケートするAWSリージョンを選択し、そのAWSリージョンにセカンダリクラスターを作成します。その後、ElastiCache は、2 つのクラスター間でデータの自動非同期レプリケーションをセットアップおよび管理します。
Valkey または Redis OSS で Global Datastore を使用すると、次の利点があります。
+ **地理的パフォーマンス** – 追加のAWSリージョンでリモートレプリカクラスターを設定し、それらのリージョン間でデータを同期することで、そのAWSリージョンのデータアクセスのレイテンシーを短縮できます。グローバルデータストアは、AWSリージョン間で低レイテンシーの地理ローカル読み取りを提供することで、アプリケーションの応答性を高めるのに役立ちます。
+ [**災害対策**] – Global Datastore 内のプライマリクラスターでパフォーマンスが低下した場合は、セカンダリクラスターを新しいプライマリクラスターとして昇格させることができます。これを行うには、セカンダリクラスターを含む任意のAWSリージョンに接続します。
次の図は、Global Datastore がどのように機能するかを示しています。
![\[Global Datastore\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/Global-DataStore.png)
# 前提条件と制限
Global Datastore を開始する前に、次の点に注意してください。
+ グローバルデータストアは、次の AWS リージョンでサポートされています。
+ **アフリカ** - ケープタウン
+ **アジアパシフィック** - 香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、タイ、東京
+ **カナダ** - カナダ中部およびカナダ西部 (カルガリー)
+ **中国** - 北京および寧夏
+ **欧州** - フランクフルト、ロンドン、アイルランド、ミラノ、パリ、スペイン、ストックホルム、チューリッヒ
+ **AWS GovCloud** - 米国西部および米国東部
+ **イスラエル** - テルアビブ
+ **中東** - バーレーンおよびアラブ首長国連邦
+ **米国** - 東部 (バージニア北部およびオハイオ) および米国西部 (北カリフォルニアおよびオレゴン)
+ **南米** - メキシコ (中部) およびサンパウロ
+ グローバルデータストア内のすべてのクラスター (プライマリとセカンダリ) は、プライマリノードの数、ノードタイプ、エンジンバージョン、およびシャードの数が同じである必要があります (クラスターモードが有効な場合)。Global Datastore 内の各クラスターには、そのクラスターのローカルな読み取りトラフィックに対応するために、異なる数のリードレプリカを設定できます。
既存の単一ノードクラスターを使用する場合は、レプリケーションを有効にする必要があります。
+ Global Datastore は、サイズがラージ以上のインスタンスでサポートされています。
+ 1 つの AWS リージョンから、最大 2 つの他の AWS リージョン内のセカンダリクラスターへのプライマリクラスターのレプリケーションをセットアップできます。
**注記**
この例外は、中国 (北京) リージョンと中国 (寧夏) リージョンであり、レプリケーションは 2 つのリージョン間でしか発生しません。
+ Global Datastore は VPC クラスターのみで操作できます。詳細については、「[Amazon VPC の ElastiCache キャッシュにアクセスするためのアクセスパターン](elasticache-vpc-accessing.md)」を参照してください。EC2-Classic を使用する場合、Global Datastore はサポートされません。詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2-Classic](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-classic-platform.html)」を参照してください。
**注記**
現時点では、[ElastiCache での Local Zones の使用](Local_zones.md) でグローバルデータストアを使用することはできません。
+ ElastiCache は、1 つの AWS リージョンから別のリージョンへの自動フェイルオーバーをサポートしていません。必要に応じて、セカンダリクラスターを手動で昇格できます。例については、[セカンダリクラスターのプライマリへの昇格](Redis-Global-Datastores-Console.md#Redis-Global-Datastores-Console-Promote-Secondary)を参照してください。
+ 既存のデータからブートストラップするには、既存のクラスターをプライマリとして使用して、Global Datastore を作成します。既存のクラスターをセカンダリとして追加することはできません。クラスターをセカンダリとして追加するプロセスでは、データが消去されるため、データが失われる可能性があります。
+ Global Datastore に属するクラスターのローカルパラメータグループを変更すると、パラメータ更新がすべてのクラスターに適用されます。
+ リージョンクラスターは、垂直方向 (スケールアップとスケールダウン) と水平方向 (スケールインとスケールアウト) の両方でスケールできます。Global Datastore を変更することで、クラスターを拡張できます。Global Datastore 内のすべてのリージョンクラスターは、中断することなく拡張されます。詳細については、「[ElastiCache のスケーリング](Scaling.md)」を参照してください。
+ Global Datastore は、[保管時の暗号化](at-rest-encryption.md)、[転送中の暗号化](in-transit-encryption.md)、および [AUTH](auth.md) をサポートします。
+ Global Datastore は、インターネットプロトコルバージョン 6 (IPv6) をサポートしていません。
+ グローバルデータストアは AWS KMS キーをサポートします。詳細については、*AWS Key Management Service デベロッパーガイド*の「[AWS キー管理サービスの概念](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)」を参照してください。
**注記**
Global Datastore では、次の条件で [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 リージョンのサブスクライバーがイベントを受け取ります。
# Global Datastore の使用 (コンソール)
コンソールを使用して Global Datastore を作成するには、次の 2 つのステップから成るプロセスに従います。
1. 既存のクラスターを使用するか、新しいクラスターを作成して、プライマリクラスターを作成します。エンジンは Valkey 7.2 以降、または Redis OSS 5.0.6 以降である必要があります。
1. Valkey 7.2 以降、または Redis OSS 5.0.6 以降を使用して、別の AWS リージョンに最大 2 つのセカンダリクラスターを追加します。
次の手順は、Valkey または Redis OSS 用の Global Datastore を作成し、ElastiCache コンソールを使用して他のオペレーションを実行する方法を示しています。
**Topics**
+ [既存のクラスターを使用した Global Datastore の作成](#Redis-Global-Datastores-Console-Create-Primary)
+ [新しいプライマリクラスターを使用した新しい Global Datastore の作成](#Redis-Global-Datastores-Create-From-Scratch)
+ [Global Datastore 詳細の表示](#Redis-Global-Datastores-Console-Details)
+ [Global Datastore へのリージョンの追加](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Global Datastore の変更](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
+ [セカンダリクラスターのプライマリへの昇格](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Global Datastore からのリージョンの削除](#Redis-Global-Datastore-Console-Remove-Region)
+ [Global Datastore の削除](#Redis-Global-Datastores-Console-Delete-GlobalDatastore)
## 既存のクラスターを使用した Global Datastore の作成
このシナリオでは、既存のクラスターを使用して、新しい Global Datastore のプライマリとして機能させます。次に、別の AWS リージョンに読み取り専用セカンダリクラスターを作成します。このセカンダリクラスターは、プライマリクラスターから自動更新と非同期更新を受け取ります。
**重要**
既存のクラスターは、Valkey 7.2 以降または Redis OSS 5.0.6 以降のエンジンを使用する必要があります。
**既存のクラスターを使用して Global Datastore を作成するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択し、**[グローバルデータストアを作成]** を選択します。
1. **[プライマリクラスターの設定]** ページで、以下の操作を行います。
+ **[グローバルデータストアに関する情報]** フィールドに、新しいグローバルデータストアの名前を入力します。
+ (省略可能) [**説明**] の値を入力します。
1. **[リージョン別クラスター]** で、**[既存のリージョンクラスターを使用]** を選択します。
1. **[既存のクラスター]** で、使用する既存のクラスターを選択します。
1. 次のオプションをそのまま使用します。これらは、プライマリクラスターの設定に合わせて事前に設定されていて、変更することはできません。
+ エンジンバージョン
+ ノードの種類
+ パラメータグループ
**注記**
ElastiCache は、指定されたパラメータグループの値から新しいパラメータグループを自動生成し、新しいパラメータグループをクラスターに適用します。この新しいパラメータグループを使用して、Global Datastore のパラメータを変更します。自動生成された各パラメータグループは、1 つの唯一のクラスターにのみ関連付けられます。したがって、1 つの唯一の Global Datastore にのみ関連付けられます。
+ シャード数
+ 保管時の暗号化 – ディスクに保存されているデータの暗号化を有効にします。詳細については、「[保管時の暗号化](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)」を参照してください。
+ **[認証デフォルトユーザー]** – Valkey または Redis OSS サーバーの認証メカニズム。詳細については、「[AUTH](auth.md)」を参照してください。
1. (オプション) 必要に応じて、残りのセカンダリクラスター設定を更新します。プライマリクラスターと同じ値が事前に入力されていますが、そのクラスターの特定の要件を満たすように更新できます。
+ ポート
+ レプリケーション数
+ サブネットグループ
+ 優先アベイラビリティーゾーン
+ セキュリティグループ
+ カスタマーマネージド (AWS KMS キー)
+ 認証トークン
+ 自動バックアップの有効化
+ バックアップの保存期間
+ バックアップウィンドウ
+ メンテナンスウィンドウ
+ SNS 通知のトピック
1. **[作成]** を選択します。これにより、Global Datastore のステータスが [**Creating**] に設定されます。プライマリクラスターがグローバルデータストアに関連付けられ、セカンダリクラスターが [**関連付け**] ステータスになった後、ステータスは [**変更中**] に移行します。
プライマリクラスターとセカンダリクラスターを Global Datastore に関連付けると、ステータスが [**Available**] に変わります。この時点で、読み取りと書き込みを受け入れるプライマリクラスターと、プライマリクラスターからレプリケートされた読み取りを受け入れるセカンダリクラスターがあります。
ページが更新され、以下を含めて、クラスターが Global Datastore の一部であるかどうかが示されます。
+ [**Global Datastore**] – クラスターが属する Global Datastore の名前。
+ [**Global Datastore Role**] – クラスターのロール (プライマリまたはセカンダリ)。
別の AWS リージョンに最大 1 つのセカンダリクラスターを追加できます。詳細については、「[Global Datastore へのリージョンの追加](#Redis-Global-Datastores-Console-Create-Secondary)」を参照してください。
## 新しいプライマリクラスターを使用した新しい Global Datastore の作成
新しいクラスターがある Global Datastore を作成する場合は、次の手順を実行します。
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択し、**[グローバルデータストアを作成]** を選択します。
1. **[Primary cluster settings]** (プライマリクラスターの設定) で、次の作業を行います。
1. **[Cluster mode]** (クラスターモード) で、**[Enabled]** (有効) または **[Disabled]** (無効) を選択します。
1. **[Global Datastore info]** (グローバルデータストアに関する情報) で、**[Name]** (名前) の値を入力します。ElastiCache は、このサフィックスを使用して、Global Datastore の一意の名前を生成します。ここで指定するサフィックスを使用して、グローバルデータストアを検索できます。
1. (オプション) [**Global Datastore Description**] に値を入力します。
1. **[Regional cluster]** (リージョンクラスター) で、次の作業を行います。
1. **[Region]** (リージョン) で、使用可能な AWS リージョンを選択します。
1. **[Create new regional cluster]** (新しいリージョンクラスターを作成) または **[Use existing regional cluster]** (既存のリージョンクラスターを使用) を選択します。
1. **[Create new regional cluster]** (新しいリージョンクラスターを作成) を選択した場合は、**[Cluster info]** (クラスター情報) で、クラスターの名前と説明 (オプション) を入力します。
1. **[Location]** (場所) で、**[Multi-AZ]** (マルチ 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)」を参照してください。
**注記**
パラメータグループを選択してエンジン設定値を設定すると、そのパラメータグループが Global Datastore 内のすべてのクラスターに適用されます。**[パラメータグループ]** ページの yes/no **[グローバル]** 属性は、パラメータグループがグローバルデータストアの一部であるかどうかを示します。
1. **[ノードタイプ]** で、下向き矢印 (![\[Downward-pointing triangle icon, typically used to indicate a dropdown menu.\]](http://docs.aws.amazon.com/ja_jp/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 が有効になっている場合は、シャードごとに少なくとも 1 つのレプリカがあることを確認してください。
+ コンソールを使用してクラスターを作成する場合、シャードごとのレプリカ数は同じになります。
+ シャードあたりのリードレプリカ数は固定され、変更できません。シャード (API/CLI: ノードグループ) あたりのレプリカ数を増減する必要がある場合は、新しいレプリカ数で新しいクラスターを作成する必要があります。詳細については、「[チュートリアル: 外部で作成されたバックアップで新しいノードベースのクラスターをシードする](backups-seeding-redis.md)」を参照してください。
1. **[Subnet group settings]** (サブネットグループ設定) で、このクラスターに適用するサブネットを選択します。ElastiCache はデフォルトの IPv4 サブネットグループを提供しています。または、新しいサブネットグループを作成することもできます。IPv6 の場合は、IPv6 CIDR ブロックを使用するサブネットグループを作成する必要があります。デュアルスタックを選択した場合は、**[Discovery IP type]** (検出 IP タイプ) (IPv6 または IPv4) を選択する必要があります。
詳細については、「[VPC にサブネットを作成する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)」を参照してください。
1. **[Availability zone placements]** (アベイラビリティーゾーンの配置) には 2 つのオプションがあります。
+ **[指定なし]** – ElastiCache がアベイラビリティーゾーンを選択します。
+ [**アベイラビリティーゾーンの指定**] – 各クラスターに対するアベイラビリティーゾーンを指定します。
アベイラビリティーゾーンの指定を選択した場合、クラスターのシャードごとにリストからアベイラビリティーゾーンを選択します。
詳細については、「[ElastiCache のリージョンとアベイラビリティーゾーンの選択](RegionsAndAZs.md)」を参照してください。
![\[イメージ: キースペースとアベイラビリティーゾーンの指定\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCache-ClusterOn-Slots-AZs.png)
*キースペースとアベイラビリティーゾーンの指定*
1. **[Next]** (次へ) を選択します。
1. **[Valkey および Redis OSS の詳細設定]** の下
1. **[Security]** (セキュリティ):
1. データを暗号化するには、次のオプションがあります。
+ **保管時の暗号化** – ディスクに保存されているデータの暗号化を有効にします。詳細については、「[保管時の暗号化](at-rest-encryption.md)」を参照してください。
**注記**
別の暗号化キーを指定するには、[**カスタマー管理の AWS KMS キー**] を選択し、キーを選択することもできます。詳細については、「[AWS KMS のカスタマー管理の CMK の使用](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)」を参照してください。
+ **[認証デフォルトユーザー]** – Valkey または Redis OSS サーバーの認証メカニズム。詳細については、「[AUTH](auth.md)」を参照してください。
+ **[認証]** – Valkey または Redis OSS サーバーの認証メカニズム。詳細については、「[AUTH](auth.md)」を参照してください。
**注記**
3.2.6 以降の Redis OSS バージョン (バージョン 3.2.10 を除く) では、[認証] のみがオプションとなります。
1. **セキュリティグループ** で、このクラスターに必要なセキュリティグループを選択します。*セキュリティグループ*は、クラスターへのネットワークアクセスを制御するためのファイアウォールとして機能します。VPC のデフォルトのセキュリティグループを使用するか、新しいセキュリティグループを作成できます。
VPC セキュリティグループの詳細については、*Amazon VPC ユーザーガイド*の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
1. 自動バックアップを定期的にスケジュールする場合は、**[自動バックアップの有効化]** を選択し、自動バックアップを保持して自動的に削除するまでの日数を入力します。自動バックアップを定期的にスケジュールしない場合は、**[自動バックアップを有効化]** チェックボックスをオフにします。いずれの場合も、常に手動バックアップを作成するオプションがあります。
バックアップと復元の詳細については、「[スナップショットおよび復元](backups.md)」を参照してください。
1. (オプション) メンテナンスウィンドウを指定します。*[メンテナンスウィンドウ]* は、ElastiCache がクラスターのシステムメンテナンスを毎週スケジュールする時間の長さ (通常は 1 時間単位) です。ElastiCache がメンテナンスの日時を選択することを許可するか (*[No preference]* (指定なし))、自分で日時と期間を選択できます (*[Specify maintenance window]* (メンテナンスウィンドウを指定))。リストから *[メンテナンス期間を指定]* を選択した場合は、メンテナンス期間の*開始日*、*開始時刻*および*所要時間* (時間単位) を選択します。すべての時刻は協定世界時 (UCT) です。
詳細については、「[ElastiCache クラスターメンテナンスの管理](maintenance-window.md)」を参照してください。
1. (オプション) **[ログ]**:
+ [**ログの形式**] の下で、[**テキスト**] または [**JSON**] を選択します。
+ **[送信先のタイプ]** の下で、**[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 は、指定されたパラメータグループの値から新しいパラメータグループを自動生成し、新しいパラメータグループをクラスターに適用します。この新しいパラメータグループを使用して、Global Datastore のパラメータを変更します。自動生成された各パラメータグループは、1 つの唯一のクラスターにのみ関連付けられます。したがって、1 つの唯一の Global Datastore にのみ関連付けられます。
+ 保管時の暗号化 – ディスクに保存されているデータの暗号化を有効にします。詳細については、「[保管時の暗号化](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)」を参照してください。
+ **[認証デフォルトユーザー]** – Valkey または Redis OSS サーバーの認証メカニズム。詳細については、「[AUTH](auth.md)」を参照してください。
**注記**
Redis OSS バージョン 4.0.2 (転送中の暗号化が最初にサポートされた) とバージョン 6.0.4 の間では、[認証] が唯一のオプションです。
セカンダリクラスターの残りの設定には、プライマリクラスターと同じ値が事前に入力されますが、そのクラスターの特定の要件を満たすように以下の項目を更新できます。
+ ポート
+ レプリケーション数
+ サブネットグループ
+ 優先アベイラビリティーゾーン
+ セキュリティグループ
+ カスタマーマネージド (AWS KMS キー)
+ 認証トークン
+ 自動バックアップの有効化
+ バックアップの保存期間
+ バックアップウィンドウ
+ メンテナンスウィンドウ
+ SNS 通知のトピック
1. **[作成]** を選択します。これにより、Global Datastore のステータスが [**Creating**] に設定されます。プライマリクラスターとセカンダリクラスターを Global Datastore に関連付けると、ステータスが [**Available**] に変わります。読み取りと書き込みを受け入れるプライマリクラスターと、プライマリクラスターからレプリケートされた読み取りを受け入れるセカンダリクラスターを用意しました。
また、ページが更新され、以下を含めて、クラスターが Global Datastore の一部であるかどうかが示されます。
+ [**Global Datastore**] – クラスターが属する Global Datastore の名前。
+ [**Global Datastore Role**] – クラスターのロール (プライマリまたはセカンダリ)。
別の AWS リージョンに最大 1 つのセカンダリクラスターを追加できます。詳細については、「[Global Datastore へのリージョンの追加](#Redis-Global-Datastores-Console-Create-Secondary)」を参照してください。
## Global Datastore 詳細の表示
既存の Global Datastore の詳細を表示し、**[グローバルデータストア]** ページで詳細を変更することもできます。
**Global Datastore の詳細を表示するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択し、使用可能な Global Datastore を選択します。
続いて、次の Global Datastore プロパティを調べることができます。
+ **Global Datastore 名:** Global Datastore の名前
+ **説明:** Global Datastore の説明
+ **ステータス:** 次のオプションがあります。
+ 作成
+ 変更中
+ 利用可能
+ [削除中]
+ [Primary-Only] - このステータスは、Global Datastore にプライマリクラスターのみが含まれていることを示します。すべてのセカンダリクラスターが削除されるか、正常に作成されません。
+ **クラスターモード:** 有効または無効のいずれか
+ **エンジンバージョン:** Global Datastore を実行する Valkey または Redis OSS エンジンバージョン
+ **インスタンスノードタイプ:** Global Datastore に使用されるノードタイプ
+ **保存時の暗号化:** 有効または無効のいずれか
+ **転送時の暗号化:** 有効または無効のいずれか
+ **認証:** 有効または無効のいずれか
Global Datastore に対して次の変更を行うことができます。
+ [Global Datastore へのリージョンの追加](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Global Datastore からのリージョンの削除](#Redis-Global-Datastore-Console-Remove-Region)
+ [セカンダリクラスターのプライマリへの昇格](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Global Datastore の変更](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
[Global Datastore] ページには、Global Datastore を構成する個々のクラスターと、それぞれの次のプロパティも一覧表示されます。
+ [**Region**] - クラスターが保存されている AWS リージョン
+ [**Role**] - プライマリまたはセカンダリのいずれか
+ [**Cluster name**] - クラスターの名前
+ [**Status**] - 次のオプションがあります。
+ [**Associating**] - クラスターを Global Datastore に関連付けています。
+ [**Associated**] - クラスターは Global Datastore に関連付けられています。
+ [**Disassociating**] - Global Datastore 名を使用して、Global Datastore からセカンダリクラスターを削除するプロセス。その後、セカンダリクラスターはプライマリクラスターから更新を受信しなくなりますが、その AWS リージョンでスタンドアロンクラスターとして残ります。
+ [**Disassociated**] - セカンダリクラスターは Global Datastore から削除され、その AWS リージョンでスタンドアロンクラスターになりました。
+ [**Global Datastore Replica lag**] – Global Datastore のセカンダリ AWS リージョンごとに 1 つの値を表示します。これは、セカンダリリージョンのプライマリノードとプライマリリージョンのプライマリノード間の遅延です。クラスターモードが有効な Valkey または Redis OSS の場合、遅延はシャード間の最大遅延 (秒単位) を示します。
## Global Datastore へのリージョンの追加
既存の Global Datastore に AWS リージョンを 1 つまで追加できます。このシナリオでは、プライマリクラスターから自動更新と非同期更新を受け取る別の AWS リージョンに読み取り専用クラスターを作成します。
**AWS リージョンを Global Datastore に追加するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択し、既存の Global Datastore を選択します。
1. **[リージョン別クラスターを追加]** を選択し、セカンダリクラスターを配置する AWS リージョンを選択します。
1. **[クラスター情報]** で、**[名前]** に値を入力し、クラスターの **[説明]** に入力 (任意) します。
1. 次のオプションをそのまま使用します。これらは、プライマリクラスターの設定に合わせて事前に設定されていて、変更することはできません。
+ エンジンバージョン
+ インスタンスタイプ
+ ノードの種類
+ シャード数
+ パラメータグループ
**注記**
ElastiCache は、指定されたパラメータグループの値から新しいパラメータグループを自動生成し、新しいパラメータグループをクラスターに適用します。この新しいパラメータグループを使用して、Global Datastore のパラメータを変更します。自動生成された各パラメータグループは、1 つの唯一のクラスターにのみ関連付けられます。したがって、1 つの唯一の Global Datastore にのみ関連付けられます。
+ 保管中の暗号化
**注記**
別の暗号化キーを指定するには、[**カスタマー管理の AWS KMS キー**] を選択し、キーを選択します。
+ 転送中の暗号化
+ AUTH
1. (オプション) セカンダリクラスターの残りの設定を更新します。プライマリクラスターと同じ値が事前に入力されますが、そのクラスターの特定の要件を満たすように設定を更新できます。
+ ポート
+ レプリケーション数
+ サブネットグループ
+ 優先アベイラビリティーゾーン
+ セキュリティグループ
+ カスタマーマネージド AWS KMS キー。
+ 認証トークン
+ 自動バックアップの有効化
+ バックアップの保存期間
+ バックアップウィンドウ
+ メンテナンスウィンドウ
+ SNS 通知のトピック
1. **[Add]** (追加) を選択します。
## Global Datastore の変更
リージョンクラスターのプロパティを変更できます。Global Datastore で実行できる変更オペレーションは 1 つだけです。ただし、セカンダリクラスターをプライマリに昇格させることは例外です。詳細については、「[セカンダリクラスターのプライマリへの昇格](#Redis-Global-Datastores-Console-Promote-Secondary)」を参照してください。
**Global Datastore を変更するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択し、**[グローバルデータストア名]** で Global Datastore を選択します。
1. [**Modify**] を選択し、次のオプションの中から選択します。
+ [**Modify description**] – Global Datastore の説明を更新します
+ **[エンジンバージョンを変更]** – Valkey 7.2 以降または Redis OSS 5.0.6 以降のみ使用できます。
+ [**Modify node type**] – リージョンクラスターを垂直方向 (スケールアップとスケールダウン) と水平方向 (スケールインとスケールアウト) の両方にスケールします。オプションには、R5 および M5 ノードファミリーがあります。ノードタイプの詳細については、「[サポートされているノードの種類](CacheNodes.SupportedTypes.md)」を参照してください。
+ [**自動フェイルオーバーの変更**] — 自動フェイルオーバーを有効または無効にします。フェイルオーバーを有効にし、リージョンクラスターのプライマリノードが予期せずシャットダウンすると、ElastiCache はリージョンレプリカの 1 つにフェイルオーバーします。詳細については、「[Auto Failover](AutoFailover.md)」を参照してください。
クラスターモードが有効になっている Valkey または Redis OSS クラスターの場合:
+ [**Add shards**] – 追加するシャードの数を入力し、オプションで 1 つ以上のアベイラビリティーゾーンを指定します。
+ [**Delete shards**] – 各 AWS リージョンで削除するシャードを選択します。
+ [**Rebalance shards**] – スロット配分を再分散して、クラスター内の既存のシャード間で均一な分散を確保します。
Global Datastore のパラメータを変更するには、Global Datastore のメンバークラスターのパラメータグループを変更します。ElastiCache は、この変更を Global Datastore 内のすべてのクラスターに自動的に適用します。そのクラスターのパラメータグループを変更するには、Valkey または Redis OSS コンソールまたは [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) API オペレーションを使用します。詳細については、「[ElastiCache パラメータグループを変更する](ParameterGroups.Modifying.md)」を参照してください。Global Datastore に含まれているクラスターのパラメータグループを変更すると、その Global Datastore 内のすべてのクラスターに適用されます。
パラメータグループ全体または特定のパラメータをリセットするには、[ResetCacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ResetCacheParameterGroup.html) API オペレーションを使用します。
## セカンダリクラスターのプライマリへの昇格
プライマリクラスターまたは AWS リージョンが利用できなくなった場合や、パフォーマンスの問題が発生している場合は、セカンダリクラスターをプライマリに昇格させることができます。昇格は、他の変更が進行中であっても、いつでも許可されます。複数のプロモーションを並行して発行することもできます。Global Datastore は、最終的に 1 つのプライマリに解決されます。複数のセカンダリクラスターを同時に昇格させる場合、ElastiCache では最終的にどのクラスターがプライマリに解決されるかは保証しません。
**セカンダリクラスターをプライマリクラスターに昇格するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択します。
1. Global Datastore 名を選択して詳細を表示します。
1. [**Secondary**] クラスターを選択します。
1. [**Promote to primary**] を選択します。
続いて、次の警告が表示され、決定を確認するように求められます: ` 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. 昇格を続行する場合は [**確認**] を、続行しない場合は [**キャンセル**] を選択します。
確認を選択した場合、Global Datastore は [**Modifying**] 状態に変わり、昇格が完了するまで使用できなくなります。
## Global Datastore からのリージョンの削除
次の手順を使用して、Global Datastore から AWS リージョンを削除できます。
**Global Datastore から AWS リージョンを削除するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択します。
1. [Global Datastore] を選択します。
1. 削除する [**Region**] を選択します。
1. [**Remove region**] を選択します。
**注記**
このオプションは、セカンダリクラスターでのみ使用できます。
続いて、次の警告が表示され、決定を確認するように求められます: ` 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 リージョンが削除され、セカンダリクラスターはレプリケーション更新を受信しなくなります。
## Global Datastore の削除
Global Datastore を削除するには、まずすべてのセカンダリクラスターを削除します。詳細については、「[Global Datastore からのリージョンの削除](#Redis-Global-Datastore-Console-Remove-Region)」を参照してください。これにより、Global Datastore のステータスは [**primary-only**] になります。
**Global Datastore を削除するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[グローバルデータストア]** を選択します。
1. [**Global Datastore Name**] で、削除する Global Datastore を選択し、[**削除**] を選択します。
続いて、次の警告が表示され、決定を確認するように求められます: `Are you sure you want to delete this Global Datastore?`。
1. **[削除]** を選択します。
Global Datastore が [**Deleting**] ステータスに変わります。
# Global Datastore の使用 (CLI)
AWS Command Line Interface (AWS CLI) を使用すると、複数の AWS のサービスをコマンドラインから制御したり、スクリプトで自動化したりできます。AWS CLI は、アドホック (ワンタイム) オペレーションに使用できます。
## AWS CLI のダウンロードと設定
AWS CLI は、Windows、macOS または Linux 上で作動します。これをダウンロードして設定するには、次の手順に従います。
**CLI をダウンロード、インストール、設定するには**
1. [[AWS コマンドラインインターフェイス](https://aws.amazon.com/cli)] のウェブページで AWS CLI をダウンロードします。
1. [*AWS Command Line Interface ユーザーガイド*] の AWS CLI のインストールおよび AWS の CLIの設定の手順に従います。
## Global Datastore での AWS CLI の使用
Global Datastore を操作するには、次の 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 は、Global Datastore ID の作成時にプレフィックスを自動的に適用します。各 AWS リージョンには独自のプレフィックスがあります。例えば、米国西部 (北カルフォルニア) リージョンで作成された Global Datastore ID は、指定したサフィックス名と共に「virxk」で始まります。サフィックスは、自動生成されたプレフィックスと組み合わされて、複数のリージョンにまたがるグローバルデータストア名の一意性を保証します。
以下のテーブルは、各 AWS リージョンとその Global Datastore ID プレフィックスを一覧表示します。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/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 Datastore の名前を `--global-replication-group-id` パラメータに指定することで、Global Datastore のセカンダリクラスターを作成します。
```
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 または ElastiCache for Redis OSS で使用可能なすべてのコマンドを一覧表示します。
```
aws elasticache help
```
また、ヘルプを使用して、特定コマンドを記述したり、その用法の詳細を確認したりすることもできます。
```
aws elasticache create-global-replication-group help
```
# レプリケーショングループを使用する高可用性
単一ノード Amazon ElastiCache Valkey および Redis OSS クラスターは、データ保護サービス (AOF) が制限されるメモリ内エンティティです。クラスターが何らかの理由で停止すると、クラスターのすべてのデータが失われます。ただし Valkey または Redis OSS エンジンを実行している場合は、2～6 個のノードをクラスターとしてグループ化できます。この場合、1～5 個の読み取り専用ノードには、グループの 1 個の読み書きプライマリノードのレプリカデータが含まれます。このシナリオでは、1 個のノードが何らかの理由で停止した場合でも 1 個以上の他のノードにレプリケートされているので、すべてのデータが失われることがありません。レプリケーションのレイテンシーが原因でプライマリの読み取り/書き込みノードが失敗した場合、一部のデータが失われる可能性があります。
次の図に示されているように、レプリケーション構造はシャード内 (API/CLI では*ノードグループ*と呼ばれる) に含まれ、シャードは Valkey または Redis OSS クラスター内に含まれています。Valkey または Redis OSS (クラスターモードが無効) クラスターには、常に 1 つのシャードがあります。Valkey または Redis OSS (クラスターモードが有効) クラスターは最大 500 個のシャードを持つことができ、クラスターのデータはこれらのシャード間で分割されます。シャードの数が多くレプリカの数が少ないクラスターを作成できます。クラスターあたり最大 90 ノードです。このクラスター設定は、シャード 90 個およびレプリカ 0 個からシャード 15 個およびレプリカ 5 個 (許容されるレプリカの最大数) までです。
ElastiCache for Valkey および Redis OSS 用の ElastiCache バージョン 5.0.6 以降では、ノードまたはシャードの制限をクラスターあたり最大 500 まで増やすことができます。例えば、83 個のシャード (シャードごとに 1 つのプライマリと 5 レプリカ) と 500 個のシャード (プライマリのみでレプリカなし) の範囲で、500 個のノードクラスターを設定できます。増加に対応できる十分な IP アドレスがあることを確認してください。一般的な落とし穴として、サブネットグループ内のサブネットの CIDR 範囲が小さすぎる、またはサブネットが他のクラスターで共有され、頻繁に使用されていることが挙げられます。詳細については、「[サブネットグループの作成](SubnetGroups.Creating.md)」を参照してください。
5.0.6 未満のバージョンの場合、クラスターあたりの制限は 250 個です。
この制限の拡大をリクエストするには、「[AWS のサービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照し、制限タイプとして [**Nodes per cluster per instance type (インスタンスタイプごとのクラスターあたりのノード)**] を選択します。
![\[イメージ: Valkey または Redis OSS (クラスターモードが無効) クラスターに 1 つのシャードと 0〜 5 個のレプリカノードがある\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Valkey または Redis OSS (クラスターモードが無効) クラスターに、1 つのシャードと 0〜 5 個のレプリカノードがある*
マルチ 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 つの方法でレプリケーションが実装されます。
+ クラスターのすべてのデータを各ノードに含む単一シャード — Valkey または Redis OSS (クラスターモードが無効)
+ 最大 500 個のシャード間でデータを分割する — Valkey または Redis OSS (クラスターモードが有効)
レプリケーショングループ内の各シャードには、単一の読み取り/書き込みプライマリノードと、最大 5 個の読み取り専用レプリカノードがあります。シャードの数が多くレプリカの数が少ないクラスターを作成できます。クラスターあたり最大 90 ノードです。このクラスター設定は、シャード 90 個およびレプリカ 0 個からシャード 15 個およびレプリカ 5 個 (許容されるレプリカの最大数) までです。
Redis OSS エンジンのバージョンが 5.0.6 以上の場合、ノードまたはシャードの制限は、クラスターごとに最大 500 個まで増やすことができます。例えば、83 個のシャード (シャードごとに 1 つのプライマリと 5 レプリカ) と 500 個のシャード (プライマリのみでレプリカなし) の範囲で、500 個のノードクラスターを設定できます。増加に対応できる十分な IP アドレスがあることを確認してください。一般的な落とし穴として、サブネットグループ内のサブネットの CIDR 範囲が小さすぎる、またはサブネットが他のクラスターで共有され、頻繁に使用されていることが挙げられます。詳細については、「[サブネットグループの作成](SubnetGroups.Creating.md)」を参照してください。
5.0.6 未満のバージョンの場合、クラスターあたりの制限は 250 個です。
この制限の拡大をリクエストするには、「[AWS のサービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照し、制限タイプとして [**Nodes per cluster per instance type (インスタンスタイプごとのクラスターあたりのノード)**] を選択します。
**Topics**
+ [Valkey または Redis OSS (クラスターモードが無効）](#Replication.Redis.Groups.Classic)
+ [Valkey または Redis OSS (クラスターモードが有効)](#Replication.Redis.Groups.Cluster)
## Valkey または Redis OSS (クラスターモードが無効）
Valkey または Redis OSS (クラスターモードが無効) クラスターには 1 つのシャードがあり、その内部はノードの集合で、1 個の読み取り/書き込みプライマリノードと、最大 5 個の読み取り専用のセカンダリレプリカノードで構成されます。各リードレプリカは、クラスターのプライマリノードにあるデータのコピーを保持します。非同期レプリケーション機能は、リードレプリカとプライマリの同期を維持するのに使用されます。アプリケーションは、クラスター内のどのノードからでも読み取ることができます。アプリケーションは、そのプライマリノードにのみ書き込むことができます。リードレプリカは読み取りスループットを向上させ、ノードの障害発生時のデータ損失に対する保護を強化します。
![\[イメージ: 1 つのシャードと複数のレプリカノードのある Valkey または Redis OSS (クラスターモードが無効) クラスター\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*1 つのシャードと複数のレプリカノードのある 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～500 個のシャード (API/CLI: ノードグループ) で構成されます。各シャードには、読み取り/書き込みプライマリノードと最大 5 個のリードレプリカノードが含まれます。この構成は、シャード 90 個およびレプリカ 0 個からシャード 15 個およびレプリカ 5 個 (許容されるレプリカの最大数) までです。
エンジンバージョンが Valkey 7.2 以上、または Redis OSS 5.0.6 以上の場合、ノードまたはシャードの制限は、クラスターごとに最大 500 個まで増やすことができます。例えば、83 個のシャード (シャードごとに 1 つのプライマリと 5 レプリカ) と 500 個のシャード (プライマリのみでレプリカなし) の範囲で、500 個のノードクラスターを設定できます。増加に対応できる十分な IP アドレスがあることを確認してください。一般的な落とし穴として、サブネットグループ内のサブネットの CIDR 範囲が小さすぎる、またはサブネットが他のクラスターで共有され、頻繁に使用されていることが挙げられます。詳細については、「[サブネットグループの作成](SubnetGroups.Creating.md)」を参照してください。
5.0.6 未満のバージョンの場合、クラスターあたりの制限は 250 個です。
この制限の拡大をリクエストするには、「[AWS のサービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照し、制限タイプとして [**Nodes per cluster per instance type (インスタンスタイプごとのクラスターあたりのノード)**] を選択します。
シャード内の各リードレプリカは、シャードのプライマリからのデータのコピーを維持します。非同期レプリケーション機能は、リードレプリカとプライマリの同期を維持するのに使用されます。アプリケーションは、クラスター内のどのノードからでも読み取ることができます。アプリケーションは、そのプライマリノードにのみ書き込むことができます。リードレプリカは、読み取り拡張性およびデータ損失に対する保護を強化します。データは、Valkey または Redis OSS (クラスターモードが有効) クラスター内のシャード間で分割されます。
アプリケーションは、Valkey または Redis OSS (クラスターモードが有効) クラスターの*設定エンドポイント*を使用して、クラスター内のノードと接続します。詳細については、「[ElastiCache での接続エンドポイントの検索](Endpoints.md)」を参照してください。
![\[イメージ: 複数のシャードとレプリカノードのある Valkey または Redis OSS (クラスターモードが有効) クラスター\]](http://docs.aws.amazon.com/ja_jp/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 以降では、2 つの異なるタイプのクラスター (API/CLI: レプリケーショングループ) のいずれかを作成できます。Valkey または Redis OSS (クラスターモードが無効) クラスターは常に 1 つのシャード (API/CLI: ノードグループ) と最大 5 個のリードレプリカノードで構成されます。Valkey または Redis OSS (クラスターモードが有効) クラスターは、最大 500 個のシャードを持ち、各シャードに 1〜5 個のレプリカノードがあります。
![\[イメージ: Valkey または Redis OSS (クラスターモードが無効) クラスターと Valkey または Redis OSS (クラスターモードが有効) クラスター\]](http://docs.aws.amazon.com/ja_jp/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 (クラスターモードが有効) クラスターの比較**
| 機能 | Valkey または Redis OSS (クラスターモードが無効) | Valkey または Redis OSS (クラスターモードが有効) |
| --- | --- | --- |
| 変更可能 | はい。レプリカノードの追加と削除、およびノードタイプのスケールアップをサポートします。 | 制限あり。詳細については、「[ElastiCache のバージョン管理](VersionManagement.md)」および「[Valkey または Redis OSS (クラスターモードが有効) クラスターのスケーリング](scaling-redis-cluster-mode-enabled.md)」を参照してください。 |
| データのパーティション化 | なし | あり |
| シャード | 1 | 1～500 |
| リードレプリカ | 0～5 レプリカがない場合、ノードに障害が発生すると、すべてのデータが損失します。 | シャードあたり 0～5。レプリカがなく、ノードに障害が発生すると、そのシャードのすべてのデータが失われます。 |
| マルチ AZ | はい、少なくとも 1 つのレプリカ。オプション。デフォルトでオン。 | ありオプション。デフォルトでオン。 |
| スナップショット(バックアップ) | はい、1 つの .rdb ファイルを作成。 | はい、シャードごとに独自の .rdb ファイルを作成。 |
| 復元 | はい。Valkey または Redis OSS (クラスターモードが無効) クラスターから 1 つの .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 以降。 |
| オンラインリシャーディング | 該当なし | バージョン 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 個のノードグループ間でのデータの分割がサポートされています。ビジネスニーズの変化に合わせて、シャードの数を動的に変更することができます。パーティション化の 1 つの利点は、より多くのエンドポイントに負荷を分散し、ピーク需要時のアクセスのボトルネックを減らすことです。また、データを複数のサーバーに分散させることができるため、より大規模なデータセットに対応できます。パーティションのスケーリングの詳細については、「[Valkey または Redis OSS (クラスターモードが有効) クラスターのスケーリング](scaling-redis-cluster-mode-enabled.md)」を参照してください。
+ **ノードサイズとノード数** – Valkey または Redis OSS (クラスターモードが無効) クラスターのシャードは 1 つだけであるため、ノードタイプはクラスターのすべてのデータと必要なオーバーヘッドに対応できるだけの大きさである必要があります。一方、Valkey または Redis OSS (クラスターモードが有効) クラスターでは複数のシャード間でデータを分割できるため、ノードタイプはより小さくできますが、全体ではノード数が増えます。詳細については、「[ノードサイズの選択](CacheNodes.SelectSize.md)」を参照してください。
+ **読み取りと書き込み** – クラスターの主な負荷がデータを読み取るアプリケーションである場合、リードレプリカを追加および削除することで、Valkey または Redis OSS (クラスターモードが無効) クラスターをスケールできます。ただし、リードレプリカの最大数は 5 です。クラスターの書き込み負荷が高い場合は、複数のシャードを持つ Valkey または Redis OSS (クラスターモードが有効) クラスターの追加の書き込みエンドポイントが役立ちます。
どちらのクラスターを実装する場合でも、現在および将来のニーズに合ったノードタイプを選択してください。
# Valkey および Redis OSS でマルチ AZ を使用して ElastiCache のダウンタイムを最小限に抑える
ElastiCache for Valkey と ElastiCache for Redis OSS では、プライマリノードを置き換える必要がある状況がいくつかあります。これには、特定のタイプの計画的メンテナンスや、プライマリノードまたはアベイラビリティーゾーンの予期しない障害などが含まれます。
この置き換えにより、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。ElastiCache ではこれを透過的に処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。
また、ElastiCache は昇格されたレプリカのドメイン名サービス (DNS) 名を伝達します。これを行うのは、アプリケーションがプライマリエンドポイントに書き込みを行う場合、アプリケーションでエンドポイントの変更が必要なくなるためです。個別のエンドポイントから読み取りを行う場合は、プライマリに昇格されたレプリカの読み取りエンドポイントを新しいレプリカのエンドポイントに変更してください。
メンテナンス更新やセルフサービス更新に伴って開始された計画的なノード置換の場合:
+ Valkey および Redis OSS クラスターでは、クラスターが受信した書き込みリクエストを処理している間に、計画的なノード置換が完了します。
+ Valkey および Redis OSS クラスターモードが無効で、マルチ AZ が有効になっているクラスターが 5.0.6 以降のエンジンで実行されている場合、クラスターが受信した書き込みリクエストを処理している間に、計画的なノード置換が完了します。
+ Valkey および Redis OSS クラスターモードが無効で、マルチ AZ が有効になっているクラスターが 4.0.10 以前のエンジンで実行されている場合、DNS の更新に伴って短い書き込みの中断が発生することがあります。この中断は数秒続く場合があります。このプロセスは、新しいプライマリを再作成してプロビジョニングする (マルチ AZ を有効にしない場合に発生すること) よりもはるかに高速です。
マルチ AZ を有効にするには、ElastiCache マネジメントコンソール、AWS CLI、または ElastiCache API を使用できます。
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 の有効化
クラスターの作成時または変更時にマルチ AZ を有効にするには (API、CLI、レプリケーショングループ内)、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用できます。
マルチ AZ は、使用可能なリードレプリカが少なくとも 1 つある Valkey または Redis OSS (クラスターモードが無効) クラスターでのみ有効にすることができます。リードレプリカのないクラスターでは、高可用性や耐障害性は提供されません。レプリケーションが有効なクラスターの作成については、「[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 の有効化 (コンソール)
ElastiCache コンソールを使用して、新しい Valkey または Redis OSS クラスターの作成時や、レプリケーションが有効になっている既存のクラスターの変更時に、マルチ AZ を有効にすることができます。
マルチ AZ は、Valkey または Redis OSS (クラスターモードが有効) クラスターでデフォルトで有効になります。
**重要**
ElastiCache は、クラスターにすべてのシャードのプライマリとは異なるアベイラビリティーゾーンに少なくとも 1 つのレプリカが含まれている場合にのみ、マルチ AZ を自動的に有効にします。
#### ElastiCache コンソールを使用したクラスター作成時のマルチ AZ の有効化
このプロセスの詳細については、「[Valkey (クラスターモードが無効) クラスターの作成 (コンソール)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)」を参照してください。必ず 1 つ以上のレプリカを用意して、マルチ AZ を有効にしてください。
#### 既存のクラスターでのマルチ AZ の有効化 (コンソール)
このプロセスの詳細については、「[ElastiCache AWS マネジメントコンソール の使用](Clusters.Modify.md#Clusters.Modify.CON)」でクラスターの変更に関する説明を参照してください。
### マルチ AZ の有効化 (AWS CLI)
次のコード例では、AWS CLI を使用して、レプリケーショングループ `redis12` のマルチ AZ を有効にします。
**重要**
レプリケーショングループ `redis12` が既に存在しており、少なくとも 1 個の利用可能なリードレプリカが必要となります。
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` が既に存在していて、少なくとも 1 個の利用可能なリードレプリカがある必要があります。
```
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)
### プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ
プライマリおよび少なくとも 1 つのリードレプリカで障害が発生した場合、利用可能でレプリケーションの遅延が最も少ないレプリカが、プライマリクラスターに昇格されます。また、障害が発生したノードおよびプライマリに昇格されたレプリカと同じアベイラビリティーゾーンで、新しいリードレプリカが作成およびプロビジョニングされます。
プライマリノードと複数のリードレプリカが失敗すると、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 マネジメントコンソール を使用した自動フェイルオーバーのテスト](#auto-failover-test-con)
+ [AWS CLI を使用した自動フェイルオーバーのテスト](#auto-failover-test-cli)
+ [ElastiCache API を使用した自動フェイルオーバーのテスト](#auto-failover-test-api)
### AWS マネジメントコンソール を使用した自動フェイルオーバーのテスト
コンソールで自動フェイルオーバーをテストするには、次の手順に従います。
**自動フェイルオーバーをテストするには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. クラスターの一覧で、テストするクラスターの名前の左にあるチェックボックスをオンにします。このクラスターには、少なくとも 1 つのリードレプリカノードが必要です。
1. **Details** エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「[ElastiCache AWS マネジメントコンソール の使用](Clusters.Modify.md#Clusters.Modify.CON)」を参照してください。
![\[イメージ: マルチ AZ が有効なクラスターの [詳細] エリア\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Valkey または Redis OSS (クラスターモードが無効) の場合、クラスターの名前を選択します。
Valkey または Redis OSS (クラスターモードが有効) の場合、次の手順を実行します。
1. クラスターの名前を選択します。
1. [**Shards**] ページで、フェイルオーバーをテストするシャード (API および CLI ではノードグループと呼ばれます) のシャード名を選択します。
1. [Nodes] ページで [**Failover Primary**] を選択します。
1. **Continue** を選択してプライマリをフェイルオーバーするか、**Cancel** を選択してプライマリノードへのフェイルオーバーをキャンセルします。
フェイルオーバープロセス中は、コンソールでノードのステータスが 使用可能** と継続して表示されます。フェイルオーバーテストの進捗状況を追跡するには、コンソールのナビゲーションペインから **Events** を選択します。**Events** タブで、フェイルオーバーの開始`Test Failover API called`と完了`Recovery completed`を示すイベントを監視します。
### AWS CLI を使用した自動フェイルオーバーのテスト
マルチ AZ が有効になっているクラスターで自動フェイルオーバーをテストするには、AWS CLI オペレーションの `test-failover` を使用できます。
**パラメータ**
+ `--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 を使用した自動フェイルオーバーのテスト
マルチ AZ が有効になっている任意のクラスターで自動フェイルオーバーをテストするには、ElastiCache API オペレーションの `TestFailover` を使用できます。
**パラメータ**
+ `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 はレプリケーションの遅延が最短のレプリカを選択します。言い換えると、最新のレプリカを選択します。これにより、失われるデータ量が最小限に抑えられます。レプリケーションの遅延が最短のレプリカは、障害が発生したプライマリノードと同じ、または異なるアベイラビリティーゾーンに存在できます。
+ マルチ AZ と自動フェイルオーバーが無効なときにのみ、Valkey または Redis OSS クラスター (クラスターモードが無効) でリードレプリカを手動でプライマリに昇格させることができます。リードレプリカをプライマリに昇格させるには、以下のステップを実行します。
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 のレプリカを持つレプリケーショングループを考えてみます。プライマリに障害が発生した場合、レプリケーションの遅延が最も小さい利用可能なレプリカをプライマリクラスターに昇格します。その後、AZ-a がバックアップとなっていて使用可能な場合にのみ、ElastiCache は AZ-a 内 (障害が発生したプライマリがあった場所) に新しいレプリカを作成します。
+ プライマリの再起動をお客様が開始した場合、自動フェイルオーバーはトリガーされません。他の再起動と障害は、自動フェイルオーバーをトリガーします。
+ プライマリが再起動すると、オンラインに戻ったときにデータがクリアされます。リードレプリカがクリアされたプライマリクラスターを検出すると、データのコピーがクリアされるため、データ損失が発生します。
+ リードレプリカが昇格されると、他のレプリカは新しいプライマリと同期されます。最初の同期後に、レプリカのコンテンツは削除され、新しいプライマリからデータが同期されます。この同期プロセスに伴って一時的に中断が発生し、その間はレプリカにアクセスできなくなります。また、この同期プロセスに伴ってレプリカとの同期中にプライマリで一時的にロードが増えます。この動作は、Valkey および Redis OSS にネイティブであり、ElastiCache のマルチ AZ に特有ではありません。この動作の詳細については、Valkey ウェブサイトの「[Replication](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 レプリケーションでは、2 つの方法から選択します。詳細については、「[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 レプリケーショングループの作成
レプリカノードのあるクラスターを作成するには、以下のオプションがあります。1 つは、レプリカを持つクラスターに関連付けられていない、プライマリノードとして使用可能な Valkey または Redis OSS (クラスターモードが無効) クラスターが既にある場合に適用されます。もう 1 つは、クラスターとリードレプリカのあるプライマリノードを作成する必要がある場合に適用されます。現時点では、Valkey または Redis OSS (クラスターモードが有効) クラスターを最初から作成する必要があります。
**オプション 1: [既存のクラスターを使用したレプリケーショングループの作成](Replication.CreatingReplGroup.ExistingCluster.md)**
このオプションは、既存の単一ノード Valkey または Redis OSS (クラスターモードが無効) クラスターを利用する場合に使用します。この既存ノードを、新しいクラスターのプライマリノードとして指定し、さらにクラスターに 1〜5 個のリードレプリカを個別に追加します。既存のクラスターがアクティブの場合、リードレプリカは作成時にそのクラスターと同期されます。「[既存のクラスターを使用したレプリケーショングループの作成](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 または Redis OSS (クラスターモードが無効) の単一ノードクラスターにレプリケーショングループを追加します。これは、クラスターを最新バージョンの Valkey にアップグレードするために必要です。これは、ダウンタイムもデータ損失もないインプレース手順です。単一ノードクラスターのレプリケーショングループを作成すると、クラスターのノードが新しいクラスターのプライマリノードになります。新しいクラスターのプライマリとして使用できる 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 マネジメントコンソールの使用](Clusters.AddNode.md#Clusters.AddNode.CON)」を参照してください。
## 使用可能な Valkey または Redis OSS のクラスターを使用したレプリケーショングループの作成 (AWS CLI)
AWS CLIを使う場合、使用可能な Valkey または Redis OSS キャッシュクラスターをプライマリとして、リードレプリカを持つレプリケーショングループを作成するには 2 つのステップがあります。
を使用する場合、 CLI コマンド を使用して、使用可能なスタンドアロンノードをクラスターのプライマリノードとして指定`--primary-cluster-id`し、クラスターに必要なノードの数を指定するレプリケーショングループAWS CLIを作成します`create-replication-group`。以下のパラメータを含めます。
**--replication-group-id**
作成するレプリケーショングループの名前。このパラメータの値が追加されたノードの名前の基礎として使用され、3 桁の連番が `--replication-group-id` の末尾に追加されます。例えば、`sample-repl-group-001`。
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループの命名に関する制約は、次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 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 〜 5 個のリードレプリカを追加します。その際に、以下のパラメータを必ず含めます。
**--cache-cluster-id**
レプリケーショングループに追加するクラスターの名前。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 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 を使用する場合、CLI コマンド `CreateReplicationGroup` を使用して、クラスターのプライマリノードとして使用可能なスタンドアロンノードを指定して (`PrimaryClusterId`)、クラスター内に含めるノードの数を指定し、レプリケーショングループを作成します。以下のパラメータを含めます。
**ReplicationGroupId**
作成するレプリケーショングループの名前。このパラメータの値が追加されたノードの名前の基礎として使用され、3 桁の連番が `ReplicationGroupId` の末尾に追加されます。例えば、`sample-repl-group-001`。
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループの命名に関する制約は、次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 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 〜 5 個のリードレプリカを追加します。その際に、以下のパラメータを必ず含めます。
**CacheClusterId**
レプリケーショングループに追加するクラスターの名前。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 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 レプリケーショングループを作成する方法を以下に説明します。Valkey または Redis OSS (クラスターモードが無効) または Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループを最初から作成するには、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用します。
続行する前に、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 (クラスターモードが無効) レプリケーショングループを最初から作成する
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループを最初から作成するには、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用します。Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループには常に 1 つのノードグループ、1 つのプライマリクラスター、および最大 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` コマンドへの 1 回の呼び出しで作成します。以下のパラメータを含めます。
**--replication-group-id**
作成するレプリケーショングループの名前。
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループの命名に関する制約は、次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 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/)」を参照してください。
**--data-tiering-enabled**
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` に設定する必要があります。
**--engine**
redis
**--engine-version**
最も豊富な機能のセットを利用するには、最新バージョンのエンジンを選択します。
ノードの名前は、レプリケーショングループ名の後に「`-00`*\$1*」を追加することで決定されます。たとえば、レプリケーショングループ名 `myReplGroup` を使用すると、プライマリの名前は `myReplGroup-001` となり、リードレプリカの名前は `myReplGroup-002` から `myReplGroup-006` となります。
このレプリケーショングループで転送時または保管時の暗号化を有効にする場合は、`--transit-encryption-enabled` パラメータと `--at-rest-encryption-enabled` パラメータの一方または両方を追加し、次の条件を満たす必要があります。
+ レプリケーショングループは Redis OSS バージョン 3.2.6 または 4.0.10 を実行している必要があります。
+ レプリケーショングループは Amazon VPC で作成されている必要があります。
+ パラメータ `--cache-subnet-group` も含める必要があります。
+ このレプリケーショングループに対するオペレーションを実行するために必要な AUTH トークン (パスワード) 用に顧客が指定した文字列値にパラメータ `--auth-token` も含める必要があります。
次のオペレーションでは、3 つのノード、1 つのプライマリ、2 つのレプリカを持つ 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` オペレーションへの 1 回の呼び出しで作成します。以下のパラメータを含めます。
**ReplicationGroupId**
作成するレプリケーショングループの名前。
Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの命名に関する制約は、次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
**ReplicationGroupDescription**
レプリケーショングループの説明。
**NumCacheClusters**
このレプリケーションのグループ、プライマリおよびリードレプリカ全体で作成するノードの総数。
マルチ AZ を有効にした場合（`AutomaticFailoverEnabled=true`）、`NumCacheClusters` の値は 2 以上であることが必要です。
**CacheNodeType**
レプリケーショングループの各ノードのノードタイプ。
ElastiCache では以下のノードタイプがサポートされています。一般に、現行世代のタイプは、以前の世代の同等タイプと比較した場合、メモリが多く処理能力が高くなっています。
各ノードタイプのパフォーマンスの詳細の詳細については、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。
**--data-tiering-enabled**
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` パラメータの一方または両方を追加し、次の条件を満たす必要があります。
+ レプリケーショングループは Redis OSS バージョン 3.2.6 または 4.0.10 を実行している必要があります。
+ レプリケーショングループは Amazon VPC で作成されている必要があります。
+ パラメータ `CacheSubnetGroup` も含める必要があります。
+ このレプリケーショングループに対するオペレーションを実行するために必要な AUTH トークン (パスワード) 用に顧客が指定した文字列値にパラメータ `AuthToken` も含める必要があります。
次のオペレーションでは、3 つのノード、1 つのプライマリ、2 つのレプリカを持つ 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 (クラスターモードが有効) でレプリケーショングループを最初から作成する
Valkey または Redis OSS (クラスターモードが有効) クラスター (API/CLI: *レプリケーショングループ*) を作成するには、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用します。Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループは、1〜500 個のシャード (API/CLI: ノードグループ) で構成され、各シャードには、1 つのプライマリノードと、最大 5 個のリードレプリカが含まれます。シャードの数が多くレプリカの数が少ないクラスターを作成できます。クラスターあたり最大 90 ノードです。このクラスター設定は、シャード 90 個およびレプリカ 0 個からシャード 15 個およびレプリカ 5 個 (許容されるレプリカの最大数) までです。
Valkey または Redis OSS エンジンのバージョンが 5.0.6 以上の場合、ノードまたはシャードの制限は、クラスターごとに最大 500 個まで増やすことができます。例えば、83 個のシャード (シャードごとに 1 つのプライマリと 5 レプリカ) と 500 個のシャード (プライマリのみでレプリカなし) の範囲で、500 個のノードクラスターを設定できます。増加に対応できる十分な IP アドレスがあることを確認してください。一般的な落とし穴として、サブネットグループ内のサブネットの CIDR 範囲が小さすぎる、またはサブネットが他のクラスターで共有され、頻繁に使用されていることが挙げられます。詳細については、「[サブネットグループの作成](SubnetGroups.Creating.md)」を参照してください。
5.0.6 未満のバージョンの場合、クラスターあたりの制限は 250 個です。
この制限の拡大をリクエストするには、「[AWS のサービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照し、制限タイプとして [**Nodes per cluster per instance type (インスタンスタイプごとのクラスターあたりのノード)**] を選択します。
**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)」を参照してください。クラスターモード (**[クラスターモードが有効 (スケールアウト)]**) を必ず有効にし、それぞれに少なくとも 2 つのシャードと 1 つのレプリカノードを指定します。
## Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループを最初から作成する (AWS CLI)
以下の手順では、AWS CLI を使用して Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループを作成します。
Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループを最初から作成する場合、レプリケーショングループとそのすべてのノードを、AWS CLI `create-replication-group` コマンドへの 1 回の呼び出しで作成します。以下のパラメータを含めます。
**--replication-group-id**
作成するレプリケーショングループの名前。
Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの命名に関する制約は、次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
**--replication-group-description**
レプリケーショングループの説明。
**--cache-node-type**
レプリケーショングループの各ノードのノードタイプ。
ElastiCache では以下のノードタイプがサポートされています。一般に、現行世代のタイプは、以前の世代の同等タイプと比較した場合、メモリが多く処理能力が高くなっています。
各ノードタイプのパフォーマンスの詳細の詳細については、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。
**--data-tiering-enabled**
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)」を参照してください。
**--engine**
redis
**--engine-version**
3.2.4
**--num-node-groups**
このレプリケーショングループのノードグループの数。有効な値は 1～500 です。
ノード/シャード制限は、クラスターあたり 500 まで増やすことができます。この制限の拡大をリクエストするには、「[AWS サービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照し、制限タイプ「インスタンスタイプごとのクラスターあたりのノード」を選択します。
**--replicas-per-node-group**
各ノードグループのレプリカノードの数。有効な値は 0～5 です。
**--network-type**
`ipv4`、`ipv` または `dual-stack` です。デュアルスタックを選択する場合は、`--IpDiscovery` パラメータを `ipv4` または `ipv6` に設定する必要があります。
このレプリケーショングループで転送時または保管時の暗号化を有効にする場合は、`--transit-encryption-enabled` パラメータと `--at-rest-encryption-enabled` パラメータの一方または両方を追加し、次の条件を満たす必要があります。
+ レプリケーショングループは Redis OSS バージョン 3.2.6 または 4.0.10 を実行している必要があります。
+ レプリケーショングループは Amazon VPC で作成されている必要があります。
+ パラメータ `--cache-subnet-group` も含める必要があります。
+ このレプリケーショングループに対するオペレーションを実行するために必要な AUTH トークン (パスワード) 用に顧客が指定した文字列値にパラメータ `--auth-token` も含める必要があります。
次のオペレーションでは、3 つのノードグループ/シャード (--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 (クラスターモードが有効) レプリケーショングループを最初から作成する際、次の例に示すように `--node-group-configuration` パラメータを使用してクラスター内の各シャードを設定することで、2 つのノードグループ (コンソール: シャード) を設定できます。1 つめのシャードは、2 つのノード、1 つのプライマリ、1 つのリードレプリカで構成されます。2 つめのシャードは、3 つのノード、1 つのプライマリ、2 つのリードレプリカで構成されます。
**--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` オペレーションへの 1 回の呼び出しで作成します。以下のパラメータを含めます。
**ReplicationGroupId**
作成するレプリケーショングループの名前。
Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの命名に関する制約は、次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
**ReplicationGroupDescription**
レプリケーショングループの説明。
**NumNodeGroups**
このレプリケーショングループで作成するノードグループの数。有効な値は 1～500 です。
**ReplicasPerNodeGroup**
各ノードグループのレプリカノードの数。有効な値は 1～5 です。
**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/)」を参照してください。
**--data-tiering-enabled**
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` パラメータの一方または両方を追加し、次の条件を満たす必要があります。
+ レプリケーショングループは Redis OSS バージョン 3.2.6 または 4.0.10 を実行している必要があります。
+ レプリケーショングループは 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 コンソール、AWS CLI for ElastiCache、または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 (クラスターモード無効) の詳細を表示する
レプリカ (API/CLI:レプリケーショングループ**) がある Valkey または Redis OSS (クラスターモード無効) クラスターの詳細を表示するには、ElastiCache コンソール、AWS CLI for ElastiCache、または ElastiCache API を使用します。
**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
}
]
}
```
詳細については、「AWS CLI for ElastiCache トピック [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 (クラスターモードが無効) クラスターには、*プライマリエンドポイント*、*リーダーエンドポイント*、*ノードエンドポイント*の 3 種類のエンドポイントがあります。プライマリエンドポイントは、常にクラスターのプライマリノードに解決される DNS 名です。プライマリエンドポイントは、リードレプリカのプライマリロールへの昇格など、クラスターに対する変更の影響を受けません。書き込みアクティビティの場合、アプリケーションをプライマリエンドポイントに接続することをお勧めします。
リーダーエンドポイントによって、ElastiCache クラスター内のすべてのリードレプリカ間でエンドポイントへの着信接続が均等に分割されます。アプリケーションがいつ接続を作成するか、アプリケーションが接続をどのように (再) 利用するかなどの追加要因によって、トラフィックの分散が決定されます。レプリカが追加または削除されても、読み込みエンドポイントはリアルタイムでクラスターの変更に対応します。ElastiCache for Redis OSS クラスターの複数のリードレプリカを異なる AWS アベイラビリティーゾーン (AZ) に配置して、リーダーエンドポイントの高可用性を確保することができます。
**注記**
リーダーエンドポイントはロードバランサーではありません。これは、ラウンドロビン方式でレプリカノードの 1 つの IP アドレスに解決される DNS レコードです。
読み取りアクティビティの場合、アプリケーションはクラスター内のいずれのノードにも接続できます。プライマリエンドポイントとは異なり、ノードエンドポイントは特定のエンドポイントに解決されます。レプリカの追加または削除など、クラスターに変更を加えた場合は、アプリケーションでノードエンドポイントを更新する必要があります。
**Valkey または Redis OSS (クラスターモードが有効)**
レプリカがある Valkey または Redis OSS (クラスターモードが有効) クラスターには、複数のシャード (API/CLI: ノードグループ) があり、これはプライマリノードが複数あることを意味するため、Valkey または Redis OSS (クラスターモードが無効) クラスターとはエンドポイント構造が異なります。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 では、API オペレーション `ModifyReplicationGroup` (CLI: `modify-replication-group`) を使用したエンジンバージョンの変更など、Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの限定的な変更をサポートしています。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)」を参照してください。
以下の例に示すように、無効状態のクラスターモードを使用する Valkey または Redis OSS に対応した既存の ElastiCache クラスターを、コンソール、[ModifyReplicationGrou](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)p API、または [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) CLI コマンドを使用して、有効状態のクラスターモードを使用するようにアップグレードできます。または、「[クラスターモードの変更](modify-cluster-mode.md)」の手順に従うこともできます。
Valkey または Redis OSS (クラスターモードが無効) クラスターの設定は AWS CLI、ElastiCache コンソール、、または ElastiCache API を使用して変更できます。現在、ElastiCache では、Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの制限された数の変更をサポートしていません。その他の変更では、現在のレプリケーショングループのバックアップを作成し、そのバックアップを使用して新しい Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループをシードする必要があります。
**Topics**
+ [の使用 AWS マネジメントコンソール](#Replication.Modify.CON)
+ [の使用 AWS CLI](#Replication.Modify.CLI)
+ [ElastiCache API の使用](#Replication.Modify.API)
## の使用 AWS マネジメントコンソール
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*」 (Yes) と入力します。プロセスの開始後に元に戻すことはできません。
```
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 マネジメントコンソール、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 マネジメントコンソール、AWS CLI、または ElastiCache API を使用します。
**Topics**
+ [の使用AWS マネジメントコンソール](#increase-replica-count-con)
+ [の使用AWS CLI](#increase-replica-count-cli)
+ [ElastiCache API の使用](#increase-replica-count-api)
## の使用AWS マネジメントコンソール
次の手順では、コンソールを使用して、Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループのレプリカの数を増やします。
**シャードのレプリカの数を増やすには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[Valkey]** または **[Redis OSS]** を選択し、レプリカを追加するレプリケーショングループの名前を選択します。
1. レプリカを追加する各シャードのチェックボックスをオンにします
1. [**Add replicas (レプリカの追加)**] を選択します。
1. [**Add Replicas to Shards (シャードにレプリカを追加)**] ページを完了します。
+ [**New number of replicas/shard (シャード当たりの新しいレプリカ数)**] に、選択したすべてのシャードが持つようになるレプリカの数を入力します。この値は、[**Current Number of Replicas per shard (現在のシャード当たりのレプリカ数)**] 以上で、5 以下である必要があります。最小の実行として、レプリカを少なくとも 2 つにすることをお勧めします。
+ [**アベイラビリティーゾーン**] では、[**指定なし**] を選択して新しいレプリカごとにアベイラビリティーゾーンを ElastiCache が選択するようにするか、**アベイラビリティーゾーンの指定**] を選択して、新しいレプリカごとにアベイラビリティーゾーンを選択します。
[**Specify Availability Zones (アベイラビリティーゾーンを指定する)**] を選択した場合、リストを使用して新しい各レプリカのアベイラビリティーゾーンを指定します。
1. [**Add (追加)**] を選択してレプリカを追加するか、[**Cancel (キャンセル)**] を選択してオペレーションをキャンセルします。
## の使用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 個で指定します。1 つだけのノードグループまたは 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 OSS は新しいレプリカごとにアベイラビリティーゾーンを選択します。
**重要**
呼び出しに、`--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 個で指定します。ノードグループが 1 つだけある 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 OSS は新しいレプリカごとにアベイラビリティーゾーンを選択します。
**重要**
呼び出しに、`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 まで減らし、マルチ AZ が有効でない場合はゼロまで減らすことができます。
+ Valkey または Redis OSS (クラスターモードが有効) のレプリカ数はゼロまで減らすことができます。ただし、プライマリノードが失敗した場合はレプリカにフェイルオーバーできません。
AWS マネジメントコンソール、AWS CLI、または ElastiCache API を使用して、ノードグループ (シャード)、またはレプリケーショングループのレプリカの数を減らせます。
**Topics**
+ [の使用AWS マネジメントコンソール](#decrease-replica-count-con)
+ [の使用AWS CLI](#decrease-replica-count-cli)
+ [ElastiCache API の使用](#decrease-replica-count-api)
## の使用AWS マネジメントコンソール
次の手順では、コンソールを使用して、Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループのレプリカの数を減らします。
**Valkey または Redis OSS シャードのレプリカの数を減らすには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで、**[Valkey]** または **[Redis OSS]** を選択し、レプリカを削除するレプリケーショングループの名前を選択します。
1. レプリカノードを削除する各シャードのチェックボックスをオンにします
1. [**Delete replicas (レプリカの削除)**] を選択します。
1. [**Delete Replicas from Shards (シャードからのレプリカの削除)**] ページを完了します。
1. [**New number of replicas/shard (シャード当たりの新しいレプリカ数)**] に、選択したシャードが持つようになるレプリカの数を入力します。この数は、1 以上にする必要があります。最小の実行として、レプリカを少なくともシャードあたり 2 つにすることをお勧めします。
1. [**Delete (削除)**] を選択してレプリカを削除するか、[**Cancel (キャンセル)**] を選択してオペレーションをキャンセルします。
**重要**
削除するレプリカノードを指定しない場合、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 OSS は新しいレプリカごとにアベイラビリティーゾーンを選択します。
**重要**
`--new-replica-count`、`--replicas-to-remove`、または `--replica-configuration` パラメータのいずれか 1 つのみを含める必要があります。
**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 OSS は新しいレプリカごとにアベイラビリティーゾーンを選択します。
**重要**
`NewReplicaCount`、`ReplicasToRemove`、または `ReplicaConfiguration` パラメータのいずれか 1 つのみを含める必要があります。
**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 (クラスターモードが無効) レプリケーショングループにのみ適用されます。
読み取りトラフィックが増えるにつれて、これらの読み取りをより多くのノードに分散させて、1 つのノードの読み取りの負荷を減らすことを考えます。このトピックでは、Valkey または Redis OSS (クラスターモードが無効) クラスターにリードレプリカを追加する方法について説明します。
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループは、最大 5 つのリードレプリカを持つことができます。すでに 5 個のリードレプリカを持つレプリケーショングループに別のリードレプリカを追加しようとすると、オペレーションが失敗します。
Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループへのレプリカの追加については、以下を参照してください。
+ [Valkey または Redis OSS (クラスターモードが有効) クラスターのスケーリング](scaling-redis-cluster-mode-enabled.md)
+ [シャードのレプリカの数を増やす](increase-replica-count.md)
Valkey または Redis OSS (クラスターモードが無効) クラスターにリードレプリカを追加するには、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用します。
**関連トピック**
+ [ノードを ElastiCache クラスターに追加する](Clusters.AddNode.md)
+ [レプリケーショングループへのリードレプリカの追加 (AWS CLI)](#Replication.AddReadReplica.CLI)
+ [API を使用したレプリケーショングループへのリードレプリカの追加](#Replication.AddReadReplica.API)
## レプリケーショングループへのリードレプリカの追加 (AWS CLI)
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループにリードレプリカを追加するには、AWS CLI `create-cache-cluster` コマンドを使用します。パラメータとして `--replication-group-id` を使用し、クラスター (ノード) を追加するレプリケーショングループを指定します。
次の例では、クラスター `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 (クラスターモードが無効) レプリケーショングループにリードレプリカを追加するには、ElastiCache `CreateCacheCluster` オペレーションを使用します。パラメータとして `ReplicationGroupId` を使用し、クラスター (ノード) を追加するレプリケーショングループを指定します。
次の例では、クラスター `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. リードレプリカを削除します。
Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループからリードレプリカを削除するには、ElastiCache コンソール、AWS CLI for ElastiCache、または ElastiCache API を使用します。
Valkey または Redis OSS レプリケーショングループからクラスターを削除する方法については、以下を参照してください。
+ [の使用AWS マネジメントコンソール](Clusters.Delete.md#Clusters.Delete.CON)
+ [を使用して ElastiCache クラスターAWS CLIを削除する](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 (クラスターモードが無効) レプリケーショングループにのみ適用されます。
Valkey または Redis OSS (クラスターモードが無効) リードレプリカをプライマリに昇格させるには、AWS マネジメントコンソール、AWS CLI、または ElastiCache API を使用します。 レプリケーショングループでマルチ AZ と自動フェイルオーバーを有効にしている場合は、リードレプリカをプライマリに昇格させることはできません。マルチ AZ が有効なレプリケーショングループのプライマリに Valkey または Redis OSS (クラスターモードが無効) レプリカを昇格させる場合は、以下が必要です。
1. レプリケーショングループを変更してマルチ AZ を無効にします (これを行うためにすべてのクラスターが同じアベイラビリティーゾーンに存在する必要はありません)。詳細については、「[レプリケーショングループの変更](Replication.Modify.md)」を参照してください。
1. リードレプリカをプライマリに昇格させます。
1. マルチ AZ を再び有効にするためにレプリケーショングループを変更します。
マルチ AZ は、Redis OSS 2.6.13 以前を実行しているレプリケーショングループでは使用できません。
## の使用AWS マネジメントコンソール
次の手順では、コンソールを使用してレプリカノードをプライマリに昇格させます。
**リードレプリカをプライマリに昇格させるには (コンソール)**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. 昇格させるレプリカが、マルチ AZ が有効な Valkey または Redis OSS (クラスターモード無効) レプリケーショングループのメンバーである場合は、先に進む前に、レプリケーショングループを変更してマルチ AZ を無効にします。詳細については、「[レプリケーショングループの変更](Replication.Modify.md)」を参照してください。
1. **[Valkey]** または **[Redis OSS]** を選択して、クラスターのリストから、変更するレプリケーショングループを選択します。このレプリケーショングループは、「Clustered Redis」エンジンではなく、「Redis」エンジンを実行していること、また 2 つ以上のノードを持っていることが必要です。
1. ノードのリストからプライマリに昇格させるレプリカノードを選択して、[**Actions (アクション)**] で、[**Promote (昇格)**] を選択します。
1. [**Promote Read Replica (リードレプリカの昇格)**] ダイアログボックスで、次の操作を行います。
1. [**Apply Immediately (すぐに適用)**] で、リードレプリカをすぐに昇格させる場合は [**Yes (はい)**] を選択し、クラスターの次回のメンテナンス期間に昇格させる場合は [**No (いいえ)**] を選択します。
1. リードレプリカを昇格させる場合は [**Promote**] を選択し、オペレーションをキャンセルする場合は [**No**] を選択します。
1. 昇格プロセスを開始する前にクラスターでマルチ AZ を有効にしている場合は、レプリケーショングループのステータスが [**available (利用可能)**] になるまで待機して、マルチ 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 アクションは、レプリケーショングループ `myReplGroup` を変更して、リードレプリカ `myReplica-1` をそのレプリケーショングループのプライマリにします。
```
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 分のメンテナンスウィンドウを割り当てます。
60 分のメンテナンス時間は、リージョンごとに決められた 8 時間の中でランダムに選択されます。次の表に、デフォルトでメンテナンス時間が割り当てられる各リージョンの時間ブロックを示します。リージョンのメンテナンス時間外で、希望するメンテナンス時間を選択できます。
| リージョンコード | リージョン名 | リージョンメンテナンスウィンドウ |
| --- | --- | --- |
| ap-northeast-1 | アジアパシフィック (東京) リージョン | 13:00～21:00 UTC |
| ap-northeast-2 | アジアパシフィック (ソウル) リージョン | 12:00～20:00 UTC |
| ap-northeast-3 | アジアパシフィック（大阪）リージョン | 12:00～20:00 UTC |
| ap-southeast-3 | アジアパシフィック (ジャカルタ) リージョン | 14:00～22:00 UTC |
| ap-south-1 | アジアパシフィック (ムンバイ) リージョン | 17:30～1:30 UTC |
| ap-southeast-1 | アジアパシフィック (シンガポール) リージョン | 14:00～22:00 UTC |
| cn-north-1 | 中国 (北京) リージョン | 14:00～22:00 UTC |
| cn-northwest-1 | 中国 (寧夏) リージョン | 14:00～22:00 UTC |
| ap-east-1 | アジアパシフィック (香港) リージョン | 13:00～21:00 UTC |
| ap-southeast-2 | アジアパシフィック (シドニー) リージョン | 12:00～20:00 UTC |
| eu-west-3 | EU (パリ) リージョン | 23:59～07:29 UTC |
| af-south-1 | アフリカ（ケープタウン）リージョン | 13:00～21:00 UTC |
| eu-central-1 | 欧州 (フランクフルト) リージョン | 23:00～07:00 UTC |
| eu-west-1 | 欧州 (アイルランド) リージョン | 22:00～06:00 UTC |
| eu-west-2 | 欧州 (ロンドン) リージョン | 23:00～07:00 UTC |
| me-south-1 | 中東 (バーレーン) リージョン | 13:00～21:00 UTC |
| me-central-1 | 中東 (アラブ首長国連邦) リージョン | 13:00～21:00 UTC |
| eu-south-1 | 欧州 (ミラノ) リージョン | 21:00～05:00 UTC |
| sa-east-1 | 南米 (サンパウロ) リージョン | 01:00～09:00 UTC |
| us-east-1 | 米国東部 (バージニア北部) リージョン | 03:00～11:00 UTC |
| us-east-2 | 米国東部 (オハイオ) リージョン | 04:00～12:00 UTC |
| us-gov-west-1 | AWS GovCloud (US) region | 06:00～14:00 UTC |
| us-west-1 | US West (N. California) リージョン | 06:00～14:00 UTC |
| us-west-2 | 米国西部 (オレゴン) リージョン | 06:00～14:00 UTC |
**クラスターまたはレプリケーショングループのメンテナンスウィンドウの変更**
メンテナンスウィンドウは使用率の最も低い時間帯に設定する必要があります。このため、場合によっては変更が必要になります。クラスターまたはレプリケーショングループを変更して、リクエストしたメンテナンス作業が発生するまでの時間範囲 (最大 24 時間) を指定することができます。お客様がリクエストした延期または保留中のクラスターの変更は、この時間に行われます。
**注記**
AWS マネジメントコンソール を使用してノードタイプの変更やエンジンのアップグレードを直ちに適用する場合は、**[今すぐ適用]** チェックボックスをオンにします。それ以外の場合は、次にスケジュールされているメンテナンス期間中にこれらの変更が適用されます。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/)—メンテナンスとノード交換のよくある質問
+ [ノードの置き換え (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 (クラスターモードが有効) クラスターで次のパラメータを変更する場合は、以降のステップに従います。
アクティブハッシュ化
データベース
クラスターの手動バックアップを作成します。「[手動バックアップの取得](backups-manual.md)」を参照してください。
クラスターを削除します。「[クラスターの削除](Clusters.html#Delete)」を参照してください。
変更されたパラメータグループとバックアップを使用してクラスターを復元し、新しいクラスターをシードします。「[バックアップから新しいキャッシュへの復元](backups-restoring.md)」を参照してください。
他のパラメータを変更する場合、これは必要ありません。
+ パラメータグループを Valkey および Redis OSS Global Datastore に関連付けることができます。[*Global Datastore*] は、複数の AWS リージョンにまたがる 1 つ以上のクラスターのコレクションです。この場合、パラメータグループは、Global Datastore を構成するすべてのクラスターで共有されます。プライマリクラスターのパラメータグループに対する変更は、Global Datastore 内の残りのすべてのクラスターにレプリケートされます。詳細については、「[グローバルデータストアを使用したAWSリージョン間のレプリケーション](Redis-Global-Datastore.md)」を参照してください。
パラメータグループが Global Datastore の一部であるかどうかを確認するには、次の場所を調べます。
+ [**パラメータグループ**] ページの ElastiCache コンソールで、yes/no [**グローバル**] 属性
+ [CacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CacheParameterGroup.html) API オペレーションの yes/no `IsGlobal` プロパティ
# ElastiCache のキャッシュパラメータグループの階層
Amazon ElastiCache には、以下に示すキャッシュパラメータグループの 3 つの階層があります。
![\[イメージ: Amazon ElastiCache パラメータグループの階層\]](http://docs.aws.amazon.com/ja_jp/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 パラメータグループを作成する
デフォルト値から変更するパラメータの値が 1 つ以上ある場合、新しいパラメータグループを作成する必要があります。ElastiCache コンソール、AWS CLI、または ElastiCache API を使用して、パラメータグループを作成できます。
## ElastiCache パラメータグループを作成する (コンソール)
次の手順では、ElastiCache コンソールを使用してパラメータグループを編集する方法を示します。
**ElastiCache コンソールを使用してパラメータグループを作成するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. 使用可能なすべてのパラメータグループのリストを表示するには、左側のナビゲーションペインで [**Parameter Groups**] を選択します。
1. パラメータグループを作成するには、[**Create Parameter Group**] を選択します。
[**Create Parameter Group**] 画面が表示されます。
1. [**Family**] のリストから、パラメータグループのテンプレートとなるパラメータグループファミリーを選択します。
*memcached1.4* や *redis3.2* などのパラメータグループファミリーは、パラメータグループの実際のパラメータとその初期値を定義します。パラメータグループファミリーは、クラスターのエンジンおよびバージョンと一致している必要があります。
1. **Name** ボックスで、このパラメータグループの一意の名前を入力します。
クラスターを作成、またはクラスターのパラメータグループを変更するときは、パラメータグループを名前で選択します。したがって、わかりやすくパラメータグループのファミリーを特定するのに役立つ名前をお勧めします。
パラメータグループの命名に関する制約は次のとおりです。
+ 先頭を ASCII 文字にする必要があります。
+ ASCII 文字、数字、ハイフンのみを含めることができます。
+ 1～255 文字にする必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
1. **Description** ボックスに、パラメータグループの説明を入力します。
1. パラメータグループを作成するには、作成**** を選択します。
パラメータグループを作成しないでプロセスを終了するには、**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=
```
このアクションからの応答は、次のようになります。
```
myMem14
memcached1.4
My first parameter group
d8465952-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=
```
このアクションからの応答は、次のようになります。
```
myRed28
redis2.8
My first parameter group
d8465952-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 マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. 使用可能なすべてのパラメータグループのリストを表示するには、左側のナビゲーションペインで **[パラメータグループ]** を選択します。
## 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 の場合は、パラメータグループが Global Datastore の一部である (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=
```
このアクションからの応答は、各グループパラメータの名前の一覧、ファミリー、説明となります。
```
myMem14
memcached1.4
My custom Memcached 1.4 parameter group
3540cc3d-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 の場合は、パラメータグループが Global Datastore に属している (isGlobal) かどうかを各パラメータグループについて説明します。
```
myRedis28
redis2.8
My custom Redis 2.8 parameter group
myMem14
memcached1.4
My custom Memcached 1.4 parameter group
myRedis56
redis5.0
My custom redis 5.6 parameter group
yes
3540cc3d-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=
```
このアクションからの応答は、名前、ファミリー、説明となります。
```
myRed28
redis2.8
My custom Redis 2.8 parameter group
3540cc3d-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=
```
このアクションからの応答は、名前、ファミリー、説明を一覧表示し、パラメータグループが Global Datastore の一部である (isGlobal) かどうかを表示します。
```
myRed56
redis5.0
My custom Redis 5.6 parameter group
yes
3540cc3d-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 マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. 使用可能なすべてのパラメータグループのリストを表示するには、左側のナビゲーションペインで **[パラメータグループ]** を選択します。
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)
ElastiCacheAPI を使用してパラメータグループのパラメータとその値を一覧表示するには、`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=
```
このアクションからの応答は、次のようになります。この応答には短縮されています。
```
integer
system
false
The maximum configurable amount of memory to use to store items, in megabytes.
1000
cache.c1.medium
6000
cache.c1.xlarge
7100
cache.m1.large
1300
cache.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=
```
このアクションからの応答は、次のようになります。この応答には短縮されています。
```
integer
system
false
The maximum configurable amount of memory to use to store items, in megabytes.
1000
cache.c1.medium
6000
cache.c1.xlarge
7100
cache.m1.large
1300
cache.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 マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. 使用可能なすべてのパラメータグループのリストを表示するには、左側のナビゲーションペインで **[パラメータグループ]** を選択します。
1. パラメータグループ名の左側にあるボックスを選択して、変更するパラメータグループを選択します。
パラメータグループのパラメータは、画面の下部に表示されます。すべてのパラメータを確認するには、ページでリストを作成する必要があります。
1. 複数のパラメータを修正するには、**[パラメータの編集]** を選択します。
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 (クラスターモードが無効) クラスターがあり、以下のパラメータを変更する場合は、クラスター内のノードを再起動する必要があります。
+ アクティブハッシュ化
+ データベース
詳細については、「[ノードの再起動](nodes.rebooting.md)」を参照してください。
**Valkey または Redis OSS (クラスターモードが有効) パラメータの変更**
Valkey または Redis OSS (クラスターモードが有効) クラスターで次のパラメータを変更する場合は、以降のステップに従います。
アクティブハッシュ化
データベース
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*] の 2 つのパラメータの値を設定します。
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*] の 2 つのパラメータの値を設定します。ここでは、*[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 (クラスターモードが無効) クラスターがあり、以下のパラメータを変更する場合は、クラスター内のノードを再起動する必要があります。
+ アクティブハッシュ化
+ データベース
詳細については、「[ノードの再起動](nodes.rebooting.md)」を参照してください。
**Valkey または Redis OSS (クラスターモードが有効) パラメータの変更**
Valkey または Redis OSS (クラスターモードが有効) クラスターで次のパラメータを変更する場合は、以降のステップに従います。
アクティブハッシュ化
データベース
クラスターの手動バックアップを作成します。「[手動バックアップの取得](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*] の 2 つのパラメータの値を設定します。
```
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*] の 2 つのパラメータの値を設定します。ここでは、[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 (クラスターモードが無効) クラスターがあり、以下のパラメータを変更する場合は、クラスター内のノードを再起動する必要があります。
+ アクティブハッシュ化
+ データベース
詳細については、「[ノードの再起動](nodes.rebooting.md)」を参照してください。
**Valkey または Redis OSS (クラスターモードが有効) パラメータの変更**
Valkey または Redis OSS (クラスターモードが有効) クラスターで次のパラメータを変更する場合は、以降のステップに従います。
アクティブハッシュ化
データベース
クラスターの手動バックアップを作成します。「[手動バックアップの取得](backups-manual.md)」を参照してください。
クラスターを削除します。「[ElastiCache でのクラスターの削除](Clusters.Delete.md)」を参照してください。
変更されたパラメータグループとバックアップを使用してクラスターを復元し、新しいクラスターをシードします。「[バックアップから新しいキャッシュへの復元](backups-restoring.md)」を参照してください。
他のパラメータを変更する場合、これは必要ありません。
# ElastiCache パラメータグループを削除する
ElastiCache コンソール、AWS CLI、または ElastiCache API を使用して、カスタムパラメータグループを削除できます。
パラメータグループがクラスターに関連付けられている場合は、パラメータグループを削除できません。デフォルトのパラメータグループも削除できません。
## パラメータグループを削除する (コンソール)
次の手順では、ElastiCache コンソールを使用してパラメータグループを削除する方法を示します。
**ElastiCache コンソールを使用してパラメータグループを削除するには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. 使用可能なすべてのパラメータグループのリストを表示するには、左側のナビゲーションペインで **[パラメータグループ]** を選択します。
1. パラメータグループ名の左側にあるボックスを選択して、削除するパラメータグループを選択します。
[**Delete**] ボタンがアクティブになります。
1. **[削除]** を選択します。
**パラメータグループの削除**の確認画面が表示されます。
1. パラメータグループを削除するには、[**Delete Parameter Groups**] の確認画面で [**Delete**] を選択します。
パラメータグループを保持するには、**キャンセル**を選択します。
## パラメータグループを削除する (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 help`、`commandlog len`、`commandlog reset.` はサーバーレスキャッシュで使用できません。
**Valkey 8.2 の新しいパラメータグループ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| search-fanout-target-mode (8.2 で追加) | デフォルト: client タイプ: 文字列 変更可能: はい 変更の適用: 即時 | search-fanout-target-mode 設定パラメータは、Valkey クラスター環境のノード間で検索クエリを分散する方法を制御します。この設定では、次の 2 つの値を使用できます。「throughput」の場合、クライアントタイプや READONLY ステータスに関係なく、検索クエリをすべてのクラスターノードにランダムに分散することで、最大のスループットが得られるように最適化します。「client」の場合、非 READONLY クライアントをプライマリノードのみにルーティングし、レプリカ接続上の READONLY クライアントをレプリカノードのみにルーティングし、プライマリ接続上の READONLY クライアントをすべてのノードにランダムにルーティングすることで、クライアントの接続特性に従います。 デフォルトの動作は「client」モードです。つまり、システムはクエリルーティングの決定の際にクライアント接続タイプと READONLY ステータスに従います。クラスターのリソースを最大限に利用することが望ましい大量の検索ワークロードには throughput モードを使用し、読み取り/書き込みの分離を維持してアプリケーションレベルの READONLY 接続パターンに従う場合は client モードを使用します。 |
| search-default-timeout-ms | デフォルト: 50,000 許可される値: 1～60,000 タイプ: 整数 変更可能: はい 変更の適用: 即時 | デフォルトの Valkey 検索クエリのタイムアウト (ミリ秒単位)。 |
| search-enable-partial-results | デフォルト: はい 許可される値: yes、no タイプ：ブール値 変更可能: はい 変更の適用: 即時 | Valkey 検索のクエリ失敗動作を設定します。有効にした場合、1 つ以上のシャードでタイムアウトが発生すると、検索クエリは部分的な結果を返します。無効にした場合、シャードタイムアウトにより検索クエリ全体が失敗し、エラーが返されます。 |
### 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 help`、`commandlog len`、`commandlog reset.` はサーバーレスキャッシュで使用できません。
**Valkey 8.1 の新しいパラメータグループ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| commandlog-large-request-max-len (8.1 で追加) | デフォルト: 1048576 タイプ: 整数 変更可能: はい 変更の適用: 即時 | Valkey コマンドログ機能によってログに記録されるリクエストの最大サイズ (バイト単位)。 |
| commandlog-large-request-max-len (8.1 で追加) | デフォルト: 128 許可される値: 0～1024 タイプ: 整数 変更可能: はい 変更の適用: 即時 | リクエストの Valkey コマンドログの最大長。 |
| commandlog-reply-larger-than (8.1 で追加) | デフォルト: 1048576 タイプ: 整数 変更可能: はい 変更の適用: 即時 | Valkey コマンドログ機能によってログに記録されるレスポンスの最大サイズ (バイト単位)。 |
| commandlog-large-reply-max-len (8.1 で追加) | デフォルト: 128 許可される値: 0～1024 タイプ: 整数 変更可能: はい 変更の適用: 即時 | レスポンスの Valkey コマンドログの最大長。 |
### Valkey 8.0 パラメータの変更
**パラメータグループファミリー:** valkey8
**注記**
Redis OSS 7.2.4 は Valkey 8 以降のパラメータグループと互換性がありません。
**Valkey 8.0 での特定のパラメータの変更**
| 名前 | Details | 説明 |
| --- | --- | --- |
| repl-backlog-size | デフォルト: 10485760 タイプ: 整数 変更可能: はい 変更の適用: 即時 | プライマリノードバックログバッファーのサイズ (バイト単位)。バックログは、プライマリノードのデータの更新を記録するために使用されます。リードレプリカは、プライマリに接続すると、部分同期 (psync) の実行を試みます。このとき、プライマリノードに追いつくことができるようにバックログからデータを適用します。psync に失敗した場合は、完全同期が必要です。 このパラメータの最小値は 16384 です。 注意: Redis OSS 2.8.22 から、このパラメータはプライマリクラスターとリードレプリカに適用されます。 |
| maxmemory-samples | デフォルト: 3 許可される値: 1～64 タイプ: 整数 変更可能: はい 変更の適用: 即時 | LRU (least-recently-used) と TTL (time-to-live) の計算の場合、このパラメータはチェックするキーのサンプルサイズを表します。デフォルトで、Redis OSS は 3 個のキーを選択し、最も長い間使用されていないキーを使用します。 |
**Valkey 8.0 の新しいパラメータグループ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| extended-redis-compatibility | 許可される値: yes、no デフォルト: はい 型: ブール値 変更可能: はい 変更の反映: 即時 | 拡張 Redis OSS 互換モードでは、Valkey が Redis OSS 7.2 のように動作します。これは、ツールまたはクライアントに問題がある場合にのみ有効にします。 顧客に対する影響: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
**Valkey 8.0 で削除されたパラメータグループ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| lazyfree-lazy-eviction | 許可される値: yes、no デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | 削除で、非同期削除を実行します。 |
| lazyfree-lazy-expire | 許可される値: yes、no デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | 期限切れのキーで、非同期削除を実行します。 |
| lazyfree-lazy-server-del | 許可される値: yes、no デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | 値を更新するコマンドに対して非同期削除を実行します。 |
| lazyfree-lazy-user-del | デフォルト: いいえ タイプ: 文字列 変更可能: はい 変更の適用: クラスター内のすべてのノードにわたって即時 | 値を yes に設定すると、DEL コマンドは UNLINK と同じように動作します。 |
| replica-lazy-flush | デフォルト: はい 型: ブール値 変更可能: いいえ 旧名: 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 も、これらのパラメータをサポートしています。
| 名前 | Details | 説明 |
| --- | --- | --- |
| 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 で変更されたパラメータは次のとおりです。
| 名前 | Details | 説明 |
| --- | --- | --- |
| activerehashing | 変更可能: `no`。Redis OSS 7 では、このパラメーターはデフォルトで非表示および有効になっています。無効にするには、[サポートケース](https://console.aws.amazon.com/support/home)を作成する必要があります。 | 変更可能は Yes でした。 |
Redis OSS 7 で削除されたパラメータは次のとおりです。
| 名前 | Details | 説明 |
| --- | --- | --- |
| hash-max-ziplist-entries | 許可される値: `0+` デフォルト: `512` 型: 整数 変更可能: はい 変更の適用: クラスター内のすべてのノードにわたって即時 | 小さなハッシュエンコーディングを表現するために `listpack` を `ziplist` の代わりに使用する |
| hash-max-ziplist-value | 許可される値: `0+` デフォルト: `64` 型: 整数 変更可能: はい 変更の適用: クラスター内のすべてのノードにわたって即時 | 小さなハッシュエンコーディングを表現するために `listpack` を `ziplist` の代わりに使用する |
| zset-max-ziplist-entries | 許可される値: `0+` デフォルト: `128` 型: 整数 変更可能: はい 変更の適用: クラスター内のすべてのノードにわたって即時 | 小さなハッシュエンコーディングを表現するために `listpack` を `ziplist` の代わりに使用します。 |
| zset-max-ziplist-value | 許可される値: `0+` デフォルト: `64` 型: 整数 変更可能: はい 変更の適用: クラスター内のすべてのノードにわたって即時 | 小さなハッシュエンコーディングを表現するために `listpack` を `ziplist` の代わりに使用します。 |
| 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 で、[ElastiCache のデータ階層化](data-tiering.md)で使用するための r6gd ノードファミリーが導入された場合、r6gd ノードタイプでは、*noeviction*、*volatile-lru*、および *allkeys-lru* の最大メモリポリシーのみがサポートされます。
詳細については、「[Redis OSS 用の ElastiCache バージョン 6.2 (拡張)](engine-versions.md#redis-version-6.2)」および「[Redis OSS 用の ElastiCache バージョン 6.0 (拡張)](engine-versions.md#redis-version-6.0)」を参照してください。
Redis OSS 6.x で追加されたパラメータは次のとおりです。
| Details | 説明 |
| --- | --- |
| 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) | デフォルト: いいえ タイプ: 文字列 変更可能: はい 変更の適用: クラスター内のすべてのノードにわたって即時 | [はい] に設定すると、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 は、2 つのメカニズムによって、有効期限 (TTL) を超えたキーを削除します。1 つでは、キーがアクセスされ、期限切れであることが判明します。もう 1 つでは、定期的なジョブがキーをサンプリングし、有効期限 (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 で削除されたパラメータは次のとおりです。
| 名前 | Details | 説明 |
| --- | --- | --- |
| lua-replicate-commands | 許可される値: はい/いいえ デフォルト: はい 型: ブール値 変更可能: はい 変更の適用: 即時 | Lua 効果レプリケーションを常に有効にするか、Lua スクリプトでは有効にしません |
### Redis OSS 5.0.3 パラメータの変更
**パラメータグループファミリー:** 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 で追加されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| 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` |
詳細については、「[Redis OSS 用の ElastiCache バージョン 5.0.6 (拡張)](engine-versions.md#redis-version-5-0.6)」を参照してください。
### Redis OSS 5.0.0 パラメータの変更
**パラメータグループファミリー:** redis5.0
Redis OSS 5.0 のデフォルトのパラメータグループ
+ `default.redis5.0` – このパラメータグループ、またはそこから派生したグループを、Valkey または Redis OSS (クラスターモードが無効) クラスターおよびレプリケーショングループに使用します。
+ `default.redis5.0.cluster.on` – このパラメータグループ、またはそこから派生したグループを、Valkey または Redis OSS (クラスターモードが有効) クラスターおよびレプリケーショングループに使用します。
**Redis OSS 5.0 で追加されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| stream-node-max-bytes | 許可される値: 0\$1 デフォルト: 4096 タイプ: 整数 変更可能: はい 変更の適用: 即時 | ストリームデータ構造は、内部の複数のアイテムをエンコードするノードの基数ツリーです。基数ツリーの単一ノードの最大サイズをバイト単位で指定するには、この設定を使用します。0 に設定されている場合、ツリーノードのサイズは無制限です。 |
| stream-node-max-entries | 許可される値: 0\$1 デフォルト: 100 タイプ: 整数 変更可能: はい 変更の適用: 即時 | ストリームデータ構造は、内部の複数のアイテムをエンコードするノードの基数ツリーです。新しいストリームエントリを追加するとき、新しいノードに切り替える前に単一ノードに含めることができるアイテムの最大数を指定するには、この設定を使用します。0 に設定されている場合、ツリーノードのアイテムの数は無制限です |
| active-defrag-max-scan-fields | 許可される値: 1～1000000 デフォルト: 1000 タイプ: 整数 変更可能: はい 変更の適用: 即時 | メインディクショナリスキャンから処理される set/hash/zset/list フィールドの最大数 |
| lua-replicate-commands | 許可される値: はい/いいえ デフォルト: はい 型: ブール値 変更可能: はい 変更の適用: 即時 | Lua 効果レプリケーションを常に有効にするか、Lua スクリプトでは有効にしません |
| replica-ignore-maxmemory | デフォルト: はい 型: ブール値 変更可能: いいえ | プライマリから独立したアイテムを削除しないで、レプリカが maxmemory 設定を無効にするかどうかを判断します。 |
Redis OSS は、コミュニティのフィードバックに応じてエンジンバージョン 5.0 でいくつかのパラメータの名前を変更しました。詳細については、「[Redis OSS 5 の最新情報](https://aws.amazon.com/redis/Whats_New_Redis5/)」を参照してください。次の表に、新しい名前と前のバージョンとの対応を示します。
**Redis OSS 5.0 で名前が変更されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| replica-lazy-flush | デフォルト: はい 型: ブール値 変更可能: いいえ 旧名: 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 変更の適用: 即時 | プライマリノードからリードレプリカから ping リクエストを受け取る必要がある秒数。この時間が経過してもプライマリが ping を受け取らない場合、レプリカは使用可能と見なされなくなります。使用可能なレプリカの数が min-replicas-to-write を下回った場合、プライマリはその時点で書き込みの受け入れを停止します。 このパラメータか min-replicas-to-write のどちらかが 0 の場合、レプリカが使用できない場合でもプライマリノードは常に書き込みリクエストを受け入れます。 |
| close-on-replica-write | デフォルト: はい 型: ブール値 変更可能: はい 旧名: close-on-slave-write 変更の適用: 即時 | 有効にした場合、読み取り専用レプリカに書き込もうとするクライアントの接続は切断されます。 |
**Redis OSS 5.0 で削除されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| 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 で変更されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| 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 では、2 つの新しい許容値が追加されました。allkeys-lfu は、近似 LFU を使用して、すべてのキーを削除します。volatile-lfu は、近似 LFU を使用して、有効期限が設定されたキーを削除します。バージョン 6.2 では、データ階層化で使用するために r6gd ノードファミリーが導入された場合、noeviction、volatile-lru および allkeys-lru max-memory ポリシーのみが r6gd ノードタイプでサポートされます。 |
**Redis OSS 4.0.10 で追加されたパラメータ**
| 名前 | Details | 説明 |
| --- |--- |--- |
| **非同期削除パラメータ** |
| --- |
| lazyfree-lazy-eviction | 許可される値: はい/いいえ デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | Performs an asynchronous delete on evictions. |
| lazyfree-lazy-expire | 許可される値: はい/いいえ デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | Performs an asynchronous delete on expired keys. |
| lazyfree-lazy-server-del | 許可される値: はい/いいえ デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | Performs an asynchronous delete for commands which update values. |
| slave-lazy-flush | 許可される値: 該当なし デフォルト: いいえ 型: ブール値 変更可能: いいえ 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 | 許可される値: はい/いいえ デフォルト: いいえ 型: ブール値 変更可能: はい 変更の反映: 即時 | アクティブなデフラグメンテーションを有効にします。 Valkey および Redis OSS バージョン 7.0 以降AWSでは、この設定に関係なく、運用上必要なときに自動的にデフラグを実行できます。 |
| active-defrag-ignore-bytes | 許可される値: 10485760～104857600 デフォルト: 104857600 タイプ: 整数 変更可能: はい 変更の反映: 即時 | Minimum amount of fragmentation waste to start active defrag. |
| active-defrag-threshold-lower | 許可される値: 1～100 デフォルト: 10 タイプ: 整数 変更可能: はい 変更の反映: 即時 | Minimum percentage of fragmentation to start active defrag. |
| active-defrag-threshold-upper | 許可される値: 1～100 デフォルト: 100 タイプ: 整数 変更可能: はい 変更の反映: 即時 | Maximum percentage of fragmentation at which we use maximum effort. |
| active-defrag-cycle-min | 許可される値: 1～75 デフォルト: 25 タイプ: 整数 変更可能: はい 変更の反映: 即時 | Minimal effort for defrag in CPU percentage. |
| active-defrag-cycle-max | 許可される値: 1～75 デフォルト: 75 タイプ: 整数 変更可能: はい 変更の反映: 即時 | Maximal effort for defrag in CPU percentage. |
| **クライアント出力バッファのパラメータ** |
| --- |
| client-query-buffer-limit | 許可される値: 1048576～1073741824 デフォルト: 1073741824 タイプ: 整数 変更可能: はい 変更の反映: 即時 | Max size of a single client query buffer. |
| proto-max-bulk-len | 許可される値: 1048576～536870912 デフォルト: 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` – Redis OSS 3.2.4 を実行する場合、Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループを作成し、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 では、次のパラメータが追加でサポートされます。
****
| 名前 | Details | 説明 |
| --- | --- | --- |
| list-max-ziplist-size | デフォルト: -2 タイプ: 整数 変更可能: いいえ | リストは、領域を節約する特殊な方法でエンコードされます。内部リストノードあたり許可されるエントリの数は、要素の固定最大サイズまたは最大数として指定できます。最大固定サイズには、-5～-1 を使用します。この意味は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| list-compress-depth | デフォルト: 0 タイプ: 整数 変更可能: はい 変更の適用: 即時 | リストは、圧縮される場合もあります。圧縮の深さは、圧縮から除外するリストの端からのクイックリスト ziplist ノードの数です。リストの先頭と末尾は、プッシュおよびポップオペレーションを高速にするために常に圧縮されません。設定は以下のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| cluster-enabled | デフォルト: no/yes \$1 タイプ: 文字列 変更可能: いいえ | これがクラスターモードの Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループである (yes) か、非クラスターモードの Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループである (no) かを示します。クラスターモードの Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループは、最大 500 のノードグループ間でデータを分割できます。 \$1 Redis OSS 3.2.*x* には 2 つのデフォルトのパラメータグループがあります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html). |
| cluster-require-full-coverage | デフォルト: いいえ 型: ブール値 変更可能: はい 変更の適用: 即時 | `yes` に設定された場合、Valkey または Redis OSS (クラスターモードが有効) のクラスターモード内のノードは、少なくとも 1 つのハッシュスロットがカバーされていない (利用可能なノードがそれを処理していない) ことを検出した場合、クエリの受け付けを停止します。このように、クラスターが部分的にダウンしている場合、クラスターは使用できなくなります。すべてのスロットが再び処理対象になると、クラスターは自動的に再び使用可能になります。 ただし、まだ処理対象になっているキー空間の部分に対するクエリを受け入れ続けるようにクラスターのサブセットが機能していることが必要な場合があります。その場合は、`cluster-require-full-coverage` オプションを `no` に設定するだけです。 |
| hll-sparse-max-bytes | デフォルト: 3000 タイプ: 整数 変更可能: はい 変更の適用: 即時 | HyperLogLog のスパースな表示バイト制限。この制限には 16 バイトのヘッダーが含まれます。スパースな表現を使用する HyperLogLog がこの制限を超えると、デンスな表現に変換されます。 16,000 より大きい値はお勧めしません。その時点では、デンスな表現の方がメモリ効率が高くなるためです。 PFADD の速度を下げすぎることなく領域効率の良いエンコードの利点を活かせる (スパースなエンコードで O(N) になる) ように、値は約 3,000 にすることをお勧めします。問題が CPU ではなく領域であり、データセットが 0～15,000 の濃度の大量の HyperLogLog で構成されているときは、値を 10,000 まで大きくすることができます。 |
| 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 では、以下のパラメータが変更されました。
****
| 名前 | Details | 変更 |
| --- | --- | --- |
| activerehashing | 変更可能: パラメータグループがいずれのクラスターにも関連付けられていない場合は、はい。それ以外の場合は No です。 | 変更可能は No でした。 |
| databases | 変更可能: パラメータグループがいずれのクラスターにも関連付けられていない場合は、はい。それ以外の場合は No です。 | 変更可能は No でした。 |
| 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 では、以下のパラメータが追加でサポートされます。
****
| 名前 | Details | 説明 |
| --- | --- | --- |
| close-on-slave-write | デフォルト: はい タイプ: 文字列 (はい/いいえ) 変更可能: はい 変更の適用: 即時 | 有効にした場合、読み取り専用レプリカに書き込もうとするクライアントの接続は切断されます。 |
#### close-on-slave-write の動作
`close-on-slave-write` パラメータが Amazon ElastiCache によって導入されたことで、リードレプリカがプライマリノードに昇格するために両者間でロールが入れ替わるときのクラスターの応答を、より細かく制御できるようになりました。
![\[イメージ: close-on-replica-write、すべてが正常に動作\]](http://docs.aws.amazon.com/ja_jp/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/ja_jp/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/ja_jp/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 では、次のパラメータが追加でサポートされます。
****
| 名前 | Details | 説明 |
| --- | --- | --- |
| min-slaves-max-lag | デフォルト: 10 タイプ: 整数 変更可能: はい 変更の適用: 即時 | プライマリノードからリードレプリカから ping リクエストを受け取る必要がある秒数。この時間が経過してもプライマリが ping を受け取らない場合、レプリカは使用可能と見なされなくなります。使用可能なレプリカの数が min-slaves-to-write を下回った場合、プライマリはその時点で書き込みの受け入れを停止します。 このパラメータか min-slaves-to-write のどちらかが 0 の場合、レプリカが使用できない場合でもプライマリノードは常に書き込みリクエストを受け入れます。 |
| min-slaves-to-write | デフォルト: 0 タイプ: 整数 変更可能: はい 変更の適用: 即時 | プライマリノードがクライアントからの書き込みを受け入れるために、使用可能でなければならないリードレプリカの数。使用可能なレプリカの数がこの数を下回った場合、プライマリノードは書き込みリクエストを受け入れなくなります。 このパラメータか min-slaves-max-lag のどちらかが 0 の場合、レプリカが使用できない場合でもプライマリノードは常に書き込みリクエストを受け入れます。 |
| notify-keyspace-events | デフォルト: (空の文字列) タイプ: 文字列 変更可能: はい 変更の適用: 即時 | Redis OSS がクライアントに通知できる keyspace イベントのタイプ。各イベントタイプは 1 文字で表されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) これらのイベントタイプは自由に組み合わせることができます。例えば、*AKE* は Redis OSS がすべてのイベントタイプの通知を発行できることを意味します。 上に挙げられた文字以外の文字を使用しないでください。使用しようとすると、エラーメッセージが表示されます。 デフォルトでは、このパラメータは空の文字列に設定されます。これは、keyspace イベント通知が無効であることを意味します。 |
| 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/ja_jp/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/ja_jp/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html)
**注記**
Redis OSS 2.6.13 クラスターにパラメータグループを指定しない場合、デフォルトのパラメータグループ (`default.redis2.6`) が使用されます。デフォルトのパラメータグループ内のパラメータは、どれも値を変更できません。ただし、いつでもカスタムパラメータグループを作成して、クラスターに割り当てることができます。
### Redis OSS のノードタイプに固有のパラメータ
ほとんどのパラメータの値は 1 つですが、一部のパラメータには、使用されているノードタイプによって複数の値が設定されることがあります。次の表は、各ノードタイプの `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 では、次のパラメータが追加でサポートされます。
**パラメータグループファミリー:** memcached1.5
| 名前 | Details | 説明 |
| --- | --- | --- |
| no\$1modern | デフォルト: 1 型: ブール値 変更可能: はい 許可された値: 0,1 変更の適用: 起動時 | `slab_reassign`、`lru_maintainer_thread`、`lru_segmented`、`maxconns_fast` コマンドを無効にするためのエイリアス。 Memcached 1.5 以降を使用する場合、`no_modern` は hash\$1algorithm を `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 型: ブール値 変更可能: はい 許可された値: 0,1 変更の適用: 起動時 | アイテム内の `VALUE` レスポンスからの数値が保存されます。最大 24 バイトを使用します。ASCII `get`、`faster` セットの小さい減速。 |
Memcached 1.5.10 では、次のパラメータが削除されます。
| 名前 | Details | 説明 |
| --- | --- | --- |
| expirezero\$1does\$1not\$1evict | デフォルト: 0 型: ブール値 変更可能: はい 許可された値: 0,1 変更の適用: 起動時 | このバージョンではサポートされなくなりました。 |
| modern | デフォルト: 1 型: ブール値 変更可能: はい (`no_modern` に設定されている場合は再起動が必要です) 許可された値: 0,1 変更の適用: 起動時 | このバージョンではサポートされなくなりました。このバージョン以降、起動または再起動するたびに `no-modern` がデフォルトで有効になります。 |
### Memcached 1.4.34 で追加されたパラメータ
Memcached 1.4.34 では、追加のパラメータはサポートされません。
**パラメータグループファミリー:** memcached1.4
### Memcached 1.4.33 で追加されたパラメータ
Memcached 1.4.33 では、次のパラメータが追加でサポートされます。
**パラメータグループファミリー:** memcached1.4
| 名前 | Details | 説明 |
| --- | --- | --- |
| modern | デフォルト: 有効 型: ブール値 変更可能: はい 変更の適用: 起動時 | 各種機能のエイリアス 有効化 `modern` は、次のコマンドをオンにし、murmur3 ハッシュアルゴリズム (`slab_reassign`、`slab_automove`、`lru_crawler`、`lru_maintainer`、`maxconns_fast`、`hash_algorithm=murmur3`) を使用する場合と同等です。 |
| watch | デフォルト: 有効 型: ブール値 変更可能: はい 変更の適用: 即時 ログは、`watcher_logbuf_size` および `worker_logbuf_size` 制限に達すると削除できます。 | ログ取得、削除または変異。たとえば、`watch` をオンにすると、`get`、`set`、`delete` または `update` が発生したときにユーザーはログを表示できます。 |
| idle\$1timeout | デフォルト: 0 (無効) タイプ: 整数 変更可能: はい 変更の適用: 起動時 | 閉じる前にクライアントがアイドル状態にできる最小秒数。値の範囲: 0～86400 |
| track\$1sizes | デフォルト: 無効 型: ブール値 変更可能: はい 変更の適用: 起動時 | 各スラブグループの消費サイズを表示します。 有効化 `track_sizes` を行うと、`stats sizes` を実行せずに `stats sizes_enable` を実行できます。 |
| 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] | デフォルト: 無効 型: ブール値 変更可能: はい 変更の適用: 即時 | lru\$1crawler を有効化すると、このコマンドによってすべてのキーがダンプされます。 `all\|1\|2\|3` - すべてのスラブ、または特定のスラブ数を指定する |
### Memcached 1.4.24 で追加されたパラメータ
Memcached 1.4.24 では、次のパラメータが追加でサポートされます。
**パラメータグループファミリー:** memcached1.4
| 名前 | Details | 説明 |
| --- | --- | --- |
| disable\$1flush\$1all | デフォルト: 0 (無効) 型: ブール値 変更可能: はい 変更の適用: 起動時 | flush\$1all を無効化するパラメータ (`-F`) を追加します。本稼働インスタンスでフルフラッシュを実行しない場合に便利です。 値: 0、1 (値が 0 の場合にユーザーは `flush_all` を実行できます。) |
| hash\$1algorithm | デフォルト: jenkins タイプ: 文字列 変更可能: はい 変更の適用: 起動時 | 使用されるハッシュアルゴリズム。使用可能な値: murmur3 と jenkins。 |
| lru\$1crawler | デフォルト: 0 (無効) 型: ブール値 変更可能: はい 変更の適用: 再起動後 実行時に、コマンドラインから `lru_crawler` を一時的に有効にすることができます。詳細については、「Describe」列を参照してください。 | 期限が切れた項目のスラブクラスを消去します。これにより、バックグラウンドで実行されるプロセスの影響を小さくなります。現在は、手動コマンドを使用して Crawl を起動する必要があります。 一時的に有効にするには、コマンドラインで `lru_crawler enable` を実行します。 `lru_crawler 1,3,5` はスラブクラス 1、3、5 をクロールし、freelist に追加する期限切れの項目を検索します。 値: 0、1 コマンドラインで `lru_crawler` を有効にして、コマンドラインまたは次の再起動で無効化されるまでクローラを有効にします。永続的に有効にするには、パラメータ値を変更する必要があります。詳細については、「[ElastiCache パラメータグループを変更する](ParameterGroups.Modifying.md)」を参照してください。 |
| lru\$1maintainer | デフォルト: 0 (無効) 型: ブール値 変更可能: はい 変更の適用: 起動時 | 容量に到達すると LRU 間で項目をシャッフルするバックグラウンドスレッドです。値: 0、1。 |
| expirezero\$1does\$1not\$1evict | デフォルト: 0 (無効) 型: ブール値 変更可能: はい 変更の適用: 起動時 | `lru_maintainer` と併用すると、項目の期限切れ時間が 0 (期限切れなし) になります。 これにより、期限切れでクリアされる他の項目をメモリから排除して、メモリを使用できるようにすることができます。 `lru_maintainer` を無視するよう設定できます。 |
### Memcached 1.4.14 で追加されたパラメータ
Memcached 1.4.14 では、次のパラメータが追加でサポートされます。
**パラメータグループファミリー:** memcached1.4
**Memcached 1.4.14 で追加されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| 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 に設定した場合、「slabs reassign」コマンドを使用してメモリを手動で再割り当てできます。 |
### Memcached 1.4.5 でサポートされているパラメータ
**パラメータグループファミリー:** memcached1.4
Memcached 1.4.5 では、さらに次のパラメータがサポートされています。
**Memcached 1.4.5 で追加されたパラメータ**
| 名前 | Details | 説明 |
| --- | --- | --- |
| backlog\$1queue\$1limit | デフォルト: 1024 タイプ: 整数 変更可能: いいえ | バックログキューの制限。 |
| binding\$1protocol | デフォルト: auto タイプ: 文字列 変更可能: はい 変更の適用: 再起動後 | バインディングプロトコル。許可される値は `ascii` および `auto` です。 `binding_protocol` の値を変更する際のガイダンスについては、「[ElastiCache パラメータグループを変更する](ParameterGroups.Modifying.md)」を参照してください。 |
| cas\$1disabled | デフォルト: 0 (false) タイプ: ブール値 変更可能: はい 変更の適用: 再起動後 | 1 (true) の場合、CAS (Check and Set) 操作が無効になり、格納されている項目が消費するバイト数は CAS が有効な場合より 8 バイト少なくなります。 |
| chunk\$1size | デフォルト: 48 タイプ: 整数 変更可能: はい 変更の適用: 再起動後 | 最も小さい項目のキー、値、およびフラグ (バイト単位) に割り当てる領域の最小量 (バイト単位)。 |
| chunk\$1size\$1growth\$1factor | デフォルト: 1.25 タイプ: 浮動小数点 変更可能: はい 変更の適用: 再起動後 | 連続する各 memcached チャンクのサイズを制御する増加係数。各チャンクは、前のチャンクより chunk\$1size\$1growth\$1factor 倍大きくなります。 |
| error\$1on\$1memory\$1exhausted | デフォルト: 0 (false) タイプ: ブール値 変更可能: はい 変更の適用: 再起動後 | 1 (true) の場合、項目を保存するメモリがないと、Memcached によって項目が削除されるのではなくエラーが返されます。 |
| large\$1memory\$1pages | デフォルト: 0 (false) タイプ: ブール値 変更可能: いいえ | 1 (true) の場合、ElastiCache は大量のメモリページを使用しようとします。 |
| lock\$1down\$1paged\$1memory | デフォルト: 0 (false) タイプ: ブール値 変更可能: いいえ | 1 (true) の場合、ElastiCache はすべてのページ分割メモリをロックダウンします。 |
| max\$1item\$1size | デフォルト: 1048576 タイプ: 整数 変更可能: はい 変更の適用: 再起動後 | クラスターに保存できる最も大きい項目のサイズ (バイト単位)。 |
| max\$1simultaneous\$1connections | デフォルト: 65000 タイプ: 整数 変更可能: いいえ | 同時接続の最大数。 |
| maximize\$1core\$1file\$1limit | デフォルト: 0 (false) タイプ: ブール値 変更可能: 変更の適用: 再起動後 | 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` がデフォルト値の 100 MB の場合、Memcached プロセスは項目を保存するために 1,200 MB 使用できます。
`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` の値を 13 MB に設定します。
自身で作成したパラメータグループをクラスターが使用している場合、`memcached_connections_overhead` の値を選択した値に設定できます。
### Memcached ノードタイプ固有のパラメータ
ほとんどのパラメータの値は 1 つですが、一部のパラメータには、使用されているノードタイプによって複数の値が設定されることがあります。次の表は、各ノードタイプの `max_cache_memory` パラメータと `num_threads` パラメータのデフォルト値を示しています。これらのパラメータの値は変更できません。
| ノードタイプ | max\$1cache\$1memory (メガバイト) | 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 キャッシュにアクセスするウェブサーバーやアプリケーションを実行することもできます。
![\[ElastiCache キャッシュを EC2 インスタンスに自動的に接続します。\]](http://docs.aws.amazon.com/ja_jp/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 に存在している必要があります。
同じ VPC に EC2 インスタンスが存在しない場合、コンソールには 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 キャッシュに関連付けられているセキュリティグループの中に、パターン `elasticache-ec2-${cacheId}:${ec2InstanceId}` に一致する名前を持つものが 1 つ以上存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | EC2 インスタンスに関連付けられた、パターン `elasticache-ec2-${cacheId}:${ec2InstanceId}` に一致する名前のセキュリティグループが 1 つまたは複数存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、ソースとしての ElastiCache キャッシュの VPC セキュリティグループにアウトバウンドルールが 1 つのみ存在します。 | ElastiCache はアクションを実行しません。 EC2 インスタンスと ElastiCache キャッシュ間の接続は、既に自動で設定されています。EC2 インスタンスと ElastiCache キャッシュの間には既に接続が存在するため、セキュリティグループは変更されません。 |
| 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/compute-connection.html) | 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/compute-connection.html) | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| ElastiCache キャッシュに関連付けられているセキュリティグループの中に、パターン `elasticache-ec2-${cacheId}:${ec2InstanceId}` に一致する名前を持つものが 1 つ以上存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | EC2 インスタンスに関連付けられた、パターン `elasticache-ec2-${cacheId}:${ec2InstanceId}` に一致する名前のセキュリティグループが 1 つまたは複数存在します。ただし、ElastiCache では、ElastiCache キャッシュとの接続にこれらのセキュリティグループのいずれも使用することはできません。ElastiCache では、ElastiCache キャッシュの VPC セキュリティグループをソースとするアウトバウンドルールが 1 つも存在しないセキュリティグループを使用できません。また、ElastiCache では、変更されたセキュリティグループを使用できません。 | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| ElastiCache キャッシュに関連付けられているセキュリティグループの中に、パターン `elasticache-ec2-${cacheId}:${ec2InstanceId}` に一致する名前を持つものが 1 つ以上存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | 接続に有効な EC2 セキュリティグループは存在しますが、EC2 インスタンスに関連付けられていません。このセキュリティグループには、パターン `ec2-elasticache-${ec2InstanceId}:${cacheId}` に一致する名前が付いています。このセキュリティグループには変更が加えられていません。ソースとしての ElastiCache キャッシュの VPC セキュリティグループにアウトバウンドルールが 1 つのみ存在します。 | [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/ja_jp/AmazonElastiCache/latest/dg/compute-connection.html) | EC2 インスタンスに関連付けられた、パターン `ec2-elasticache-${ec2InstanceId}:${cacheId}` に一致する名前のセキュリティグループが 1 つまたは複数存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、ソースとしての ElastiCache キャッシュの VPC セキュリティグループにアウトバウンドルールが 1 つのみ存在します。 | [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 セキュリティグループにアウトバウンドルールが 1 つ存在します。このセキュリティグループは EC2 インスタンスに関連付けられ、これにより EC2 インスタンスは ElastiCache キャッシュにトラフィックを送信できます。
**ElastiCache アクション: EC2 セキュリティグループを関連付ける**
ElastiCache は、有効な既存の EC2 セキュリティグループを EC2 インスタンスに関連付けます。このセキュリティグループにより、EC2 インスタンスは ElastiCache キャッシュにトラフィックを送信できます。
## 接続中のコンピューティングリソースを表示する
AWS マネジメントコンソールを使用して、ElastiCache キャッシュに接続されているコンピューティングリソースを表示できます。表示されるリソースには、自動的に設定されたコンピューティングリソース接続が含まれます。例えば、キャッシュに関連付けられた VPC セキュリティグループにルールを追加することで、コンピューティングリソースがキャッシュに手動でアクセスできるようになります。これらのリソースは、接続されたコンピューティングリソースのリストには表示されません。
コンピューティングリソースを一覧表示するには、EC2 インスタンスと ElastiCache キャッシュを自動的に接続する場合と同じ条件を適用する必要があります。
**ElastiCache キャッシュに接続されたコンピューティングリソースを表示する方法**
1. AWS マネジメントコンソールにサインインし、ElastiCache コンソールを開きます。
1. ナビゲーションパネルで、**[キャッシュ]** を選択して、Valkey または Redis OSS のキャッシュを選択します。
1. **[接続とセキュリティ]** タブの **[コンピューティング接続をセットアップ]** にコンピューティングリソースが表示されます。
![\[接続中のコンピューティングリソース。\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ec2-elasticache-connected_resources.png)
# ElastiCache のスケーリング
ElastiCache キャッシュは、ニーズに合わせてスケールできます。サーバーレスキャッシュとノードベースのクラスターには、複数の異なるスケーリングオプションが用意されています。
## ElastiCache サーバーレスのスケーリング
ElastiCache サーバーレスは、ワークロードトラフィックの増減に応じて自動的に対応します。ElastiCache では、各 ElastiCache サーバーレスキャッシュの CPU、メモリ、ネットワークなどのリソースの使用率を継続的に追跡しています。これらのリソースのいずれかに制約がある場合、ElastiCache サーバーレスは新しいシャードを追加し、データを新しいシャードに再分配することでスケールアウトします。アプリケーションのダウンタイムは発生しません。キャッシュデータストレージの `BytesUsedForCache` メトリクスとコンピューティング使用量の `ElastiCacheProcessingUnits` (ECPU) メトリクスをモニタリングすることで、CloudWatch のキャッシュによって消費されているリソースをモニタリングできます。
## スケーリング制限を設定してコストを管理する
キャッシュコストを抑えるために、キャッシュデータストレージとキャッシュの ECPU/秒の両方に使用量の上限を設定することができます。そうすることで、キャッシュ使用量が設定した上限を超えることがなくなります。
スケーリングの上限を設定した場合、キャッシュが上限に達すると、アプリケーションのキャッシュパフォーマンスが低下する可能性があります。キャッシュデータストレージの上限を設定し、キャッシュデータストレージが上限に達すると、ElastiCache は LRU ロジックを使用して Time-To-Live (TTL) が設定されているキャッシュ内のデータの削除を開始します。削除できるデータがない場合、追加データを書き込むリクエストにはメモリ不足(OOM) エラーメッセージが表示されます。ECPU/秒の上限を設定し、ワークロードのコンピューティング使用率がこの値を超えると、ElastiCache はリクエストのスロットリングを開始します。
`BytesUsedForCache` または `ElastiCacheProcessingUnits` に上限を設定する場合、CloudWatch アラームを上限よりも低い値に設定することを強くお勧めします。これにより、キャッシュがこの制限に近づいたときに通知を受け取ることができます。設定した上限の 75% にアラームを設定することをお勧めします。CloudWatch アラームの設定方法については、ドキュメントを参照してください。
## ElastiCache サーバーレスでの事前スケーリング
**ElastiCache サーバーレスの事前スケーリング**
事前スケーリングは事前ウォーミングとも呼ばれ、ElastiCache キャッシュでサポートされる最小制限を設定できます。これらの最小値は、1 秒あたりの ElastiCache 処理ユニット数 (ECPU) またはデータストレージに対して設定できます。これは、予想されるスケーリングイベントに備えるうえで役立ちます。例えば、あるゲーム会社で新しいゲームのリリースから最初の 1 分以内にログイン数が 5 倍増加すると予想される場合、この大幅な使用量の急増に備えてキャッシュを準備することができます。
ElastiCache コンソール、CLI、または API を使用して、事前スケーリングを実行できます。ElastiCache サーバーレスは 60 分以内にキャッシュで使用可能な 1 秒あたりの ECPU を更新し、最小制限の更新が完了するとイベント通知を送信します。
**事前スケーリングの仕組み**
1 秒あたりの ECPU またはデータストレージの最小制限がコンソール、CLI、または API を介して更新されると、その新しい制限は 1 時間以内に利用可能になります。ElastiCache サーバーレスは、空のキャッシュで 30K の ECPU/秒、レプリカからの読み取り機能を使用する場合は最大 90K の ECPU/秒 をサポートします。ElastiCache Serverless for Valkey 8.0 では、サポートされる 1 秒あたりのリクエスト数 (RPS) を 2～3 分おきに 2 倍に拡張でき、キャッシュあたりの RPS は 13 分も経たないうちにゼロから 5 万 RPS に達します。p50 の読み取りレイテンシーも一貫してミリ秒未満を維持します。今後のスケーリングイベントがこの速度を超えると予想される場合は、最小 ECPU/秒を、ピークイベントの 60 分以上前に予想されるピーク ECPU/秒に設定することをお勧めします。設定しておかないと、アプリケーションでレイテンシーが増加し、リクエストのスロットリングが発生する可能性があります。
最小制限の更新が完了すると、ElastiCache サーバーレスは新しい最小 ECPU/秒または新しい最小ストレージに基づいて計測を開始します。これは、アプリケーションがキャッシュでリクエストを実行していない場合や、データストレージの使用量が最小値を下回っている場合にも発生します。現在の設定から最小制限を低くすると、更新は即時に適用され、ElastiCache サーバーレスはすぐに新しい最小制限で計測を開始します。
**注記**
最小使用量制限を設定すると、実際の使用量が最小使用量制限を下回っていても、その制限に対して課金されます。ECPU またはデータストレージの使用量が最小使用量制限を超えると、通常の料金が課金されます。例えば、最小使用制限を 100,000 ECPU/秒に設定すると、使用量がその最小設定を下回る場合でも、1 時間あたり 1.224 USD (us-east-1 の ECPU 料金を使用) が課金されます。
ElastiCache サーバーレスは、キャッシュの集約レベルでリクエストされた最小スケールをサポートします。ElastiCache サーバーレスは、スロットあたり最大 30K ECPU/秒 (READONLY 接続を使用してレプリカから読み取る場合は 90K ECPU/秒) もサポートします。ベストプラクティスとして、アプリケーションでは Valkey または Redis OSS スロット間のキー分散と、キー間のトラフィックができるだけ均等になるように設定すべきです。
## コンソールと を使用したスケーリング制限の設定AWS CLI
*AWSコンソールを使用したスケーリング制限の設定*
1. にサインインAWS マネジメントコンソールし、[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 を使用してスケーリング上限を削除するには、Minimum と Maximum の制限パラメータを 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 クラスターが 1 つ以上のリージョン間でレプリケートされている場合、それらのリージョンは順番にスケールされます。スケールアップする場合、セカンダリリージョンが最初にスケーリングされ、次にプライマリリージョンがスケーリングされます。スケールダウンする場合、プライマリリージョンが最初に、次にセカンダリリージョンが続きます。
エンジンバージョンを更新する場合、最初にセカンダリリージョン、次にプライマリリージョンの順序になります。
**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 は、Memcached をAWSクラウドにデプロイ、運用、垂直スケーリングするフルマネージドのインメモリキャッシュサービスを提供します。
**オンデマンドの垂直スケーリング**
垂直スケーリングにより、ElastiCache for Memcached は、データベースの負荷を軽減して動的アプリケーションを高速化するために広く使用されている、高性能の分散メモリキャッシュシステムを提供します。データやオブジェクトは RAM に保存されるため、外部データソースから読み取る必要がなくなります。
垂直スケーリングは、既存のノードベースのクラスターにも新しいクラスターにも適用できます。そのため、リソース割り当てに柔軟性が生まれ、ユーザーはクラスターアーキテクチャを変更せずにワークロードの変化に効率的に適応できるようになります。このスケーリング機能では、需要の高い期間にはキャッシュ容量を増やし、需要の低い期間にはスケールダウンしてコストを最適化するため、パフォーマンスが向上します。その結果、オペレーションが簡素化され、リソース要件の変化に合わせて新しいクラスターを作成する必要がなくなり、トラフィックの変動への迅速な対応が可能になります。全体として、ノードベースの Memcached クラスターの垂直スケーリングは、コスト効率とリソース使用率の向上に役立ちます。また、ユーザーが Memcached インスタンスタイプを変更することもできます。こうしたメリットにより、キャッシュインフラストラクチャを実際のアプリケーションのニーズに合わせやすくなります。
**注記**
ノードタイプの変更は、エンジンバージョンが 1.5 以降のノードベースの Memcached クラスターでのみ行うことができます。
垂直スケーリングを使用するには、自動検出を有効にする必要があります。
## ノードベースの Memcached クラスターのオンデマンド垂直スケーリングを設定する
`scale-config` を使用して、Memcached のオンデマンド垂直スケーリングを設定できます。scale-config には 2 つのパラメータがあります。
1. **ScaleIntervalMinutes:** Memcached アップグレードプロセス中のスケーリングバッチ間の時間 (分単位)
1. **ScalePercentage:** Memcached アップグレードプロセス中に同時にスケールするノードの割合
**CLI を使用して既存の Memcached ノードタイプを垂直スケーリングが可能なキャッシュに変換する**
既存のノードベースの Memcached クラスターを垂直スケーリングが可能なキャッシュに変換するには、CLI で `elasticache modify-cache-cluster` を使用します。
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config \
--apply-immediately
```
**CLI を使用して垂直スケーリングを設定する**
CLI を使用してノードベースの Memcached クラスターの垂直スケーリングを設定するには、`elasticache modify-cache-cluster` を使用し、`scale-config` とそのパラメータである `ScalePercentage` および `ScaleIntervalMinutes` を指定します。
+ **scale-interval-minutes:** スケーリングバッチ間の時間 (分単位) を定義します。この設定の範囲は 2～30 分です。値を指定しない場合、デフォルト値の 5 分が適用されます。
+ **scale-percentage:** 各バッチで同時にスケールするノードの割合を指定します。この設定の範囲は 10～100 です。この設定は除算時に切り上げられるため、例えば結果が 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 マネジメントコンソール**
を使用してノードベースの Memcached クラスターを垂直方向にスケーラブルなクラスターAWS マネジメントコンソールに変換するには、次の手順に従います。
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. 変換する Memcached クラスターを選択します。
1. **[変更]** タブを選択します。
1. **[キャッシュ設定]** セクションに移動し、目的の **[ノードタイプ]** を選択します。
1. **[変更をプレビュー]** を選択し、変更を確認します。
1. [**Modify**] を選択します。
## Memcached の自動水平スケーリング
ElastiCache はAWS Application Auto Scaling (AAS) サービスと統合され、Memcached クラスターの自動水平スケーリングが含まれるようになりました。AWS Application Auto Scaling サービスを使用してスケーリングポリシーを定義し、事前定義されたメトリクスまたはスケジュールに基づいて、必要に応じて Memcached クラスター内のノード数を自動的に調整できます。
**注記**
自動水平スケーリングは現在、北京リージョンと寧夏リージョンでは利用できません。
ノードベースのクラスターの自動水平スケーリングに使用できる方法には次のものがあります。
+ **スケジュールされたスケーリング:** スケジュールに基づくスケーリングでは、予想可能な負荷の変化に対する独自のスケーリングスケジュールを設定できます。たとえば、毎週、ウェブアプリケーションへのトラフィックが水曜日に増え始め、木曜日は高いままで、金曜日に下がり始めるとします。この場合は、水曜日に容量を増やし、金曜日に減らすように自動スケーリングを設定できます。
+ **ターゲット追跡:** ターゲット追跡スケーリングポリシーで、スケーリングメトリクスを選択してターゲット値を設定します。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. **ターゲット追跡スケーリングポリシーを作成する**
次に、PutScalingPolicy 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` コマンドは、指定された将来の日時に 1 回実行されるアクションをスケジュールします。この schedule フィールドは、rate (分、時間、日など) と cron (cron 式の場合) もサポートしています。
指定された日時がくると、Application Auto Scaling が `MinCapacity` および `MaxCapacity` の値を更新します。Application Auto Scaling は MinCapacity までスケールアウトして、キャッシュノード数を 70 に設定します。
**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. **複数のスケーリングポリシー**
複数のスケーリングポリシーを作成できます。[自動スケーリングターゲット追跡](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 マネジメントコンソール**
を使用して既存のノードベースの Memcached クラスターAWS マネジメントコンソールを水平方向にスケーラブルなクラスターに変換するには、次の手順に従います。
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. 変換する Memcached キャッシュを選択します。
1. **[自動スケーリング]** タブに移動します。
1. **[動的なスケーリングを追加]** または **[スケジュールされたスケーリングを追加]** を選択して、適用するスケーリングポリシーを選択します。
1. 必要に応じて、選択したポリシーの詳細を入力します。
1. [**Create (作成)**] をクリックします。
# Memcached クラスターの手動スケーリング
Memcached クラスターの手動による水平スケーリングのアウト/インはクラスターでのノードの追加または削除と同じくらい簡単です。Memcached クラスターは 1～60 個のノードで構成されます。
Memcached クラスターのすべてのノード間でデータを分割できるため、メモリのより大きいノードタイプにスケールアップすることはほとんど必要ありません。ただし、Memcached エンジンではデータが保持されないため、別のノードタイプにスケールすると、アプリケーションがデータを入力しない限り、新しいクラスターは空の状態から開始します。
Memcached クラスターを手動で垂直にスケールするには、新しいクラスターを作成する必要があります。Memcached クラスターは、アプリケーションによって事前設定されない限り、最初は空の状態になります。
**Memcached クラスターの手動スケーリング**
| Action | 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 クラスターで自動検出を使用する場合は、ノードを追加したり削除するたびに、アプリケーションのエンドポイントを変更する必要はありません。自動検出の詳細については、「[クラスター (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 マネジメントコンソールを使用してノードベースの Memcached クラスターを垂直にスケールする方法について説明しています。
1. 新しいノードインスタンスタイプで新しいクラスターを作成します。詳細については、「[Memcached クラスター (CLI) の作成 (コンソール)](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. 古いクラスターを削除します。詳細については、「[を使用して ElastiCache クラスターAWS CLIを削除する](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 つのノードを使用します。マルチノードクラスターには、0～5 の読み取り専用レプリカノードのある読み取り/書き込みプライマリノードとして常に 1 個のノードがあります。
**Topics**
+ [Valkey または Redis OSS (クラスターモードが無効) クラスターのスケーリング](#Scaling.RedisStandalone)
**Valkey または Redis OSS クラスターのスケーリング**
| Action | 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/ja_jp/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/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 コンソール、、AWS CLIまたは ElastiCache API を使用するかどうかにかかわらず、ElastiCache は次のプロセスを実行します。
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/ja_jp/AmazonElastiCache/latest/dg/scaling-redis-classic.html)
保留中のオペレーションによってブロックされている場合は、以下のいずれかを行うことができます。
+ **[すぐに適用]** チェックボックスをオフにして (CLI では `--no-apply-immediately`、API では `ApplyImmediately=false` を使用)、次のメンテナンス期間に Valkey または Redis OSS スケールアップオペレーションをスケジュールします。
+ Valkey または Redis OSS のスケールアップオペレーションを実行する次のメンテナンス期間 (またはその後) まで待ちます。
+ **[すぐに適用]** チェックボックスをオンにして (CLI では `--apply-immediately`、API では `ApplyImmediately=true` を使用)、このクラスターの変更に Valkey または Redis OSS エンジンのアップグレードを追加します。これにより、エンジンのアップグレードがすぐに実行されて、スケールアップオペレーションのブロックが解除されます。
ElastiCache コンソール、、または ElastiCache API を使用して、単一ノードの Valkey AWS CLIまたは ElastiCacheクラスターをスケールアップできます。
**重要**
パラメータグループが `reserved-memory` を使用して Valkey または Redis OSS のオーバーヘッド用のメモリを確保する場合、スケーリングを開始する前に、新しいノードタイプ用に適切な容量のメモリを確保するカスタムパラメータグループがあることを確認してください。または、`reserved-memory-percent` を使用するようにカスタムパラメータグループを変更し、新しいクラスターに対して、パラメータグループを使用することができます。
`reserved-memory-percent` を使用している場合、これを行う必要はありません。
詳細については、「[Valkey および Redis OSS の予約済みメモリを管理する](redis-memory-management.md)」を参照してください。
#### 単一ノードの Valkey または Redis OSS (クラスターモードが無効) クラスターのスケールアップ (コンソール)
以下の手順では、ElastiCache マネジメントコンソールを使用して、単一ノード Valkey または Redis OSS クラスターをスケールアップする方法について説明しています。このプロセス中、Valkey または Redis OSS クラスターは最小限のダウンタイムでリクエストを処理し続けます。
**単一ノード Valkey または Redis OSS クラスター をスケールアップするには (コンソール)**
1. にサインインAWS マネジメントコンソールし、[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. **[Modify]** (変更) を選択します。
1. [**Modify Cluster**] ウィザードで:
1. **Node type** リストから、スケーリングするノードタイプを選択します。
1. `reserved-memory` を使用してメモリを管理している場合、[**Parameter Group**] リストから新しいノードタイプのために適切な容量のメモリを確保するカスタムパラメータグループを選択します。
1. スケールアッププロセスをすぐに実行する場合は、[**Apply immediately**] ボックスを選択します。[**Apply immediately**] ボックスを選択していない場合、スケールアッププロセスはこのクラスターの次のメンテナンス期間中に実行されます。
1. **[Modify]** (変更) を選択します。
前の手順で **[すぐに適用]** を選択した場合、クラスターのステータスは *[変更中]* に変わります。ステータスが 使用可能** に変わると、変更は完了し、新しいクラスターの使用を開始できます。
#### 単一ノード 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. を使用した場合は`--apply-immediately`、次のパラメータを指定して コマンドを使用してAWS CLI`describe-cache-clusters`、新しいクラスターのステータスを確認します。ステータスが *available* に変わると、新しい、より大きいクラスターの使用を開始できます。
+ `--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` アクションを使用することで、新しいクラスターのステータスを確認します。ステータスが *available* に変わると、新しい、より大きいクラスターの使用を開始できます。
+ `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 スナップショットを作成するのに十分なメモリがあることを確認する](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 マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. クラスターのリストから、スケールダウンするクラスターを選択します。このクラスターは、クラスター化された Valkey または Redis OSS エンジンではなく、Valkey または Redis OSS エンジンを実行している必要があります。
1. **[Modify]** (変更) を選択します。
1. [**Modify Cluster**] ウィザードで:
1. [**ノードのタイプ**] リストから、スケールダウンするノードタイプを選択します。
1. `reserved-memory` を使用してメモリを管理している場合、[**Parameter Group**] リストから新しいノードタイプのために適切な容量のメモリを確保するカスタムパラメータグループを選択します。
1. スケールダウンプロセスをすぐに実行する場合は、[**すぐに適用**] チェックボックスをオンにします。[**すぐに適用**] チェックボックスを選択しないままにすると、スケールダウンプロセスはこのクラスターの次のメンテナンスウィンドウ中に実行されます。
1. **[Modify]** (変更) を選択します。
1. クラスターのステータスが [*modifying*] から [*available*] に変わると、クラスターは新しいノードタイプにスケーリングされます。アプリケーションでエンドポイントを更新する必要はありません。
#### 単一ノード 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. を使用した場合は`--apply-immediately`、次のパラメータを指定して コマンドを使用してAWS CLI`describe-cache-clusters`、新しいクラスターのステータスを確認します。ステータスが *available* に変わると、新しい、より大きいクラスターの使用を開始できます。
+ `--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` アクションを使用することで、新しいクラスターのステータスを確認します。ステータスが *available* に変わると、新しい、より小さいクラスターの使用を開始できます。
+ `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 (クラスターモードが無効) のレプリカノードのスケーリング
レプリカノード (API/CLI では*レプリケーショングループ*) を含む Valkey または Redis OSS クラスターは、マルチ AZ と自動フェイルオーバーが有効になっているレプリケーションを通じて、高可用性を実現します。レプリカノードを含むクラスターは、最大 6 つの Valkey または Redis OSS ノードの論理的な集合であり、1 つのノード (プライマリ) は読み取りと書き込みの両方のリクエストに対応できます。クラスター内の他のすべてのノードは、プライマリの読み取り専用レプリカです。プライマリに書き込まれたデータはクラスターのすべてのリードレプリカに非同期でレプリケートされます。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 では、コンソール、CLI、API を使用した Valkey または Redis OSS (クラスターモードが無効) レプリケーショングループのスケールアップがサポートされています。
スケールアッププロセスが開始されると、ElastiCache によって以下の処理が実行されます。
1. 新しいノードタイプを使用して、レプリケーショングループを起動します。
1. 現行プライマリノードのすべてのデータを新しいプライマリノードにコピーします。
1. 新しいリードレプリカを新しいプライマリノードと同期させます。
1. 新しいノードを参照するように DNS エントリを更新します。このため、アプリケーションのエンドポイントを更新する必要はありません。Valkey 7.2 以降、Redis OSS 5.0.5 以降では、クラスターがオンラインのままで受信リクエストを処理している間に、自動フェイルオーバーが有効なクラスターをスケールできます。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/ja_jp/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)
保留中のオペレーションによってブロックされている場合は、以下のいずれかを行うことができます。
+ **[すぐに適用]** チェックボックスをオフにして (CLI では `--no-apply-immediately`、API では `ApplyImmediately=false` を使用)、次のメンテナンス期間に Valkey または Redis OSS スケールアップオペレーションをスケジュールします。
+ Valkey または Redis OSS のスケールアップオペレーションを実行する次のメンテナンス期間 (またはその後) まで待ちます。
+ **[すぐに適用]** チェックボックスをオンにして (CLI では `--apply-immediately`、API では `ApplyImmediately=true` を使用)、このクラスターの変更に Valkey または Redis OSS エンジンのアップグレードを追加します。これにより、エンジンのアップグレードがすぐに実行されて、スケールアップオペレーションのブロックが解除されます。
以下のセクションでは、ElastiCache コンソール、、および ElastiCache ElastiCache API を使用して、レプリカを使用して Valkey AWS CLIまたは 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 マネジメントコンソールし、[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. **[Modify]** (変更) を選択します。
1. [**Modify Cluster**] ウィザードで:
1. **Node type** リストから、スケーリングするノードタイプを選択します。すべてのノードタイプがスケールダウンできるわけではないことに注意してください。
1. `reserved-memory` を使用してメモリを管理している場合、[**Parameter Group**] リストから新しいノードタイプのために適切な容量のメモリを確保するカスタムパラメータグループを選択します。
1. スケールアッププロセスをすぐに実行する場合は、[**Apply immediately**] チェックボックスをオンにします。[**Apply immediately**] チェックボックスをオフのままにすると、スケールアッププロセスは、このクラスターの次のメンテナンス期間中に実行されます。
1. **[Modify]** (変更) を選択します。
1. クラスターのステータスが [*modifying*] から [*available*] に変わると、クラスターは新しいノードタイプにスケーリングされます。アプリケーションでエンドポイントを更新する必要はありません。
### Valkey または Redis OSS レプリケーショングループのスケールアップ (AWS CLI)
次のプロセスでは、AWS CLIを使用して、レプリケーショングループを現在のノードタイプから新しいより大きいノードタイプにスケールします。このプロセスでは、ElastiCache は新しいノードを参照するように DNS エントリを更新します。このため、アプリケーションのエンドポイントを更新する必要はありません。Valkey 7.2 以降、Redis OSS 5.0.5 以降では、クラスターがオンラインのままで受信リクエストを処理している間に、自動フェイルオーバーが有効なクラスターをスケールできます。バージョン 4.0.10 以前では、DNS エントリが更新されている間、以前のバージョンのプライマリノードからの読み取りと書き込みが短時間中断することがあります。
より大きいノードタイプへのスケールアップにかかる時間はノードタイプと現在のクラスターのデータ量によって異なります。
**Valkey または Redis OSS レプリケーショングループをスケールアップするには (AWS CLI)**
1. 次のパラメータを指定して `list-allowed-node-type-modifications` コマンドを実行してAWS CLI、スケールアップできるノードタイプを決定します。
+ `--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 以降では、クラスターがオンラインのままで受信リクエストを処理している間に、自動フェイルオーバーが有効なクラスターをスケールできます。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` アクションを使用することで、レプリケーショングループのステータスをモニタリングします。ステータスが [*modifying*] から [*available*] に変わると、スケールアップした新しいレプリケーショングループへの書き込みを開始できます。
+ `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 マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. クラスターのリストから、スケールダウンするクラスターを選択します。このクラスターは、クラスター化された Valkey または Redis OSS エンジンではなく、Valkey または Redis OSS エンジンを実行している必要があります。
1. **[Modify]** (変更) を選択します。
1. [**Modify Cluster**] ウィザードで:
1. [**ノードのタイプ**] リストから、スケールダウンするノードタイプを選択します。
1. `reserved-memory` を使用してメモリを管理している場合、[**Parameter Group**] リストから新しいノードタイプのために適切な容量のメモリを確保するカスタムパラメータグループを選択します。
1. スケールダウンプロセスをすぐに実行する場合は、[**すぐに適用**] チェックボックスをオンにします。[**すぐに適用**] チェックボックスを選択しないままにすると、スケールダウンプロセスはこのクラスターの次のメンテナンスウィンドウ中に実行されます。
1. **[Modify]** (変更) を選択します。
1. クラスターのステータスが [*modifying*] から [*available*] に変わると、クラスターは新しいノードタイプにスケーリングされます。アプリケーションでエンドポイントを更新する必要はありません。
### Valkey または Redis OSS レプリケーショングループのスケールダウン (AWS CLI)
次のプロセスでは、AWS CLIを使用して、レプリケーショングループを現在のノードタイプから新しいより小さいノードタイプにスケールします。このプロセスでは、ElastiCache は新しいノードを参照するように DNS エントリを更新します。このため、アプリケーションのエンドポイントを更新する必要はありません。Valkey 7.2 以降、Redis OSS 5.0.5 以降では、クラスターがオンラインのままで受信リクエストを処理している間に、自動フェイルオーバーが有効なクラスターをスケールできます。バージョン 4.0.10 以前では、DNS エントリが更新されている間、以前のバージョンのプライマリノードからの読み取りと書き込みが短時間中断することがあります。
ただし、リードレプリカクラスターからの読み取りは中断されません。
より小さいノードタイプへのスケールダウンにかかる時間はノードタイプと現在のクラスターのデータ量によって異なります。
**Valkey または Redis OSS レプリケーショングループをスケールダウンするには (AWS CLI)**
1. 次のパラメータを指定して `list-allowed-node-type-modifications` コマンドを実行してAWS CLI、スケールダウンできるノードタイプを決定します。
+ `--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レプリケーショングループのステータスをモニタリングします。ステータスが *modifying* から *available* に変わると、スケールダウンした新しいレプリケーショングループへの書き込みを開始できます。
+ `--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 以降では、クラスターがオンラインのままで受信リクエストを処理している間に、自動フェイルオーバーが有効なクラスターをスケールできます。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` アクションを使用することで、レプリケーショングループのステータスをモニタリングします。ステータスが *modifying* から *available* に変わると、スケールダウンした新しいレプリケーショングループへの書き込みを開始できます。
+ `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 レプリケーショングループにリードレプリカ (最大 5 個) を追加します。
Valkey または Redis OSS クラスターの読み取り容量は、ElastiCache コンソール、、AWS CLIまたは ElastiCache API を使用してスケールできます。詳細については、「[Valkey または Redis OSS (クラスターモードが無効) のリードレプリカを追加する](Replication.AddReadReplica.md)」を参照してください。
## 読み込みキャパシティーの削減
読み込みキャパシティーを減らすには、レプリカを含む Valkey または Redis OSS クラスター (API/CLI では*レプリケーショングループ*) から 1 つ以上のリードレプリカを削除します。クラスターで自動フェイルオーバーを備えたマルチ 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 (クラスターモードが有効) クラスターをスケールするには、水平スケーリングと垂直スケーリングの 2 つの方法があります。
+ 水平スケーリングでは、ノードグループ (シャード) を追加または削除することで、レプリケーショングループ内のノードグループ (シャード) の数を変更できます。オンラインのリシャーディングプロセスでは、クラスターが着信リクエストの処理を継続しながら、スケールイン/スケールアウトが可能です。
新しいクラスターで、古いクラスターと異なるスロットを設定します。オフラインメソッドに限られます。
+ 垂直スケーリング - ノードタイプを変更することで、クラスターのサイズを変更します。オンラインの垂直スケーリングでは、クラスターが着信リクエストの処理を継続しながら、スケールアップ/ダウンが可能です。
スケールインまたはスケールダウンによってクラスターのサイズとメモリ容量を減らす場合は、新しい構成にデータと 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 (クラスターモードが有効) クラスター (レプリケーショングループ) に追加することで、読み込みおよび書き込みキャパシティーを増やすことができます。
レプリケーショングループに 1 つ以上のシャードを追加する場合、それぞれの新しいノードのノード数は既存の最小のシャードのシャード数と同じです。
+ **スケールイン** – Valkey または Redis OSS (クラスターモードが有効) クラスターからシャードを削除することで、読み込みおよび書き込みキャパシティーを減らして、コストを削減します。
+ **再分散** – Valkey または Redis OSS (クラスターモードが有効) クラスター内のシャード間でキースペースを移動させ、シャード間でできるだけ均等に分散されるようにします。
次のことはできません。
+ **シャードを個別に構成:**
シャードのキースペースを個別に指定することはできません。これを行うには、オフライン処理を使用する必要があります。
現在、ElastiCache のオンラインリシャーディングおよび再分散には、次の制限が適用されます。
+ このプロセスには Valkey 7.2 以降または Redis OSS 3.2.10 以降が必要です。エンジンバージョンのアップグレードについての詳細は、「[ElastiCache のバージョン管理](VersionManagement.md)」を参照してください。
+ スロットまたはキースペース、および大きなアイテムには制限があります。
シャード内のキーのいずれかに大きなアイテムが含まれる場合、そのキーはスケールアウトまたは再分散の際に移行されません。この機能により、アンバランスなシャードになる可能性があります。
シャード内のキーのいずれかに大きなアイテム (シリアル化後 256 MB より大きいアイテム) が含まれる場合、シャードはスケールイン時に削除されません。この機能により、一部のシャードは削除されない可能性があります。
+ スケールアウトの際、新しいシャードのノード数はいずれも、既存の最小のシャードのノード数と等しくなります。
+ スケールアウトの際、既存のすべてのシャードに共通するタグは、すべて新しいシャードにコピーされます。
+ グローバルデータストアクラスターをスケールアウトする場合、ElastiCache は既存のノードの 1 つから新しいノードに関数を自動的に複製しません。すべてのシャードが同じ関数を持つように、クラスターをスケールアウトした後に、新しいシャードに関数を読み込むことをお勧めします。
**注記**
ElastiCache for Valkey 7.2 以降、ElastiCache for Redis OSS バージョン 7 以降の場合: クラスターをスケールアウトすると、ElastiCache は (ランダムに選択された) 既存のノードのいずれかにロードされた関数を新しいノードに自動的にレプリケートします。アプリケーションで[関数](https://valkey.io/topics/functions-intro/)を使用している場合は、スケールアウトする前に、クラスターがシャードによって異なる関数定義にならないように、すべての関数をすべてのシャードに読み込むことをお勧めします。
詳細については、「[オンラインクラスターのサイズ変更](best-practices-online-resharding.md)」を参照してください。
AWS マネジメントコンソール、AWS CLI、および ElastiCache API を使用して、Valkey または Redis OSS (クラスターモードが有効) クラスターを水平スケーリングまたは再分散できます。
### オンラインリシャーディングによるシャードの追加
、、または ElastiCache API を使用してAWS マネジメントコンソールAWS CLI、Valkey または Redis OSS (クラスターモードが有効) クラスターにシャードを追加できます。Valkey または Redis OSS (クラスターモードが有効) クラスターにシャードを追加すると、既存のシャードのすべてのタグが新しいシャードにコピーされます。
**Topics**
#### シャードの追加 (コンソール)
を使用してAWS マネジメントコンソール、1 つ以上のシャードを Valkey または Redis OSS (クラスターモードが有効) クラスターに追加できます。以下の手順では、このプロセスについて説明します。
**シャードを Valkey または Redis OSS (クラスターモードが有効) クラスターに追加するには**
1. ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey クラスター]** または **[Redis OSS クラスター]** を選択します。
1. シャードを追加する Valkey または Redis OSS (クラスターモードが有効) クラスターの名前 (クラスター名の左にあるボックスではなく) を見つけて選択します。
**ヒント**
Valkey または Redis OSS (クラスターモードが有効) では、**[モード]** 列に **[クラスター化された Valkey]** または **[クラスター化された Redis OSS]** が表示されます。
1. [**Add shard**] を選択します。
1. [**追加するシャード数**] で、このクラスターに追加するシャード数を選択します。
1. [**アベイラビリティーゾーン**] で、[**No preference**] または [**Specify availability zones**] を選択します。
1. [**Specify availability zones**] を選択した場合は、各シャードのそれぞれのノードごとに、アベイラビリティゾーンのリストからノードのアベイラビリティーゾーンを選択します。
1. **[Add]** (追加) を選択します。
#### シャードの追加 (AWS CLI)
以下のプロセスでは、AWS CLIを使用してシャードを追加し、Valkey または Redis OSS (クラスターモードが有効) クラスターでシャードを再構成する方法について説明します。
`modify-replication-group-shard-configuration` を使って以下のパラメータを使用します。
**パラメータ**
+ `--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）
`ModifyReplicationGroupShardConfiguration` オペレーションを使うことで、ElastiCache API を使用して Valkey または Redis OSS (クラスターモードが有効) クラスターのシャードをオンラインで再構成できます。
`ModifyReplicationGroupShardConfiguration` を使って以下のパラメータを使用します。
**パラメータ**
+ `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)」を参照してください。
### オンラインリシャーディングによるシャードの削除
、、または ElastiCache API を使用してAWS マネジメントコンソールAWS CLI、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 マネジメントコンソールを使用してシャードを削除し、Valkey または Redis OSS (クラスターモードが有効) クラスターでシャードを再構成する方法について説明します。
レプリケーショングループからノードグループ (シャード) を削除する前に、ElastiCache はすべてのデータが残りのシャードに収まるようにします。データが収まる場合、指定したシャードはリクエストに応じてレプリケーショングループから削除されます。データが残りのノードグループに収まらない場合、プロセスは終了し、レプリケーショングループはリクエスト前と同じノードグループ設定のままになります。
を使用してAWS マネジメントコンソール、Valkey または Redis OSS (クラスターモードが有効) クラスターから 1 つ以上のシャードを削除できます。レプリケーショングループのすべてのシャードを削除することはできません。代わりに、レプリケーショングループを削除する必要があります。詳細については、「[レプリケーショングループの削除](Replication.DeletingRepGroup.md)」を参照してください。次の手順では、1 つ以上のシャードを削除する手順を説明します。
**Valkey または Redis OSS (クラスターモードが有効) クラスターからシャードを削除するには**
1. ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/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 (クラスターモードが有効) クラスターから 1 つ以上のシャードを削除できます。レプリケーショングループのすべてのシャードを削除することはできません。代わりに、レプリケーショングループを削除する必要があります。詳細については、「[レプリケーショングループの削除](Replication.DeletingRepGroup.md)」を参照してください。
`modify-replication-group-shard-configuration` を使って以下のパラメータを使用します。
**パラメータ**
+ `--apply-immediately` – 必須。シャードの再構成オペレーションがすぐに開始するよう指定します。
+ `--replication-group-id` – 必須。シャードの再構成オペレーションをどのレプリケーショングループ (クラスター) で実行するかを指定します。
+ `--node-group-count` – 必須。オペレーションの完了時に存在するシャード (ノードグループ) 数を指定します。シャードを削除する場合、`--node-group-count` の値は現在のシャード数より小さくなければなりません。
+ `--node-groups-to-remove` – `--node-group-count` が現在のノードグループ (シャード) 数より少ない場合は必須です。レプリケーショングループから削除するシャード (ノードグループ) ID の一覧。
次の手順では、1 つ以上のシャードを削除する手順を説明します。
**Example - シャードの削除**
次の例では、Valkey または Redis OSS (クラスターモードが有効) クラスター `my-cluster` から 2 つのノードグループを削除します。オペレーション完了時に合計 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）
`ModifyReplicationGroupShardConfiguration` オペレーションを使うことで、ElastiCache API を使用して Valkey または Redis OSS (クラスターモードが有効) クラスターのシャードをオンラインで再構成できます。
以下のプロセスでは、ElastiCache API を使用してシャードを削除し、Valkey または Redis OSS (クラスターモードが有効) クラスターでシャードを再構成する方法について説明します。
**重要**
レプリケーショングループからノードグループ (シャード) を削除する前に、ElastiCache はすべてのデータが残りのシャードに収まるようにします。データが収まる場合、指定されたシャード (`NodeGroupsToRemove`) はリクエストに応じてレプリケーショングループから削除され、キースペースは残りのシャードにマッピングされます。データが残りのノードグループに収まらない場合、プロセスは終了し、レプリケーショングループはリクエスト前と同じノードグループ設定のままになります。
ElastiCache API を使用して、Valkey または Redis OSS (クラスターモードが有効) クラスターから 1 つ以上のシャードを削除できます。レプリケーショングループのすべてのシャードを削除することはできません。代わりに、レプリケーショングループを削除する必要があります。詳細については、「[レプリケーショングループの削除](Replication.DeletingRepGroup.md)」を参照してください。
`ModifyReplicationGroupShardConfiguration` を使って以下のパラメータを使用します。
**パラメータ**
+ `ApplyImmediately=true` – 必須。シャードの再構成オペレーションがすぐに開始するよう指定します。
+ `ReplicationGroupId` – 必須。シャードの再構成オペレーションをどのレプリケーショングループ (クラスター) で実行するかを指定します。
+ `NodeGroupCount` – 必須。オペレーションの完了時に存在するシャード (ノードグループ) 数を指定します。シャードを削除する場合、`NodeGroupCount` の値は現在のシャード数より小さくなければなりません。
+ `NodeGroupsToRemove` – `--node-group-count` が現在のノードグループ (シャード) 数より少ない場合は必須です。レプリケーショングループから削除するシャード (ノードグループ) ID の一覧。
次の手順では、1 つ以上のシャードを削除する手順を説明します。
**Example - シャードの削除**
次の例では、Valkey または Redis OSS (クラスターモードが有効) クラスター `my-cluster` から 2 つのノードグループを削除します。オペレーション完了時に合計 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=
```
### オンラインのシャード再分散
、、または ElastiCache API を使用してAWS マネジメントコンソールAWS CLI、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 マネジメントコンソールを使用してシャードを再分散し、Valkey または Redis OSS (クラスターモードが有効) クラスターでシャードを再構成する方法について説明します。
**Valkey または Redis OSS (クラスターモードが有効) クラスターでシャード間のキースペースを再分散するには**
1. ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey クラスター]** または **[Redis OSS クラスター]** を選択します。
1. 再分散する Valkey または Redis OSS (クラスターモードが有効) クラスターの名前 (名前の左にあるボックスではなく) を選択します。
**ヒント**
Valkey または Redis OSS (クラスターモードが有効) クラスターは、**[シャード]** 列で 1 以上の値を持ちます。
1. [**再分散**] を選択します。
1. プロンプトが表示されたら、[**再分散**] を選択します。次のようなメッセージが表示されることがあります。*レプリケーショングループのスロットは均一に分散されています。Nothing to do。(サービス: AmazonElastiCache; ステータスコード: 400; エラーコード: InvalidReplicationGroupState; リクエスト ID: 2246cebd-9721-11e7-8d5b-e1b0f086c8cf)*。この場合、[**キャンセル**] を選択します。
#### オンラインのシャード再分散 (AWS CLI)
`modify-replication-group-shard-configuration` を使って以下のパラメータを使用します。
**パラメータ**
+ `-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）
`ModifyReplicationGroupShardConfiguration` オペレーションを使うことで、ElastiCache API を使用して Valkey または Redis OSS (クラスターモードが有効) クラスターのシャードをオンラインで再構成できます。
`ModifyReplicationGroupShardConfiguration` を使って以下のパラメータを使用します。
**パラメータ**
+ `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 (Elastic Network Interface) 容量があることを確認します。スケールダウンの場合は、ノードを小さくすることで予想されるトラフィックを吸収するのに十分なメモリがあることを確認します。
メモリ管理のベストプラクティスについては、「[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 マネジメントコンソールを使用して、Valkey または Redis OSS クラスターをスケールアップする方法について説明しています。このプロセス中、クラスターは最小限のダウンタイムでリクエストを処理し続けます。
**Valkey または Redis OSS クラスターをスケールアップするには (コンソール)**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで **[Valkey クラスター]** または **[Redis OSS クラスター]** を選択します。
1. クラスターのリストから、クラスターを選択します。
1. **[Modify]** (変更) を選択します。
1. [**Modify Cluster**] ウィザードで:
1. **Node type** リストから、スケーリングするノードタイプを選択します。スケールアップするには、既存のノードよりも大きいノードタイプを選択します。
1. スケールアッププロセスをすぐに実行する場合は、[**すぐに適用**] ボックスを選択します。[**Apply immediately**] ボックスを選択していない場合、スケールアッププロセスはこのクラスターの次のメンテナンス期間中に実行されます。
1. **[Modify]** (変更) を選択します。
前の手順で **[すぐに適用]** を選択した場合、クラスターのステータスは *[変更中]* に変わります。ステータスが 使用可能** に変わると、変更は完了し、新しいクラスターの使用を開始できます。
### 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. を使用した場合は`--apply-immediately`、次のパラメータを指定して コマンドを使用してAWS CLI`describe-cache-clusters`クラスターのステータスを確認します。ステータスが *available* に変わると、新しい、より大きいクラスターノードの使用を開始できます。
### Valkey または Redis OSS クラスターのスケールアップ (ElastiCache API)
以下のプロセスでは、ElastiCache API を使用して、クラスターを現在のノードタイプから新しい、より大きいノードタイプにスケールします。このプロセスでは、ElastiCache は新しいノードを参照するように DNS エントリを更新します。このため、アプリケーションのエンドポイントを更新する必要はありません。Valkey 7.2 以降、Redis OSS 5.0.5 以降では、クラスターがオンラインのままで受信リクエストを処理している間に、自動フェイルオーバーが有効なクラスターをスケールできます。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` アクションを使用することで、レプリケーショングループのステータスをモニタリングします。ステータスが [*modifying*] から [*available*] に変わると、スケールアップした新しいレプリケーショングループへの書き込みを開始できます。
+ `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 マネジメントコンソールを使用して、Valkey または Redis OSS クラスターをスケールダウンする方法について説明しています。このプロセス中、Valkey または Redis OSS クラスターは最小限のダウンタイムでリクエストを処理し続けます。
**Valkey または Redis OSS クラスターをスケールダウンするには (コンソール)**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. ナビゲーションペインで **[Valkey クラスター]** または **[Redis OSS クラスター]** を選択します。
1. クラスターのリストから、希望するクラスターを選択します。
1. **[Modify]** (変更) を選択します。
1. [**Modify Cluster**] ウィザードで:
1. **Node type** リストから、スケーリングするノードタイプを選択します。スケールダウンするには、既存のノードより小さいノードタイプを選択します。すべてのノードタイプがスケールダウンできるわけではないことに注意してください。
1. スケールダウンプロセスをすぐに実行する場合は、[**すぐに適用**] ボックスを選択します。[**すぐに適用**] ボックスを選択していない場合、スケールダウンプロセスはこのクラスターの次のメンテナンスウィンドウ中に実行されます。
1. **[Modify]** (変更) を選択します。
前の手順で **[すぐに適用]** を選択した場合、クラスターのステータスは *[変更中]* に変わります。ステータスが 使用可能** に変わると、変更は完了し、新しいクラスターの使用を開始できます。
### 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. を使用した場合は`--apply-immediately`、次のパラメータを指定して コマンドを使用してAWS CLI`describe-cache-clusters`クラスターのステータスを確認します。ステータスが *available* に変わると、新しい、より小さいクラスターノードの使用を開始できます。
### 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 データタイプおよび関連するコマンドが自動的に使用可能になります。`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 以降を実行している必要があります。
Bloom データ型は、Valkey ベースではない他の Bloom サービスとは RDB 互換性がありません。
## Bloom フィルターのデータ型の概要
Bloom フィルターは、要素を追加したり、要素が存在するかどうかを確認したりできる、スペース効率の高い確率的データ構造です。要素が追加されなかったにもかかわらず、フィルターによって要素が存在すると誤って示される偽陽性が発生する可能性があります。ただし、ブルームフィルターは、偽陰性 (要素が追加されたにもかかわらず、要素が存在しないという誤った表示) が発生しないことを保証します。
Bloom フィルターに関するドキュメントの主なソースは、valkey.io のドキュメントページにあります。これには、次の情報が含まれます。
+ [Bloom フィルターの一般的なユースケース](https://valkey.io/topics/bloomfilters/#common-use-cases-for-bloom-filters)
+ 広告/イベントの重複排除
+ 不正検出
+ 有害なコンテンツ/スパムのフィルタリング
+ 一意のユーザーの検出
+ [スケーリングと非スケーリングの Bloom フィルター](https://valkey.io/topics/bloomfilters/#scaling-and-non-scaling-bloom-filters)
+ スケーリングと非スケーリングの 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 フィルターオブジェクトによるメモリ消費量は 128 MB に制限されます。`BF.INFO SIZE` コマンドを使用すると、Bloom フィルターによって消費されるメモリの量を確認できます。
## Bloom ACL
Bloom コマンドとデータへのアクセスを簡単に管理するために、既存のデータ型ごとのカテゴリ (@string、@hash など) と同様の新しいカテゴリ @bloom が追加されました。他の既存の Valkey および Redis OSS のコマンドは @bloom カテゴリのメンバーではありません。
新しい Bloom コマンドを含めるように更新された既存の ACL カテゴリは、@read、@write、および @fast の 3 つあります。以下の表は、適切なカテゴリへの 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 メトリクス | Unit | サーバーレス/ノードベース | 説明 |
| --- | --- | --- | --- |
| BloomFilterBasedCmds | カウント | [Both] (両方) | 読み取りコマンドと書き込みコマンドの両方を含む 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 フィルターに 1 つの項目を追加します。フィルターがまだ存在しない場合は、作成されます。 |
| [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 フィルターに 1 つ以上の項目を追加します。 |
| [BF.MEXISTS](https://valkey.io/commands/bf.mexists/) | Bloom フィルターに 1 つ以上の項目が含まれているかどうかを決定します。 |
| [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`は 1 つのハッシュスロットにスコープされます。つまり、同じハッシュスロットにマッピングされたキーのみが、同じ接続によって同時に監視でき、監視コマンドに従うトランザクションは、同じハッシュスロットでのみ動作できます。アプリケーションが別のハッシュスロットからのキーを監視しようとしたり、監視対象のキーとは異なるハッシュスロットにマッピングされたキーで動作するトランザクションコマンドを実行しようとすると、`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
```
## 監視制限
クライアント接続ごとに最大 1000 個のキーを同時に監視できます。
## 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 のベクトル検索は、すべての [AWSリージョン](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)のノードベースのクラスター上の Valkey バージョン 8.2 で追加料金なしで利用できます。開始するには、[AWS マネジメントコンソール](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 は、数十億の高次元ベクトル埋め込みのインデックス作成、検索、更新を行う機能を提供します。ベクトル検索を使用すると、セカンダリインデックスを作成、保守、使用して、効率的でスケーラブルな検索を行うことができます。各ベクトル検索オペレーションは、1 つのインデックスに適用されます。インデックスオペレーションは、指定されたインデックスにのみ適用されます。インデックスの作成オペレーションと削除オペレーションを除き、任意のインデックスに対して任意の数のオペレーションをいつでも発行できます。クラスターレベルでは、複数のインデックスに対する複数のオペレーションが同時に進行している可能性があります。
このドキュメント内では、キー、行、レコードという用語は同一のものであり、相互互換的に使用されます。同様に、列、フィールド、パス、メンバーという用語も相互互換的に使用されます。
`FT.CREATE` コマンドを使用すると、指定したインデックスタイプのキーのサブセットに対してインデックスを作成できます。`FT.SEARCH` は、作成されたインデックスに対してクエリを実行し、`FT.DROPINDEX` は既存のインデックスと関連するすべてのデータを削除します。インデックス付きデータを追加、削除、変更するための特別なコマンドはありません。インデックス内のキーを変更する既存の `HASH` または `JSON` コマンドは、インデックスを自動的に更新します。
**Topics**
+ [インデックスと Valkey OSS キースペース](#indexes-keyspace)
+ [インデックスフィールドの型](#index-field-types)
+ [ベクトルインデックスアルゴリズム](#vector-index-algorithms)
+ [ベクトル検索のセキュリティ](#vector-search-security)
## インデックスと Valkey OSS キースペース
インデックスは、Valkey OSS キースペースのサブセット上で構築および維持されます。各インデックスのキースペースは、インデックスの作成時に提供されるキープレフィックスのリストによって定義されます。プレフィックスのリストはオプションであり、省略した場合、キースペース全体がそのインデックスの一部になります。複数のインデックスは、制限なく、キースペースの素のサブセットまたは重複するサブセットを選択できます。
また、インデックスは、型が一致するキーのみをカバーするという点で型指定されます。現在、インデックスは `JSON` 型と `HASH` 型でのみサポートされています。`HASH` インデックスは、プレフィックスリストによってカバーされる `HASH` キーのインデックスのみを作成します。同様に、`JSON` インデックスは、プレフィックスリストによってカバーされる `JSON` キーのインデックスのみを作成します。インデックスのキースペースプレフィックスリスト内のキーのうち、指定されたタイプを持たないキーは無視され、検索オペレーションに影響を及ぼしません。
コマンドがインデックスのキースペース内にあるキーを変更すると、そのインデックスが更新されます。Valkey は、各インデックスの宣言されたフィールドを自動的に抽出し、インデックスを新しい値で更新します。更新プロセスには 3 つのステップがあります。最初のステップでは、HASH または JSON キーが変更され、リクエスト元のクライアントがブロックされます。2 番目のステップはバックグラウンドで実行され、変更されたキーを含む各インデックスをそれぞれ更新します。3 番目のステップでは、クライアントはブロック解除されます。したがって、ミューテーションと同じ接続で実行されるクエリオペレーションの場合、その変更はすぐに検索結果に表示されます。
インデックスの作成は複数のステップからなるプロセスです。最初のステップは、インデックスを定義する FT.CREATE コマンドを実行することです。作成が正常に実行されると、2 番目のステップであるバックフィルが自動的に開始されます。バックフィルプロセスはバックグラウンドスレッドで実行され、キースペースをスキャンして、新しいインデックスのプレフィックスリスト内にあるキーを探します。見つかった各キーはインデックスに追加されます。最終的にはキースペース全体がスキャンされて、インデックス作成プロセスが完了します。バックフィルプロセスの実行中は、インデックス付きキーのミューテーションが許可され、制限はなく、すべてのキーのインデックスが適切に作成されるまではインデックスバックフィルプロセスが完了しないことに留意してください。インデックスのバックフィル中に試行されるクエリオペレーションは許可されず、エラーで終了します。FT.INFO コマンドは、バックフィルプロセスのステータスを 'backfill\$1status' フィールドに入れて返します。
## インデックスフィールドの型
各インデックスには、インデックスの作成時に宣言される特定の型と、インデックスが作成されるフィールド (列) の場所が含まれます。`HASH` キーの場合、その場所は `HASH` 内のフィールド名です。`JSON` キーの場合、その場所は パスの説明です。キーが変更されると、宣言されたフィールドに関連付けられたデータが抽出され、宣言された型に変換されてインデックスに格納されます。データが欠落している場合、または宣言された型に正常に変換できない場合、そのフィールドはインデックスから省略されます。次で説明するように、フィールドには 3 つのタイプがあります。
+ **ベクトルフィールド**には、ベクトル埋め込みとも呼ばれる数値のベクトルが含まれます。ベクトルフィールドを使用すると、類似度を測定する指定された距離メトリクスに基づいてベクトルをフィルタリングできます。`HASH` インデックスの場合、フィールドにはバイナリ形式 (リトルエンディアンIEEE 754) でエンコードされたベクトル全体が含まれている必要があります。`JSON` キーの場合、パスは数字が入力されている正しいサイズの配列を参照する必要があります。なお、JSON 配列をベクトルフィールドとして使用すると、JSON キー内の配列の内部表現が、選択したアルゴリズムに必要な形式に変換され、メモリ消費量と精度が削減されます。JSON コマンドを使用した後続の読み取りオペレーションでは、精度の値が小さくなります。
+ **数値フィールド**には 1 つの数値が含まれます。数値フィールドは範囲検索演算子とともに使用できます。`HASH` の場合、フィールドには、固定小数点数または浮動小数点数の標準形式で記述された数値の ASCII テキストが含まれることが想定されます。`JSON` フィールドの場合、JSON 数値の数値規則に従う必要があります。キー内の表現にかかわらず、このフィールドはインデックス内に格納するために 64 ビットの浮動小数点数に変換されます。基になる数値は精度制限のある浮動小数点で格納されるため、浮動小数点数の数値比較に関する通常のルールが適用されます。
+ **タグフィールド**には、単一の UTF-8 文字列としてコード化された 0 個以上のタグ値が含まれます。タグフィールドを使用すると、大文字と小文字を区別する比較または大文字と小文字を区別しない比較で、タグ値の同等性についてクエリをフィルタリングできます。文字列は、先頭と末尾の空白が削除された区切り文字 (デフォルトはカンマだが、上書きが可能) を使用してタグ値に解析されます。単一のタグフィールドには、任意の数のタグ値を含めることができます。
## ベクトルインデックスアルゴリズム
Valkey では、2 つのベクトルインデックスアルゴリズムがサポートされています。
+ **Flat** – Flat アルゴリズムは、インデックス内の各ベクトルの総当たり線形処理であり、距離計算の精度の範囲内で正確な答えを生成します。インデックスの線形処理のため、インデックスが大きい場合、このアルゴリズムの実行時間が非常に長くなる可能性があります。フラットインデックスは、より高速の取り込みをサポートします。
+ **Hierarchical Navigable Small Worlds (HNSW)** – HNSW アルゴリズムは、実行時間を大幅に短縮する代わりに、最も近いベクトル一致の近似値を提供する代替手段です。このアルゴリズムは、`M`、`EF_CONSTRUCTION`、`EF_RUNTIME` の 3 つのパラメータによって制御されます。最初の 2 つのパラメータはインデックスの作成時に指定され、変更できません。`EF_RUNTIME` パラメータにはインデックスの作成時に指定されるデフォルト値が含まれていますが、その後の個々のクエリオペレーションで上書きできます。これらの 3 つのパラメータは相互に影響し合って、取り込みおよびクエリオペレーション中のメモリと CPU 消費のバランスを取るだけでなく、正確な KNN 検索の近似値の質 (再現率と呼ばれます) を制御します。
HNSW では、パラメータ M は各ノードが接続できるネイバーの最大数を制御し、インデックス密度を形成します。M の値を大きくすると (32 以上など)、より接続されたグラフが生成され、関連するネイバーに到達するためのパスが増えるため、再現率とクエリ速度が向上します。ただし、インデックスサイズとメモリ使用量が増加し、インデックス作成が遅くなります。M の値を小さくすると (8 以下など)、インデックスが小さくなり、インデックス作成が高速化し、メモリ使用量も減少しますが、接続数が減少することで再現率が低下し、クエリに時間がかかるようになる場合があります。
パラメータ EF\$1construction は、インデックスの作成時に評価される接続の候補の数を示します。EF\$1construction の値を大きくすると (400 以上など)、インデクサがネイバーを選択する前に検討するパスが増えるため、後の再現率とクエリ効率がいずれも向上するグラフになりますが、それと引き換えにインデックス作成が遅くなり、構築中の CPU とメモリの使用量が増加します。EF\$1construction の値を小さくすると (64～120 など)、インデックス作成が高速化し、リソースの使用量が減少しますが、EF\$1runtime を大きな値に設定したとしても、結果のグラフの再現率が低下し、クエリが遅くなる可能性があります。
最後に、EF\$1runtime はクエリ中の検索の幅を管理し、実行時に探索されるネイバーの候補の数を制御します。これを大きな値に設定すると、再現率と精度は向上しますが、クエリのレイテンシーと CPU の使用量が犠牲になります。EF\$1runtime の値が小さければ、クエリは高速かつ軽量になりますが、再現率は低下します。M や EF\$1construction とは異なり、このパラメータはインデックスのサイズや作成時間には影響せず、インデックスの作成後に再現率とレイテンシーのトレードオフを調整するパラメータになります。
両方のベクトル検索アルゴリズム (Flat および HNSW) は、オプションの `INITIAL_CAP` パラメータをサポートしています。このパラメータを指定すると、インデックス用にメモリが事前に割り当てられるため、メモリ管理のオーバーヘッドが削減され、ベクトルの取り込み速度が向上します。フラットインデックスは、HNSW よりも優れた取り込み速度をサポートします。
HNSW などのベクトル検索アルゴリズムは、以前に挿入されたベクトルの削除または上書きを効率的に処理できない場合があります。これらのオペレーションを使用すると、インデックスメモリが過剰に消費されたり、再現の質が低下したりする可能性があります。インデックスの再作成は、最適なメモリ使用量および/または再現を復元するための 1 つの方法です。
## ベクトル検索のセキュリティ
コマンドアクセスとデータアクセスの両方のための [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)を参照してください。
## パラメトリック制限
次の表は、プレビューにおけるさまざまなベクトル検索項目の制限を示しています。
**ベクトル検索の制限**
| Item | 最大値 |
| --- | --- |
| ベクトルの次元の数 | 32768 |
| 作成できるインデックスの数 | 10 |
| インデックス内のフィールドの数 | 50 |
| FT.SEARCH TIMEOUT 句 (ミリ秒) | 60000 |
| インデックスごとに許可されるプレフィックスの最大数 | 16 |
| タグフィールドの最大長 | 10000 |
| 数値フィールドの最大長 | 256 |
| HNSW M パラメータ | 2000000 |
| HNSW EF\$1CONSTRUCTION パラメータ | 4096 |
| HNSW EF\$1RUNTIME パラメータ | 4096 |
## オペレーションの制限
### インデックスの永続化とバックフィル
更新プロセスには 3 つのステップがあります。最初のステップでは、HASH または JSON キーが変更され、リクエスト元のクライアントがブロックされます。2 番目のステップはバックグラウンドで実行され、変更されたキーを含む各インデックスをそれぞれ更新します。3 番目のステップでは、クライアントはブロック解除されます。したがって、ミューテーションと同じ接続で実行されるクエリオペレーションの場合、その変更はすぐに検索結果に表示されます。ただし、キーの挿入または更新は、短期間ではありますが、他のクライアントの検索結果に表示されない場合があります。システム負荷および/またはデータのミューテーションが多い期間中は、表示できるようになるまでの遅延が長くなる可能性があります。
ベクトル検索機能は、インデックスの定義とインデックスの内容を保持します。ベクトルフィールドのインデックスは保存されますが、TAGS および NUMERIC のインデックスは保存されません。つまり、外部でロードされるとき (完全同期または再ロード) に、インデックスを再構築する必要があります。つまり、ノードの起動または再起動を引き起こすオペレーションリクエストまたはイベント中に、ベクトルのインデックス定義と内容が最新のスナップショットから復元されます。これを開始するには、ユーザーアクションは必要ありません。ただし、TAGS および NUMERIC のインデックスの場合、再構築はデータが復元されるとすぐにバックフィルオペレーションとして実行されます。これは、定義されたインデックスごとに FT.CREATE コマンドを自動的に実行するシステムと機能的に同等です。データが復元されるとノードはアプリケーションのオペレーションにすぐに利用可能になりますが、インデックスのバックフィルが完了する前である可能性が高いため、アプリケーションが再びバックフィルオペレーションを認識できるようになることにご注意ください。
インデックスバックフィルの完了は、プライマリとレプリカの間で同期されません。この同期の欠如は予期せずアプリケーションにとって認識可能になる可能性があるため、検索オペレーションを開始する前に、アプリケーションでプライマリとすべてのレプリカでバックフィルが完了したことを検証することをお勧めします。
### [Scaling limits]（スケーリング履歴）
スケーリングイベント中、データが移行されるとインデックスのバックフィルが行われる場合があります。これは、検索クエリの再現率の低下につながります。
### スナップショットのインポート/エクスポートとライブ移行
検索インデックスを持つ 1 つのクラスターの 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` のデータ構造内にベクトルを保存するために必要な実際の容量と、最も近いメモリスラブへのオーバーヘッドを測定して計算されます。各ベクトルインデックスは、これらのデータ構造に保存されているベクトルデータへの参照と、インデックス内のベクトルの追加コピーを使用します。インデックスによるこの追加のスペースの消費量を計画することをお勧めします。
ベクトルの数は、データをベクトルとして表す方法によって異なります。例えば、1 つのドキュメントを複数のチャンクに表現することを選択できます。各チャンクはベクトルを表します。または、ドキュメント全体を単一のベクトルとして表現することもできます。ベクトルのディメンションの数は、選択した埋め込みモデルによって異なります。たとえば、AWS Titan 埋め込みモデルを使用する場合、ディメンションの数は 1536 になります。インスタンスタイプをテストして要件に適合していることを確認する必要があることに注意してください。
## ワークロードのスケーリング
ベクトル検索は、水平、垂直、レプリカの 3 つのスケーリング方法をすべてサポートしています。容量をスケーリングする場合、ベクトル検索は通常の 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` 句は必須です。
**[Syntax]** (構文)
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
| VECTOR [HNSW|FLAT] [ ])
| TAG [SEPARATOR ] [CASESENSITIVE]
| NUMERIC
)+
```
** (必須):** インデックスに付ける名前です。同じ名前のインデックスが既に存在する場合、エラーが返されます。
**ON HASH \$1 JSON (オプション):** 指定されたタイプに一致するキーのみがこのインデックスに含まれます。省略すると、HASH が想定されます。
**PREFIX (オプション):** この句を指定すると、指定されたプレフィックスの 1 つ以上と同じバイトで始まるキーのみがこのインデックスに含まれます。この句を省略すると、正しいタイプのすべてのキーが含まれます。長さが 0 のプレフィックスは、正しいタイプのすべてのキーとも一致します。
**フィールドタイプ:**
+ TAG: タグフィールドは、1 つ以上のタグ値を含む文字列です。
+ SEPARATOR (オプション): 個々のタグを区切るために使用される文字 (`,.<>{}[]"':;!@#$%^&*()-+=~`) の 1 つ。省略した場合、デフォルトは「`,`」です。
+ CASESENSITIVE (オプション): 存在する場合、タグの比較では大文字と小文字が区別されます。デフォルトでは、タグの比較では大文字と小文字は区別されません。
+ NUMERIC: 数値フィールドには数値が含まれます。
+ VECTOR: ベクトルフィールドにはベクトルが含まれます。現在、HNSW (Hierarchical Navigable Small World) と FLAT (ブルートフォース) という 2 つのベクトルインデックス作成アルゴリズムがサポートされています。それぞれのアルゴリズムには追加の属性のセットがあり、その中には必須の属性とオプションの属性があります。
+ 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 です。最大値は 4096 です。
+ 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 オプションが設定されている場合を除き、すべてのフィールドが返されます。NOCONTENT オプションが設定されている場合は、フィールドは返されません。count を 0 に設定すると、NOCONTENT と同じように動作します。
+ LIMIT: : 結果の一部を選択できます。最初の キーはスキップされ、最大 個のキーのみが含まれます。デフォルトは LIMIT 0 10 で、最大 10 個のキーを返します。
+ PARAMS: key-value ペアの数の 2 倍。Param の key/value ペアはクエリ式内から参照できます。詳細については、「[ベクトル検索クエリ式](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression)」を参照してください。
+ DIALECT: (オプション): 方言を指定します。サポートされている方言は 2 のみです。
**応答**
このコマンドでは、成功した場合は配列が返され、失敗した場合はエラーが返されます。
成功すると、応答配列の最初のエントリは一致するキーの数を表し、一致するキーごとに 1 つの配列エントリがその後に続きます。`LIMIT` オプションが指定されている場合は、返されるキーの数のみが制御され、最初のエントリの値には影響しないことに注意してください。
`NOCONTENT` が指定されている場合は、応答内の各エントリには一致するキー名のみが含まれます。それ以外の場合、各エントリには一致するキー名が含まれ、返されたフィールドの配列がその後に続きます。キーの結果フィールドは、名前と値のペアのセットで構成されます。最初の名前と値のペアは、計算された距離用です。このペアの名前は、ベクトルフィールド名の先頭に「\$1\$1」が付き、末尾に「\$1score」が付く形で構成され、値は計算された距離になります。残りの名前と値のペアは、`RETURN` 句によって制御されるキーのメンバーと値です。
クエリ文字列は次の構文に準拠しています。
```
=>[ KNN @ $ ]
```
コードの説明は以下のとおりです。
+ : \$1 またはフィルター式です。\$1 はフィルタリングが行われないことを示し、インデックス内のすべてのベクトルが検索されます。フィルター式を提供して、検索対象のベクトルのサブセットを指定できます。
+ : 指定されたインデックス内のベクトルフィールドの名前。
+ : 返される最も近い近傍ベクトルの数。
+ : KNN アルゴリズムのクエリベクトルを提供する対応する値を持つ PARAM 名。このパラメータは、リトルエンディアン形式の 32 ビット IEEE 754 バイナリ浮動小数点としてエンコードする必要があることに注意してください。
+ : (オプション) この特定の KNN 検索を変更するキーワードと値のペアのリスト。現在、次の 2 つのキーワードがサポートされています。
+ このキーワードには、インデックス作成時に指定された EF\$1RUNTIME のデフォルト値を上書きする整数値が付随します。
+ AS: このキーワードには、結果のスコアフィールドの名前となる文字列値が付随しており、デフォルトのスコアフィールド名生成アルゴリズムが上書きされます。
**フィルター式**
フィルター式は、括弧内に含まれるタグと数値の検索演算子の論理的な組み合わせとして構成されます。
**タグ**:
タグ検索演算子は、\$1 文字で区切られた 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]
```
**論理演算子**
複数のタグ検索演算子と数値検索演算子を使用して、論理演算子で複雑なクエリを構築できます。
**論理 AND**
論理 AND を設定するには、述語の間にスペースを入れます。例えば、次のようになります。
`query1 query2 query3`
**論理 OR**
論理 OR を設定するには、述語の間にスペースを入れます。例えば、次のようになります。
`query1 | query2 | query3`
**論理否定**
クエリは、各クエリの前に `-` 文字を付加することで否定できます。負のクエリは、クエリと一致しないエントリをすべて返します。これには、フィールドを持たないキーも含まれます。
例えば、@genre:\$1comedy\$1 に関する負のクエリは、コメディではないすべての書籍と、ジャンルフィールドを持たないすべての書籍を返します。
次のクエリは、2015 年から 2024 年の間に出版されていない、または年フィールドがない「コメディ」ジャンルのすべての書籍を返します: @genre:[comedy] -@year:[2015 2024]
**演算子の優先順位**
一般的な演算子の優先順位ルールが適用されます。つまり、論理 NEGATE が最も優先順位が高く、次に論理 AND、そして論理 OR が最も優先順位が低くなります。括弧を使用して、デフォルトの優先順位ルールを上書きできます。
*論理演算子の組み合わせの例*
論理演算子を組み合わせて複雑なフィルター式を形成することができます。
次のクエリは、2015 年から 2024 年の間に出版された「コメディ」または「ホラー」ジャンル (AND) のすべての書籍を返します: `@genre:[comedy|horror] @year:[2015 2024]`
次のクエリは、2015 年から 2024 年の間に出版された「コメディ」または「ホラー」ジャンル (OR) のすべての書籍を返します: `@genre:[comedy|horror] | @year:[2015 2024]`
次のクエリは、2015 年から 2024 年の間に出版された、ジャンルフィールドがないか、ジャンルフィールドが「コメディ」ではないすべての書籍を返します: `-@genre:[comedy] @year:[2015 2024]`
# FT.DROPINDEX
**[Syntax]** (構文)
```
FT.DROPINDEX
```
指定されたインデックスが削除されます。OK、またはそのインデックスが存在しない場合はエラーを返します。
+ (必須): 削除するインデックスの名前。
# FT.INFO
**[Syntax]** (構文)
```
FT.INFO
```
ベクトル検索は、[FT.INFO](https://valkey.io/commands/info/) コマンドに統計とカウンターの追加セクションをいくつか追加します。セクション SEARCH の取得をリクエストすると、次のセクションがすべて取得されます。
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| index\$1name | string | インデックスの名前 |
| index\$1options | string | リザーブド。現在は「0」に設定されています |
| index\$1definition | array | これらの配列要素の定義については、以下を参照してください。 |
| 属性 | 属性情報の配列 | この配列には定義された属性ごとに 1 つの要素があります。属性情報の定義については以下を参照してください。 |
| num\$1docs | integer | 現在インデックスに含まれているキーの数 |
| num\$1terms | integer | リザーブド。現在は「0」に設定されています。 |
| record\$1count | integer | 各属性の「サイズ」フィールドの合計。 |
| hash\$1indexing\$1failures | integer | 属性を、宣言された属性タイプに変換できなかった回数。名前にかかわらず、これは JSON キーにも適用されます。 |
| backfill\$1in\$1progress | integer | バックフィルが現在進行中の場合は「1」、それ以外の場合は「0」になります。 |
| backfill\$1percent\$1complete | float | バックフィル完了の推定。[0..1] の範囲に収まる少数になります |
| mutation\$1queue\$1size | integer | インデックス更新を待機しているキーの数。 |
| recent\$1mutations\$1queue\$1delay | integer | インデックス更新の遅延 (秒単位) の推定。更新が進行中の場合は 0。 |
| state | string | バックフィルの状態:「ready」は、バックフィルが正常に完了したことを示します。「backfill\$1in\$1progress」は、バックフィルが進行中であることを示します。「backfill\$1paused\$1by\$1oom」は、メモリ不足のためバックフィルが一時停止されていることを意味します。メモリ不足が解消されると、バックフィルは続行されます。 |
index\$1definition 構造は、次のように定義されたキーと値のペアの配列です。
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| key\$1type | string | 文字列「JSON」または文字列「HASH」のいずれか |
| prefixes | array | 配列内の各要素は、インデックスに定義されたプレフィックスです。インデックスの作成時にプレフィックスが指定されていなかった場合、この配列のエントリは 0 になります。 |
| default\$1score | string | リザーブド。現在は「1」に設定されています |
属性情報: 属性情報はタイプ固有です。
数値属性:
| Key | 値のタイプ | 説明 |
| --- | --- | --- |
| 識別子 | string | キー内の属性の場所。ハッシュメンバー名または JSON パス |
| alias | string | クエリの説明で使用される属性の名前。 |
| 型 | string | 文字列「NUMERIC」 |
| サイズ | integer | この属性で有効な数値を持つキーの数。 |
タグの属性:
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| 識別子 | string | キー内の属性の場所。ハッシュメンバー名または JSON パス |
| alias | string | クエリの説明で使用される属性の名前。 |
| 型 | string | 文字列「TAG」 |
| SEPARATOR | 文字 | インデックスの作成時に定義された区切り文字 |
| CASESENSITIVE | 該当なし | このキーには、関連付けられている値はありません。このオプションで属性が作成された場合にのみ存在します。 |
| サイズ | integer | この属性内で有効なタグ値を持つキーの数 |
ベクトル属性:
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| 識別子 | string | キー内の属性の場所。ハッシュメンバー名または JSON パス |
| alias | string | クエリの説明で使用される属性の名前。 |
| 型 | string | 文字列「VECTOR」 |
| index | 文字 | ベクトルインデックスの詳細については、以下を参照してください。 |
ベクトルインデックスの説明:
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| 容量 | string | インデックスの現在の容量 |
| ディメンション | string | 各ベクトルの要素の数 |
| distance\$1metric | string | 「COSINE」、「L2」、または「IP」のいずれか |
| サイズ | array | ベクトルインデックスの説明については、以下を参照してください。 |
| data\$1type | string | 宣言されたデータ型。現在サポートされているのは「FLOAT32」のみです。 |
| アルゴリズム | array | ベクトル検索アルゴリズムの詳細な説明。 |
FLAT ベクトル検索アルゴリズムの説明:
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| 名前 | string | アルゴリズム名: FLAT |
| block\$1size | 数値 | FLAT インデックスのブロックのサイズ。 |
HNSW ベクトルインデックスの説明:
| キー名 | 値の型 | 説明 |
| --- | --- | --- |
| 名前 | string | アルゴリズム名: HNSW |
| m | 数値 | HNSW の「M」パラメータ |
| ef\$1construction | 数値 | HNSW の「ef\$1construction」パラメータ |
| ef\$1runtime | 数値 | HNSW の「ef\$1runtime」パラメータ。 |
# FT.\$1LIST
すべてのインデックスを一覧表示します。
**[Syntax]** (構文)
```
FT._LIST
```
現在定義されているインデックスの名前である文字列の配列を返します。
# Valkey および Redis OSS で JSON の使用を開始する
ElastiCache は、JavaScript Object Notation (JSON) 形式をサポートしています。これは、Valkey および Redis OSS クラスター内の複雑なデータセットをエンコードするシンプルでスキーマレスな方法です。クラスター内で JavaScript Object Notation (JSON) 形式を使用してデータをネイティブに保存およびアクセスし、それらのクラスターに保存されている JSON データを更新できます。シリアル化および逆シリアル化のためにカスタムコードを管理する必要はありません。
JSON 上で動作するアプリケーションに対して Valkey および Redis OSS API オペレーションを使用できるほか、オブジェクト全体を操作しなくても、JSON ドキュメントの特定の部分を効率的に取得および更新できるようになりました。これにより、パフォーマンスを向上させ、コストを削減できます。また、[Goessner-style](https://goessner.net/articles/JsonPath/) `JSONPath` クエリを使用して、JSON ドキュメントの内容を検索することもできます。
サポートされているエンジンバージョンでクラスターを作成すると、JSON データタイプおよび関連するコマンドが自動的に使用可能になります。JSON モジュールのバージョン 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 データ型の概要と、サポートされているコマンドの詳細なリストを示します。
## 用語
****
| 言葉 | 説明 |
| --- | --- |
| 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 [Unicode](https://www.unicode.org/standard/WhatIsUnicode.html) がサポートされています。
## ルート要素
ルート要素は任意の JSON データ型にすることができます。以前の RFC 4627 では、オブジェクトまたは配列のみがルート値として許可されていたことに注意してください。RFC 7159 への更新以降、JSON ドキュメントのルートは任意の JSON データ型にすることができます。
## ドキュメントサイズの制限
JSON ドキュメントは、迅速なアクセスおよび変更のために最適化された形式で内部的に格納されます。通常、この形式では、同じドキュメントのシリアル化された同等の表現よりもいくらか多くのメモリを消費することになります。
単一の JSON ドキュメントによるメモリ消費量は 64 MB に制限されています。これは JSON 文字列ではなく、インメモリデータ構造のサイズです。`JSON.DEBUG MEMORY` コマンドを使用すれば、JSON ドキュメントが消費するメモリの量を確認できます。
## JSON ACLs
+ JSON コマンドおよびデータへのアクセスを簡単に管理するために、既存のデータ型ごとのカテゴリ (@string、@hash など) と同様の新しいカテゴリ @json が追加されました。他の既存の Valkey または Redis OSS コマンドは @json カテゴリのメンバーではありません。すべての JSON コマンドは、キースペースまたはコマンドの制限と権限を強制します。
+ 次の 5 つの既存の Valkey および Redis OSS ACL カテゴリが、新しい JSON コマンドを含むように更新されています: @read、@write、@fast、@slow、@admin。以下の表は、適切なカテゴリへの 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]
+ 追加のオプション引数は省略記号 (「…」) で示されます。例: [json ...]
## パス構文
Redis JSON では、次の 2 種類のパス構文をサポートしています。
+ **拡張構文** – 以下の表に示すように、[Goessner](https://goessner.net/articles/JsonPath/) で説明されている JSONPath 構文に従います。わかりやすくするために、表の説明を並べ替え、一部変更しています。
+ **制限構文** — クエリ機能が制限されます。
**注記**
一部のコマンドの結果は、使用されるパス構文のタイプの影響を受けます。
クエリパスが「\$1」で始まる場合は、拡張構文が使用されます。その他の場合は、制限構文が使用されます。
**拡張構文**
****
| 記号/式 | 説明 |
| --- | --- |
| \$1 | ルート要素。 |
| . または [] | 子演算子。 |
| .. | 再帰下降。 |
| \$1 | ワイルドカード。オブジェクトまたは配列のすべての要素。 |
| [] | 配列の添字演算子。インデックスは 0 ベースです。 |
| [,] | union 演算子。 |
| [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] | 最初の 2 冊の本です。 |
| \$1..book[0,1] | 最初の 2 冊の本です。 |
| \$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]"
```
**制限構文**
****
| 記号/式 | 説明 |
| --- | --- |
| . または | 子演算子。 |
| [] | 配列の添字演算子。インデックスは 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/)が適用されます。
## 一般的なエラープレフィックス
各エラーメッセージにはプレフィックスが付いています。以下は、一般的なエラープレフィックスのリストです。。
****
| プレフィックス | 説明 |
| --- | --- |
| ERR | 一般的なエラーです。 |
| 制限 | サイズ制限を超えたときに発生するエラーです。例えば、ドキュメントのサイズ制限やネストの深度制限を超えた場合などです。 |
| NONEXISTENT | キーまたはパスが存在しません。 |
| OUTOFBOUNDARIES | 配列インデックスが範囲外です。 |
| SYNTAXERR | 構文エラーです。 |
| WRONGTYPE | 値のタイプが間違っています。 |
## JSON 関連メトリクス
以下の JSON 情報メトリクスが提供されます。
****
| Info | 説明 |
| --- | --- |
| json\$1total\$1memory\$1bytes | JSON オブジェクトに割り当てられたメモリの合計です。 |
| json\$1num\$1documents | Valkey または Redis OSS 内のドキュメントの総数です。 |
コアメトリクスをクエリするには、以下のコマンドを実行します。
```
info json_core_metrics
```
## ElastiCache for Valkey および ElastiCache for Redis OSS と JSON との連携方法
以下のセクションでは、ElastiCache for Valkey および ElastiCache for Redis OSS と JSON データ型との連携方法について説明します。
### 演算子の優先順位
フィルタリングの条件式を評価するときは、ほとんどの言語と同様に、&& が最も優先され、次に \$1\$1 が評価されます。括弧内の操作が最初に実行されます。
### 最大パスネスト制限の動作
ElastiCache for Redis OSS の最大パスネスト制限は 128 です。したがって、`$.a.b.c.d...` のような値は 128 レベルまでしか到達できません。
### 数値の処理
JSON では、整数と浮動小数点数で異なるデータ型を使用しません。それらはすべて数値と呼ばれます。
数値表現:
入力で JSON 数値を受け取ると、次の 2 つの内部バイナリ表現のいずれかに変換されます: 64 ビット符号付き整数、または 64 ビット IEEE 倍精度浮動小数点数。元の文字列、およびそのすべての書式は保持されません。そのため、数値が JSON 応答の一部として出力されるときに、内部のバイナリ表現が、一般的な書式ルールが使用された印刷可能文字列に変換されます。これらのルールにより、受信した文字列とは異なる文字列が生成される場合があります。
算術コマンド `NUMINCRBY` および `NUMMULTBY`:
+ 両方の数値が整数で、結果が `int64` の範囲外である場合は、自動的に 64 ビット IEEE 倍精度浮動小数点数になります。
+ 数字の少なくとも 1 つが浮動小数点の場合、結果は 64 ビット IEEE 倍精度浮動小数点数になります。
+ 結果が 64 ビット IEEE 倍精度の範囲を超える場合は、`OVERFLOW` エラーが返されます。
利用可能なコマンドの詳細なリストについては、「[サポートされている Valkey および Redis OSS のコマンドJSON コマンド](json-list-commands.md)」を参照してください。
### 直接配列フィルタリング
ElastiCache for Valkey または ElastiCache for 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 または ElastiCache for Redis OSS では、配列で正と負の両方のインデックスを使用できます。長さ 5 の配列の場合、0 で最初の要素を照会し、1 で 2 番目の要素を照会する、という順序になります。負の数は配列の最後から始まるので、-1 は 5 番目の要素を照会し、-2 は 4 番目の要素を照会し、以下同様に続きます。
お客様の予測可能な動作を保証するために、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
パスの配列値に 1 つ以上の値を追加します。
構文
```
JSON.ARRAPPEND [json ...]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - 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 値を検索します。
+ 範囲外のエラーは、インデックスを配列の開始と終了に丸めることによって処理されます。
+ start > end の場合は、-1 (見つからない) を返します。
構文
```
JSON.ARRINDEX [start [end]]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - JSON パス。
+ json-scalar (必須) – 検索するスカラー値。JSON スカラーは、オブジェクトでも配列でもない値を指します。すなわち、文字列、数値、ブール、null がスカラー値です。
+ start (オプション) – 開始インデックス (この値を含みます)｡ 指定しない場合、デフォルトで 0 になります。
+ end (オプション) – 終了インデックス (この値を含みません)。指定しない場合、デフォルトで 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
そのインデックスの前のパスの配列値に 1 つ以上の値を挿入します。
構文
```
JSON.ARRINSERT [json ...]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - JSON パス。
+ index (必須) – 値が挿入される前の配列インデックス。
+ json (必須) - 配列に追加される JSON 値。
**戻る**
パスが拡張構文の場合:
+ 各パスの配列の新しい長さを表す整数の配列。
+ 値が空の配列の場合、対応する戻り値は null です。
+ 値が配列でない場合、対応する戻り値は null です。
+ index 引数が範囲外である場合は、`OUTOFBOUNDARIES` エラーになります。
パスが制限構文の場合:
+ 整数、配列の新しい長さ。
+ パスの値が配列でない場合は、`WRONGTYPE` エラーになります。
+ index 引数が範囲外である場合は、`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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 各パスの配列の長さを表す整数の配列。
+ 値が配列でない場合、対応する戻り値は 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]]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
+ index (オプション) — ポップを開始する配列内の位置。
+ 指定しない場合、デフォルトで -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
部分配列 [start, end] となるようにパスの配列をトリムします (どちらもこの値を含みます)。
+ 配列が空の場合は、何もしないで 0 を返します。
+ start < 0 の場合は、0 として扱います。
+ end >= サイズ (配列のサイズ) の場合は、サイズ-1 として扱います。
+ start >= サイズまたは start > end の場合は、配列を空にして 0 を返します。
構文
```
JSON.ARRTRIM
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - JSON パス。
+ start (必須) — 開始インデックス (この値を含みます)｡
+ end (必須) — 終了インデックス (この値を含みます)｡
**戻る**
パスが拡張構文の場合:
+ 各パスの配列の新しい長さを表す整数の配列。
+ 値が空の配列の場合、対応する戻り値は null です。
+ 値が配列でない場合、対応する戻り値は null です。
+ index 引数が範囲外である場合は、`OUTOFBOUNDARIES` エラーになります。
パスが制限構文の場合:
+ 整数、配列の新しい長さ。
+ 配列が空の場合は null になります。
+ パスの値が配列でない場合は、`WRONGTYPE` エラーになります。
+ index 引数が範囲外である場合は、`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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
+ 整数、クリアされたコンテナの数。
+ 空の配列またはオブジェクトをクリアすると、1 つのコンテナがクリアされます。
+ コンテナ以外の値をクリアすると 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 値のバイト数でレポートします。パスが指定されていない場合、デフォルトはルートになります。
+ FIELDS [path] – 指定されたドキュメントパスのフィールド数をレポートします。パスが指定されていない場合、デフォルトはルートになります。コンテナ以外の JSON 値はそれぞれ 1 つのフィールドとしてカウントされます。オブジェクトと配列は、それらを含む JSON 値ごとに 1 つのフィールドを再帰的にカウントします。ルートコンテナを除く各コンテナ値は、1 つの追加フィールドとしてカウントされます。
+ 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 値を削除します。パスがルートの場合、Valkey または Redis OSS からキーを削除することと同じです。
構文
```
JSON.DEL [path]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
+ 削除された要素の数。
+ 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
1 つ以上のパスにあるシリアル化された JSON を返します。
構文
```
JSON.GET
[INDENT indentation-string]
[NEWLINE newline-string]
[SPACE space-string]
[NOESCAPE]
[path ...]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ INDENT/NEWLINE/SPACE (オプション) – 返される JSON 文字列の形式、すなわち「整形出力」を制御します。それぞれのデフォルト値は空の文字列です。任意の組み合わせでオーバーライドすることが可能です。これらは任意の順序で指定できます。
+ NOESCAPE - オプション。レガシーの互換性のために存在しており、他の効果はありません。
+ path (オプション) – ゼロ以上の JSON パス。何も指定されていない場合は、デフォルトでルートになります。パス引数は末尾に置く必要があります。
**戻る**
拡張パス構文:
パスが 1 つ指定されている場合:
+ 値の配列のシリアル化された文字列を返します。
+ 値が選択されなかった場合は、空の配列を返します。
複数のパスが指定されている場合:
+ 各パスがキーである、文字列化された 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 ...]
```
+ key (必須) - ドキュメントタイプの 1 つ以上の Valkey または Redis OSS キー。
+ path (必須) - 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 値に置き換えられます。
**戻る**
+ 単純な文字列の応答: オペレーションが成功した場合は「OK」。
+ 単純なエラー応答: オペレーションが失敗した場合。
**例**
拡張パス構文:
```
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
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - JSON パス。
+ number (必須) — 数値。
**戻る**
パスが拡張構文の場合:
+ 各パスの結果値を表す一括文字列の配列。
+ 値が数値でない場合、対応する戻り値は 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
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - JSON パス。
+ number (必須) — 数値。
**戻る**
パスが拡張構文の場合:
+ 各パスの結果値を表す一括文字列の配列。
+ 値が数値でない場合、対応する戻り値は 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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 各パスのオブジェクトの長さを表す整数の配列。
+ 値がオブジェクトでない場合、対応する戻り値は 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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 一括文字列の配列の配列。各要素は、一致するオブジェクト内のキーの配列です。
+ 値がオブジェクトでない場合、対応する戻り値は空の値です。
+ ドキュメントキーが存在しない場合は、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 の Serialization Protocol (RESP) で指定されたパスの JSON 値を返します。値がコンテナの場合、応答は RESP 配列またはネストされた配列になります。
+ JSON null は、RESP Null 一括文字列にマップされます。
+ JSON ブール値は、それぞれの RESP 単純文字列にマッピングされます。
+ 整数は RESP 整数にマップされます。
+ 64 ビット IEEE 倍精度浮動小数点数は、RESP 一括文字列にマッピングされます。
+ JSON 文字列は、RESP 一括文字列にマッピングされます。
+ JSON 配列は RESP 配列として表されます。最初の要素は単純な文字列 [ で、その後に配列の要素が続きます。
+ JSON オブジェクトは RESP 配列として表されます。最初の要素は単純な文字列 \$1 で、その後にキーと値のペアが続きます。それぞれが RESP 一括文字列です。
構文
```
JSON.RESP [path]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 配列の配列。各配列要素は、1 つのパスにおける値の 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 個持つことができます。
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (必須) - JSON パス。新しいキーの場合、JSON パスはルート「.」でなければなりません。
+ NX (オプション) — パスがルートである場合は、キーが存在しない場合にのみ値を設定します。つまり、新しいドキュメントを挿入します。パスがルートでない場合は、パスが存在しない場合にのみ値を設定します。つまり、ドキュメントに値を挿入します。
+ XX (オプション) — パスがルートである場合は、キーが存在する場合にのみ値を設定します。つまり、既存のドキュメントを置き換えます。パスがルートでない場合は、パスが存在する場合にのみ値を設定します。つまり、既存の値を更新します。
**戻る**
+ 成功した場合は、シンプルな文字列「OK」が返されます。
+ 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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
+ json\$1string (必須) — 文字列の JSON 表現。JSON 文字列は引用符で囲む必要があることに注意してください。例: 「"string example"」。
**戻る**
パスが拡張構文の場合:
+ 各パスの文字列の新しい長さを表す整数の配列。
+ パスの値が文字列でない場合、対応する戻り値は 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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 各パスの文字列値の長さを表す整数の配列。
+ 値が文字列でない場合、対応する戻り値は 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
パスのブール値を true と false の間で切り替えます。
構文
```
JSON.TOGGLE [path]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 各パスの結果のブール値を表す整数 (0 - false、1 - true) の配列。
+ 値がブール値でない場合、対応する戻り値は null です。
+ ドキュメントキーが存在しない場合は、`NONEXISTENT` エラーになります。
パスが制限構文の場合:
+ 結果のブール値を表す文字列 (「true」/「false」)。
+ ドキュメントキーが存在しない場合は、`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]
```
+ key (必須) - JSON ドキュメントタイプの Valkey または Redis OSS キー。
+ path (オプション) – JSON パス。指定しない場合、デフォルトでルートになります。
**戻る**
パスが拡張構文の場合:
+ 各パスの値の型を表す文字列の配列。型は、\$1「null」、「boolean」、「string」、「number」、「integer」、「object」、および「array」\$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 マネジメントコンソール、、AWS CLIおよび ElastiCache API を使用して操作できます。
IAM を使用している場合は、AWSアカウントのどのユーザーにタグを作成、編集、または削除するためのアクセス許可があるかを制御できます。詳細については、「[リソースレベルのアクセス許可](IAM.ResourceLevelPermissions.md)」を参照してください。
## タグを付けることができるリソース
アカウントにすでに存在するほとんどの ElastiCache リソースにタグ付けできます。以下の表に、タグ付けをサポートするリソースを示します。を使用している場合はAWS マネジメントコンソール、タグ[エディタを使用してリソースにタグ](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)を適用できます。一部のリソースの画面では、リソースの作成時にリソースのタグを指定できます。例えば、Name のキーと指定した値をタグ付けします。ほとんどの場合、リソースの作成後すぐに (リソースの作成時ではなく) コンソールによりタグが適用されます。コンソールではリソースを [**Name**] タグに応じて整理できますが、このタグには ElastiCache サービスに対する意味論的意味はありません。
さらに、リソース作成アクションによってはリソースの作成時にリソースのタグを指定できます。リソースの作成時にタグを適用できない場合はリソース作成プロセスがロールバックされます。これにより、リソースがタグ付きで作成されるか、まったく作成されないようになるため、タグ付けされていないリソースが存在することがなくなります。作成時にリソースにタグ付けすることで、リソース作成後にカスタムタグ付けスクリプティングを実行する必要がなくなります。
Amazon ElastiCache API、 CLI、またはAWS SDK AWSを使用している場合は、関連する ElastiCache API アクションで `Tags`パラメータを使用してタグを適用できます。具体的には次の 2 つです。
+ `CreateServerlessCache`
+ `CreateCacheCluster`
+ `CreateReplicationGroup`
+ `CopyServerlessCacheSnapshot`
+ `CopySnapshot`
+ `CreateCacheParameterGroup`
+ `CreateCacheSecurityGroup`
+ `CreateCacheSubnetGroup`
+ `CreateServerlessCacheSnapshot`
+ `CreateSnapshot`
+ `CreateUserGroup`
+ `CreateUser`
+ `PurchaseReservedCacheNodesOffering`
次の表は、タグ付けできる ElastiCache リソースと、ElastiCache API、 CLI、またはAWS SDK AWSを使用して作成時にタグ付けできるリソースを示しています。
**ElastiCache リソースのタグ付けのサポート**
| [リソース] | タグをサポート | 作成時のタグ付けをサポート |
| --- | --- | --- |
| serverlesscache | はい | はい |
| parametergroup | はい | はい |
| securitygroup | はい | はい |
| subnetgroup | はい | はい |
| replicationgroup | はい | はい |
| クラスター | はい | はい |
| reserved-instance | はい | はい |
| serverlesscachesnapshot | はい | はい |
| スナップショット | はい | はい |
| ユーザー | はい | はい |
| usergroup | はい | はい |
**注記**
グローバルデータストアにタグを付けることはできません。
IAM ポリシーでタグベースのリソースレベルアクセス許可を、作成時のタグ付けをサポートする ElastiCache API アクションに適用し、作成時にリソースにタグ付けできるユーザーとグループを細かく制御できます。リソースは、作成時から適切に保護されます。タグはリソースに即座に適用されます。したがって、リソースの使用を制御するタグベースのリソースレベルの許可は、ただちに有効になります。リソースはより正確に追跡および報告されます。新しいリソースにタグ付けの使用を適用し、リソースで設定されるタグキーと値をコントロールできます。
詳細については、「[リソースのタグ付けの例](#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 件
+ タグキーはリソースごとにそれぞれ一意である必要があります。また、各タグキーに設定できる値は 1 つのみです。
+ キーの最大長 – 128 Unicode 文字 (UTF-8)
+ 値の最大長 - 256 Unicode 文字 (UTF-8)。
+ 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` というタグキーを使用できます。1 つのリソースでは値を `ElastiCache` と `Asia Pacific (Singapore)` にし、別のリソースでは値を `ElastiCache` と `Europe (Frankfurt)` にします。これによって、ElastiCache の合計コストをリージョンごとに表示できます。詳細については、[「AWS Billingユーザーガイド」](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)の*「コスト配分タグの使用」*(Use Cost Allocation Tags) を参照してください。
ElastiCache のコスト配分タグを ElastiCache のノードベースのクラスターに追加できます。タグの追加やリスト、変更、削除を行った場合、そのオペレーションは、指定したクラスターにのみ適用されます。
**ElastiCache コスト配分タグの特徴**
+ コスト配分タグは、ARN として CLI および API オペレーションで指定された ElastiCache リソースに適用されます。resource-type は "cluster" です。
サンプル ARN: `arn:aws:elasticache::::`
サンプル arn: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
+ タグキーは、必須のタグ名です。キーの文字列値は、長さが 1～128 文字の Unicode 文字です。`aws:` をプレフィックスとして使用することはできません。文字列には、一連の Unicode 文字、数字、空白、下線 ( \$1 )、ピリオド ( . )、コロン ( : )、バックスラッシュ ( \$1 )、等号 ( = )、プラス記号 ( \$1 )、ハイフン ( - )、またはアットマーク ( @ ) を含めることができます。
+ タグ値は、オプションのタグの値です。値の文字列値は、長さが 1～256 文字の Unicode 文字です。`aws:` をプレフィックスとして使用することはできません。文字列には、一連の Unicode 文字、数字、空白、下線 ( \$1 )、ピリオド ( . )、コロン ( : )、バックスラッシュ ( \$1 )、等号 ( = )、プラス記号 ( \$1 )、ハイフン ( - )、またはアットマーク ( @ ) を含めることができます。
+ ElastiCache リソースには、最大 50 個のタグを設定できます。
+ 値はタグセット内で一意である必要はありません。例えば、タグセット内に `Service` と `Application` というキーがあり、両方の値として `ElastiCache` を指定できます。
AWSはタグに意味論的な意味を適用しません。タグは文字列として厳密に解釈されます。AWSによって ElastiCache リソースのタグは自動的に設定されません。
# AWS CLI を使用したコスト配分タグの管理
AWS CLI を使用して、コスト配分タグを追加、変更、または削除できます。
コスト配分タグは、ElastiCache クラスターに適用されます。タグ付けされるクラスターは、ARN (Amazon リソースネーム) を使用して指定されます。
サンプル 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) オペレーションを行い、AWS CLI を使用して既存の ElastiCache リソースのタグを一覧表示できます。
次のコードは、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": []
}
```
詳細については、「AWS CLI for ElastiCache [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html)」を参照してください。
## AWS CLI を使用したタグの追加
[add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) CLI オペレーションを行い、AWS CLI を使用して、既存の ElastiCache リソースにタグを追加できます。タグキーがリソースに存在しない場合は、キーと値がリソースに追加されます。キーが既にリソースに存在する場合、キーに関連付けられた値は新しい値に更新されます。
次のコードでは、AWS CLI を使用して、それぞれ `elasticache` と `us-west-2` という値を持つキー `Service` と `Region` を、リージョン us-west-2 のクラスター `my-cluster` 内のノード `my-cluster-001` に追加します。
**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"
}
]
}
```
詳細については、「AWS CLI for ElastiCache [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html)」を参照してください。
オペレーション 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) オペレーションを行い、AWS CLI を使用して、既存の ElastiCache for Memcached クラスターからタグを削除できます。
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": []
}
```
詳細については、「AWS CLI for ElastiCache [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)」を参照してください。
# ElastiCache API を使用したコスト配分タグの管理
ElastiCache API を使用して、コスト配分タグを追加、変更、または削除できます。
コスト配分タグは、ElastiCache for Memcached クラスターに適用されます。タグ付けされるクラスターは、ARN (Amazon リソースネーム) を使用して指定されます。
サンプル 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 API を使用して、既存の ElastiCache クラスターにタグを追加できます。タグキーがリソースに存在しない場合は、キーと値がリソースに追加されます。キーが既にリソースに存在する場合、キーに関連付けられた値は新しい値に更新されます。
次のコードは、ElastiCache API を使用して、`Service` と `Region` というキーを追加し、それぞれの値を `elasticache` と `us-west-2` に設定します。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 API を使用して既存の ElastiCache for Memcached クラスターからタグを削除できます。
次のコードは、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 レンズの使用
このセクションでは、優れたアーキテクチャの ElastiCache ワークロードを設計するための設計原則とガイダンスの集合である Amazon ElastiCache Well-Architected レンズについて説明します。
+ [ElastiCache レンズはAWS Well-Architected フレームワーク](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) - 一体となって事業価値をもたらす一連のコンポーネント。ワークロードの例としては、マーケティングウェブサイト、e コマースウェブサイト、モバイルアプリのバックエンド、分析プラットフォームなどがあります。
**注記**
このガイドは、ElastiCache サーバーレスキャッシュと新しい Valkey エンジンに関する情報を反映して更新されていません。
**Topics**
+ [Amazon ElastiCache Well-Architected レンズのオペレーショナルエクセレンスの柱](OperationalExcellencePillar.md)
+ [Amazon ElastiCache Well-Architected レンズのセキュリティの柱](SecurityPillar.md)
+ [Amazon ElastiCache Well-Architected レンズの信頼性の柱](ReliabilityPillar.md)
+ [Amazon ElastiCache Well-Architected レンズのパフォーマンス効率の柱](PerformanceEfficiencyPillar.md)
+ [Amazon ElastiCache Well-Architected レンズのコスト最適化の柱](CostOptimizationPillar.md)
# Amazon ElastiCache Well-Architected レンズのオペレーショナルエクセレンスの柱
運用上の優秀性の柱では、ビジネス価値をもたらし、プロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングすることに焦点を当てています。主なトピックは、変更の自動化、イベントへの対応、日常業務を管理するための標準の定義です。
**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 コンソールでの ElastiCache により (リージョンを選択した後)、または [Amazon コマンドラインインターフェイス](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) を使用して生成されたイベントを確認します。Amazon Simple Notification Service (Amazon SNS) を使用して重要なクラスターイベントの通知が送信されるように ElastiCache を設定します。クラスターで Amazon SNS を使用すると、ElastiCache イベントに対してプログラム的にアクションを実行できます。
+ イベントには、現在のイベントと予定されているイベントの 2 つの大きなカテゴリがあります。現在のイベントのリストには、リソースの作成と削除、スケーリングオペレーション、フェイルオーバー、ノードの再起動、スナップショットの作成、クラスターのパラメーターの変更、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 メトリクスを使用する必要があります。
**[リソース]:** Lambda と SNS を使用するユースケースについては、[AWS Lambda、Amazon Route 53、Amazon SNS を使用して ElastiCache (クラスターモードが無効) リードレプリカエンドポイントをモニタリングします](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 では、リソースの使用率が高すぎる、または低すぎる場合、2 つの次元でスケールインすることで改善できます。ノード容量を増減することで垂直方向にスケールできます。ノードを追加および削除して、水平方向にスケールすることもできます。
+ **[必須]** プライマリノードの CPU とネットワークの使用率が高すぎる場合は、読み取りオペレーションをレプリカノードにオフロードおよびリダイレクトすることで対処する必要があります。読み取り操作にはレプリカノードを使用して、プライマリノードの使用率を下げます。これは、Valkey または Redis OSS クライアントライブラリで構成でき、クラスターモードが無効な場合は ElastiCache リーダーエンドポイントに接続するか、クラスターモードが有効な場合は READONLY コマンドを使用します。
**[リソース]:**
+ [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 と Redis OSS に対応した ElastiCache クラスターのスケーリング](Scaling.md)
+ [Memcached に対応した ElastiCache クラスターのスケーリング](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/)
+ **[最良]** ElastiCache リソースが CloudFormation で作成されている場合は、運用上の一貫性を保ち、管理されていない構成変更やスタックドリフトを避けるために、CloudFormation テンプレートを使用して変更を実行するのがベストプラクティスです。
**[リソース]:**
+ [CloudFormation の ElastiCache リソースタイプリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[最良]** クラスターの運用データを使用してスケーリングオペレーションを自動化し、CloudWatch でしきい値を定義してアラームを設定します。CloudWatch イベントと 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 は、指定したクラスターのメンテナンス期間中に、基盤となるインフラストラクチャを自動的に更新します。ただし、クラスターで実行されているノードは、セルフサービスの更新によって更新されます。これらの更新には、セキュリティパッチとマイナーソフトウェアの更新の 2 種類があります。パッチの種類の違いと適用時期について必ず理解しておいてください。
**[リソース]:**
+ [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) が短縮され、クライアントが以前のレスポンスをまだ読み取っていない場合でも、新しいリクエストを処理できます。
+ パイプラインを使用すると、応答/ack を待たずに複数のコマンドをサーバーに送信できます。パイプラインの欠点は、最終的にすべてのレスポンスを一括取得したときに、エラーが発生しても、そのエラーを最後までキャッチできない可能性があることです。
+ 不正なリクエストを省略したエラーが返されたときに、リクエストを再試行するメソッドを実装します。
**[リソース]:** [パイプライン](https://valkey.io/topics/pipelining/)
## OE 5: ワークロード用に ElastiCache コンポーネントをどのようにデプロイするか。
**質問レベルの紹介:**ElastiCache 環境は、AWS コンソールから手動でデプロイすることも、API、CLI、ツールキットなどを使用してプログラムでデプロイすることもできます。オペレーショナルエクセレンスのベストプラクティスでは、可能な限りコードを使用してデプロイメントを自動化することを推奨しています。さらに、ElastiCache クラスターはワークロードごとに分離することも、コストの最適化のために組み合わせることもできます。
**質問レベルのメリット:** ElastiCache 環境に最も適したデプロイメカニズムを選択することで、時間の経過とともにオペレーションエクセレンスを向上させることができます。ヒューマンエラーを最小限に抑え、再現性、柔軟性、イベントへの応答時間を向上させるため、可能な限りコードとしてオペレーションを実行することをお勧めします。
ワークロードの分離要件を理解することで、ワークロードごとに専用の ElastiCache 環境を使用するか、複数のワークロードを 1 つのクラスターにまとめるか、またはそれらを組み合わせるかを選択できます。トレードオフを理解することは、オペレーショナルエクセレンスとコスト最適化のバランスをとるのに役立ちます。
+ **[必須]** 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 Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
# Amazon ElastiCache Well-Architected レンズのセキュリティの柱
セキュリティの柱は、情報とシステムの保護に焦点を当てています。主なトピックは、データの機密性と完全性、権限ベースの管理による誰が何を実行できるのかの特定と管理、システムの保護、セキュリティイベントを検出するための制御の確立です。
**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 内の Amazon Elastic Compute Cloud インスタンス、サーバーレス関数 (AWS Lambda)、またはコンテナ (Amazon Elastic Container Service) からアクセスできるように設計されています。最もよく遭遇するシナリオは、同じ Amazon Virtual Private Cloud (Amazon Virtual Private Cloud) の Amazon Elastic Compute Clou インスタンスから ElastiCache クラスターにアクセスすることです。Amazon EC2 インスタンスからクラスターに接続するには、Amazon EC2 インスタンスにクラスターへのアクセスを許可する必要があります。VPC で実行されている ElastiCache クラスターにアクセスするには、クラスターへのネットワーク進入を許可する必要があります。
**質問レベルのメリット:** クラスターへのネットワーク進入は VPC セキュリティグループによって制御されます。セキュリティグループは、Amazon EC2 インスタンスの仮想ファイアウォールとして機能し、受信トラフィックと送信トラフィックを制御します。インバウンドルールはインスタンスへの受信トラフィックを制御し、アウトバウンドルールはインスタンスからの送信トラフィックをコントロールします。ElastiCache の場合、クラスターを起動するときに、セキュリティグループを関連付ける必要があります。これにより、インバウンドとアウトバウンドのトラフィックルールがクラスターを構成するすべてのノードに適用されるようになります。さらに、ElastiCache はプライベートサブネットにのみデプロイするように設定されているため、VPC のプライベートネットワーク経由でのみアクセスできます。
+ **[必須]** クラスターに関連付けられているセキュリティグループは、クラスターへのネットワークの進入とアクセスを制御します。デフォルトでは、セキュリティグループにはインバウンドルールが定義されていないため、ElastiCache への進入パスはありません。これを有効にするには、セキュリティグループのインバウンドルールを設定し、送信元 IP アドレス/範囲、TCP タイプのトラフィック、および ElastiCache クラスターのポート (例えば、ElastiCache for Valkey と ElastiCache for 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 トークン (パスワード) を強制することが含まれます。
+ **[最良]** Redis OSS 用の ElastiCache バージョン 6.x 以降と Valkey 用の ElastiCache バージョン 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)
+ **[最良]** Redis OSS 用の 6.x より前のバージョンの ElastiCache では、強力なトークンまたはパスワードを設定し、AUTH の厳格なパスワードポリシーを維持することに加えて、パスワードまたはトークンをローテーションすることがベストプラクティスです。ElastiCache は一度に最大 2 つの認証トークンを管理できます。また、クラスターを変更して、認証トークンの使用を明示的に要求することもできます。
**[リソース]: **[既存の ElastiCache クラスターでの AUTH トークンの変更](auth.md#auth-modifyng-token)
## SEC 3: コマンドが誤って実行され、データが失われたり失敗するリスクはあるか。
**質問レベルの導入:** 誤って実行されたり、悪意のある攻撃者によって実行されたりすると、オペレーションに悪影響を及ぼす可能性のある Valkey または Redis OSS コマンドが多数あります。これらのコマンドは、パフォーマンスとデータ安全性の観点から、意図しない結果をもたらす可能性があります。例えば、開発者が開発環境で日常的に FLUSHALL コマンドを呼び出している場合、間違って本番システムでこのコマンドを呼び出そうとすると、誤ってデータが失われる可能性があります。
**質問レベルのメリット:** Redis OSS 用の ElastiCache バージョン 5.0.3 以降、ワークロードに支障をきたす可能性のある特定のコマンドの名前を変更できるようになりました。コマンドの名前を変更すると、クラスターでコマンドが誤って実行されるのを防ぐことができます。
+ **[必須] **
**[リソース]: **
+ [Redis OSS 用の ElastiCache バージョン 5.0.3 (廃止、バージョン 5.0.6 を使用してください)](engine-versions.md#redis-version-5-0.3)
+ [Redis OSS 用の ElastiCache バージョン 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 クラスターの保管中のデータの暗号化に使用されるキーを作成、所有、管理できます。
**[リソース]: **
+ [ からの KMS のカスタマーマネージドキーの使用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 と ElastiCache for 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 レンズの信頼性の柱
信頼性の柱は、ワークロードがその意図した機能を果たし、需要に応じて迅速に障害から回復する方法に焦点を当てています。主なトピックとして、分散システムの設計、復旧計画、および要件の変更への対応方法があります。
**Topics**
+ [REL 1: 高可用性 (HA) アーキテクチャの導入をどのようにサポートしているか。](#ReliabilityPillarREL1)
+ [REL 2: ElastiCache を使用して目標復旧時点 (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 および ElastiCache for Redis OSS
1. ElastiCache for Memcached にはレプリケーションメカニズムがなく、主に一時的なワークロードに使用されます。
1. ElastiCache for Valkey と ElastiCache for Redis OSS は、以下で説明する HA 機能を提供します。
+ **[最良]** HA を必要とするワークロードでは、1 つのシャードしか必要としないスループット要件の低いワークロードでも、1 シャードあたり少なくとも 2 つのレプリカがあるクラスターモードで ElastiCache を使用します。
1. クラスターモードを有効にすると、マルチ AZ が自動的に有効になります。
マルチ AZ は、計画的または計画外のメンテナンスが発生した場合に、プライマリノードからレプリカへの自動フェイルオーバーを実行することでダウンタイムを最小限に抑え、AZ の障害を軽減します。
1. シャーディングされたワークロードの場合、最低 3 つのシャードを使用するとフェイルオーバーイベント中の復旧が速くなります。これは、Valkey または Redis OSS クラスタープロトコルでは、クォーラムの達成にプライマリノードの過半数を利用可能にする必要があるためです。
1. アベイラビリティ全体で 2 つ以上のレプリカを設定します。
レプリカが 2 つあると、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 を使用して目標復旧時点 (RPO) をどのように達成しているか。
**質問レベルの紹介:** ワークロードの RPO を理解して、ElastiCache のバックアップとリカバリの戦略に関する意思決定に役立てます。
**質問レベルのメリット:** RPO 戦略を策定することで、ディザスタリカバリシナリオが発生した場合の事業継続性を向上させることができます。バックアップと復元のポリシーを設計すると、ElastiCache データの目標復旧時点 (RPO) の達成に役立ちます。ElastiCache には、Amazon S3 に保存されるスナップショット機能と、設定可能な保持ポリシーがあります。これらのスナップショットは、定義されたバックアップウィンドウ中に取得され、サービスによって自動的に処理されます。ワークロードにさらに細かいバックアップが必要な場合は、1 日あたり最大 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 グローバルデータストアを使用すると、1 つのリージョンのクラスターに書き込み、そのデータを他の 2 つのクロスリージョンのレプリカクラスターから読み取ることができるため、リージョン間での低レイテンシーの読み取りとディザスタリカバリが可能になります。
**質問レベルのメリット:** さまざまな災害シナリオを理解して計画することで、事業継続性を確保できます。DR 戦略は、コスト、パフォーマンスへの影響、およびデータ損失の可能性とのバランスを取る必要があります。
+ **[必須]** ワークロード要件に基づいて、すべての ElastiCache コンポーネントの DR 戦略を策定し、文書化します。ElastiCache がユニークなのは、完全に一時的で DR 戦略を必要としないユースケースもあれば、逆に、きわめて強固な DR 戦略を必要とするユースケースもあるという点です。すべてのオプションは、コストの最適化に対して比較検討する必要があります。回復力を高めるには、より多くのインフラストラクチャが必要です。
リージョンレベルおよびマルチリージョンレベルで利用可能な DR オプションを理解します。
+ AZ 障害を防ぐために、マルチ AZ 配置が推奨されます。マルチ AZ アーキテクチャでは、必ずクラスターモードを有効にして、最低 3 つの AZ が利用可能な状態でデプロイします。
+ リージョンの障害を防ぐために、グローバルデータストアの使用が推奨されます。
+ **[最良]** リージョンレベルの耐障害性を必要とするワークロードには、グローバルデータストアを有効にします。
+ プライマリのパフォーマンスが低下した場合に備えて、セカンダリリージョンへのフェイルオーバーを計画します。
+ 本番環境でフェイルオーバーする前に、マルチリージョンのフェイルオーバープロセスをテストします。
+ `ReplicationLag` メトリクスをモニタリングして、フェイルオーバーイベント中のデータ損失の潜在的な影響を把握します。
+ **[リソース]: **
+ [障害の軽減](disaster-recovery-resiliency.md#FaultTolerance)
+ [Global Datastore を使用した AWS リージョン間のレプリケーション](Redis-Global-Datastore.md)
+ [クラスターのサイズ変更 (オプション) によるバックアップからの復元](backups-restoring.md)
+ [マルチ AZ を使用して ElastiCache for Valkey と ElastiCache for Redis OSS のダウンタイムを最小限に抑える](AutoFailover.md)
## REL 4: フェイルオーバーを効果的に計画するにはどうすればよいか。
**質問レベルの紹介:** 自動フェイルオーバーでマルチ AZ を有効にすることは、ElastiCache のベストプラクティスです。場合によっては、ElastiCache for Valkey と ElastiCache for Redis OSS はサービス運用の一貫としてプライマリノードを置き換えます。例えば、計画されたメンテナンスのイベントや、ノードの障害またはアベイラビリティゾーンの問題という万一の場合が含まれます。フェイルオーバーが成功するかどうかは、ElastiCache とクライアントライブラリの設定の両方に依存します。
**質問レベルのメリット:** ElastiCache フェイルオーバーのベストプラクティスを特定の ElastiCache クライアントライブラリと組み合わせて実行すると、フェイルオーバーイベント中の潜在的なダウンタイムを最小限に抑えることができます。
+ **[必須]** クラスターモードが無効になっている場合は、タイムアウトを使用して、クライアントが古いプライマリノードから切断して、更新されたプライマリエンドポイントの IP アドレスを使用して新しいプライマリノードに再接続する必要があるかどうかを検出できるようにします。クラスターモードが有効になっている場合、クライアントライブラリは基盤となるクラスタートポロジの変更を検出します。これは、ほとんどの場合、ElastiCache クライアントライブラリの設定によって実現されます。これにより、頻度と更新方法も設定できます。各クライアントライブラリには独自の設定があり、詳細は対応するドキュメントに記載されています。
**[リソース]: **
+ [マルチ AZ を使用して ElastiCache for Valkey と ElastiCache for Redis OSS のダウンタイムを最小限に抑える](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 を使用して、フェイルオーバー中のアプリケーションの応答性を定期的に検証します。
**[リソース]: **
+ [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 を増やすには、シャードを追加します (スケールアウト)
+ ネットワーク IO を増やすには — ネットワーク最適化インスタンス、スケールアップを使用します
+ **[最良]** ElastiCache コンポーネントをクラスターモードを有効にしてデプロイし、少ないノード数で大規模にするのではなく、小さなノードを数多くします。これにより、ノード障害時の影響範囲を効果的に制限できます。
+ **[最良]** クラスターにレプリカを含めると、スケーリングイベント中の応答性が向上します
+ **[良い]** クラスターモードが無効になっている場合は、リードレプリカを活用して全体的な読み取り容量を増加します。ElastiCache は、クラスターモードが無効な状態で最大 5 つのリードレプリカをサポートし、垂直スケーリングもサポートします。
+ **[リソース]: **
+ [ElastiCache クラスターのスケーリング](Scaling.md)
+ [オンラインスケールアップ](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# Amazon ElastiCache Well-Architected レンズのパフォーマンス効率の柱
パフォーマンス効率の柱は、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: 自動スケーリングは ElastiCache クラスターのパフォーマンスを向上させるのにどのように役立つか。](#PerformanceEfficiencyPillarPE8)
## PE 1: Amazon ElastiCache クラスターのパフォーマンスをどのようにモニタリングするか。
**質問レベルの紹介:** 既存のモニタリングメトリクスを理解することで、現在の使用率を特定できます。適切にモニタリングすることで、クラスターのパフォーマンスに影響を与える潜在的なボトルネックを特定できます。
**質問レベルのメリット:** クラスターに関連するメトリクスを理解することは、レイテンシーの削減とスループットの向上につながる最適化手法の指針となります。
+ **[必須]** ワークロードのサブセットを使用したベースラインパフォーマンスのテスト。
+ 負荷テストなどのメカニズムを使用して、実際のワークロードのパフォーマンスをモニタリングする必要があります。
+ これらのテストを実行しながら CloudWatch メトリクスをモニタリングして、利用可能なメトリクスを理解し、パフォーマンスのベースラインを確立します。
+ **[最良]** ElastiCache for Valkey と ElastiCache for Redis OSS のワークロードでは、`KEYS` など、計算量の多いコマンドの名前を変更して、ユーザーが本番クラスターでブロッキングコマンドを実行する能力を制限します。
+ Redis OSS 用のエンジン 6.x を実行する ElastiCache ワークロードでは、ロールベースのアクセスコントロールを利用して特定のコマンドを制限できます。コマンドへのアクセスは、AWSコンソールまたは CLI を使用してユーザーとユーザーグループを作成し、ユーザーグループをクラスターに関連付けることで制御できます。Redis OSS 6 では、RBAC が有効になっている場合、「-@dangerous」を使用できます。これにより、そのユーザーには KEYS、MONITOR、SORT などのコストの高いコマンドが許可されなくなります。
+ エンジンバージョン 5.x では、クラスターパラメータグループで `rename-commands` パラメータを使用してコマンドの名前を変更します。
+ **[さらに良い]** 処理が遅いクエリを分析し、最適化手法を検討します。
+ ElastiCache for Valkey と ElastiCache for Redis OSS のワークロードの場合は、スローログを分析してクエリについて詳しく調べます。例えば、`valkey-cli slowlog get 10` コマンドを使用して、レイテンシーのしきい値 (デフォルトは 10 ミリ秒) を超えた直近の 10 個のコマンドを表示できます。
+ 特定のクエリは、ElastiCache for Valkey と ElastiCache for Redis OSS の複雑なデータ構造を使用するとより効率的に実行できます。例えば、数値形式の範囲検索の場合、アプリケーションはソートセットを使用して単純な数値インデックスを実装できます。これらのインデックスを管理することで、データセットに対して実行されるスキャン数を減らし、より高いパフォーマンス効率でデータを返すことができます。
+ ElastiCache for Valkey と ElastiCache for 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 と ElastiCache for Redis OSS は、使用中のクラスターモードに基づいてさまざまなエンドポイントを実装します。クラスターモードを有効にすると、ElastiCache が設定エンドポイントを提供します。クラスターモードを無効にすると、ElastiCache はプライマリエンドポイント (通常は書き込み用) と、レプリカ間の読み取りのバランスを図るリーダーエンドポイントを提供します。これらのエンドポイントを正しく実装すると、パフォーマンスが向上し、オペレーションのスケーリングが容易になります。特定の要件がない限り、個々のノードエンドポイントへの接続は回避します。
+ マルチノードの Memcached クラスターでは、ElastiCache は自動検出を可能にする設定エンドポイントを提供します。キャッシュノード全体に作業を均等に分散するには、ハッシュアルゴリズムの使用をお勧めします。多くの Memcached クライアントライブラリは整合性のあるハッシュを実装しています。使用中のライブラリのドキュメントを参照し、整合性のあるハッシュをサポートするかどうかと、その実装方法について確認してください。これらの機能の実装の詳細については、[こちら](BestPractices.LoadBalancing.md)をご覧ください。
+ **[さらに良い]** スケーラビリティを向上させるために、ElastiCache for Valkey と ElastiCache for Redis OSS のクラスターモードが有効なクラスターを活用します。
+ ElastiCache for Valkey と ElastiCache for Redis OSS の (クラスターモードが有効) クラスターは[オンラインスケーリングオペレーション](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) (アウト/イン、アップ/ダウン) をサポートしているため、シャード全体にデータを動的に分散できます。設定エンドポイントを使用すると、クラスター対応クライアントがクラスタートポロジーの変化に確実に適応できるようになります。
+ また、ElastiCache for Valkey と ElastiCache for Redis OSS の (クラスターモードが有効) クラスター内の使用可能なシャード間でハッシュスロットを移動して、クラスターのバランスを再調整することもできます。これにより、使用可能なシャード間で作業をより効率的に分散できます。
+ **[さらに良い]** ワークロード内のホットキーを特定して修正するための戦略を実装します。
+ リスト、ストリーム、セットなどの多次元の Valkey または Redis OSS データ構造の影響を考慮してください。これらのデータ構造は、単一のノードにある単一の Keys に保存されます。多次元キーが非常に大きい場合、他のデータ型よりも多くのネットワーク容量とメモリを使用する可能性があり、そのノードが不均衡に使用される可能性があります。可能な場合は、データアクセスを多数の個別のキーに分散するようにワークロードを設計します。
+ ワークロード内のホットキーは、使用中のノードのパフォーマンスに影響を与える可能性があります。ElastiCache for Valkey と ElastiCache for Redis OSS のワークロードでは、LFU 最大メモリポリシーが設定されている場合、`valkey-cli --hotkeys` を使用してホットキーを検出できます。
+ ホットキーを複数のノードに複製して、アクセス権を均等に分散することを検討してください。この方法では、クライアントは複数のプライマリノードへの書き込み (Valkey または Redis OSS ノード自体はこの機能は提供しません) と、元のキー名に加えて読み取り元のキー名のリストの管理が必要となります。
+ Valkey 用の ElastiCache エンジン 7.2 以降と Redis OSS 用の ElastiCache バージョン 6 以降はすべて、サーバー支援型[クライアント側のキャッシュ](https://valkey.io/topics/client-side-caching/)をサポートしています。これにより、アプリケーションはキーが変更されるのを待ってから、ElastiCache にネットワークコールバックを行うことができます。
+ **[リソース]: **
+ [可用性を高めるために ElastiCache for Valkey と ElastiCache for 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 使用率の値と合わせて測定および収集し、存続時間やその他のアプリケーションコンポーネントを調整する必要があるかどうかを判断します。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、ElastiCache for Memcached、ElastiCache for 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)
+ [Redis OSS 用の ElastiCache バージョン 5.0.3 は I/O 処理を強化してパフォーマンスを向上](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 ElastiCache クラスター上のエビクションの数は、Amazon CloudWatch のエビクションメトリクスを使用してモニタリングできます。
+ **[さらに良い]** 削除動作を標準化してクラスターのパフォーマンスへの影響を制御し、予期しないパフォーマンスのボトルネックを回避します。
+ ElastiCache for Valkey と ElastiCache for Redis OSS のワークロードでは、クラスターからキーを明示的に削除すると、`UNLINK` は `DEL` のように、指定されたキーが削除されます。ただし、このコマンドは実際のメモリ再利用を別のスレッドで実行するため、ブロッキングしませんが、`DEL` はします。実際の削除は後に非同期で行われます。
+ Redis OSS 用の ElastiCache バージョン 6.x のワークロードでは、`DEL` コマンドの動作は、`lazyfree-lazy-user-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 および ElastiCache for Redis OSS コマンドの時間の複雑さは Big O 表記法で定義されます。このコマンドの時間の複雑さは、その影響をアルゴリズム的または数学的に表現したものです。アプリケーションに新しいデータ型を導入する際には、関連するコマンドの時間の複雑さを注意深く見直す必要があります。時間の複雑さが O (1) のコマンドは時間が一定で、入力のサイズには依存しませんが、時間の複雑さが O (N) のコマンドは時間が線形で、入力のサイズに影響されます。ElastiCache for Valkey と ElastiCache for 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 に転送する機能もあります。
**質問レベルのメリット:** 専用の場所にログを記録し、処理が遅いコマンドに通知イベントを提供することは、詳細なパフォーマンス分析に役立ち、自動イベントのトリガーにも使用できます。
+ **[必須]** ElastiCache で Valkey エンジン 7.2 以降、または Redis OSS エンジンバージョン 6.0 以降を実行し、パラメータグループが適切に設定され、クラスターで SLOWLOG ロギングが有効になっていること。
+ 必須パラメータは、エンジンバージョンの互換性が Valkey 7.2 以降、Redis OSS バージョン 6.0 以降に設定されている場合にのみ使用できます。
+ SLOWLOG ロギングは、コマンドのサーバー実行時間が指定された値よりも長い場合に発生します。クラスターの動作は、関連するパラメータグループのパラメータ (`slowlog-log-slower-than` および `slowlog-max-len`) によって異なります。
+ 変更は即時適用されます。
+ **[最良]** CloudWatch または Kinesis Data Firehose の機能を活用します。
+ CloudWatch、CloudWatch Logs Insights、Amazon Simple Notification Services のフィルタリング機能とアラーム機能を使用して、パフォーマンスのモニタリングとイベント通知を行います。
+ Kinesis Data Firehose のストリーミング機能を使用して、SLOWLOG ログを永続ストレージにアーカイブしたり、クラスターパラメータの自動チューニングをトリガーします。
+ JSON 形式とプレーンテキスト形式のどちらがニーズに最も適しているかを判断してください。
+ CloudWatch または Kinesis Data Firehose に公開するための IAM アクセス許可を提供します。
+ **[さらに良い]** `slowlog-log-slower-than` をデフォルト以外の値に設定します。
+ このパラメータは、実行速度が遅いコマンドとして記録されるまでにコマンドが Valkey または Redis OSS エンジン内で実行できる時間を決定します。デフォルト値は 10,000 マイクロ秒 (10 ミリ秒) です。一部のワークロードでは、このデフォルト値は高すぎる場合があります。
+ アプリケーションのニーズとテスト結果に基づいて、ワークロードにより適した値を決定します。ただし、値が低すぎると、過剰なデータが生成される可能性があります。
+ **[さらに良い]** `slowlog-max-len` をデフォルト値のままにしておきます。
+ このパラメータは、所定の時間において実行速度が遅いコマンドを Valkey または Redis OSS メモリにキャプチャする数の上限を決定します。値が 0 の場合、キャプチャは事実上無効になります。値が大きいほど、メモリに保存されるエントリの数が増え、確認する前に重要な情報がエビクションされる可能性が低くなります。デフォルト値は 128 です。
+ デフォルト値は、ほとんどのワークロードに適しています。valkey-cli から SLOWLOG コマンドを使用して拡張された時間枠でデータを分析する必要がある場合は、この値の増加を検討してください。これにより、より多くのコマンドを 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: 自動スケーリングは ElastiCache クラスターのパフォーマンスを向上させるのにどのように役立つか。
**質問レベルの紹介:** Valkey または Redis OSS 自動スケーリングの機能を実装することで、ElastiCache コンポーネントは時間の経過とともに調整され、必要なシャードやレプリカを自動的に増減できます。これは、ターゲットトラッキングポリシーまたはスケジュールされたスケーリングポリシーのいずれかを実装することで実現できます。
**質問レベルのメリット:** ワークロードの急増を把握し、計画を立てることで、キャッシュのパフォーマンスと事業継続性を確実に向上させることができます。ElastiCache 自動スケーリングは、クラスターが希望するパフォーマンスレベルで動作していることを確認するために、CPU とメモリの使用率を継続的にモニタリングします。
+ **[必須] **ElastiCache for Valkey または ElastiCache for Redis OSS に対してクラスターを起動する場合:
1. クラスターモードが有効になっていることを確認します
1. インスタンスが自動スケーリングをサポートする特定のタイプとサイズのファミリーに属していることを確認します
1. クラスターがグローバルデータストア、Outposts、または Local Zones で実行されていないことを確認します
**[リソース]: **
+ [Valkey および Redis OSS (クラスターモードが有効) でのクラスターのスケーリング](scaling-redis-cluster-mode-enabled.md)
+ [シャードでの自動スケーリングの使用](AutoScaling-Using-Shards.md)
+ [レプリカでの自動スケーリングの使用](AutoScaling-Using-Replicas.md)
+ **[最良]** ワークロードが読み取り中心か、または書き込み中心かを特定して、スケーリングポリシーを定義します。最高のパフォーマンスを達成するには、1 つのトラッキングメトリクスのみを使用します。自動スケーリングポリシーは、ターゲットがヒットするとスケールアウトしますが、すべてのターゲットトラッキングポリシーがスケールインできる状態になって初めてスケールインするため、ディメンションごとに複数のポリシーを設定するのは避けることをお勧めします。
**[リソース]: **
+ [自動スケーリングポリシー](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 レンズのコスト最適化の柱
コスト最適化の柱は、不必要なコストを回避することに焦点を当てています。主なトピックには、資金の用途の把握と管理、最適なノードタイプの選択 (ワークロードのニーズに基づくデータ階層化をサポートするインスタンスの使用)、適切な数のリソースタイプ (リードレプリカの数)、経時的な支出の分析、浪費することなくビジネスニーズを満たすためのスケーリングなどがあります。
**Topics**
+ [コスト 1: ElastiCache リソースに関連するコストをどのように特定し、追跡するか。作成したリソースをユーザーが作成、管理、廃棄できるようにするメカニズムをどのように開発しますか。](#CostOptimizationPillarCOST1)
+ [コスト 2: ElastiCache リソースに関連するコストの最適化のために、継続的モニタリングツールをどのように使用するか。](#CostOptimizationPillarCOST2)
+ [コスト 3: データ階層化をサポートするインスタンスタイプを使用すべきか。データ階層化のメリットは何か。データ階層化インスタンスを使用すべきでないのはどのような場合か。](#CostOptimizationPillarCOST3)
## コスト 1: ElastiCache リソースに関連するコストをどのように特定し、追跡するか。作成したリソースをユーザーが作成、管理、廃棄できるようにするメカニズムをどのように開発しますか。
**質問レベルの紹介:** コストメトリクスを把握するには、ソフトウェアエンジニアリング、データ管理、製品所有者、財務、リーダーシップなど、複数のチームの参加とコラボレーションが必要です。主なコスト要因を特定するには、すべての関係者がサービスの利用管理手段とコスト管理のトレードオフを把握する必要があり、多くの場合、それがコスト最適化の取り組みの成功と失敗を大きく左右します。開発から本番稼働まで、そして廃止までに作成されたリソースを追跡するプロセスとツールを用意しておくと、ElastiCache に関連するコストを管理するのに役立ちます。
**質問レベルのメリット:** ワークロードに関連するすべてのコストを継続的に追跡するには、ElastiCache をコンポーネントの 1 つとして含むアーキテクチャを深く理解する必要があります。さらに、使用状況を収集して予算と比較するためのコスト管理計画を立てておく必要があります。
+ **[必須]** 組織の ElastiCache の使用状況に関するメトリクスの定義、追跡、アクションの実行のために、創設憲章の 1 つとともに Cloud Center of Excellence (CCoE) を設立してください。CCoE が存在し、機能している場合は、ElastiCache に関連するコストの読み取り方法と追跡方法について把握していることを確認してください。リソースを作成したら、IAM のロールとポリシーを使用して、特定のチームとグループのみがリソースをインスタンス化できることを検証します。これにより、コストがビジネスの成果と結びつき、コストの観点から明確な説明責任が確立されます。
1. CCoE は、次のようなカテゴリデータにおける主要な ElastiCache の使用状況について、定期的に (毎月) 更新されるコストメトリクスを特定、定義、公開する必要があります。
1. 使用されるノードの種類とその属性: 標準インスタンスとメモリ最適化インスタンス、オンデマンドインスタンスとリザーブドインスタンス、リージョンとアベイラビリティゾーン
1. 環境の種類: 無料、開発、テスト、本番
1. バックアップストレージと保存戦略
1. リージョン内およびリージョン間のデータ転送
1. Amazon Outposts で実行されているインスタンス
1. CCoE は、組織内のソフトウェアエンジニアリング、データ管理、製品チーム、財務チーム、リーダーシップチームからの非独占的な代表者による部門横断チームで構成されています。
**[リソース]: **
+ [Cloud Center of Excellence の作成](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 には 2 つのタイプのコスト配分タグ、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 の効果的なコスト管理戦略を立てるには、可視性、説明責任、優先順位付け、リソースに対するリーダーシップのサポートが不可欠です。
## コスト 2: ElastiCache リソースに関連するコストの最適化のために、継続的モニタリングツールをどのように使用するか。
**質問レベルの紹介:** ElastiCache のコストとアプリケーションのパフォーマンスメトリクスの適切なバランスを図ることを目指す必要があります。Amazon CloudWatch は主要な運用メトリクスを可視化できるため、ElastiCache リソースの使用率が高すぎるか、または十分に活用されていないかをニーズに応じて評価できます。コスト最適化の観点からは、いつオーバープロビジョニングされているかを把握し、運用、可用性、回復力、パフォーマンスのニーズを維持しつつ、ElastiCache リソースのサイズを変更する適切なメカニズムを開発できる必要があります。
**質問レベルのメリット:** 理想的な状態では、ワークロードの運用上のニーズを満たすのに十分なリソースをプロビジョニングでき、コストが最適ではない状態につながる可能性のある、十分に活用されていないリソースがないことです。サイズが大きすぎる ElastiCache リソースの長期間の使用を特定し、同時に回避できる必要があります。
+ **[必須]** CloudWatch を使用して ElastiCache クラスターを監視し、これらのメトリクスが AWS Cost 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 時間あたりの使用料金よりもはるかに安くなります。
1. リザーブドインスタンスの要件を推定するのに十分なデータを収集するまで、オンデマンドノードを使用して ElastiCache クラスターを運用する必要がある場合があります。ニーズを満たすために必要なリソースを計画して文書化し、インスタンスタイプ (オンデマンドとリザーブド) で予想コストを比較します。
1. 利用可能な新しいキャッシュノードタイプを定期的に評価し、コストと運用メトリクスの観点から、インスタンスフリートを新しいキャッシュノードタイプに移行することが理にかなっているかどうかを評価します。
## コスト 3: データ階層化をサポートするインスタンスタイプを使用すべきか。データ階層化のメリットは何か。データ階層化インスタンスを使用すべきでないのはどのような場合か。
**質問レベルの紹介:** 適切なインスタンスタイプを選択すると、パフォーマンスやサービスレベルだけでなく、財務面にも影響が及びます。インスタンスタイプにはそれぞれ異なるコストがかかります。そのため、メモリ内のすべてのストレージニーズに対応できる大規模なインスタンスタイプを 1 つまたはいくつか選択するのは、自然な判断かもしれません。ただし、プロジェクトが成熟するにつれて、この選択はコストに大きな影響を与える可能性があります。正しいインスタンスタイプが選択されていることを確認するには、ElastiCache オブジェクトのアイドル時間を定期的に調査する必要があります。
**質問レベルのメリット:** さまざまなインスタンスタイプが現在および将来のコストにどのように影響するかを明確に理解しておく必要があります。ワークロードのわずかな変化や定期的な変更によってコストが不均等に変化してはいけません。ワークロードが許せば、データ階層化をサポートするインスタンスタイプのほうが、利用可能なストレージあたりの価格が向上します。インスタンスごとに利用可能な SSD ストレージのため、データ階層化インスタンスは、インスタンス機能あたりはるかに多の合計データ容量をサポートします。
+ **[必須]** データ階層化インスタンスの制限を理解する
1. ElastiCache for Valkey または ElastiCache for Redis OSS クラスターでのみ利用可能です。
1. データ階層化をサポートしているインスタンスタイプは限られています。
1. Redis OSS 用の ElastiCache バージョン 6.2 以降のみがサポートされています
1. 大きなアイテムは SSD にスワップアウトされません。128 MiB を超えるオブジェクトはメモリに保持されます。
**[リソース]: **
+ [データ階層化](data-tiering.md)
+ [Amazon ElastiCache 料金表](https://aws.amazon.com/elasticache/pricing/)
+ **[必須]** データベースの何パーセントがワークロードから定期的にアクセスされているかを把握します。
1. データ階層化インスタンスは、データセット全体のごく一部にアクセスすることが多いものの、残りのデータへの高速アクセスが必要なワークロードに最適です。つまり、ホットデータとウォームデータの比率は約 20:80 です。
1. オブジェクトのアイドル時間をクラスターレベルで追跡する機能を開発します。
1. 優れた選択肢としては、500 GB を超えるデータを扱う大規模な実装を行うことです。
+ **[必須]** 特定のワークロードでは、データ階層化インスタンスはオプションではないことを理解しておきます。
1. 使用頻度の低いオブジェクトはローカル SSD にスワップアウトされるため、アクセス時に多少のパフォーマンスコストが発生します。アプリケーションが応答時間に敏感な場合は、ワークロードへの影響をテストしてください。
1. 主にサイズが 128 MiB を超える大きなオブジェクトを格納するキャッシュには適していません。
**[リソース]: **
+ [制限](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. **クラスターモード: **CROSSLOT エラーまたは [SELECT](https://valkey.io/commands/select/) コマンドでエラーが発生する場合、クラスタープロトコルをサポートしていない 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 にデプロイされている場合、キャッシュにアクセスするときにアプリケーションにクロス AZ ホップが発生し、クライアント側のレイテンシーが高くなる可能性があります。
+ **接続を再利用する: **ElastiCache サーバーレスリクエストは、RESP プロトコルを使用した TLS が有効な TCP 接続を介して行われます。接続の開始 (設定されている場合は接続の認証を含む) には時間がかかるため、最初のリクエストのレイテンシーは通常よりも高くなります。初期化済みの接続を介したリクエストでは、ElastiCache は一貫した低レイテンシーを実現できます。このため、接続プールを使用するか、既存の Valkey または Redis OSS 接続を再利用することを検討する必要があります。
+ **スケーリング速度: **ElastiCache サーバーレスは、リクエストレートの増加に応じて自動的にスケールします。リクエストレートが急激に増加し、ElastiCache サーバーレスのスケーリング速度を上回る場合、しばらくの間レイテンシーが高くなる可能性があります。ElastiCache サーバーレスは、通常、サポートされるリクエストレートを迅速に増加でき、リクエストレートを 2 倍にするには最大 10～12 分かかります。
+ **長時間実行されているコマンドを検査する: **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 と ElastiCache for Redis OSS では、スロットあたりのキーまたはリクエストの分散が不均等になると、ホットスロットが発生し、レイテンシーが高くなる可能性があります。ElastiCache サーバーレスは、シンプルな SET/GET コマンドを実行するワークロードにおいて、1 つのスロットで最大 30,000 ECPU/秒 (レプリカからの読み取りを使用する場合、90,000 ECPU/秒) をサポートします。リクエストレートがこの制限を超える場合は、スロット間でキーとリクエストの分散を評価し、均等な分散を確認することをお勧めします。
## ElastiCache サーバーレスでのスロットリング問題のトラブルシューティング
サービス指向アーキテクチャや分散システムでは、API 呼び出しが各種サービスコンポーネントによって処理される速度を制限することをスロットリングと呼びます。これにより、急増が平滑化され、コンポーネントのスループットの不一致が制御され、予期しない運用上のイベントが発生した場合の回復が予測しやすくなります。ElastiCache サーバーレスはこれらのタイプのアーキテクチャ用に設計されており、ほとんどの Valkey または Redis OSS クライアントには、スロットリングされたリクエストの再試行が組み込まれています。ある程度のスロットリングはアプリケーションにとって必ずしも問題とはなりませんが、データワークフローのレイテンシーの影響を受けやすい部分を継続的にスロットリングすると、ユーザーエクスペリエンスに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。
ElastiCache サーバーレスでリクエストがスロットリングされると、`ThrottledRequests` [ElastiCache サーバーレス](serverless-metrics-events-redis.md#serverless-metrics)メトリクスが増加します。スロットリングされたリクエストの数が多い場合は、次の点を考慮してください。
+ **スケーリング速度: **ElastiCache サーバーレスは、より多くのデータを取り込んだり、リクエストレートを引き上げたりすると自動的にスケールします。アプリケーションのスケール速度が ElastiCache サーバーレスのスケーリング速度を超える場合、ElastiCache サーバーレスがワークロードに応じてスケールする間にリクエストがスロットリングされる可能性があります。ElastiCache サーバーレスは、通常、ストレージサイズを迅速に増加でき、キャッシュ内のストレージサイズを 2 倍にするには最大 10～12 分かかります。
+ **キーとリクエストの均等な分散: **ElastiCache for Valkey と ElastiCache for Redis OSS では、スロットあたりのキーまたはリクエストの分散が不均等になると、ホットスロットが発生する可能性があります。単一のスロットへのリクエストレートが 30,000 ECPU/秒を超えると、それがシンプルな SET/GET コマンドを実行するワークロードの場合には、ホットスロットによってリクエストがスロットリングされる可能性があります。同様に、ElastiCache for Memcached では、リクエストレートが 30,000 ECPU/秒を超えると、ホットキーによってリクエストがスロットリングされる可能性があります。
+ **レプリカからの読み取り: **アプリケーションで許可されている場合は、「レプリカからの読み取り」機能の使用を検討してください。ほとんどの Valkey または Redis OSS クライアントは、レプリカノードへの読み取りを指示するように、「読み取りのスケーリング」を設定できます。この機能を使用すると、読み取りトラフィックをスケールできます。さらに、ElastiCache サーバーレスは、レプリカリクエストからの読み取りをアプリケーションと同じアベイラビリティーゾーンのノードに自動的にルーティングするため、レイテンシーが低くなります。レプリカからの読み取りを有効にすると、シンプルな SET/GET コマンドを使用するワークロードに対して、1 つのスロットで最大 90,000 ECPU/秒を達成できます。
# 持続的な接続性の問題
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)
+ [1 つのリクエストを完了するのにかかった時間の解読](#Dissecting-time)
## セキュリティグループ
セキュリティグループは、ElastiCache クライアント (EC2 インスタンス、AWS Lambda 関数、Amazon ECS コンテナなど) と ElastiCache キャッシュを保護する仮想ファイアウォールです。セキュリティグループはステートフルです。つまり、着信トラフィックまたは発信トラフィックが許可されると、そのトラフィックに対する応答は、その特定のセキュリティグループのコンテキストで自動的に承認されます。
ステートフル機能では、セキュリティグループがすべての許可された接続を追跡し続ける必要があり、追跡される接続には制限があります。制限に到達すると、新しい接続は失敗します。クライアント側または 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 ルールの評価はシーケンシャルです。つまり、トラフィックに一致する最も小さい番号を持つルールで、それが許可または拒否されます。Valkey または Redis OSS トラフィックを許可する最小構成は次のとおりです。
クライアント側のネットワーク ACL:
+ **インバウンドルール:**
+ ルール番号: 好ましくは拒否ルールよりも低い。
+ [タイプ]: [カスタム TCP ルール]。
+ [Protocol]: TCP
+ [Port Range]: 1024～65535
+ [ソース]: 0.0.0.0/0 (または ElastiCache クラスターサブネット用の個別ルールを作成する)
+ [許可/拒否]: 許可
+ **アウトバウンドルール:**
+ ルール番号: 好ましくは拒否ルールよりも低い。
+ [タイプ]: [カスタム TCP ルール]。
+ [Protocol]: TCP
+ [Port Range]: 6379
+ [ソース]: 0.0.0.0/0 (または ElastiCache クラスターサブネット。特定の IP を使用すると、フェイルオーバーやクラスターのスケーリング時に問題が発生する可能性があることに注意してください）
+ [許可/拒否]: 許可
ElastiCache ネットワーク ACL:
+ **インバウンドルール:**
+ ルール番号: 好ましくは拒否ルールよりも低い。
+ [タイプ]: [カスタム TCP ルール]。
+ [Protocol]: TCP
+ [Port Range]: 6379
+ [ソース]: 0.0.0.0/0 (または ElastiCache クラスターサブネット用の個別ルールを作成する)
+ [許可/拒否]: 許可
+ **アウトバウンドルール:**
+ ルール番号: 好ましくは拒否ルールよりも低い。
+ [タイプ]: [カスタム TCP ルール]。
+ [Protocol]: TCP
+ [Port Range]: 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` はすべての vCPUs 全体の使用率を提供します。複数の vCPU を持つノードは、通常、`CPUUtilization` と `EngineCPUUtilization` で異なる値を持ち、ここで 2 番目が一般的に高くなります。高い `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 スリーウェイハンドシェイクは、全体的な応答時間に悪影響を及ぼします。
1 分あたり数千の `NewConnections` がある ElastiCache ノードは、最適ではない、接続が少数のコマンドのみで作成および使用されることを示します。確立された接続を維持し、新しいオペレーションのために接続を再使用することがベストプラクティスです。これは、クライアントアプリケーションが接続プーリングまたは永続的な接続をサポートし、適切に実装している場合に可能です。接続プーリングでは、`currConnections` の数には大きなバリエーションがないので、`NewConnections` をできる限り低くする必要があります。Valkey または Redis OSS は、少数の currConnections で最適なパフォーマンスを提供します。CurrConnection を数十または数百のオーダーで維持すると、クライアントバッファのような個別の接続や、接続に役立つ CPU サイクルをサポートするためのリソースの使用量が最小限になります。
+ ネットワークスループット:
+ 帯域幅の決定: ElastiCache ノードのネットワーク帯域幅は、ノードサイズに比例します。アプリケーションの特性が異なるため、結果はワークロードに応じて異なる場合があります。たとえば、小さなリクエストの割合が高いアプリケーションは、ネットワークのスループットよりも CPU 使用率に影響を及ぼす傾向がありますが、キーが大きいほどネットワーク使用率が高くなります。そのため、制限をよりよく理解するために、実際のワークロードでノードをテストすることをお勧めします。
アプリケーションからの負荷をシミュレートすると、より正確な結果が得られます。ただし、ベンチマークツールは、制限についての良いアイデアを提供することができます。
+ リクエストが主に読み取りの場合、読み取りオペレーションでレプリカを使用すると、プライマリノードの負荷が軽減されます。ユースケースが主に書き込みの場合、多くのレプリカを使用するとネットワークの使用が増大します。プライマリノードに書き込まれるすべてのバイトについて、N バイトがレプリカに送信され、ここで N はレプリカの数になります。書き込み集中的なワークロードでのベストプラクティスは、クラスターモードが有効の ElastiCache for Redis OSS を使用することです。これにより、書き込みを複数のシャード間でバランスさせたり、より多くのネットワーク機能があるノードタイプにスケールアップしたりできます。
+ CloudWatch メトリクスの `NetworkBytesIn` と `NetworkBytesOut` は、ノードに出入りするデータ量をそれぞれ提供します。`ReplicationBytes` は、データ複製専用のトラフィックです。
詳細については、「[ネットワーク関連の制限](#Network-limits)」を参照してください。
+ 複雑なコマンド: Redis OSS コマンドは単一のスレッドで提供されます。つまり、リクエストは順番に処理されます。単一のスローコマンドは、他のリクエストや接続に影響を及ぼし、タイムアウトが発生する可能性があります。複数の値、キー、またはデータ型に作用するコマンドの使用は、慎重に行う必要があります。接続は、パラメータの数や入出力値のサイズに応じて、ブロックまたは終了できます。
評判の悪い例は、`KEYS` コマンドです。これは、指定されたパターンを検索するキースペース全体をスイープし、その実行中に他のコマンドの実行をブロックします。Redis OSS は、コマンドの複雑さを記述するために「Big O」表記法を使用しています。
キーコマンドには O(N) 時間の複雑さがあり、ここで N はデータベース内のキーの数になります。したがって、キーの数が多いほど、コマンドは遅くなります。`KEYS` は、さまざまな方法で問題を引き起こす可能性があります。検索パターンが使用されていない場合、コマンドは利用可能なすべてのキー名を返します。数千または数百万の項目を含むデータベースでは、巨大な出力が作成され、ネットワークバッファがフラッディングします。
検索パターンを使用すると、パターンに一致するキーのみがクライアントに戻ります。ただし、エンジンはキースペース全体のスイープを続けるので、コマンドを完了する時間は同じになります。
`KEYS` の代替は、`SCAN` コマンドです。これは、キースペースを反復し、特定の数の項目の反復を制限して、エンジン上の長引くブロックを回避します。
スキャンには `COUNT` パラメータがあり、反復ブロックのサイズを設定するために使用されます。デフォルト値は 10 (1 回の反復あたり 10 個のアイテム) です。
データベース内の項目数に応じて、小さな `COUNT` 値のブロックは、フルスキャンを完了するために多くの反復を必要とし、値を大きくすると、各反復でエンジンをビジー状態でより長く維持します。小さなカウント値は大きなデータベースで `SCAN` をより遅くしますが、値を大きくすると `KEYS` で説明されたものと同じ問題が生じる可能性があります。
例として、10 のカウント値がある `SCAN` コマンドの実行は、100 万個のキーがあるデータベースでの 100,000 回の繰り返しを必要とします。平均ネットワークラウンドトリップ時間が 0.5 ミリ秒の場合、リクエストの転送に約 50,000 ミリ秒（50 秒）が費やされます。
一方、カウント値が 100,0000 であった場合、1 回の反復が必要で、転送に費やされる時間はわずか 0.5 ミリ秒です。ただし、コマンドがすべてのキースペースのスイープを終了するまで、エンジンは他のオペレーションのために完全にブロックされます。
`KEYS` に加えて、いくつかの他のコマンドは、正しく使用されない場合、潜在的に有害になります。すべてのコマンドのリストとそれぞれの時間の複雑さを確認するには、「[Valkey and Redis OSS commands](https://valkey.io/commands)」にアクセスしてください。
潜在的な問題の例:
+ Lua スクリプト: Redis OSS は組み込み Lua インタプリタを提供し、サーバー側でのスクリプトの実行を可能にします。Valkey および Redis OSS の Lua スクリプトはエンジンレベルで実行され、定義上アトミックです。つまり、スクリプトの実行中に他のコマンドやスクリプトは実行できません。Lua スクリプトは、複数のコマンド、意思決定アルゴリズム、データ解析などをエンジン上で直接実行する可能性を提供します。スクリプトのアトミック性とアプリケーションのオフロードの機会は魅力的ですが、スクリプトは小さなオペレーションでは注意を払って使用する必要があります。ElastiCache では、Lua スクリプトの実行時間は 5 秒に制限されています。キースペースに書き込まれていないスクリプトは、5 秒後に自動的に終了します。データの破損や不整合を避けるため、スクリプトの実行が 5 秒以内に完了せず、実行中に書き込みがあった場合、ノードはフェイルオーバーします。[トランザクション](https://valkey.io/topics/transactions)は、Redis OSS の複数の関連するキー変更の一貫性を保証する代替手段です。トランザクションは、コマンドのブロックの実行を可能にし、既存のキーの変更を監視します。トランザクションの完了前に監視キーのいずれかが変更された場合、すべての変更は破棄されます。
+ アイテムの一括削除: `DEL` コマンドは、削除するキー名である複数のパラメータを受け入れます。削除オペレーションは同期的であり、パラメータのリストが大きい場合、または大きなリスト、セット、ソートされたセット、またはハッシュ (いくつかのサブ項目を保持するデータ構造) が含まれている場合、多くの CPU 時間がかかります。言い換えれば、単一のキーを削除しても、多くの要素がある場合、多くの時間がかかることがあります。`DEL` の代替は `UNLINK` です。これは、Redis OSS 4 以降で利用可能な非同期コマンドです。いつでも可能な限り、`DEL` が `UNLINK` より優先される必要があります。ElastiCache for Redis OSS 6x 以降で、`lazyfree-lazy-user-del` パラメータを有効にすると、`DEL` コマンドが `UNLINK` のように動作するようになりました。詳細については、「[Redis OSS 6.0 パラメータの変更](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x)」を参照してください。
+ 複数のキーに作用するコマンド: `DEL` は、複数の引数を受け入れるコマンドとして前述されており、実行時間はそれに正比例します。ただし、Redis OSS には、同様に機能する多くのコマンドが用意されています。例として、`MSET` と `MGET` を使用すると、一度に複数の String キーを挿入または取得できます。これらの使用は、複数の個別の `SET` または `GET` コマンドに固有のネットワーク遅延を低減するために有益である可能性があります。ただし、パラメータの広範なリストは CPU 使用率に影響します。
CPU 使用率だけが接続の問題の原因ではありませんが、複数のキーで単一または少数のコマンドを処理するのに時間がかかりすぎると、他のリクエストが失敗し、CPU 使用率が増加する可能性があります。
キーの数とそのサイズは、コマンドの複雑さ、また結果として完了時間に影響します。
複数のキーに対して作用できるコマンドのその他の例: `HMGET`、`HMSET`、`MSETNX`、`PFCOUNT`、`PFMERGE`、`SDIFF`、`SDIFFSTORE`、`SINTER`、`SINTERSTORE`、`SUNION`、`SUNIONSTORE`、`TOUCH`、`ZDIFF`、`ZDIFFSTORE`、`ZINTER` または `ZINTERSTORE`。
+ 複数のデータ型に作用するコマンド: Redis OSS はまた、そのデータ型に関係なく、1 つまたは複数のキーに作用するコマンドを提供します。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 はハッシュ内の項目数になります。長時間実行されるコマンドを避けるために、`HSCAN` が `HKEYS` より優先される必要があります。`HDEL`、`HGETALL`、`HMGET`、`HMSET` および `HVALS` は、大きなハッシュで注意して使用する必要があるコマンドです。
+ 他の大きなデータ構造: ハッシュに加えて、他のデータ構造では CPU 集中的になる可能性があります。セット、リスト、ソートされたセット、およびハイパーログログも、そのサイズと使用されるコマンドによっては、操作に多くの時間がかかることがあります。これらのコマンドの詳細については、「[Valkey and Redis OSS commands](https://valkey.io/commands)」を参照してください。
## ネットワーク接続性の検証
DNS 解決、セキュリティグループ、ネットワーク ACL、およびルートテーブルに関連するネットワーク設定を確認した後、VPC Reachability Analyzer とシステムツールを使用して接続性を検証できます。
Reachability Analyzer は、ネットワーク接続性をテストし、すべての要件と許可が満たされているかどうかを確認します。以下のテストでは、VPC で使用可能な ElastiCache ノードの 1 つの ENI ID (Elastic Network Interface 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. 次のステップに進みます。
1. 解析パス ([https://console.aws.amazon.com/vpc/home?\$1ReachabilityAnalyzer](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer)) を作成し、次のオプションを選択します。
+ [**ソースタイプ**]: ElastiCache クライアントが Amazon EC2 インスタンスで実行されている場合は [**インスタンス**] を選択し、awsvpc ネットワーク AWS Lambda などを用いた AWS Fargate Amazon ECS などの別のサービス、およびそれぞれのリソース ID (EC2 インスタンスまたは ENI ID) を使用する場合は [**ネットワークインターフェイス**] を選択します。
+ [**送信先タイプ**]: [**ネットワークインターフェイス**] を選択し、リストから [**Elistiache ENI**] を選択します。
+ **送信先ポート**: ElastiCache for Redis OSS では 6379 を指定し、ElastiCache for Memcached では 11211 を指定します。これらはデフォルト設定で定義されたポートであり、この例では、変更されていないことを前提としています。
+ [**Protocol**]: TCP
分析パスを作成し、結果まで数分待ちます。ステータスが到達不能の場合は、解析の詳細を開き、[**解析エクスプローラ**] で、リクエストがブロックされた場所の詳細を確認してください。
到達可能性テストに合格した場合は、OS レベルでの検証に進みます。
ElastiCache サービスポートで TCP 接続を検証するには: Amazon Linux で、`Nping` はパッケージの `nmap` で利用可能で、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`: 1 秒あたりの最大パケット数を超えています。非常に小さなリクエストの高いレートに基づくワークロードは、最大帯域幅よりも前にこの制限にヒットした可能性があります。
上記のメトリクスは、ノードがネットワーク制限にヒットしていることを確認するための理想的な方法です。ただし、制限はネットワークメトリクスのプラトーによっても特定できます。
プラトーが長期間にわたって観察される場合、レプリケーションの遅れ、キャッシュで使用されるバイト数の増加、解放可能なメモリの低下、高いスワップおよび 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
```
上記のイベントは 12 月 26 日 19:26:07 (UTC) に起こり、完了までに 4.8秒（4.823ms）かかり、クライアント 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
```
短時間 (同じ分以下) での多くのスローコマンドは、懸念の理由になります。コマンドの性質と、それらを最適化する方法を確認してください (前の例を参照)。O(1) の時間の複雑さがあるコマンドが頻繁に報告される場合は、前述の CPU 使用率が高いかどうかについて他の要因を確認してください。
+ レイテンシーメトリクス: ElastiCache for Redis OSS は、さまざまなコマンドクラスの平均レイテンシーをモニタリングするための CloudWatch メトリクスを提供します。データポイントは、カテゴリ内のコマンドの実行総数を期間内の合計実行時間で割って計算されます。レイテンシーメトリクスの結果は、複数のコマンドの集合であることを理解することが重要です。1 つのコマンドで、メトリクスに大きな影響を与えずに、タイムアウトのような予期しない結果が発生する可能性があります。このような場合、スローログイベントはより正確な情報源になります。次のリストには、使用可能なレイテンシーメトリクスと、それらに影響する各コマンドが含まれています。
+ 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: 現在接続されているクライアントのリスト、およびバッファの使用状況、最後に実行されたコマンドなどの関連情報を提供します。
+ バックアップとレプリケーション: ElastiCache for Redis OSS の 2.8.22 より前のバージョンでは、フォークされたプロセスを使用してバックアップを作成し、レプリカとの完全同期を処理します。このメソッドは、書き込み集中的なユースケースのために多くのメモリオーバーヘッドが発生する可能性があります。
ElastiCache Redis OSS 2.8.22 以降、AWS は、フォークレスなバックアップおよびレプリケーションの方法を導入しました。新しい方法は、障害を防ぐために書き込みを遅らせる場合があります。どちらの方法でも、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 (Publish/Subscribe) クライアントのバッファを制御します。
+ 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` のようなオペレーティングシステムツールによるリアルタイムの監視が必要です。
+ ネットワーク
+ インスタンスの機能に応じて、ネットワークスループットが許容可能な値未満であるかどうかを確認してください。詳細については、「[Amazon EC2 のインスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。
+ `ena` 拡張ネットワークドライバーのインスタンスで、タイムアウトまたは超えられた制限がないか [[ENA 統計](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`: 1 秒あたりの過剰なパケット比率のためにドロップされたパケット数。PPS 制限は、ネットワークトラフィックが 1 秒あたり数千または数百万の非常に小さなリクエストで構成されている場合にヒットする可能性があります。ElastiCache トラフィックは、`GET` の代わりに `MGET` のような一度に複数のオペレーションを実行するパイプラインやコマンドを介してネットワークパケットをより効果的に利用できるように最適化できます。
## 1 つのリクエストを完了するのにかかった時間の解読
+ ネットワーク上: `Tcpdump` および `Wireshark` (コマンドラインでは tshark) は、リクエストがネットワークを走行し、ElastiCache エンジンをヒットしてリターンを得るのにかかった時間を理解するための便利なツールです。次の例では、次のコマンドで作成された 1 つのリクエストを強調表示します。
```
$ 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 スリーウェイハンドシェイクが 222 マイクロ秒 (918091～917869) で完了し、ping コマンドが送信され、173 マイクロ秒 (918295～918122) で返されたことを確認できます。
リクエストから接続を閉じるまで、438 マイクロ秒 (918307～917869) かかりました。これらの結果では、ネットワークとエンジンの応答時間が良好であることを確認し、調査は他のコンポーネントに焦点を当てることができます。
+ オペレーティングシステム上: `Strace` は、OS レベルでのタイムギャップを特定するのに役立ちます。実際のアプリケーションの分析では、より広範で特殊なアプリケーションプロファイラやデバッガを使用することをお勧めします。次の例は、基本オペレーティングシステムコンポーネントが予期したとおりに動作しているかどうかを示しています。そうでない場合、さらに調査が必要になることがあります。同じ Redis OSS `PING` コマンドを `strace` で使用すると、次の結果が得られます。
```
$ 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 のインスタンス化と名前解決 (697712 から 717890 まで) には多くの時間 (約 20ms) がかかりました。その後、TCP ソケットの作成には 2ms (745659 から 747858)、リクエストに対する応答の送信と受信には 0.4ms (747858 から 748330) が必要でした。
## 関連トピック
+ [ElastiCache のベストプラクティスとキャッシュ戦略](BestPractices.md)