為什麼我的 Amazon DynamoDB 平均延遲正常但最大延遲指標高?

上次更新日期:2022 年 9 月 7 日

當我檢視我的 Amazon DynamoDB 工作負載的 Amazon CloudWatch 指標時,發現最大延遲指標高。但平均延遲正常。

解決方案

在分析 CloudWatch 指標 SuccessfulRequestLatency 時,檢查平均延遲是一種最佳做法。最大延遲並不能反映 DynamoDB 資料表的整體延遲。它反映的是該時間段內單個請求所花費的最長時間。例如,如果您一次對 DynamoDB 資料表進行 100 個請求,即使 99 個請求只需要 10 毫秒,但只要有 1 個請求需要 100 毫秒,那麼最大延遲指標也會是 100 毫秒。

DynamoDB 是一種大規模的分散式系統,其後端機群有數千個節點。因此,一個 DynamoDB 資料表可能在資料表空間中有多個分割區,並且每個分割區在後端機群中有多個複本。當您對 DynamoDB 進行 API 呼叫時,DynamoDB 服務端點會接收呼叫,然後將其路由到後端節點之一進行處理。成功處理呼叫後,DyanamoDB 會將結果路由回您的用戶端。

在大多數情況下,一個 API 呼叫在一次嘗試中即可成功處理,因此您在用戶端上觀察到的延遲會很小。但第一次嘗試有時會因後端節點遇到下列狀況而失敗:

  • 忙碌
  • 容錯移轉
  • 分割區拆分
  • 連線問題
在這些狀況下,第一次嘗試會在伺服器端逾時 (5000 毫秒) 內失敗。然後,伺服器會自動在另一個節點上重試 API 呼叫,並且通常會進行多次。成功處理 API 呼叫後,伺服器會將結果返回給用戶端。發生這種狀況時,您會觀察到該特定請求的延遲增加。

因此,您通常不需要擔心較高的最大延遲指標。如果 DynamoDB 服務觀察到某個節點持續出現高延遲,則該服務會自動將該節點從後端機群中移除。當前面提到的局部故障發生在服務端時,您可能會觀察到一定百分比的 API 呼叫延遲有所增加。這在 CloudWatch 中會反映為相關 DynamoDB 資料表的 SuccessfulRequestLatency 指標升高。因此,局部故障可能會導致最大延遲增加,但您無需採取任何措施來控制此故障。

但是,您可以透過指數退避重試快速檢錯來設定應用程式,以快速做出反應。這意味著新請求會被快速路由到新的節點,從而您可以更快地取得結果。如需詳細資訊,請參閱為延遲感知型 Amazon DynamoDB 應用程式調整 AWS Java SDK HTTP 請求設定