告别AWS，Instagram将服务迁至Facebook数据中心

ZDNet至顶网软件频道消息：Instagram已基本完成AWS到Facebook基础设施的迁移。听到这个消息，笔者并不惊讶。首先，社交巨头拥有自己的大规模数据中心；其次，作为风头正劲的互联网公司之一，社交巨头拥有着大量的服务，其技术堆栈及API可以轻易满足Instagram的架构需求；再次，在Facebook规模，不管是从成本，还是从性能及可用性上看，迁移都是上上之选。最后，避免平台的约束和锁定，Instagram将有更大的发展空间。

言归正传，下面我们看一些博文摘译：

在2012年加入Facebook之后，我们就发现了多个与Facebook基础设施的集成点，这将允许我们更加快速的开发产品，同时还能提高社区的安全性。开始时，我们使用的是ad-hoc端点接入，但是随后就发现这限制了我们的敏捷性及Facebook服务的利用率。

在2013年4月后，我们开始大规模的迁移到Facebook数据中心，其中的重点是服务可用性的平稳过渡，以及最小化基础设施级改变来避免其中的操作复杂性。开始时非常简单，在EC2和Facebook的一个数据中心之间建立连接，然后一块一块的迁移。

但是随后就发现事情并非那么容易，主要的问题就是Facebook私有IP空间和EC2的冲突。我们的方法是，首先使用Amazon的Virtual Private Cloud（VPC），随后使用Amazon Direct Connect将之与Facebook连接。

鉴于每天都会开启新的EC2实例，这个任务看起来非常艰巨。为了最小化服务停机时间以及操作复杂性，EC2和VPC实例是否在同一个网络至关重要。AWS并没有提供安全组或者私有EC2与VPC网络的共享方式，公共地址空间成为两个私有网络的唯一通信渠道。

因此，我们发明了Neti，一个动态的iptables操作守护进程，使用Python编写，通过ZooKeeper支撑。Neti不仅提供了缺少的安全组功能，还为每个实例都提供了单独的地址，不管是EC2还是VPC。Neti管理了数千个NAT以及实例上的过滤规则，从而保证了独立的、flat “overlay”安全通信。NAT规则会为实例选择一个最有效的通信途径，跨越VPC和EC2边界时会选择公共网络，内部通信则会选择私有网络。这些对我们的应用和后端系统都是透明的，因为Neti会提供一个恰当的iptables规则。

从EC2到VPC花费了大约3周时间，随后所有实例就运行在一个兼容的地址空间，下一个阶段无疑就是迁移到Facebook数据中心。

多来以来，Instagram围绕EC2建立了一整套生产系统管理工具，其中包括配置管理脚本，用于服务开通的Chef，以及服务于运营任务的Fabric，从应用到数据库，这些针对EC2环境的工具都将不适用于数据中心环境。

为了给这些工具提供可移植性，我们使用了LXC。配置工具用于建立基础系统，Chef则运行在container中，用以安装和配置Instagram特定软件。为了支撑横跨EC2及Facebook数据中心的基础设施，当下的Chef加入了新的逻辑用以支撑Facebook内部使用的CentOS，之前在EC2上使用的是Ubuntu。同时，用于基础任务的EC2命令行工具也被一个全新的工具代替，它被设计成了一个抽象层，提供了类似EC2工作流中的环境，为技术和人们使用方式做过渡。在这些都完成后，VPC到数据中心的迁移只花费了两周。

写在最后

对于Instagram来说，迁移可以带来显而易见的好处，同时，我们也相信会有更多这个类型的应用被收购后会做出类似的举措，比如未来我们可能会看到WhatsApp迁离SoftLayer。然而对于云服务提供商来说，这绝对不是件想看到的事情，Instagram之类的到还好说，如果是Netflix这样的合作伙伴，撇开直接收入，生态圈受到的影响显然更加深远。