iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 1
0
自我挑戰組

AWS架構應用系列 第 15

ASG 步驟縮放政策 Step scaling policies - Day15

  • 分享至 

  • xImage
  •  

ASG 步驟縮放政策 Step scaling policies - Day15

今天詳細介紹 Auto Scaling Group 的 Step scaling policies,下圖為我們要實作的環境,為安全考量我們將 Auto Scaling Group 放到私有子網,而 ELB 則是需要對外開放所以放在公有子網,考慮容錯,所以跨兩個可用區。

具有自動擴展功能的應用程式架構
圖 1、具有自動擴展功能的應用程式架構

Aoto Scaling Group 建置

接下來的操作其實跟 ASG 目標跟蹤縮放政策 Target tracking scaling policies - Day 14類似,可以參照該網址,但為方便起見我們還是操作一遍

  1. 建置 VPC 與相關的子網 - 請參閱 Amazon VPC 練習 - Day07
  2. 新增 EC2 實例 - 請參閱 Amazon Elastic Compute Cloud (EC2) - Day08
  3. 新增 AMI - 建置一個 AMI 範本供後續的 Launch Configuration 使用

根據以上所建立的 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 實例的功能符合要求
圖 2、確認 EC2 實例的功能符合要求

到 EC2 主控台,選擇左邊選單中的 執行個體,再選擇剛剛建立的 EC2 實例,按滑鼠右建,選擇 Image > Create Image,接著輸入以下內容建可以建立一個 AMI Image

Image name : ithomeAMI
Image description : ithome Web Server AMI

新增 AMI
圖 3、新增 AMI

輸入 AMI 資訊
圖 4、輸入 AMI 資訊

  1. 新增 Application Load Balancer (ALB) - 主要就是完成負載平衡的工作,可以分擔流量以及容錯。

進入 EC2 主控台,在左手選單下方選擇負載平衡器,並在右邊按下 Create Load Balancer

新增負載平衡器
圖 5、新增負載平衡器

我們選擇 Application Load Balancer (ALB)

選擇 Application Load Balancer
圖 6、選擇 Application Load Balancer

接下來需要六個步驟來設定 ALB
步驟 1. Configure Load Balancer : 建議先看一下圖一,可以發現負載平衡器會跨越兩個可用區,因為唯有如此才能完成高可用性的設定,所以除了設定名字外,記得選擇 VPC (PS:一個區域可以有多個 VPC )以及可用區

Name : ithomeALB
Availability Zones
VPC : vpc-0bb7004b67556d0da (172.16.0.0/16) | ithomeVPC
Availability Zones
ap-southeast-1a: subnet-0f1df807467b642f6 (ithome public subnet 1)
ap-southeast-1b: subnet-06f56dccb2a9cfcf0 (ithome public subnet 2)

設定負載平衡器的涵蓋範圍
圖 7、設定負載平衡器的涵蓋範圍

步驟 2. Configure Security Settings : 沒有設定

步驟 3. Configure Security Groups : 設定安全組,選擇先前設定的安全組,跟原來的 EC2 實例一樣

Assign a security group: Select an existing security group
_ithome_web_SG _

設定負載平衡器安全組
圖 8、設定負載平衡器安全組

步驟 4. Configure Routing : 設定要將收到的流量轉給哪個對象,因為 AWS 會將這些對象設定成一個目標群 (Traget Group) ,所以我們先指定一個目標群,到後面再來設定這個目標群的內容

Target group : New target group
Name : ithomeTargetGroup

指定負載平衡器目標群
圖 9、指定負載平衡器目標群

步驟 5. Register Targets : 不要指定目標群的內容,因為目標群的實例將會由 Auto Scaling Group 靜態或動態產生,如下圖

負載平衡器目標群內容不指定
圖 10、負載平衡器目標群內容不指定

步驟 6. Review

完成設定後,記得在回到負載平衡器得主畫面,這時候就可以看到剛剛建立的負載平衡器,這時候就可以直接複製 DNS Name 的欄位,如下圖,當作是網址,直接讀取網頁,但請注意,要等一段時間,因為 DNS 註冊需要一段時間,所以可能要等五分鐘後, DNS 的 TTL 到期後會再去抓取的時候,這時候網頁才會正常。

負載平衡器的內容
圖 11、負載平衡器的內容

  1. 新增 Launch Configuration - 主要是提供 Auto Scaling Group 啟動實例的範本,用來設定目標群內的 EC2 實例的啟動組態

到 EC2 主控台,選擇左邊選單中的 Launch Configuration,按下右邊的建立啟動組態按鈕

建立啟動組態
圖 12、建立啟動組態

完成啟動組態設定

名稱 : ithomeLC
AMI : ithomeAMI
執行個體類型 : t2.micro (1 vCPU, 1 GiB, 僅 EBS)
監控 (Monitoring) : 在 CloudWatch 中啟用 EC2 執行個體詳細監控 #重要!!!啟用詳細監控之後,當您使用此啟動組態時,Auto Scaling 群組可以具備相關擴展政策,以 1 分鐘的頻率在 Amazon EC2 執行個體指標上擴展。
指派安全群組 :
選取現有的安全群組
ithome_web_SG
金鑰對選項 :
選擇現有的金鑰對
ithome

啟動組態設定畫面
圖 13、啟動組態設定畫面

  1. 新增 Auto Scaling Group

到 EC2 主控台,選擇左邊選單中的 Auto Scaling 群組,按下右邊的建立 Auto Scaling 群組按鈕,接下來需要完成七個步驟來完成Auto Scaling 群組的設定

步驟 1. 選擇啟動範本或組態

Auto Scaling 群組名稱 : ithomeACG
啟動組態 : ithomeLC (記得一定要先按下轉換至啟動組態,才會切換到選擇啟動組態)

選擇啟動組態
圖 14、選擇啟動組態

步驟 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

網路組態設定
圖 15、網路組態設定

步驟 3 (選用) 設定進階選項

負載平衡
勾選 啟用負載平衡
_Application Load Balancer _
為您的負載平衡器選擇目標群組 : ithomeTargetGroup
運作狀態檢查 - 選用
運作狀態檢查類型 : 勾選 EC2ELB
運作狀態檢查寬限期 : 150
其他設定 - 選用
監控 : 勾選 在 CloudWatch 中啟用群組指標集合

負載平衡設定
圖 16、負載平衡設定

步驟 4 (選用) 設定群組大小和擴展政策

群組大小 - 選用
變更所需的容量,以指定 Auto Scaling 群組的大小。您也可以指定最小和最大容量限制。所需的容量必須在限制範圍內。
所需容量 : 2 # 指的是一開始啟動 Auto Scaling Group 會啟動的 EC2 實例數量
容量下限 : 1 # 指的是 Auto Scaling Group 最少正在執行的 EC2 實例數量
容量上限 : 10 # 指的是 Auto Scaling Group 最多正在正常執行的 EC2 實例數量

擴展政策 - 選用
選擇

等一下自行設定步驟縮放政策 Step scaling policies,所以現在先選無

設定群組大小和暫不設定擴展政策
圖 17、設定群組大小和暫不設定擴展政策

步驟 5 (選用) 新增通知

沒有設定

步驟 6 (選用) 新增標籤

標籤
金鑰 : Name # 注意大小寫是不同的
數值 : itHomeWebServer

設定新啟動的 EC2 實例的名稱
圖 18、設定新啟動的 EC2 實例的名稱

步驟 7. 檢閱

再次確認上述資料有無錯誤後,確認新增

設定步驟縮放政策 Step scaling policies

  1. 建立 CloudWatch Dashboard 儀表板
    按下上方的服務按鈕,選擇 CloudWatch ,進入 CloudWatch 主控台後,按下右方功能選單儀表板,按下建立儀表板後,輸入要觀察的衡量指標值-服務的實體總數 (GroupInServiceInstances), CPU 使用率 (CPUUtilization)。

儀表板名稱: ithomeSimplePolicyDashboard

建立 CloudWatch 儀表板畫面
圖 19、建立 CloudWatch 儀表板畫面

設定 CloudWatch 儀表板中 Widget 類型
圖 20、設定 CloudWatch 儀表板中 Widget 類型

Widget 的資料來源選擇指標值 (Metrics)

設定 Widget 的資料來源
圖 21、設定 Widget 的資料來源

指標值設定為 Singapore > 全部 > Auto Scaling > GroupInServiceInstances,要注意要確定看到上面的圖型有資料才能確定已經正確找到指標值

設定哪一個指標值
圖 22、設定 GroupInServiceInstances 指標值

指標值設定為 Singapore > 全部 > EC2 > 依照 Auto Scaling 群組 > CPUUtilization

設定哪一個指標值
圖 23、設定 CPUUtilization 指標值

設定完畢後,務必記得儲存 CloudWatch 儀表板。

完成 CloudWatch 儀表板設定
圖 24、完成 CloudWatch 儀表板設定

  1. 建立 CloudWatch Alerm 警示

在 CloudWatch 主控台,按下右方功能選單警示,按下建立警示後,我們建立兩個警示一個是新增實例 (Scale out),閾值是 CPU 使用率 > 60%,一個是減少實例 (Scale In),閾值是 CPU 使用率 < 30%。建立指標有四個步驟,分別如下:

步驟 1. 指定指標和條件
指定指標的設定方式跟內容跟儀表板一樣,唯一需要注意的是期間預設是5分鐘,記得改成 1 分鐘。

CloudWatch Alerm 指定指標
圖 25、CloudWatch Alerm 指定指標

條件
閾值類型 : 靜態
每當 CPUUtilization 為 : 大於 > 閾值
定義閾值 : 60
要發出警示的資料點 : 1 出於 1 # 這個意思是第一個 1 是得到的資料數,第二個 1 是採樣資料的次數,舉例來說,如果設定 1 出於 2,表示採樣 2 次,只要有一次的 CPUUtilization > 60%,就會發出警示

CloudWatch Alerm 指定條件
圖 26、CloudWatch Alerm 指定條件

步驟 2. 設定動作
記得移除預設的通知動作,不移除的話也可以,要指定 email 以及到 指定的 email 去訂閱 SNS (Simple Notification Service) 主題。

移除 CloudWatch Alerm 預設通知動作
圖 27、移除 CloudWatch Alerm 預設通知動作

步驟 3. 新增名稱和描述

警示名稱: ithomeStepScalingOutAlerm
警示描述 - 選用: ithome Step ScalingOut policy Alerm

步驟 4. 預覽並建立
再次確認資料是否正確

相同方法在建立另一個警示

閾值是 CPU 使用率 < 30%
警示名稱: ithomeStepScalingInAlerm
警示描述 - 選用: ithome Step ScalingIn policy Alerm

  1. 建立 Auto Scaling Group 擴展政策
    按下上方的服務按鈕,選擇 EC2 ,進入 EC2 主控台後,按下右方功能選單Auto Scaling Groups,按下剛剛建立的ithomeACG,按下方頁簽的自動調整規模後,在擴展政策中選擇新增政策

新增Auto Scaling Group的擴展政策
圖 28、新增Auto Scaling Group的擴展政策

建立擴展政策
政策類型: 步驟擴展
擴展政策名稱: ithomeStepOutPolicy
CloudWatch 警示: ithomeStepScalingOutAlerm
採取行動: 新增
200 群組百分比
執行個體需求: 150 納入指標之前的暖機秒數

步驟擴展政策擴展設定
圖 29、步驟擴展政策擴展設定

建立擴展政策
政策類型: 步驟擴展
擴展政策名稱: ithomeStepInPolicy
CloudWatch 警示: ithomeStepScalingInAlerm
採取行動: 移除
50 群組百分比
執行個體需求: 150 納入指標之前的暖機秒數

步驟擴展政策縮減設定
圖 30、步驟擴展政策縮減設定

觀察目標追蹤擴展政策的運作

我們列出目前的設定

  • 在 Auto Scaling Group 中 - 冷卻時間: 300 秒、運作狀態檢查寬限期: 150 秒;
  • 在 步驟擴展政策中 - 暖機時間: 150 秒
  • 步驟擴展政策擴展設定 - CPUUtilization > 60%,新增 200% 的目前容量,舉例說目前有 1 台實例,那會再啟動 2 台實例
  • 步驟擴展政策縮減設定 - CPUUtilization < 30%,移除 50% 的目前容量,舉例說目前有 10 台實例,那會移除 5 台實例
  • CloudWatch 警示設定為適用於 1 分鐘 內的 1 資料點,也就是只要檢查到 1 次就立刻觸發擴縮政策
  • CloudWatch - 監控週期: 60 秒
  • Target groups - Deregistration delay: 120 seconds
  • 實例啟動時間 - 變動的

於是在13:52分拉高 CPU 使用率,預期應該會在 1~2 分鐘左右,約 13:53 ,發出 CloudWatch 警示。我們來實際驗證一下,到 EC2 主控台,選擇左邊選單中的 Auto Scaling Groups,選擇指定的自動縮放群 ithomeASG ,按下下方的 活動(Activation) 頁簽,在這個頁簽會找到活動歷史記錄。如下圖所示

Auto Scaling Group 活動歷史記錄-擴展
圖 31、Auto Scaling Group 活動歷史記錄-擴展

根據 CloudWatch 儀表板的觀察,整個 CPU 使用率在 14:05分下降到 30% 以下,所以應該會在 1~2 分鐘左右觸發縮減設定,以下兩張圖說明整個步驟擴展政策的執行狀況,很明顯的使用步驟擴展的效能要求以及成本考量,都比目標追蹤擴展政策來的好。

CloudWatch 儀表板
圖 32、CloudWatch 儀表板

Auto Scaling Group 活動歷史記錄-縮減
圖 33、Auto Scaling Group 活動歷史記錄-縮減

步驟擴展政策

  • 從實際拉高 CPU 使用率,到擴展到群組最大上限 10 的時間為 13:52 -> 14:04 ~ 12 minutes
  • 發出 CloudWatch 縮減警示,到縮減到群組最小下限 1 的時間為 14:07 -> 14:21 ~ 14 minutes

目標追蹤擴展政策

  • 從實際拉高 CPU 使用率,到擴展到群組最大上限 10 的時間為 13:33 -> 13:56 ~ 23 minutes
  • 發出 CloudWatch 縮減警示,到縮減到群組最小下限 1 的時間為 13:43 -> 14:14 ~ 31 minutes

References


上一篇
ASG 目標跟蹤縮放政策 Target tracking scaling policies - Day 14
下一篇
ASG 簡單縮放政策 Simple scaling policies - Day16
系列文
AWS架構應用24
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言