转载

Swiftype为什么从EC2切换到真正的服务器

Swiftype 是一家搜索解决方案提供商，目前已为超过10万个网站和应用程序提供搜索服务。 Oleksiy Kovyrin 是其技术运营部门的负责人。近日，他发表了一篇博文，介绍Swiftype为什么以及如何从EC2切换到真正的服务器。

2012年，Swiftype创建之初选择了Amazon Web Services作为基础设施，因为云容易增加服务器，而又不需要自己管理硬件，并且没有前期成本。遗憾地是，虽然有些服务（如Route53 和S3）非常有用且稳定，但EC2却常常给团队带来困扰。基础设施的可靠性和稳定性决定着他们能否满足客户的性能期望和不间断服务的需求。但在Amazon云上，他们经常会遇到网络问题、VM实例宕机问题、不可预见的性能衰减（可能是由同他们共享硬件的其它应用程序导致的）。这些问题占用了他们大量的时间。因此，他们决定放弃EC2，转而使用真正的硬件。基于以往与托管供应商打交道的经验，他们决定选择SoftLayer。

在迁移之前，他们有大约40个Amazon EC2实例，每周会遇到2到3次严重的问题，有时候每天都遇到。于是，他们决定切换到真正的硬件，并且切换过程不能中断现有服务。为此，他们从以下两个方面做了充分的准备：

连接EC2和SoftLayer ——他们在SoftLayer上的数据中心里构建一个新的基础设施架构，即可以以开发级负载运行所有关键生产服务的最小服务器子集。然后，他们在新旧数据中心之间构建了一个VPN隧道系统，用于确保两个数据中心的组件之间可以实现透明的网络连接。
修改应用程序架构 ——他们对应用程序进行了修改，确保它们可以在原有的云环境和新建的基础设施上并行运行。然后，他们构建了一个数据复制通道，用于确保云基础设施和SoftLayer部署能够保持同步。

Amazon EC2的Virtual Private Cloud（VPC）功能提供了一种连接EC2服务器和另一个私有网络的方法。但是，对于Swiftype的现有实例而言，他们需要停机才能以这种方式实现连接。在经过慎重地考虑和计划之后，他们意识到，真正需要跨数据中心互连的只有MongoDB节点，其它的都可以使用数据中心的本地服务，如Redis集群、搜索服务器、应用程序集群等。这样一来，需要互连的实例数量就相对较少了。因此，他们采用了一种简单但经证明稳定且有效的方式：

每个数据中心部署一个专用的OpenVPN服务器，用于实现所有客户端流量到其私有网络地址的转换；
每个需要连接到另一个数据中心的节点会建立一个VPN通道，并建立本地路由表，将所有指向另一个数据中心的连接正确地转发到那个隧道。

接下来是修改应用程序架构，这项工作的前提是深入了解每个组件。Kovyrin指出，对于任意复杂度的基础设施，其迁移都必须有足够的时间和工程师资源，要仔细考虑应用程序和后端服务之间建立的每一个网络连接。该过程主要包含如下步骤：

所有无状态服务（缓存、应用程序集群、Web层）均在两个数据中心单独部署。
对于每个有状态后端服务（数据库、搜索集群、异步队列等），他们必须考虑是否需要将数据复制到另一个数据中心，或者是否不得不承担数据中心互连造成的延迟。总之，VPN是最后选项，尽量减少数据中心之间的流量和到无法复制的主服务副本的连接。
对于可以复制的服务，他们就复制，并确保应用程序服务器总是或优先使用服务的本地副本。
对于无法复制的服务（如搜索后端），他们修改应用程序，使用异步工作进程和队列实现数据复制。

经过一个多月的努力后，一切准备就绪。他们通过将DNS TTL调至几秒开启切换。在EC2流量已经很少之后，他们停用了旧数据中心，并将剩余的连接转发到新数据中心。由于DNS更新需要时间，这个过程持续了至少一个周的时间。

从EC2切换到真正的硬件之后，发生了以下几个方面的变化：

稳定性提升：严重故障次数由每周2到3次降到了每月1到2次；
性能提升：所有后端服务的性能都获得了提升，IO密集型服务（如数据库和搜索集群）比CPU密集型服务提升更明显，更重要的是，性能有了更强的可预见性，不会突然出现与软件活动本身无关的降低或升高；
成本降低：月度成本至少降低了50%；
配置灵活度提升，但配置时间增加了。

最后，Kovyrin总结道：

如果你的目标从一开始就是业务构建，并且没有多余的工程师资源消耗在“云税（cloud tax）”上，那么，使用真正的硬件可能是更好的选择。

感谢徐川对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

正文到此结束