Load balancing is an approach to handling an extremely large number or requests by configuring multiple app servers running the same app behind a single proxy server called a load balancer. The load balancer divides incoming requests among the app servers. As a result, if you have ten app servers behind a load balancer, each app server would handle one-tenth of the incoming requests.
Often, load balancing is used in situations where even a single, very large server could not handle all of the requests an app receives.
A load balancing system requires the following components:
Load Balancer. A proxy server or service that receives all incoming requests and proxies each request to a single app server.
App servers. Behind your load balancer, you must have multiple servers configured to run the exact same app.
Remote database. As there will be multiple app servers each needing to use the same database, you should use a central database that is accessible from all of your app servers.
There are two types of load balancers: TCP load balancers and HTTP/HTTPS load balancers. Unless you are a familiar with TCP load balancing, you should use an HTTP/HTTPS load balancer. With an HTTPS load balancer, your app's SSL certificate needs to be configured in the load balancer, not just in your app servers.
Aside from the type of load balancer, there are two ways to run a load balancer: using a load balancing service or managing your own load balancer.
Many server providers offer load balancers as a service. Through the provider's interface and API, you can specify which of your app servers should receive traffic from the load balancer.
Examples of these types of managed load balancers include:
Though more complicated, it's also possible to run your own load balancer. For example, you can use a separate server where you have manually configured Nginx as a load balancer.
No customizations to your app servers are absolutely required. If your app server would work on its own without a load balancer in front of it, then it will work with a load balancer in front of it.
The one optional customization to your app servers you may consider is to configure them to understand that the load balanacer is a proxy and therefore to not treat the load balancer's address as the requesting client's address.
To customize your server to trust X-Forwarded-For headers from the load balancer, you can create the following file on each app server:
/etc/nginx-sp/http.d/proxy_addresses.conf
In that file, use the Nginx set_real_ip_from directive to list the addresses or address ranges of your load balancers. For example, if the load balancer's address could be anywhere in the 10.0.0.0-10.255.255.255 address range, you would use:
set_real_ip_from 10.0.0.0/8;
Once you've created this file, restart Nginx on each app server with the following command run as root:
sudo service nginx-sp restart
You will point DNS for your domain to your load balancer's public address. That is, when using a load balancer, you will no longer have DNS pointed to any individual app server's address.
For your central database that is accessible from all app servers, you can either:
Unless you have a MySQL expert on your team who is experienced with scaling MySQL, you will generally want to use your provider's cloud MySQL service.