Skpr provides applications with a robust MySQL implementation built on the highly regarded Amazon Relational Database Service.
This blog post covers the considerations that went into the design and development of the service.
Architecture Overview
The Skpr MySQL service consists of the following components:
- Database Credentials - Automatically provisioned database credentials that are unique to each environment.
- Amazon RDS Proxy - Boosts MySQL performance and availability by pooling connections.
- Amazon Aurora - A MySQL compatible relational database built for the cloud.
- Amazon CloudWatch - A monitoring and observability service built for DevOps engineers, developers, site reliability engineers (SREs), and IT managers.
This blog post will cover each of these components.
Database Credentials
The Skpr hosting platform automatically provisions a MySQL database and set of unique credentials for each environment. The lifecycle of the database and credentials are managed using a set of custom Kubernetes controllers developed by the Skpr platform team.
The provisioned database and credentials are then exposed to the application using the Skpr Configuration System.
Certificates are also provided to the application to allow for secure connections to the MySQL service.
For more information see our documentation.
Amazon RDS Proxy
Database connections are routed by Amazon RDS Proxy, a fully managed, highly available database proxy for Amazon Relational Database Service (RDS). Amazon RDS Proxy makes applications more scalable, more resilient to database failures, and more secure.
Applications such as Drupal (PHP) do not provide native mechanisms for pooling database connections. Meaning a new connection is made for every web request and, in the event of a high traffic scenario, consumes valuable compute resources that could be used for more important application-focused tasks.
We have seen significant performance and scalability characteristics when deploying RDS Proxy in front of our MySQL clusters.
The Skpr platform team intends to publish a dedicated blog post to showcase the performance and scalability improvements when deploying RDS Proxy.
Before RDS Proxy
After RDS Proxy
Amazon Aurora
The Skpr platform is backed by Amazon Aurora, a MySQL-compatible relational database solution built to run natively on the AWS cloud.
Skpr MySQL clusters consist of at least 2 MySQL instances: 1 writer and 1+ readers.
- Writer - The primary MySQL cluster instance that the application will connect to perform a database operation.
- Reader - One or more MySQL cluster instances can respond to "read-only" database requests, e.g. Select Statement. In a failure, a reader will be promoted to the writer.
Both of the above instance types can be connected to through a consistent, load-balanced endpoint. Both of these endpoints are available to developers through the Skpr Configuration System.
We found this architecture advantageous since we can utilize the reader instances for "out of band" cluster operations such as backups, metrics gathering etc., without impacting the main writer instance.
Amazon CloudWatch
The Skpr hosting platform provides a detailed dashboard outlining key metrics used when debugging performance issues.
Key information surfaced by the dashboard includes:
- Resource utilisation (CPU / Memory)
- Query type breakdown (Select / Insert / Update / Delete)
- Query latency by type
- Slow queries
Supports Custom Configurations
The Skpr hosting platform comes by default with preconfigured prod and non-production MySQL services operating in multi-tenant mode.
We can also spin up dedicated MySQL services with a custom configuration for projects with specific requirements.
Roadmap
Monitoring
The Skpr platform team is always looking for ways to improve our monitoring and insights into the service and continue improving on the CloudWatch Dashboard.
Serverless v2
The Skpr platform team watches the preview of Aurora Serverless v2 very closely.
We were very fond of Serverless v1 and its vertical autoscaling features. However, it doesn't offer multi-az support, which means it is not viable for production workloads. Serverless v2 promises to solve this shortcoming.
For More Information
Contact us today if you have any questions, We'd love to hear from you.