Comment by zhoutong | Hacker News Reader

Comment by zhoutong | Hacker News Reader

Parent Full thread

This is almost exactly how I deployed NameTerrific (https://www.nameterrific.com). It automatically gets ready for any horizontal scaling in the future.

In addition, I allocate the workers to their own instances so that they can grow independently. Also I use Capistrano to automate deployment. Whenever additional resources are needed, simply clone the instance and add it to the load balancer.

I use 2 Nginx workers and 8 Unicorn workers in a single app instance, and they serve in HTTP at 80 and 443 (yes they respond in HTTP via port 443 and the app should assume it's HTTPS). The app instances are firewalled in a private network and they use private IP addresses.

The load balancer has two networking interfaces, one public-facing and one private-facing. It's basically a reverse proxy serving traffic in both HTTP and HTTPS (which will be forwarded to HTTP:443). So the load balancer handles the encryption entirely.

The assets get compiled during deployment, and everything gets cached. I bundle all the CSS and JS into a single package, so that there's nothing to load other than the HTML and images (natively async) in subsequent visits. The website is simply way more responsive when deployed this way. I also use CloudFront to host the assets by simply pointing the cloud distribution to the website itself as the origin. Rails will handle the assets host automatically as well.

Whenever I need to deploy or manage the database directly for any reason, I will need to connect to the private network via VPN. It's secure and just neat.

If I need to build a local mirror, I'll install another nginx box, connect to the VPN, and reverse proxy HTTPS requests to the HTTP:443 directly. This reduces the HTTPS handshaking latency while still maintaining the security. And it just works.

EDIT: Added a link to make it easier for the curious people.

> Uses MySQL or Postgres as the datastore, deployed to a single instance, with frequent data backups to cloud storage

this does not seem to be "ready for horizontal scaling in the future".

I don't know whether you have multiple slaves, and TFA itself says that they'd scale the database _vertically_, I'm just stating that there's a pretty important mismatch between what you say and what the article says.

Well, it's true that database isn't horizontal-scaling-ready as described in the OP. But for many web apps, the database is not the bottleneck. Efforts should be spent on memory caching and NoSQL long before vertical scaling generates diminishing returns.

Of course, it's easy to add a master-slave replication to a single database instance when the need arises, even possible without downtime. So I assume most RDBMSs to be horizontal-scaling-ready.

The difficult part is the app stack. We need to be able to deploy more instances in minutes, not hours or days. If at the beginning we cram everything (Nginx, Unicorn and MySQL) into a single dedicated server it can be really difficult to increase the capacity in the future without downtime or additional expense. Instead, even if you don't need the power of several dedicated servers, it's worthwhile to virtualize a single server and split into a few boxes and make them horizontal-scaling-ready. Then you can clone, resize and migrate the instances.

This is what I do to increase the capacity of my app in a few minutes:

  1. Create a new instance, and load the pre-built app image
  2. Assign an IP address and add it to the DNS (like app-3.nameterrific.net pointing to an internal IP)
  3. Add the app server to deploy.rb (for Capistrano)
  4. cap deploy
  5. Add the IP to load balancer

That's it. This stack can be used from day one affordably and it can scale to potentially billions of visitors.

>But for many web apps, the database is not the bottleneck.

Really? I think the database is usually the bottleneck in most web apps. That's why you cache data: to avoid hitting the database.

Writes to the DB (and more importantly replication since it is single threaded in mysql) are often the bottleneck that is hard to scale. Write through caches can scale reads up very high. It takes a long time to hit the write limit for most applications so often read slaves and memcache is sufficient.

If you don't mind me asking, what load balancer are you using? I'm trying to setup multiple app servers on EC2 behind ELB using Redis as a session_store and I can't get sessions to persist.

I used to use ELB, but later I migrated the whole app to a self-hosted private cloud on a dedicated server.

I'm using Nginx as the load balancer, and there're no session problems for me because I use the built-in secure cookie store.

Thanks for the response. I appreciate it.

This sounds like a bug in your session store code as opposed to a load balancing issue. Are they all on the same host name?

Reply on news.ycombinator.com