翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 のベストプラクティスとキャッシュ戦略](BestPractices.md)