Hi, everyone, and welcome back.
Now, in today's video, we are going to discuss about the architecture of scaling based on Amazon SKUs
at a high level overview.
Now, in many of the organizations, the number of EC two instances that would be running in the production
environment directly correlates with the number of messages that are part of the rescue.
For example, let's say that there are ten messages in the US queue, and since there are two EC two
instances that are running each EC two instance will take care and process five messages and after processing
they upload the artifacts to the S3 bucket.
Now let's say tomorrow there is a big sale that is going on and in the US instead of ten message, there
are 10,000 messages.
Now, since there are high number of messages in the queue, there are two options.
First one is you keep only two easy to instance running and the processing of 10,000 messages will take
a lot of time.
So that is first option.
Second option is you increase the number of EC two instances that are running in the production environment,
let's say from 2 to 20.
So now 20 is two instances are running, 10,000 messages will be processed in much more quicker way.
However, increasing the number of EC two instance will also increase the cost.
Now, after sale has completed, the number of message in the queue has been reduced from 10,000 back
to ten.
So now what you have to do, you have to terminate the extra EC.
Two instances that we're running to reduce the overall cost.
Now in production environment, you want to implement such kind of architecture where EC two instances
are launched and terminated based on the number of messages in the queue.
And in fact in a lot of organizations you will see such kind of an architecture being implemented.
So at a high level overview, let's quickly look into what are the things that needs to be done in order
to achieve this kind of architecture.
Now, if you're making use of an auto scaling group, then in such cases you can configure it to launch
or terminate the easy two instances based on the number of messages that are part of the rescue.
Now, this can be explained with this diagram where you have an application that is reading the number
of messages that are part of the queue and it is storing the data in cloud watch.
Now, depending upon the data in cloud watch, the auto scaling either launches new set of instances
or it terminates the additional set of instances that we're running.
Now the question that comes is how does this specific application know how many messages are there in
rescue?
And the answer to this is one of the six attribute columns, approximate number of messages.
So let's go ahead and quickly look into it.
Now, for today's demo, I have a rescue and there are two messages that are available.
So if we open the rescue, we get the URL of the queue.
And based on this URL, you can go ahead and check how many messages are present.
So let's go ahead and quickly look into it.
So I have a CLI command call us eight us get attributes, we specify the queue URL over here and we
specify the attribute name and the name of the attribute here is approximate number of messages.
This is very similar to what we were discussing and the region is AP Southeast one.
Now if I quickly press enter here, you see that the number of messages it is showing is two and this
is the same thing that the application can do and it can publish it to a central service from which
auto scaling will launch and terminate the instances as required.
So this is one of the architecture designs that can be implemented in case if you have a use case where
you want to launch and terminate instances based on the number of messages.
So with this will conclude today's video.