EC2 -> EBS -> S3 ?

rubyonrails-talk
1

Greetings!

I'd appreciate hearing from anybody who's had experience with any of this. I've got a Rails app that currently deployed on EC2 with MySQL and am readying to move from a dev / prototype model to a full-scale production model. Right now I've got a single MySQL instance. I'm getting ready to move that to a master-slave setup. I'm also planning to use EBS volumes for the MySQL storage with snapshots saved to S3 for backup. Would love to hear from anybody who's done any of this before.

Also, I've been reading the stuff from Rightscale and they really seem to know what they're doing. Anybody got any experience using their services?

Thanks, Bill

2

Forgot to mention...

The database growth plan is to use sharding rather than clustering. So any experience with software 'load-balancing' front-ends that direct to an app instance based on subdomain rather than / in addition to availability would be very helpful.

Thanks again, Bill

3

Not trying to offend you, really. But how about getting big before planning sharding ? You can get really big with just tweaking mysql on a 4 core server and then you can have loads of memory and eventually you can keep everything in memory. Then you can cache the site, and then you can put varnish cache in front. I work on a site with more than 1.5 million individuals visiting each and every day, not distributed evenly, and for the most part it is a single mysql server, single web server and varnish cache. This setup replaced 14 squid servers that used to be in front.

(We actually have everything with fail over and more setup, but mostly to keep things simpler). With the setup we have, we can grow a lot bigger before we need to increase anything.

Trausti

4

Hi Trausti,

Not trying to offend you, really.

No offense taken, Trausti. Really.

But how about getting big before planning sharding ?

Agreed, at least as far as 'we won't need to do it for a good long while.' I was just saying that sharding rather than clustering is the eventual path we'll take. Much of that decision is based on another decision: deploying on EC2.

You can get really big with just tweaking mysql on a 4 core server and then you can have loads of memory and eventually you can keep everything in memory. Then you can cache the site, and then you can put varnish cache in front. I work on a site with more than 1.5 million individuals visiting each and every day, not distributed evenly, and for the most part it is a single mysql server, single web server and varnish cache. This setup replaced 14 squid servers that used to be in front.

Understood. And thanks for the numbers. I've got a lot more investigating / benchmarking to do before I know what our 'break point' will be. Most of the usage of the site I'm working on now will be updates rather than reads. I know that MySQL is optimized for reads, and there's lots of numbers out there for that but I haven't seen as as much about the update side of the performance.

(We actually have everything with fail over and more setup, but mostly to keep things simpler). With the setup we have, we can grow a lot bigger before we need to increase anything.

Thanks much for your reply. I appreciate it!

Bill