Another Reason to Enable Private IP Addresses on Google Cloud SQL
Google Cloud SQL recently introduced the capability for an instance to have an IP address within the private address space of your VPC network. Previously, all Cloud SQL instances had IP addresses within the address space of the public Internet. Obviously, the public IP was a security and privacy concern, as well as a potential violation of some compliance and governance frameworks. Now, each instance may have a public IP, private IP, or both. There’s another potential benefit to using a private IP address: performance!
Transition to Private IP Address for Cloud SQL
Baseline Configuration
The baseline configuration was three CPU-heavy web servers in a managed instance group, backed by a single Cloud SQL instance with a failover replica. The web servers have IP addresses within the private IP address space of our VPC network, so they can only communicate with external resources via a NAT/gateway server. Each web server was running Cloud SQL Proxy, configured with the public IP address of the Cloud SQL instance.
Enable Private IP Address on Cloud SQL
A private IP address was enabled on the Cloud SQL instance during after-hours maintenance, because the change will cause the SQL instance to reboot immediately. The cloud SQL proxy service on each web server was reconfigured to use the private IP instead of the public IP. As the graphs above demonstrate, both CPU and network load on the NAT server dropped dramatically as soon as the last production web servers were transitioned to the private IP. All SQL queries from the web servers had been proxied through the NAT server when they used the public IP of the Cloud SQL instance. As soon as the web servers started using the private IP, all of this traffic was able to bypass the NAT server.
Conclusions
We were able to reduce the size of the NAT gateway server, resulting in a slight reduction in monthly cloud cost. Surprisingly, New Relic logs do not show any significant improvement in the performance of the web application. This indicates that the n1-standard-2 NAT instance was actually very efficient at handling the SQL traffic, and the bottleneck in SQL query performance is elsewhere.