云就像一个魔盒-您问您需要什么，资源随处可见。 虚拟机，数据库，网络-所有这些仅属于您。 云中还有其他租户，但是在您的宇宙中，您是唯一的统治者。 您确定您将始终获得所需的资源，不会与任何人争执，而是独立确定网络将是什么。 如何使云灵活地分配资源并使租户彼此完全隔离的魔力？
AWS Cloud是一个复杂的系统，自2006年以来一直在发展。 Amazon Web Services的架构师
Vasily Pantyukhin发现了部分开发内容。 作为一名架构师，他不仅从最终结果中看到，而且从AWS克服的挑战中看到。 对系统越了解，就越有信心。 因此，Vasily将分享AWS云服务的秘密。 削减的对象是用于AWS物理服务器的设备，灵活的数据库可伸缩性，自定义的Amazon数据库以及在降低虚拟机价格的同时提高虚拟机性能的方法。 了解亚马逊的架构方法将帮助您更好地利用AWS服务，并可能为构建自己的解决方案提供新的思路。
关于演讲者：Vasily Pantyukhin（ Hen ）最初是in.ru公司的Unix管理员，在Sun Microsystem的大型腺体工作了6年，并在11年间倡导以EMC为中心的以数据为中心。 自然地演变为私有云，并在2017年转变为公共云。 现在有了技术提示，他帮助在AWS云中生活和开发。
免责声明：以下所有内容都是Vasily的个人观点，可能与Amazon Web Services的立场不符。 我们的YouTube频道上提供了根据其创建文章的报告的视频 。我为什么要谈论亚马逊设备
我的第一辆汽车是在手动变速箱上装有“把手”的。 感觉很棒，因为我能控制机器并完全控制机器。 我还喜欢我至少大致了解她的工作原理。 自然，我非常原始地想到了盒式设备-大致就像自行车上的变速箱。
一切都很棒，除了一件事-站在交通拥堵中。 看来您坐着无所事事，但是您不断换档，踩离合器，油门，刹车-您真的对它感到厌倦。 当一台机器出现在家庭中的机器上时，交通堵塞问题得到了部分解决。 在方向盘上，有时间考虑一些事情，听有声读物。
我的生活中出现了一个谜，因为我通常不再了解汽车的工作原理。 现代汽车是复杂的设备。 该车可同时适应多种不同的参数：踩油门，刹车，驾驶方式和道路质量。 我不再了解它是如何工作的。
当我开始使用Amazon Cloud时，这对我也是一个谜。 仅此秘密要高出一个数量级，因为汽车中只有一个驾驶员，而AWS中有数百万。 所有用户同时转向，踩油门并刹车。 他们去想要的地方真是太神奇了-对我来说这是一个奇迹！ 该系统会自动适应，缩放和灵活地适应每个用户，使他觉得自己在这个宇宙中是一个人。
当我后来成为亚马逊的一名建筑师时，魔术消失了。 我看到了我们面临的问题，如何解决它们，如何开发服务。 随着对系统了解的增加，对服务的信心也越来越大。 因此，我想分享一下AWS云幕后的情况。
我们要谈什么
我选择了一种多元化的方法-我选择了4个有趣的值得一提的服务。
服务器优化 。 具有物理实施例的临时云：物理数据中心，那里的物理服务器在嗡嗡作响，正在预热和闪烁的灯泡。
无服务器功能 （Lambda）可能是云中最具扩展性的服务。
数据库扩展 。 我将讨论我们如何构建自己的可伸缩数据库。
网络扩展 。 我将在其中打开网络设备的最后一部分。 这是一件了不起的事情-云的每个用户都认为自己独自在云中，根本看不到其他租户。
注意事项 本文将重点介绍服务器优化和数据库扩展。 网络扩展将在下一篇文章中讨论。 无服务器功能在哪里？ 关于他们的另一个笔录出来了：“ 马尔，是的，大胆。 鞭炮微病毒装箱 。“ 它讨论了几种不同的扩展方式，并且详细分析了Firecracker解决方案-共生虚拟机和容器的最佳质量。
伺服器
云是短暂的。 但是这种短暂性仍然具有物理体现-服务器。 最初，他们的体系结构是经典的。 标准的x86芯片组，网卡，Linux，运行虚拟机的Xen虚拟机管理程序。
在2012年，这种架构表现出色。 Xen是一个很棒的管理程序，但是有一个主要缺陷。 他
在模拟设备方面有相当
高的开销 。 随着新的更快的网卡或SSD的出现，这些开销变得太高了。 如何解决这个问题？ 我们决定同时在两个方面进行工作-同时
优化硬件和管理程序 。 任务很严肃。
铁和管理程序的优化
一次做好所有事情都行不通。 最初，“好”是难以理解的。
我们决定采用一种进化的方法-我们改变了建筑的一个重要元素，并将其投入生产。
我们踩着所有耙子，听取投诉和建议。 然后，我们更改另一个组件。 因此，我们会以很小的增量根据用户的反馈和支持从根本上改变整个体系结构。
转型始于2013年最困难的事情-网络。 在
C3实例中，特殊的Network Accelerator卡已添加到标准网卡中。 它通过前面板上的一条短的环回电缆连接。 难看，但在云中不可见。 但是，与硬件的直接交互从根本上改善了抖动和网络带宽。
然后，我们决定专注于改善对EBS块存储-弹性块存储的访问。 这是网络和存储的结合。 困难在于，如果市场上有Network Accelerator卡，就无法仅购买Storage Accelerator硬件。 因此，我们求助于初创公司
Annapurna Labs ，后者为我们开发了专用ASIC芯片。 他们允许您将远程EBS卷连接为NVMe设备。
在
C4实例中，我们解决了两个问题。 首先，我们使用有前途但当时还很新的NVMe技术为未来奠定了基础。 第二个-通过将对EBS的请求处理转移到新卡上，从而显着卸载了中央处理器。 事实证明很好，所以现在Annapurna Labs是Amazon的一部分。
到2017年11月，我们意识到是时候更改虚拟机监控程序本身了。
新的虚拟机管理程序是基于修改后的KVM内核模块开发的。
它可以从根本上降低仿真设备的开销成本，并直接与新ASIC一起工作。
C5实例是运行新管理程序的第一个虚拟机。 我们称之为
Nitro 。
时间轴上实例的演变。自2017年11月以来出现的所有新型虚拟机均在此虚拟机监控程序上运行。
Iron Bare Metal实例没有管理程序 ，但由于使用专用的Nitro卡，因此也称为Nitro。
在接下来的两年中，Nitro实例的类型数量超过了十几种：A1，C5，M5，T3等。
实例类型。现代硝基车的工作原理
它们具有三个主要组件：Nitro虚拟机管理程序（如上讨论），安全芯片和Nitro卡。
该安全芯片直接集成到主板中。 它控制许多重要功能，例如，控制主机OS的加载。
硝基卡 -有四种类型。 所有这些均由Annapurna Labs开发，并基于通用ASIC。 他们的固件的一部分也很常见。
四种硝基卡。其中一张卡旨在与
VPC 网络配合使用 。 在
虚拟机中可以看到她是
ENA网卡
-Elastic Network Adapter 。 当流量通过物理网络传输时，它还封装了流量（我们将在本文的第二部分中讨论），控制安全组防火墙，负责路由和其他网络事物。
单独的卡可与服务器内置的
EBS块存储和磁盘一起使用。 它们作为
NVMe适配器提供给来宾虚拟机。 他们还负责数据加密和磁盘监视。
Nitro卡系统，管理程序和安全芯片集成到SDN或
软件定义的网络中 。 控制
卡负责管理此网络（控制平面）。
当然，我们将继续开发新的ASIC。 例如，在2018年底，他们发布了Inferentia芯片，该芯片可以更高效地处理机器学习任务。
Inferentia机器学习处理器芯片。可扩展的数据库
传统数据库具有分层结构。 如果大大简化，则可以区分以下级别。
- SQL-客户端和查询调度程序就可以使用它。
- 确保交易安全-此处清楚显示所有内容，ACID等。
- 缓冲池提供的缓存。
- 日志记录 -提供重做日志的工作。 在MySQL中，它们称为Bin Logs，在PosgreSQL中，它们称为Write Ahead Logs（WAL）。
- 存储 -直接写入磁盘。
分层数据库结构。扩展数据库的方式有多种：分片，无共享架构，共享驱动器。
但是，所有这些方法都保留相同的整体数据库结构。 这大大限制了缩放比例。 为了解决此问题，我们开发了自己的数据库
Amazon Aurora 。 它与MySQL和PostgreSQL兼容。
亚马逊极光
主要的体系结构思想是从主数据库拆分存储和日志记录级别。
展望未来，我会说我们还使缓存级别独立。 建筑不再是一个整体，我们在扩展单个块时获得了更多的自由度。
日志记录和存储级别与数据库分开。传统的DBMS以块的形式将数据写入存储系统。 在Amazon Aurora，我们创建了一个可以说
重做日志语言的“智能”存储库。 在内部，存储库将日志转换为数据块，监视其完整性并自动备份。
这种方法使您可以实现诸如
克隆之类的有趣的事情。 由于它不需要创建所有数据的完整副本，因此它从根本上更快，更经济地工作。
存储级别实现为分布式系统。 它由大量物理服务器组成。 每个重做日志由
六个节点同时处理和存储。 这提供了数据保护和负载平衡。
可以使用适当的副本来实现读缩放。 分布式存储消除了我们通过其写入数据的主数据库实例与其他副本之间的同步需求。 保证当前数据可用于所有副本。
唯一的问题是在只读副本上缓存旧数据。 但是，通过
将所有重做日志传输到内部网络上的副本可以解决此问题。 如果日志在缓存中，则将其标记为无效并被覆盖。 如果它不在高速缓存中，则将其简单地丢弃。
我们找出了存储空间。
如何扩展DBMS级别
在这里，水平缩放要困难得多。 因此，让我们走过去
经典垂直缩放的必经之路 。
假设我们有一个通过主节点与DBMS通信的应用程序。
使用垂直缩放时，我们选择一个具有更多处理器和内存的新节点。
接下来，将应用程序从旧的主节点切换到新的主节点。 有问题。
- 这将需要明显的应用程序停机时间。
- 新的主节点将具有冷缓存。 只有在缓存预热后，数据库性能才能达到最高。
情况如何改善？ 在应用程序和主节点之间放置一个代理。
它会给我们什么？ 现在，无需将所有应用程序手动重定向到新节点。 切换可以在代理下完成，并且从根本上讲更快。
该问题似乎已解决。 但是，不，我们仍然需要预热缓存。 另外，出现了一个新问题-现在代理是潜在的故障点。
Amazon Aurora Serverless的最终解决方案
我们如何解决这些问题？
留下了代理 。 这不是一个单独的实例，而是整个分布式代理服务器，应用程序通过代理服务器连接到数据库。 发生故障时，几乎可以立即更换任何节点。
我们添加了各种大小的热节点池 。 因此，如果有必要分配更大或更小的新节点，则该节点立即可用。 无需等待它加载。
整个缩放过程由特殊的监视系统控制。 监视不断监视当前主节点的状态。 例如，如果检测到处理器负载已达到临界值，则会通知热实例池分配新节点的需求。
分布式代理，热实例和监视。所需功率的节点可用。 将缓冲池复制到该缓冲池，系统开始等待安全的时刻进行切换。
通常，切换的时刻到来很快。 然后，代理和旧的主节点之间的通信被挂起，所有会话都切换到新的节点。
使用数据库恢复。
该图显示该悬浮液实际上非常短。 在蓝色图形上，负载，在红色阶上-缩放时刻。 蓝色图表中的短期下跌正是那短暂的延迟。
顺便说一下，Amazon Aurora允许您在不使用时（例如，在周末）完全保存并关闭数据库。 停止负载后，数据库会逐渐降低其电源并关闭一段时间。 当负载恢复时，它将再次平稳上升。
在Amazon设备讨论的下一部分中，我们将讨论网络扩展。 订阅时事通讯并继续关注，以免错过这篇文章。
在HighLoad ++上， Vasily Pantyukhin将作一个演讲“ 休斯顿，我们有问题。 故障系统设计，Amazon云内部服务开发模式 。” 哪些亚马逊设计开发人员使用分布式系统设计模式，服务失败的原因是什么，什么是基于单元的架构，持续工作，随机分片-将会很有趣。 在会议召开不到一个月前订票 。 10月24日，最终提价。