안녕하세요 MANVSCLOUD 김수현입니다.
데이터 센터 또는 클라우드 환경에서 부하 분산은 서비스의 안정성과 확장성을 위한 필수 요소입니다. 네이버 클라우드 플랫폼은 이러한 요구를 충족하기 위해 여러 종류의 Load Balancer 서비스를 제공하고 있습니다.
오늘은 다양한 Load Balancer 중 Network Load Balancer(NLB)에 대해 작성해보았습니다.
Network Load Balancer
Network Load Balancer는 사용자의 요청을 여러 서버에 분산시켜 각 서버의 부하를 줄이고 전체적인 성능을 향상시킵니다. 이는 서비스의 가용성을 높이고 장애 상황에서도 서비스 운영에 대한 안정성을 확보할 수 있습니다.
NLB의 경우 L4 스위치를 다루어본 경험이 있다면 상당히 친근하게 느껴지는 서비스일 것입니다. TCP 프로토콜을 사용하며 헬스 체크 기능을 제공하지만 로깅 기능과 동일 인스턴스의 여러 포트로의 로드밸런싱은 제공하지 않습니다. 또한 L4 계층에서 작동하기 때문에 경로 기반 라우팅, HTTP 2.0, SSL Offload와 같은 기능은 제공하지 않습니다. 하지만 NLB의 경우 최소 100,000 ~ 최대 400,000 CPS (초당 연결 수)의 분산 처리를 보장하므로 Application Load Balancer보다 높은 성능을 보입니다. 다만 Private 환경에서는 100,000 CPS(Small)만 제공된다는 점은 인지하고 있어야 합니다.
Load Balancer의 알고리즘은 연결된 Target Group에서 설정할 수 있는데 네트워크 로드밸런서의 경우 Hash와 Round Robin 방식을 지원하고 있습니다. Hash 방식은 클라이언트 IP 주소 정보를 사용하여 고유한 Hash를 생성하고 이 Hash 값에 따라 트래픽을 서버에 분배하는 방식입니다. 즉, 동일한 클라이언트로부터의 연속된 요청은 항상 동일한 서버로 전달됩니다. 이로 인해 클라이언트 세션 유지가 가능해지며 서버 간에 데이터 동기화가 필요한 상황에서 유용합니다. 그러나 이 알고리즘은 서버의 균형된 부하 분산을 보장하지 않을 수 있습니다. 이때 Round Robin을 고려해볼 수도 있습니다. Round Robin은 각 서버에 순차적으로 요청을 분배하는 방식입니다. 모든 서버는 동일한 요청을 순차적으로 받게 되므로 균형된 부하 분산을 달성하는 데에 유리합니다. 간단하면서도 효과적인 이 방식은 독립적인 요청을 처리하는 상황에서 유용합니다. 하지만 클라이언트 세션이 유지되어야 하는 상황에서는 Hash 알고리즘에 비해 불리할 수 있습니다.
추가적으로 네이버 클라우드 플랫폼의 Network Load Balancer는 DSR(Direct Server Return)을 지원하는데 DSR이란 다음과 같습니다.
DSR
DSR은 클라이언트의 요청을 서버에게 직접 전달하고, 서버는 응답을 로드밸런서를 거치지 않고 클라이언트에게 바로 전달하는 방식입니다. 이 방식은 로드밸런서가 응답 트래픽으로 인해 부하를 받는 것을 방지하고 전체 시스템의 처리 용량을 향상시킵니다.
DSR 환경에서는 몇 가지 주의사항이 있습니다. 전송 속도가 빠르고 클라이언트와 서버 간 IP 정보를 공유가 가능하다는 장점이 있지만 서버 내 LoopBack 인터페이스에 NLB의 IP(VIP)를 입력해주어야하는 작업이 필요할 수도 있습니다.
대표적인 사례로 네이버 클라우드에서 설치형 데이터베이스를 이중화할 때 NLB를 사용할 수 있는데요. 암호화와 같은 작업을 위해 서버에서 NLB로 통신이 필요한 경우가 있습니다.
이때 Direct Server Return(DSR) 모드인 Network Load Balancer는 클라이언트의 요청을 적절한 서버로 전달하는 역할만 하기때문에 서버의 응답은 직접 클라이언트로 보내지게 됩니다.
문제는 서버가 클라이언트의 요청을 받았을 때 목적지가 NLB IP 주소인 부분입니다.
클라이언트는 NLB의 IP 주소로 패킷을 보내는데 DSR 모드에서는 이 패킷을 서버에게 직접 전달시킵니다. 서버는 이 패킷을 받아서 처리하고 응답을 NLB를 거치지않고 클라이언트에게 직접 보내게되는데 이때 서버는 자신의 IP 주소가 아니라 NLB의 IP주소로부터 응답이 오는 것처럼 패킷을 만들어야하는 상황이 만들어집니다. 기본적으로 보안상 ARP Sppfing을 방지하기 위해 다른 IP 주소에서 오는 패킷을 거부하도록 되어있기때문에 추가적인 작업이 필요하게 됩니다. 보안상의 문제라기보다 DSR 방식의 로드 밸런싱이 원활하게 동작하기 위해 필요한 설정이므로 이를 해결하기 위해 서버 쪽에서 NLB의 IP 주소에서 오는 패킷을 받을 수 있도록 LoopBack 인터페이스에 NLB의 IP를 설정할 필요가 있습니다. 이와 같은 설정을 하게 되면 서버는 NLB의 IP주소에서 오는 패킷을 자신이 보낸 것으로 인식하게 되기때문에 이러한 케이스를 잘 알고 적용할 수 있어야합니다.
그렇다면 이러한 환경을 또 다르게 생각해봅시다. 예를 들어 Application Load Balancer의 경우 특정 IP만 접근할 수 있도록 제한해야할 경우 어떻게 할 수 있을까요? NACL을 사용하여 Allow와 Deny로 관리할 수 있습니다. 그렇다면 Network Load Balancer를 퍼블릭으로 사용해야할 경우에도 NACL를 고려해야할까요? 꼭 그렇지않습니다. Network Load Balancer 아래에 연결된 서버들의 ACG를 사용할 수 있습니다.
즉 Network Load Balancer 사용 시 서버 ACG에서 NLB 서브넷과 통신되도록 해두고 접속하는 곳에서 접속할 수 있도록 허용해주지 않으면 NLB DNS를 통해서 접속이 불가능합니다.
Hands-On
이 포스팅에서 Hands On은 Network Load Balancer 사용 시 적용하게될 LoopBack 설정 작업을 준비해보았습니다. Windows와 Linux 환경에서 어떻게 설정할 수 있을지 따라해보시기 바랍니다.
※ Windows Server
먼저 Windows 환경에서 적용해보도록 합시다.
” [실행] – hdwwiz ” 을 이용하여 하드웨어 추가 마법사를 실행해줍니다.
” Next ” 를 클릭해주세요.
” Install the hardware that I manually select from a list (Advanced) ” 선택 후 Next를 클릭해줍니다.
(목록에서 직접 선택한 하드웨어 설치(고급))
” Network adapters “를 찾아 선택 후 Next를 눌러주세요.
(네트워크 어댑터)
” Microsoft – Microsoft KM-TEST Loopback Adapter” 클릭 후 Next를 눌러줍니다.
” Next ” 클릭
” Finish ” 를 누르면 끝!
이제 ” [실행] – ncpa.cpl ” 을 입력 및 실행하여 ‘네트워크 연결’을 켜줍시다.
Microsoft KM-TEST Loopback Adapter의 Ethernet을 우클릭 하여 Properties(속성)을 눌러줍니다.
Internet Protocol Version 4 (TCP/IPv4)를 클릭 후 Properties(속성)을 클릭합니다.
1) Use the following IP Address
2) IP address에는 루프백 설정이 필요한 IP를 입력해줍니다.
3) Subnet mask는 255.255.255.255로 설정해주세요.
4) OK
구분하기 쉽게 이름을 변경해줍니다.
Microsoft KM-TEST Loopback Adapterd의 이름은 LoopBack으로 설정.
기존 XenServer PV Network Device는 Default로 설정.
이제 Weak Host Model 설정을 해주어야 하는데 운영 체제가 패킷 라우팅을 처리하는 방식에 따라 Weak Host와 Strong Host 두 가지 모드가 존재합니다.
주로 인바운드와 아웃바운드 패킷이 특정 인터페이스를 통해 전송되어야 하는지를 결정하는 데 사용되는데 Weak Host Model에서는 패킷이 모든 인터페이스를 통해 전송될 수 있고 Strong Host Model에서는 패킷이 특정 인터페이스를 통해 오가게 된다는 차이가 있습니다. 운영 체제 기본값은 Weak Host Model입니다.
그럼 Weak Host Model 설정을 진행해보도록 하겠습니다.
cmd를 실행해주고 위 그림과 같이 아래 명령어를 입력해줍니다.
netsh interface ipv4 set interface "LoopBack" metric=254 netsh interface ipv4 set interface "Default" weakhostreceive=enabled netsh interface ipv4 set interface "LoopBack" weakhostreceive=enabled netsh interface ipv4 set interface "LoopBack" weakhostsend=enabled
설정 후 netsh interface ip dump 명령어를 이용하여 설정된 내용을 확인할 수 있습니다.
※ Linux Server
이제 Linux 환경에서 설정해볼텐데 OS는 CentOS 7과 Ubuntu 20.04 기준으로 준비했습니다.
[root@centos-server ~]# vi /etc/sysconfig/network-scripts/ifcfg-lo:0
network-scripts 내에 ifcfg-lo:0 이름으로 파일 하나를 새로 생성해줍시다.
DEVICE=lo:0 IPADDR=LOOPBACK_IP NETMASK=255.255.255.255 ONBOOT=yes BOOTPROTO=none
위 내용에서 LOOPBACK_IP 부분만 루프백으로 지정할 IP로 설정 후 저장해줍니다.
[root@centos-server ~]# vi /etc/sysctl.conf
이제 리눅스 커널 설정을 추가로 해줍시다.
ARP 요청에 대한 시스템의 반응을 제어하기 위해 아래 값을 추가해줍니다.
net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.lo.arp_ignore = 1 net.ipv4.conf.lo.arp_announce = 2
[참고]
1) arp_ignore: 이 값을 설정하면 Linux 커널이 요청에 대한 ARP 응답을 보낼 때 사용할 인터페이스를 선택하는 방법을 변경합니다.
→ 0 (기본값): 커널은 ARP 요청에 대해 모든 로컬 주소를 사용하여 응답할 수 있습니다.
→ 1: 요청된 주소가 해당 인터페이스에 연결된 경우에만 ARP 응답을 보냅니다.
→ 2: 요청된 주소가 인터페이스에 연결되어 있고 해당 인터페이스가 요청을 보낸 인터페이스와 같은 경우에만 ARP 응답을 보냅니다.
2) arp_announce: 이 값을 설정하면 Linux 커널이 ARP 요청을 보낼 때 사용할 로컬 주소를 선택하는 방법을 변경합니다.
→ 0 (기본값): 커널은 모든 로컬 주소를 사용할 수 있습니다.
→ 1: 커널은 대상에 가장 가까운 로컬 주소를 사용합니다.
→ 2: 커널은 소스 주소 선택 알고리즘을 통해 선택된 주소를 사용합니다.
[root@centos-server ~]# ifup lo:0 [root@centos-server ~]# sysctl -p
위 명령어를 이용하여 생성한 lo:0 interface를 올려주고 커널 설정을 즉시 로드해줍니다.
[root@centos-server ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 123.123.123.123/32 brd 123.123.123.123 scope global lo:0
valid_lft forever preferred_lft forever
ip a 명령어를 이용하여 설정된 루프백 IP를 확인할 수 있습니다.
만약 Ubuntu를 사용한다면 네트워크 설정은 /etc/netplan/ 경로 아래 .yaml 파일에 아래와 같이 작성할 수 있습니다.
network:
version: 2
renderer: networkd
ethernets:
lo:
match:
name: lo
addresses:
- LOOPBACK_IP/32
동일하게 LOOPBACK_IP 부분만 루프백으로 지정할 IP로 설정 후 저장해줍니다.
netplan apply
이후 netplan apply 명령어 실행 시 /etc/netplan/ 디렉토리에 있는 YAML 구성 파일들을 읽고 그에 따라 시스템의 네트워크 구성을 즉시 업데이트할 수 있습니다.
root@ubuntu-server:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 10.0.13.14/32 scope global lo
valid_lft forever preferred_lft forever
지금까지 Network Load Balancer 서비스 사용 시 적용할 수 있는 LoopBack 설정 Hands On을 진행해보았습니다. Network Load Balancer 서비스 도입 후 이러한 케이스로 인해 LoopBacks 설정이 필요할 경우 크게 도움될 것이라 생각됩니다.
Personal Comments
네이버 클라우드 플랫폼의 네트워크 로드밸런서는 서비스의 성능과 안정성을 확보하는데 필수적인 도구입니다. L4 계층에서 작동하며 DSR을 지원하는 NLB는 대량의 트래픽을 효과적으로 분산 처리할 수 있습니다.
그러나 NLB를 사용함에 있어서는 그 특성과 제한사항을 정확히 이해하고 적절한 환경에서 사용하는 것이 중요합니다. 특히 DSR에 대한 개념을 이해하지 못하는 경우 네트워크 로드밸런서 사용에 어려움을 겪을 수도 있으므로 반드시 알고 있다면 도움이 될 것입니다.
긴 글 읽어주셔서 감사합니다.
