HTTP load balancing using Nginx

Load balancing is a popular way to scale out an application and increase its performance and redundancy. Here, we are going to use Nginx, a popular web server that can also be configured as a simple yet powerful load balancer.

Load Balancing

The simplest configuration for load balancing with Nginx may look like the following:

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://myapp1;
        }
    }
}

In this example, there are 3 instances of the same application running onsrv1, srv2 and srv3. When the load balancing method is not specifically configured, it defaults to round-robin.

Note: 
1. By using 'proxy_pass' you are telling nginx to pass the request to the mentioned URL. In our case it is 'http://myapp1'.
2. upstream defines a cluster that you can proxy requests to. It's commonly used for defining either a web server cluster for load balancing, or an app server cluster for routing / load balancing.

Nginx Load Balancing Mechanism:

round-robin:

technique: The default load‑balancing technique for NGINX. If you have two servers installed the first request will go to the 1st server and the second request will go to the 2nd server and so on.

upstream backend {
       server backend1.example.com;
       server backend2.example.com;
}

Here the first request will backend1 server and 2nd request will be routed to backend2 server.

least-connected:

technique: The load balancer compares the current number of active connections of each server and sends the request to the server having fewest connections. least-connectedallows controlling the load on application instances more fairly in a situation when some of the requests take longer to complete.

configuration: just add least_conn directive to the server group configuration.

upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

ip_hash:

technique: This makes user session sticky, subsequesnt request from a specific client will always be routed to same server except when this server is unavailable.

configuration: just add ip_hash directive to the server (upstream) group configuration:

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

If a user’s request routed to srv1 at the first place then ip_hash technique will force the subsequent request from the same client to be routed to srv1 .

Weighted load balancing:

It is possible to specify how many requests will be routed to a server by weighted load balancing . When the weight parameter is specified for a server, the weight is accounted as part of the load balancing decision.

The server weights are not configured in round robin , least_connection or ip_hash mechanism which means that all specified servers are treated as equally qualified for a particular load balancing method.

upstream myapp1 {
server srv1.example.com weight=3;
  server srv2.example.com; 
  server srv3.example.com;
}

With this configuration, every 5 new requests will be distributed across the application instances as the following:

srv1 — — — > 3 requests

srv2 — — — > 1 request

srv3 — — — > 1 request

This is the part-I of 2-parts articles of load balancing. The second part is here https://medium.com/@tasnuva2606/http-load-balancing-using-nginx-c00933c4f5e5