為什麼我的 EC2 執行個體在平均使用率較低時超出其網路限制？

2 分的閱讀內容

為什麼我的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體在平均使用率較低時超出其網路限制？

簡短描述

針對支援增強型網路功能的執行個體，您可透過彈性網路介面卡 (ENA) 即時查詢網路效能指標。自從上一次重設裝置之後，會透過這些指標顯示每個網路介面排入佇列或捨棄的累計封包數。以下是部分 ENA 指標：

**bw_in_allowance_exceeded：**由於輸入彙總頻寬超過執行個體上限而排入佇列或捨棄的封包數。
**bw_out_allowance_exceeded：**由於傳出彙總頻寬超過執行個體上限而排入佇列或捨棄的封包數。
**pps_allowance_exceeded：**由於每秒雙向封包 (PPS) 超過執行個體上限而排入佇列或捨棄的封包數。

網路效能規格會根據執行個體類型而有所不同。若要檢視規格，請參閱目前世代的執行個體。即使您在 Amazon CloudWatch 看到的平均頻寬或 PPS 很低，您有時仍可能會看到排入佇列或捨棄的情況。例如，CloudWatch 的下列指標：NetworkIn、NetworkOut、NetworkPacketsIn 或 NetworkPacketsOut 可能會顯示數目，但這不代表已經達到上限。

解析度

前述狀況最常見的原因是微爆。微爆是指需求短暫暴增，隨後活動量降低或無活動量。這些暴增通常僅持續數秒、毫秒甚至微秒。上一節列出的 CloudWatch 指標不夠精細，無法反映微爆的情況。

如何計算平均值

上一節列出的 CloudWatch EC2 指標每分鐘取樣一次。這些指標擷取此期間內傳輸的總位元組或封包數。然後，每隔 5 分鐘，會彙總這些樣本並傳送到 CloudWatch。這個時段内的每個統計數字都會傳回不同的樣本值：

Sum 指所有樣本值的總和。
SampleCount 指彙總樣本的數量 (這個例子為 5)。
Minimum 指最低位元組 / 封包數的樣本值。
Average 指平均樣本值，由 Sum 除以 SampleCount 得出。
Maximum 指最高位元組 / 封包數的樣本值。

平均輸送量或 PPS 有兩種計算方式：

將總和除以時段 (例如 300 秒)，即可得到簡單的 5 分鐘平均值。
將最大值除以 60 秒，計算活動量最高那一分鐘的平均值。

CloudWatch 指標如何反映微爆

以下是微爆的範例，以及如何在 CloudWatch 中反映：

執行個體的網路頻寬效能為每秒 10 Gbps (每秒 1.25 GB)。
在指定樣本 (60 秒) 中，20 GB 的傳出資料傳輸會耗盡所有可用頻寬，導致 bw_out_allowance_exceeded 增加。傳輸大約 20 秒內完成，隨後不再傳送任何資料。
剩餘的 4 個樣本 (240 秒)，執行個體會維持閒置狀態。

根據此範例，5 分鐘內的平均輸送量遠低於微爆期間的平均輸送量：

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

即使您根據最高樣本計算輸送量，平均值仍然無法反映輸送量：

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

監視微爆

若要以更精細的層級測量輸送量與 PPS，請使用作業系統 (OS) 工具來監視網路統計數據。在塑形或高活動量期間，以更頻繁的頻率監視您的網路統計數據。

以下是操作系統工具的範例：

Linux

sar
nload
iftop
iptraf-ng

Windows

效能監視器

Linux 及 Windows 可利用 CloudWatch 代理程式，將這些作業系統層級的網路指標傳送到 CloudWatch 作為自訂指標。這些指標最低可以每隔 1 秒傳送一次。請注意，高解析度指標 (期間低於 60 秒的指標) 收費會更高。有關 CloudWatch 的定價資訊，請參閱 Amazon CloudWatch 定價。

最佳實務是監視 ENA 提供的網路效能指標。若要監視這些指標，驅動程式版本必須是 2.2.10 (Linux) 及 2.2.2 (Windows) 或更高版本。如需更多資訊，請參閱 Linux 與 Windows 的相關頁面。

CloudWatch 代理程式也可傳送 ENA 指標。如需指示了解 Linux 傳送的 ENA 指標，請參閱收集網路效能指標。可從效能監視器獲得 Windows 的 ENA 指標，而 CloudWatch 代理程式可設定向 Windows 傳送任何可用指標。

避免微爆

為了避免出現微爆，傳送者必須調節流量，以防超過最大輸送量或封包速率。這令微爆難以避免。傳送者若要調節流量，通常需要應用程式層級的變更。根據變更的執行方式，傳送者可能需要提供並開啟作業系統才能調節流量。這並不總是可行，有時甚至不可能。若在短時間內傳送封包的連線太多，也可能發生微型爆量。發生這種情況時，調節單一發送者並無幫助。

由於這些原因，監視 ENA 指標乃是最佳實務。如果經常達到極限，或者有證據顯示流量塑造影響了您的應用程式，請遵循下列指示：

**縱向擴展：**移至較大的執行個體。較大的執行個體通常有著更高的限額。網路最佳化執行個體 (例如包含「n」，如 C5n) 的限額高於其對應的非網路最佳化執行個體。
**橫向擴展：**將流量分散到多個執行個體，降低個別執行個體的流量及競爭。

針對 Linux，除了上述選項之外，進階使用者還有可能的風險降低選項。您可以單獨或合併實作這些選項。最佳實務是在測試環境中對緩和措施進行基準測試，以確認措施是否減少或消除流量塑造，而不會對工作負載造成不利影響。

**SO_MAX_PACING_RATE：**可透過應用程式將此通訊端選項傳送給 setsockopt 系統呼叫，來指定最大調節率 (每秒位元組數)。然後，Linux 核心會調節通訊端流量，使其不超過限制。此選項需要執行下列操作：

應用程式程式碼層級變更。
核心提供的支援。
使用公平佇列 (FQ) 佇列規則或核心的支援 TCP 層級調節 (僅適用於 TCP)。

**佇列規則 (qdiscs)：**qdiscs 負責封包排程及可選塑造。有些 qdiscs (例如 fq) 有助於消除個別流量中的流量激增。如需詳細資訊，請參閱流量控制 (TC) 手冊頁面。
**淺層傳輸 (Tx) 佇列：**在部分情況下，淺層 Tx 佇列可降低 PPS 塑造。這可透過兩種方式完成：

位元組佇列限制 (BQL)：BQL 動態限制 Tx 佇列在執行中的位元組數量。Linux 核心隨附的 ENA 驅動程式版本 (以「K」結尾的版本) 預設為開啟 BQL。GitHub 的 ENA 驅動程式版本 (以「g」結尾的版本) 從 v2.6.1g 起提供 BQL 並預設為關閉。您可利用 enable_bql ENA 單元參數來開啟 BQL。
**降低 Tx 佇列長度：**把 Tx 佇列長度從預設的 1,024 個封包減少到較低數量 (最少 256 個)。您可利用 ethtool 來變更長度。