Instagram 有 2 億用戶，上面保留有用戶分享的 200 億張照片。從 2010 年到今年春之前，這些照片一直存放在 Amazon 的 EC2(彈性計算云)上，但現在這些照片已經被Instagram的一只小型團隊搬到了收購了他們的 Facebook 的數據中心上，但 2 億用戶對此卻毫不知情，仿佛什么事情都沒發生過一樣。他們是怎么做到的呢?

　　Facebook 是在以 10 億美元收購 Instagram 1 年后的 2013 年 4 月作出遷移決定的。整個遷移過程用時大約 1 年。盡管遷移工作量巨大，但實施遷移工作的卻是一支非常小規模的團隊，遷移開始時 Instagram 的維護團隊只有 8 人，后來才逐步擴張到 20 人。實際的數據遷移工作只用的 1 個月時間，其余的時間完全都是用于遷移的準備工作。

　　搬遷工作的第一步，是要在 Facebook 的數據中心建立一套一模一樣的軟件。然后再把數據遷移過去。當然，這個過程要比你想象的要困難。在 Facebook 這一側開通 Instagram 的照片共享服務之前，需要首先將 Instagram 搬遷至 Amazon 云的另一部分。換句話說，得搬兩次。

　　第一次搬家是將服務從 Amazon EC2 搬遷至 Amazon 的虛擬私有云 VPC。通過 VPC，遷移小組可以建立起一個可拓展至 Amazon 以外地方(即 Facebook 數據中心)的邏輯網絡。這一步很重要，因為 Facebook 可以對運行 Instagram 的機器的 IP 地址擁有完全控制權。而只有這樣，在進行軟件遷移時才不會出現無數的地址沖突問題。

　　但是，要想把 Instagram 從 EC2 搬到 VPC，首先還必須在兩者之間搭建一個公用的網絡。Amazon 本身沒有提供這樣的工具，因此為了暫時解決這個問題，Facebook 自己開發了一套網絡工具 Neti。這一點說明了云計算的復雜性，對于任何想要跨云服務搭建自己應用的人來說，Facebook 的這一步都是一個最大的經驗教訓。

　　部分遷移團隊成員，左起依次是Pedro Canahuati、Patrick Bozeman、Rick Branson、Nick Shortway、Chris Bray和Michael Gorven，照片：Ariel Zambelich/WIRED

　　Instagram 一開始沒有用 VPC 是因為 2010 年的時候 VPC 還沒有出來。因此，現在的初創企業要是一開始就未雨綢繆的話，可以考慮在 VPC 上做自己的應用，這樣就能省下這一步遷移工作。而且對于只想把部分設施搬遷到私有數據中心的人來說，用 VPC 也是明智之選。

　　而接下來的軟件遷移工作，他們得靠一款越來越火配置管理軟件—Chef。Chef 可以為軟件 / 應用在大規模機器上的加載和配置編寫出自動化的“食譜(recipes 或 cookbooks)”。比方說這種食譜可以自動把適當的軟件加載在運行于 Amazon VPC 的機器上。然后，團隊可以利用類似的食譜在 Facebook 數據中心內部的機器上加載相同的軟件。為此，遷移小組編寫了專門用于在各種 Instragram 數據庫服務器上安裝軟件的食譜，然后又制作了用于配置緩存服務器(緩存服務器的用途是加速熱門照片的提供)的食譜。

　　如此，到了 2014 年的 4 月，最后一部分的軟件和數據也遷移到 Facebook 的數據中心上了。遷移后的 Instagram 效率是原來的 3 倍，而且數據提取時間減少了 80%。

　　此次搬遷的意義，對于 Instagram 來說，可以使用 Facebook 的計算工具，對于運營數據中心的工程師來說，此次搬遷是一個模板，也為廣大的在云服務至上搭建 app 的技術社區提供了一個從公有云向私有云遷移的范例。

　　當然，Facebook 的遷移動作說到底只是相對少數。因為，對于大多數的中小企業來說，向公有云遷移才是大勢。像 Facebook 這樣將服務從公有云搬遷到自己私有云的只有財大氣粗者才會這么做。我們也相信，隨著 Docker、Mesosphere等資源統一調度和部署管理工具的成熟，應用的遷移也會變得像即插即用一樣的容易。