1- キー範囲スループットの超過 (ホットパーティション) - Amazon DynamoDB
キー範囲スループット超過の緩和策一般的な診断とモニタリング解決手順その他のリソース

1- キー範囲スループットの超過 (ホットパーティション)

Amazon DynamoDB は、テーブルとグローバルセカンダリインデックス (GSI) の両方について、パーティションレベルで特定のスループット制限を適用します。各パーティションには、1 秒あたりの読み込みキャパシティーユニット (RCU) と書き込みキャパシティーユニット (WCU) の最大数があります。パーティションがこれらの制限を超える集中トラフィックを受信すると、スロットリングが発生し、他のオペレーションが十分に活用されないままになり、「ホットパーティション」が発生する可能性があります。DynamoDB のパーティションレベルのスロットリングは、読み取りと書き込みに対して独立して動作します。パーティションは、書き込みが正常に継続している間に読み取りをスロットリングするか、その逆を行います。このスロットリングは、テーブルまたは GSI の全体的なキャパシティが十分であっても発生する可能性があります。詳細を確認するトピック

個々のパーティションがスループット制限を超えると、DynamoDB はスロットリング例外で KeyRangeThroughputExceeded スロットリングの理由タイプを返します。この情報により、パーティションのトラフィックが多くなり、どのオペレーションタイプ (読み取りまたは書き込み) が問題の原因になっているかがわかります。

キー範囲スループット超過の緩和策

このセクションでは、パーティションレベルのスロットリングシナリオの解決ガイダンスを提供します。このガイドを使用する前に、アプリケーションの例外処理から特定のスロットリングの理由を特定し、影響を受けるリソースの Amazon リソースネーム (ARN) を決定していることを確認します。スロットリングの理由の取得とスロットリングされたリソースの識別については、「DynamoDB スロットリング診断フレームワーク」を参照してください。

特定のスロットリングシナリオに進む前に、まず問題が自動的に解決されるかどうかを確認します。

  • DynamoDB は、多くの場合、自動 split-for-heat メカニズムを通じてホットパーティションに適応します。短期間後に停止するスロットリングイベントが表示される場合は、ホットパーティションを分割してテーブルが既に適応している可能性があります。パーティションが分割されると、新しい各パーティションはキースペースの小さなセクションを処理するため、負荷をより均等に分散できます。多くの場合、DynamoDB は自動的に問題を解決しているため、それ以上のアクションは必要ありません。

    split-for-heat メカニズムの詳細については、「その他のリソース」を参照してください。

スロットリングが持続する場合は、以下の特定のスロットリングシナリオを参照して、ターゲットを絞った修復オプションを確認します。

TableReadKeyRangeThroughputExceeded

この問題が発生した場合

DynamoDB テーブル内の 1 つ以上のパーティションの消費レートが、パーティションの読み取りスループット制限を超えています。このスロットリングは、テーブルの合計プロビジョンドキャパシティに関係なく発生し、プロビジョンドテーブルとオンデマンドテーブルの両方に影響します。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

修復オプション

スロットリングイベントに対処するには、以下の手順を検討します。

プロビジョニングモードとオンデマンドモードの両方の場合:

  • 事前ウォーミングキャパシティ: スロットリングが持続する場合は、テーブルの DynamoDB ウォームスループットについて キャパシティが制限されているかどうかを確認します。予想されるトラフィックの増加に備えて、ウォームスループットを使用するか、事前に読み込みプロビジョンドキャパシティを増やします。ウォームスループットを上げると、スロットリングが発生する前に突然のトラフィックのスパイクを処理するテーブルの機能が向上します。時間の経過とともに、実際のスループットがウォームスループットレベルに一貫して近づくと、DynamoDB は観測された使用パターンに基づいて使用率が高いパーティションを分割することがあります。

  • ホットキーを特定する: テーブルが自動的に解決せず、ウォームスループットが高い場合、またはウォームスループットを上げても効果がない場合は、特定のホットキーを特定する必要があります。CloudWatch Contributor Insights を使用したホットキーの識別 を使用して、特定のパーティションキー値がホットかどうかを判断します。これは、緩和作業を効果的にターゲットにするための最初のステップです。特にローリングホットパーティション (時間の経過とともに異なるパーティションがホットになる) や、スキャンなどのオペレーションによってスロットリングがトリガーされる場合、識別が必ずしも簡単であるとは限りません。このような複雑なシナリオでは、アプリケーションのアクセスパターンを分析し、スロットリングイベントのタイミングと関連付ける必要がある場合があります。

  • ユースケースに応じて、結果整合性のある読み込みの使用を検討する: 強力な整合性のある読み込みから結果整合性のある読み込みに切り替えると、RCU の半分が消費され、有効な読み込み容量がすぐに 2 倍になります。結果整合性のある読み込みを実装して読み込みキャパシティの消費量を削減するベストプラクティスについては、「DynamoDB の読み取り整合性」を参照してください。

  • パーティションキー設計の改善: 長期ソリューションとして、パーティションキー設計の改善 を改善し、パーティション間でアクセスをより均等に分散することを検討します。このアプローチは、多くの場合、根本原因に対処することで、ホットパーティションの問題に対する最も包括的な解決策を提供します。ただし、重要な移行の課題を伴うため、慎重な計画が必要です。

TableWriteKeyRangeThroughputExceeded

この問題が発生した場合

DynamoDB テーブル内の 1 つ以上のパーティションの消費レートが、パーティションの書き込みスループット制限を超えています。このスロットリングは、テーブルの合計プロビジョンドキャパシティに関係なく発生し、プロビジョンドテーブルとオンデマンドテーブルの両方に影響します。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

修復オプション

スロットリングイベントに対処するには、以下の手順を検討します。

プロビジョニングモードとオンデマンドモードの両方の場合:

  • 事前ウォーミングキャパシティ: スロットリングが持続する場合は、テーブルの DynamoDB ウォームスループットについて キャパシティが制限されているかどうかを確認します。予想されるトラフィックの増加に備えて、ウォームスループットを使用するか、事前に書き込みプロビジョンドキャパシティを増やします。ウォームスループットを上げると、スロットリングが発生する前に突然のトラフィックのスパイクを処理するテーブルの機能が向上します。時間の経過とともに、実際のスループットがウォームスループットレベルに一貫して近づくと、DynamoDB は観測された使用パターンに基づいて使用率が高いパーティションを分割することがあります。

  • ホットキーを特定する: テーブルが自動的に解決せず、ウォームスループットが高い場合、またはウォームスループットを上げても効果がない場合は、特定のホットキーを特定する必要があります。CloudWatch Contributor Insights を使用したホットキーの識別 を使用して、特定のパーティションキー値がホットかどうかを判断します。これは、緩和作業を効果的にターゲットにするための最初のステップです。以下の一般的なパターンを検討します。

    • スロットリングデータに同じパーティションキーが頻繁に表示される場合は、集中ホットキーであることを示しています。

    • キーが繰り返し表示されないが、順序付けられた方法でデータを書き込んでいる場合 (シーケンシャルタイムスタンプやキースペースの順序に従うスキャンベースのオペレーションなど)、書き込みがキースペースを通過するにつれて、時間の経過とともに異なるキーがホットになるローリングホットパーティションがある可能性があります。

    書き込みスロットリングは、BatchWriteItem や複数の項目に同時に影響を与えるトランザクションなどの操作でも発生する可能性があることに注意してください。BatchWriteItem リクエスト内の個々の項目がスロットリングされると、DynamoDB はこれらのスロットリングエラーをアプリケーションコードに伝達しません。代わりに、DynamoDB はレスポンス内の未処理の項目に関する情報を返します。アプリケーションは、それらの特定の項目を再試行して処理する必要があります。トランザクションの場合、いずれかの項目でスロットリングが発生すると、オペレーション全体が TransactionCanceledException で失敗します。このような複雑なシナリオでは、アプリケーションの書き込みパターンとデータインジェストワークフローを分析し、スロットリングイベントのタイミングと関連付けて、適切な再試行処理戦略を実装する必要がある場合があります。

  • パーティションキー設計の改善: 長期ソリューションとして、パーティションキー設計の改善 を改善し、パーティション間でアクセスをより均等に分散することを検討します。このアプローチは、多くの場合、根本原因に対処することで、ホットパーティションの問題に対する最も包括的な解決策を提供します。ただし、重要な移行の課題を伴うため、慎重な計画が必要です。

IndexReadKeyRangeThroughputExceeded

この問題が発生した場合

DynamoDB GSI 内の 1 つ以上のパーティションの消費レートが、パーティションの読み取りスループット制限を超えています。このスロットリングは、GSI の合計プロビジョンドキャパシティに関係なく発生し、プロビジョンドテーブルとオンデマンドテーブルの両方に影響します。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

修復オプション

スロットリングイベントに対処するには、以下の手順を検討します。

  • 事前ウォーミングキャパシティ: スロットリングが持続する場合は、GSI の DynamoDB ウォームスループットについて キャパシティが制限されているかどうかを確認します。予想されるトラフィックの増加に備えて、ウォームスループットを使用するか、事前に読み込みプロビジョンドキャパシティを増やします。ウォームスループットを上げると、スロットリングが発生する前に突然のトラフィックのスパイクを処理する GSI の機能が向上します。時間の経過とともに、実際のスループットがウォームスループットレベルに一貫して近づくと、DynamoDB は観測された使用パターンに基づいて使用率が高いパーティションを分割することがあります。

  • ホットキーを特定する: GSI が自動的に解決せず、ウォームスループットが高い場合、またはウォームスループットを上げても効果がない場合は、特定のホットキーを特定する必要があります。CloudWatch Contributor Insights を使用したホットキーの識別 を使用して、特定のパーティションキー値がホットかどうかを判断します。これは、緩和作業を効果的にターゲットにするための最初のステップです。GSI の場合、パーティションキーの分散は基本テーブルと大きく異なり、異なるホットキーパターンが発生する可能性があることに注意してください。

  • GSI パーティションキーの再設計: GSI キー設計が、少数のパーティションに読み取りを集中させる人工的なホットスポット (ステータスフラグ、日付のみのキー、ブール属性など) を作成しているかどうかを検討します。低カーディナリティ属性を高カーディナリティ属性と組み合わせる複合キーを使用すること (単に「ACTIVE」ではなく「ACTIVE#customer123」など)、または GSI ディストリビューションに影響する基本テーブル項目に 書き込みシャーディングを使用して DynamoDB テーブルでワークロードを均等に分散させる 手法を適用して複数のパーティションに書き込みを分散することを検討します。シャードデータをクエリするには結果を集約するための追加のアプリケーションロジックが必要ですが、このアプローチではアクセスパターンをより均等に分散することでスロットリングを防止します。

IndexWriteKeyRangeThroughputExceeded

この問題が発生した場合

DynamoDB GSI 内の 1 つ以上のパーティションの消費レートが、パーティションの書き込みスループット制限を超えています。このスロットリングは、GSI の合計プロビジョンドキャパシティに関係なく発生し、プロビジョンドテーブルとオンデマンドテーブルの両方に影響します。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

修復オプション

スロットリングイベントに対処するには、以下の手順を検討します。

  • GSI パーティションキーの再設計: GSI パーティションキー設計を確認して、書き込みを均等に分散するのに十分なカーディナリティ (一意性) があることを確認します。GSI 書き込みスロットリングの一般的な原因は、GSI パーティションキーとして低カーディナリティ属性を使用することです (可能な値が少ないステータスフラグなど)。基本テーブルに適切に分散されたパーティションキーがある場合でも、パーティションキーが少数の値に書き込みが集中すると、GSI でホットパーティションが発生する可能性があります。例えば、項目の 80% に「ACTIVE」というステータスがある場合、ステータスベースの GSI に重大なホットパーティションが作成されます。低カーディナリティ属性を高カーディナリティ属性と組み合わせる複合キーを使用すること (単に「ACTIVE」ではなく「ACTIVE#customer123」など)、または GSI ディストリビューションに影響する基本テーブル項目に 書き込みシャーディングを使用して DynamoDB テーブルでワークロードを均等に分散させる 手法を適用して複数のパーティションに書き込みを分散することを検討します。シャードデータをクエリするには結果を集約するための追加のアプリケーションロジックが必要ですが、このアプローチではアクセスパターンをより均等に分散することでスロットリングを防止します。

  • 事前ウォーミングキャパシティ: GSI が DynamoDB ウォームスループットについて キャパシティによって制限されているかどうかを確認します。予想されるトラフィックの増加に備えて、ウォームスループットを使用するか、事前に読み込みプロビジョンドキャパシティを増やします。ウォームスループットを上げると、スロットリングが発生する前に突然のトラフィックのスパイクを処理する GSI の機能が向上します。時間の経過とともに、実際のスループットがウォームスループットレベルに一貫して近づくと、DynamoDB は観測された使用パターンに基づいて使用率が高いパーティションを分割することがあります。

  • GSI 射影の最適化: GSI への書き込み量を減らす GSI 射影の最適化 手法を適用します。属性の数を減らすと、各 GSI 更新で消費される書き込みキャパシティが大幅に減少します。

一般的な診断とモニタリング

パーティションレベルのスロットリングをトラブルシューティングする場合、複数の CloudWatch メトリクスがホットパーティションを特定し、根本原因を確認するのに役立ちます。

重要な CloudWatch メトリクス

これらの主要なメトリクスをモニタリングして、パーティションレベルのスロットリングを診断します。

解決手順

CloudWatch Contributor Insights を使用したホットキーの識別

この手順を使用して、スロットリングの原因となっているパーティションキーを特定します。

  1. テーブルまたは GSI で CloudWatch Contributor Insights を有効にして、最もスロットリングされたキーを追跡します。スロットリングされたキーモードを使用して、CloudWatch Contributor Insights をリアルタイムスロットリングアラートで継続的に有効にすることを検討します。このモードは、スロットリングが発生したときにのみイベントを処理することで、スロットリングされたリクエストのみに焦点を当てます。このターゲットを絞ったモニタリングは、スロットリングの問題を継続的に可視化するためのコスト効率の高い方法です。

  2. ホットパーティションの問題の原因となっているキーを特定します。

  3. (フルアクセスおよびスロットリングされたキーが有効になっている場合) アクセスパターンを経時的に分析して、ホットキーが一貫しているか、特定の期間に発生するかを判断します。

パーティションキー設計の改善

このアプローチは、パーティション間でトラフィックをより適切に分散するようにテーブルスキーマを変更できる場合に使用します。可能な場合、これはホットパーティションの問題に対する最も効果的な長期的なソリューションです。パーティションキーの設計は、最初のテーブル設計段階で慎重に検討することをお勧めします。

パーティションキーの再設計は、アプリケーションエコシステム全体に影響を与えるデータモデルへの根本的な変更を表します。このアプローチを進める前に、以下の重要な制限事項を慎重に検討してください。

  • データ移行の複雑さ: パーティションキーを再設計するには、既存のすべてのデータを移行する必要があります。大規模なテーブルでは、リソースを大量に消費し、時間がかかる場合があります。

  • アプリケーションコードの変更: テーブルを読み書きするすべてのアプリケーションコードは、新しいキー構造を使用するように更新する必要があります。

  • 本番稼働への影響: 新しいキー設計に移行するには、移行中にダウンタイムや複雑な二重書き込み戦略が必要になることがよくあります。

パーティションキー設計に関する包括的なガイダンスと原則については、「DynamoDB でパーティションキーを効率的に設計し、使用するためのベストプラクティス。」および「パーティションキーを設計してワークロードを DynamoDB で分散する」を参照してください。

GSI 射影の最適化

アプリケーションのクエリパターンを確認して、GSI をクエリするときに使用できる属性を正確に決定し、射影をそれらの属性のみに制限します。GSI に射影されていない属性を更新すると、その GSI で書き込みオペレーションは行われず、更新中の書き込みスループットの消費量が減少します。このターゲット射影戦略は、アプリケーションのクエリ要件をサポートしながら、パフォーマンスとコストの両方を最適化します。属性の射影数を減らすと、書き込みキャパシティの消費量は減りますが、基本テーブルの読み取りがさらに必要になる場合があります。

効率的な射影戦略の詳細については、「DynamoDB でセカンダリインデックスを使用するためのベストプラクティス」を参照してください。

その他のリソース

次のブログ投稿では、このガイドで説明されている概念の実践的な例と実践的な詳細について説明します。