Serverless application architectures are still an emerging art form. One of the big challenges serverless architectures pose is traceability and debugging. Because we are dealing with many discrete entities performing as a single cohesive unit, we want to be able to see the impact of those entities on the system as a whole.
Amazon Web Services (AWS) is leading the field in serverless architecture, and their answer to the challenge of traceability is Amazon X-Ray, a service designed to track the performance data of distributed serverless systems. X-Ray was rolled out as a preview at last year’s AWS Re:Invent, and this past week at the AWS Global Summit San Francisco, it was announced for general availability, and a new preview feature was unveiled: Lambda Integration. I want to show you how easy it is to add X-Ray functionality to your serverless applications with the new Lambda Integration feature.
The first step is to have an application that you want to instrument. For simplicity’s sake, I used the basic CRUD API example application from AWS Labs’ Serverless Application Model github repository. If you want to follow along, simply clone the repository, and follow the included HOWTO.md instructions to launch the serverless application stack of your choice. When stack creation has completed, your resources will be available through the console as normal.
Now that you have a running serverless application, have a look at one of its constituent Lambdas. Of interest to us is the “configuration” tab of each Lambda. Note the execution role assigned to the function, and then expand the “Advanced settings” rollout at the bottom.
Under “Advanced Settings” find the checkbox for “Enable active tracing” and check it. Save this Lambda, and repeat this step for any other Lambdas you want to include in your X-ray trace.
The other thing to do is to ensure that the execution roles for each Lambda have permission to write to the X-Ray service. Navigate on the IAM console to the roles you noted earlier when enabling tracing on the Lambdas. Click “Attach Policy” from the permissions tab, and add the “AWSXrayWriteOnlyAccess” policy. [Note: when you go to tear down the stack, the roles to which you have attached policies manually will fail automatic deletion, so be sure to remove them manually if you desire]
At this point your application is instrumented! If you have other containerized or ec2 elements to your call graph, you can use the “getting started” instructions from the X-Ray page to add tracing, depending on your language and configuration.
To test the tracing, I made several API calls using the Insomnia REST client. If you’re familiar with Postman, Insomnia’s operation is very similar. If you’re not using either of these for debugging your REST applications, you should start.
Because our application model is very simple, the service map is also very simple. What it shows us is that the Lambda container itself is triggered by the API call which in turn calls the Lambda’s function. The Lambda Integration gives us a separate timer for the outer container and the inner function to show performance overhead. The overhead is more clearly illustrated by looking at an individual trace (click “Traces” and then one of the trace identifiers):
Obviously for cascading calls across multiple Lambda objects, this will be a more interesting graph with important data about where your performance bottlenecks are and where the time in your API calls is being spent.
As you can see, Lambda Integration greatly simplifies the process of adding traceability to AWS serverless applications. I hope you find this tutorial useful, and gain insight into your traced applications by using this powerful new AWS tool.