이 포스팅에서는 NLB(Network Load Balancer)에서 제공하는 Stickiness 기능에 대해 살펴보려고 합니다. 일반적으로 부하 분산 솔루션을 사용할 때 고려하는 고려사항으로는 “부하분산 알고리즘” 과 “Persistent” 혹은 “Sticky” 등으로 불리는 동일한 Client 가 동일한 서버로 분기되도록 하는 기능인데요. NLB 에서는 이처럼 동일한 Client 가 동일한 서버로 분기되도록 유지하는 기능을 “Stickiness” 라고 합니다.
따라서, “Stickeiness” 가 활성화되어 있는 경우라면 동일한 Client 는 동일한 서버로의 접속이 보장되게 됩니다. 반대로 이야기하면 Stickiness 가 활성화되어 있지 않다면 하나의 Client 가 항상 동일한 서버로 접속되는 것을 보장하지 않는 의미라고 보셔도 될 것 같습니다. 이 경우라면 Load Balancer 에 설정되어 있는 부하 분산 알고리즘을 따르게 되겠죠.
참고로, NLB 에는 별도로 부하 분산 알고리즘을 설정하는 옵션이 없습니다. 따라서, NLB 를 생성하면 한 가지 부하 분산 알고리즘을 따르게 되는데요. NLB 에서는 아래의 정보를 기반으로 한 Hash 방식의 부하 분산을 수행합니다.
- The protocol
- The source IP address and source port
- The destination IP address and destination port
- The TCP sequence number
일반적으로 On-premise 에서 사용하는 Load Balancer 에서 지원하는 Hash 는 IP 주소를 기반으로한 Hash 를 사용해서 부하 분산과 동시에 Stickiness 기능을 지원하지만 NLB 가 사용하는 Hash 는 여러개의 정보를 Hashing 하여 처리하기 때문에 단일 TCP 세션에 대한 부하 분산은 가능하지만 Hash 자체만으로 Stickiness 기능을 포함하지는 않습니다.
각 AWS Load Balancer 의 부하 분산 알고리즘은 아래의 링크를 참고하시기 바랍니다.
먼저 간단하게 구성되어 있는 저의 테스트 환경을 살펴보도록 하겠습니다.
- Internet Facing NLB 가 각각 AZ1, AZ3 에 Provisioning 되어 있습니다.
- AZ1 과 AZ3 에는 2대씩 총 4대의 웹서버가 EC2 에 구성되어 있습니다.
- 4대의 웹서버를 Target Group 으로 등록 후 NLB 에 연결하였습니다.
NLB 생성이 완료되었으니 생성된 NLB 의 DNS Name 을 “nslookup” 을 통해 확인해보도록 하겠습니다.
위 그림과 같이 nslookup 결과 NLB DNA Name 에 대해서 2개의 공인 IP 를 확인할 수 있는데요. 그 이유는 Target Group 을 AZ1(ap-northeast-2a)과 AZ3(ap-northeast-2c)에 Provisioning 하였기 때문입니다.
일단 DNS Name 을 인터넷 브라우저에 입력하여 NLB 가 인터넷을 통해 정상적으로 접속이 되는지 확인하였습니다.
이제 좀 더 상세한 내용을 다뤄보기 위해 위 과정에서 파악한 NLB DNS Name 의 두 공인 IP 로 각각 20개씩의 요청을 전달하여 부하 분산 여부를 확인하도록 하겠습니다.
위 그림들과 같이 각각의 공인 IP 가 두 대의 서버로만 트래픽이 분산되는 것을 확인할 수 있었는데요.
왜 나머지 두대의 서버로는 부하 분산이 되지 않았을까요?
그 이유는 바로 Default 설정이라면 NLB 는 Cross Zone Load Balancing 설정이 비활성화되어 있기 때문입니다. 일단은 Cross Zone Load Balancing 설정은 그대로 두고 이 상태에서 Target Group 의 Stickiness 설정을 활성화해보도록 하겠습니다.
NLB 에 등록된 Target Group 의 속성에서 아래와 같이 Stickiness 값을 활성화한 후 동일하게 curl 명령을 수행하도록 하겠습니다.
참고로, NLB 의 속성 변경 시 변경된 값이 적용되기까지 몇 분의 시간이 소요될 수 있으므로 설정이 적용이 될 때까지 잠시 기다린 후 테스트를 진행합니다.
먼저, AZ1 에 해당하는 공인 IP 로 테스트를 진행하였습니다.
아래 그림과 같이 AZ1 에 해당하는 공인 IP 로 접속하는 경우 특정 서버(Server1)로 요청이 계속 전달되는 것을 확인할 수 있습니다.
AZ3 로 접속을 하는 경우에도 아래와 같이 특정 서버(Server3)로 요청이 계속 전달되는 것을 확인할 수 있습니다.
여기까지의 테스트를 통해 우리는 한가지를 알게 되었는데요. 일반적으로 Stickiness 와 같은 기능을 사용하는 경우에는 동일한 Client 가 동일한 Server 로 접속하도록 하기 위해 사용되는데 NLB 환경에서 Cross Zone Load Balancing 이 비활성화되어 있다면 각 AZ 에 설치된 NLB 의 Endpoint 는 Client 가 갖더라도 서로다른 Stickiness 를 갖는다는 것을 알게 되었습니다.
그럼 이번에는 Cross Zone Load Balancing 을 활성화한 후에 동일한 테스트를 해보도록 하겠습니다.
NLB 에서 아래와 같이 Cross Zone Load Balancing 의 값을 “Enabled(활성화)” 로 변경합니다.
그리고 Target Group 의 Stickiness 값도 비활성화하여 부하 분산이 잘 이뤄지는지 확인하도록 하겠습니다.
Cross Zone Load Balancing 옵션을 활성화하기 전과 동일하게 nslookup 을 통해 알아낸 두 개의 공인 IP 로 각각 동일한 요청을 보냈을 때 아래와 같이 AZ 에 관계없이 모두 부하 분산이 잘 되는 것을 확인하였습니다.
그럼 이번에는 이 상태에서 Stickiness 를 활성화 한 후 다시 테스트를 해보도록 하겠습니다.
아래 테스트 결과와 같이 Cross Zone Load Balancing 이 활성화되어 있는 경우에는 두 개의 공인 IP 중 어느 곳으로 접속하여도 AZ 에 상관없이 모두 동일한 서버로 요청이 전달되는 것을 확인할 수 있습니다.
위의 테스트 결과에서 알 수 있듯이 NLB 에서 제공하는 Stickiness 는 Cross Zone Load Balancing 옵션을 어떻게 설정하느냐에 따라서 각 AZ 별로 서로 다른 Stickiness 값을 가질 수 있습니다. 제가 수행한 테스트에서는 제가 nslookup 을 통해 DNS Name 에 해당하는 공인 IP 를 알아낸 후 특정 공인 IP 로 요청을 전달하였기 때문에 실제로 Client 입장에서는 공인 IP 별로 항상 동일한 서버로 접속이 된다는 것을 알 수 있었습니다. 하지만, Cross Zone Load Balancing 기능이 비활성화되어 있는 상황에서 일반적인 사용자라면 어떻게 될까요? 아마도, 저처럼 nslookup 을 통해 공인 IP 를 알아낸 후 접속하는 것이 아니라 DNS Name 을 통해 직접 접속하게 될 것입니다. 그런 상황을 고려해서 가정해 본다면 어떤 Client 는 NLB DNS Name 에 대한 공인 IP 값을 Return 받는 값이 달라지는 상황이 된다면(공인 IP 1 에서 공인 IP 2로 바뀌는 상황) Stickiness 값이 활성화 되어 있는 NLB 에 접속했음에도 불구하고 서로 다른 서버로 접근이 되는 상황이 발생할 수도 있다는 것을 알 수 있습니다. 물론, 일반적인 DNS TTL 을 고려해본다면 단시간에 이런 상황이 발생할 가능성은 낮겠지만 좀 더 긴 시간동안에 Stickiness 가 보장되어야 한다면 Cross Zone Load Balancing 옵션을 활성화하여 이러한 시나리오를 미연에 방지하는 것을 권고 드립니다.
감사합니다.
