See X-ray application tracing in action. Learn how new monitoring tools play a role in serverless applications.
- [Instructor] New types of architecture and new services also require new types of monitoring, and Amazon has come out with a tool that I wanna showcase here, around monitoring for scalability called X-ray. So what I have done is I have set up the sample application, and it sets up a node JS application to website using Elastic Beanstalk and some other services. I do wanna call out that in particular X-ray is designed to work with Amazon lambda, and I've actually had some really great results working with a set of customers on looking at a server less application, finding the bottle necks and making it more available and more scalable using X-ray tracing.
So what does this look like? So to launch this and if you wanted to do this on your own, you'd click launch the sample application. And that launches a Cloud Formation template with a number of resources. So I'm gonna just close this and go to Cloud Formation. So once you would click through that previous set of prompts, this would load the template into Cloud Formation, and it takes about a half an hour to set up, so I set this up in advance. And you can see that it gives you once it's done, an Elastic Beanstalk URL and that's your website basically.
And then you can take a look down here and see what was created. Another tip is when you are working with different scalability scenarios, if you can use these Cloud Formation templates of course when you're done you can just remove all the resources by going into stacks, and I have a number of things going on here, and then I could delete the stack and that would remove all the resources cleanly. So it's just a tip when you're learning as well. So in any case we see all the objects that were created here, and then we go to the outputs and we can look at the actual website, and that's over here.
And the way this website works is it just automatically sends in a login request, once you click start. And I've had this on for awhile so I've got 3,000 requests. Then you can also do manual requests here. So I did some before, so I'll just do a few more, make 'em a little bit different. So you can see it's pretty simple, it's just for scalability. And of course you could automate this too if you wanted to really try out high levels of scalability. So once you have this set up then this creates this Elastic Beanstalk application.
So here's the Beanstalk application. And I'm just gonna close that 'cause we don't really need to look at that. Creates an SNS topic, so there's our topic. That's this one right here. And then it creates a DynamoDB table, so here it is. And we have a number of items from the simulated activity. So we have basically an application that is using both servers and server less. So real world, so our application consists of Elastic Beanstalk, SNS and Dynamo.
So what does that look like in X-ray? X-ray has a couple of capabilities. And here we are inside of X-ray, it has a service map which I think is pretty intuitive, pretty well designed. You can see that if I click on this, I have an EC2 instance that is hosting Beanstalk. Oh and I didn't go to the EC2 console, but I could have easily gone there. I have a DynamoDB table and I have SNS. And then I have traces. So you can think of this as a sophisticated log reader, and an aggregate log reader that can help you to understand where you have application bottle necks.
And can also be used to verify scalability. So for example, if I click on my DynamoDB table and it's a little bit crunched because of the resolution of the screen here, you can see that I have both yellow and green. I have an average 30 milliseconds and an eight T per minute there. And if I scroll down, you can see that I have an 87% okay over this time period, and I have an error rate of 13%. If I just wanna see the error traffic, then I can look at the error traffic over time.
And if I had faults or throttling, important for scalability of course that would show up as well. Now inside of here, I can set the time to a little bit longer time period here. So it's a little bit more interesting. And then what I can do is if I wanna look at this peak, I can look at that peak. And then I can view the associated logs or traces for that peak. Now inside of here you can see that I'm looking by URL, and here's my query, and here's the time period. And I have my average response time.
So this can be great in terms of scalability. Here's potentially a KPI, how quickly is the sign up page delivered, and what percentage of the traces are coming back okay, right? So then if I go into this and then go to the trace list, I can look at the various response times if I look at this particular trace. I can go all the way down to the level of the services and you can see that I have my front end dev, and here's my response time, DynamoDB, and SNS.
Now once I go into here I can see a great amount of data in terms of the time it takes for the process to occur, whether there's faults, resources, so which instances, which availability zone. Interestingly it can also use annotations. And this is just a key value pair, this was a technique we actually used with a customer that I had to get into, it was a custom machine learning process, so we wanted to basically see into the process to see where the bottle neck was.
And we found it in the code and we actually rewrote it using annotations, so it was a neat use of this service. And then you can have metadata and then exceptions. So for each of the services you can drill in here, you can see very granularly what is the amount of time that's being taken by the process. Now in the case of DynamoDB scalability, as I mentioned in a previous movie, you can turn on auto scaling on DynamoDB, but that can be not a good fit for your business scenario because if you had some sort of problem, some sort of fault condition that caused scaling to go to a really large aspect, that might not be desirable.
So you might wanna have manual scaling that you then set based on metrics. And tools such as X-ray that help you to really see very granularly into the processes, in this case around Dynamo, can help you to set the appropriate scaling metrics. And then just to be complete, I'll just look at SNS here. And again, you can see how SNS is performing. I started by showing this tool because in server less architectures in particular, this is a critical tool in terms of understanding how the different server less services interact.
Another aspect of this which I'm not showing here 'cause I don't have lambda, I have EC2, is a known issue with lambda which is warm up time on cold starts. And it's very, very easy to see inside of the service map and then going down to the level of the traces. If you need to do some custom optimizations around lambda or maybe rewrite your code or change how you implement your lambda, so that you can try to mitigate that known issue of lambda cold start time.
So lots of fantastic information. This is a relatively new service so it may have even more features by the time you watch this. And I would recommend that if there are new capabilities that you consult the documentation because I know Amazon is excited about this service, and I've seen some features roll out even in around a year that the service has been out in GA. So to just round this out, if you wanted to try this out yourself you could just bring up the sample with the Cloud Formation template, and then when you're done working with it you would just wanna click on this, and then you would wanna delete the stack and that would remove all the resources.
- Scalability in AWS application design
- Scaling serverless vs. server-based applications
- Scaling files
- Storage design approaches
- Design approaches to scaling data and data storage
- Scaling SQL queries
- Understanding Data Migration Service
- Scaling applications