今天詳細介紹 Auto Scaling Group 的 Target tracking scaling policies，下圖為我們要實作的環境，為安全考量我們將 Auto Scaling Group 放到私有子網，而 ELB 則是需要對外開放所以放在公有子網，考慮容錯，所以跨兩個可用區。
圖一、具有自動擴展功能的應用程式架構
有接下來的操作其實跟 Auto Scaling Up/Down 自動擴展或縮減 - Day12類似，可以參照該網址，但為方便起見我們還是操作一遍
根據以上所建立的 EC2 實例，我們必須在該實例上進行一些雛型系統配置，作為將來檢驗之用
系統設定
# 安裝套件 httpd php
sudo yum -y install httpd php
# 啟動 Web Server
sudo systemctl start httpd
# 設定 Web Server 為系統服務，可在下次重開機時自動啟動
sudo systemctl enable httpd
應用程式設定
首頁程式 index.php，可以增加主機CPU負載的鏈結
<center>
<p>
<a href="put-cpu-load.php" target="_blank">Increase CPU Load</a>
</p>
<table class='table table-bordered'>
<tr><th>Meta-Data</th><th>Value</th></tr>
<?php
#The URL root is the AWS meta data service URL where metadata
# requests regarding the running instance can be made
$urlRoot="http://169.254.169.254/latest/meta-data/";
$instanceId = file_get_contents($urlRoot . 'instance-id');
$availabilityZone = file_get_contents($urlRoot . 'placement/availability-zone');
# Get the instance ID from meta-data and print to the screen
echo "<tr><td>InstanceId</td><td><i>" . $instanceId . "</i></td><tr>";
# Availability Zone
echo "<tr><td>Availability Zone</td><td><i>" . $availabilityZone . "</i></td><tr>";
?>
</table>
</center>
產生 CPU 負載的程式 put-cpu-load.php
<?php
# Start PHP Session to keep track of whether or not load is getting generated
session_start();
echo "<meta http-equiv=\"refresh\" content=\"5,URL=./put-cpu-load.php\" />";
$idleCpu = exec('vmstat 1 2 | awk \'{ for (i=1; i<=NF; i++) if ($i=="id") { getline; getline; print $i }}\'');
if ($idleCpu > 50) {
echo exec('dd if=/dev/zero bs=100M count=500 | gzip | gzip -d > /dev/null &');
echo "Generating CPU Load! (auto refresh in 5 seconds)";
}
else {
echo "Under High CPU Load! (auto refresh in 5 seconds)";
}
echo "<br /><p>Current CPU Load: <b>";
echo 100-$idleCpu;
echo "%</b></p>";
?>
透過瀏覽器確認功能無誤，確認首首以及產生 CPU 負載測試頁均可正常運行，如下圖顯示
圖二、確認 EC2 實例的功能符合要求
到 EC2 主控台，選擇左邊選單中的 執行個體，再選擇剛剛建立的 EC2 實例，按滑鼠右建，選擇 Image > Create Image，接著輸入以下內容建可以建立一個 AMI Image
Image name : ithomeAMI
Image description : ithome Web Server AMI
圖三、新增 AMI
圖四、輸入 AMI 資訊
Register Targets: 指定目標群的內容，將先前設定的兩個 EC2 實例指定到上面新建立的目標群
圖五、指定負載平衡器目標群內容
但因為這次的目標群是不固定的，會在下一個步驟再設定，所以應該是不要指定，如下圖
圖六、負載平衡器目標群內容不指定
到 EC2 主控台，選擇左邊選單中的 Launch Configuration，按下右邊的建立啟動組態按鈕
圖七、建立啟動組態
完成啟動組態設定
名稱 : ithomeLC
AMI : ithomeAMI
執行個體類型 : t2.micro (1 vCPU, 1 GiB, 僅 EBS)
監控 (Monitoring) : 在 CloudWatch 中啟用 EC2 執行個體詳細監控 #重要！!!啟用詳細監控之後，當您使用此啟動組態時，Auto Scaling 群組可以具備相關擴展政策，以 1 分鐘的頻率在 Amazon EC2 執行個體指標上擴展。
指派安全群組 :
選取現有的安全群組
ithome_web_SG
金鑰對選項 :
選擇現有的金鑰對
ithome
圖八、啟動組態設定畫面
到 EC2 主控台，選擇左邊選單中的 Auto Scaling 群組，按下右邊的建立 Auto Scaling 群組按鈕，接下來需要完成七個步驟來完成Auto Scaling 群組的設定
步驟 1. 選擇啟動範本或組態
Auto Scaling 群組名稱 : ithomeACG
啟動組態 : ithomeLC (記得一定要先按下轉換至啟動組態，才會切換到選擇啟動組態)
圖九、選擇啟動組態
步驟 2. 進行設定
選擇私有子網
VPC : vpc-0bb7004b67556d0da (172.16.0.0/16) | ithomeVPC
子網路 :
ap-southeast-1a | subnet-0c60019adc4bec5f6 (ithome private subnet 1) 172.16.1.0/24
ap-southeast-1b | subnet-0b047b309432d952c (ithome private subnet 2) 172.16.2.0/24
圖十、網路組態設定
步驟 3 (選用) 設定進階選項
負載平衡
勾選 啟用負載平衡
_Application Load Balancer _
為您的負載平衡器選擇目標群組 : ithomeTargetGroup
監控 : 勾選 在 CloudWatch 中啟用群組指標集合
圖十一、負載平衡設定
步驟 4 (選用) 設定群組大小和擴展政策
群組大小 - 選用
變更所需的容量，以指定 Auto Scaling 群組的大小。您也可以指定最小和最大容量限制。所需的容量必須在限制範圍內。
所需容量 : 2 # 指的是一開始啟動 Auto Scaling Group 會啟動的 EC2 實例數量
容量下限 : 1 # 指的是 Auto Scaling Group 最少正在執行的 EC2 實例數量
容量上限 : 10 # 指的是 Auto Scaling Group 最多正在正常執行的 EC2 實例數量
擴展政策 - 選用
選擇 目標追蹤擴展政策
選擇所需的結果，並將其保留至擴展政策中，視需要新增和移除容量，以實現該結果。
擴展政策名稱: itHomePolicy
指標類型 : 平均 CPU 使用率
目標數值 : 50
納入指標之前的暖機秒數 : 120
這個設定的意思是說當整個 Auto Scaling Group 的平均 CPU 使用率為 50% 的話，會擴展一台新的 EC2 實例來降低整個系統的負荷
納入指標之前的暖機秒數這個數字是說，當新增一台新的 EC2 實例，從啟動到可以被註冊到目標群的時間
圖十二、設定群組大小和擴展政策
步驟 5 (選用) 新增通知
沒有設定
步驟 6 (選用) 新增標籤
標籤
金鑰 : Name # 注意大小寫是不同的
數值 : itHomeWebServer
圖十三、設定新啟動的 EC2 實例的名稱
步驟 7. 檢閱
再次確認上述資料有無錯誤後，確認新增
當完成上述步驟後就算是完成 Auto Scaling Group 的建置，但問題是他是如何運行的，讓我們再看一次他的運行架構，下圖描述了 AWS 自動擴展或縮減架構， ELB 對外提供服務，透過 Cloud Watch 來監控 ELB 目前的狀態，根據使用者是先定義好的 Auto Scaling Policy 來通知 Auto Scaling 是否要新增 EC2 實例，如果需要，則從 Launch Configuration 所定義好的 EC2 實例進行啟動，並放置到 ELB 的 target group 中。
圖十四、AWS 自動擴展或縮減架構
簡單來說，驅動整個 Auto Scaling Group 運行的關鍵服務其實是 CloudWatch 警示，我們切換到 CloudWatch 的主控台看看，根據剛剛建立的目標追蹤擴展政策，產生了甚麼影響。按下上方的服務按鈕，選擇 CloudWatch ，進入CloudWatch主控台後，按下右方功能選單警示，應該可以看到兩個剛剛建立的 CloudWatch 警示，分別是 TargetTracking-ithomeASG-AlarmLow-xxx , TargetTracking-ithomeASG-AlarmHigh-xxx ，這兩個警示是設定目標追蹤擴展政策後，系統自動生成的。
圖十五、目標追蹤擴展政策建立的 CloudWatch 警示
檢視這兩個警示可以發現一些細節，我們先看一下底下這張擴展政策觸發示意圖，當我們預期的事件發生時，比方說平均 CPU 使用率 60% 是 9:00:20，而我們設定的 CloudWatch 監控週期是 1 分鐘，所以會在 9:01:00， CloudWatch 才發現目前的平均 CPU 使用率已經超過 60% ，但請注意，並不是現在就發出 CloudWatch 警示，請注意看上圖，它觸發的條件為 CPUUtilization > 50 (適用於 3 分鐘 內的 3 資料點) ，我們忽略 CPU 使用率的值，關注後面的 3 分鐘 內的 3 資料點，這說明系統發出 CloudWatch 警示的時間會是在9:03:00，另一個是 CloudWatch 警示並沒有在設定中是系統自動生成，會在監控到 CPUUtilization < 42.5 後連續 15 分鐘，才發出 CloudWatch 警示通知關閉 EC2 實例。
圖十六、擴展政策觸發示意圖
接下來我們來確認這樣的想法是否正確，於是在13:33分拉高 CPU 使用率，預期應該會在 3~4 分鐘左右，約 13:37 ，發出 CloudWatch 警示。我們來實際驗證一下，到 EC2 主控台，選擇左邊選單中的 Auto Scaling Groups，選擇指定的自動縮放群 ithomeASG ，按下下方的 活動(Activation) 頁簽，在這個頁簽會找到活動歷史記錄。如下圖所示
圖十七、Auto Scaling Group 活動歷史記錄
我們列出目前的設定
2020 九月 14, 01:37:19 下午 +08:00 － 觸動 CloudWatch 警示，啟動 1 個新實例， 主機從 1 > 2
2020 九月 14, 01:39:51 下午 +08:00 － 主機 2 啟動完成，實例啟動時間 2:32
2020 九月 14, 01:40:19 下午 +08:00 － 觸動 CloudWatch 警示，啟動 2 個新實例， 主機從 2 > 4
2020 九月 14, 01:42:50 下午 +08:00 － 主機 3 啟動完成，實例啟動時間 2:31
2020 九月 14, 01:43:18 下午 +08:00 － 觸動 CloudWatch 警示，啟動 4 個新實例， 主機從 4 > 8
從上面這些時間，我們可以發現每次觸動 CloudWatch 警示的時間間隔是有規律的，約 3 分鐘左右，這主要的影響因子是暖機時間跟實例啟動時間。另外一個發現是啟動主機數量是呈現倍數 1 > 2 -> 4，這符合官方手冊說明的方式：為了確保應用程式可用性，Auto Scaling Group 可以按比例快速地向外擴展到指標，但向內擴展時會比較平緩。
透過下圖的 CloudWatch 儀表板，可以看出整個系統在 13:43 CPU使用率就下降為 0，依照 CloudWatch 警示的設定，應該會在 15~16分後開始進行向內擴展，觀察活動歷史記錄可以發現以下數據，說明在時間上的確如此。接著我們觀察關機時間，卻發現比開機時間還長，約5~6 分鐘，原因應該是受冷卻時間與 Deregistration delay ，可以看圖十九，在 Target group 中對於每個實體要解除這個目標群時，有個解除註冊延遲( Deregistration delay )，預設的解除註冊延遲為 300 秒，約 5 分鐘。
2020 九月 14, 01:59:51 下午 +08:00 － 觸動 CloudWatch 警示，關閉 1 個新實例
2020 九月 14, 02:05:36 下午 +08:00 － 關閉主機完成，關閉時間 5:45
圖十八、CloudWatch 儀表板
圖十九、 Target group 設定
References
iThome鐵人賽
看影片追技術