Amazon Aurora Reader

Question

I have an Aurora cluster with a reader and writer instances. And the reader instance has high hits and hits 100% every now and then. I was wondering about possible options to reduce the load on the same. The current instance type is db.r4.4xlarge.

I also read about adding multiple reader instances which uses the same endpoint and AWS load balances the traffic between them automatically. I would love to know if all I have to do is add another reader instance and all the load balancing happens automatically? And does creating a new reader affect the performance of the cluster while the new one is being created?

What about using a Redis ElastiCache instance? How can I use this with RDS to reduce load o the same instance?

Which of the above 2 would be the best way to go forward??? Please suggest

Answer 1

Adding more reader instances to Aurora cluster or scaling up reader instance are way to avoid high CPU. While using readeronly endpoint, you have to keep few things in mind

Load Balancing with the Aurora Reader Endpoint

The Aurora reader endpoint contains all Aurora Replicas, it can provide DNS-based, round-robin load balancing for new connections. Every time you resolve the reader endpoint, you'll get an instance IP that you can connect to, chosen in round-robin fashion.

DNS load balancing works at the connection level (not the individual query level). You must keep resolving the endpoint without caching DNS to get a different instance IP on each resolution. If you only resolve the endpoint once and then keep the connection in your pool, every query on that connection goes to the same instance. If you cache DNS, you receive the same instance IP each time you resolve the endpoint.

DNS Caching

Aurora Replicas can experience unequal utilization because of DNS caching.

Unless you use a smart database driver, you depend on DNS record updates and DNS propagation for failovers, instance scaling, and load balancing across Aurora Replicas. Currently, Aurora DNS zones use a short Time-To-Live (TTL) of 5 seconds. Ensure that your network and client configurations don't further increase the DNS cache TTL. Remember that DNS caching can occur anywhere from your network layer, through the operating system, to the application container. For example, Java virtual machines (JVMs) are notorious for caching DNS indefinitely unless configured otherwise.

Another good read on the same topic.