使用 DynamoDB Auto Scaling 功能自動管理輸送容量 - Amazon DynamoDB

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

使用 DynamoDB Auto Scaling 功能自動管理輸送容量

許多資料庫工作負載本來就具週期性且難以事先預測。例如,假設有一個社交聯網應用程式,其中大部分使用者會在日間活動。資料庫必須能夠處理日間活動,但夜間則不需要同樣多的輸送量。又例如,請設想一下正被快速採用的新行動遊戲應用程式。如果遊戲變得太熱門,可能會超過可用的資料庫資源,而導致效能變慢及客戶不滿意。這類工作負載通常需要手動介入來擴展或縮減資料庫資源,以回應不斷改變的用量。

Amazon DynamoDB auto 動擴展使用應用 Ap AWS plication Auto Scaling 服務代表您動態調整佈建的輸送量容量,以回應實際的流量模式。這可讓資料表或全域次要索引增加其佈建的讀取與寫入容量,不需調節就以處理突然增加的流量。當工作負載降低時,Application Auto Scaling 可降低輸送量,讓您無須為未使用的佈建容量付費。

注意

如果您使用建 AWS Management Console 立表格或全域次要索引,預設會啟用 DynamoDB auto 調整規模。您可隨時修改自動調整規模設定。如需詳細資訊,請參閱 AWS Management Console 搭配使用 auto 調整

當您刪除資料表或全域表格複本時,系統不會自動刪除任何相關聯的可調整目標、縮放原則或 CloudWatch 警示。

使用 Application Auto Scaling,您就可以為資料表或全域次要索引建立擴展政策。調整規模政策可指定您要擴展讀取容量或寫入容量 (或兩者),也可為資料表或索引指定最大與最小佈建容量單位設定。

調整規模政策也包含目標使用率:即在某個時間點耗用的佈建輸送量百分比。Application Auto Scaling 使用目標追蹤演算法,向上或向下調整資料表 (或索引) 的佈建輸送量,以此回應實際的工作負載,讓實際容量使用率保持或接近目標使用率。

當兩個資料點在一分鐘範圍內違反設定的目標使用率值時,可觸發自動擴展。因此,由於消耗的容量在兩分鐘內高於目標使用率,因此可能會發生 auto 擴展。但是,如果尖峰相隔超過一分鐘,則可能不會觸發 auto 縮放。同樣地,當連續 15 個資料點低於目標使用率時,就會觸發縮減規模事件。在任何一種情況下,在觸發 auto 縮放之後,都會UpdateTable叫用呼叫。然後可能需要幾分鐘的時間來更新表格或索引的佈建容量。在此期間,任何超過表格先前佈建容量的要求都會受到限制。

重要

您不能調整要洩露的數據點數量以觸發基礎警報(儘管當前數量 future 可能會更改)。

您可將自動調整規模目標使用率值設定在 20% 至 90% 之間,做為您的讀寫容量。

注意

除了資料表外,DynamoDB Auto Scaling 功能也支援全域次要索引。每個全域次要索引都有自己的佈建輸送容量,與其基礎資料表的佈建輸送容量無關。當您為全域次要索引建立擴展政策時,Application Auto Scaling 會調整索引的佈建輸送量設定,以確保其實際使用率保持或接近您想要的使用比率。

DynamoDB Auto Scaling 功能的運作方式

注意

若要快速開始使用 DynamoDB Auto Scaling 功能,請參閱 AWS Management Console 搭配使用 auto 調整

下圖提供 DynamoDB Auto Scaling 功能如何管理資料表輸送容量的高層級概觀。

下列步驟摘要說明上圖所示的自動調整規模程序:

  1. 您可以為 DynamoDB 資料表建立 Application Auto Scaling 政策。

  2. DynamoDB 會將使用的容量指標發佈到 Amazon。 CloudWatch

  3. 如果表格的消耗容量在特定時間長度內超過目標使用率 (或低於目標),Amazon 會 CloudWatch 觸發警示。您可以在主控台檢視警示,並使用 Amazon Simple Notification Service (Amazon SNS) 接收通知。

  4. CloudWatch 警示會叫 Application Auto Scaling 來評估您的資源調整政策。

  5. Application Auto Scaling 發出 UpdateTable 請求來調整資料表的佈建輸送量。

  6. DynamoDB 處理 UpdateTable 請求,並動態增加 (或減少) 資料表的佈建輸送容量,以便接近您的目標使用率。

若要了解 DynamoDB Auto Scaling 功能的運作方式,請假設您有一個名為 ProductCatalog 的資料表。該資料表不常大量載入資料,因此不會產生太多寫入活動。不過,它會發生大量讀取活動,並會隨著時間變化。透過監控的 Amazon CloudWatch 指標ProductCatalog,您可以判斷表格需要 1,200 個讀取容量單位 (以避免 DynamoDB 在活動達到尖峰時節流讀取請求)。您也判斷出當讀取流量在最低點時,ProductCatalog 至少需要 150 個讀取容量單位。如需防止限流的詳細資訊,請參閱 使用佈建容量模式的 DynamoDB 表格的節流問題

在 150 到 1,200 個讀取容量單位範圍內,您決定 ProductCatalog 資料表的適當目標使用率為 70%。目標使用率是以使用容量單位與佈建容量單位的比率,以百分比表示。Application Auto Scaling 使用其目標追蹤演算法,確保視需要調整 ProductCatalog 的佈建讀取容量,讓使用率維持在或接近 70%。

注意

只有在實際工作負載持續幾分鐘保持很高 (或很低) 的狀態時,DynamoDB Auto Scaling 功能才會修改佈建輸送量設定。Application Auto Scaling 目標追蹤演算法會設法長期將目標使用率保持在或接近您選擇的數值。

資料表的內建高載容量可應付短期遽增的活動。如需詳細資訊,請參閱 高載容量

若要為 ProductCatalog 資料表啟用 DynamoDB Auto Scaling 功能,您可以建立擴展政策。此政策會指定以下內容:

  • 要管理的資料表或全域次要索引

  • 要管理的容量類型 (讀取容量或寫入容量)

  • 佈建輸送量設定的上限與下限

  • 您的目標使用率

當您建立擴展政策時,Application Auto Scaling 會代表您建立一對 Amazon CloudWatch 警示。每組警示皆代表您佈建輸送量設定的上限與下限。當表格的實際使用率在持續一段時間內偏離目標使用率時,就會觸發這些 CloudWatch 警示。

觸發其中一個 CloudWatch 警示時,Amazon SNS 會傳送通知給您 (如果您已啟用它)。然後 CloudWatch 警示會叫 Application Auto Scaling 整,進而通知 DynamoDB 適當地向上或向下調整ProductCatalog表格的佈建容量。

在擴展事件期間, AWS Config 會根據記錄的組態項目收費。發生縮放事件時,會針對每個讀取和寫入 auto-scaling 事件建立四 CloudWatch 個 ProvisionedCapacity 警報:警報: ProvisionedCapacityLow ProvisionedCapacityHigh 和 ConsumedCapacity 警報: AlarmHigh、 AlarmLow。這會導致總共八個警報。因此,每個擴展事件都會 AWS Config 記錄八個組態項目。

注意

您也可以排程 DynamoDB 擴展,使其在特定時間發生。在這裡了解基本步驟。

使用須知

開始使用 DynamoDB Auto Scaling 功能之前,您應該注意下列事項:

  • DynamoDB Auto Scaling 功能可根據您的自動調整規模政策,視需要經常增加讀取容量或寫入容量。所有 DynamoDB 配額仍然有效,如 Amazon DynamoDB 中的服務、帳戶和資料表配額 所述。

  • DynamoDB Auto Scaling 功能不會阻止您手動修改佈建輸送量設定。這些手動調整不會影響與 DynamoDB auto 調整相關的任何現有 CloudWatch警示。

  • 如果您為具有一或多個全域次要索引的資料表啟用 DynamoDB Auto Scaling,強烈建議您也將自動調整規模統一套用至這些索引。這將有助於確保改善資料表的寫入和讀取效能,並有助於避免限流。您可以在 AWS Management Console中選取 Apply same settings to global secondary indexes (將相同的設定套用至全域次要索引) 來啟用自動調整規模的功能。如需詳細資訊,請參閱 在現有資料表上啟用 DynamoDB Auto Scaling 功能

  • 當您刪除表格或全域表格複本時,任何相關聯的可調整目標、縮放原則或 CloudWatch 警示都不會隨之自動刪除。

  • 為現有資料表建立 GSI 時,不會為 GSI 啟用 Auto Scaling。建置 GSI 時,您必須手動管理容量。GSI 上的回填完成並達到活動狀態後,Auto Scaling 的操作將恢復正常。