接下來更重要的是,把服務照順序刪除。不要放著讓它跑啊,整個架構都會計費的!至於要刪除也是有順序的,順序錯是會卡住無法刪除的:
(一) 刪除 Load Balancer、憑證、後端
因為不能一次刪兩個 LB,所以先選 “lb-1” 來刪除,它會順便問你要不要把憑證跟後端都刪除。憑證跟後端放著不會產生費用,憑證是有公信力的建議留著。而後端則是必須要刪除,要不然 IG 會無法刪除。

截圖自 GCP Console
刪完記得再刪除負責把 HTTP 轉到 HTTPS 的 “fe-1-redirect”。

(二) 刪除 Cloud Armor 的 Policy
當我們進入 Policy 的頁面應該會看到 Target 的數量為 0,如果前面 LG 還沒刪掉,Target 數量就是 1,那 Policy 是無法刪除的,再等 1~2 分鐘等它歸 0。要注意這部分容易忘記,因為當初我們是在 LB 後端設定的,根本沒來過 Cloud Armor 的頁面,所以非常容易忘記。

截圖自 GCP Console
(三) 釋放靜態 IP
因為 LB 刪除了,所以原本靜態的 IP 會變成閒置狀態,要注意,IP 分配給 LB 使用時,IP 是免費的,但如果閒置的話,它的費用會比在 VM 上使用還貴,這也很容易忘記喔!另外釋放 IP 的按鈕在最旁邊,要把視窗拉開才會看到。

截圖自 GCP Console
(四) 刪除 Instance Group
再來我們要刪除 IG 了,刪除之後務必確認它是否刪除成功。

截圖自 GCP Console
像是這個例子,我看到下面這個錯誤,”apache-ig-1” 這個 IG,被相同名字的 Autoscaler 綁住,一直處於調整機器數量的狀態,所以無法刪除。

截圖自 GCP Console=
因為 IG 的 CPU Capacity 之前調整到 5%,有點太低,偏偏開關機這件事情,耗用的 CPU 太多,所以讓 IG 一直不斷在開機又關機,變得無法刪除。再改回 60%,讓 Autoscale 的門檻提高,不要再動不動就 Scale。

截圖自 GCP Console
後來設定好之後,IG 就成功刪除了。
(五) 刪除 Instance Template
Instance Template 不會產生任何費用,有需要留著也沒關係。

截圖自 GCP Console
(六) 刪除 Image
Image 是會佔用一點點空間的,但是沒多少費用,要刪不刪都可以。

截圖自 GCP Console
(七) 刪除原本用來做 Image 的主機和 Disk
機器沒開是不會計費的,但它的 Disk 還是會有費用,你可以看情況要不要刪。

截圖自 GCP Console
(八) 刪除 DNS 記錄
如果你是用 Hinet、GoDaddy 或 Namecheap,DNS 記錄不會有額外費用,如果是 Cloud DNS,有人持續在查詢網域的話,會依照查詢次數計費,不過查詢一百萬次才會有 0.4 美金,費用不高。但 DNS 記錄留在那邊容易誤會,以為你還有主機是用這個網域,為了管理的目的,還是建議刪乾淨比較好。

截圖自 GCP Console
五、結論
我們終於完成整個 Load Balacer 的建立過程,你會發現整個架構運作起來,有非常多要考慮的地方,除了 Instance Group 和 Instance Template 相關的前置作業要做,還有 Google 的 SSL 憑證、Cloud CDN 和 Cloud Armor 功能,要搭配 LB 才能運作。
前前後後有很多互相關聯的設定,牽一髮而動全身,設錯要改還很麻煩,務必要弄懂所有細節,或是多做幾次才能駕輕就熟。當你整個做完一遍,你就算是掌握了 GCP 的核心功能 – Autoscale,以後面對高流量的服務,就可以透過 LB 和 IG 的設定,來打造一個高可用的雲端架構。
如果對於 LB 的原理還不了解,可以參考《超越負載壓力,提升網站效能!為什麼 GCP Load Balancing 是你最佳的選擇?》這篇文章。
文章轉載自《東東GCP 教學》網站
📚 Cloud Load Balancer 相關文章
🔗 【東東老師 X 思想科技】如何替網站設定 GCP Load Balancer 確認架構規劃問題?






