一般的なトラブルシューティング手順とベストプラクティス

接続の問題

ElastiCache キャッシュに接続できない場合は、次のいずれかを検討してください。

1. TLS の使用: ElastiCache エンドポイントに接続しようとしたときに接続がハングしている場合、クライアントで TLS を使用していない可能性があります。 ElastiCache サーバーレスを使用している場合、転送中の暗号化は常に有効になります。クライアントが TLS を使用してキャッシュに接続していることを確認します。TLS 対応キャッシュへの接続の詳細については、「」を参照してください。

2. VPC: ElastiCache キャッシュには、VPC 内からのみアクセスできます。キャッシュとキャッシュにアクセスする EC2 インスタンスが同じ VPC に作成 ElastiCache されていることを確認します。または、EC2 インスタンスが存在する VPC とキャッシュを作成する VPC 間の VPC ピアリングを有効にする必要があります。

3. セキュリティグループ: ElastiCache は、セキュリティグループを使用してキャッシュへのアクセスを制御します。以下の点を考慮します。

   1. ElastiCache キャッシュで使用されるセキュリティグループが EC2 インスタンスからのインバウンドアクセスを許可していることを確認します。セキュリティグループでインバウンドルールを正しく設定する方法については、こちらを参照してください。

   2. ElastiCache キャッシュで使用されるセキュリティグループがキャッシュのポート (サーバーレスの場合は 6379 および 6380、独自設計型の場合は 6379) へのアクセスを許可していることを確認します。 はこれらのポート ElastiCache を使用して Redis OSS コマンドを受け入れます。ポートアクセスの設定方法の詳細については、Amazon VPC セキュリティグループからキャッシュへのネットワークアクセスを許可する「」を参照してください。

Redis OSS クライアントエラー

ElastiCache Serverless には、Redis OSS クラスターモードプロトコルをサポートする Redis OSS クライアントを使用してのみアクセスできます。独自設計型クラスターには、クラスター設定に応じて、Redis OSS クライアントからどちらのモードでもアクセスできます。

クライアントで Redis OSS エラーが発生した場合は、次の点を考慮してください。

1. クラスターモード: SELECT Redis OSS コマンドで CROSSLOT エラーまたはエラーが発生した場合、Redis OSS クラスタープロトコルをサポートしていない Redis OSS クライアントを使用してクラスターモードが有効なキャッシュにアクセスしようとしている可能性があります。 ElastiCache Serverless は、Redis OSS クラスタープロトコルをサポートする Redis OSS クライアントのみをサポートします。「クラスターモードが無効」 (CMD) で Redis OSS を使用する場合は、独自のクラスターを設計する必要があります。

2. CROSSLOT エラー: ERR CROSSLOT Keys in request don't hash to the same slot エラーが発生した場合、クラスターモードキャッシュの同じスロットに属さないキーにアクセスしようとしている可能性があります。注意点として、 ElastiCache Serverless は常にクラスターモードで動作します。複数のキーを含むマルチキーオペレーション、トランザクション、または Lua スクリプトは、関連するすべてのキーが同じハッシュスロットにある場合にのみ許可されます。

Redis OSS クライアントの設定に関するその他のベストプラクティスについては、このブログ記事「」を参照してください。

ElastiCache Serverless での高レイテンシーのトラブルシューティング

ワークロードのレイテンシーが高いと思われる場合は、 SuccessfulReadRequestLatencyおよび CloudWatch SuccessfulWriteRequestLatencyメトリクスを分析して、レイテンシーが ElastiCache Serverless に関連しているかどうかを確認できます。これらのメトリクスは、 ElastiCache サーバーレスの内部にあるレイテンシーを測定します。クライアント側のレイテンシーと、クライアントと ElastiCache サーバーレスエンドポイント間のネットワークトリップ時間は含まれません。

クライアント側のレイテンシーのトラブルシューティング

クライアント側でレイテンシーが増加していることに気付いたが、それに対応する CloudWatch SuccessfulReadRequestLatencyおよびサーバー側のレイテンシーを測定するSuccessfulWriteRequestLatencyメトリクスの増加がない場合は、次の点を考慮してください。

• セキュリティグループがポート 6379 および 6380:Serverless へのアクセスを許可 ElastiCache していることを確認します。プライマリエンドポイントには 6379 ポートを使用し、リーダーエンドポイントには 6380 ポートを使用します。一部のクライアントは、アプリケーションがレプリカからの読み取り機能を使用していない場合でも、新しい接続ごとに両方のポートへの接続を確立します。セキュリティグループが両方のポートへのインバウンドアクセスを許可していない場合、接続確立に時間がかかることがあります。ポートアクセスの設定方法の詳細については、「」を参照してください。

サーバー側のレイテンシーのトラブルシューティング

変動や時折のスパイクが懸念される原因になることはありません。ただし、Average統計が急激な増加を示し、持続する場合は、 AWS Health Dashboard と Personal Health Dashboard で詳細を確認する必要があります。必要に応じて、 でサポートケースを開くことを検討してください AWS Support。

レイテンシーを減らすには、次のベストプラクティスと戦略を検討してください。

• レプリカからの読み取りを有効にする: アプリケーションで許可されている場合は、Redis OSS クライアントの「レプリカからの読み取り」機能を有効にして、読み取りをスケーリングし、レイテンシーを短縮することをお勧めします。有効にすると、 ElastiCache Serverless はクライアントと同じアベイラビリティーゾーン (AZ) にあるレプリカキャッシュノードに読み取りリクエストをルーティングしようとします。これにより、AZ 間のネットワークレイテンシーを回避できます。クライアントでレプリカからの読み取り機能を有効にすると、アプリケーションが結果整合性をデータに受け入れることを意味します。キーに書き込んだ後に読み取りを試みると、アプリケーションが古いデータを受信することがあります。

• アプリケーションがキャッシュと同じ AZs にデプロイされていることを確認します。アプリケーションがキャッシュと同じ AZs にデプロイされていない場合、クライアント側のレイテンシーが高くなることがあります。サーバーレスキャッシュを作成すると、アプリケーションがキャッシュにアクセスするサブネットを指定でき、 ElastiCache サーバーレスはそれらのサブネットに VPC エンドポイントを作成します。アプリケーションが同じ AZs にデプロイされていることを確認します。そうしないと、キャッシュにアクセスするときにアプリケーションにクロス AZ ホップが発生し、クライアント側のレイテンシーが高くなる可能性があります。

• 接続の再利用: ElastiCache サーバーレスリクエストは、RESP プロトコルを使用した TLS 対応 TCP 接続を介して行われます。接続の開始 (設定されている場合は接続の認証を含む) には時間がかかり、最初のリクエストのレイテンシーが通常よりも長くなります。既に初期化された接続を介したリクエストは、 ElastiCacheの一貫した低レイテンシーを実現します。このため、接続プーリングを使用するか、既存の Redis OSS 接続を再利用することを検討する必要があります。

• スケーリング速度: ElastiCache サーバーレスは、リクエストレートの増加に応じて自動的にスケーリングします。 ElastiCache サーバーレスがスケーリングする速度よりも速く、リクエストレートが突然大きく増加すると、レイテンシーがしばらく長くなる可能性があります。 ElastiCache サーバーレスは通常、サポートされるリクエストレートを迅速に増加させ、リクエストレートの 2 倍になるまでに最大 10～12 分かかります。

• 長時間実行されるコマンドの検査: Lua スクリプトや大規模なデータ構造でのコマンドなど、一部の Redis OSS コマンドは長時間実行されることがあります。これらのコマンドを識別するために、 はコマンドレベルのメトリクス ElastiCache を発行します。ElastiCache Serverless では、BasedECPUsメトリクスを使用できます。

• スロットリングされたリクエスト: ElastiCache Serverless でリクエストがスロットリングされると、アプリケーションでクライアント側のレイテンシーが増加する可能性があります。Serverless でリクエストがスロットリングされると、 ElastiCache Serverless ThrottledRequests メトリクスが増加します。 ElastiCache スロットリングされたリクエストのトラブルシューティングについては、以下のセクションを参照してください。

• キーとリクエストの均一な分散: ElastiCache (Redis OSS) では、スロットあたりのキーまたはリクエストの分散が不均等になると、ホットスロットになり、レイテンシーが増加する可能性があります。 ElastiCache Serverless は、単純な SET/GET コマンドを実行するワークロードで、1 つのスロットで最大 30,000 ECPUs/秒 (レプリカからの読み取りを使用する場合、90,000 ECPUs/秒) をサポートします。スロット間でキーとリクエストの分散を評価し、リクエストレートがこの制限を超えた場合は統一された分散を確保することをお勧めします。

ElastiCache Serverless でのスロットリングの問題のトラブルシューティング

サービス指向アーキテクチャや分散システムでは、API 呼び出しが各種サービスコンポーネントによって処理される速度を制限することをスロットリングと呼びます。これにより、スパイクが滑らかになり、コンポーネントのスループットの不一致が制御され、予期しない運用イベントが発生した場合のより予測可能な復旧が可能になります。 ElastiCache Serverless はこれらのタイプのアーキテクチャ向けに設計されており、ほとんどの Redis OSS クライアントにはスロットリングされたリクエストの再試行が組み込まれています。ある程度のスロットリングはアプリケーションにとって必ずしも問題とはなりませんが、データワークフローのレイテンシーの影響を受けやすい部分を継続的にスロットリングすると、ユーザーエクスペリエンスに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。

Serverless でリクエストがスロットリングされると、 ElastiCache Serverless ThrottledRequests メトリクスが増加します。 ElastiCache スロットリングされたリクエストの数が多い場合は、次の点を考慮してください。

• スケーリング速度: ElastiCache サーバーレスは、より多くのデータを取り込むか、リクエストレートを上げると自動的にスケーリングします。アプリケーションが ElastiCache サーバーレスのスケーリング速度よりも速くスケールすると、リクエストがスロットリングされ、 ElastiCache サーバーレスはワークロードに合わせてスケーリングされます。 ElastiCache サーバーレスは通常、ストレージサイズをすばやく増やすことができ、キャッシュ内のストレージサイズが 2 倍になるまでに最大 10～12 分かかります。

• キーとリクエストの均一な分散: ElastiCache (Redis OSS) では、スロットあたりのキーまたはリクエストの不均等な分散により、ホットスロットが発生する可能性があります。1 つのスロットへのリクエストレートが 30,000 ECPUs/秒を超える場合、シンプルな SET/GET コマンドを実行するワークロードでホットスロットがリクエストのスロットリングを引き起こす可能性があります。

• レプリカから読み取る: アプリケーションで許可されている場合は、「レプリカから読み取る」機能の使用を検討してください。ほとんどの Redis OSS クライアントは、読み取りをレプリカノードに転送するように「読み取りをスケーリング」するように設定できます。この機能により、読み取りトラフィックをスケーリングできます。さらに、 ElastiCache サーバーレスはレプリカリクエストからの読み取りをアプリケーションと同じアベイラビリティーゾーンのノードに自動的にルーティングするため、レイテンシーが低くなります。レプリカからの読み取りを有効にすると、シンプルな SET/GET コマンドを使用するワークロードに対して、1 つのスロットで最大 90,000 ECPUs/秒を実現できます。

関連トピック

• その他のトラブルシューティング手順

• ElastiCache ベストプラクティスとキャッシュ戦略