雲端架構的節省成本心法

由於我們公司跟微軟和Google都有一定的合作關係，所以同時使用Azure和GCP。

Azure我們只是創建一個虛擬機器做FTP Server，由於開帳號的人只會用Windows，因此就選擇使用Windows 2019 DataCenter版本。

GCP是我們主要雲端部署的平台，主要使用Cloud Run、Cloud SQL還有VPC等等，同時使用Google Firebase作為Angular的Hosting。

大致上講完我們雲端架構使用的服務，那哪些成本該怎樣節省最好呢？

VM節省成本

VM如果是走微軟架構的，也就是Windows Server的，那授權費會根據獨立的vCPU數量來算，共享CPU的授權費就顯的比較經濟實惠。有時兩台共享vCPU的VM會省超過一台獨立vCPU的VM。

首先一定是先創一個2 Shared vCPU/4GB RAM的機器起跳，因為VM改變大小很容易，除了硬碟的部分以外。

先跑一陣子程式監控看看CPU用量和RAM的用量。如果超過80%才要增加大小，雲端節省心法是，這類的服務負擔最好在40~60%，如果負擔的程度太低代表自己在燒錢，因為每一點資源都等於錢。

這邊就不提VM的水平擴充等等，因為水平擴充最好還是考慮容器化以後用Kubernates或者Cloud Run之類的服務。

Cloud Run節省成本

Cloud Run有一個最大的問題是冷啟動時間很長，我們公司寫的WAF在第一次執行的時候有時要等到1.5秒才會驗證過。這個使用體驗會很差，但Cloud Run可以選擇使用更多CPU減少冷啟動時間。

但更多CPU就要成本，所以要挑選一些冷啟動會影響使用體驗的設定就好。

最好從1 vCPU開始設定，除非那個容器幾乎24小時都有人用，或者該容器要做比較複雜的運算。

C#是我們寫Cloud Run容器的語言，128 MB RAM是不太可能執行的，多半都要256 MB以上。容器執行完以後不會立刻關閉，會有一段閒置時間，也就是第二個第三個使用者要用都可以用同一個容器，所以要考慮同一個容器多個使用者的時候RAM用多少最佳。

建議可以先從512 MB開始看，因為GCP有很清楚的監控儀表板，所以可以知道RAM的使用量和並行容器數量等等。

相當不建議把所有程式寫在同一個容器裡面，因為算價格的方式是vCPU秒和RAM的秒數來算，可以把一些小的模組拆到另一個Cloud Run的容器裡面。

Cloud SQL節省成本

Cloud SQL我這邊只講MS SQL Server，建議除非已經知道負載量很大，不然一開始直接選Express版本 1vCPU 3.75 GB RAM是正解。

因為Cloud SQL可以Upgrade版本，到Web版本可以支援4 vCPU，如果公司預算有到Standard版本，可以在開發初期先Express然後慢慢升上去，可以節省一些成本。

Cloud SQL我曾經規劃了一個Web版本的伺服器2 vCPU，但因為銷售不如預期，只用到12%的vCPU用量。這個就相當浪費，因為Web有3x USD的授權費，2 vCPU機器也會比較貴。

因此我寫文章的剛剛就建立一個新的Cloud SQL，然後將一堆容器全部重新指向VPC給定的內部IP，這個相當麻煩，也容易出錯，還要公司人員協助測試。

所以最好是不要一開始挑太高，因為不能Downgrade，要重建一個執行個體才可以。

結論

這篇講了一下VM、Cloud Run、Cloud SQL節省成本的一些心法，這些我自己摸索了3~6個月才研究出來，中間如果不是因為是Google Partner有Credits可以用的話，已經浪費公司不少錢。

希望這篇文章有幫到您，下一篇預計寫GCP上的Shared VPC。