翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon ElastiCache Well-Architected レンズのパフォーマンス効率の柱
<a name="PerformanceEfficiencyPillar"></a>

パフォーマンス効率の柱は、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 クラスターのパフォーマンスをどのようにモニタリングするか。
<a name="PerformanceEfficiencyPillarPE1"></a>

**質問レベルの紹介:** 既存のモニタリングメトリクスを理解することで、現在の使用率を特定できます。適切にモニタリングすることで、クラスターのパフォーマンスに影響を与える潜在的なボトルネックを特定できます。

**質問レベルのメリット:** クラスターに関連するメトリクスを理解することは、レイテンシーの削減とスループットの向上につながる最適化手法の指針となります。
+ **[必須]** ワークロードのサブセットを使用したベースラインパフォーマンスのテスト。
  + 負荷テストなどのメカニズムを使用して、実際のワークロードのパフォーマンスをモニタリングする必要があります。
  + これらのテストを実行しながら 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 クラスターノード間で作業をどのように分散するか。
<a name="PerformanceEfficiencyPillarPE2"></a>

**質問レベルの紹介:** アプリケーションを 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: キャッシュワークロードの場合、キャッシュの有効性とパフォーマンスをどのように追跡して報告するか。
<a name="PerformanceEfficiencyPillarPE3"></a>

**質問レベルの紹介:** キャッシュは 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: ワークロードがどのようにしてネットワークリソースと接続の使用を最適化するか。
<a name="PerformanceEfficiencyPillarPE4"></a>

**質問レベルの紹介:** 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: キーの削除および/またはエビクションをどのように管理しているか。
<a name="PerformanceEfficiencyPillarPE5"></a>

**質問レベルの紹介:** ワークロードにはさまざまな要件があり、クラスターノードがメモリ消費量の上限に近づいたときに予想される動作も異なります。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 のデータをどのようにモデル化して操作するか。
<a name="PerformanceEfficiencyPillarPE6"></a>

**質問レベルの紹介:** 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 クラスターに記録するか。
<a name="PerformanceEfficiencyPillarPE7"></a>

**質問レベルの紹介:** 実行時間の長いコマンドのキャプチャ、集約、通知によるパフォーマンスチューニングのメリット。コマンドの実行に必要な時間を把握することで、パフォーマンスを低下させているコマンド、またエンジンの最適な実行を妨げるコマンドを特定できます。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 クラスターのパフォーマンスを向上させるのにどのように役立つか。
<a name="PerformanceEfficiencyPillarPE8"></a>

**質問レベルの紹介:** 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)