共计 2023 个字符，预计需要花费 6 分钟才能阅读完成。
当 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 是一个证明。
投身于打造你的工具；执行这样的大规模迁移，你最需要的是出人意料的曲线球。
重用团队熟悉的概念和工作流以避免向团队掺杂通信改变的复杂。
这是多团队和诸多个体贡献者的通力协作。在接下来的几周，我们将提供这个迁移工作更深入的介绍，时刻关注这个空间。
