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

[[247768]]

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

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

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

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

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

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

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

潛在解決方案

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

1. 對(duì)Cassandra分區(qū)

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

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

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

2. TAO僅限于寫入到本地

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

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

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

與每個(gè)基礎(chǔ)設(shè)施項(xiàng)目一樣，我們?cè)诖诉^程中汲取了一些重要的經(jīng)驗(yàn)教訓(xùn)。以下是幾個(gè)主要的。

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

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

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