Facebook如何將Instagram從AWS搬到自己的服務(wù)器
當(dāng)Instagram在2012年加入Facebook，我們快速建立了大量的Facebook基礎(chǔ)設(shè)施整合點(diǎn)，以加速產(chǎn)品開發(fā)，使社區(qū)更加安全。一開始我們通過使用ad-hoc端點(diǎn)在Facebook web服務(wù)之間有效傳遞來構(gòu)建這些整合。不過我們發(fā)現(xiàn)這種方式可能稍顯笨拙，還限制了我們使用內(nèi)部的Facebook服務(wù)的能力。
2013年四月伊始，我們開始將Instagram的后端從Amazon Web Services(AWS）向Facebook的數(shù)據(jù)中心大規(guī)模遷移。這將緩和與其他內(nèi)部的Facebook系統(tǒng)整合并允許我們充分利用為管理大規(guī)模服務(wù)器部署構(gòu)建的工具。遷移的主要目標(biāo)是在過渡中保持網(wǎng)站的完整服務(wù)，避免影響特性部署，最小化基礎(chǔ)設(shè)施級別的改變來避免操作的復(fù)雜性。
起初遷移好像很簡單:在Amazon的Elastic Compute Cloud(EC2)和Facebook的數(shù)據(jù)中心之間搭建一個安全的連接，一塊一塊地將服務(wù)遷移過來。簡單。
不止如此。這個簡單的遷移的主要障礙是Facebook的私有IP空間和EC2的私有IP空間沖突。我們只有一條路可走:先遷移到Amazon的Virtual Private Cloud（VPC)，隨后使用Amazon Direct Connect遷移到Facebook。Amazon的VPC提供了必要的伸縮尋址來避開與Facebook的私有網(wǎng)絡(luò)沖突。
我們對這個任務(wù)望而卻步；在EC2上運(yùn)行著數(shù)以千計的實(shí)例，還有每天出現(xiàn)的新實(shí)例。為了最小化停工時間和操作上的復(fù)雜性，運(yùn)行在EC2和VPC中的實(shí)例必須像是來自同一個網(wǎng)絡(luò)。AWS沒有提供分享安全群組的方法，也沒有私有EC2和VPC網(wǎng)絡(luò)的橋接。這兩個私有網(wǎng)絡(luò)通信的唯一方法是使用公共地址空間。
所以我們用Python開發(fā)了Neti—— 一個動態(tài)IP信息包過濾系統(tǒng)守護(hù)進(jìn)程，由Hadoop的正式子項(xiàng)目ZooKeeper提供支持。Neti提供了安全群功能，并且為運(yùn)行在EC2和VPC中的每一個實(shí)例提供單獨(dú)地址。它管理著上千個本地NAT和每一個實(shí)例的過濾規(guī)則，允許使用獨(dú)立的、平坦的"重疊"("overlay")地址空間進(jìn)行安全通信。NAT規(guī)則在源實(shí)例和目標(biāo)實(shí)例之間選擇***效的路徑。VPC和EC2之間的實(shí)例通信使用公共網(wǎng)絡(luò)，內(nèi)部通信使用私有網(wǎng)絡(luò)。這對我們的應(yīng)用和后端系統(tǒng)是透明的，因?yàn)镹eti在每一個實(shí)例上應(yīng)用了合適的IP信息包過濾系統(tǒng)。
構(gòu)成Instagram棧的各式各樣的組件從EC2到VPC環(huán)境的遷移不到三周，這讓我們相信如果沒有Neti，時間會長很多。在此過程中，沒有出現(xiàn)過重大的服務(wù)停工，同時也讓我們很快意識到這是有史以來最快的VPC規(guī)模遷移。
隨著VPC遷移的完工，我們的實(shí)例運(yùn)行在兼容的地址空間中，Instagram準(zhǔn)備開始完成向Facebook數(shù)據(jù)中心的遷移。
一個圍繞EC2構(gòu)建的工具集已經(jīng)存在多年，它管理著Instagram的產(chǎn)品系統(tǒng)，包括配置管理腳本，用來供應(yīng)的Chef（"大廚”），從應(yīng)用部署到數(shù)據(jù)庫master提升等廣泛的操作任務(wù)使用的Fabric。這個工具集對EC2做出的假定在Facebook環(huán)境中已經(jīng)不再適用。
為了讓我們的供給工具更加輕便，Instagram特定的軟件現(xiàn)在都運(yùn)行在Facebook數(shù)據(jù)中心服務(wù)器上的一個Linux容器中(LXC)。Facebook供應(yīng)工具用來構(gòu)建基礎(chǔ)系統(tǒng)，Chef運(yùn)行在容器中安裝并配置Instagram特定的軟件。為了提供跨越EC2和Facebook數(shù)據(jù)中心的的基礎(chǔ)設(shè)施，我們目前的Chef recipes（"大廚配方“）就是否允許它們支持Facebook內(nèi)部使用的CentOS平臺一并支持在EC2中使用的Ubuntu的新邏輯展開爭論。
用于基礎(chǔ)任務(wù)的EC2特定命令行工具，例如枚舉運(yùn)行主機(jī)和Chef“knife"工具內(nèi)的供給支持，被同一個工具替代。這個工具被設(shè)計成一個抽象層，向EC2中使用的工具提供相似的工作流，減少了人的壓力，緩和了向新環(huán)境的技術(shù)過渡。
我們在工具和環(huán)境到位后的兩周內(nèi)完成了Instagram的產(chǎn)品基礎(chǔ)設(shè)施從VPC到Facebook的數(shù)據(jù)中心的遷移。
這個分階段的工作達(dá)到了工程開始時設(shè)定的主要目標(biāo)，是一次巨大的成功。此外，在計劃和執(zhí)行遷移的階段中，團(tuán)隊運(yùn)送了接近兩倍的諸如Instagram Direct的主要特性和我們的用戶基數(shù)。我們恪守最小化改變的客觀初衷，所以過渡對于我們的工程團(tuán)隊幾乎是透明的。
回顧一下這個一年之久的工程的一些關(guān)鍵點(diǎn)(key takeaways):
-
計劃支持新環(huán)境的最小改變, 避免 “while we’re here.”的誘惑。
-
有時，瘋狂的想法是有用的——Neti是一個證明。
-
投身于打造你的工具；執(zhí)行這樣的大規(guī)模遷移，你最需要的是出人意料的曲線球。
-
重用團(tuán)隊熟悉的概念和工作流以避免向團(tuán)隊摻雜通信改變的復(fù)雜。
這是多團(tuán)隊和諸多個體貢獻(xiàn)者的通力協(xié)作。在接下來的幾周，我們將提供這個遷移工作更深入的介紹，時刻關(guān)注這個空間。
