最佳实践｜亚马逊可持续发展的架构模型

在过去的十年里面，亚马逊云科技一直都致力于帮助企业和开发者实现数字化转型，包括如何使用云技术帮助企业提高运营中资源利用率；如何通过云基础架构、容器、DevOps 进行业务的创新和敏捷性；未来的十年，亚马逊云科技将帮助**开发者和企业开始新的可持续发展转型**。让开发者可以使用相同的工具更专注于可持续性工作，并通过最佳实践和整体基础架构，帮助你应对在可持续发展转型过程中的新挑战。 在致力于云本身的可持续性发展转型的同时，我们将实践和经验做出了总结，并设计了有效的工具和服务提供给开发者。 作为云上的可持续性发展目标，我们认为有两方面的工作是非常重要的： 第一，要持续降低工作负载的能耗。 第二，要不断提高工作负载组件之间的工作效率。 基于以上两个目标，我们总结了六个方面的最佳实践，帮助开发者构建云上可持续发展的架构模型，包括：**区域的选择、正确使用云资源、软件的架构、数据使用、硬件的选择以及开发部署。** # 亚马逊可持续性发展的最佳实践 ## 选择合适的区域来部署你的工作负载  亚马逊云科技的区域 亚马逊云科技在全球提供了 30 多个区域以及 99 个可用区。我们的构建者可以根据业务需求来选择不同可用区的资源，包括网络延迟，数据合规要求等等。而可持续性发展，也就是节能减排的目标也应该在选择合适的可用区时纳入考量。 亚马逊云科技分别在北美洲、欧洲、中东和非洲、以及亚太区域通过 310 个可再生能源项目，实现了共计 15.7 千兆瓦可再生能耗。不同的区域针对不同的可再生能源项目，得到的能耗节省略有不同。其中 32 个亚太地区的可再生能源项目包括中国山东和吉林的两个可再生能源项目。山东项目是 100 兆瓦 (MW) 的太阳能项目，目前已经投入运营，每年可产生 12.8 万兆瓦时 (MWh) 的清洁能源。吉林项目是亚马逊在中国支持的第二个可再生能源项目，是 100 兆瓦 (MW) 的风能项目。该项目也将很快投入运营，届时每年可提供超过 30 万兆瓦时（MWh）的可再生能源，相当于为超过 15 万户中国普通家庭提供电力支持。 我们建议的最佳做法是选择靠近这些可再生能源项目的区域，利用亚马逊现有的成果实现第一步的节能减排。 ## 正确使用云资源 我们的第二个建议是**正确使用云资源**。 这一点非常重要。和自建数据中心不同，云上的资源按需付费。多数企业，并没有将企业内部数据中心的建设成本平均到具体业务所占用的服务成本，因此按照自建数据中心的方式消费云资源，对于单个应用来说，云上资源消耗没有特别明显的优势。因此建立新的使用习惯，规范云资源的使用方式，特别是加入制定明确的可持续发展目标，将其与 SLA 相平衡为前提来设计应用的交付方式，比如：按需扩张、消除闲置资源、根据所在地理位置油画工作负载的地理布局、以及根据可持续发展目标，优化云上资源的使用行为。通过规范云上资源使用行为，可以帮助开发者进一步实现敏捷、高效、自动化，同时加快实现可持续发展转型。 通过具体案例来看一下，什么是正确的云资源使用方式： 我们把某个具体的服务运行在两个可用区，通过实现从一个可用区到另一个可用区的实时故障切换，来获得高可用性。显而易见，这个服务在每个可用区都需要预留与实际工作负载相匹配有空闲资源。因此每个可用区的实际工作负载的能耗要限制在整体资源的 50% 以内。   但是，如果我们通过三个可用区实现这个服务的高可用性。那么我们在每个可用区只要预留总资源的 2/3 就可以满足实时的故障切换。因此我们可以看到，对于实时故障切换的高可用要求，三个可用区的选择，资源平均利用率更高，成本更低，故障的影响最小。 很简单，这就是云上资源的正确使用方式之一。   还有一个案例也很有趣，这是一个平衡 SLA 和可持续发展目标的案例： 针对非实时的故障切换业务，它们重要的考量因素是成本，用故障切换等待的时间来换取尽可能大的资源节省。 对于非实时故障切换的业务需求，我们可以通过优化故障切换的时长来实现可持续发展的目标。具体的方式是选择“冷容量”作为故障切换时服务资源的。 当需要故障切换的时候，我们在可用区里面寻找或者等待空闲的资源，再去做故障切换。虽然我们在切换的过程中牺牲了响应的时间，但是我们大幅度的减少了资源闲置所造成的浪费和能耗，从运行成本上实现可持续发展的目标。 其实如何正确的使用云上资源来实现可持续性发展的目标，最大的考量点是平衡不同业务的 SLA 和整体业务的可持续发展目标。在平衡工作负载的部署、业务部署、架构部署时做出正确的选择，这就是我们的最佳实践。 ## 优化软件与架构 我们可以通过改变软件和架构来减少资源消耗和产生的影响。包括：异步和调度、使用高能效的编程语言、移除或重构使用率低甚至是无用的负载组件、低代码化、优化开发者的终端设备产生的影响，使用匹配的数据访问和存储模式的软件以及架构。 ### 通过性能调度，减少因为“峰值”所产生的能耗  图中展示了一个服务在它业务生命周期中的性能曲线。三条基准线分别表示： - 平均能耗的消耗线 (Average) - 业务峰值的能耗 (Peak) - 业务运行所需要的资源 (Provisioned Capacity) 我们发现：服务使用的实际资源和能耗并不是平均能耗曲线下的面积，而是配置容量线下的面积。值得注意的是配置容量的大小取决于该应用的能耗峰值。通常情况下，基于高可用的考量，配置容量是能耗峰值的两倍。 如果，我们通过牺牲一定的 SLA 来低峰值，或者我们调整业务运行的方式，以整个业务周期来平均工作负载，再或者我们通过实施了一个队列来平滑负载。 如下图所示：  那么我们就能平衡能耗从峰值到平均的更好比例，就能降低能耗峰值，就能调低配置的容量。从而实现更少的资源占用，更少的能源消耗。 举个例子： 大多数企业都使用系统默认的时间运行 Crontab。这是一个通用的服务。试想云上所有企业的所有 Crontab 都在深夜3点被触发。那么 Crontab 在这一时间点上产生的能耗峰值就会推高他们所需云上资源的总容量。从可持续性发展的目标出发，这是可以被优化的。事实上，对于 Crontab 这样的服务，非实时的需求响应，不会对业务本身造成影响。因此可以通过事件驱动的架构和技术来平滑服务需求的峰值。具体的实现方式是通过事件路由器，如 Amazon Event Bridge 或者 [Amazon SNS](https://aws.amazon.com/cn/sns/?trk=cndc-detail)，将服务需求放入相应的缓冲区，再在通过队列服务如 [Amazon SQS](https://aws.amazon.com/cn/sqs/?trk=cndc-detail)，[Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) 来实现异步的、并行的处理和对 Crontab 需求的响应。 当然，也可以自己调度作业，或操作流程，不要统一在凌晨 3:00 触发，而是将触发事件分散开来，来降低服务能耗峰值。但是显然用事件驱动的架构，[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)技术来实现自动化程度更好，能耗峰值降低的效果更明显。 Crontab 服务业务场景是通过队列或缓冲区的手段降低业务能耗峰值，降低总容量配置，从而获得保证 SLA 的同时减少整体资源的使用和影响。除此之外，我们还可以通过优化手段在不改变成本的前提下，来减少资源争抢而提高性能，从而平衡 SLA 和可持续性发展的目标。 典型的场景有：应对工作的增加而扩大规模。扩容过程和扩容本身就使用了资源，如果把它降到最低。同样可以使用事件驱动，[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)技术，通过队列或缓冲器来按需弹性扩缩容，从而平滑需求的峰值，并保持所用资源处于高的持续利用率。 ### 高效的编程语言有助于减少能耗 对于开发者来说，使用高能效的编程语言来编译软件也是一个很好的可持续发展经验。当然这对于很多开发者来说，也是一个非常大的难题： > 什么才是高能效的语言？ > > 它的标准是什么？ > > 怎么去衡量它？ > > … 很多科学家早就为此做过研究，在 2017 年的报告中： 科学家设计了 10 个测试场景，对比了 27 种比较主流的语言在执行时间、能耗以及最大内存等不同场景下的能耗。结果 C 语言和 Rust 在能效方面无可争议的击败了其他的语言。它比开发者常用的 Java 能耗节省了 50%，比 Python 的能耗节省了98%。 Linux 的创始人也曾说过，他认为 Rust 是一门可以很好地解决问题的编程语言。Rust 在比肩 C 的效率的同时，还能避免各种不安全的风险。 亚马逊云科技向我们的开发者推荐 Rust 语言，同时亚马逊本身也是 Rust 语言的践行者。在亚马逊的多个重要的开源项目中，如用于支持[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)计算的开源虚拟化技术 ++[Firecraker](https://firecracker-microvm.github.io/?trk=cndc-detail)++、基于 Linux 的容器化操作系统++ [Bottlerocket](https://aws.amazon.com/cn/bottlerocket/?trk=cndc-detail ) ++都使用了 Rust 语言进行开发，并取得了巨大的成功。在亚马逊，Rust 已经成为构建大规模基础设施的关键，为 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 、Amazon EC2、[Amazon CloudFront](https://aws.amazon.com/cn/cloudfront/?trk=cndc-detail) 等提供关键性服务。亚马逊对 Rust 的信赖还表现在对他保持持续的贡献。自 2019 年以来亚马逊一直是 Rust 项目的赞助商， 2020 年开始雇佣 Rust 维护者和贡献者， 2021 年成为 Rust 基金会的创始成员。 ## 硬件 硬件的选择和优化对于可持续性发展转型的影响包括： - 用最少的硬件满足需求 - 选择合适的计算实例 - 使用托管服务 - GPUs 资源的优化 首先是计算实例上的选择所产生的影响。我们建议，使用能满足要求且影响最小的实例类型，帮助减少碳足迹。 以开发者熟知的 Graviton 为例：  Graviton 2 是由亚马逊云科技设计并开发的 ARM 架构的处理器。相比最近一代的 X86 实例，在应用服务器、微服务、视频编码、高性能计算、电子设计、自动化、游戏、开源数据库、内存缓存和基于 CPU、[机器学习](https://aws.amazon.com/cn/machine-learning/?trk=cndc-detail)推理等等广泛的工作负载中，它都可以提供高达 40% 的性价比，非常容易实现且迁移的成本不高。Graviton 2 是亚马逊云科技目前最省电的处理器之一。 在整个工作负载的运行过程中，Graviton 2 的确帮助开发者实现了能耗的节省。基于 Graviton 2 我们也发布了 Graviton 3。它与 Graviton 2 相比，价格性能又提高了 25%，能耗降低了 60%。在亚马逊云科技的很多核心的应用和服务，包括容器服务，[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)服务等，目前都与 Graviton 2 兼容。 可见，只是从计算实例上选择合适的计算实例，就可以帮助开发者在整体的可持续性发展目标进行优化。 ## 数据 当然还要考虑数据。完成了工作负载和数据迁移以后，对于数据的合理管理，存放介质的选择，也能够帮助开发者进一步实现可持续性发展的目标。这里有一些可供参考的最佳实践，包括： - 选择合适的数据访问和存储技术； - 制定数据分类政策； - 使用生命周期策略来自动删除不必要的数据； - 最大限度地减少超额配置 - 删除不需要的或多余的数据 - 使用共享文件系统或对象存储来访问公共数据 - 尽量减少网络间的数据移动 - 数据备份 具体来说，选择合适的存储介质和技术来存放不同类型的数据。或者使用智能分层的方式动态存放数据，都可以帮助开发者节省能耗。 例如在对象存储 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 中，就提供了各种类型供开发者选择：  挑选合适的存储介质和技术 从热数据，暖数据，冷数据，到需要删除或者归档的数据，开发者都可以选择不同的存储介质和技术。它们会对响应时间、存放成本、以及数据类型提供对应的技术支撑。一方面开发者可以很容易地实现数据的智能分层，另一方面也对数据有效的生命周期进行管理。 通过自动化的方式对不经常使用的数据进行归档，对所有数据进行标记和审查并设置报警机制，根据数据访问要求制定规则，使用策略来迁移或清除数据等等，可以大量的减少不必要存储资源的消耗，从大的层面上保证我们云上的计算或者是云上的业务更进一步的接近可持续性发展的一个目标。其实接下来我有一个小的基于亚马逊自己的研发工程师的一个小的实践，能够去优化我们的存储资源的，它就是优化日志存储。  数据访问及存储 ### 优化日志存储 我们会发现我们每天各个应用都会产生大量的日志文件，如果我们把大量的非结构化日志文件归档，或者存放在我们的 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 的对象存储里面，其实就可以去通过这种零散的数据结合在一起，能够让我们的空间有一个非常大的节省。我们本身的经验实践是节省了一个 EB 的，大家知道一个 EB 其实是有 100 万兆字节的这样一个容量的节省。另外其实我们的服务团队也对这种不同的压缩算法进行了大量的尝试。我们会发现从 gzip 到 LZ4 再到 ZSTD，其实它的压缩的效果是逐渐递加是明显的。我们也把它不同的压缩比展示给大家，大家可以根据实际的情况去做一个合理的选择。 ## 开发和部署  减少构件工具大小 最后一个方面实践就是关于开发和部署的，这是一个非常大的话题。首先我们通过一个有意思的真实案例作为引入，大家对 Amazon SDK for JavaScript 可能大家都不陌生，因为你每当浏览器或者是 node.js 的代码调用亚马逊云科技的服务的时候，几乎都会用到这样一个工具包。随着使用开发频次的增加，使用次数的一个增加，这个服务包的库的副本也会慢慢不断的膨胀，就会导致 SDK 的包越来越大。 我们知道大包的管理，其实对于能耗的消耗以及你的管理的人的消耗是是非常非常大的。于是我们在 SDK for Javascript 的第三个版本中，就引入了模块化的这种方式去来优化它。我们把大家共用的那些工具和代码去把它抽取出来，做成一个基本包。这个基本包以它为基础，再去上面去叠加你的个性化的一些代码，或者是你的一个工具。这个基础包就跟你之前你的开发如果要去实现一个具体的开发项目所去产生的附加的包比起来，它的容量节省了 75%。在这个包的基础之上，再去叠加不同的应用和工具的时候，也会去通过删减，去通过一系列的优化的方式，再去进一步的节省。我们会发现具体的应用在包的之上，再去叠加你的个性化的，或者是你特别需要的一些工具或者服务的时候，会在 75% 的节省之上，再去节省 50% 的容量。这个其实也是一个经验提供给各位，各位可以去来优化你的开发工具，实现你的资源的能耗，云上资源能耗的进一步的一个节省。 总而言之，其实我们会发现可持续性发展不是我们在某一个环节设定的目标，它就能实现的。就像在这个话题刚开始的时候所跟大家分享的一样，它是一个非常大而远的这么一个目标，我们其实是可以把它细分成不同的阶段性的、小的、可达的一个目标。在你的整个的开发和测试的流程里面，在每个过程里面去实现不同的可持续性发展的目标。积小成多，最终一定会能够加快你整体的可持续性发展目标的一个实现。  希望大家通过这期的内容，接下来能够去设置你的目标，并且去寻找你合理的工具去来了解这些最佳实践和这些经验，并且通过这些最佳实践去来在你的实际的工作中得到验证，产生新的最佳实践，欢迎与我们分享。 以上就是亚马逊可持续发展的架构模型，后续我们还将带来更多专业的技术类分享，请持续关注 Build On Cloud 微信公众号！