Auto-Scaling

Loading...

From the course by Arizona State University

Data Management in the Cloud

16 ratings

Arizona State University

Data Management in the Cloud

16 ratings

Course 5 of 5 in the Specialization Data Systems

Ubiquitous, on-demand network access to shared pools of configurable computing resources ideally requires minimal management effort or service provider interaction. This course covers the essential characteristics of data processing in the cloud, service and deployment models, and key components of implementing Amazon Web Services, as well as constructing Hadoop clusters and performing MapReduce operations.

From the lesson

Cloud-Based Data Management

AWS Interfaces1:54

Auto-Scaling8:24

Scalable Data Processing18:59

AWS Security6:45

Meet the Instructors

Mohamed Sarwat
Assistant Professor
Computer Science and Engineering
Ming Zhao
Associate Professor
ASU School of Computing, Informatics, and Decision Systems Engineering.

Auto-scaling, meaning that to be able to scale in, scale out,

and scale up and down automatically,

is a very important characteristic of Cloud applications.

Because the Cloud resources are elastic,

so the application that we build will run on the Cloud resources should also be elastic.

Only in this way that we can fully enjoy the benefits of Cloud computing.

Of course, we can run,

we can import all source of application to the Cloud,

but that does not make those applications really Cloud applications.

A true native Cloud application must be elastic.

And for example, using the early model.com example that we learnt before,

this is a Cloud application because it can use the elastic resources that is available,

easy to handle the surge,

the huge surge in demand.

And that's what auto-scaling means.

But the Application itself is able automatically to scale up

when the demand increases by taking advantage

of the scalable resources available from the Cloud.

So, elastic Cloud application should be able to acquire Cloud resources on-demand,

including all kinds of resources such as compute and storage,

and then make efficient use of

the rented resources because we don't want to waste resources.

The resource that are rented,

that are acquired from the Cloud must be used efficiently, fully utilized.

And then, when the demand drops,

when the resources are not needed anymore,

the only resources should also be

relinquished timely quickly again so that we don't waste resources.

And these are three important characteristics of elastic Cloud application.

Being able to acquire resources on-demand,

and relinquish resource on-demand,

and they use the right resources efficiently.

So, how do we do auto-scaling?

I believe we mentioned this before that when we use resources from IaaS provider,

auto-scaling is comparatively more difficult than

we when we do it using the resources from a PaaS provider.

So this is indeed the case AWS.

AWS has limited support for auto-scaling.

So, there is indeed a service called auto-scaling

in the suite of services provided by AWS.

So, what this auto-scaling service does is the following.

So first, it will use the CloudWatch service,

which is another service for AWS to monitor utilization of the instances.

So this CloudWatch will allow the users to peek into

the instances and see the utilization of those instances in real time.

And when the auto-scaling service

detects that utilization in particular instance is a high,

then the auto-scaling service can trigger scaling actions.

Which means that it create additional instances to handle the load, distribute the load.

And then, when we have multiple instances to handle the load in a distributed function,

then we can use another service provider,

which we just call Elastic Load Balancing service to

automatic balance the load across the instances.

So this Elastic Load

Balancing service will be able to automatically distribute the request that is

received by the application across now

the different instances that are served in the same tier.

And this diagram illustrates this.

So we have the Elastic Load Balancing service here,

which is served as a proxy,

and it receives all the requests,

and then automatically send the requests to the different instances that

automatically scale up and down by auto-scaling service.

So that's the auto-scaling service that is available from AWS.

Like I imagine, it has a limited capability,

it is utilization based auto-scaling,

but we cannot do much more beyond that.

So more often, we want to do more than that.

And the way to do is,

we have to build our auto-scaling capability by ourselves,

and using SQS, using the queueing service from AWS.

So the way to do this is that,

we will use SQS to queue the requests received by one component of our application,

and then, based on the number of pending requests in the queue,

then we can automatically scale up and down the next component of our application.

So here, we have a simple example here.

We have a multi-tier application.

In this application, in fact, we have two tiers.

One is the web tier,

and the other is processing tier.

So you got familiar with the multi-tier application,

then this should be issued already to all these different tiers.

So we just focus on two tiers,

web tier and the processing tier.

We assume that the web tier is using a single instance or rather web tier is sufficient.

We don't have to auto-scale the web tier.

But we do want to auto-scale the processing service,

or the app tier.

And we could accomplish that by using the SQS service,

by using specifically two queues.

So we have a request queue,

which we use to queue the requests.

So the requests, they will come from the users,

and they are processed by the web server,

the web server will deposit the requests to the request queue.

And then the process, the updated tier,

the processing servers will choose the request from that request queue.

And based on the number requests in the queue,

the application can decide how many instances that

need to be run in order to handle all the pending requests now in the queue.

So we can measure the length of the queue,

and use the massive queue to infer that the load,

the current load on the application.

And then after these requests are processed by the processing servers,

the responses are also queued in the response queue.

The web server then will retrieve those responses from request queue,

and then send them back to the users.

So, in this way, we used the SQS first to decouple,

to guide the different tiers of our application.

And then we use this SQS,

this two queues to allow the two tiers to operate at different speed,

and to allow the app tier to automatically scale up

and down based on the load that is received by the application.

This is indeed one typical way to implement auto-scaling for a call application,

does not have to be a one-tier application like this.

This prior time can be used to support auto-scaling for

any application as long as you can decouple the components in the application,

and then figure out which components need to be automatically scaled up and down.

Then you can use the queues to support it, to implement auto-scaling.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2019 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play