In the realm of scaling systems to accommodate increasing user loads, reliance on a single machine becomes untenable. Cloud providers like AWS offer a solution by allowing the rental of VMs or containers for flexible durations. This enables the provisioning of additional machines during traffic surges and their deactivation during lulls, optimizing cost efficiency.
The question is, how does all this traffic get to our new machines?
AWS Elastic Load Balancing!
What is Elastic Load Balancing?
Elastic Load Balancing, or short ELB, is a set of services provided by AWS. They give you one address via IP or DNS, to which you can direct all your traffic. They’re proxy servers that use algorithms or measurements to decide which downstream service should handle the traffic.
For example, a load balancer could send the first request to the first server, the second to the second, and so on. Then when it sends a request to all available servers, it starts from the beginning.
ELB encompasses three primary load balancing services:
- Application Load Balancer: Tailored for HTTP workloads such as web servers.
- Gateway Load Balancer: Suited for custom servers on EC2, like firewalls or packet inspectors.
- Network Load Balancer: Designed for TCP and UDP workloads like gaming or video servers
Additionally, there exists a Classic Load Balancer, primarily utilized for EC2 servers within classic networks. However, its relevance diminishes for non-legacy AWS systems.
This article will discuss monitoring Application Load Balancers.
Why Monitor Elastic Load Balancing?
As we learned before, load balancers manage the traffic between multiple servers. This makes them a critical part of your infrastructure. If one is overwhelmed, misconfigured, or crashes, your users can’t access the systems it’s sending traffic to.
In the end, a load balancer is just one or more servers so that it can get overwhelmed like any other system in your architecture. The modern ones from AWS aren’t too susceptible to such problems, but it’s always important to look out.
The same is valid for the configuration. You have to configure it just like any other service; if you do it wrong, you might pay more than you want or make your architecture vulnerable to the outside.
And finally, like any other service, a load balancer can crash. AWS might have a good track record for service uptime, but they aren’t perfect. If your load balancer goes down, you want to get notified as soon as possible.
So, while load balancers don’t execute business logic and are more or less generic support services inside your architecture, you still need to know how they perform. Otherwise, your business could be at risk.
What to Monitor in Elastic Load Balancing?
Since a load balancer is a proxy server installed on a VM in the cloud, you can monitor everything you could watch in a generic VM. Starting from such low-level metrics doesn’t yield easily digestible and actionable information. So, let’s look at more focused metrics.
Requests
The most basic metric is requests in a specific period. It gives you a coarse view of a load balancer, how much is happening, and if issues are occurring.
Errors
If things go wrong, you want to know how often an error transpired and the related error code. If you only get 4XX errors once in a while, chances are good your services aren’t to blame, but some fluctuations on your user’s clients. If you get regular 5XX, you might have to look deeper into your downstream services to find out if they are misconfigured or if you need to provide them with more potent hardware.
Connections
Connections tell you how many clients are connected to your ALB at any time. They give you an idea of how many users are active simultaneously. If you get connection spikes at specific times of the day or week, you might want to provision additional instances in those periods.
Consumed Load Balancer Capacity Units
AWS bills you by Load Balancer Capacity Units (LCUs), an aggregate metric used to calculate how much you used your load balancer. It consists of new connections per second, active connections per minute, processed bytes per hour, and rule evaluations per second.
Since this more or less complicated aggregate is what will end up on your monthly bill, you want to have an eye on this without manually calculating it.
How to Monitor Elastic Load Balancing?
AWS offers several ways to monitor your ALB. They include CloudWatch Metrics, request tracing, and CloudTrail Logs.
CloudWatch has a technical focus. It allows you to check how your endpoints are performing, if some downstream services can’t keep up, or if there are errors. It’s all about finding answers to a developer’s questions when trying to improve service.
CloudTrail is about resource access. It will tell you who accessed what and when. For lawsuits, it can help prove someone accessed some information. CloudTrail can help you with post mortems. When things go wrong, you need to reconstruct what happened.
Request tracing is helpful to see what services your requests used. In serverless architectures, you’ll have dozens of services, and it can be hard to keep up with their interactions. The trace created by X-Ray will give you a step-by-step view of all points in your architecture touched by requests.
Summary
ELBs serve as the gateway to cloud services, demanding continuous monitoring to ensure seamless operation and cost optimization. Treating them as standalone services and vigilantly managing their configuration is crucial for maintaining system integrity and cost efficiency.
