基於 Amazon 的擴展政策 SQS - Amazon EC2 Auto Scaling
搭配正確的指標使用目標追蹤限制與事前準備 Amazon SQS 和執行個體擴充保護

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

基於 Amazon 的擴展政策 SQS

重要

下列資訊和步驟說明如何使用SQS佇列屬性計算每個執行個體的 Amazon ApproximateNumberOfMessages 佇列積壓，然後再將 CloudWatch其發佈為自訂指標。但是，您現在可以使用指標數學來節省發佈自己指標的成本和精力。如需詳細資訊，請參閱使用指標數學建立目標追蹤擴展政策。

本節說明如何擴展 Auto Scaling 群組，以回應 Amazon 簡單佇列 (AmazonSQS) 佇列中系統負載的變化。若要進一步了解如何使用 AmazonSQS，請參閱 Amazon 簡單佇列服務開發人員指南。

在某些情況下，您可能會考慮擴展以回應 Amazon SQS 佇列中的活動。例如，假設您有一個 web 應用程式，可讓使用者上傳影像及在線上使用這些影像。在此情境下，每個影像都需要調整大小和編碼，才能進行發佈。應用程式會在 Auto Scaling 群組中的EC2執行個體上執行，並設定為處理一般上傳速率。運作狀態不佳的執行個體會中止且取代，為維持目前執行個體數量。應用程式會將影像的原始點陣圖資料放在SQS佇列中進行處理。它會處理影像，然後發佈處理後的影像，供使用者瀏覽。如果要上傳的影像數量不會隨時間變化，此案例的架構便能夠良好的運作。但如果上傳的數量會隨時間變更，建議您考慮使用動態擴展來擴展您 Auto Scaling 群組的容量。

目錄

搭配正確的指標使用目標追蹤

如果您使用以自訂 Amazon SQS 佇列指標為基礎的目標追蹤擴展政策，動態擴展可以更有效地根據應用程式的需求曲線進行調整。如需為目標追蹤選擇指標的詳細資訊，請參閱 選擇 Metrics (指標)。

使用 CloudWatch Amazon SQS 指標進行目標追蹤的問題在ApproximateNumberOfMessagesVisible於，佇列中的訊息數量可能不會與處理佇列訊息的 Auto Scaling 群組大小成比例變更。這是因為SQS佇列中的訊息數量並不僅定義所需的執行個體數量。Auto Scaling 群組中的執行個體數會受到多個因素影響，包括其處理訊息所花費的時間，以及可接受的延遲量 (佇列延遲)。

為解決這些狀況，可使用帶有目標值的 backlog per instance (每個執行個體的待處理項目) 指標，作為要維持的 acceptable backlog per instance (每個執行個體的可接受待處理項目)。您可以透過以下列方式計算這些數字：

  • 每個執行處理的待處理項目：若要計算每個執行處理的待處理項目，請從 ApproximateNumberOfMessages queue 屬性開始判斷SQS佇列的長度 (可從佇列擷取的訊息數目)。將此數量除以機群的執行容量 (對 Auto Scaling 群組而言是處於 InService 狀態的執行個體數量)，求出每個執行個體的待處理項目。

  • 每個執行個體的可接受待處理項目：如要計算您的目標值，請先判斷您應用程式針對延遲可接受的應用程式。然後，取得可接受的延遲值，並將其除以EC2執行個體處理訊息所需的平均時間。

例如，假設您目前有一個 Auto Scaling 群組，其中包含 10 個執行個體，且佇列 (ApproximateNumberOfMessages) 中的可見訊息數量為 1500。如果每個訊息的平均處理時間為 0.1 秒，最長可接受的延遲為 10 秒，則每個執行個體的可接受待處理項目 10/0.1，等於 100 個訊息。這表示 100 是目標追蹤政策的目標值。當每個執行個體的待處理項目達到目標值時，就會發生橫向擴展事件。因為每個執行個體的待處理項目數量已經為 150 個訊息 (1500 個訊息/10 個執行個體)，您的群組便會橫向擴展，並橫向擴展五個執行個體來維持與目標值的比例。

下列程序示範如何發佈自訂指標及建立目標追蹤擴展政策，設定您的 Auto Scaling 群組來根據這些計算進行擴展。

重要

請記住，若要降低成本，請改用指標數學。如需詳細資訊，請參閱使用指標數學建立目標追蹤擴展政策。

這組態有三個重要部分：

  • 用於管理EC2執行個體的 Auto Scaling 群組，以處理SQS佇列中的訊息。

  • 傳送至 Amazon 的自訂指標， CloudWatch 用於測量 Auto Scaling 群組中每個EC2執行個體佇列中的訊息數量。

  • 一種目標追蹤政策，可將 Auto Scaling 群組設定為根據自訂指標和設定的目標值進行擴展。 CloudWatch 警示會叫用資源調整政策。

下圖說明此組態的架構。

Amazon 使用隊列架構圖 EC2 Auto Scaling

限制與事前準備

如要使用此組態，您需要注意下列限制：

  • 您必須使用 AWS CLI 或SDK將自訂量度發佈到 CloudWatch。然後，您可以使用 AWS Management Console.

  • Amazon EC2 Auto Scaling 主控台不支援使用自訂指標的目標追蹤擴展政策。您必須使用 AWS CLI 或SDK來指定資源調度政策的自訂指標。

下列各節將引導您使 AWS CLI 用您需要執行的工作。例如，若要取得反映佇列目前使用情況的測量結果資料，請使用SQSget-queue-attributes指令。確保您已CLI安裝並配置。

在開始之前，您必須有一個 Amazon SQS 隊列才能使用。下列各節假設您已有佇列 (標準或FIFO)、Auto Scaling 群組，以及EC2執行使用佇列之應用程式的執行個體。如需 Amazon 的詳細資訊SQS，請參閱 Amazon 簡單佇列服務開發人員指南。

Amazon SQS 和執行個體擴充保護

執行個體終止時尚未處理的訊息會傳回SQS佇列，並由另一個仍在執行中的執行個體處理這些訊息。對於執行長時間執行任務的應用程式，您可以選擇性地使用執行個體縮減保護，控制 Auto Scaling 群組縮減時要終止哪些佇列工作者。

下列虛擬程式碼顯示可保護長時間執行、佇列導向的工作者處理程序免於縮減終止的一種方法。

while (true)
{
  SetInstanceProtection(False);
  Work = GetNextWorkUnit();
  SetInstanceProtection(True);
  ProcessWorkUnit(Work);
  SetInstanceProtection(False);
}

如需詳細資訊，請參閱設計您的應用程式以妥善處理執行個體終止。