HAProxy EP 3: Sarah’s Adventure with L7 Load Balancing and HAProxy

{% raw %}

Meet Sarah, a backend developer at “BrightApps,” a fast-growing startup specializing in custom web applications. Recently, BrightApps launched a new service called “FitGuru,” a health and fitness platform that quickly gained traction. However, as the platform’s user base started to grow, the team noticed performance issues—page loads were slow, and users began to complain.

Sarah knew that simply scaling up their backend servers might not solve the problem. What they needed was a smarter way to handle incoming traffic and distribute it across their servers. That’s when she decided to dive into the world of Layer 7 (L7) load balancing with HAProxy.

Understanding L7 Load Balancing

Layer 7 load balancing operates at the Application Layer of the OSI model. Unlike Layer 4 (L4) load balancing, which only considers information from the Transport Layer (like IP addresses and ports), an L7 load balancer examines the actual content of the HTTP requests. This deeper inspection allows it to make more intelligent decisions on how to route traffic.

Here’s why Sarah chose L7 load balancing for “FitGuru”:

1. Content-Based Routing: Sarah could route requests to different servers based on the URL path, HTTP headers, cookies, or even specific parameters in the request. For example, requests for video content could be directed to a server optimized for handling media, while API requests could go to a server focused on data processing.
2. SSL Termination: The L7 load balancer could handle the SSL encryption and decryption, relieving the backend servers from this CPU-intensive task.
3. Advanced Health Checks: Sarah could set up health checks that simulate real user traffic to ensure backend servers are actually serving content correctly, not just responding to pings.
4. Enhanced Security: With L7, she could filter out malicious traffic more effectively by inspecting request contents, blocking suspicious patterns, and protecting the app from common web attacks.

Step 1: Sarah’s Plan with HAProxy as an HTTP Proxy

Sarah decided to configure HAProxy as an HTTP proxy. This way, it would operate at Layer 7 and provide advanced traffic management capabilities. She had a few objectives:

• Route traffic based on the URL path to different servers.
• Offload SSL termination to HAProxy.
• Serve static files from specific backend servers and dynamic content from others.

Sarah started with a simple Flask application to test her configuration:

Flask Application Setup

Sarah created two basic Flask apps:

1. Static Content Server (static_app.py):

from flask import Flask, send_from_directoryapp = Flask(__name__)@app.route('/static/<path:filename>')def serve_static(filename):    return send_from_directory('static', filename)if __name__ == '__main__':    app.run(host='0.0.0.0', port=5001)

This app served static content from a folder named static.

2. Dynamic Content Server (dynamic_app.py):

from flask import Flaskapp = Flask(__name__)@app.route('/')def home():    return "Welcome to FitGuru!"@app.route('/api/data')def api_data():    return {"data": "Some dynamic data"}if __name__ == '__main__':    app.run(host='0.0.0.0', port=5002)

This app handled dynamic requests like API endpoints and the home page.

Step 2: Configuring HAProxy for HTTP Proxy

Sarah then moved on to configure HAProxy. She created an HAProxy configuration file (haproxy.cfg) to route traffic based on URL paths

global    log stdout format raw local0    maxconn 4096defaults    mode http    log global    option httplog    option dontlognull    timeout connect 5000ms    timeout client  50000ms    timeout server  50000msfrontend http_front    bind *:80    acl is_static path_beg /static    use_backend static_backend if is_static    default_backend dynamic_backendbackend static_backend    balance roundrobin    server static1 127.0.0.1:5001 checkbackend dynamic_backend    balance roundrobin    server dynamic1 127.0.0.1:5002 check

Explanation of the Configuration

1. Frontend Configuration (http_front):
   • The frontend listens on ports 80 (HTTP).
   • An ACL (is_static) is defined to identify requests for static content based on the URL path prefix /static.
   • Requests that match the is_static ACL are routed to the static_backend. All other requests are routed to the dynamic_backend.
2. Backend Configuration:
   • The static_backend handles static content requests and uses a round-robin strategy to distribute traffic between the servers (in this case, just static1).
   • The dynamic_backend handles all other requests in a similar manner.

Step 3: Deploying HAProxy with Docker

Sarah decided to use Docker to deploy HAProxy quickly:

Dockerfile for HAProxy:

FROM haproxy:2.4COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

Build and Run:

docker build -t haproxy-http .docker run -d -p 80:80 -p 443:443 haproxy-http

This command runs HAProxy in a Docker container, listening on ports 80.

Step 4: Testing the Setup

Now, it was time to test!

1. Static Content Test:
   • Sarah visited http://localhost:5000/static/logo.png. The L7 load balancer identified the /static path and routed the request to static_backend.
2. Dynamic Content Test:
   • Visiting http://localhost:5000 or http://localhost:5000/api/data confirmed that requests were routed to the dynamic_backend as expected.

The Result: A Smoother Experience for “FitGuru”

With L7 load balancing in place, “FitGuru” was now more responsive and could efficiently handle the incoming traffic surge:

• Optimized Performance: Static content requests were efficiently served from servers dedicated to that purpose, while dynamic content was processed by more capable machines.
• Enhanced Security: SSL termination was handled by HAProxy, and the backend servers were freed from CPU-intensive encryption tasks.
• Flexible Traffic Management: Sarah could now easily add or modify rules to adapt to changing traffic patterns or requirements.

By implementing Layer 7 load balancing with HAProxy, Sarah provided “FitGuru” with a robust and scalable solution that ensured a seamless user experience, even during peak times. Now, she could confidently tackle the growing demands of their expanding user base, knowing the platform was built to handle whatever traffic came its way.

Layer 7 load balancing was more than just a tool; it was a strategy that allowed Sarah to understand, control, and optimize traffic in a way that best suited their application’s unique needs. And with HAProxy, she had all the flexibility and power she needed to keep “FitGuru” running smoothly.

{% endraw %}