1. 개요
지난 2017년 9월 7일, 새로운 Load Balancer인 Network Load Balancer가 발표되었다.
2. 비교 자료
아래 비교는 NLB 발표 당시 AWS에서 제공하던 Elastic Load Balancing 제품 비교 자료를 기준으로 한다. 애플리케이션 요구 사항에 따라 적절한 로드 밸런서를 선택하면 된다. 유연한 애플리케이션 레벨 관리가 필요하면 Application Load Balancer, 높은 성능과 고정 IP가 필요하면 Network Load Balancer, EC2-Classic 네트워크에서 만들어진 기존 애플리케이션이라면 Classic Load Balancer를 선택하는 식이다.
Feature |
Application Load Balancer |
Network Load Balancer |
Classic Load Balancer |
Protocols |
HTTP, HTTPS |
TCP |
TCP, SSL, HTTP, HTTPS |
Platforms |
VPC |
VPC |
EC2-Classic, VPC |
Health checks |
✔ |
✔ |
✔ |
CloudWatch metrics |
✔ |
✔ |
✔ |
Logging |
✔ |
✔ |
✔ |
Zonal fail-over |
✔ |
✔ |
✔ |
| Connection draining (deregistration delay) | ✔ | ✔ | ✔ |
Load Balancing to multiple ports on the same instance |
✔ |
✔ |
|
WebSockets |
✔ |
✔ |
|
| IP addresses as targets | ✔ | ||
Load balancer deletion protection |
✔ |
✔ |
|
Path-Based Routing |
✔ |
||
Host-Based Routing |
✔ |
||
Native HTTP/2 |
✔ |
||
| Configurable idle connection timeout | ✔ | ✔ | |
Cross-zone load balancing |
✔ |
✔ |
|
SSL offloading |
✔ |
✔ |
|
Sticky sessions |
✔ |
✔ |
|
Back-end server encryption |
✔ |
✔ |
|
Static IP |
✔ |
||
Elastic IP address |
✔ |
||
Preserve Source IP address |
✔ |
3. 특징
3-1. 해시 라우팅
NLB는 해시 라우팅 알고리즘을 제공한다. (출처: https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)
Network Load Balancer에서는 연결을 수신하는 로드 밸런서 노드가 프로토콜, 원본 IP 주소, 원본 포트, 대상 IP 주소 및 대상 포트에 따라 흐름 해시 알고리즘을 사용하여 대상 그룹에서 기본 규칙을 위한 대상을 선택합니다. 그러면 동일한 원본에서 동일한 대상으로 이동하는 트래픽에 세션 고정이 제공됩니다.
즉, 같은 클라이언트에서 같은 목적지로 향하는 동일한 TCP 흐름은 같은 대상으로 전달되는 성격이 있다. 다만 이는 HTTP 쿠키 기반의 세션 고정과는 다르므로, 애플리케이션 레벨의 세션 관리가 필요하다면 별도로 고려해야 한다.
3-2. 고정 IP
- 각 AZ Subnet당 1개의 고정 IP를 제공한다.
- 이 특성 때문에 방화벽이나 보안 그룹에서 로드 밸런서의 IP를 명시해야 하는 구성에 유리하다.
3-3. Pre-warm
- Pre-warm 작업이 필요 없다.
- NLB는 기본적으로 초당 수백만 건 이상의 처리가 가능하다.
- Reverse Proxy 방식과 달리 리턴 트래픽을 처리하지 않는다.
4. 구성
4-1. 대상 그룹(Target Group) 생성
이름, VPC, 프로토콜 정도만 정의하면 바로 생성 가능하다. 프로토콜은 반드시 TCP를 선택한다. HTTP 방식의 대상 그룹을 만들면 NLB에 할당할 수 없다.
4-1.1. 대상 그룹에 인스턴스 추가
대상 그룹에 넣을 인스턴스를 선택한다. 단, 현재 기동되어 있는 인스턴스만 보인다. 중지 중인 인스턴스는 표시되지 않는다.
4-1.2. 대상 그룹 삭제
만약 대상 그룹이 로드 밸런서에 할당되어 있다면 삭제가 불가능하다.
Target group 'arn:aws:elasticloadbalancing:ap-northeast-2:.....:targetgroup/xxxxx/yyyyy' is currently in use by a listener or a rule
4-2. NLB 생성
- 생성 작업 시 위에서 만든 대상 그룹을 할당하면 된다.
- 특별히 설정할 것은 많지 않다.
- 다만 고급 상태 검사 설정의 Health Check 부분은 확인할 필요가 있다. [정상 임계 값]은 언제나 수정 가능하다. 또 [비정상 임계 값]은 [정상 임계 값]을 따라가므로 역시 수정 가능한 값이라고 할 수 있다. 대신 [간격]은 NLB 생성 시에 설정한 값으로 고정된다. 즉, 나중에 수정할 수 없는 값이다. 10초와 30초 중 택일이며 기본값은 30초이다.
생성 후에는 대상 그룹의 Health Check 상태가 healthy로 바뀌는지 먼저 확인하는 것이 좋다. 여기서 실패한다면 실제 서비스 포트 접근 문제인지, Health Check 포트 또는 보안 그룹 문제인지 분리해서 확인해야 한다.
5. nslookup
5-1. backend에 하나의 AZ에 해당하는 인스턴스만 존재할 때
Non-authoritative answer: Name: nlb-an2-sarc-......elb.ap-northeast-2.amazonaws.com Address: 10.0.0.83
하나의 IP만 lookup된다.
5-2. backend에 두 개의 AZ에 해당하는 인스턴스가 모두 존재할 때
Non-authoritative answer: Name: nlb-an2-sarc-......elb.ap-northeast-2.amazonaws.com Address: 10.0.1.169 Name: nlb-an2-sarc-......elb.ap-northeast-2.amazonaws.com Address: 10.0.0.83
2개의 IP가 lookup된다.
5-3. 중지 감지
각 AZ에 하나씩 Tomcat이 기동되어 있는 상황일 때, 특정 AZ에 속한 EC2 내 Tomcat을 shutdown하면 궁극적으로 NLB에서 해당 AZ에 해당하는 IP가 빠지는 것을 확인할 수 있다.
| 순번 | Tomcat 중지 시간 | NLB IP 제거 시간 | 소요 시간 | Health Check 설정 |
| 1 | 04:42:00 | 04:43:12 | 72초 | 3/3/10/30 |
| 2 | 04:41:00 | 04:52:01 | 61초 | 3/3/10/30 |
| 3 | 05:04:59 | 05:05:52 | 53초 | 3/3/10/30 |
| 4 | 05:14:00 | 05:14:33 | 33초 | 3/3/10/30 |
| 5 | 05:17:05 | 05:18:34 | 89초 | 3/3/10/30 |
| 6 | 07:02:31 | 07:03:17 | 46초 | 2/2/10/30 |
| 7 | 07:08:11 | 07:09:16 | 65초 | 2/2/10/30 |
| 8 | 07:12:08 | 07:13:16 | 68초 | 2/2/10/30 |
| 9 | 07:15:25 | 07:16:20 | 55초 | 2/2/10/30 |
| 10 | 07:17:48 | 07:18:20 | 32초 | 2/2/10/30 |
5-4. 기동 감지
5-3과 반대되는 상황이다.
| 순번 | Tomcat 기동 시간 | NLB IP 인식 시간 | 소요 시간 | Health Check 설정 |
| 1 | 04:47:18 | 04:48:10 | 52초 | 3/3/10/30 |
| 2 | 04:43:06 | 04:54:01 | 56초 | 3/3/10/30 |
| 3 | 05:11:35 | 05:12:32 | 57초 | 3/3/10/30 |
| 4 | 05:15:11 | 05:16:34 | 83초 | 3/3/10/30 |
| 5 | 05:19:01 | 05:19:34 | 33초 | 3/3/10/30 |
| 6 | 07:06:21 | 07:07:16 | 55초 | 2/2/10/30 |
| 7 | 07:10:15 | 07:11:16 | 61초 | 2/2/10/30 |
| 8 | 07:13:50 | 07:14:16 | 26초 | 2/2/10/30 |
| 9 | 07:16:43 | 07:17:20 | 37초 | 2/2/10/30 |
| 10 | 07:18:46 | 07:19:20 | 34초 | 2/2/10/30 |
위 테스트처럼 DNS 응답에 나타나는 NLB IP 변화를 관찰하면 AZ별 대상 상태 변화를 어느 정도 확인할 수 있다. 단, 실제 환경에서는 클라이언트 또는 DNS 캐시의 영향으로 관찰 시간이 달라질 수 있으므로 여러 번 반복해서 보는 것이 좋다.
6. WEB-WAS 사이에 NLB 구성 시 구성 방법
- WEB의 Security Group Outbound에 NLB Real IP 지정(Real IP는 nslookup하여 확인)
- WAS의 Security Group Inbound에 WEB 서버 Real IP 지정(Source는 자기 IP 정보를 그대로 달고 옴)
- WAS의 Security Group Inbound에 NLB Real IP 지정(그렇지 않으면 NLB에서 Health Check가 안 됨)
NLB는 원본 IP를 보존하는 특성이 있으므로, WAS 입장에서는 실제 호출자인 WEB 서버의 IP가 보일 수 있다. 반면 Health Check 트래픽은 NLB 쪽에서 들어오므로, 서비스 트래픽과 Health Check 트래픽을 모두 허용하도록 보안 그룹을 분리해서 확인해야 한다.
7. CLI
aws elb describe-load-balancers 사용 시 NLB 정보는 확인할 수 없다. --load-balancer-names 옵션을 써도 그렇다.
An error occurred (LoadBalancerNotFound) when calling the DescribeLoadBalancers operation: There is no ACTIVE Load Balancer named 'my-test-nlb'
NLB는 elbv2를 써야 한다.
aws elbv2 describe-load-balancers --names