【51CTO.com快譯】2014年，Instagram加入Facebook兩年后，Instagram的工程團隊該將公司的基礎(chǔ)設(shè)施從亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)服務(wù)器遷移到了Facebook的數(shù)據(jù)中心。Facebook在歐美有多個數(shù)據(jù)中心，但直到最近Instagram才使用美國的數(shù)據(jù)中心。

[[247768]]

Instagram想把基礎(chǔ)設(shè)施擴展到大洋彼岸的主要原因是，我們在美國已沒場地可用。隨著服務(wù)不斷增多，Instagram已到了我們需要考慮利用Facebook建在歐洲的數(shù)據(jù)中心的地步。另一個好處是：本地數(shù)據(jù)中心意味著對歐洲用戶來說延遲更低，這有望在Instagram上打造更好的用戶體驗。

2015年，Instagram將基礎(chǔ)設(shè)施從一個數(shù)據(jù)中心擴展到了三個，以提供急需的彈性：我們的工程團隊不想重蹈2012年AWS災(zāi)難的覆轍，當(dāng)時弗吉尼亞州的一場大風(fēng)暴導(dǎo)致其近一半的實例癱瘓。從三個數(shù)據(jù)中心擴展到五個很輕松；我們只是增加了復(fù)制因子，將數(shù)據(jù)復(fù)制到新的區(qū)域;然而當(dāng)下一個數(shù)據(jù)中心遠(yuǎn)在另一個大陸時，擴展起來會更難。

了解基礎(chǔ)設(shè)施

基礎(chǔ)設(shè)施通?？煞譃閮煞N類型：

• 無狀態(tài)服務(wù)通常用作計算，根據(jù)用戶流量進行擴展(按需擴展)。Django Web服務(wù)器就是個例子。
• 有狀態(tài)服務(wù)通常用作存儲，必須在數(shù)據(jù)中心之間保持一致性。比如包括Cassandra和TAO。

每個人都喜歡無狀態(tài)服務(wù)，它們易于部署和擴展，可以隨時隨地根據(jù)需要來啟動。事實上，我們還需要像Cassandra這樣的有狀態(tài)服務(wù)來存儲用戶數(shù)據(jù)。運行帶有太多副本的Cassandra不僅增加了維護數(shù)據(jù)庫的復(fù)雜性，還浪費了容量，更不用說越洋傳輸仲裁(quorum)請求有多慢了。

Instagram還使用TAO(面向社交圖的分布式數(shù)據(jù)存儲)作為數(shù)據(jù)存儲系統(tǒng)。我們將TAO作為每個分片(shard)的單個主系統(tǒng)(master)來運行，沒有任何從屬系統(tǒng)(slave)為任何寫入請求更新分片。它將所有寫入內(nèi)容轉(zhuǎn)發(fā)到分片的主區(qū)域。由于所有寫入都在位于美國的主區(qū)域進行，所以歐洲那邊的寫入延遲無法忍受。你可能注意到我們的問題反饋基本上是光速。

潛在解決方案

我們能否縮短請求越洋傳輸?shù)臅r間(甚至使往返傳輸消失)?有兩種方法可以解決這個問題。

1. 對Cassandra分區(qū)

為了防止仲裁請求越洋傳輸，我們在考慮將數(shù)據(jù)集分為兩部分：Cassandra_EU和Cassandra_US。如果歐洲用戶的數(shù)據(jù)存儲在Cassandra_EU分區(qū)中，美國用戶的數(shù)據(jù)存儲在Cassandra_US分區(qū)中，用戶的請求就不必遠(yuǎn)距離傳輸來獲取數(shù)據(jù)。

比如說，假設(shè)美國有五個數(shù)據(jù)中心，歐盟有三個數(shù)據(jù)中心。如果我們通過復(fù)制當(dāng)前集群而在歐洲部署Cassandra，復(fù)制因子將是8，仲裁請求必須與8個副本中的5個進行聯(lián)系。

但是如果我們可以找到將數(shù)據(jù)分成兩組的方法，就會有一個復(fù)制因子是5的Cassandra_US分區(qū)和一個復(fù)制因子是3的Cassandra_EU分區(qū)，每個分區(qū)可獨立運行，而不影響其他分區(qū)。與此同時，每個分區(qū)的仲裁請求能夠保持在同一個大陸，因而解決往返傳輸?shù)难舆t問題。

2. TAO僅限于寫入到本地

為了縮短TAO寫入的延遲，我們可以將所有EU寫入限制于本地區(qū)域。這在最終用戶看來幾乎一樣。我們向TAO發(fā)送寫入時，TAO將在本地更新，不會阻止同步向主數(shù)據(jù)庫發(fā)送寫入;相反，它會在本地區(qū)域?qū)懭敕诺疥犃兄?。在寫入的本地區(qū)域，數(shù)據(jù)可立即從TAO獲取，而在其他區(qū)域，數(shù)據(jù)將在從本地區(qū)域傳播后可用。這類似今天的常規(guī)寫入，數(shù)據(jù)從主區(qū)域傳播。

雖然不同的服務(wù)可能會有不同的瓶頸，但如果致力于減少或消除越洋流量這個想法，我們能逐一解決問題。

經(jīng)驗教訓(xùn)

與每個基礎(chǔ)設(shè)施項目一樣，我們在此過程中汲取了一些重要的經(jīng)驗教訓(xùn)。以下是幾個主要的。

• 別急著搞新項目。開始在新數(shù)據(jù)中心配置服務(wù)器之前，確保你了解為什么需要在新區(qū)域部署服務(wù)、有什么樣的依賴關(guān)系以及新區(qū)域投入使用時系統(tǒng)會如何運行。此外，別忘了反思災(zāi)難恢復(fù)計劃，并進行必要的改動。
• 別低估復(fù)雜性。總是在你的日程安排中留出足夠的時間，因為要犯錯誤，要找出意外的阻礙因素，要學(xué)習(xí)你不了解的新的依賴關(guān)系。你可能發(fā)現(xiàn)自己無意中在重新設(shè)計構(gòu)建基礎(chǔ)設(shè)施的方式。
• 明白取舍。成功總是要付出代價。我們對Cassandra數(shù)據(jù)庫進行分區(qū)后，通過縮小復(fù)制因子，節(jié)省了大量存儲空間。然而為了確保每個分區(qū)仍然準(zhǔn)備好面對災(zāi)難，我們需要更多的前端Django容量，以接受來自故障區(qū)域的流量，因為現(xiàn)在分區(qū)無法彼此共享容量了。
• 耐心一點。在開啟歐洲數(shù)據(jù)中心的過程中，我不記得有多少次我們說過“哦，見鬼!”但事情總是最終得到了解決?？赡鼙饶泐A(yù)期的要更久，但要有耐心，整個團隊要通力合作，這是超有意思的過程。

原文標(biāo)題：How Instagram is scaling its infrastructure across the ocean，作者：Sherry Xiao

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】