

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

# 編輯 Application Load Balancer 的目標群組屬性
<a name="edit-target-group-attributes"></a>

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

**Topics**
+ [取消登記的延遲](#deregistration-delay)
+ [路由演算法](#modify-routing-algorithm)
+ [慢速啟動模式](#slow-start-mode)
+ [運作狀態設定](#modify-target-group-health-settings)
+ [跨區域負載平衡](#modify-cross-zone)
+ [自動目標權重 (ATW)](#automatic-target-weights)
+ [黏性工作階段](#sticky-sessions)

## 取消登記的延遲
<a name="deregistration-delay"></a>

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

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

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

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

------
#### [ Console ]

**更新取消註冊延遲值**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 在**目標取消註冊管理**窗格中，輸入**取消註冊延遲**的新值。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**更新取消註冊延遲值**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令搭配 `deregistration_delay.timeout_seconds` 屬性。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes "Key=deregistration_delay.timeout_seconds,Value={{60}}"
```

------
#### [ CloudFormation ]

**更新取消註冊延遲值**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含 `deregistration_delay.timeout_seconds` 屬性。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "deregistration_delay.timeout_seconds"
          Value: "{{60}}"
```

------

## 路由演算法
<a name="modify-routing-algorithm"></a>

路由演算法是負載平衡器在判斷哪些目標將接收請求時使用的方法。預設會使用**循環配置**路由演算法，在目標群組層級路由請求。根據您的應用程式需求，也可以使用**最不未完成的請求**和**加權隨機**路由演算法。目標群組一次只能有一個作用中的路由演算法，但路由演算法可以視需要更新。

如果您啟用黏性工作階段，選取的路由演算法會用於初始目標選擇。來自相同用戶端的未來請求將轉送至相同的目標，繞過選取的路由演算法。如果您已啟用目標最佳化工具，則路由演算法只能是循環配置。

**循環配置**
+ 循環配置路由演算法會依序將請求平均路由到目標群組中運作狀態良好的目標。
+ 當收到的請求在複雜性方面類似 、已註冊的目標在處理能力方面類似，或者您需要在目標之間平均分配請求時，通常會使用此演算法。

**最少未完成的請求**
+ 最不未完成的請求路由演算法會將請求路由到正在進行中請求數量最低的目標。
+ 當收到的請求的複雜性不同時，通常會使用此演算法，註冊的目標的處理能力也不同。
+ 當支援 HTTP/2 的負載平衡器使用僅支援 HTTP/1.1 的目標時，會將請求轉換為多個 HTTP/1.1 請求。在此組態中，最少未完成的請求演算法會將每個 HTTP/2 請求視為多個請求。
+ 使用 WebSockets 時，會使用最不未完成的請求演算法來選取目標。選取目標之後，負載平衡器會建立與目標的連線，並透過此連線傳送所有訊息。
+ 最少未完成的請求路由演算法無法與慢速啟動模式搭配使用。

**加權隨機**
+ 加權隨機路由演算法會以隨機順序，將請求平均路由到目標群組中運作狀態良好的目標。
+ 此演算法支援自動目標權重 (ATW) 異常緩解。
+ 加權隨機路由演算法無法與慢速啟動模式搭配使用。
+ 加權隨機路由演算法無法與黏性工作階段搭配使用。

------
#### [ Console ]

**更新路由演算法**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 在**流量組態**窗格中，針對**負載平衡演算法**，選擇**循環配置**、**最少未完成的請求**或**加權隨機**。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**更新路由演算法**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令搭配 `load_balancing.algorithm.type` 屬性。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes "Key=load_balancing.algorithm.type,Value={{least_outstanding_requests}}"
```

------
#### [ CloudFormation ]

**更新路由演算法**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含 `load_balancing.algorithm.type` 屬性。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "load_balancing.algorithm.type"
          Value: "{{least_outstanding_requests}}"
```

------

## 慢速啟動模式
<a name="slow-start-mode"></a>

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

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

**考量事項**
+ 啟用目標群組的慢啟動時，運作狀態良好的已註冊目標不會進入慢速啟動模式。
+ 為空白目標群組啟用慢速啟動，然後使用單一註冊操作註冊目標時，這些目標不會進入慢速啟動模式。只有在至少一個運作狀態良好的目標不處於慢速啟動模式時，新註冊的目標才會進入慢速啟動模式。
+ 如果您將處於慢速啟動模式的目標取消註冊，該目標會退出慢速啟動模式。如果您再次註冊相同的目標，當目標群組視為運作狀態良好時，它會進入慢速啟動模式。
+ 如果處於慢速啟動模式的目標變得運作狀態不佳，目標就會結束慢速啟動模式。當目標狀況良好時，它會再次進入慢速啟動模式。
+ 使用**最不未完成的請求**或**加權隨機**路由演算法時，您無法啟用慢速啟動模式。

------
#### [ Console ]

**更新慢速啟動持續時間值**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 在**流量組態**窗格中，輸入**慢速啟動持續時間**的新值。若要停用慢速啟動模式，請輸入 0。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**更新慢速啟動持續時間值**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令搭配 `slow_start.duration_seconds` 屬性。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes "Key=slow_start.duration_seconds,Value={{30}}"
```

------
#### [ CloudFormation ]

**更新慢速啟動持續時間值**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含 `slow_start.duration_seconds` 屬性。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "slow_start.duration_seconds"
          Value: "{{30}}"
```

------

## 運作狀態設定
<a name="modify-target-group-health-settings"></a>

根據預設，Application Load Balancer 會監控目標的運作狀態，並將請求路由至運作狀態良好的目標。不過，如果負載平衡器沒有足夠的運作狀態良好的目標，它會自動將流量傳送至所有已註冊的目標 （失敗開啟）。您可以修改目標群組的目標群組運作狀態設定，以定義 DNS 容錯移轉和路由容錯移轉的閾值。如需詳細資訊，請參閱[目標群組運作狀態](load-balancer-target-groups.md#target-group-health)。

------
#### [ Console ]

**修改目標群組運作狀態設定**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的**負載平衡**中，選擇**目標群組**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 檢查是否開啟或關閉跨區域負載平衡。視需要更新此設定，以確保您有足夠的容量可在區域發生故障時處理額外的流量。

1. 展開**目標群組運作狀況需求**。

1. 針對**組態類型**，建議您選擇**統一組態**，這兩個動作都會設定相同的臨界值。

1. 對於**狀態良好的狀態要求**，請執行下列其中一項：
   + 選擇**最小運作狀況目標計數**，然後輸入從 1 到目標群組目標數目上限的數字。
   + 選擇**最小狀態良好目標百分比**，然後輸入 1 到 100 之間的數字。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**修改目標群組運作狀態設定**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 指令。下列範例會將兩個運作狀態不佳的動作的運作狀態良好閾值設定為 50%。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes \
        "Key=target_group_health.dns_failover.minimum_healthy_targets.percentage,Value={{50}}" \
        "Key=target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage,Value={{50}}"
```

------
#### [ CloudFormation ]

**修改目標群組運作狀態設定**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源。下列範例會將兩個運作狀態不佳的動作的運作狀態良好閾值設定為 50%。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "target_group_health.dns_failover.minimum_healthy_targets.percentage"
          Value: "{{50}}"
        - Key: "target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage"
          Value: "{{50}}"
```

------

## 跨區域負載平衡
<a name="modify-cross-zone"></a>

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

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

**考量事項**
+ 跨區域負載平衡關閉後，不支援目標粘性。
+ 跨區域負載平衡關閉後，不支援將 Lambda 函數作為目標。
+ 如果有任何目標的參數 `AvailabilityZone` 設定為 `all`，則嘗試透過 `ModifyTargetGroupAttributes` API 關閉跨區域負載平衡會導致錯誤。
+ 註冊目標時需要 `AvailabilityZone` 參數。跨區域負載平衡關閉後，僅允許特定可用區域值。否則，系統會忽略此參數並將其當作 `all`。

**最佳實務**
+ 針對您預期使用的所有可用區域，為每個目標群組規劃足夠的目標容量。如果無法為所有參與的可用區域規劃足夠容量，建議將跨區域負載平衡保持開啟的狀態。
+ 如果 Application Load Balancer 設定有多個目標群組，請確定所有目標群組都在設定的區域內參與相同的可用區域。這是為了避免跨區域負載平衡關閉後可用區域變成空白的狀態，因為這會對進入空白可用區域的所有 HTTP 請求觸發 503 錯誤。
+ 避免建立空白子網路。Application Load Balancer 會透過 DNS 公開空白子網路的區域 IP 地址，這會針對 HTTP 請求觸發 503 錯誤。
+ 還可能會發生這種情況：關閉跨區域負載平衡的目標群組為每個可用區域都計劃有足夠的目標容量，但可用區域中的所有目標都變成運作狀態不佳。當至少一個目標群組包含的所有目標都運作狀態不佳時，就會將負載平衡器節點的 IP 地址從 DNS 移除。當目標群組具有至少一個運作狀態良好的目標之後，IP 地址就會還原到 DNS。

### 關閉跨區域負載平衡
<a name="cross_zone_console_disable"></a>

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

------
#### [ Console ]

**關閉跨區域負載平衡**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤上，選取**編輯**。

1. 在**目標選取組態**窗格中，選擇**關閉**以進行**跨區域負載平衡**。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**關閉跨區域負載平衡**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令並將 `load_balancing.cross_zone.enabled` 屬性設為 `false`。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes "Key=load_balancing.cross_zone.enabled,Value=false"
```

------
#### [ CloudFormation ]

**關閉跨區域負載平衡**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含 `load_balancing.cross_zone.enabled` 屬性。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "load_balancing.cross_zone.enabled"
          Value: "{{false}}"
```

------

### 開啟跨區域負載平衡
<a name="cross_zone_console_enable"></a>

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

------
#### [ Console ]

**關閉跨區域負載平衡**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤上，選取**編輯**。

1. 在**目標選取組態**窗格中，選擇**開啟**以進行**跨區域負載平衡**。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**開啟跨區域負載平衡**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令並將 `load_balancing.cross_zone.enabled` 屬性設為 `true`。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes "Key=load_balancing.cross_zone.enabled,Value=true"
```

------
#### [ CloudFormation ]

**開啟跨區域負載平衡**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含 `load_balancing.cross_zone.enabled` 屬性。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "load_balancing.cross_zone.enabled"
          Value: "{{true}}"
```

------

## 自動目標權重 (ATW)
<a name="automatic-target-weights"></a>

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

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

**考量：**
+ 異常偵測目前會監控來自目標的 HTTP 5xx 回應碼，以及目標的連線失敗。異常偵測一律開啟且無法關閉。
+ 使用 Lambda 做為目標時，不支援 ATW。

**Contents**
+ [異常偵測](#anomaly-detection)
+ [異常緩解](#anomaly-mitigation)

### 異常偵測
<a name="anomaly-detection"></a>

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

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

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

**異常偵測狀態**

您可以檢視目前的異常偵測狀態。以下為可能值：
+ `normal` – 未偵測到異常。
+ `anomalous` – 偵測到異常。

------
#### [ Console ]

**檢視異常偵測狀態**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 選擇 **Targets (目標)** 標籤。

1. 在**已註冊目標**資料表中，**異常偵測結果**欄會顯示每個目標的異常狀態。

------
#### [ AWS CLI ]

**檢視異常偵測狀態**  
使用 [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html) 命令。下列範例顯示指定目標群組中每個目標的狀態。

```
aws elbv2 describe-target-health \
    --target-group-arn {{target-group-arn}} \
    --include AnomalyDetection
```

------

### 異常緩解
<a name="anomaly-mitigation"></a>

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

**需求**  
只有在使用**加權隨機**路由演算法時，才能使用 ATW 的異常緩解函數。

**在緩解期間：**
+ ATW 會定期調整路由至異常目標的流量。目前，期間為每 5 秒一次。
+ ATW 會將路由至異常目標的流量減少至執行異常緩解所需的最低數量。
+ 不再偵測到為異常的目標會逐漸將更多流量路由到它們，直到它們與目標群組中的其他正常目標達到同位。

------
#### [ Console ]

**開啟異常緩解**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 在**流量組態**窗格中，確認**負載平衡演算法**的選取值為**隨機加權**。

   一開始選取加權隨機演算法時，預設會開啟異常偵測。

1. 在**異常緩解**下，確保已選取**開啟異常緩解**。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**開啟異常緩解**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令搭配 `load_balancing.algorithm.anomaly_mitigation` 屬性。

```
aws elbv2 
```

------

**緩解狀態**

您可以檢查 ATW 是否正在對目標執行緩解措施。以下為可能值：
+ `yes` – 緩解進行中。
+ `no` – 緩解未進行中。

------
#### [ Console ]

**檢視異常緩解狀態**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 選擇 **Targets (目標)** 標籤。

1. 在**已註冊目標**資料表中，您可以在**緩解生效**欄中檢視每個目標的異常緩解狀態。

------
#### [ AWS CLI ]

**檢視異常緩解狀態**  
使用 [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html) 命令。下列範例顯示指定目標群組中每個目標的狀態。

```
aws elbv2 describe-target-health \
    --target-group-arn {{target-group-arn}} \
    --include AnomalyDetection
```

------

## 黏性工作階段
<a name="sticky-sessions"></a>

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

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

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

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

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

**要求**
+ HTTP/HTTPS 負載平衡器。
+ 在各個可用區域內啟動至少一個正常運作的執行個體。

**考量事項**
+ 如果[跨區域負載平衡已停用](#modify-cross-zone)，便不支援粘性會話。停用跨區域負載平衡時，嘗試啟用黏性工作階段失敗。
+ 對於應用程式型 Cookie，必須針對每個目標群組個別指定 Cookie 名稱。但是，對於持續時間型 Cookie，`AWSALB` 是所有目標群組中唯一使用的名稱。
+ 如果您使用多層 Application Load Balancer，則可以使用應用程式型 Cookie 在所有層級間啟用粘性會話。但是，如果使用持續時間型 Cookie，便只能在一個層上啟用粘性會話，因為 `AWSALB` 是唯一可用的名稱。
+ 如果 Application Load Balancer 同時收到 `AWSALBCORS`和以`AWSALB`持續時間為基礎的黏性 Cookie，則 中的值`AWSALBCORS`將優先。
+ 應用程式型粘性不適用於加權目標群組。
+ 如果您有一個[轉送規則](rule-action-types.md#forward-actions)涉及多個目標群組，且一個或多個目標群組已啟用粘性會話，則您必須啟用目標群組層級的粘性。
+ WebSocket 連線本質上具粘性。如果用戶端請求將連線升級到 WebSocket，傳回 HTTP 101 狀態碼以接受連線升級的目標，為 WebSocket 連線中使用的目標。在 WebSocket 升級完成之後，不會使用以 Cookie 為基礎的黏性。
+ Application Load Balancer 會使用 Cookie 標頭中的 `Expires` 屬性，而非 `Max-Age` 屬性。
+ Application Load Balancer 不支援 URL 編碼的 Cookie 值。
+ 如果 Application Load Balancer 在目標因取消註冊而耗盡時收到新的請求，則請求會路由至運作狀態良好的目標。
+ 如果啟用目標最佳化工具，則不支援黏性工作階段。

**Topics**
+ [持續時間型粘性](#duration-based-stickiness)
+ [應用程式型粘性](#application-based-stickiness)

### 持續時間型粘性
<a name="duration-based-stickiness"></a>

持續時間型粘性會使用負載平衡器產生的 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 請求。

------
#### [ Console ]

**啟用以持續時間為基礎的黏性**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 在**目標選取組態**下，執行下列動作：

   1. 選取**開啟黏性**。

   1. 在**粘性類型**中，選取**負載平衡器產生的 Cookie**。

   1. 針對 **Stickiness duration (黏性持續期間)**，指定介於 1 秒到 7 天之間的值。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**啟用以持續時間為基礎的黏性**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令搭配 `stickiness.enabled` 和 `stickiness.lb_cookie.duration_seconds` 屬性。

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-arn}} \
    --attributes \
        "Key=stickiness.enabled,Value=true" \
        "Key=stickiness.lb_cookie.duration_seconds,Value={{300}}"
```

------
#### [ CloudFormation ]

**啟用以持續時間為基礎的黏性**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含 `stickiness.enabled`和 `stickiness.lb_cookie.duration_seconds` 屬性。

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - Key: "stickiness.enabled"
          Value: "true" 
        - Key: "stickiness.lb_cookie.duration_seconds"
          Value: "{{300}}"
```

------

### 應用程式型粘性
<a name="application-based-stickiness"></a>

應用程式型粘性可讓您靈活地設定自己的用戶端目標粘性標準。啟用應用程式型粘性後，負載平衡器會根據選擇的演算法，將第一個請求路由到目標群組內的目標。目標預期會設定與負載平衡器上設定的 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，依此類推。

------
#### [ Console ]

**啟用應用程式型黏性**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing** (負載平衡) 中，選擇 **Target Groups (目標群組)**。

1. 選擇目標群組的名稱，以開啟其詳細資訊頁面。

1. 在**屬性**索引標籤中，選擇**編輯**。

1. 在**目標選取組態**下，執行下列動作：

   1. 選取**開啟黏性**。

   1. 在**粘性類型**中，選取**應用程式型 Cookie**。

   1. 針對 **Stickiness duration (黏性持續期間)**，指定介於 1 秒到 7 天之間的值。

   1. 在**應用程式 Cookie 名稱**中，輸入應用程式型 Cookie 的名稱。

      請勿使用 `AWSALB`、`AWSALBAPP`、或 `AWSALBTG` 作為 Cookie 名稱；它們預留供負載平衡器使用。

1. 選擇**儲存變更**。

------
#### [ AWS CLI ]

**啟用應用程式型黏性**  
使用 [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) 命令搭配以下屬性：
+ `stickiness.enabled`
+ `stickiness.type`
+ `stickiness.app_cookie.cookie_name`
+ `stickiness.app_cookie.duration_seconds`

```
aws elbv2 modify-target-group-attributes \
    --target-group-arn {{target-group-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={{300}}"
```

------
#### [ CloudFormation ]

**啟用應用程式型黏性**  
更新 [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) 資源以包含下列屬性：
+ `stickiness.enabled`
+ `stickiness.type`
+ `stickiness.app_cookie.cookie_name`
+ `stickiness.app_cookie.duration_seconds`

```
Resources:
  myTargetGroup:
    Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
    Properties:
      Name: my-target-group
      Protocol: HTTP
      Port: 80
      TargetType: ip
      VpcId: !Ref myVPC
      TargetGroupAttributes: 
        - 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: "{{300}}"
```

------

**手動重新平衡**

縱向擴展時，如果目標數量大幅增加，則由於粘性，可能會導致負載分配不均衡。在這種情況下，可以使用下列兩個選項重新平衡目標上的負載：
+ 在由應用程式產生的 Cookie 上設定早於目前日期和時間的到期時間。這可防止用戶端將 Cookie 傳送至 Application Load Balancer，這會重新啟動建立黏性的程序。
+ 在負載平衡器的應用程式型黏性組態上設定較短的持續時間，例如 1 秒。即使目標設定的 Cookie 未過期，這也會強制 Application Load Balancer 重新建立黏性。