【東東老師 X 思想科技】檢查 Load Balancer 各項設定

(一) SSL 憑證

當我們設定好 DNS，需要一點時間等它生效，我們可以用 Google Admin Toolbox 檢查，這是一個免費的工具，任何人都可以直接使用。我們直接點擊 “Dig”。

接下來直接在 “名稱” 裡輸入網域，然後點擊 “A”，它就會解析這個網域是否指向某個 IP 位址，像我在輸入之後，它就解析到 LB 的 IP 位址，代表 DNS 已經生效了。

我們再回去看憑證的狀態，因為 Google 也確認我的網域有解析到正確的 IP 位址，所以 SSL 憑證就變成 “Active” 的狀態。你會看到它的到期日是 2024/12/1，但是不用擔心，等到那一天，憑證會再自動展期，我們什麼事情都不用做。

最後我們就可以在瀏覽器輸入網址，會看到網頁終於顯示出來了。

我們可以再點擊網址左邊的圖示，再點擊「已建立安全連線」，會展開安全性的頁面，看到「憑證有效」，再點擊下去，就會看到完整的憑證資訊。其中 Google Trust Services 就是 Google 成立的根憑證授權單位，代表 Google 背書證明憑證是有效的。

還可以再點擊詳細資訊，然後點「序號」，可以看到「欄位值」顯示序號。這裡可以確認這個憑證，和我們在 LB 上憑證頁面的序號一模一樣，證明這真的是我剛建立的憑證。

(二) Cloud CDN

因為我們在後端還有勾選 Cloud CDN，我們可以在 Chrome 瀏覽器最右邊點擊三個小點，

再點擊「更多工具」=>「開發人員工具」，來測試 CDN 的效果。

你會看到右邊顯示一堆按鈕，這時我們再重新整理網頁。

你會看到右邊的圖表區域產生變化，我們再點擊 Network => Index.html => Headers 會看到詳細訊息，例如 Status Code 為 “304 Not Modified”，平常我們看到應該是 “200 OK”，304 則代表 Index.html 這個網頁已經被 Cloud CDN 暫存，瀏覽器確認內容是一樣的，沒有更新，所以就會繼續使用本機的版本。

再往下看 Cache-Control 的部分，看到 “max-age=3600”，表示這個內容會在瀏覽器存在一個小時，跟我們在 Cloud CDN 設定的 Client TTL 長度是相同的。

我們也可以從 Cloud Logging 來看，點擊 “Application Load Balancer”， 然後展開狀態為 304 的 Log，可以看到一些關於 Cloud CDN 的內容，例如 “CacheLookup: True” 代表 CDN 有查詢該內容是否在 CDN 節點上，只代表有執行”查詢”動作。

而 “CacheHit: True” 則代表找到了，俗稱「快取命中」。最下方還能看到 “StatusDetails: “Response_From_Cache””，代表內容是從 CDN 節點回覆的。由此可證明我們的 Cloud CDN 有設定正確，讓它能夠有效運作。

(三) Cloud Armor

我們直接使用 Cloud Shell 來做為發送流量的機器，點擊右上角的圖示：

待 Cloud Shell 視窗開啟完成後，輸入以下指令，更新套件位置，這樣才能讓它從最新的位置自動下載並安裝軟體。

sudo apt-get update

接下來安裝壓力測試軟體 Siege： 

sudo apt-get install siege

我們在前面後端設定中，是設定每分鐘超過 500 的 Request，超求就禁止存取。

所以我們故意設定發出 550 個 Request，讓它超過 500 次，指令如下：

siege -c 5 -r 110 https://web1.dongdonggcp.com/

c 代表同時執行多少個執行緒。

r 代表每個執行緒發出的請求。

兩者相乘總共 550 次。

由於次數不高，差不多 4 秒左右就已送出 550 個 Request 了。

然後我們去看 Cloud Armor，也看到它有一個 Policy 在運作，而且已經套用到 “bk-1” 這個後端。

接著我們再點擊 Policy 名稱：

進去後看到 Logs 的頁籤，點擊該頁籤，再點擊 “View Policy Logs”：

你會看到它開打 Cloud Logging 的畫面，並且自動套用查詢和 Cloud Armor Policy 有關的 Log 語法，看到 ALB 總共收到 550 次 Request，其中 507 次是正確的，而另外 43 次則有 403 錯誤。

我們再點開其中一筆 Log，看到 Request 被 Cloud Armor 擋住，它在 “EnforcedSecurityPolicy” 有相關細節，說明現在已經觸發 “Throttle” 節流動作，動作執行的結果是 “DENY” 拒絕 Request。代表 Cloud Armor 的設定是有生效的，對於超過上限的 Request 有執行阻擋動作。

(四) Autoscale 功能

最後我們要確認最重要的功能，到底 Autoscale 能不能如期擴充機器。 

我們這次就不設上限，每秒 250 個 Request，一直打到它長出新的機器為止：

siege -c 250 https://web1.dongdonggcp.com/

執行之後，游標會不見，是正確的，表示現在正在發送流量。我們可以直接去 IG 的頁面觀查，點擊 IG 的名字。

我們看到 IG 一直保持在 1 台機器，因為 CPU 使用率一直到不了 60%，大概只有 18% 左右。所以沒有觸發 Autoscale。

那我們就直接點擊 IG 的 “Edit”，把 “Target CPU Utilization” 從 60% 改成 5%，再按下 “Save”。

讓它的 CPU 只要有一點負載，就輕易觸發 Autoscale。

然後我們再持續觀察，就看到它直接從一台機器，一口氣長到三台機器。而每一台機器的 CPU 使用率其實沒有很高，約 18% 左右，因為已經超過 5% 所以就觸發了 Autoscale，三台機器的加總 CPU 使用率為 54%，而每台機器的 Capacity 是 5%，三台上限為 15%，所以系統提示機器數量已經到達上限，提示你要不要再增加更多機器。

我們可以點擊 IG 的 “Overview” 看到有 IG 底下有三台機器，或是去 “VM Instances” 也會看到相同的三台機器。

所以我們已經確認成功觸發了 Autoscale，那就回到 Cloud Shell 按下 “Ctrl + C” 停止 Siege，它也提供相關統計資料，顯示總共發出了 25 萬次的 Request，每個 Request 平均回應時間為 1.71 秒，算是比較慢的，因為機器規格很小，而且打的次數又快，所以回應速度變慢許多。然後它又說成功次數和 Request 總數一模一樣，表示所有的 Request 都有被我們的網站接住。

我們也看一下 Cloud Logging，可以看到總共收到的 Request 數量，因為我在壓力測試之前也做過其他測試，所以數量比較多。

所以整個測試就完成了。

最後我們這個範例，在整個 GCP 的 LB 架構如下，其中藍色字代表我們建立好的各項服務所提供的功能：

文章轉載自《東東GCP 教學》網站