Amazon ElastiCache Well-Architected レンズのパフォーマンス効率の柱 - Amazon ElastiCache
PE 1: Amazon ElastiCache クラスターのパフォーマンスをどのようにモニタリングしますか？PE 2: ElastiCache クラスターノード全体にどのように作業を分散していますか？PE 3: キャッシュワークロードの場合、キャッシュの有効性とパフォーマンスをどのように追跡して報告するか。PE 4: ワークロードがどのようにしてネットワークリソースと接続の使用を最適化するか。PE 5: キーの削除および/またはエビクションをどのように管理しているか。PE 6: のデータをどのようにモデル化して操作しますか ElastiCache？ PE 7: Amazon ElastiCache クラスターで実行が遅いコマンドを記録するにはどうすればよいですか？PE8: Auto Scaling はElastiCache クラスターのパフォーマンスを向上させる上でどのように役立ちますか？

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

Amazon ElastiCache Well-Architected レンズのパフォーマンス効率の柱

パフォーマンス効率の柱は、IT リソースとコンピューティングリソースを効率的に使用することに重点を置いています。主なトピックには、ワークロード要件に基づいた適切なリソースの種類とサイズの選択、パフォーマンスの監視、ビジネスニーズの変化に応じて効率を維持するための情報に基づいた意思決定が含まれます。

PE 1: Amazon ElastiCache クラスターのパフォーマンスをどのようにモニタリングしますか？

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

質問レベルのメリット: クラスターに関連するメトリクスを理解することは、レイテンシーの削減とスループットの向上につながる最適化手法の指針となります。

  • [必須] ワークロードのサブセットを使用したベースラインパフォーマンスのテスト。

    • 負荷テストなどのメカニズムを使用して、実際のワークロードのパフォーマンスをモニタリングする必要があります。

    • これらのテストの実行中に CloudWatch メトリクスをモニタリングして、使用可能なメトリクスを理解し、パフォーマンスベースラインを確立します。

  • 〔ベスト] ElastiCache (Redis OSS) ワークロードの場合、 などの計算コストの高いコマンドの名前を変更してKEYS、ユーザーが本番クラスターでブロッキングコマンドを実行する機能を制限します。

    • ElastiCache エンジン 6.x を実行している (Redis OSS) ワークロードでは、ロールベースのアクセスコントロールを活用して特定のコマンドを制限できます。コマンドへのアクセスは、 AWS コンソールまたは でユーザーとユーザーグループを作成しCLI、ユーザーグループを ElastiCache (Redis OSS) クラスターに関連付けることで制御できます。Redis OSS6 RBACでは、 を有効にすると、「-@dangerous」を使用できSORT、そのユーザーの KEYS、MONITOR、 などの高価なコマンドは許可されません。

    • エンジンバージョン 5.x では、 ElastiCache (Redis OSS) クラスターrename-commandsパラメータグループの パラメータを使用してコマンドの名前を変更します。

  • [さらに良い] 処理が遅いクエリを分析し、最適化手法を検討します。

    • ElastiCache (Redis OSS) ワークロードについては、スローログを分析してクエリの詳細を確認してください。例えば、valkey-cli slowlog get 10 コマンドを使用して、遅延のしきい値 (デフォルトは 10 秒) を超えた直近の 10 個のコマンドを表示できます。

    • 特定のクエリは、複雑な ElastiCache (Redis OSS) データ構造を使用してより効率的に実行できます。例えば、数値形式の範囲検索の場合、アプリケーションはソートセットを使用して単純な数値インデックスを実装できます。これらのインデックスを管理することで、データセットに対して実行されるスキャン数を減らし、より高いパフォーマンス効率でデータを返すことができます。

    • ElastiCache (Redis OSS) ワークロードの場合、 redis-benchmarkは、クライアントの数やデータのサイズなどのユーザー定義の入力を使用して、さまざまなコマンドのパフォーマンスをテストするためのシンプルなインターフェイスを提供します。

    • Memcached はシンプルなキーレベルコマンドのみをサポートしているため、クライアントのクエリを処理するためにキースペースを繰り返し処理しないように、追加のキーをインデックスとして作成することを検討してください。

  • [リソース]:

PE 2: ElastiCache クラスターノード全体にどのように作業を分散していますか？

質問レベルの紹介: アプリケーションが Amazon ElastiCache ノードに接続する方法は、クラスターのパフォーマンスとスケーラビリティに影響を与える可能性があります。

質問レベルのメリット: クラスター内の利用可能なノードを適切に使用することで、利用可能なリソース全体に作業が分散されます。次の手法は、リソースのアイドル状態を回避するのにも役立ちます。

  • 〔必須] クライアントに適切な ElastiCache エンドポイントに接続してもらいます。

    • ElastiCache (Redis OSS) は、使用中のクラスターモードに基づいて異なるエンドポイントを実装します。クラスターモードが有効になっている場合、 ElastiCache は設定エンドポイントを提供します。クラスターモードが無効の場合、 ElastiCache は、通常書き込みに使用されるプライマリエンドポイントと、レプリカ間で読み取りのバランスをとるためのリーダーエンドポイントを提供します。これらのエンドポイントを正しく実装すると、パフォーマンスが向上し、オペレーションのスケーリングが容易になります。特定の要件がない限り、個々のノードエンドポイントへの接続は回避します。

    • マルチノード Memcached クラスターの場合、 は Auto Discovery を有効にする設定エンドポイント ElastiCache を提供します。キャッシュノード全体に作業を均等に分散するには、ハッシュアルゴリズムの使用をお勧めします。多くの Memcached クライアントライブラリは整合性のあるハッシュを実装しています。使用中のライブラリのドキュメントを参照し、整合性のあるハッシュをサポートするかどうかと、その実装方法について確認してください。これらの機能の実装の詳細については、こちらをご覧ください。

  • 〔より良い] （ ElastiCache Redis OSS) クラスターモードを有効にしてスケーラビリティを向上させます。

    • ElastiCache (Redis OSS) (クラスターモードが有効) クラスターは、オンラインスケーリングオペレーション (アウト/インおよびアップ/ダウン) をサポートし、シャード間でデータを動的に分散するのに役立ちます。設定エンドポイントを使用すると、クラスター対応クライアントがクラスタートポロジーの変化に確実に適応できるようになります。

    • (Redis OSS) ElastiCache （クラスターモードが有効) クラスターで使用可能なシャード間でハッシュスロットを移動することで、クラスターのバランスを再調整することもできます。これにより、使用可能なシャード間で作業をより効率的に分散できます。

  • [さらに良い] ワークロード内のホットキーを特定して修正するための戦略を実装します。

    • リスト、ストリーム、セットなどの多次元 Valkey または Redis OSS データ構造の影響を考慮します。これらのデータ構造は、単一のノードに存在する単一のキーに保存されます。多次元キーが非常に大きい場合、他のデータ型よりも多くのネットワーク容量とメモリを使用する可能性があり、そのノードが不均衡に使用される可能性があります。可能な場合は、データアクセスを多数の個別のキーに分散するようにワークロードを設計します。

    • ワークロード内のホットキーは、使用中のノードのパフォーマンスに影響を与える可能性があります。 ElastiCache (Redis OSS) ワークロードの場合、LFUmax-memory ポリシーvalkey-cli --hotkeysが設定されている場合、 を使用してホットキーを検出できます。

    • ホットキーを複数のノードに複製して、アクセス権を均等に分散することを検討してください。このアプローチでは、クライアントが複数のプライマリノードに書き込む必要があり (Valkey または Redis OSSノード自体はこの機能を提供しません）、元のキー名に加えて、読み取るキー名のリストを保持する必要があります。

    • ElastiCache Valkey 7.2 以降および Redis OSSバージョン 6 以降では、サーバー支援のクライアント側のキャッシュ がサポートされています。これにより、アプリケーションは へのネットワーク呼び出しを元に戻す前に、キーの変更を待つことができますElastiCache。

  • [リソース]:

PE 3: キャッシュワークロードの場合、キャッシュの有効性とパフォーマンスをどのように追跡して報告するか。

質問レベルの紹介: キャッシュは でよく発生するワークロードであり ElastiCache 、キャッシュの有効性とパフォーマンスを管理する方法を理解することが重要です。

質問レベルのメリット: アプリケーションのパフォーマンスが低下する兆候が見られる場合があります。キャッシュワークロードでは、キャッシュ固有のメトリクスを使用してアプリケーションのパフォーマンスを向上させる方法を決定できることが重要です。

  • [必須] キャッシュヒットレートを経時的に測定し、追跡します。キャッシュの効率は、その「キャッシュヒットレート」によって決まります。キャッシュヒットレートは、キーヒット数の合計をヒット数とミス数の合計で割った値で定義されます。比率が 1 に近いほど、キャッシュの効率は高くなります。キャッシュヒットレートが低いのは、キャッシュミスの数が多いためです。キャッシュミスは、要求されたキーがキャッシュに見つからない場合に発生します。キーは、エビクションまたは削除されたか、有効期限が切れているか、あるいは存在したことがないため、キャッシュに存在しません。キーがキャッシュにない理由を理解し、キーをキャッシュに含めるための適切な戦略を立てます。

    [リソース]:

  • 〔必須] レイテンシーとCPU使用率の値と組み合わせてアプリケーションキャッシュのパフォーマンスを測定および収集して、 time-to-liveまたは他のアプリケーションコンポーネントを調整する必要があるかどうかを把握します。 は、データ構造ごとに集約されたレイテンシーの CloudWatch メトリクスのセット ElastiCache を提供します。これらのレイテンシーメトリクスは、 ElastiCache (Redis OSS) INFO コマンドのコマンド統計を使用して計算され、ネットワークと I/O 時間は含まれません。これは、 ElastiCache (Redis OSS) がオペレーションを処理するために消費した時間のみです。

    [リソース]:

  • [最良] ニーズに合った適切なキャッシュ戦略を選択します。キャッシュヒットレートが低いのは、キャッシュミスの数が多いためです。ワークロードがキャッシュミス数が少ないように設計されている場合 (リアルタイム通信など)、キャッシュ戦略を見直し、メモリやパフォーマンスを測定するためのクエリ計測など、ワークロードに最適な解決策を適用するのが最善です。キャッシュを入力し維持するために実装する実際の戦略は、クライアントがキャッシュする必要のあるデータとそのデータへのアクセスパターンによって決まります。例えば、ストリーミングアプリケーションのパーソナライズされた推奨とトレンドニュースの両方に同じ戦略を使用する可能性はほとんどありません。

    [リソース]:

PE 4: ワークロードがどのようにしてネットワークリソースと接続の使用を最適化するか。

質問レベルの紹介: ElastiCache (Redis OSS) と ElastiCache (Memcached) は多くのアプリケーションクライアントでサポートされており、実装は異なる場合があります。潜在的なパフォーマンスへの影響を分析するには、実施されているネットワークと接続の管理について理解する必要があります。

質問レベルのメリット: ネットワークリソースを効率的に使用することで、クラスターのパフォーマンス効率を向上させることができます。以下の推奨事項は、ネットワークの需要を減らし、クラスターのレイテンシーとスループットを向上させることができます。

  • 〔必須] ElastiCache クラスターへの接続をプロアクティブに管理します。

    • アプリケーション内の接続プーリングにより、接続の開閉により生じるクラスターのオーバーヘッドの量を減らすことができます。CurrConnections と CloudWatch を使用して Amazon の接続動作をモニタリングしますNewConnections。

    • 必要に応じてクライアント接続を適切に閉じて接続リークを回避します。接続管理戦略には、使用されていない接続を適切に閉じることや、接続タイムアウトを設定することが含まれます。

    • Memcached ワークロードの場合、memcached_connections_overhead と呼ばれる接続を処理するために確保される設定可能なメモリの量があります。

  • [さらに良い] 大きなオブジェクトを圧縮してメモリを減らし、ネットワークのスループットを向上させます。

    • データを圧縮すると、必要なネットワークスループット (Gbps) は低下しますが、データを圧縮および解凍するアプリケーションでの作業量が増えます。

    • 圧縮により、キーが消費するメモリの量も減少します。

    • アプリケーションのニーズに応じて、圧縮率と圧縮速度のトレードオフを検討してください。

  • [リソース]:

PE 5: キーの削除および/またはエビクションをどのように管理しているか。

質問レベルの紹介: ワークロードにはさまざまな要件があり、クラスターノードがメモリ消費の制限に近づいている場合に期待される動作があります。 ElastiCache （Redis OSS) には、これらの状況を処理するためのさまざまなポリシーがあります。

質問レベルのメリット: 使用可能なメモリを適切に管理し、エビクションポリシーを理解することで、インスタンスのメモリ制限を超えた場合のクラスターの動作を確実に把握できます。

  • [必須] データアクセスを実装して、どのポリシーを適用するかを評価します。クラスターでエビクションを実行するかどうか、またその方法を制御するための適切な最大メモリーポリシーを特定します。

    • エビクションは、クラスターの最大メモリーが消費され、エビクションを許可するポリシーが設定されているときに発生します。この状況でのクラスターの動作は、指定されたエビクションポリシーによって異なります。このポリシーは、 maxmemory-policy ElastiCache (Redis OSS) クラスターパラメータグループの を使用して管理できます。

    • デフォルトのポリシーは、設定された有効期限 (TTL 値) でキーを削除することでメモリをvolatile-lru解放します。最小使用頻度 (LFU) ポリシーと最近使用頻度 (LRU) ポリシーは、使用状況に基づいてキーを削除します。

    • Memcached ワークロードの場合、各ノードの立ち退きを制御するデフォルトのLRUポリシーがあります。Amazon ElastiCache クラスターのエビクションの数は、Amazon のエビクションメトリクスを使用してモニタリングできます CloudWatch。

  • [さらに良い] 削除動作を標準化してクラスターのパフォーマンスへの影響を制御し、予期しないパフォーマンスのボトルネックを回避します。

    • ElastiCache (Redis OSS) ワークロードの場合、クラスターからキーを明示的に削除すると、 UNLINKのようなものになりますDEL。指定されたキーを削除します。ただし、このコマンドは実際のメモリ再利用を別のスレッドで実行するため、ブロッキングしませんが、DEL はします。実際の削除は後に非同期で行われます。

    • ElastiCache (Redis OSS) 6.x ワークロードの場合、 DEL コマンドの動作は パラメータグループで lazyfree-lazy-user-del パラメータを使用して変更できます。

  • [リソース]:

PE 6: のデータをどのようにモデル化して操作しますか ElastiCache？

質問レベルの紹介: ElastiCache は、使用するデータ構造とデータモデルに大きく依存しますが、基盤となるデータストア (存在する場合) も考慮する必要があります。利用可能な ElastiCache (Redis OSS) データ構造を理解し、ニーズに最も適したデータ構造を使用していることを確認します。

質問レベルの利点: のデータモデリングElastiCache には、アプリケーションのユースケース、データ型、データ要素間の関係など、複数のレイヤーがあります。さらに、各 ElastiCache (Redis OSS) データ型とコマンドには、明確に文書化された独自のパフォーマンス署名があります。

  • [最良] ベストプラクティスは、意図しないデータの上書きを減らすことです。キー名の重複を最小限に抑える命名規則を使用します。従来のデータ構造の命名では、APPNAME:CONTEXT:ID、ORDER-APP:CUSTOMER:123 などの階層的な方法を使用します。

    [リソース]:

  • [Best] ElastiCache (Redis OSS) コマンドには、Big O 表記で定義される時間の複雑さがあります。このコマンドの時間の複雑さは、その影響をアルゴリズム的または数学的に表現したものです。アプリケーションに新しいデータ型を導入する際には、関連するコマンドの時間の複雑さを注意深く見直す必要があります。時間の複雑さが O (1) のコマンドは時間が一定で、入力のサイズには依存しませんが、時間の複雑さが O (N) のコマンドは時間が線形で、入力のサイズに影響されます。ElastiCache (Redis OSS) のシングルスレッド設計により、長時間の複雑なオペレーションが多いと、パフォーマンスが低下し、オペレーションがタイムアウトする可能性があります。

    [リソース]:

  • 〔最良] クラスター内のデータモデルをGUI可視化APIsするために使用します。

    [リソース]:

PE 7: Amazon ElastiCache クラスターで実行が遅いコマンドを記録するにはどうすればよいですか？

質問レベルの紹介: 実行時間の長いコマンドのキャプチャ、集約、通知によるパフォーマンスチューニングのメリット。コマンドの実行にかかる時間を理解することで、どのコマンドがパフォーマンスの低下につながるか、およびエンジンが最適に動作することをブロックするコマンドを特定できます。 ElastiCache （Redis OSS) には、この情報を Amazon CloudWatch または Amazon Kinesis Data Firehose に転送する機能もあります。

質問レベルのメリット: 専用の場所にログを記録し、処理が遅いコマンドに通知イベントを提供することは、詳細なパフォーマンス分析に役立ち、自動イベントのトリガーにも使用できます。

  • 〔必須] エンジンバージョン 6.0 以降を実行している Amazon ElastiCache (Redis OSS) で、適切に設定されたパラメータグループと、クラスターで有効になっているSLOWLOGログ記録。

    • 必要なパラメータは、エンジンバージョンの互換性が Valkey 7.2 以降、または Redis OSSバージョン 6.0 以降に設定されている場合にのみ使用できます。

    • SLOWLOG ログ記録は、コマンドのサーバー実行時間が指定された値よりも長い場合に発生します。クラスターの動作は、関連するパラメータグループのパラメータ (slowlog-log-slower-than および slowlog-max-len) によって異なります。

    • 変更は即時適用されます。

  • 〔ベスト] CloudWatch または Kinesis Data Firehose の機能を活用します。

    • 、Logs Insights CloudWatch、 CloudWatchAmazon Simple Notification Services のフィルタリングとアラーム機能を使用して、パフォーマンスモニタリングとイベント通知を実現します。

    • Kinesis Data Firehose のストリーミング機能を使用して、SLOWLOGログを永続的ストレージにアーカイブしたり、クラスターパラメータの自動調整をトリガーしたりできます。

    • JSON またはプレーンTEXT形式がニーズに最も適しているかどうかを確認します。

    • CloudWatch または Kinesis Data Firehose に発行するIAMアクセス許可を付与します。

  • [さらに良い] slowlog-log-slower-than をデフォルト以外の値に設定します。

    • このパラメータは、コマンドが低速実行コマンドとしてログに記録されるまでに、Valkey または Redis OSS エンジン内で コマンドが実行される時間を決定します。デフォルト値は 10,000 マイクロ秒 (10 ミリ秒) です。一部のワークロードでは、このデフォルト値は高すぎる場合があります。

    • アプリケーションのニーズとテスト結果に基づいて、ワークロードにより適した値を決定します。ただし、値が低すぎると、過剰なデータが生成される可能性があります。

  • [さらに良い] slowlog-max-len をデフォルト値のままにしておきます。

    • このパラメータは、任意の時点で Valkey または Redis OSSメモリにキャプチャされる低速実行コマンドの数の上限を決定します。値が 0 の場合、キャプチャは事実上無効になります。値が大きいほど、メモリに保存されるエントリの数が増え、確認する前に重要な情報がエビクションされる可能性が低くなります。デフォルト値は 128 です。

    • デフォルト値は、ほとんどのワークロードに適しています。SLOWLOG コマンドを使用して valkey-cli から拡張された時間枠でデータを分析する必要がある場合は、この値を増やすことを検討してください。これにより、より多くのコマンドを Valkey または Redis OSSメモリに残すことができます。

      CloudWatch Logs または Kinesis Data Firehose のいずれかにSLOWLOGデータを送信する場合、データは保持され、 ElastiCache システムの外部で分析できるため、実行が遅いコマンドを多数 Valkey または Redis OSSメモリに保存する必要がなくなります。

  • [リソース]:

PE8: Auto Scaling はElastiCache クラスターのパフォーマンスを向上させる上でどのように役立ちますか？

質問レベルの紹介: Valkey または Redis OSS 自動スケーリングの機能を実装することで、 ElastiCache コンポーネントは時間の経過とともに調整して、必要なシャードまたはレプリカを自動的に増減できます。これは、ターゲットトラッキングポリシーまたはスケジュールされたスケーリングポリシーのいずれかを実装することで実現できます。

質問レベルの利点: ワークロードの急増を理解し、計画することで、キャッシュのパフォーマンスと事業継続性を強化できます。 ElastiCache （Redis OSS) Auto Scaling は CPU/Memory 使用率を継続的にモニタリングし、クラスターが希望するパフォーマンスレベルで動作していることを確認します。

  • 〔必須] ElastiCache (Redis OSS) のクラスターを起動する場合：

    1. クラスターモードが有効になっていることを確認します

    2. インスタンスが自動スケーリングをサポートする特定のタイプとサイズのファミリーに属していることを確認します

    3. クラスターがグローバルデータストア、Outposts、または Local Zones で実行されていないことを確認します

    [リソース]:

  • [最良] ワークロードが読み取り中心か、または書き込み中心かを特定して、スケーリングポリシーを定義します。最高のパフォーマンスを達成するには、1 つのトラッキングメトリクスのみを使用します。自動スケーリングポリシーは、ターゲットがヒットするとスケールアウトしますが、すべてのターゲットトラッキングポリシーがスケールインできる状態になって初めてスケールインするため、ディメンションごとに複数のポリシーを設定するのは避けることをお勧めします。

    [リソース]:

  • [最良] パフォーマンスを経時的にモニタリングすることで、特定の時点でモニタリングしても気付かないようなワークロードの変化を検出できます。4 週間のクラスター使用率に対応するCloudWatch メトリクスを分析して、ターゲット値のしきい値を決定できます。選択する値が不明な場合は、サポートされる最小定義メトリクス値から開始することをお勧めします。

    [リソース]:

  • [より良い] スケーリングポリシーを策定し、可用性の問題を軽減するために、クラスターに必要なシャード/レプリカの正確な数を特定するために、予想される最小ワークロードと最大ワークロードでアプリケーションをテストすることをお勧めします。

    [リソース]: