1

I am trying to get my backend stuff up and running and I am looking into the best way to save money, my app does api request usually between 8:30 am and 8:30 at night, with the morning, lunch and night having huge peaks.

What I planned to do is set up autoscaling instance group on google compute engine, but I ran into trouble in setting it up.

At first I set it up with nginx on a instance, and multiple copies of my vm all load balanced, but that does not help me with peak hours as well as saving money.

So I looked into the autoscaling, the issue I have is, my VM uses docker containers, with 3 running containers, one for nginx, one for couchdb, and one for some other background stuff.

What I tried to do is create a instance-001 that has the base work, all the files, databases, and everything. Once that hits 70% load, it will duplicate itself, and then load balance between the two.

The issue is I cant get it to keep the data, and spin up a duplicate. After setting one instance all up and working, (instance-001), I hit it with some loads, forcing it above 70%, it then spun up two more instances, 002, and 003, both empty clean vms, and then once it went below 70%, and the VM's were being removed, 001, with the actual data was removed, and 003 was left over.

As of right now, I am unsure how to set it up to scale and load balance.

The VM's were just 1CPU 3G machines with a 10GB ssd for testing, and I was following https://www.youtube.com/watch?v=TfbEwfYjKl4

It is slightly outdated as before it allowed you to load from snapshots, which is how I did this before, now it wont.

My biggest thing is what is the best production style setup for scaling a couchdb getup.

Anthony Taylor
  • 111
  • 1
  • couchdb is horrible in production. You can try to build enough infrastructure around couch that it won't be suck or switch to a production-quality DB like riak. – chicks Apr 18 '16 at 03:22
  • You can create an image from the disk with has data and configuration and use this image for your instance group template. I hope that helps. – Faizan Apr 19 '16 at 22:48
  • @Faizan I sort of have it working your way, but what I want is a disk, that when I update the DB, if a VM spins up right away, it will have access to the new data, instead of me having to recreate an image from the in-use disk and then reapply that to the group. – Anthony Taylor Apr 20 '16 at 23:09
  • Autoscaling works best for frontend instances. I would recommend having your database on a separate instance which is not part of autoscaling and use autoscaling for frontend instnaces only. In this way it will be easy to push updates to your database. You can refer to [this link](https://cloud.google.com/solutions/scalable-and-resilient-apps) for more information on building scalable application on Google Cloud Platform. – Faizan Apr 21 '16 at 19:04

1 Answers1

1

To add visibility posting an answer based on Faizan's Comments.

As described in the first 2 minutes of this video, the backend service can be autoscaled in a similar way as the frontend. The requirement for this is that the backend must be ¨stateless¨ (The database cannot live in the instance managed group that conform the backend).

The details can be found here for autoscaler and this additional article for the design.

Carlos
  • 1,385
  • 8
  • 15