1. What is SQS?
Let’s talk about what SQS is. This entire lecture is theoretical. We’re going to look at different examples, but it can be quite wordy. So just see if you can follow me. So, Amazon SQS is a web service that gives you access to a message queue that can be used to store messages while waiting for a computer to process them. So we have an example of a web application. Maybe you upload an image file to this web application, and then what that web application will do is alert SQS that a user has uploaded an image file and that a job needs to be executed on it.
So it will store that message on the SQS system. You’ll then have some application servers queueing that SQS system, and it’ll say, “Oh wow, look, I’ve got a new job that’s just come in.” A user’s uploaded an image. These application services might then access that image, which should be stored in, say, an S3 bucket, and do a task on it, like, say, applying a watermark, for example. Once that has been done, the application servers will update that queue and then remove that message from the queue. So it’s basically a way of decoupling your environment, or loosely coupling your environment, so that if you lose that web server, that message is still in the queue, and the application server can still go through and run it. Another example is that if an application server fails while attempting to watermark an image, other application servers can step in and complete the task, which we’ll discuss in more detail later.
So Amazon SQS is a distributed queue system that enables web service applications and reliably routes messages that one component in the application generates to another component. So that was my example of a web server generating a message that an application server needs to go in and do something inside an S3 bucket. A queue is a temporary repository for messages that are awaiting processing. Using Amazon SQS, you can decouple components of an application so they run independently with Amazon SQS, easing message management between components. Any component of a distributed application can store messages in a fail-safe queue. Messages can contain up to 256 characters in any format. Now remember that number because it comes up time and time again in the exam. How large can your SQS be? It’s 256 KB.
Any component can later retrieve the messages programmatically using the Amazon SQS API. The queue acts as a buffer between the component producing and saving the data. So think of the web services and the component receiving the data for processing as being your application services. This means that the queue resolves issues that arise if the producer is producing work faster than the consumer can process it or if the producer or consumer are only intermittently connected to the network. So they’re basically talking about either autoscaling there or talking about failover. So we’ll cover both scenarios in a couple of slides. Amazon SQS ensures delivery of each message at least once and supports multiple readers and writers interacting with the same queue.
A single queue can be used simultaneously by many distributed application components, without the need for those components to coordinate with each other to share the queue. As a result, it’s an excellent method for scaling out your applications. Amazon SQS is engineered to always be available and deliver messages. One of the resulting trade-offs is that SQS does not guarantee first-in, first-out delivery of messages. For many distributed applications, each message can stand on its own, and as long as all messages are delivered, the order is not important. If your system requires that order be preserved, you can place sequencing information in each message so that you can reorder the messages when the queue returns them. And so this is the example I was talking about earlier. And do remember that first in, first out bit because it is an exam question, but we’ve got a slide with all the different exam tips that are coming up. So to illustrate, suppose you have a large number of image files to encode in an Amazon SQS worker queue. You can create an Amazon SQS message for each file, specifying the command and the location of the file in Amazon. S three, create a pool of Amazon and EC2 instances running the required image-processing software, and then proceed as follows: So basically, they’re going to asynchronously pull task messages from the queue. So they’re going to go in there and pull the messages from the queue. Also, notice that I said “pull” rather than “push.” That’s also an exam question.
Messages are always pulled by SQS. The message queue is never pushed out. You’ve got EC running in two instances, constantly pulling the queue and trying to pull data down. That’s a big deal because it distinguishes it from things like simple notification services, which we’ll go over in another lecture. So basically, it’s polling the messages from the queue. It then retrieves the file name of the image. It then processes the conversion and might apply a watermark. It then writes the image back to S 3. It then writes a task-complete message to another queue, deletes the original task message, and checks for more messages in the worker queue.
Okay, so let’s look at this diagrammatically. So basically, component one, which we’ll call component one, is our web server. It’s sent a message to the queue, and there’s a visibility timeout clock as to how long that message is going to be visible in the queue. Now, component two would be our application server. It retrieves the message from the queue, and the visibility timeout period starts. So it’s important to remember that the visibility timeout period only starts when the application server has picked up the message. And that’s how Amazon guaranteed that message would be delivered at least once. So, basically, component two processes that message.
So this is our application server. It is now adding a watermark to that image. And then, once it’s completed, it will delete it from the queue during the visibility timeout period. Now, if something happens and that visibility timeout expires, for example, if our application server goes offline and it doesn’t get a chance to do the watermark for that web application, that’s fine; that message will remain in the queue and will not be deleted. And then another application server will pull that queue; it will see that that message has expired, that the visibility clock has timed out, and it will assume that there’s been a failure somewhere, and it will then pull that message in and then start its own encoding on it. So keep in mind that it is only complete when it is deleted from the message queue; that is when it is finished. SQS can also do auto-scaling, so you can configure auto-scaling groups too.
And if we looked at our auto-scaling example, we had thresholds set so that if you hit 85% CPU utilization, you could add additional servers. We can also configure auto-scaling so that if the queue gets beyond a certain size, we’ll start spinning up more application servers to deal with that. So maybe you’ve created a new meme and it’s gone viral; you’ve posted it to Reddit or something, and someone’s completely made up a new meme, and suddenly everyone is just flooding at your website, wanting to produce that meme with all kinds of different sayings on it. So what your application servers will do through auto scaling is they’ll see that that queue is growing rapidly, and you can set at what point you want to auto scale.
But then your auto-scaling groups can come in and basically spin up multiple application servers, depending on how you set it, to then reduce the size of that queue and bring it down. After that queue has died down, you can use auto-scaling to begin terminating instances. So it’s completely flexible. which is why using auto scaling with SQS is so powerful. And it’s basically some of the backbones of some of the biggest websites out there, like Netflix, Reddit, or any of these meme websites where you’re encoding images; this is exactly how they structure it. So you’ve got SQS and auto scaling working together. So I have some exam tips for you. It does not offer first in, first out. You’ve got a visibility timeout window of 12 hours. By default. SQS is designed to deliver all messages in its queue at least once. Although each message is usually delivered to your application only once, You should design your system so that processing a message more than once does not create any errors or consistency issues. So that’s really down to your developers. 256-bit message sizing is now available. Originally, they were 64 kilobytes, so the billing is still based on the old message sizes. So you’re billed in 64 KB chunks. So you effectively get four chunks per message size effectively. Now we’ll just go over the pricing. So your first 1 million AmazonSQS requests per month are free. It’s fifty cents per one million Amazon SQS requests per month thereafter. And a single request can have from one to ten messages, or up to a maximum payload of 256. The final piece is that each 64-kilobyte chunk of a payload is billed as one request.
So even though you might be making just one API call for a 256-kilobyte payload, that’s actually going to be billed as four requests because 64256 divided by 64 is equal to four times. So even though you’re making one request, you’re still going to be billed for four requests because it’s basically an old system where it used to be 64 kilobyte chunks. Okay? So that really covers SQS. You just really need to know. And it does mention it in the exam. The blueprint talks about how you can decouple your infrastructure. Anytime you see the word “decouple,” just think SQS. That’s what they’re looking for. Remember the size of the payload. So it’s a 256-kilobyte payload, but when it comes in, the billing is done in 64-kilobyte chunks. It’s first in, first out. It guarantees that your messages will be delivered at least once. and that’s pretty much it. Oh, and you can apply auto-scaling to SQS. So if you have any questions, please let me know. If you do the exam and you see something else that comes up that we haven’t covered, please let us know what that is, and I’ll update the course accordingly. And if you’ve got time, please move on to the next lecture. Thank you.
2. SQS Developer Exam Tips
Lecture. So the first thing I want to start off with is SQS delivery. And this is really important to remember because SQS messages can be delivered multiple times and in any order. So you might get a question about how you’ve got to process your messages in order, or some messages might need a higher priority than other messages.
What should you do in a situation like that? If you need to process one type or set of messages faster than another, you’d simply create two queues. So you’d have your QA, which would get a higher priority in your application, and then you’d have your QA, which would be a lower priority. So that’s the way you would split it out. But that is just a really important point to remember when you go into the exam: that the messages can be received and processed in any order. There’s no first in, first out, last in, first out, or anything like that. So do remember that going into the next exam is about the default visibility timeout. So by default, your visibility timeout is 30 seconds. So this is how long the message will be hidden in the queue. The maximum for that is 12 hours. And you can change your message’s visibility.
So when you receive a message from the queue and begin processing it, you may find that the visibility timeout for the queue is insufficient to fully process and delete the message. To give yourself more time to process the message, you can extend its visibility timeout by using the Change Message Visibility action to specify a new timeout value. Amazon SQS restarts the timeout period using the new value. So just remember that call. It’s called a change message. Polling with high visibility. So questions will frequently arise, and we’ll see in the next slide how to use SQS to save money and how to stop constantly polling the queue when it’s empty. Long polling is the only way to accomplish this. So SQS long polling is a way to retrieve messages from your SQS queues, while traditional SQS short polling returns messages immediately. Even if the queue being polled is empty, SQS long polling doesn’t return a response until a message arrives in the queue or the long pole times out. SQS long polling makes retrieving messages from your SQS queue easier and less expensive as long as they are available. So the maximum long poll timeout is 20 seconds. So I want you to think about this for a second. If you’ve got an EC2 instance, it sends a queue request to the SQS queue, and just normal polling is enabled, also known as standard polling or short polling. Sometimes it’s referred to, and that queue is empty. It may then wait a few seconds before re-polling the queue, and it is simply polling an empty queue.
And you’re getting charged for that from SQS. You’re just burning through CPU cycles, and it’s costing you extra money. So if you enable long polling on an SQS queue, basically your EC2 instance sends a request saying, “Are there any messages?” And then it just waits. And it waits for the length of time that a long poll timeout is set. So, if you set it to the maximum of 20 seconds, your SQSQ will send a message to the EC-2 message saying, “Yeah, I’ve got a message for you.” However, if nothing happens or no messages are received, it will wait for the specified amount of time. So, if you set the maximum, or long pole timeout, it will wait for that amount of time before returning an empty result. So then, that way, you only need to pull the queue once every 20 seconds, as opposed to polling the queue every two or three seconds. And if a message does arrive, you don’t need to wait the full 20 seconds; it will tell you instantly. So it’s just a good way to save money. And typically, an example question in the exam might be about polling and typing loops. Is burning CPU cycles costing a company money? How would you fix this? and the answer is to enable long polling. Okay, the last thing I want to talk about is fanning out SQS.
So far, we haven’t covered SNS, but you can create an SMS topic and then subscribe multiple SQS queues to this SNS topic, so that whenever a message issents to the SNS topic, the message is fanned out to the other SQS queues. So SNS will deliver the message to all SQS queues that are subscribed to the topic. So it’s this way: you can have one message come into a queue, and then you can pass that on to multiple queues. You might have 15 or 20 different queues; NHQ might do something different, but that’s basically how to distribute your message. You’ve got to couple it with SNS, which we’ll cover in the next section. So that’s it for SQS. If you have any questions, please let me know. If you do go through your exam and you find something in the exam that we haven’t covered on SQL, maybe a specific API call, please just make a note of it and let me know, and I’ll make sure it’s in an updated lecture for the rest of the students. But that’s it. If you have any questions, please let me know. If not, please move on to the next section. Thank you.
