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

# 以 Amazon SQS 為基礎的擴展政策
<a name="as-using-sqs-queue"></a>

**重要**  
下列資訊和步驟說明在將佇列屬性作為自訂指標發佈到 CloudWatch 之前，如何使用 `ApproximateNumberOfMessages` 佇列屬性計算每個執行個體的 Amazon SQS 佇列待辦項目。但是，您現在可以使用指標數學來節省發佈自己指標的成本和精力。如需詳細資訊，請參閱[使用指標數學建立目標追蹤擴展政策](ec2-auto-scaling-target-tracking-metric-math.md)。

您可以擴展 Auto Scaling 群組，以回應 Amazon Simple Queue Service (Amazon SQS) 佇列中系統負載的變更。若要進一步了解如何使用 Amazon SQS，請參閱《[Amazon Simple Queue Service 開發人員指南](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)》。

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

**Topics**
+ [搭配正確的指標使用目標追蹤](#scale-sqs-queue-custom-metric)
+ [限制](#scale-sqs-queue-limitations)
+ [根據 Amazon SQS 設定擴展](scale-sqs-queue-cli.md)
+ [Amazon SQS 和執行個體縮減保護](#scale-sqs-queue-scale-in-protection)

## 搭配正確的指標使用目標追蹤
<a name="scale-sqs-queue-custom-metric"></a>

如果您使用以自訂 Amazon SQS 佇列指標為基礎的目標追蹤擴展政策，動態擴展可以更有效地調整至您應用程式的需求曲線。如需為目標追蹤選擇指標的詳細資訊，請參閱 [選擇 Metrics (指標)](as-scaling-target-tracking.md#target-tracking-choose-metrics)。

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

為解決這些狀況，可使用帶有目標值的 *backlog per instance* (每個執行個體的待處理項目) 指標，作為要維持的 *acceptable backlog per instance* (每個執行個體的可接受待處理項目)。您可以透過以下列方式計算這些數字：
+ **每個執行個體的待處理項目**：如要計算每個執行個體的待處理項目，請從 `ApproximateNumberOfMessages` 佇列屬性開始，以判斷 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-target-tracking-metric-math.md)。

這組態有三個重要部分：
+ 用來管理 EC2 執行個體的 Auto Scaling 群組，主要目的在處理來自 SQS 佇列中的訊息。
+ 傳送給 Amazon CloudWatch 的自訂指標，用來 Auto Scaling 群組每個 EC2 執行個體佇列中的訊息數量。
+ 目標追蹤擴展政策設定 Auto Scaling 群組會根據自訂指標和設定的目標值來進行擴展。CloudWatch 警示呼叫擴展政策。

下圖說明此組態的架構。

![\[Amazon EC2 Auto Scaling 使用佇列架構圖表\]](http://docs.aws.amazon.com/zh_tw/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)


## 限制
<a name="scale-sqs-queue-limitations"></a>

您必須使用 AWS CLI 或 SDK 將自訂指標發佈至 CloudWatch。然後，您可以使用 監控指標 AWS 管理主控台。

在下列各節中，您會 AWS CLI 針對需要執行的任務使用 。例如，若要取得反映佇列目前使用情況的指標資料，您可以使用 SQS [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html) 命令。

## Amazon SQS 和執行個體縮減保護
<a name="scale-sqs-queue-scale-in-protection"></a>

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

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

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

如需詳細資訊，請參閱[設計您的應用程式以正常處理執行個體終止](gracefully-handle-instance-termination.md)。