Ravindra BagaleCourses & study guides मराठी Track your progress

Chapter 18: Load Balancing

18.13 Multiple target groups

By Last updated:

Why one balancer has more than one group

Section 18.5 used two groups so / and /api/ could land in different places. A real site needs that split for a stronger reason than a lab page. The web pages, the API, and the images do not want the same port, the same instance size, or the same spare capacity.

Instagram-style traffic is the picture, not Instagram's private design. People open the app, scroll photos, and call an API. Those are not one process. If they share one target group, a flood of image requests sits in the same queue as the API. Flipkart on a sale day has the same shape. Browsing can spike while checkout must stay up. One group would let the browsing spike take the checkout instances too.

What a target group is

A target group is the list the listener forwards to. It is not the load balancer.

Piece What you set Example we use
Protocol How the balancer speaks to the targets HTTP
Port The port on the instance 80 or 8080
Targets The EC2 instances registered in the group 2 or 3 instances
Health check The page that must answer before a target gets users Path /health, covered in section 18.15

One Application Load Balancer can forward to many groups. The listener rules choose the group. The group then chooses a healthy instance inside itself.

How one ALB uses three groups

This is one internet-facing Application Load Balancer in ap-south-1. The names are lab names.

One ALB · three target groups · path rules User ALBinternet //api/*/images/* TG-web :802 EC2 w1 w2 TG-api :80803 EC2 a1 a2 a3 TG-images :802 EC2 i1 i2 Default with no match returns 404. Refreshing / never lands on an API instance.

One Application Load Balancer forwards / to TG-web (port 80, 2 EC2), /api/* to TG-api (port 8080, 3 EC2), and /images/* to TG-images (port 80, 2 EC2).

Target group Port EC2 instances What it serves
TG-web 80 2 The pages
TG-api 8080 3 The API
TG-images 80 2 The images

Seven EC2 instances in total. Three groups. One balancer.

The listener rules we set:

  1. Path / forwards to TG-web.
  2. Path /api/* forwards to TG-api.
  3. Path /images/* forwards to TG-images.
  4. If no rule matches, the default action answers. In this example the default is a fixed response 404. The request does not guess a group.
Requests arrive and paint onto the matching group Browser ALBrules TG-web · / TG-api · /api/* TG-images · /images/* Blue = / · green = /api/* · orange = /images/* · three paths cycling

Requests arrive and are painted onto the matching group: blue for /, green for /api/*, orange for /images/*.

A request for / can only reach the 2 instances in TG-web. A request for /api/v1/feed can only reach the 3 instances in TG-api, on port 8080. A request for /images/photo-12.jpg can only reach the 2 instances in TG-images. Refreshing / never lands on an API instance, because that instance is not in TG-web.

How a sale uses a separate checkout group

Sale day — browsing and checkout stay separate Same ALB TG-browse desired 4 · max 12 TG-checkout desired 2 · max 6 path / path /checkout Browsing can grow toward 12. Checkout stays at 2 until checkout itself is busy.

On a sale day, TG-browse holds desired 4 (max 12) while TG-checkout stays at desired 2 (max 6) behind the same balancer.

Second example. Flipkart-style sale traffic, not Flipkart's real counts. Browsing and checkout are different groups behind the same balancer, so a spike in browsing does not take the payment capacity.

Target group Desired instances Maximum Why the numbers differ
TG-browse 4 12 Sale browsing is the spike
TG-checkout 2 6 Payment stays small and separate
  1. A shopper opens /. The rule sends that to TG-browse. Four instances share it.
  2. The same shopper posts /checkout. The rule sends that to TG-checkout.
  3. Browsing then jumps. The browsing group may grow toward 12.
  4. Checkout stays at desired 2 until checkout itself is busy. It does not have to grow just because people are looking at products.
  5. You should see two desired counts, 4 and 2, and two different maximums, 12 and 6.

How to create each target group

Button names may vary. Do these for TG-web first.

  1. Open the EC2 console in Asia Pacific (Mumbai).
  2. Open Target Groups.
  3. Choose Create target group.
  4. Choose target type Instances.
  5. Set the target group name to TG-web.
  6. Set the protocol to HTTP.
  7. Set the port to 80.
  8. Select the VPC that holds the two web instances.
  9. Leave the health check for section 18.15. For this pass, path / and success code 200 are enough so the group can be created.
  10. Choose Next.
  11. Select the first web instance.
  12. Confirm the port shown for it is 80.
  13. Choose Include as pending.
  14. Select the second web instance.
  15. Confirm that port is 80.
  16. Choose Include as pending.
  17. Choose Create target group.
  18. Open TG-web.
  19. You should see 2 registered targets.

Create TG-api the same way, with these differences on their own lines.

  1. Set the name to TG-api.
  2. Set the protocol to HTTP.
  3. Set the port to 8080.
  4. Register 3 instances, not 2.
  5. Confirm each pending port is 8080.
  6. Create the group.
  7. You should see 3 registered targets.

Create TG-images next.

  1. Set the name to TG-images.
  2. Set the protocol to HTTP.
  3. Set the port to 80.
  4. Register 2 instances.
  5. Create the group.
  6. You should see 2 registered targets.
  7. You should now see three groups, with counts 2, 3, and 2. The balancer is still not created. The groups are only lists until a listener forwards to them.