316 | Chapter 10: Large Projects
Shared-Nothing Scalability
One of the most basic concerns when deploying any web application is scalability:
how well the underlying architecture can respond to increased traffic. The canonical
Rails answer to the scalability question isshared-nothing(which really means shared-
database): design the system so that nearly any bottleneck can be removed by add-
ing hardware. The standard architecture looks like Figure 10-6.
The interface to the application is either a light web server (operating as a reverse
proxy balancer*) or a hardware load balancer. A small web server is usually used to
handle the static files (images, JavaScript, static HTML, stylesheets, and the like)
because a single-purpose static file server is much faster than an application server at
serving static files. This front end box delegates dynamic requests to one of the appli-
cation servers, selected either randomly or based on load.
For redundancy in large setups, two front end servers can be used, on separate
machines, proxying to the same set of application servers (see Figure 10-7).
If high availability is required, the load balancers must use a VIP-/VRRP-based solu-
tion to ensure that the cluster will always respond to all of its I Paddresses even
under the failure of one load balancer. If high availability is not a requirement, primi-
tive load balancing will suffice, by giving each load balancer its own I Paddress and
exposing them all through a DNS RR (round-robin) record.
Figure 10-6. Simple shared-nothing deployment environment
*Aforward proxysits in front of users and accelerates content that those users request. Areverse proxysits in
front of web servers and accelerates the content requested of that server. Aproxy balanceris a reverse proxy
that balances requests among its member servers.
Web server/
load balancerApplication
serverApplication
serverApplication
serverMore application
servers as
neededInternet DB