Facebook 如何将 Instagram 从 AWS 搬到自己的服务器

当Instagram在2012年加入Facebook，我们快速建立了大量的Facebook基础设施整合点，以加速产品开发，使社区更加安全。一开始我们通过使用ad-hoc端点在Facebook web服务之间有效传递来构建这些整合。不过我们发现这种方式可能稍显笨拙，还限制了我们使用内部的Facebook服务的能力。

2013年四月伊始，我们开始将Instagram的后端从Amazon Web Services(AWS）向Facebook的数据中心大规模迁移。这将缓和与其他内部的Facebook系统整合并允许我们充分利用为管理大规模服务器部署构建的工具。迁移的主要目标是在过渡中保持网站的完整服务，避免影响特性部署，最小化基础设施级别的改变来避免操作的复杂性。

起初迁移好像很简单:在Amazon的Elastic Compute Cloud(EC2)和Facebook的数据中心之间搭建一个安全的连接，一块一块地将服务迁移过来。简单。

不止如此。这个简单的迁移的主要障碍是Facebook的私有IP空间和EC2的私有IP空间冲突。我们只有一条路可走:先迁移到Amazon的Virtual Private Cloud（VPC)，随后使用Amazon Direct Connect迁移到Facebook。Amazon的VPC提供了必要的伸缩寻址来避开与Facebook的私有网络冲突。

我们对这个任务望而却步；在EC2上运行着数以千计的实例，还有每天出现的新实例。为了最小化停工时间和操作上的复杂性，运行在EC2和VPC中的实例必须像是来自同一个网络。AWS没有提供分享安全群组的方法，也没有私有EC2和VPC网络的桥接。这两个私有网络通信的唯一方法是使用公共地址空间。

所以我们用Python开发了Neti—— 一个动态IP信息包过滤系统守护进程，由Hadoop的正式子项目ZooKeeper提供支持。Neti提供了安全群功能，并且为运行在EC2和VPC中的每一个实例提供单独地址。它管理着上千个本地NAT和每一个实例的过滤规则，允许使用独立的、平坦的"重叠"("overlay")地址空间进行安全通信。NAT规则在源实例和目标实例之间选择最高效的路径。VPC和EC2之间的实例通信使用公共网络，内部通信使用私有网络。这对我们的应用和后端系统是透明的，因为Neti在每一个实例上应用了合适的IP信息包过滤系统。

构成Instagram栈的各式各样的组件从EC2到VPC环境的迁移不到三周，这让我们相信如果没有Neti，时间会长很多。在此过程中，没有出现过重大的服务停工，同时也让我们很快意识到这是有史以来最快的VPC规模迁移。

随着VPC迁移的完工，我们的实例运行在兼容的地址空间中，Instagram准备开始完成向Facebook数据中心的迁移。

一个围绕EC2构建的工具集已经存在多年，它管理着Instagram的产品系统，包括配置管理脚本，用来供应的Chef（"大厨”），从应用部署到数据库master提升等广泛的操作任务使用的Fabric。这个工具集对EC2做出的假定在Facebook环境中已经不再适用。

为了让我们的供给工具更加轻便，Instagram特定的软件现在都运行在Facebook数据中心服务器上的一个Linux容器中(LXC)。Facebook供应工具用来构建基础系统，Chef运行在容器中安装并配置Instagram特定的软件。为了提供跨越EC2和Facebook数据中心的的基础设施，我们目前的Chef recipes（"大厨配方“）就是否允许它们支持Facebook内部使用的CentOS平台一并支持在EC2中使用的Ubuntu的新逻辑展开争论。

用于基础任务的EC2特定命令行工具，例如枚举运行主机和Chef“knife"工具内的供给支持，被同一个工具替代。这个工具被设计成一个抽象层，向EC2中使用的工具提供相似的工作流，减少了人的压力，缓和了向新环境的技术过渡。

我们在工具和环境到位后的两周内完成了Instagram的产品基础设施从VPC到Facebook的数据中心的迁移。

这个分阶段的工作达到了工程开始时设定的主要目标，是一次巨大的成功。此外，在计划和执行迁移的阶段中，团队运送了接近两倍的诸如Instagram Direct的主要特性和我们的用户基数。我们恪守最小化改变的客观初衷，所以过渡对于我们的工程团队几乎是透明的。

回顾一下这个一年之久的工程的一些关键点(key takeaways):

• 计划支持新环境的最小改变, 避免 “while we’re here.”的诱惑。

• 有时，疯狂的想法是有用的——Neti是一个证明。

• 投身于打造你的工具；执行这样的大规模迁移，你最需要的是出人意料的曲线球。 

• 重用团队熟悉的概念和工作流以避免向团队掺杂通信改变的复杂。

这是多团队和诸多个体贡献者的通力协作。在接下来的几周，我们将提供这个迁移工作更深入的介绍，时刻关注这个空间。