對 Amazon DynamoDB 中的延遲問題進行疑難排解 - Amazon DynamoDB

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

對 Amazon DynamoDB 中的延遲問題進行疑難排解

若您的工作負載似乎出現高延遲，您可以分析 CloudWatch SuccessfulRequestLatency 指標，並透過百分位數指標 (p50) 檢視平均與中位延遲，以判斷問題是否與 DynamoDB 有關。所回報的 SuccessfulRequestLatency 出現部分變化屬正常現象，偶發的尖峰 (尤其是在 Maximum 統計資料與高百分位數中) 無需特別擔心。然而，若 Average 統計資料或 p50 (中位數) 持續急遽上升，請檢視 AWS 服務健康狀態儀表板及個人健康儀表板，以取得更多資訊。可能的原因包括資料表中項目的大小 (1 KB 項目與 400 KB 項目的延遲會有所差異)，或查詢的範圍 (10 個項目與 100 個項目相比)。

百分位數指標 (p99、p90 等) 可協助您更深入了解延遲分布情形。例如：

  • p50 (中位數) 代表您的工作負載的典型延遲值。

  • p90 表示有 90% 的請求速度快於此值。

  • p99 有助於識別影響 1% 請求的最差延遲情況。

若 p99 值偏高但 p50 值正常，可能代表零星問題影響少部分請求；若 p50 值持續升高，則可能顯示效能衰退。

注意

若要分析自訂百分位數值 (例如 p99.9)，可在 CloudWatch 指標統計欄位中手動輸入所需百分位數。這可讓您評估超出下拉選單預設百分位數範圍的延遲分布。

延遲指標出現變化 (特別是在高百分位數) 屬預期情形，通常是由 DynamoDB 背景作業造成，這些作業可協助維持儲存在 DynamoDB 資料表中的資料高可用性與耐用性，或反映暫時性基礎設施問題。

如有必要，請考慮使用 AWS 支援 建立支援案例，然後根據您的執行手冊，繼續評估您應用程式的任何可用回復選項 (例如，如果您有多區域架構，則撤離一個區域)。您應記錄慢速請求的請求 ID，以便在開啟支援案例時提供給 AWS 支援。

SuccessfulRequestLatency 指標僅衡量 DynamoDB 服務內部延遲，不包含用戶端活動與網路往返時間。若要深入了解用戶端呼叫 DynamoDB 服務的整體延遲，您可以在 AWS SDK 中啟用延遲指標記錄。

注意

對於大部分單一操作 (透過完全指定主索引鍵的值來套用至單一項目的操作)，DynamoDB 提供個位數的毫秒 Average SuccessfulRequestLatency。此值不包括存取 DynamoDB 端點之呼叫者程式碼的傳輸負荷。對於多項目資料操作，延遲會因結果集的大小、傳回資料結構的複雜度，以及套用的任何條件表達式和篩選條件表達式等因素而有所不同。對於具有相同參數之相同資料集的重複多項操作，DynamoDB 提供高度一致的 Average SuccessfulRequestLatency。

請考慮下列一或多種策略來減少延遲：

  • 重複使用連線：DynamoDB 請求預設透過 HTTPS 的已驗證工作階段傳送。建立連線需經多次往返且耗時，因此第一個請求的延遲通常高於後續重複使用連線的請求。經由已啟動連線的請求，可以提供 DynamoDB 一致的低延遲。為減少建立新連線的延遲負擔，若無其他 GetItem 請求，建議每 30 秒傳送一次請求，以實作「保持連線」機制。

  • 使用最終一致讀取：如果您的應用程式不需要高度一致性讀取，請考慮使用預設的最終一致讀取。最終一致讀取的成本較低，且可從多個可用區域讀取資料，可選擇與請求端共置的可用區域，以降低延遲。如需更多詳細資訊，請參閱 DynamoDB 讀取一致性。

  • 實作請求對沖：若對 p99 延遲有極低要求，建議考慮實作請求對沖機制。在使用請求對沖時，若初始請求未能及時收到回應，系統會傳送第二個等效請求，並讓兩者同時競爭，以最先回應者為準。此方法可改善尾端延遲，但需付出額外請求的成本。您可自行設定在傳送第二個請求前的等待時間。對於讀取操作，對沖策略較容易實作。對於寫入操作，請使用以時間戳記為基礎的排序機制，以確保對沖請求視為在首次嘗試時發生，防止更新順序錯亂。此方法已在 Amazon DynamoDB 寫入對沖的時間戳記寫入一文中詳述。

  • 調整請求逾時與重試行為：從用戶端到 DynamoDB 的傳輸路徑會經過多個元件，且各元件皆具備備援設計。請考量以下面向：

    • 網路韌性

    • TCP 封包逾時

    • DynamoDB 的分散式架構

    SDK 的預設行為已針對多數應用程式進行最佳化。不過，您也可採用快速檢錯策略，並視需要調整逾時設定。明顯超出一般時間的請求，最終成功機率較低。採用快速檢錯並重新嘗試的方式，您可以透過其他路徑更快完成請求。此策略類似於請求對沖，但會終止第一個請求，而非讓其持續執行。

    避免將逾時值設定得過低。過低的逾時設定可能造成用戶端引起的可用性問題。例如，若通訊端逾時設定為 50 毫秒，當網路延遲出現尖峰 (例如單一流量接近 Amazon EC2 執行個體頻寬上限) 時，可能導致連線錯誤。請仔細權衡較低逾時設定的效益與其對應用程式可用性造成的風險，並建議優先採用對沖策略，而非縮短逾時。

    如需更深入的討論，請參閱為延遲感知的 Amazon DynamoDB 應用程式調整 AWS Java SDK HTTP 請求設定。

  • 減少用戶端與 DynamoDB 端點之間的距離：如果您的使用者遍布全球，請考慮使用 全域資料表：多重作用中的多區域複寫。透過全域資料表，您可將資料表複寫至指定的 AWS 區域，以確保在所需區域可供使用。可將資料複本部署於接近終端使用者的位置，以降低讀寫操作的網路延遲。如需深入了解如何有效使用 DynamoDB 全域資料表，請參閱使用 Amazon DynamoDB 全域資料表 (AWS 規範指引)。

  • 使用快取：若您的應用以讀取為主，請考慮以下快取服務：