By Antony Prasad Thevaraj, Solutions Architect

Getting the maximum scale from your database often requires fine-tuning the application which incurs time and cost. It’s productivity that could have been used towards other strategic initiatives. The Heimdall Proxy was designed to intelligently manage SQL connections helping you get the most out of your database without application changes.

In this blog post, we demonstrate two SQL offload features offered by the Heimdall Proxy: 1) Automated Query Caching and 2) Read/Write Split for improved database scale. By leveraging the Heimdall Proxy, users will save on development costs and accelerate the onboarding of applications into production.

Figure 1. Heimdall Proxy Distributed, Auto-Scaling Architecture

Why Query Caching?

For e-commerce websites with high read calls and infrequent data changes, query caching can drastically improve Amazon RDS scale by serving results from Amazon ElastiCache. Retrieving data from cache has a shorter access time, which reduces latency and improves input/output (I/O) operations.

The Heimdall Proxy provides automated results caching to the grid-cache of your choice without code changes. What makes this solution also unique is the distributed, scalable architecture. As your traffic grows, auto-scaling is supported by simply adding proxies. Multiple proxies work together as a cohesive unit for caching and invalidations. It can take developers months to create a cache subsystem with continual maintenance of adjusting the cache TTL and expiry time.

Why Read/Write Splitting?

While it is simple to configure a primary and read replica instance on the AWS Management Console, the developer is challenged to implement such a scale-out architecture with these issues:

• Replication Lag: A query, read-after-write may result in data inconsistency due to replication lag. Many applications require strong consistency.
• DNS dependencies: Due to the DNS cache, many connections can be routed to a single replica creating uneven load distribution across replicas.
• Network latency: If you deploy Amazon RDS globally (e.g. Aurora Global Database), how does the application intelligently choose the optimal reader?

The Heimdall Proxy makes it easy to elastically scale out read-heavy database workloads. The Heimdall Proxy’s Read/Write splitting supports:

• ACID Compliance: Determines the replication lag and know when it is safe to access a database table, ensuring data consistency
• Database load balancing: Tracks the status of each DB instance for its health and evenly distribute connections without relying on DNS
• Intelligent Routing: Chooses the optimal reader to access based on the lowest latency to create local-like response times. Check out our Aurora Global Database

Check out our This is My Architecture Blog: https://youtu.be/mT4KDGRgo4k

Customer Success Story by Hayden Cacace, Director of Engineering at Tornado

Tornado is a modern web and mobile brokerage that empowers anyone who aspires to become a better investor.

Within a three-month timeline, our engineering team was tasked to improve the performance and stability of the backend such that it could handle the massive surge in traffic. At that time, our backend system relied on a single Amazon RDS instance, which handled a large number of read and write operations. We knew we had to start using read replicas to reduce the load on the main database instance.

First, we migrated from regular Postgres on RDS to Aurora for Postgres since it provided better data replication speed. But we still faced a problem – the amount of time it would take to update server code to use the read replicas was too much for our team that was already stretched thin. And the launch deadline was fast approaching.

Enter the Heimdall Proxy: We evaluated a handful of options for a database proxy that could automatically do Read/Write split for us with no code changes, and it became clear that Heimdall was our best option. Not only did it have the Read/Write splitting “out of the box” with zero applications required, it also came with a database query caching built-in (integrated with Amazon Elasticache) which promised to take additional load of the database.

Before the Tornado launch date, our load testing showed the new system handling several times more load than we were able to previously with a primary Aurora Postgres instance and 2 read replicas behind the Heimdall proxy. When Tornado launch date arrived, the system performed well and was a big success. As an added bonus, we are even seeing some background jobs averaging around 50% hit rate on the Heimdall cache which has really helped reduce the database load and improve the run time of those jobs.

Thanks to Heimdall Data, we now have a data architecture with some additional room to scale going forward. This buys us the time we need to make larger architectural improvements necessary for the future while continuing to provide a good experience to our customers using the live product today.

Download a free trial from the AWS Marketplace.

Resources

• AWS Blog: Read/Write Split with ACID Compliance
• AWS Blog: Automated Query Caching
• AWS Blog: Advanced Connection Pooling
• Heimdall Data technical documentation
• Contact: info@heimdalldata.com