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