Today Keys : nlb, attribute, 속성, network, loadbalancer, 로드밸런서, cross zone, routing, policy, target, selection
이번 포스팅에서는 AWS Network Loadbalancer의 속성인 Client routing policy (DNS Record)와 Load balancer targets selection policy에 대해서 알아봅니다.
실제 속성에 따라서 도메인 질의(Query)에 대한 응답과 서비스 호출이 어떻게 되는지 알아봅니다.
AWS Network Loadbalancer의 2가지 속성
Client routing policy (DNS Record)
클라이언트가 NLB DNS 이름을 조회했을 때, 어느 AZ의 NLB IP를 우선 응답할지”를 결정합니다.
즉, DNS 응답 단계(클라이언트 → DNS) 의 분산 정책
Any Availability Zone (default): 특정 AZ를 선호하지 않고, 전체 AZ의 정상(healthy) NLB IP들 중에서 응답
Availability Zone affinity: 가능하면 클라이언트가 위치한 동일 AZ의 NLB IP를 우선 응답
해당 AZ에 정상 IP가 없으면 다른 AZ로 넘어감. (100% zonal affinity)
Partial Availability Zone affinity: 대부분(85%)은 동일 AZ를 선호하되, 일부는 전체 AZ에서 응답하도록 설정
※ 참고로 이 DNS affinity는 Route 53 Resolver를 통해 NLB DNS를 해석하는 클라이언트에 적용되는 동작으로 설명됩니다.
즉, Routing Policy는 Public DNS로 질의 및 응답에는 관여하지 않습니다.
Load balancer targets selection policy
트래픽이 NLB에 도착한 뒤, 등록된 타깃 중 어느 가용영역(AZ)/어느 타깃으로 전달할지를 결정
즉, 포워딩 단계(NLB → Target) 에서 교차 가용영역(Cross-zone AZ)으로 전달할지를 선택
Cross-zone load balancing OFF (기본): 각 가용영역의 NLB 노드는 자기 가용영역에 있는 타깃에게만 트래픽을 전달
Cross-zone load balancing ON: 각 가용영역의 NLB 노드는 다른 가용영역의 타깃까지 포함해 전체 타깃 풀로 트래픽을 분산
이제 Internet Facing NLB와 Internal NLB를 구성하고,
가용 영역 별로 타겟을 아래와 같이 구성하여, 속성을 변경하면서 테스트를 해보겠습니다.
여기에서는 Internet Facing NLB와 Internal NLB를 각각 테스트 했지만, 각 속성이 NLB에 따라 다르게 적용되지는 않습니다.
가용영역은 총 4개로 구성되어 있으며, NLB는 모든 가용 영역을 활성화했습니다.
AZ-1 ~ AZ-3까지 Target을 구성하였지만, AZ-2의 Target은 Unhealthy 상태입니다.
먼저, Cross-Zone을 활성화 한 상태에서 테스트를 진행합니다.
VPC 내에 있는 EC2와 VPC 외부에서 각각 NLB에 질의를 하면,
NLB에서 활성화한 4개의 가용영역의 NLB의 Interface 정보가 모두 질의에 응답합니다.
다음은 Cross-Zone을 비활성화 한 상태에서 테스트를 진행하겠습니다.
VPC 내에 있는 EC2와 VPC 외부에서 각각 NLB에 질의를 하면,
NLB에서 활성화한 4개의 가용영역 중에서 Healthy한 가용영역의 NLB Interface 정보만 질의에 응답합니다.
다음은 Cross-Zone을 비활성화하고, Routing Policy를 Availability Zone affinity로 설정하고 테스트를 진행합니다.
VPC 내에 있는 EC2와 VPC 외부에서 각각 NLB에 질의를 하면,
NLB에서 활성화한 4개의 가용영역 중에서
VPC 내부의 EC2는 동일한 가용 영역의 NLB Interface 정보만 질의에 응답하고,
VPC 외부에서는 Healthy한 가용영역의 NLB Interface 정보만 질의에 응답합니다.
이는 앞서 알아본 것처럼 Routing Policy가 Public DNS의 질의와 답변에는 영향을 미치지 않기 떄문입니다.
다음은 Internal NLB 구성에서의 테스트입니다.
Internal NLB도 가용영역은 총 4개로 구성되어 있으며, NLB는 모든 가용 영역을 활성화했습니다.
AZ-1 ~ AZ-3까지 Target을 구성하였지만, AZ-2의 Target은 Unhealthy 상태입니다.
먼저, Cross-Zone을 활성화 한 상태에서 테스트를 진행합니다.
VPC 내에 있는 EC2에서 질의를 하는 데, AZ-1과 AZ-3에 있는 EC2에서 질의를 합니다.
NLB에서 활성화한 4개의 가용영역의 NLB의 Interface 정보가 모두 질의에 응답합니다.
Internet NLB와 동일하게 동작합니다.
실제 각 가용영역1/3에 있는 EC2에서 Internal NLB로 서비스를 호출하면,
Cross AZ가 허용되기 때문에 2개의 가용 영역의 서버로 서비스가 되는 것을 확인 할 수 있습니다.
다음은 Cross-Zone을 비활성화 한 상태에서 테스트를 진행하겠습니다.
VPC 내에 있는 EC2에서 질의를 하는 데, AZ-1과 AZ-3에 있는 EC2에서 질의를 합니다.
NLB에서 활성화한 4개의 가용영역 중에서 Healthy한 가용영역의 NLB Interface 정보만 질의에 응답합니다.
실제 각 가용영역1/3에 있는 EC2에서 Internal NLB로 서비스를 호출하면,
Cross AZ가 허용되지 않았기 때문에 2개의 가용 영역의 서버가 각각의 가용영역의 서버로 서비스가 되는 것을 확인 할 수 있습니다.
다음은 Cross-Zone을 비활성화하고, Routing Policy를 Availability Zone affinity로 설정하고 테스트를 진행합니다.
VPC 내에 있는 EC2에서 질의를 하는 데, AZ-1과 AZ-3에 있는 EC2에서 질의를 합니다.
NLB에서 활성화한 4개의 가용영역 중에서
각각 동일한 가용 영역의 NLB Interface 정보만 질의에 응답하는 것을 볼 수 있습니다.
하지만, 서비스 호출은 Cross AZ를 허용했기 때문에 2개의 Healthy한 서버를 모두 사용하여 서비스 하는 것을 볼 수 있습니다.
마지막으로 한 가지를 더 알아봅니다.
현재 AZ-1/3에만 Healthy한 서버가 존재하는 상태에서, AZ-2의 서버에서 NLB를 호출합니다.
NLB의 속성은 Cross AZ를 Disable한 상태로 진행합니다. Routing Policy는 어느 것을 선택해도 됩니다. (동일 결과)
AZ-2에는 Healthy한 서버가 존재하지 않지만, DNS 질의에 대한 결과도 Healthy한 모든 NLB의 인터페이스로 결과를 응답받고,
서비스도 Healthy한 각 AZ-1/3의 서버를 통해서 서비스 되는 것을 확인 할 수 있습니다.
