診斷限流 - Amazon DynamoDB
了解調節例外狀況診斷架構

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

診斷限流

當您的應用程式遇到限流時，DynamoDB 會提供詳細的例外狀況資訊和目標 CloudWatch 指標，以協助您診斷這些事件。

本節提供一種系統性方法來了解 DynamoDB 應用程式中的限流事件。它說明如何解譯限流例外狀況、將它們與 CloudWatch 指標建立關聯，以獲得更深入的洞見，以及了解哪些變更會減少 DynamoDB 應用程式中的限流。

了解調節例外狀況

當 DynamoDB 調節請求時，它會傳回具有詳細診斷資訊的特定例外狀況。例如，在 Java 中，這些包括 ProvisionedThroughputExceededException、 RequestLimitExceeded或 ThrottlingException。

每個例外狀況都包含 ThrottlingReasons，ThrottlingReason其中包含兩個關鍵欄位的個別集合，可協助您識別和了解限流：

  • 原因 - 遵循格式的串連欄位 <ResourceType><OperationType><LimitType>

  • 資源 ARN - 受影響資料表或索引的 Amazon Resource Name (ARN)

原因欄位遵循一致的模式，可協助您確切了解發生的情況：

  • ResourceType （正在節流的內容）：Table或 Index

  • OperationType （哪種類型的操作）： Read 或 Write

  • LimitType （調節發生的原因）：

    • KeyRangeThroughputExceeded：當支援資料表或索引的特定分割區耗用超過每個分割區內部輸送量限制的讀取或寫入容量時，就會發生這種情況。

    • ProvisionedThroughputExceeded：當讀取或寫入耗用率超過佈建數量時，這發生在佈建資料表或全域次要索引上。

    • AccountLimitExceeded：當讀取或寫入耗用率超過在帳戶層級設定的資料表及其索引的最大耗用率時，這會發生在隨需資料表或索引上。您可以在此配額中請求提高。

    • MaxOnDemandThroughputExceeded：當讀取或寫入耗用率超過使用者為資料表或索引設定的最大耗用率時，這會發生在隨需資料表或索引上。您可以自行將此值提高到帳戶限制的任何值，或設定為 -1 表示沒有使用者提供的限制。

資源 ARN 會確切識別要調節的資料表或索引：

  • 對於資料表： arn:aws:dynamodb:[region]:[account-id]:table/[table-name]

  • 對於索引： arn:aws:dynamodb:[region]:[account-id]:table/[table-name]/index/[index-name]

完全限流原因的範例：

  • TableReadProvisionedThroughputExceeded

  • IndexWriteAccountLimitExceeded

這有助於準確識別正在調節的資源、導致該資源的操作類型，以及調節發生的原因。

範例例外狀況

範例 1：GSI 超過佈建容量

{
    "ThrottlingReasons": [
        {
            "reason": "IndexWriteProvisionedThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders/index/OrderDateIndex"
        }
    ],
    "awsErrorDetails": {
        "errorCode": "ProvisionedThroughputExceeded",
        "errorMessage": "The level of configured provisioned throughput for the index was exceeded",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}

在此範例中，應用程式會收到ProvisionedThroughputExceededException原因為 的 IndexWriteProvisionedThroughputExceeded。正在OrderDateIndex調節對 的寫入，因為寫入消耗已超過 GSI 設定的佈建寫入容量。

範例 2：超過隨需輸送量上限

{
    "ThrottlingReasons": [
        {
            "reason": "TableReadMaxOnDemandThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserSessions"
        }
    ],
    "awsErrorDetails": {
        "errorMessage": "Throughput exceeds the maximum OnDemandThroughput configured on table or index",
        "errorCode": "ThrottlingException",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}

在此範例中，資料表的讀取UserSessions會受到調節，因為它們超過資料表上設定的隨需輸送量上限。

DynamoDB 限流診斷架構

當您的應用程式遇到限流時，請依照下列步驟診斷並解決問題。

步驟 1 - 分析ThrottlingReason詳細資訊

  1. 檢查原因欄位，以識別限流的特定原因。原因會詳細說明調節的資源類型 （資料表或索引）、導致限流事件的操作類型 （讀取或寫入），以及超過的限制類型 （分割區、佈建輸送量、帳戶限制）。

  2. 檢查 resourceArn 欄位，以識別要調節哪些資源 （資料表或 GSI)。

  3. 使用此合併資訊來了解調節問題的完整內容。

    例如，請考慮此案例，您會收到以下例外狀況，ProvisionedThroughputExceededException並說明調節原因 TableWriteKeyRangeThroughputExceeded。受影響的 resourceARN 為 arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders。

    此組合會通知您CustomerOrders資料表的寫入操作正在調節。調節發生在分割區層級 （而非資料表層級，顯示為 TableWriteProvisionedThroughputExceeded)。根本原因是您已超過特定分割區索引鍵值或範圍的最大輸送量容量，指出熱分割區問題。

    了解例外狀況元素之間的這種關係可協助您實作適當的緩解策略 - 在這種情況下，處理熱分割區，而不是增加資料表的整體佈建容量。

步驟 2 - 識別和分析相關的 CloudWatch 指標

  1. 識別您的指標：DynamoDB 中的每個調節原因都直接對應到您可以監控的特定 CloudWatch 指標，以追蹤和分析調節事件。您可以從調節原因有系統地衍生適當的 CloudWatch 指標名稱。

  2. 使用此參考表將您的限流原因與對應的 CloudWatch 指標相符：

    完成限流原因和 CloudWatch 指標參考
    類別 調節原因 主要 CloudWatch 指標
    超過佈建容量 TableReadProvisionedThroughputExceeded ReadProvisionedThroughputThrottleEvents
    TableWriteProvisionedThroughputExceeded WriteProvisionedThroughputThrottleEvents
    IndexReadProvisionedThroughputExceeded ReadProvisionedThroughputThrottleEvents (GSI)
    IndexWriteProvisionedThroughputExceeded WriteProvisionedThroughputThrottleEvents (GSI)
    超過分割區限制 TableReadKeyRangeThroughputExceeded ReadKeyRangeThroughputThrottleEvents
    TableWriteKeyRangeThroughputExceeded WriteKeyRangeThroughputThrottleEvents
    IndexReadKeyRangeThroughputExceeded ReadKeyRangeThroughputThrottleEvents (GSI)
    IndexWriteKeyRangeThroughputExceeded WriteKeyRangeThroughputThrottleEvents (GSI)
    超過隨需上限 TableReadMaxOnDemandThroughputExceeded ReadMaxOnDemandThroughputThrottleEvents
    TableWriteMaxOnDemandThroughputExceeded WriteMaxOnDemandThroughputThrottleEvents
    IndexReadMaxOnDemandThroughputExceeded ReadMaxOnDemandThroughputThrottleEvents (GSI)
    IndexWriteMaxOnDemandThroughputExceeded WriteMaxOnDemandThroughputThrottleEvents (GSI)
    超過帳戶限制 TableReadAccountLimitExceeded ReadAccountLimitThrottleEvents
    TableWriteAccountLimitExceeded WriteAccountLimitThrottleEvents
    IndexReadAccountLimitExceeded ReadAccountLimitThrottleEvents GSIs)
    IndexWriteAccountLimitExceeded WriteAccountLimitThrottleEvents GSIs)

    例如，如果您收到 IndexWriteProvisionedThroughputExceeded，您至少應該監控 中識別的特定索引的 WriteProvisionedThroughputThrottleEvents CloudWatch 指標ResourceArn。

  3. 在 CloudWatch 中監控這些指標，以了解限流事件的頻率和時間、區分讀取和寫入限流、識別限流增加時的時間模式，以及追蹤您的容量使用率趨勢。

    DynamoDB 會發佈每個資料表和全域次要索引的詳細指標。指標 (ReadThrottleEvents、 WriteThrottleEvents和 ThrottledRequests) 會彙總資料表及其索引的所有限流事件。

步驟 3 - 使用 CloudWatch Contributor Insights 識別限流金鑰和高存取率 （適用於分割區相關的限流）

如果您在步驟 1 中發現分割區相關問題 （例如KeyRangeThroughputExceeded錯誤），適用於 DynamoDB 的 CloudWatch Contributor Insights 可協助您診斷哪些特定金鑰正在驅動流量，並在資料表或索引中遇到限流事件。

  1. 根據您的 為您的調節資料表或索引啟用 CloudWatch Contributor InsightsResourceARN。

    您可以選擇限流金鑰模式，只專注於最限流的金鑰。此模式非常適合持續監控，因為它只在限流發生時處理事件。或者，已存取和限流金鑰模式可協助您在最常存取的金鑰中尋找模式。

  2. 分析報告以識別有問題的模式。尋找具有不成比例高存取或限流速率的金鑰，並關聯限流和流量模式。您可以建立整合儀表板，結合 Contributor Insights 圖形和 DynamoDB CloudWatch 指標。

如需啟用和使用 CloudWatch Contributor Insights 的詳細資訊，請參閱使用適用於 DynamoDB 的 CloudWatch Contributor Insights。

步驟 4 - 判斷適當的解決方案

診斷調節的特定原因後，根據您的特定內容實作建議的解決方案。適當的解決方案取決於多個因素，包括調節案例、資料表的容量模式、資料表和金鑰設計決策、存取模式和查詢效率、全域和次要索引組態，以及整體系統架構和整合點。

如需解決特定限流案例的詳細解決方案，請參閱 DynamoDB 限流解析度指南一節。此資源提供針對您的特定限流原因和容量模式組態自訂的目標修復策略。

步驟 5 - 監控您的進度

  1. 追蹤與限流案例對應的 CloudWatch 指標。

  2. 透過觀察限流事件的減少，驗證您的緩解策略是否有效。