Background:
Movietimes.com is a global online ticketing website. We have over 1.5 million users, deployed in AWS. We deployed three EC2 application instances connected to Aurora for MySQL. As our user traffic grew, our application response times slowed down. This was caused by the inefficient interaction between the application and database. Slow, duplicated queries were hitting the backend Aurora.
Our initial 3 proposals turned out to be less optimal:
- Scale up to a larger Aurora instance: Although very quick to upgrade, adding more CPU cores would only improve database-processing capacity, and not the per-query response time. To solve the overall application performance problem, we needed a solution that reduced network round trip times.
- Rewrite the application code: We inherited a monolithic code base and time-to-market was an issue. Rewriting the application was out of the scope of feasibility.
- Implement SQL caching: As we developing a caching platform, we soon discovered implementation involved time and most importantly, risk. Which queries should we cache, and not cache? How do we dynamically keep the data fresh and ensure accuracy? We decided to look for off-the-shelf solutions.
Solution:
We discovered the Heimdall Proxy: Client-side SQL auto-caching without code changes. Heimdall was compatible with Amazon Aurora and intelligently auto-cached into the storage of your choice (e.g. Amazon Elasticache, Redis, Hazelcast, Gemfire). Heimdall had an AWS configuration wizard that allowed us to transparently connect our existing Amazon Aurora, Amazon Elatiscache, and Amazon Cloudwatch deployment with zero changes to our AWS existing infrastructure.
Customer Benefit:
Aurora gave us enhanced MySQL scalability and performance. And, being full managed saved us the operational costs of database backup and software patching. Similarly, the Heimdall Data SQL optimization layer was also transparent which solved our application-database performance issues. We deployed a client-side caching solution in 1 day without any coding (i.e. what to cache, when to expire); it would have taken our team up to 1 year to develop such a solution. In production, we saw SEO rankings improve and user session times boost by 10x.
Takeaways:
There is a developer culture that is DIY (Do IT Yourself) which operational costs are typically ignored. We achieved application-database scaling with very little effort and no code changes. Migrating from MySQL to Aurora was seamless. And deploying a cache system with Heimdall Data was transparent. We let others do the backend scaling for us. The operational and capital cost of the Heimdall Data and Aurora proved to be a success for Movietimes.com. Highly recommended.
Resources and links:
