2014年，Amazon将VPC（虚拟私有云）作为在Amazon Web Services上创建的所有新应用程序的标准部署环境。如果您在此之前启动了AWS帐户，并且还没有迁移，那么您的应用程序很可能仍然使用ec2classic（弹性计算云）。如果您还没有将现有的EC2经典架构迁移到VPC，那么有很多安全性、价格和架构方面的原因。问题是，如果你运行1400个独立的EC2实例和50多个服务，比如Amplitude，很多服务要么有严格的正常运行时间要求，要么迁移到VPC可能会导致数据损坏。我们花了一年多的时间来完成完整的端到端迁移，仅在devops回购中就涉及30000行代码，但我们做到了这一点，还成功地构建了其他各种升级来启动。以下是我们一路上学到的4个最重要的经验教训。1不要使用加权DNS循环法逐步推出面向客户的服务的新版本当您在AWS中推出面向客户的服务的新版本时，有一点假DNS的魔力很诱人，但最终很危险：加权循环。它的工作原理如下：DNS记录指向的每个资源集根据您指定的权重因子接收流量。这意味着，如果你要推出一项新的服务，基于集群改变这些权重因子似乎是一种神奇的便捷方式，你只需将10%的流量发送到一个新的Spirly test集群，而剩下的90%则会流向你那死气沉沉的老兵集群。当Spirly测试集群认为它讨厌你，而你的500速率猛增10倍时，它也会显得很棒。当这种情况发生时，你可以简单地将测试集群的权重设置为0%，在短暂的TTL周期后，懒懒淘客，流量似乎神奇地停止流向它。但是，即使您的DNS记录中有一个适当的TTL，实际上也有isp会完全忽略您的TTL（甚至在某些情况下，个别客户拥有自己的过度激进的缓存）。在最坏的情况下，100%的客户可能碰巧使用了一个忽略TTL的ISP，导致100%的客户在一段时间内继续使用他们的某个百分比的请求来访问测试集群，这完全超出了您的控制范围。这个陷阱对某些人来说可能是好的-这完全取决于上下文。然而，考虑到有更简单、更可靠的替代方案，我建议一般不要将加权循环作为一种渐进式的推出机制。工程提示：当然，逐步推出一个测试集群（testcluster）的方法不那么挑剔，这将给您更多的控制权。AWS中最简单的选择之一是使用两个自动伸缩组，假设您正在处理一个适合于自动伸缩的服务。您所要做的就是独立地管理两个组的扩展。例如，您可以将第一个集群安排在10个节点上，而第二个集群在50到100个节点之间伸缩。然后，一旦您对新集群比较熟悉，就可以调整伸缩性。无论你选择什么，理想情况下，它都能让你尽可能可靠地控制流量，否则当你发现你正在与一家ISP打交道时，你可能会发现自己陷入了一个噩梦般的境地，而这个ISP的公司口号是"我们可以将你连接到某个东西，但前提是我们愿意。"2计划失败就是计划失败，但是在你还没有开始之前就计划好一切都是失败的。对于这种规模的迁移，迭代的、全力以赴的方法实际上比试图制定一个完美的计划更容易完成项目。这是因为它可以让你尽早和经常地进行实验，并使你能够更有效地向公司其他人传达渐进式的进展。对任何一个对工作充满激情的人来说，很容易被卷入计划每一个细节的事情是如何运作的。剧透提醒：你可能会错过大部分真正重要的东西。你看，从前在另一家公司，我尝试了一个与振幅VPC迁移非常相似的项目。我们花了一年的时间来规划迁移，试图预测我们可能会遇到的每一步，但却从来没有真正抽出时间来取得具体的进展。在振幅上，我们毫不犹豫，我相信这对最终完成专有网络迁移至关重要。在项目的第一周结束时，我在新的专有网络中有了一个生产服务，它从那里开始有机地增长。我们从构建核心VPC网络架构开始，然后根据服务器是ec2classic还是VPC，我们找出了如何使配置管理系统的行为有所不同，并对如何组织terraform代码做出了一些先决条件。在那之后，我们差不多都去看比赛了。工程提示：世界上没有人能够有效地管理一个软件项目，而这个项目的最后期限是一年。然而，任何一个有点像样的工程师都可以在两周后完成一个项目。所以，如果你有一个长期的项目，把它分成一系列的项目，每个项目都会增加价值。从项目管理的角度和从业务的角度来看，什么是淘客，这种微型项目方法往往会工作得非常好。从某种意义上说，你添加的每一个新功能都是一个实验，也是一次与客户的对话。你添加了这个功能，你从你的客户那里得到了反馈，并且根据你的经验进行了必要的调整。所以，如果你的过程中充满了实验，而这些实验只需要花上一年的时间来设置，那么当你开始从你的客户那里学到任何东西的时候，可能有一个竞争对手已经吸取了所有这些经验教训，而且比你遥遥领先。在VPC大规模迁移的背景下，这种将一年多的项目分解为更小的项目的过程实质上相当于对每个服务在移动到专有网络时的增值有了一个概念。例如，当我们将前端负载均衡器移到VPC时，我们知道这将为我们提供一个利用HTTP/2的简单方法，因为amazon的VPC-only-ALB服务支持它的开箱即用。这是独立的有价值的——即使我们当时放弃了VPC项目的其余部分，我们仍然可以保持额外的价值。另一个例子是，当我们将主查询引擎移到VPC时，我们还切换了实例类型以使用i3实例附带的NVMe实例存储，这给了我们一些不错的性能提升。如果那时我们只是决定辞职去做其他的事情，那么这些性能提升仍然是值得的和有价值的。三。小心闪亮的新AWS实例类型自己做测试，不要过早提交。在谈到i3s的时候，我不得不发出一个强烈的警告，关于尝试实例类型。做你的调查。调查其他人遇到的错误，阅读细节，并在尽可能接近您的生产工作负载的情况下进行测试。在我们的例子中，我们首先在我们的一个Kafka集群上试用i3实例，由于我们一直使用大型EBS附件而不是免费的实例存储，因此它承诺了比以前设置更低的性能。我编写了一个自定义的Kafka迁移脚本来处理系统中的大量数据，而不会对任何上游或下游造成太大的破坏，同时我还编写了一个愚蠢的懒虫机器人，每当有进展的时候，它都会用一个故意讨厌的表情符号向每个人发送信息。胜利就在眼前，直到卡夫卡做了它最擅长的事，提醒我们所有人，我们只是愚蠢的凡人，琐事都是为了孩子。一位主持人以一种惊悚的方式看着一堆可怕的消息：blk_update_请求：I/O错误，dev nvme0n1，扇区123290040每次Kafka进程崩溃，我们都会去重新启动它，结果几分钟后它又崩溃了，大数据中心是什么，而且总是伴随着那些威胁性的nvme错误堆积起来。当我们发现一个与i3nvme设备上的缓冲区I/O错误有关的bug线程时，Google似乎是来救我们的。在浏览了足够长的时间，让我的怀疑慢慢平息下来，我终于找到了一个具体的建议，它似乎太疯狂了，不可能再做了，它还需要重新启动所有受影响的主机。结果证明，这项建议充其量只能争取一点时间。第二天，所有的主机又因为同样的原因崩溃了。我们带回了定制的Kafka迁移脚本，当然仍然带有故意讨厌的表情符号通知，并且不情愿地将所有数据移回原始集群，这样我们就可以和平地重组了。在一系列的AWS支持消息之后，我们最终意识到i3实例只被官方推荐用于某些操作系统，而我们的实例并不在列表中。然而，i3发布时的确切引述是"为了从NVMe存储带来的性能中获益，您必须运行以下操作系统之一…"，这听起来不像"如果您不使用以下操作系统之一，i3将去开膛手杰克对你可怜的，大数据精准，毫无防备的和平机器镇。第二件事我很想知道。我们还发现，nvme错误通常只发生在重负载下，而且我们实际上可以通过使用一个名为Bonnie的免费基准测试工具在testi3上触发它们++在真正的振幅方式下，我们最终在这里所做的是重现VPC迁移的所有进展，并将所有内容重新迁移到ubuntu主机上，这样我们就可以安全地使用i3s了，大数据是干什么的，这只花了一周的时间。作为一个相关的旁白，这感觉是一个很好的地方指出