Are GCP CloudSQL instances billed by usage? - mysql

I'm starting a project where a CloudSQL instance would be a great fit however I've noticed they are twice the price for the same specification VM on GCP.
I've been told by several devops guys I work with that they are billed by usage only. Which would be perfect for me. However on their pricing page it states "Instance pricing for MySQL is charged for every second that the instance is running".
https://cloud.google.com/sql/pricing#2nd-gen-pricing
I also see several people around the web saying they are usage only.
Cloud SQL or VM Instance to host MySQL Database
Am I interpreting Googles pricing pages incorrectly?
Am I going to be billed for the instance being on or for its usage?

Billed by usage
All depend what you mean by USAGE. When you run a Cloud SQL instance, it's like a server (compute engine). Until you stop it, you will pay for it. It's not a pay-per-request pricing, as you can have with BigQuery.
With Cloud SQL, you will also pay the storage that you use. And the storage can grow automatically according with the usage. Be careful the storage can't be reduce!! even if you delete data in database!
Price is twice a similar Compute engine
True! A compute engine standard1-n1 is about $20 per month and a same config on Cloud SQL is about $45.
BUT, what about the price of the management of your own SQL instance?
You have to update/patch the OS
You have to update/patch the DB engine (MySQL or Postgres)
You have to manage the security/network access
You have to perform snapshots, ensure that the restoration works
You have to ensure the High Availability (people on call in case of server issue)
You have to tune the Database parameters
You have to watch to your storage and to increase it in case of needs
You have to set up manually your replicas
Is it worth twice the price? For me, yes. All depends of your skills and your opinion.

There are a lot of hidden configuration options that when modified can quickly halve your costs per option.
Practically speaking, GCP's SQL product only works by running 24/7, there is no time-based 'by usage' option, short of you manually stopping and restarting the compute engine.
There are a lot of tricks you can follow to lower costs, you can read many of them here: https://medium.com/#the-bumbling-developer/can-you-use-google-cloud-platform-gcp-cheaply-and-safely-86284e04b332

Related

How to lower costs of having MySQL db in Google Cloud

I set up Google Cloud MySQL, I store there just one user (email, password, address) and I'm querying it quite often due to testing purposes of my website. I set up minimal zone availability, the lowest SSD storage, memory 3.75GB, 1vCPUs, automatic backups disabled but running that database from the last 6 days costing me £15... How can I decrease the costs of having MySQL database in the cloud? I'm pretty sure paying that amount is way too much. Where is my mistake?
I suggest using the Google Pricing Calculator to check the different configurations and pricing you could have for a MySQL database in Cloud SQL.
Choosing Instance type
As you've said in your question, you're currently using the lowest standard instance, which is based on CPU and memory pricing.
As you're currently using your database for testing purposes, I could suggest to configure your database with the lowest Shared-Core Machine Type which is db-f1-micro, as shown here. But note that
The db-f1-micro and db-g1-small machine types are not included in the Cloud SQL SLA. These machine types are designed to provide low-cost test and development instances only. Do not use them for production instances.
Choosing Storage type
As you have selected the lowest allowed disk space, you could lower cost changing the storage type to HDD instead of a SSD if you haven't done so, as stated in the documentation:
Choosing SSD, the default value, provides your instance with SSD storage. SSDs provide lower latency and higher data throughput. If you do not need high-performance access to your data, for example for long-term storage or rarely accessed data, you can reduce your costs by choosing HDD.
Note that Storage type could only be selected when you're creating the instance and could not be changed later, as stated in the message when creating your instance.
Choice is permanent. Storage type affects performance.
Stop instance when is not in use
Finally, you could lower costs by stopping the database instance when it is not in use as pointed in the documentation.
Stopping an instance suspends instance charges. The instance data is unaffected, and charges for storage and IP addresses continue to apply.
Using Google Pricing Calculator
The following information is presented as a calculation exercise based in the Google Pricing Calculator
The estimated fees provided by Google Cloud Pricing Calculator are for discussion purposes only and are not binding on either you or Google. Your actual fees may be higher or lower than the estimate. A more detailed and specific list of fees will be provided at time of sign up
Following the suggestions above, you could get a monthly estimate of 6.41 GBP. Based on a 24 hour per 7 days running instance.
And using a SSD, it increases to 7.01 GBP. As said before, the only way to change the storage type would be to create a new instance and load your data.
And this could lower to 2.04 GBP if you only run it for 8 hours 5 days a week running on HDD.

Isn't Google App Engine suppose to be more expensive than Google Kubernetes engine

I had my app in the app engine(Flex). But it's costing a lot with no traffic yet!
I decided to move that to Kubernetes Engine which utilizes the compute engine.
Another reason I moved to Kubernetes because I wanted to run docker container services like Memcached that come with an added cost in App Engine Flex.
If you are tempted to ask why am not using App Engine Standard which is economical, that's because I couldn't find any easy way if at all there's any for running services like GDAL & Memcached.
I thought Kubernetes should be a cheaper option, but what I am seeing is the opposite.
I have even had to change the machine type to g1-small from N1...
Am I missing something?
Any ideas on how to reduce cost in Kubernetes / compute engine instances?
Please have a look at the documentation GKE Pricing and App Engine Pricing:
GKE clusters accrue a management fee of $0.10 per cluster per hour,
irrespective of cluster size or topology. One zonal (single-zone or
multi-zonal) cluster per billing account is free.
GKE uses Compute Engine instances for worker nodes in the cluster. You
are billed for each of those instances according to Compute Engine's
pricing, until the nodes are deleted. Compute Engine resources are
billed on a per-second basis with a one-minute minimum usage cost.
and
Apps running in the flexible environment are deployed to virtual
machine types that you specify. These virtual machine resources are
billed on a per-second basis with a 1 minute minimum usage cost.
Billing for the memory resource includes the memory your app uses plus
the memory that the runtime itself needs to run your app. This means
your memory usage and costs can be higher than the maximum memory you
request for your app.
So, both GAE Flex and GKE cluster are "billed on a per-second basis with a 1 minute minimum usage cost".
To estimate usage cost in advance you can use Google Cloud Pricing Calculator, also you can use it to estimate how changing parameters of your cluster can help you to reduce cost and which solution is more cost effective.
In addition, please have a look at the documentation Best practices for running cost-optimized Kubernetes applications on GKE.

trying to understand gcp cloud costs and determine free or low cost relational database hosting?

I was originally planning to use Azure SQL for a client's database but Azure said that the estimated cost was going to be something around $250/month for the most basic configuration. I remember when using Azure for my own experimentation in the past, that Azure costs were higher than expected so I decided to look at GCP as an alternative.
GCP offered me a free trial credit of $300 so I accepted that by default. I created a new SQL Server instance via my GCP account, created the most basic database configuration, then connected via SSMS and created a single database table with a single Id column. That's it. Now, 2 days later with no additional usage of this database table, my GCP free trial credit has been burned down by $15. Based on this trend, a SS instance on GCP seems to cost about as much as an Azure SQL instance. Am I inferring this correctly?
Can you recommend a good quality option which provides free relational database hosting for low volume, low transaction databases? SQL Server would be great but MySQL should work too. I'm assuming that MySQL is fairly equivalent for simple databases?
I don't know about costs related to other cloud providers, but gcp's are usually really competitive on the market. With cloud SQL you pay per instance/h and you pay more/less based on different factors. Use the google cloud price calculator to have a general idea of the costs, and adjust cloud sql accordingly: https://cloud.google.com/products/calculator
Additionally, here you may find all the information regarding Pricing details of Cloud SQL.

Concurrent migrations of Google Compute Engine instances

Google Compute Engine guide says that Google may migrate a VM in order to do maintenance:
https://cloud.google.com/compute/docs/instances/setting-instance-scheduling-options
By default, standard instances are set to live migrate, where Google
Compute Engine automatically migrates your instance away from an
infrastructure maintenance event, and your instance remains running
during the migration. Your instance might experience a short period of
decreased performance, although generally most instances should not
notice any difference.
There is a disruption during migration.
Is it possible that Google decides to migrate all instances within a zone at the same time? Is there a maximum to a number of concurrent migrations?
Q: There is a disruption during migration?
A: Yes there is a small period of time where the instance is not running on the old host neither the new one. Here [1] you can see how the process works.
Q: Is it possible that Google decides to migrate all instances within a zone at the same time?
A: It is very unlikely that this escenario happens, as this would implicate that all your Google Compute Engine instances of your project are on the same physical host.
Q: Is there a maximum to a number of concurrent migrations?
A: I don't know the answer to that question but I have addressed to the proper team so maybe they can answer it.
You can find more about the live migration procedure here [2].
[1] https://cloud.google.com/compute/docs/instances/live-migration#how_does_the_live_migration_process_work
[2] https://cloud.google.com/compute/docs/instances/live-migration

How does Google Cloud SQL Performance Tiers compare with Amazon AWS RDS for MySQL?

There are only 7 performance tiers in GCS (D0, D1, D2, D4, D8, D16, D32), RAM maxes out at 16GB (D32) as they are based on Google Compute Engine(GCE) machine types. See screenshot below (1)
By comparison, Amazon has 13 performance tiers with db.r3.8xlarge's RAM maxes out at 244GB. (2)
So my question is, what is the rough equivalent performance tier in AWS RDS for MySQL for a Google Cloud SQL's D32 tier?
Disclaimer: I am new to Google Cloud SQL. I only start to use Cloud SQL because I started a new job that's 100% Google Cloud. Previously I have been a AWS user since the early days.
The D0-D32 Cloud SQL tiers are not based on GCE VMs so a direct comparison is not straightforward. Note that the storage for D0-D32 is replicated geographically and that makes writes a lot slower. The ASYNC mode improves the performance for small commits. The upside is that the instances can be relocated quickly between location that are farther apart.
The connectivity for Cloud SQL is also different from RDS. RDS can be access using IPs and the latency is comparable with VMs talking over local IPs. Cloud SQL uses only external IPs. That makes the latency from GCE higher (~1.25ms) but it provides a slightly better for experience for connections coming from outside the Google Cloud because the TCP connections are terminated closer to the clients.
That being said, from a memory point of view, the db.m3.xlarge from RDS is the closest match for the D32 from Cloud SQL. If the working set fits in the memory the performance for some queries will be similar.
Currently in Alpha, there is a new feature of Cloud SQL that uses comparable performance to GCE machine types.
A Google Cloud SQL Performance Class instance is a new Google Cloud
SQL instance type that provides better performance and more storage
capacity, and is optimized for heavy workloads running on Google
Compute Engine. The new instance type is an always-on, long-lived
database as compared to a Standard Class instance type. Performance
Class instances are based on tiers that correspond to Google Compute
Engine (GCE) standard or highmem machine types.
Link: https://cloud.google.com/sql/docs/getting-started-performance-class
Anyway, very good question, comparing prices with AWS, I found out that there is a huge difference in resources for the smallest instances and the same price:
GCE, D0 = $0.025 per hour (0,128 GB RAM + "an appropriate amount of CPU")
AWS, db.t2.micro = $0.02 per hour (1 GB RAM + 1 vCPU)
For 1 GB RAM in GCE, one would have to pay $0.19 per hour. Unfortunately Google does not specify anything about SSD storage, something very important for performance comparison.