DynamoDB Accelerator (DAX) クラスターでレイテンシーが大きいことに関するトラブルシューティングするにはどうすればよいですか?

解決方法

リクエストでレイテンシーが発生する理由は複数あります。レイテンシーをトラブルシューティングするには、以下の潜在的な問題をそれぞれ参照してください。

クラスターまたはノードに高い負荷がかかっている

DAX クラスターで高い負荷がかかっているクラスターまたはノードがレイテンシーの原因になることがよくあります。クライアントをクラスター URL ではなく単一ノード URL に設定している場合、このレイテンシーはさらに影響を受ける可能性があります。このケースでは、高負荷時にノードに何らかの問題が発生すると、クライアントのリクエストにレイテンシーまたはスロットリングが発生します。

単一クラスターまたはノードでの高負荷によるレイテンシーとスロットリングを解決するには、水平スケーリングまたは垂直スケーリングを使用します。

DAX クライアントの設定ミス

withMinIdleConnectionSize パラメータを小さくすると、DAX クラスター全体のレイテンシーが増加する可能性が高くなります。このパラメータは、DAX クラスターとのアイドリング接続の最小数を設定します。リクエストごとに、クライアントは利用可能なアイドル接続を使用します。利用できる接続がない場合、クライアントは新しい接続を確立します。例えば、このパラメータが 20 に設定されている場合、DAX クラスターとのアイドル接続は最低 20 個です。

クライアントは接続プールを維持します。アプリケーションが DynamoDB または DAX に API 呼び出しを行うと、クライアントは接続プールから接続をリースします。次に、クライアントは API 呼び出しを行い、接続をプールに返します。ただし、接続プールには上限があります。DAX への API 呼び出しを一度に多数行うと、接続プールの制限を超える可能性があります。この場合、一部のリクエストは、接続プールからリースを取得する前に、他のリクエストが完了するのを待つ必要があります。これにより、リクエストは接続プールレベルでキューに入れられます。その結果、アプリケーションの往復レイテンシーが増加します。

そのため、アプリケーション内で定期的に発生するトラフィックの急増を減らすために、setMinIdleConnectionSize、getMinIdleConnectionSize、および withMinIdleConnectionSize のパラメータを調整してください。これらのパラメータは DAX クラスターのレイテンシーにおいて重要な役割を果たします。API 呼び出し用にこれらを設定して、DAX が新しい接続を再確立する必要のない適切な数のアイドリング接続を使用するようにします。

アイテムのキャッシュミス

読み取りリクエストでアイテムが見つからない場合、DAX はそのリクエストを DynamoDB に送信します。DynamoDB は、結果整合性のある読み込みを使用してリクエストを処理し、アイテムを DAX に返します。DAX はそれらをアイテムキャッシュに保存し、アプリケーションに返します。基になる DynamoDB テーブルのレイテンシーが、リクエストのレイテンシーの原因となる可能性があります。

キャッシュミスは通常、次の 2 つの理由で発生します。

1.    強力な整合性のある読み込み: 同じアイテムに対する強力な整合性のある読み込みは DAX にキャッシュされません。これにより、エントリは DAX をバイパスし、DynamoDB テーブル自体から取得されるため、キャッシュミスが発生します。この問題を解決するには、結果整合性のある読み込みを行うこともできますが、DynamoDB はデータをキャッシュするために最初にデータを読み取る必要があることに注意してください。

2.    DAX のエビクションポリシー: クエリされたデータが、すでにキャッシュから削除されていると、ミスが発生します。DAX は 3 つの異なる値を使用してキャッシュエビクションを決定します。

• DAX クラスターは、Least Recently Used (LRU) アルゴリズムを使用してアイテムに優先順位を付けます。優先順位が最も低いアイテムは、キャッシュが満杯になると削除されます。
• DAX は、キャッシュでアイテムが使用可能な期間の Time-to-Live (TTL) 値を使用します。アイテムの TTL 値を超えると、そのアイテムは削除されます。
  注: デフォルトの TTL 値である 5 分を使用している場合は、TTL 時間後にデータをクエリするかどうかを確認してください。
• DAX は書き込みスルー機能を使用して、新しい値が書き込まれると古い値を削除します。これにより、DAX アイテムキャッシュを、単一の API コールを使用して基になるデータストアと整合させることができます。

アイテムの TTL 値を延長するには、「TTL 設定の構成」を参照してください。
注: 実行中の DAX インスタンスで使用中のパラメータグループを変更することはできません。

キャッシュミスは、メンテナンスパッチが DAX クラスターに適用された場合にも発生する可能性があります。このダウンタイムを減らすには、複数のノードクラスターを使用してください。

メンテナンスウィンドウ

特にクラスターのノードにソフトウェアのアップグレード、パッチ、またはシステム変更がある場合は、毎週のメンテナンスウィンドウ中にレイテンシーが発生する可能性があります。ほとんどの場合、リクエストはメンテナンスを受けていない他の利用可能なノードによって正常に処理されます。大規模なメンテナンス中にリクエスト数が多いクラスターでは、障害が発生する可能性があります。

レイテンシーや障害の可能性を減らすには、オフピーク時間にメンテナンスウィンドウを設定してください。これにより、リクエストの負荷が軽いときにクラスターをアップグレードできます。

DynamoDB テーブルのレイテンシー

書き込みオペレーションでは、データは最初に DynamoDB テーブルに書き込まれ、次に DAX クラスターに書き込まれます。データがテーブルと DAX の両方に正常に書き込まれた場合にのみ、オペレーションは成功となりとなります。基になる DynamoDB テーブルのレイテンシーが、リクエストのレイテンシーの原因となる可能性があります。Amazon DynamoDB テーブルでレイテンシーが大きいことに関してトラブルシューティングするにはどうすればよいですか?

アプリケーションのレイテンシー要件に合わせて DynamoDB をさらに設定するには、「レイテンシーを考慮した Amazon DynamoDB アプリケーションのための AWS Java SDK HTTP リクエスト設定の調整」を参照してください。

リクエストのタイムアウト期間

setIdleConnectionTimeout パラメータによってアイドル接続のタイムアウト期間が決定され、setConnectTimeout によって DAX クラスターとの接続のタイムアウト期間が決定されます。この 2 つのパラメータで、接続プールのタイムアウトが処理されます。接続プールのタイムアウトはクラスターのレイテンシーに影響する可能性があります。

setRequestTimeout パラメータを調整して、DAX クラスターとの接続のリクエストタイムアウトを設定します。詳細については、DAX ドキュメントの「setRequestTimeout」を参照してください。

また、エクスポネンシャルバックオフ再試行を使用することもベストプラクティスです。これにより、リクエストエラーが減り、運用コストも削減されます。

注: DAX は CloudWatch メトリクスのクラスターのレイテンシーをサポートしていません。

---