从个人到互联网规模：编程Amazon EC2全攻略

需积分: 9 196 浏览量更新于2024-07-17 收藏 4.22MB PDF 举报

"《编程亚马逊EC2》是一本由Jurg van Vliet和Flavia Paganelli合著的权威指南，专为在亚马逊网络服务（AWS）上构建和发展应用程序而设计。本书的目标读者是那些希望托管个人博客或小型Web应用的开发者，同时也涵盖了如何像社交游戏公司Zynga通过Farmville那样实现业务增长。作为一本AWS EC2方面的实用教程，它深入讲解了如何利用云计算平台来扩展应用，从初创阶段到互联网级别的规模。书中内容详尽，覆盖了从基础入门到高级实践的所有层面，包括但不限于设置和管理EC2实例、安全性和访问控制、弹性负载均衡、自动缩放、存储选项（如EBS和S3）、以及如何优化性能和成本。读者将学习如何部署稳定且可扩展的服务，充分利用Amazon VPC和容器技术（如Docker on ECS），并理解如何处理监控和日志管理。此外，该书还提到了在线版本的获取途径，即通过O'Reilly Safari Online Library获取，适合教育机构和个人购买。书中强调版权信息，声明了O'Reilly Media Inc.的多项商标，并列出了编辑、生产编辑、校对人员等幕后团队的工作。封面设计、内部设计以及插图都展现了专业品质，确保了读者在阅读过程中获得清晰易懂的视觉体验。《编程亚马逊EC2》是一本紧跟时代潮流的技术手册，无论是对个人开发者还是企业架构师，都能提供宝贵的实践经验，帮助他们在云计算的大潮中稳健前行，实现业务的持续成长。"

CHAPTER 1

Introducing AWS

From 0 to AWS

By the late 1990s, Amazon had proven its success—it showed that people were willing

to shop online.

Amazon generated $15.7 million in sales in 1996, its first full fiscal year.

Just three years later, Amazon saw $1.6 billion in sales, and Jeff Bezos was chosen

Person of the Year by Time magazine. Realizing its sales volume was only 0.5% that of

Wal-Mart, Amazon set some new business goals. One of these goals was to change

from shop to platform.

At this time, Amazon was struggling with its infrastructure. It was a classic monolithic

system, which was very difficult to scale, and Amazon wanted to open it up to third-

party developers. In 2002, Amazon created the initial AWS, an interface to program-

matically access Amazon’s features. This first set of APIs is described in the wonderful

book

Amazon Hacks by Paul Bausch (O’Reilly), which still sits prominently on one of

our shelves.

But the main problem persisted—the size of the Amazon website was just too big for

conventional (web) application development techniques. Somehow, Jeff Bezos found

Werner Vogels (now CTO of Amazon) and lured him to Amazon in 2004 to help fix

these problems. And this is when it started for the rest of us. The problem of size was

addressed, and slowly

AWS transformed from “shop API” to an “infrastructure cloud.”

To illustrate exactly what AWS can do for you, we want to take you through the last

six years of AWS evolution (see Figure 1-1 for a timeline). This is not just a historical

journey, but also a friendly way to introduce the most important components for start-

ing with AWS.

AWS has two unique qualities:

• It doesn’t cost much to get started. For example, you don’t have to buy a server to

run it.

• It scales and continues to run at a low cost. For example, you can scale elastically,

only paying for what you need.

The second quality is by design, since dealing with scale was the initial problem AWS

was designed to address. The first quality is somewhat of a bonus, but Amazon has

really used this quality to its (and our) advantage. No service in AWS is useless, so let’s

go through them in the order they were introduced, and try to understand what prob-

lems they were designed to solve.

Figure 1-1. Timeline of AWS

Biggest Problem First

If your system gets too big, the easiest (and perhaps only) solution is to break it up into

smaller pieces that have as few dependencies on each other as possible. This is often

referred to as decoupling. The first big systems that applied this technique were not web

applications; they were applications for big corporations like airlines and banks. These

applications were built using tools such as

CORBA and the concept of “component-

based software engineering.” Similar design principles were used to coin the more re-

cent term service-oriented architecture or SOA which is mostly applied to web appli-

cations and their interactions.

Amazon adopted one of the elements of these broker systems, namely message pass-

ing. If you break up a big system into smaller components, they probably still need to

exchange some information. They can pass messages to each other, and the order in

which these messages are passed is often important. The simplest way of organizing a

message passing system, respecting order, is a queue (

Figure 1-2). And that is exactly

what Amazon built first in 2004:

Amazon Simple Queue Service or SQS.

By using SQS, according to AWS, “developers can simply move data between distrib-

uted components of their applications that perform different tasks, without losing

messages or requiring each component to be always available.” This is exactly what

Amazon needed to start deconstructing its own monolithic application. One interesting

feature of SQS is that you can rely on the queue as a buffer between your components,

implementing elasticity. In many cases, your web shop will have huge peaks, generating

80% of the orders in 20% of the time. You can have a component that processes these

orders, and a queue containing them. Your web application puts orders in the queue,

2 | Chapter 1: Introducing AWS

and then your processing component can work on the orders the entire day without

overloading your web application.

Figure 1-2. Passing messages using a queue

Infinite Storage

every

application, storage is an issue. There is a very famous quote attributed to Bill

Gates that 640 K “ought to be enough for anybody.” Of course, he denies having said

this, but it does hit a nerve. We all buy hard disks believing they will be more than

enough for our requirements, but within two years we already need more. It seems

there is always something to store and there is never enough space to store it. What we

need is infinite storage.

To fix this problem once and for all, Amazon introduced

Amazon Simple Storage Serv-

ice or S3

. It was released in 2006, two years after Amazon announced SQS. The time

Amazon took to release it shows that storage is not an easy problem to solve. S3 allows

you to store objects of up to 5 terabytes, and the number of objects you can store is

unlimited. An average DivX is somewhere between 600 and 700 megabytes. Building

a video rental service on top of S3 is not such a bad idea, as Netflix realized.

According to AWS, S3 is “designed to provide 99.999999999% durability and 99.99%

availability of objects over a given year.” This is a bit abstract, and people often ask us

what it means. We have tried to calculate it ourselves, but the tech reviewers did not

agree with our math skills. So this is the perfect opportunity to quote someone else.

According to Amazon Evangelist Jeff Barr, this many 9s means that, “If you store 10,000

objects with us, on average we may lose one of them every 10 million years or so.”

Impressive! S3 as a service is covered by a service level agreement (SLA), making these

numbers not just a promise but a full contract.

S3 was extremely well received. Even Microsoft was (or is) one of the customers using

S3 as a storage solution, as advertised in one of the announcements of AWS:

“Global

enterprises like Microsoft are using Amazon S3 to dramatically reduce their storage

costs without compromising scale or reliability”. In only two years, S3 grew to store 10

billion objects. In early 2010, AWS reported to store 102 billion objects in S3.

Fig-

ure 1-3

illustrates the growth of S3 since its release.

From 0 to AWS | 3

In 2007, EC2 was opened to everyone, but it took more than a year before AWS an-

nounced general availability, including SLA. There were some very important features

added in the meantime, most of them as a result of working with the initial community

of EC2 users. During this period of refining EC2, AWS earned the respect of the de-

velopment community. It showed that Amazon listened and, more importantly, cared.

And this is still true today. The Amazon support forum is perhaps its strongest asset.

By offering computing capacity per hour, AWS created elasticity of infrastructures from

the point of view of the application developer (which is also our point of view.) When

it was this easy to launch servers, which Amazon calls instances, a whole new range of

applications became reachable to a lot of people. Event-driven websites, for example,

can scale up just before and during the event and can run at low capacity the rest of the

time. Also, computational-intensive applications, such as weather forecasting, are

much easier and cheaper to build. Renting one instance for 10,000 hours is just as cheap

as renting 10,000 instances for an hour.

Very Scalable Data Store

Amazon’s big system is decoupled with the use of SQS and S3. Components can com-

municate effectively using queues and can share large amounts of data using S3. But

these services are not sufficient as glue between the different applications. In fact, most

of the interesting data is structured and is stored in shared databases. It is the relational

database that dominates this space, but relational databases are not terribly good at

scaling, at least for commodity hardware components. Amazon introduced Relational

Database Server (RDS) recently, sort of “relational database as a service,” but its own

problem dictated that it needed something else first.

Although normalizing data is what we have been taught, it is not the only way of han-

dling information. It is surprising what you can achieve when you limit yourself to a

searchable list of structured records. You will lose some speed on each individual

transaction because you have to do more operations, but you gain infinite scalability.

You will be able to do many more simultaneous transactions. Amazon implemented

this in an internal system called Dynamo, and later, AWS launched

Amazon SimpleDB.

It might appear that the lack of joins severely limits the usefulness of a database, espe-

cially when you have a client-server architecture with dumb terminals and a mainframe

server. You don’t want to ask the mainframe seven questions when one would be

enough. A browser is far from a dumb client, though. It is optimized to request multiple

sources at the same time. Now, with a service specially designed for many parallel

searches, we have a lot of possibilities. By accessing a user’s client ID, we can get her

wish list, her shopping card, and her recent searches, all at the same time.

From 0 to AWS | 5

www.allitebooks.com

剩余173页未读，继续阅读

kanlaw0420

粉丝: 1
资源: 62

从个人到互联网规模：编程Amazon EC2全攻略

亚马逊EC2编程指南

亚马逊EC2编程实战指南

programming-openresty

Parallel Programming with Spark

carryhome_node_api:随身携带API接口| 节点| EC2-AWS

亚马逊API JAVA

mini2S:使用JPA和RestAPI开发板

PyPI 官网下载 | fabazon-0.3.1-py2-none-any.whl

pandas-1.3.5-cp37-cp37m-macosx_10_9_x86_64.zip

基于java的大学生兼职信息系统答辩PPT.pptx

最新资源