Target Group
Target Group is used to route requests to one or more registered targets. A target can be resources like an instance or IP address, where traffic incoming to the load balancer is distributed across targets. Traffic received at a listener is routed to a target group based on the conditions set at each listener. Health check settings can be applied to a target group, which checks the status of all targets included in the target group.
Target group protocol and routing configuration
A target group can specify a Protocol and a port for each target. KakaoCloud supports HTTP, HTTPS, TCP, UDP, and PROXY Protocols, and the choice of target group protocol may be limited 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 a UDP listener in DSRNLB, additional settings are required for target instances, and only specific operating systems are supported. For more details, please refer to the How-to Guides.
Health check
The load balancer performs health checks periodically to check the status of targets. By applying health check settings to a target group, you can monitor the status of the connected resources and exclude faulty servers from traffic distribution targets.
When creating a target group, you can choose whether or not to use health checks. If health checks are not used, the Operating status of the target will be displayed as No Monitor. If health check settings are enabled, you can configure the type of health check, check frequency, timeout, and state transition criteria (success and failure). When choosing HTTP/HTTPS as the type, additional settings such as HTTP method, version, status code, and Check path can be configured.
Direct Server Return Network load balancer (DSRNLB) requires additional settings for the target instance for health check configurations. For details, refer to the How-to Guides.
The types of health checks applicable based on the target group protocol are as follows:
Combination of target group protocol and health check type
| Target group protocol | Health check type |
|---|---|
HTTP | HTTP, PING |
HTTPS | HTTPS, PING |
TCP | PING, TCP |
UDP | TCP, HTTP |
PROXY | PING, TCP |
Health check type
| Health check type | Description |
|---|---|
PING | Sends packets to the target and checks the response (ICMP Ping) |
HTTP | Sends packets to the specified path and checks the response |
HTTPS | Checks the response of targets using certificates in the same way as HTTP |
TCP | Checks the target's status using TCP protocol ports |
Target
Traffic routed to a target group is distributed among targets. targets can be instances in the same Availability Zone (AZ) and Virtual Private Cloud (VPC) as the load balancer to which the target group is connected. When registering targets, you must specify a port number, and you cannot register the same instance and port combination more than once within a target group.
The instance and port combination is determined by the primary private IP of the instance's primary network interface. Unused targets can be detached. Detaching only affects routing targets and does not impact the instance.
- For DSRNLB to work properly, the target's port must match the port of the listener Protocol connected to the target group. For details, refer to the How-to Guides.
- Additional settings are required for target instances when using DSRNLB. For more information, refer to the How-to Guides.
- When using DSRNLB, the load balancer and target instances must be in the same Subnet.
Status
A target has two status indicators: Provisioning status, which indicates whether the resource has been successfully created or is being modified or deleted, and Operating status, which indicates whether the created resource is available. Both statuses are displayed based on the status of underlying resources.
To check the status of targets, you need to apply health check settings. When health check settings are applied, health checks are performed periodically on all targets registered in the target group. The status of each target can be checked in the target group details, and targets that are not in a healthy state are automatically excluded from traffic distribution targets. Traffic routing resumes once the target is deemed healthy again.
Target provisioning status
| Status | Definition |
|---|---|
Active | Target provisioning successful |
Error | Target provisioning failed |
Creating | Target creation in progress |
Updating | Target modification in progress |
Deleting | Target deletion in progress |
Target operating status
| Status | Definition |
|---|---|
Healthy | Target is operating normally |
Draining | Target's weight is set to 0 |
Offline | Target group is adding an instance and waiting for health check |
No Monitor | Health check is not used |
Unhealthy | Target is not responding to health checks or has failed health checks |
Invalid | The instance registered as a target has been deleted |
Security group
A Security Group controls traffic that can reach and leave the load balancer. To ensure proper operation of the load balancer, policies must be configured to allow communication on health check ports and IPs. This requires adding an inbound policy to the Security Group of the instance that is added as a target.
When using Ping as the health check type, ICMP ports should also be set in the inbound policy.
Algorithms
The algorithm of a target group determines how traffic is routed to targets. KakaoCloud Load Balancing service provides the following three algorithms:
Round Robin: Distributes traffic sequentially to targets within the target group.Least connections: Prioritizes distributing traffic to targets with fewer connections.Source IP Hash: Ensures that clients with the same IP header always send traffic to the same target.
Sticky sessions
By default, traffic is routed to targets based on the selected algorithm. However, you can use the sticky session feature to bind a user's session to a specific target. This means that all requests from a user during a session will be sent to the same target. This feature is useful for servers that maintain state information to provide continuity for clients.
KakaoCloud provides sticky session options for HTTP cookies, app cookies, and source IP types. The available types vary depending on the combination of listener and target group protocols, and additional input may be required based on the selected type.
Sticky session methods
| Sticky session | Definition |
|---|---|
| HTTP cookie | Uses a cookie generated by the load balancer for connection - Additional configuration for stickiness duration |
| App cookie | Uses a user-specified cookie name for connection - Additional configuration for stickiness duration, cookie name |
| Source IP | Binds connection based on the client's IP - Additional configuration for sticky IP-netmask |
Configurable types based on listener and target group protocol combinations
| Listener-target group protocol | Sticky session |
|---|---|
| HTTP-HTTP | HTTP Cookie, App cookie |
| TCP-TCP | Source IP |
| UDP-UDP | Source IP |
Traffic weight
Different traffic weight can be assigned to targets based on user environments. By default, all targets in a target group have the same traffic weight. After creating a target group, traffic weight can be set as integers between 0 and 256, and the weight is displayed as a converted value. Traffic is then distributed based on the converted value's ratio.
- Weight conversion = (Weight/256)*100 (Rounded up to the first decimal place)
Setting a weight to 0 will display the target's status as Draining, but sessions connected to the target will be maintained until they end. Therefore, if you want to exclude a specific target from the target group, it is better to change the weight to 0 and then detach it, rather than detaching it immediately. This way, ongoing user connections are not forcibly terminated, allowing for stable service operation.
Monitoring port
Health checks are performed on the monitoring port. By default, this is the same as the target's traffic port. While you can change this to a different port according to your settings, it is not recommended as health check results might not reflect the actual service status.
Cases based on target port and monitor port settings
| Monitoring port setting | Target health check result | Target's actual service status | Load balancing operation | Description |
|---|---|---|---|---|
| Same as target port | Healthy | Healthy | O | |
| Unhealthy | Unhealthy | X | ||
| Different from target port | Healthy | Healthy | O | |
| Healthy | Unhealthy | O | The server provides normal service, but health check results are deemed 'Healthy', so requests are not routed → Increased load on other servers might lead to difficulties in handling failures | |
| Unhealthy | Healthy | X | The server fails to provide normal service, but health check results are deemed 'Healthy', so requests are routed → Clients cannot access the service | |
| Unhealthy | Unhealthy | X |