2018/07/4 更新

Google已道歉，並承諾改進

https://www.ithome.com.tw/news/124304

2018/07/3 更新

已上 ITHome 新聞

https://www.ithome.com.tw/news/124255

今天在GCP社群上看到轉貼一篇國外的文章

從後端社群上轉來的，關於Google AI判斷GCP用戶行為的後果

先不管消息目前的可信度，因為Reddit上連造假論都出來了…

這個事件先不管最後如何？實際可信度如何？

如果這個事件是真的

那GCP真的是給我三觀帶來無限的驚喜

『你的專案會被關掉』

只要Google的AI認為你的專案活動有異常

而且這個驚喜，Google不會通知你

社群上的文章如下

犯罪都還需要通知你出庭，讓法官判

沒通知就直接關

苦主的公司賠慘了

不多說了，原文連結在此

請各位看官自己評斷

畢竟我們不是當事者

中間過程發生甚麼我也不清楚

但沒有通知真的是有點….

也許AI不會通知吧XD

我真心希望GCP改掉任何以”技術主導“為主的服務核心

希望回到以”使用者需求“為主的服務價值

雖然AWS在很多時候也好不到哪

但是在對客戶的服務上，我是認為沒有話說

老是請使用者改掉，配合GCP的架構實作?真的沒人可以接受啦

看看對岸的討論文章 點我

如果一個人評論這個平台服務不好，應該是偏見

如果幾個人評論這個平台服務不好，也許是意見

如果多數人評論這個平台服務不好，那還需要說?

我相信一個有野心的雲平台是可以被質疑的，否則哪來的成長？

還是希望GCP可以越來越好，畢竟使用者不希望自己的平台

三天兩頭出狀況，誰都不想看到XD

最近用了GCP也十個月了

之前曾抱怨過GCP Cloud SQL在HA與MA的不良設計

現在再來說說其他的

正常在使用MySQL的時候，大多數時候都會依照一些經驗去調整參數

而之前在使用AWS RDS的時候也是如此

那問題來了

在Cloud SQL 上，能讓您調整的只有這些

https://cloud.google.com/sql/docs/mysql/flags

那我們來看看AWS RDS有哪些？

網址太長我縮掉了

經歷了十個月多來的使用

以及與偉大的GCP業務端或SA端討論的結果

Cloud SQL 的開發團隊，不認為這有問題

(之前在HA與MA的狀況上，也是給我這一句話)

然後接下來的情況是

我們在不調效參數的情況下

Cloud SQL 會頻繁發生重啟

試問哪個公司的產品可以容許“資料庫不定時重啟“?

如果有，Cloud SQL絕對很適合你們，包你重開到high起來

我們正在嘗試解決的方式，自己使用GCE建置MySQL

原因很簡單，沒有其他解法了

GCP並不像RDS那樣還有其他MySQL資料庫選擇(MariaDB,Aurora)

所以嚴格來說，Cloud SQL是一個非常不成熟的資料庫產品

我們目前驗證到現在

Cloud SQL的預設參數調效，除了連線數設置為4000以外

其餘設定皆與在Linux Server 上安裝MySQL 預設設定一模一樣

講白話一點就是，他說有幫你做最佳調校，但實際上沒有

我們是撈資料庫參數出來看的，一比對就知道

這時候想起業務講過的話

Cloud SQL 就好像一台傻瓜相機，不適合你們進階玩家使用

那各位進階玩家們，這牌子的相機不好用，那下一步各位自己評估吧

另外我想澄清一點，Cloud SQL不是不能用

普通用途可以，重要性很高的話，還是不要考慮

請參考我前面跟Cloud SQL相關的文章再自行評估

不能調效、HA與MA不適用，我想不出他剩下的優點在哪了？

可能只有代管、備份這件事了…

前陣子在修改架構時，要將目前的架構加入HA的概念

所以負載平衡是少不了的，但看了一下教學

都是從頭開始做的，現有的Server要加入有點麻煩

所以自己嘗試了一下，順手就寫一下文章

首先在需要加入的Server中，點選新建個體群組

修改名稱，其餘設定不變，在port的命名跟port號填上需要設定的

注意，如果server有分兩個az，則兩台的個體群組需要分開設定

如asia-a有web-01 但 asia-b 有web-02 ，則要設定兩組

預設的個體就會直接被套用進去，之後按建立即可

兩個個體群組都建立完成後

選擇網路服務->負載平衡

選擇HTTP(S)負載平衡，這裡有地方需要注意，如果對外服務port不是80、8080的話，只能使用TCP負載平衡，如8443這種port

名稱設定打上自己需要設定的，之後設定後端server群組，建立後端服務

如果是靜態服務的項目，如圖片檔，可以直接指向Bucket(Cloud Storage)

port不用設定，如果在設定個體群組有設定的時候，選擇個體群組就會跳出顯示

可以直接套用進去

設定可以使用CPU負載或是連線的要求數量去決定，這裡先用預設

之後新增健康檢查

這裡需要注意FW規則需要加入google檢查的IP網段

130.211.0.0/22,35.191.0.0/16 否則會永遠偵測不到存活，因為連不到

預設先用http 80 去get /

這裡有一個問題，如果你的地區有3個az，連續檢查兩次存活的話

那每次監測就是3*2=6次get，如果有一些防禦機制的話要留意

接著主機與路徑規劃不需特別設定，除非有不同的PATH要導向不同的個體群組

如 /web 給後端web群組  /member 給後端會員群組 這樣

接著設定前端，IP通常是設定一組，不是設定臨時

PORT只有80、8080可以選

完成後點選建立

就創建好了 

昨天跟之前的同事聊了一下

目前他有幫忙做一個案子

跟我目前做的系統架構類似，但是尚未分拆及優化系統

簡單的拿了現有的架構設計幫他改了一下

WEB端一樣做負載平衡 由AWS ELB 處理，SSL加密如有需求一樣由ELB做

後端兩台WEB SERVER 做 HA 備援使用，資料庫與他目前使用的相同一樣用MYSQL

資料端一樣做負載平衡 由 AWS ELB處理，差別在於只接收資料，在看程式邏輯是否做資料驗證動作與SSL加密

資料流接收後塞進SQS做序列待取，保證資料在系統端更新或異動時不會流失

由JOB機器確認資料是取出進S3做為RAWDATA，或是直接計算進MYSQL做資料顯示

HADOOP做資料的計算與分析動作，或是進行資料再利用動作，計算完成一樣進MYSQL給前端網頁做呈現

由目前得知的消息，大概做了這樣子的規劃，畢竟算是新創，沒有多大的資源做多大的架構設計，目前這樣子應該是堪用，在看系統的結構做調整

我知道有些人第一次看見AWS的計價方式

都會感覺有被震驚到

擺脫以往在承租虛擬主機時的計價方式

AWS採用的計價方式與種類非常多樣，往往會讓人不知道該怎麼做

這時候就有一個貼心的網頁計算工具出現了

http://calculator.s3.amazonaws.com/index.html

裡面會持續更新AWS的現有服務與更新的計價方式做update

有時候不清楚轉移到AWS上一個月要多少錢?

來這裡算就對了~