Multi-region serverless backend — reloaded

Accelerating Serverless Applications with Global Accelerator and Application Load Balancer

Adrian Hornsby
Feb 1, 2019 · 16 min read
Image for post
Image for post

Brace yourself: DNS isn’t perfect

DNS is one of the most important services on the Internet as it turns a user-friendly domain name like amazon.com into an IP address that computers use to identify each other and direct traffic to a network.

Image for post
Image for post
Using Dig command to translate DNS to IPs

Caching to the rescue

Luckily, the designers of the DNS service thought about that and specified the use of a time-to-live (TTL) for every DNS record. Caching name servers use that TTL configuration to determine how long the result of a particular DNS query should be stored. DNS caching improves the efficiency of the DNS service as it reduces the DNS traffic across the Internet, but also serves as a resiliency technique because it prevents overloads of the authoritative name-servers, particularly the root name-servers which sit at the top of the hierarchy.

Image for post
Image for post
Setting up the TTL in the AWS Console — Route53
Image for post
Image for post
Extracting the TTL from the Domain Name with Dig command
Image for post
Image for post
DNS cache in Firefox (default 60 seconds)
Image for post
Image for post
Cache be like…

Introducing Global Accelerator

Global Accelerator (GA) is a networking service that improves the availability and performance of global applications without relying on DNS services and caching name servers. Instead, GA uses static IP addresses as a single, fixed entry point for users connecting to applications.

So, how does it work?

To enable fault tolerance, GA provides you with multiple static IP addresses that are serviced by independent network zones. Similar to Availability Zones, these network zones are isolated units with their own set of physical infrastructures and service IP addresses from a unique IP subnet. If one IP address from a network zone becomes unavailable, client applications can retry on the healthy static IP address from the other isolated network zone.

Back to our multi-region serverless architecture

Another important release from reInvent 2018 is the Application Load Balancers (ALB) support for Lambda functions.

Solution Overview

The solution presented here leverages the same database as the 2018 series DynamoDB Global Table which provides a fully-managed, multi-region, multi-master database. Since I wrote extensively about Global Tables here and here, I won’t go into detail in this post.

Image for post
Image for post
Multi-Region Serverless Backend Solution Overview

Let’s get started!

#1 Creating a Global Table

When you create a DynamoDB table, in addition to the table name, you must specify the primary key of the table. The primary key uniquely identifies each item in the table so that no two items have the same key. In a global table, every replica table shares the same table name and the same primary key. Because a global table is a multi-master database, applications can write data to any of the replica tables. DynamoDB automatically propagates these writes to the other replica tables in the AWS Regions you choose.

Image for post
Image for post
  1. Choose Enable streams.
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

#2: Creating the Lambda function

For demo purposes, I’ll create a simple function that gets an item from the DynamoDB global table created previously, and returns a health check. For the sake of simplicity and clarity, I’ll include both functions in one file called get.py.

Building the ZIP package for the Lambda function

Regardless if you’re using Linux, Mac or Windows, a simple way to create your ZIP package for Lambda is to use Docker because AWS Lambda needs Linux-compatible versions of libraries to execute properly.

simplejson==3.16.0
Image for post
Image for post
$ docker run -v $PWD:/var/task -it lambci/lambda:build-python3.6 /bin/bash -c "pip install -r requirements.txt -t vendor"
Image for post
Image for post
$ zip -r function.zip .

Uploading the Lambda function

Log into the AWS Lambda Console and create a Python 3.7 compatible function from scratch and upload the ZIP package. Make sure the handler is get.get_item

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

3#: Adding the Application Load Balancer

Log into the EC2 AWS console and create a new load balancer. Select the Application Load Balancer type. Click Create.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

3#: Creating the Global Accelerator

Log into the GA console and create a new accelerator.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

4#: Testing the Global Accelerator

Let’s quickly test the newly-deployed accelerator. Notice that we get the same result from both static IP addresses: 13.248.149.110 and 76.223.19.244 .

Image for post
Image for post
Image for post
Image for post

5#: Let’s try that Global Accelerator!

First, let’s do a simple API call to see if the GA does indeed connect me to the closest endpoint. To simulate my geographic location, I’ll use a VPN connection setup to connect to a server in Europe (Frankfurt).

Image for post
Image for post
Image for post
Image for post

6# Now let’s break things and test the failover!

Before doing any chaos, lets modify some of the settings to optimize a speedy failover.

Image for post
Image for post

Understanding the failover timing

According to the FAQs, GA can detect an unhealthy endpoint and take it out of service in less than one minute.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

6# Final points: Global Accelerator versus Route 53

One question remains: When should you use Global Accelerator, and when should you use Route 53 with latency-based routing for a multi-region backend setup?

Image for post
Image for post
AWS Global Network
Image for post
Image for post

Wrapping up.

That’s all for now, folks. Thanks for reading this lengthy blog post — hopefully it’s inspired you to start experimenting with the new GA and the ALB to Lambda integration. Let me know what you think: share your opinions, or simply clap your hands :)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store