Target Group
A Target Group is used to route requests to one or more registered targets. Targets can be instances, IP addresses, or other resources, and traffic that flows into the load balancer is distributed among these targets. The traffic received by the listener is routed to the target group based on the conditions set in each listener. Health check settings can be applied to the target group, and the status of all targets in the group is monitored.
Target Group Protocol and Routing Configuration
A target group can specify a protocol, and each target can have a port defined. KakaoCloud supports the HTTP, HTTPS, TCP, UDP, and PROXY protocols, and the selection of the target group protocol may be restricted based on the load balancer or listener you are connecting to. A single target group can be connected to multiple listeners of the same load balancer but cannot be connected to more than one load balancer.
| Load Balancer | Listener Protocol | Target Group Protocol |
|---|---|---|
| ALB | HTTP | HTTP, PROXY |
HTTPS | HTTP | |
| NLB | TCP | HTTP, HTTPS, TCP, PROXY |
UDP | UDP | |
TLS | TCP | |
| DSRNLB | TCP | TCP |
UDP | UDP |
- When using the UDP listener in DSRNLB, additional configuration is required for the target instances, and it supports only certain operating systems. For detailed information, refer to How-to Guides.
Health Check Settings
The load balancer performs periodic health checks on the targets to monitor their status. By applying health check settings to the target group, you can check the status of connected resources and exclude unhealthy servers from receiving traffic.
When creating a target group, you can choose whether to enable health checks. If health checks are not enabled, the target's operational status is displayed as "No Monitor." When health checks are enabled, you can configure the health check type, interval, timeout, and the success and failure criteria. If you choose HTTP/HTTPS as the check type, you can additionally configure the HTTP method, version, status code, and check path.
For Direct Server Return Network Load Balancer (DSRNLB), additional configuration is required on the target instance to enable health checks. For more details, refer to How-to Guides.
Depending on the protocol of the target group, the applicable health check types are as follows:
Target Group Protocol and Health Check Type Combination
| Target Group Protocol | Health Check Type |
|---|---|
HTTP | HTTP, PING |
HTTPS | HTTPS, PING |
TCP | PING, TCP |
UDP | TCP, HTTP |
PROXY | PING, TCP |
Health Check Types
| Health Check Type | Description |
|---|---|
PING | Sends packets to the target and checks the response (ICMP Ping) |
HTTP | Sends packets to a configured path and checks the response |
HTTPS | Checks the response from a target using certificates, similar to HTTP |
TCP | Checks the target's status using the TCP protocol port |
Target
Traffic routed to the target group is distributed to the targets. The targets can be instances located in the same availability zone (AZ) and Virtual Private Cloud (VPC) as the load balancer. When registering targets, a port number must be specified, and the same instance-port combination cannot be registered multiple times in a target group. The criteria for determining the instance-port combination is based on the instance's primary private IP address of its network interface. Targets that are not used can be deregistered. Deregistering a target removes it from the routing target but does not affect the instance.
- For DSRNLB, the port of the target must match the port of the listener protocol in the target group to work correctly. For more details, refer to How-to Guides.
- When using DSRNLB, additional configuration is required for the target instance. For more details, refer to How-to Guides.
- The load balancer and target instance must exist within the same subnet when using DSRNLB.
Status
Targets have two status indicators: Provisioning and Operating. The Provisioning status shows whether the resource has been successfully created, or if it is in the process of being modified or deleted, while the Operating status indicates whether the resource is available for use. Both statuses are combined with the status of lower-level resources.
To monitor the target's status, health check settings must be applied. When health checks are applied, periodic health checks are performed on all targets registered in the target group. The status of each target can be viewed in the target group details, and targets that are not healthy are automatically excluded from traffic routing. Once the target is considered healthy again, traffic will be routed to it.
Target Provisioning Status
| Status | Definition |
|---|---|
Active | Target provisioning successful |
Error | Target provisioning failed |
Creating | Target creation in progress |
Updating | Target update in progress |
Deleting | Target deletion in progress |
Target Operating Status
| Status | Definition |
|---|---|
Healthy | Target is functioning normally |
Draining | Target weight is set to 0 |
Offline | Waiting for target to pass health check |
No Monitor | Health check is not enabled |
Unhealthy | Target did not respond or failed the health check |
Invalid | Target instance has been deleted |
Security Group
A security group controls traffic to and from the load balancer. To ensure proper functioning of the load balancer, rules must be configured to allow traffic to and from the health check port and IP. For this, you need to add inbound rules to the security group of the instance added as the target.
When using the Ping health check type, ICMP ports must also be added to the inbound rules.
Algorithms
The algorithm of a target group determines how traffic is routed to the targets. KakaoCloud Load Balancing service provides three algorithms:
Round Robin: Distributes traffic sequentially to the targets within the target group.Least Connections: Prioritizes routing traffic to targets with fewer connections.Source IP Hash: Routes traffic to the same target for clients with the same IP header.
Sticky Sessions
By default, traffic is routed to targets according to the selected algorithm. However, the Sticky Session feature allows the load balancer to bind a user's session to a specific target. This ensures that all requests from the user during the session are sent to the same target. This feature is useful for maintaining session state on a server.
KakaoCloud supports sticky sessions using HTTP Cookie, App Cookie, and Source IP. The types that can be configured depend on the combination of the listener and target group protocols, and some types may require additional configuration.
Sticky Session Types
| Sticky Session | Definition |
|---|---|
| HTTP Cookie | Uses a cookie generated by the load balancer to bind the connection - Additional settings for Stickiness duration |
| App Cookie | Uses a user-defined cookie name to bind the connection - Additional settings for Stickiness duration and Cookie name |
| Source IP | Binds the connection based on the client's IP - Additional settings for Sticky IP-netmask |
Configurable Sticky Session Types Based on Listener and Target Group Protocol Combination
| Listener-Target Group Protocol | Sticky Session |
|---|---|
| HTTP-HTTP | HTTP Cookie, App Cookie |
| TCP-TCP | Source IP |
| UDP-UDP | Source IP |
Traffic Weight
You can assign different traffic weights to targets depending on your environment. All targets in a target group initially have the same traffic weight. After creating the target group, you can configure the traffic weight from 0 to 256, and the traffic will be distributed according to the calculated weights.
- Weight Calculation = (Weight/256)*100 (rounded to the nearest integer)
If a weight is set to 0, the target's status is marked as Draining, but any active sessions connected to that target will be maintained until they end. To exclude a target from the group immediately, it's better to set its weight to 0 and then deregister it, as this prevents forced disconnections for users.
Monitoring Port
Health checks are performed on the monitoring port. By default, this is the same port as the target's traffic port. While you can change it to another port, it is not recommended as the results of health checks may not match the actual service status.
Target Port and Monitoring Port Configuration Cases
| Monitor Port Setting | Target Health Check Result | Target's Actual Service Status | Load Balancing Functionality | Description |
|---|---|---|---|---|
| Same as Target Port | Healthy | Healthy | O | |
| Unhealthy | Unhealthy | X | ||
| Different from Target Port | Healthy | Healthy | O | |
| Healthy | Unhealthy | O | Server is providing service but health check shows healthy, so no traffic is forwarded → Increased load on other servers may cause issues | |
| Unhealthy | Healthy | X | Server cannot provide service, but health check shows healthy, so traffic is still forwarded → Clients cannot use the service | |
| Unhealthy | Unhealthy | X |