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

編輯 Application Load Balancer 的目標群組屬性

為 Application Load Balancer 建立目標群組之後，您可以編輯其目標群組屬性。

取消登記的延遲

Elastic Load Balancing 會停止將請求傳送給正在取消註冊的目標。在預設情況下，Elastic Load Balancing 需要等待 300 秒，才能完成取消註冊程序，這有助於至目標的傳輸中請求完成。若要變更 Elastic Load Balancing 等待的時間，請更新取消註冊延遲時間值。

取消註冊中的目標，其初始狀態為 draining。經過取消註冊延遲之後，取消註冊程序會完成，並且目標的狀態為 unused。如果目標是 Auto Scaling 群組的一部分，可加以終止和取代。

如果取消註冊的目標沒有傳輸中的請求，也沒有作用中連線，Elastic Load Balancing 會立即完成取消註冊程序，而不會等候取消註冊延遲時間結束。不過，即使目標取消註冊完成，目標的狀態仍會顯示為 draining，直到取消註冊延遲逾時結束。逾時結束後，目標會轉變為 unused 狀態。

如果取消註冊目標在取消註冊延遲經過之前終止連線，用戶端會收到 500 層級的錯誤回應。

使用 更新取消註冊延遲值 AWS CLI

使用 modify-target-group-attributes 命令搭配 deregistration_delay.timeout_seconds 屬性。

慢速啟動模式

在預設情況下，在向目標群組註冊目標並通過初始運作狀態檢查之後，目標隨即會開始接收其請求的完整共用。使用慢速啟動模式可讓目標在負載平衡器向它們傳送請求的完整共用之前，有時間進行暖機。

啟用目標群組的慢啟動後，當目標群組被視為運作狀態良好時，其目標會進入慢速啟動模式。慢速啟動模式的目標，會在設定的慢啟動超過持續的時間或目標變得狀態不良時，結束慢速啟動模式。負載平衡器會線性增加可以在慢速啟動模式中傳送到目標的請求數量。在運作狀態良好的目標退出慢速啟動模式之後，負載平衡器可以將完整份額的請求傳送給它。

使用 更新慢速啟動持續時間值 AWS CLI

將 modify-target-group-attributes 命令與 slow_start.duration_seconds 屬性搭配使用。

Application Load Balancer 目標群組的跨區域負載平衡

負載平衡器的節點會將請求從用戶端分發到已註冊的目標。跨區域負載平衡開啟後，每個負載平衡器節點會將流量分散到所有已註冊可用區域內的已註冊目標。跨區域負載平衡關閉後，每個負載平衡器節點只會將流量分散到其可用區域內已註冊的目標。如果區域故障網域優先於地區故障網域，就可能發生此情形，以確保運作狀態良好的區域不受運作狀態不佳區域的影響，也可能是為改善整體延遲。

使用 Application Load Balancer 時，跨區域負載平衡一律會在負載平衡器層級開啟，而且無法關閉。對於目標群組，預設設定為使用負載平衡器設定，但您可以在目標群組層級明確關閉跨區域負載平衡來覆寫預設設定。

關閉跨區域負載平衡

您可以隨時為 Application Load Balancer 目標群組關閉跨區域負載平衡。

若要使用 關閉跨區域負載平衡 AWS CLI

使用 modify-target-group-attributes 命令，並將 load_balancing.cross_zone.enabled 屬性設定為 false。

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

以下是回應範例：

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "false"
        },
    ]
}

開啟跨區域負載平衡

您可以隨時為 Application Load Balancer 目標群組開啟跨區域負載平衡。目標群組層級的跨區域負載平衡設定會覆寫負載平衡器層級的設定。

使用 開啟跨區域負載平衡 AWS CLI

使用 modify-target-group-attributes 命令，並將 load_balancing.cross_zone.enabled 屬性設定為 true。

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

以下是回應範例：

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "true"
        },
    ]
}

自動目標權重 (ATW)

自動目標權重 (ATW) 會持續監控執行應用程式的目標，偵測顯著的效能偏差，稱為異常。ATW 可讓您透過即時資料異常偵測，動態調整路由至目標的流量量。

自動目標權重 (ATW) 會自動對帳戶中的每個 Application Load Balancer 執行異常偵測。識別異常目標時，ATW 可以透過減少路由的流量來自動嘗試穩定這些目標，稱為異常緩解。ATW 會持續最佳化流量分佈，以最大化每個目標的成功率，同時將目標群組失敗率降至最低。

異常偵測

ATW異常偵測會監控任何顯示與目標群組中其他目標行為明顯偏差的目標。這些偏差稱為異常，是透過比較一個目標的錯誤百分比與目標群組中其他目標的錯誤百分比來決定。這些錯誤可能是連線錯誤和 HTTP 錯誤代碼。報告明顯高於其對等的目標會被視為異常。

異常偵測需要目標群組中至少三個運作良好的目標。當目標註冊到目標群組時，必須先通過運作狀態檢查，才能開始接收流量。一旦目標接收到目標，ATW 會開始監控目標並持續發佈異常結果。對於沒有異常的目標，異常結果為 normal。對於具有異常的目標，異常結果為 anomalous。

ATW異常偵測的運作與目標群組運作狀態檢查無關。目標可以通過所有目標群組運作狀態檢查，但由於錯誤率提高，仍會標記為異常。變成異常的目標不會影響其目標群組運作狀態檢查狀態。

異常偵測狀態

ATW 會持續發佈其對目標執行的異常偵測狀態。您可以使用 AWS Management Console 或 隨時檢視目前的狀態 AWS CLI。

使用 檢視異常偵測結果 AWS CLI

使用 describe-target-health 命令，並將Include.member.N屬性值設定為 AnomalyDetection。

異常緩解

ATW異常緩解會自動路由流量遠離異常目標，讓他們有機會復原。

開啟 ATW 異常緩解

您可以隨時開啟異常緩解功能。

使用 開啟異常緩解 AWS CLI

使用 modify-target-group-attributes 命令搭配 load_balancing.algorithm.anomaly_mitigation 屬性。

異常緩解狀態

每當 ATW 在目標上執行緩解時，您隨時都可以使用 AWS Management Console 或 檢視目前的狀態 AWS CLI。

若要使用 檢視異常緩解狀態 AWS CLI

使用 describe-target-health 命令，並將Include.member.N屬性值設定為 AnomalyDetection。

Application Load Balancer 的粘性會話

根據預設，Application Load Balancer 會根據所選的負載平衡演算法，將每個請求獨立路由至註冊的目標。不過，您可以使用粘性會話功能 (也稱為工作階段親和性)，讓負載平衡器將使用者的工作階段繫結到特定目標。這樣能確保該工作階段期間所有的使用者請求都能傳送到同一個目標。這功能對於維護狀態資訊以便為用戶端提供持續體驗的伺服器來說很實用。若要使用粘性會話，用戶端必須支援 Cookie。

Application Load Balancer 支援持續時間型 Cookie 和應用程式型 Cookie。粘性會話會在目標群組層級啟用。您可以組合使用持續時間型粘性、應用程式型粘性，以及目標群體之間無粘性。

管理粘性會話的金鑰是決定您的負載平衡器應該持續將使用者請求路由到同一個目標的時間。如果您的應用程式有自己的工作階段 Cookie，則您可以使用應用程式型粘性，負載平衡器工作階段 Cookie 會遵循應用程式的工作階段 Cookie 指定的持續時間。如果您的應用程式沒有自己的工作階段 Cookie，則您可以使用持續時間型粘性，來產生具有指定持續時間的負載平衡器工作階段 Cookie。

系統會使用輪換金鑰來對負載平衡器產生的 Cookie 內容進行加密。您不能解密或修改負載平衡器產生的 Cookie。

對於這兩種粘性類型，Application Load Balancer 會在每次請求後重設其產生的 Cookie 到期時間。如果 Cookie 過期，則工作階段不再具有粘性，用戶端應該從其 Cookie 存放區中刪除該 Cookie。

持續時間型粘性

持續時間型粘性會使用負載平衡器產生的 Cookie (AWSALB)，將請求路由至目標群組中的同一個目標。Cookie 用於將工作階段映射到目標。如果您的應用程式沒有自己的工作階段 Cookie，您可以指定自己的粘性持續時間，並管理負載平衡器應持續地將使用者的請求路由至同一個目標的時間。

負載平衡器首次從用戶端收到請求時，它會將請求路由到目標 (根據所選演算法)，並產生一個名為 AWSALB 的 Cookie。它會對所選目標的資訊進行編碼，對 Cookie 進行加密，並在對用戶端的回應中包含 Cookie。負載平衡器產生的 Cookie 自己有 7 天的有效期，且無法設定。

在後續的請求中，用戶端應該包括 AWSALB Cookie。負載平衡器收到來自用戶端包含 Cookie 的請求時，會偵測到此 Cookie，並會將該請求路由至同一個目標。如果 Cookie 存在但無法解碼，或者它參照了已取消註冊或狀況不良的目標，負載平衡器會選取新的目標，並以新目標的相關資訊更新 Cookie。

對於跨來源資源共用 (CORS) 請求，某些瀏覽器需要SameSite=None; Secure啟用黏性。為了支援這些瀏覽器，負載平衡器一律會產生第二個黏性 Cookie，AWSALBCORS其中包含與原始黏性 Cookie 相同的資訊，以及 SameSite 屬性。用戶端會收到兩個 Cookie，包括非 CORS 請求。

使用 啟用以持續時間為基礎的黏性 AWS CLI

使用 modify-target-group-attributes 命令搭配 stickiness.enabled和 stickiness.lb_cookie.duration_seconds 屬性。

請使用下列命令啟用持續時間型粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

輸出內容應如下範例所示。

     {     
        "Attributes": [
           ...
            {
                 "Key": "stickiness.enabled",
                 "Value": "true"
              },           
              {
                  "Key": "stickiness.lb_cookie.duration_seconds",
                  "Value": "86500"
              
              },
           ...
          ]
      }           

應用程式型粘性

應用程式型粘性可讓您靈活地設定自己的用戶端目標粘性標準。啟用應用程式型粘性後，負載平衡器會根據選擇的演算法，將第一個請求路由到目標群組內的目標。目標預期會設定與負載平衡器上設定的 Cookie 相符的自訂應用程式 Cookie，以啟用粘性。這個自定義 Cookie 可以包括應用程序所需的任何 Cookie 屬性。

Application Load Balancer 從目標收到自訂應用程式 Cookie 後，會自動產生新的加密應用程式 Cookie，以擷取粘性資訊。此負載平衡器產生的應用程式 Cookie 會擷取每個已啟用應用程式型粘性之目標群組的粘性資訊。

負載平衡器產生的應用程式 Cookie 不會複製目標所設定之自訂 Cookie 的屬性。它自己有 7 天的有效期，且無法設定。在對用戶端的回應中，Application Load Balancer 只會驗證在目標群組層級設定之自訂 Cookie 的名稱，而不會驗證自訂 Cookie 的值或到期屬性。只要名稱相符，負載平衡器會在對用戶端待回應中傳送兩個 Cookie，即目標設定的自訂 Cookie 以及負載平衡器產生的應用程式 Cookie。

在後續請求中，用戶端必須傳回這兩個 Cookie 以保持粘性。負載平衡器會解密應用程式 Cookie，並檢查設定的粘性持續時間是否仍然有效。然後，它會使用 Cookie 中的資訊來將請求傳送給目標群組中的同一個目標，以維持粘性。負載平衡器也會將自訂應用程式 Cookie 代理至目標，且不會對其進行檢查或修改。在後續回應中，負載平衡器產生的應用程式 Cookie 到期時間，以及在負載平衡器上設定的粘性持續時間都會重設。為了保持用戶端和目標之間的粘性，Cookie 的到期時間和粘性的持續時間不應結束。

如果目標失敗或運作狀態不佳，負載平衡器會停止路由請求到該目標，並根據選擇的負載平衡演算法選擇運作狀態良好的新目標。負載平衡器會將工作階段視為「粘到」運作狀態良好的新目標，並持續路由請求到運作狀態良好的新目標，即使失敗的目標恢復也是如此。

透過跨來源資源共用 (CORS) 請求，若要啟用黏性，只有在使用者代理版本為 Chromium80 或更高版本時，負載平衡器才會將SameSite=None; Secure屬性新增至負載平衡器產生的應用程式 Cookie。

由於大部分瀏覽器會將 Cookie 大小限制在 4K，負載平衡器會將大於 4K 的應用程式 Cookie 分成多個 Cookie 碎片。Application Load Balancer 支援的 Cookie 大小上限為 16K，因此最多會建立 4 個傳送到用戶端的碎片。用戶端看到的應用程式 Cookie 名稱以「AWSALBAPP-」開頭，並包含片段編號。例如，如果 Cookie 大小為 0-4K，用戶端會看到 AWSALBAPP-0。如果 Cookie 大小為 4-8k，用戶端會看到 AWSALBAPP-0 和 AWSALBAPP-1，以此類推。

使用 啟用應用程式型黏性 AWS CLI

使用 modify-target-group-attributes 命令搭配下列屬性：

請使用下列命令啟用應用程式型粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

輸出內容應如下範例所示。

 
       {
            "Attributes": [
                ...
                {
                    "Key": "stickiness.enabled",
                    "Value": "true"
                },
                {
                    "Key": "stickiness.app_cookie.cookie_name",
                    "Value": "MyCookie"
                },
                {
                    "Key": "stickiness.type",
                    "Value": "app_cookie"
                },
                {
                    "Key": "stickiness.app_cookie.duration_seconds",
                    "Value": "86500"
                },
                ...
            ]
        }  
            
            

手動重新平衡

縱向擴展時，如果目標數量大幅增加，則由於粘性，可能會導致負載分配不均衡。在這種情況下，可以使用下列兩個選項重新平衡目標上的負載：