羅巴特

主機部屬位置攸關整體效能與速度

不過以一般網站來說，真的感覺不太出來，個人覺得啦～

就跟文書需求的人買電腦，i5跟i7感覺不出快在哪裡，因為都很快XD

然而，如果你是擁有數千數萬的瀏覽量的網站，那選擇資料中心就有很大的差異

更何況百萬人同時上線，服務擴及全世界的服務網站，那就不是一個區域一個節點就能解決的

還要考慮負載平衡諸如此類的，雖然Google也有提供這類服務，不過不在目前的討論範圍

以下整理一些雜項資料，提供剛好需要的時候參考

資料中心位置

資料中心部屬位置可參考下圖(來源：https://cloud.google.com/compute/docs/regions-zones/regions-zones)

美國/歐洲

亞洲/澳洲

ASIA-NORTHEAST1 在 日本東京

ASIA-EAST1 在台灣彰化

ASIA-SOUTHEAST1 在新加坡文雅

在Google雲端架站(2)中，建立的虛擬機會存在一個區域(Regions)或一個區域(Zones)，兩個的中文都叫區域，不過概念上有些不同

Regions可以理解成一座資料中心，就像上述所說的台灣彰化、日本東京

而Zones可以理解成在Regions中的子區域

Regions就是Zones的集合，因此上圖中，ASIA-EAST1是Regions，而他其中有一個子區域(zone)叫做a，也就是asua-east1-a （<region>-<zone>的組成方式）

網路頻寬

網路的頻寬在各個節點之間也不太一樣

Google提供的公開與不公開對等連線地點清單可在 PeeringDB 中查詢

https://www.peeringdb.com/asn/15169

網路延遲

如果以路程+節點最小是速度越快的來看，那麼選擇台灣彰化對我來說就是最快的節點。因此做了一個實驗如下

直接ping位於美國 us-central1-c 的主機 (f1-micro型)，平均200ms

直接ping 位於台灣asia-east1-c主機 (f1-micro型)，平均40ms

可以發現反應速度整個差很多阿

網路服務

雖然Google部屬在各地的資料中心都有提供Google Compute Engine，但每個區域的細部項目不盡相同

例如台灣彰化有提供Google Cloud Bigtable，但日本東京就沒有此服務

在選擇部屬上這也是要考慮的一個點

可以參考 https://cloud.google.com/about/locations/#locations 有提供服務地圖

結論

在多台機器部屬時，部屬在不同的Regions及不同的Zones可以提高可容錯性以及避免突如其來的意外造成故障

假設你只有在台灣有客戶，那你可以部屬多台虛擬機在asua-east1中，但zone本身有最大頻寬，如同一棟建築物對外排水管需要排放整棟的水，要避免單一zone的壅塞，可以選擇在a,b,c分別部屬。

同理，Regions本身也有最大的頻寬限制，因此可以同時部屬台灣與日本的虛擬機，但日本距離較遠，相對於直接存取台灣的速度來說就會慢一點

部屬的組合十分複雜，如何在最低成本與速度之間取捨，主要是看當下的應用以及目標需求，而且要實際側試過才知道好壞