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 is shared-nothing (which really means shareddatabase):
design the system so that nearly any bottleneck can be removed by adding
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 application
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 solution
to ensure that the cluster will always respond to all of its IPaddresses even
under the failure of one load balancer. If high availability is not a requirement, primitive
load balancing will suffice, by giving each load balancer its own IPaddress and
exposing them all through a DNS RR (round-robin) record.
Pages:
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481