One of the best practices of building highly available, robust and fail-tolerant systems is to build redundancy. And when it comes to web services, redundancy means more instances (general term nodes) which run the same code and pretty much stateless so there’s no hick-ups for clients making requests to different nodes. The benefit is that if one node fails, you got another running.

Also, let’s say you are publishing services like Twitter or WordPress and one of the articles published on your website became viral, there are thousands of requests per second. Also, let’s assume you don’t have any CDN caching, how do you scale this to your website? If you are just using a single instance and its public IP (probably AWS Elastic IP) - not good. A better way is to use a load balancer and in AWS there’s a services for that which is called Elastic Load Balancer (ELB). This service is part of the EC2 category.

AWS Elastic Load Balancer will not just distribute the traffic but also check for status health which makes your system more fail-tolerant. You can also reload and push new versions with 0-reload time if you use an ELB and multiple instances.

There are two categories of ELB: classic and app. Classic works directly with instances while app ELB works with target groups which allows for more flexibility. App ELB has more features like HTTP/2, multi-port (containers!) and path-routing which is great for microservices.

Let’s implement an app ELB!

Here are the steps:

Create 2 instances with Apache httpd and hello world HTML, register them with ELB - only private IP

Create an app ELB with external (public) IP

Test that you can see the page by going to the ELB’s public DNS (not IP!)

Stop one of the instances and see if you can still see the webpage

1. Create two instances

Because we will be using instances which don’t have public IPs, they won’t be able to fetch yum update and source code from the internet. We can just create an instance with a public IP first, verify that the web server is running, and then create an image of that. This is a very realistic scenario because in real life you’ll be working with images to save time on launching new instances (it’s faster to create an instance from an image which has an app and environment than use User Data to re-create environment anew). See this and this for more info.

First, create a public instance.

AMI: Amazon Linux hvm, SSD

Type: t2.micro

User Data as below

Tags: role=aws-course

VPC and AZ: default

Public IP: default (enabled)

Volume: default

Security group: open

User Data which creates an HTML page served by Apache httpd web server:

On 6. Review, check all the configs and then click on create button (blue). Wait, verify that you see success message and close (blue button).

You can verify all the settings again from the ELB console list view. The important thing is to have two instances from different AZs under the same ELB (in the same target group):

3. Test

Copy the ELB’s DNS name from the Description tab in the ELB list view’s bottom drawer. Paste the address in the browser and press enter. You should see: This is my cool HTML page (or whatever HTML you put on the instances).

You can also explore Listeners and Monitoring tabs. Listeners allow you to re-route to different target groups (you can have more than one target group with one IP) based on protocol, port and even path with is very useful (especially for microservices!).

4. Stop and test

Stop one of the instances… wait then check in the target group. It’ll say that the stopped instance is unhealthy. What’s good about app ELB is that it’ll distribute the load cross-AZs.

The webpage should still be visible in the browser on the same ELB’s URL.

Terminate instances, remove image, target group, and ELB.

Troubleshooting

If your private instance is not healthy, then you might want to see the logs. Unfortunately, logs from the web console are delayed. To log in to your instance which does not have a public IP simply use another instance with a public IP. Two instances must be in the same VPC. Copy the private key to your public instance with scp where (azat-aws-course is my key name and I’m copying to the home folder of my remote machine):

Logs will be in /var/log. If you used the provided lab User Data for this, then /var/log/user-data.log, otherwise just /var/log/cloud-init-output.log.

Wrap up

AWS EC2 offer one-stop-solution for robust and scalale systems. With Elastic Load Balancer, which is part of AWS EC2, developers can built redundancy by distributing the load among different virtual machines (instances) in various data centers (Availability Zones).

0 comments

ABOUT

This is the official blog of Node University: The Ultimate Resource on Node.js. You can find here the top resources on Node.js, JavaScript, cloud, React and software engineering. For free video previews, view courses at https://node.university/courses.