翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
を使用した一般的なトラブルシューティング手順とベストプラクティス ElastiCache
以下のトピックでは、 の使用時に発生する可能性のあるエラーや問題のトラブルシューティングに関するアドバイスを提供します ElastiCache。ここに記載されていない問題が見つかった場合は、このページの [フィードバック] ボタンを使用して報告できます。
トラブルシューティングに関するアドバイスと一般的なサポートに関する質問への回答の詳細については、AWS ナレッジセンター
トピック
接続の問題
ElastiCache キャッシュに接続できない場合は、次のいずれかを検討してください。
の使用TLS: ElastiCache エンドポイントへの接続時にハング接続が発生している場合は、クライアントTLSで を使用していない可能性があります。 ElastiCache Serverless を使用している場合、転送中の暗号化は常に有効になります。クライアントが TLSを使用してキャッシュに接続していることを確認します。TLS 有効なキャッシュ への接続について説明します。
VPC： ElastiCache caches には、 内からのみアクセスできますVPC。キャッシュにアクセスするEC2インスタンスと ElastiCache キャッシュが同じ に作成されていることを確認しますVPC。または、EC2インスタンスが存在する VPC とキャッシュを作成する VPC 間のVPCピアリングを有効にする必要があります。
セキュリティグループ: ElastiCache セキュリティグループを使用してキャッシュへのアクセスを制御します。以下の点を考慮します。
ElastiCache キャッシュで使用されるセキュリティグループが、EC2インスタンスからのインバウンドアクセスを許可していることを確認します。セキュリティグループでインバウンドルールを正しく設定する方法については、こちらをご覧ください。
ElastiCache キャッシュで使用されるセキュリティグループがキャッシュのポート (サーバーレスの場合は 6379 と 6380、セルフ設計の場合は 6379) へのアクセスを許可していることを確認します。 はこれらのポート ElastiCache を使用して Valkey または Redis OSS コマンドを受け入れます。ポートアクセスの設定方法については、Amazon VPC セキュリティグループからキャッシュへのネットワークアクセスを許可する「」を参照してください。
接続が引き続き困難な場合は、他の手順永続的な接続の問題については、「」を参照してください。
Valkey または Redis OSSクライアントエラー
ElastiCache Serverless は、Valkey または Redis OSSクラスターモードプロトコルをサポートするクライアントを使用してのみアクセスできます。独自設計のクラスターは、クラスター設定に応じて、どちらのモードでもクライアントからアクセスできます。
クライアントでエラーが発生した場合は、次の点を考慮してください。
クラスターモード: SELECT
コマンドでCROSSLOTエラーまたはエラーが発生した場合、クラスタープロトコルをサポートしていない Valkey または Redis OSSクライアントを使用してクラスターモード対応キャッシュにアクセスしようとしている可能性があります。 ElastiCache Serverless は、Valkey または Redis OSSクラスタープロトコルをサポートするクライアントのみをサポートします。「クラスターモードが無効」 (CMD) OSSで Valkey または Redis を使用する場合は、独自のクラスターを設計する必要があります。 CROSSLOT エラー:
ERR CROSSLOT Keys in request don't hash to the same slotエラーが発生した場合、クラスターモードキャッシュの同じスロットに属していないキーにアクセスしようとしている可能性があります。念のため、 ElastiCache Serverless は常にクラスターモードで動作します。複数のキーを含むマルチキーオペレーション、トランザクション、または Lua スクリプトは、関連するすべてのキーが同じハッシュスロットにある場合にのみ許可されます。
Valkey または Redis OSSクライアントの設定に関するその他のベストプラクティスについては、このブログ記事
ElastiCache Serverless での高レイテンシーのトラブルシューティング
ワークロードのレイテンシーが高いと思われる場合は、 SuccessfulReadRequestLatencyと CloudWatch SuccessfulWriteRequestLatencyメトリクスを分析して、レイテンシーが ElastiCache Serverless に関連しているかどうかを確認することができます。これらのメトリクスは、 ElastiCache サーバーレスの内部にあるレイテンシーを測定します。クライアント側のレイテンシーと、クライアントと ElastiCache サーバーレスエンドポイント間のネットワークトリップ時間は含まれません。
クライアント側のレイテンシーのトラブルシューティング
クライアント側でレイテンシーが増加しても、サーバー側のレイテンシーを測定する CloudWatch SuccessfulReadRequestLatencyおよび SuccessfulWriteRequestLatencyメトリクスの対応する増加が見られない場合は、以下を考慮してください。
サーバー側のレイテンシーのトラブルシューティング
一部の変動や時折の急増は、懸念の原因とはなりません。ただし、Average統計が急増し、持続する場合は、 AWS Health Dashboard と Personal Health Dashboard で詳細を確認してください。必要に応じて、 でサポートケースを開くことを検討してください AWS Support。
レイテンシーを減らすために、次のベストプラクティスと戦略を検討してください。
レプリカからの読み取りを有効にする: アプリケーションで許可されている場合は、Valkey または Redis OSSクライアントの「レプリカからの読み取り」機能を有効にして、読み取りをスケーリングし、レイテンシーを低くすることをお勧めします。有効にすると、 ElastiCache Serverless はクライアントと同じアベイラビリティーゾーン (AZ) にあるレプリカキャッシュノードに読み取りリクエストをルーティングしようとします。これにより、AZ 間のネットワークレイテンシーを回避できます。クライアントでレプリカからの読み取り機能を有効にすると、アプリケーションが最終的なデータの整合性を受け入れることを意味します。キーへの書き込み後に読み取りを試みると、アプリケーションが古いデータを受信することがあります。
アプリケーションがキャッシュAZsと同じ にデプロイされていることを確認します。アプリケーションがキャッシュAZsと同じ にデプロイされていない場合、クライアント側のレイテンシーが高くなることがあります。サーバーレスキャッシュを作成すると、アプリケーションがキャッシュにアクセスするサブネットを指定でき、 ElastiCache サーバーレスはそれらのサブネットにVPCエンドポイントを作成します。アプリケーションが同じ にデプロイされていることを確認しますAZs。そうしないと、キャッシュにアクセスするときにアプリケーションにクロス AZ ホップが発生し、クライアント側のレイテンシーが高くなる可能性があります。
接続の再利用: ElastiCache サーバーレスリクエストは、RESPプロトコルを使用してTLS有効なTCP接続を介して行われます。接続の開始 (設定されている場合は接続の認証を含む) には時間がかかり、最初のリクエストのレイテンシーが通常よりも長くなります。既に初期化された接続を介したリクエストは、 ElastiCacheの一貫した低レイテンシーを提供します。このため、接続プーリングを使用するか、既存の Valkey または Redis OSS接続を再利用することを検討する必要があります。
スケーリング速度: ElastiCache Serverless は、リクエストレートの増加に応じて自動的にスケーリングされます。 ElastiCache サーバーレスがスケーリングする速度よりも速く、リクエストレートが急激に大きく増加すると、レイテンシーがしばらく長くなる可能性があります。 ElastiCache サーバーレスは通常、サポートされるリクエストレートをすばやく増加させ、リクエストレートを 2 倍にするには最大 10～12 分かかります。
長時間実行されているコマンドの検査: Lua スクリプトや大きなデータ構造のOSSコマンドなど、一部の Valkey または Redis コマンドは長時間実行されることがあります。これらのコマンドを識別するには、 コマンドレベルのメトリクス ElastiCache を発行します。ElastiCache Serverless では、
BasedECPUsメトリクスを使用できます。スロットリングされたリクエスト: ElastiCache Serverless でリクエストがスロットリングされると、アプリケーションでクライアント側のレイテンシーが増加する可能性があります。 ElastiCache Serverless でリクエストがスロットリングされると、
ThrottledRequestsElastiCache Serverless メトリクスが増加します。スロットリングされたリクエストのトラブルシューティングについては、以下のセクションを参照してください。キーとリクエストの均一な分散: Valkey と Redis ElastiCache ではOSS、スロットあたりのキーまたはリクエストの分散が不均等になると、ホットスロットが発生し、レイテンシーが長くなる可能性があります。 ElastiCache Serverless は、シンプルな SET/GET コマンドを実行するワークロードで、1 つのスロットで最大 30,000 ECPUs/秒 (レプリカからの読み取りを使用する場合、90,000 ECPUs/秒) をサポートします。スロット間でキーとリクエストの分散を評価し、リクエストレートがこの制限を超えた場合は、均一に分散させることをお勧めします。
ElastiCache Serverless でのスロットリング問題のトラブルシューティング
サービス指向アーキテクチャと分散システムでは、さまざまなサービスコンポーネントによってAPIコールが処理されるレートを制限することをスロットリングと呼びます。これにより、スパイクがスムーズになり、コンポーネントのスループットの不一致が制御され、予期しない運用イベントが発生したときにより予測可能な復旧が可能になります。 ElastiCache Serverless はこれらのタイプのアーキテクチャ向けに設計されており、ほとんどの Valkey または Redis OSSクライアントはスロットリングされたリクエストに対して再試行を組み込みます。ある程度のスロットリングはアプリケーションにとって必ずしも問題とはなりませんが、データワークフローのレイテンシーの影響を受けやすい部分を継続的にスロットリングすると、ユーザーエクスペリエンスに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。
ElastiCache Serverless でリクエストがスロットリングされると、ThrottledRequestsElastiCache Serverless メトリクスが増加します。スロットリングされたリクエストの数が多いことに気付いた場合は、次の点を考慮してください。
スケーリング速度: ElastiCache Serverless は、より多くのデータを取り込み、リクエストレートを引き上げるたびに自動的にスケーリングされます。アプリケーションが ElastiCache Serverless のスケーリング速度よりも速くスケーリングされると、リクエストがスロットリングされ、 ElastiCache Serverless はワークロードに合わせてスケーリングされます。 ElastiCache Serverless は通常、ストレージサイズをすばやく増やすことができ、キャッシュ内のストレージサイズを 2 倍にするには最大 10～12 分かかります。
キーとリクエストの均一な分散: Valkey または Redis ElastiCache ではOSS、スロットあたりのキーまたはリクエストの分散が不均等になると、ホットスロットが発生する可能性があります。単一のスロットへのリクエストレートが 30,000 ECPUs/秒を超える場合、単純な SET/GET コマンドを実行するワークロードでホットスロットを使用すると、リクエストがスロットリングされる可能性があります。
レプリカから読み取る: アプリケーションで許可されている場合は、「レプリカから読み取る」機能の使用を検討してください。ほとんどの Valkey または Redis OSSクライアントは、「スケールリード」を設定して、リードをレプリカノードに誘導できます。この機能を使用すると、読み取りトラフィックをスケーリングできます。さらに、 ElastiCache Serverless は、レプリカリクエストから読み取られたノードをアプリケーションと同じアベイラビリティーゾーンのノードに自動的にルーティングするため、レイテンシーが低くなります。レプリカからの読み取りが有効になっている場合、シンプルな ECPUs/ コマンドのワークロードに対して、1 つのスロットで最大 90,000 SET/GET秒を達成できます。
関連トピック
