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: 自動スケーリングは ElastiCache クラスターのパフォーマンスを向上させるのにどのように役立つか。

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

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

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

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

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

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

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

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

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

  • 〔最良] ElastiCache for Valkey および Redis OSS ワークロードでは、 などの計算コストの高いコマンドの名前を変更してKEYS、本番クラスターでブロッキングコマンドを実行するユーザーの能力を制限します。

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

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

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

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

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

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

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

  • [リソース]:

PE 2: ElastiCache クラスターノード間で作業をどのように分散するか。

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

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

  • [必須] クライアントを適切な ElastiCache エンドポイントに接続します。

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

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

  • 〔さらに良い] ElastiCache for Valkey および Redis OSS クラスターモードが有効なクラスターを活用して、スケーラビリティを向上させます。

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

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

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

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

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

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

    • Valkey 以降では ElastiCache エンジン 7.2、Redis OSS 以降では ElastiCache バージョン 6 はすべて、サーバー支援のクライアント側のキャッシュをサポートしています。これにより、アプリケーションはキーが変更されるのを待ってから、ElastiCache にネットワークコールバックを行うことができます。

  • [リソース]:

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

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

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

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

    [リソース]:

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

    [リソース]:

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

    [リソース]:

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

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

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

  • [必須] ElastiCache クラスターへの接続を積極的に管理します。

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

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

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

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

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

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

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

  • [リソース]:

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

質問レベルの紹介: ワークロードにはさまざまな要件があり、クラスターノードがメモリ消費量の上限に近づいたときに予想される動作も異なります。ElastiCache には、これらの状況を処理するためのさまざまなポリシーがあります。

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

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

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

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

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

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

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

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

  • [リソース]:

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

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

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

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

    [リソース]:

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

    [リソース]:

  • [最良] API を使用すると、クラスター内のデータモデルを GUI で表示できます。

    [リソース]:

PE 7: 実行速度が遅いコマンドをどのように Amazon ElastiCache クラスターに記録するか。

質問レベルの紹介: 実行時間の長いコマンドのキャプチャ、集約、通知によるパフォーマンスチューニングのメリット。コマンドの実行に必要な時間を把握することで、パフォーマンスを低下させているコマンド、またエンジンの最適な実行を妨げるコマンドを特定できます。ElastiCache には、この情報を Amazon CloudWatch または Amazon Kinesis Data Firehose に転送する機能もあります。

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

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

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

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

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

  • [最良] CloudWatch または Kinesis Data Firehose の機能を活用します。

    • CloudWatch、CloudWatch 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 メモリに保存する必要がなくなります。

  • [リソース]:

PE8: 自動スケーリングは ElastiCache クラスターのパフォーマンスを向上させるのにどのように役立つか。

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

質問レベルのメリット: ワークロードの急増を把握し、計画を立てることで、キャッシュのパフォーマンスと事業継続性を確実に向上させることができます。ElastiCache Auto Scaling は CPU/メモリ使用率を継続的にモニタリングし、クラスターが希望するパフォーマンスレベルで動作していることを確認します。

  • 〔必須] ElastiCache for Valkey または Redis OSS のクラスターを起動する場合：

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

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

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

    [リソース]:

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

    [リソース]:

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

    [リソース]:

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

    [リソース]: