Which solution will meet these requirements?
Migrate the database to Amazon Aurora MySQL. Replace the read replicas with Aurora Replicas, and configure Aurora Auto Scaling. Replace the stored procedures with Aurora MySQL native functions.
Deploy an Amazon ElastiCache for Redis cluster in front of the database. Modify the application to check the cache before the application queries the database. Replace the stored procedures with AWS Lambda functions.
Migrate the database to a MySQL database that runs on Amazon EC2 instances. Choose large, compute optimized EC2 instances for all replica nodes. Maintain the stored procedures on the EC2 instances.
Migrate the database to Amazon DynamoDB. Provision a large number of read capacity units (RCUs) to support the required throughput, and configure on-demand capacity scaling. Replace the stored procedures with DynamoDB streams.
Explanations:
Migrating to Amazon Aurora MySQL and using Aurora Replicas can significantly reduce replication lag due to its optimized architecture for replication and better performance under load. Aurora also supports auto-scaling, which helps manage peak loads without changing application code. Native functions can be leveraged for stored procedures, maintaining performance while reducing lag.
Deploying ElastiCache for Redis can improve read performance by caching frequently accessed data, but it does not directly address the replication lag issue. Additionally, modifying the application code to check the cache before querying the database increases operational overhead. Replacing stored procedures with Lambda functions also adds complexity and doesn’t align with the goal of minimizing changes to the application.
Migrating to a MySQL database on EC2 instances may allow for choosing larger, more powerful instances to reduce lag, but this approach involves significant operational overhead in terms of management and scaling. Additionally, it doesn’t provide the same level of optimized replication as Aurora, potentially leading to continued lag issues. Maintaining stored procedures on EC2 does not address the need for minimizing changes.
Migrating to Amazon DynamoDB would require a complete redesign of the data model and application logic, as DynamoDB is a NoSQL database and does not support stored procedures. Although it can handle high throughput with on-demand capacity scaling, it does not address the specific issue of replication lag experienced in the current architecture and introduces significant changes to the application.
I draft that the answer is:
Migrate the database to Amazon Aurora MySQL. Replace the read replicas with Aurora Replicas, and configure Aurora Auto Scaling. Replace the stored procedures with Aurora MySQL native functions.