aws 弹性三剑客_AWS和弹性：超越用户需求

aws 弹性三剑客

I’ll assume that, one way or another, you’re already familiar with many of AWS’s core deployment services. That means you now know about:

我假设您已经熟悉许多AWS的核心部署服务。 这意味着您现在知道：

• EC2 instances and AMIs (Amazon Machine Images), and the “peripheral” tools that support their deployment like security groups and EBS volumes

•EC2实例和AMI(Amazon机器映像)，以及支持其部署的“外围”工具，例如安全组和EBS卷

• Incorporating databases into our applications, both on-instance and through the managed RDS service

•实例化和通过托管RDS服务将数据库整合到我们的应用程序中

• Using S3 buckets to deliver media files through our EC2 applications and for server backup storage

•使用S3存储桶通过我们的EC2应用程序传递媒体文件并用于服务器备份存储

• Controlling access to our AWS resources with IAM (Identity and Access Management)

•使用IAM(身份和访问管理)控制对我们AWS资源的访问

• Managing growing resource sets by intelligently applying tags, and

•通过智能地应用标签来管理不断增长的资源集，以及

• Accessing our resources using either the browser interface or the AWS CLI (Command Line Interface)

•使用浏览器界面或AWS CLI(命令行界面)访问我们的资源

All that can be represented by the schematic in figure 1.

所有这些都可以由图1中的示意图表示。

Now I’m going to shift the focus just a bit and explore some best-practices for application optimization. Figure 2 can help you visualize how all that infrastructure can be made highly available through the magic of network segmenting, auto scaling, and load balancing.

现在，我将重点转移一点，并探索一些应用程序优化的最佳实践。 图2可以帮助您可视化如何通过网络分段，自动扩展和负载平衡的魔力使所有基础设施高度可用。

While you probably won’t yet be familiar with many of the tools and relationships represented in the diagram, you should spend a minute making a mental note of at least a few key points, including:

尽管您可能还不熟悉图中所示的许多工具和关系，但是您应该花一点时间至少记下一些关键点，包括：

• The Virtual Private Cloud (VPC) that encompasses all the AWS resources in our application deployment

•虚拟私有云(VPC)包含我们应用程序部署中的所有AWS资源

• The two kinds of availability zones: private and public — used to manage and, where needed, isolate resources

•两种可用性区域：私有和公共-用于管理资源，并在需要时隔离资源

• The security groups whose rules control the movement of data between resources

•其规则控制资源之间的数据移动的安全组

• The EC2 AMI (Amazon Machine Image) that acts as a template for replicating precise operating system environments

•EC2 AMI(Amazon机器映像)，用作复制精确的操作系统环境的模板

• The S3 (Simple Storage Service) bucket that can store and deliver data — both for backup and delivery to users

•S3(简单存储服务)存储桶，可以存储和交付数据-既可以备份又可以交付给用户

• The EBS volumes that act as data volumes (like hard drives) for an instance

•充当实例的数据卷(例如硬盘驱动器)的EBS卷

• The auto scaler that permits automatic provisioning of greater (or fewer) instances to meet changing demands on an application, and

•自动缩放器，允许自动设置更多(或更少)的实例，以满足对应用程序不断变化的需求，以及

• The load balancer that routes traffic among multiple servers to ensure the smoothest and most efficient user experience

•在多个服务器之间路由流量的负载平衡器，以确保最流畅，最有效的用户体验

I’m pretty sure you’ve picked up on this already: the “e” in many AWS service names (EC2, ECS, EFS, EMR…) doesn’t stand for “electronic” the way it does in the names of some older technologies like email, but “elastic.” You can, nevertheless, be excused for wondering just what it is about the AWS vision of cloud computing that’s so elastic.

我敢肯定，您已经掌握了这一点：许多AWS服务名称(EC2，ECS，EFS，EMR…)中的“ e”并不代表某些名称中的“电子”方式较早的技术(例如电子邮件)，但具有“弹性”。 但是，您可以因怀疑AWS如此灵活的云计算愿景而感到困惑。

But before I get to answering that question, it might be useful to talk a bit about cloud computing in general. Understanding what makes the cloud unique is probably essential to taking full advantage of all that it has to offer.

但是，在我开始回答这个问题之前，通常先讨论一下云计算可能会很有用。 要充分利用云所提供的一切，了解云独特的原因可能是必不可少的。

云计算 (Cloud Computing)

The US National Institute of Standards and Technology (NIST) defines cloud computing as services that offer their users all of these five qualities:

美国国家标准技术研究院(NIST)将云计算定义为为用户提供以下五种品质的服务：

• On-demand self-service: Customers are able to access public cloud resources whenever needed and without having to order them through a human representative.

•按需自助服务：客户可以在需要时访问公共云资源，而不必通过人工代表订购。

• Broad network access: Cloud resources are accessible from any network-connected (i.e., Internet) location.

•广泛的网络访问：可从任何网络连接(即Internet)位置访问云资源。

• Resource pooling: Cloud providers offer a multi-tenant model, whereby individual customers can safely share resources with each other, and dynamic resource assignment, through which resources can be allocated and deallocated according to customer demand.

•资源池：云提供商提供了多租户模型，单个客户可以安全地共享彼此的资源，并可以动态分配资源，从而可以根据客户需求分配和重新分配资源。

• Rapid elasticity: Resource availability and performance can be automatically increased or decreased to meet changing customer demand.

•快速弹性：可以自动增加或减少资源可用性和性能，以满足不断变化的客户需求。

• Measured service: Customers are able to consume services at varying levels through a single billing period and be charged only for those resources that they actually use.

•计量服务：客户可以在一个计费周期内使用不同级别的服务，并且仅对其实际使用的资源付费。

These five qualities describe a deeply flexible and highly automated system whose elements can be freely mixed and matched to provide the most efficient and cost-effective service possible. But, a great deal of what makes this possible is the existence of integrated systems that can dynamically adjust themselves based on what’s going on around them. These adjustments are examples of elastic behavior.

这五种品质描述了一个高度灵活且高度自动化的系统，该系统的各个要素可以自由混合和匹配，以提供最高效，最具成本效益的服务。 但是，使这成为可能的很多原因是存在集成系统，这些系统可以根据周围发生的事情动态地进行自我调整。 这些调整是弹性行为的示例。

弹性与可伸缩性 (Elasticity vs Scalability)

So elasticity, as we have established, is a system’s ability to monitor user demand and automatically increase and decrease deployed resources accordingly. Scalability, by contrast, is a system’s ability to monitor user demand and automatically increase and decrease…wait: didn’t I just say that about elasticity?

因此，正如我们已经建立的，弹性是系统监视用户需求并相应地自动增加和减少已部署资源的能力。 相比之下，可伸缩性是系统监视用户需求并自动增加和减少…的能力……等等：我不是只是说弹性吗？

It’s a bit complicated. In fact, the two terms are sometimes used interchangeably. However I think it’s worthwhile distinguishing between them. Now bear in mind that the way I explain the relationship between these two ideas is by no means the last word on the subject -– look around a bit and you will find some other approaches. But, I think, within the context of understanding how AWS works, my spin should be useful.

这有点复杂。 实际上，这两个术语有时可以互换使用。 但是，我认为有必要区分它们。 现在请记住，我解释这两种想法之间关系的方式绝不是该主题的最后一句话-环顾四周，您会发现其他一些方法。 但是，我认为，在了解AWS如何工作的背景下，我的旋转应该会很有用。

What makes an elastic band elastic, is partly its ability to stretch under pressure, but also the way it quickly returns to its original size when the pressure is released. In AWS terms, that would mean the way, for instance, EC2 makes instances available to you when needed, but lets you drop them when they’re not; charging you only for up time. See figure 3.

使松紧带具有弹性的部分原因是其在压力下拉伸的能力，而且还在于在释放压力后Swift恢复其原始大小的方式。 用AWS术语来说，这意味着，例如，EC2可以在需要时向您提供实例，而在不需要时可以将它们删除； 仅向您收费。 参见图3。

Scalability describes the way a system is designed to meet changing demand. That might include the fact that you’ve got 24-hour access to any resources you might need (which, of course, is an elastic feature), but it also means that the underlying design itself supports rapid and unpredictable changes.

可伸缩性描述了系统满足不断变化的需求的方式。 这可能包括以下事实：您可以24小时访问您可能需要的任何资源(这当然是一种弹性功能)，但这也意味着底层设计本身支持快速且不可预测的更改。

As an example, software that’s scalable can be easily picked up and dropped onto a new server -– possibly within a new network environment -– and just run without any manual configuration. Similarly, as is illustrated in figure 4, the composition of a scalable infrastructure can be quickly changed in a way that all the old bits and pieces immediately know how to work together with the new ones.

例如，可以轻松地将可伸缩的软件安装到新服务器上(可能在新的网络环境中)并放到新服务器上，而无需任何手动配置即可运行。 类似地，如图4所示，可伸缩基础结构的组成可以以所有旧的点点滴滴都立即知道如何与新的点点滴滴一起工作的方式快速更改。

With that in mind, we can say that Amazon’s EC2 is not only elastic but, since its elements (instances, storage volumes, security groups, etc.) can be smoothly dropped into and out of running infrastructures, it’s also very scalable. Ah, but what kind of scalable? There are two, you know:

考虑到这一点，我们可以说Amazon EC2不仅具有弹性，而且由于其元素(实例，存储量，安全组等)可以顺利地放入和退出运行的基础架构，因此它也具有很好的可扩展性。 嗯，但是什么样的可扩展性？ 有两个，您知道的：

• Horizontal scaling is “scaling out” — where you add more lightweight server nodes (or “instances”) to meet growing demand.

•水平扩展是“向外扩展” —在其中添加更多轻量级服务器节点(或“实例”)以满足不断增长的需求。

• Vertical scaling is “scaling up” — where you move your application from a single lightweight server to one with greater compute capacity.

•垂直扩展是“向上扩展” —您将应用程序从单个轻量级服务器移至具有更大计算能力的服务器。

It is certainly possible to transfer AWS-based applications from lighter to heavier servers, and for some payloads — like many high-load transaction databases, it’s preferred. But in an AWS context, if you hear some conjugation of the word “scale”, the odds are that it’s referring to horizontal scaling.

当然，可以将基于AWS的应用程序从较轻的服务器转移到较重的服务器，并且对于某些负载(例如许多高负载事务数据库)，它是首选。 但是在AWS环境中，如果您听到“ scale”一词的一些变化，那么很可能是指水平缩放。

实际应用 (Practical applications)

Ok. But who cares? Well, as the customer demand on our WordPress site continues to grow, we will, and in a big way. You see, for some reason -– perhaps related to the fact that we discount the price of our product by 75% for just a half an hour each evening -– customers arrive in their greatest numbers in the early evening, local time. So while the single server we’ve been running stands largely unused throughout most of the day, it simply melts under the pressure of thousands of visits squeezed into such a short stretch of time.

好。 但谁在乎？ 好吧，随着我们WordPress网站上的客户需求持续增长，我们将以极大的方式发展。 您会看到某些原因-也许与我们每晚将产品价格降低75％的事实有关-每天晚上半小时客户到达的数量最多。 因此，尽管我们一直在运行的单个服务器在一天中的大部分时间里都处于闲置状态，但它却在成千上万次访问的压力下融化了，而访问却被压缩到如此短的时间内。

And then there’s that question one of the guys in the office asked the other day: “Our entire business is running on a single web server; what happens if it goes down?” What indeed.

那天办公室里的一个人问了一个问题：“我们的整个业务都在一台Web服务器上运行； 如果它下降怎么办？” 的确如此。

We could provision four or five extra servers and run them full time. That way, we’d be covered for the high-volume periods and for the failure of any one server. But it would still involve colossal waste, since for most of each day we’d be paying for most of the instances to sit idle. Nor would it necessarily be much help in the event of a network failure, which would likely cut connectivity to all the servers at the same time.

我们可以提供四到五台额外的服务器，并全时运行它们。 这样一来，我们就可以应对大批量交易以及任何一台服务器的故障。 但这仍然会带来巨大的浪费，因为在每天的大部分时间里，我们都会为大多数实例保持空闲状态付费。 如果发生网络故障，也不一定会有太大帮助，因为这可能会同时切断与所有服务器的连接。

We could always address at least the customer demand issue by arranging for someone to be at the office every evening to manually fire up as many extra servers as we’ll need. But we asked around, and no one volunteered. And besides, the best way to ensure a daily job won’t get done is to assume that an admin will remember to do it.

我们总是可以安排每天晚上到办公室来手动启动尽可能多的额外服务器，从而至少解决客户需求问题。 但是我们四处询问，没有人自愿参加。 此外，确保日常工作不会完成的最好方法是假设管理员会记得这样做。

自动化高可用性 (Automating High Availability)

Alternatively, we could spend some time incorporating high availability capability into our setup and let the whole thing be quietly and efficiently managed by software. This will be the subject of the next few chapters of my book, where we will learn to leverage AWS’s geographically remote availability zones to make total application failure much less likely, use load balancing to coordinate between parallel servers and monitor their health, and auto scaling to let AWS automatically respond to the peaks and valleys of changing demand by launching and shutting down instances according to need.

另外，我们可以花一些时间将高可用性功能整合到我们的设置中，然后让整个过程由软件安静有效地管理。 这将是本书接下来几章的主题，我们将在其中学习如何利用AWS的地理位置远程可用性区域来降低应用程序整体故障的可能性，使用负载平衡来协调并行服务器之间的状态并监控其运行状况，并自动扩展让AWS通过根据需要启动和关闭实例来自动响应需求变化的高峰和低谷。

For more info on Amazon Web Services, download the free first chapter of Learn Amazon Web Service in a Month of Lunches and see this Slideshare presentation. Don’t forget to use code ssclinton to save 42% off your purchase.

有关Amazon Web Services的更多信息， 请在一个月的午餐中下载学习Amazon Web Service的免费第一章，并参阅此Slideshare演示文稿 。 不要忘了使用代码ssclinton节省42％的购买费用。

翻译自: https://www.freecodecamp.org/news/aws-and-elasticity-keeping-ahead-of-user-demand/

aws 弹性三剑客