안녕하세요. 오랜만에 글을 씁니다.
이번 글에서는 로드 밸런서와 그 종류에 대해 알아보겠습니다.
Load Balancing, 한글로 부하 분산이라 부르는 이것은 웹 애플리케이션에서 쉽게 만나볼 수 있습니다. 트래픽을 수신해 여러 서버로 요청을 대신 전달하는 역할을 합니다.
이번 글에서는 컴퓨터 네트워크 기초와 애플리케이션 개발자에게는 생소할 수 있는 다양한 로드 밸런싱에 대해 알아보겠습니다.
OSI 7 Layer, TCP/IP 모델과 네트워크 통신
OSI 7 Layer와 TCP/IP 프로토콜 스택은 컴퓨터 네트워크에서 데이터를 주고받을 때 사용되는 모델입니다. 이 두 모델은 모두 네트워크 통신에 대해 설명하지만, OSI 7 Layer는 이론적인 내용을 다룰 때 많이 사용됩니다. 실제 네트워크 모델은 대부분 TCP/IP 프로토콜 스택을 기준으로 동작합니다. 본 글에서는 OSI 7 Layer를 기준으로 설명하겠습니다.
각 계층은 자신만의 역할을 가지고, 네트워크 통신 시 각자 해야 할 일에 대해 책임을 집니다. 이렇게 하면 문제가 생겼을 때 책임 소재를 명확히 할 수 있습니다. 가령 사내의 모든 PC에서 인터넷 접속이 안된다면 문제의 원인을 PC 가 아닌 라우터나 인터넷 회사에서 공급되는 회선에 문제가 있는지를 살펴봐야 합니다.
캡슐화와 역 캡슐화
OSI 7 Layer에 의해 캡슐화와 역 캡슐화가 진행됩니다. 사용자가 naver.com 이라는 주소로 접속한다고 가정하면, 사용자는 “내가 naver.com에 접속하고 싶다.”라는 정보를 패킷에 담아 네이버 서버에 요청합니다. 그 과정에서 아래의 정보들이 포함됩니다.
- 응용 계층 — HTTPS 프로토콜을 사용한다. GET 메서드를 사용해 네이버 웹 페이지의 리소스를 받아오고 싶다. 나는 iPhone을 사용하고 있고, safari 브라우저를 사용한다.
- 표현 계층 — 문자 인코딩은 UTF-8 로 인코딩한다. SSL /TLS 프로토콜을 사용해 암호화 한다. 암호화 키는 RSA 알고리즘을 사용해 교환하고, 데이터는 AES-256 알고리즘으로 암호화한다.
- 세션 계층 — SSL/TLS 핸드셰이크를 수행한다. 이미 수행했으면 이전에 협상했던 방법으로 암호화한다.
- 전송 계층 — TCP 프로토콜을 사용한다. 포트 번호로는 443번(HTTPS)을 사용한다.
- 네트워크 계층 — 내 ip 주소는 211.109.6.249이고 목적지 ip 주소는172.217.25.174 이다. 출발지 포트는 49152번이고 목적지 포트는 443이다. 프로토콜 번호는 6번(TCP의 프로토콜 번호)이다.
- 데이터 링크 계층 — 나의 MAC 주소는 9a:ab:b6:dc:19:18이고, 목적지 MAC 주소는 4c:a9:19:2a:d5:a4 이다. 이더 타입은 0x0800(IPv4의 이더 타입) 이다.
- 물리 계층 — 전송 속도는 100Mbps이다. 통신 방식은 Full-Duplex로 한다.
Network Layer
본 글에서 소개하는 내용을 이해하기 위해 네트워크 계층에 대한 이해가 선행되어야 합니다. 네트워크 계층의 목적은 멀리 떨어진 원격지 네트워크로 패킷을 전달하는 게 목적입니다. 패킷이 갈 경로를 지정하는 행위를 라우팅이라 하고, 라우팅을 하는 장비를 라우터(Router)라고 합니다.
집이나 사무실, 카페같은 작은 규모의 네트워크에서 라우터는 외부 인터넷과 통신하기 위한 관문과도 같은 역할을 하므로 Internet Gateway라고도 부릅니다. 보통 게이트웨이는 해당 네트워크에서 사용 가능한 IP 주소 풀 중 첫 번째나 마지막 주소를 사용하는 경우가 많습니다.
라우터는 라우팅 테이블을 보고 라우팅 합니다. 라우팅 테이블은 패킷을 전송하려는 목적지로 가려면 어떻게 가야 하는지에 대한 정보가 작성되어 있습니다. 마치 지도 애플리케이션처럼 가는데 소요되는 비용, 거리, 정확도 등을 제공합니다. 더 정확하고(Subnet mask가 길고), 거리가 가깝고(Administraive Distance가 낮고), 비용이 낮은(Metric 값이 적은) 경로로 패킷을 라우팅 합니다. 이해를 돕기 위해 일상적인 용어를 사용했지만 실제로 라우터는 이와 같은 우선순위로 패킷을 라우팅 합니다.
Load Balancing
직역하면 ‘부하 분산’이라고 하는 로드 밸런싱은 일상생활에서도 쉽게 만나볼 수 있습니다.
예를 들어보겠습니다. 공항에서 수화물을 위탁할 때, 창구가 여러 개면 일을 빨리 처리할 수 있지만 한 개라면 굉장히 오래 걸립니다. 한 개의 창구에서 모든 일을 처리하다 창구 직원이 못해먹겠다며 그만두면 아예 짐을 부치지 못하는 사태가 생길 수도 있습니다.
서버도 마찬가지로 한 곳의 서버로 트래픽이 몰리면 정상적인 서비스를 제공하지 못합니다. 따라서 부하를 분산해 주는 로드밸런싱이 필요하고, 로드밸런싱을 제공하는 주체를 로드밸런서라고 부릅니다.
Load Balancing Algorithm
부하를 분산하는 방법은 여러가지가 있습니다.
- 라운드 로빈 — 요청을 순서대로 순환하며 분배하는 방식
- 최소 연결 — 연결된 세션 수가 가장 적은 서버로 요청을 분배하는 방식
- 최소 응답 시간 — 서버의 현재 응답 시간을 기준으로 가장 빠르게 응답할 수 있는 서버에 요청을 분배하는 방식
- IP 해시 — 클라이언트의 IP 주소를 해싱해 동일한 IP 에서 들어오는 요청은 동일한 서버로 분배하는 방식
Load Balancer
부하를 분산시키는 주체는 로드밸런서입니다. 다양한 로드밸런서에 대해 알아보겠습니다.
애플리케이션 개발자에게는 L7와 L4의 로드밸런서가 가장 익숙할 겁니다. 클라우드 벤더는 간편한 로드밸런싱을 제공합니다. AWS의 Application Load Balancer와 Network Load Balancer 가 그 예시이며, 각각 응용 계층과 전송 계층 프로토콜의 정보를 바탕으로 로드밸런싱을 제공합니다.
Nginx 나 Apache HTTP Server 등의 소프트웨어는 웹 서버의 역할도 하면서 리버스 프락시의 역할도 수행합니다. 리버스 프락시를 사용함으로써 내부망에 위치한 서버의 위치를 숨길 수 있고, 설정(라운드 로빈, 가중치 라운드 로빈, IP 해시, 최소 연결 등)에 따라 부하를 분산할 수도 있습니다.
위의 로드밸런싱 이외에도 다양한 로드밸런싱이 있습니다.
Global Server Load Balancing(GSLB)
글로벌 서버 로드밸런싱은 지리적으로 분산된 여러 데이터 센터나 서버에 트래픽을 분산하는 방식입니다. GSLB를 이해하려면 DNS에 대한 이해가 선행되어야 합니다.
Domain Name System(DNS)
일반 사용자들은 203.179.33.12 같은 IP 주소만 보고서는 이 서비스가 무슨 서비스인지 알기 힘듭니다. 그래서 해당 IP에 별명을 붙여주는데, 이를 도메인 네임이라 부릅니다. 도메인 네임을 기반으로 IP 주소를 획득하는 과정을 DNS 라 합니다. 이때 매핑되는 IP는 여러 가지 일 수 있습니다.
nslookup(name server look up)은 도메인의 정보를 가지고 있는 name server에 도메인 정보를 질의하는 명령어입니다. 어떤 DNS 서버에 질의할지는 변경할 수 있습니다.
위 사진과 같이 gui로 세팅할 수도 있고, cli 환경에서는 /etc/resolv.conf 파일에서 네임서버를 수정할 수 있습니다.
DNS는 단점이 있습니다. 도메인 질의에 의해 IP 주소를 반환할 때 헬스체크를 하지 않는다는 점입니다. 헬스체크를 하지 않고 단순히 번갈아가며 IP를 반환하는 Round Robin 방식으로 동작하기 때문에, 최악의 경우에는 서비스 불가능한 IP 주소만을 계속 응답할 수 있습니다.
이런 DNS의 단점을 보완하는 장비가 GSLB입니다. GSLB 가 알고 있는 IP에 헬스체크를 수행해 정상인 IP 만 응답합니다. 이런 이유로 GSLB Inteligence DNS라고도 부릅니다.
GSLB는 DNS 트래픽을 지리적으로 가까운 서비스로 분산해 더 빠른 서비스 제공이 가능합니다.
위 사진은 도쿄 리전과 오하이오 리전에 각각 ec2를 만들어 google.com 도메인에 질의한 결과입니다. GSLB를 사용하는 구글은 사용자의 DNS 질의 각 지리에서 가장 빠르게 접속 가능한 IP를 반환합니다. 오하이오 리전에서의 질의는 시카고의 데이터센터로, 도쿄 리전에서의 질의는 도쿄의 데이터센터로 응답하고 있습니다.
CloudFlare와 같은 CDN 서비스를 사용해 GSLB를 구현할 수 있습니다. 또는 AWS Route 53과 같은 각 클라우드 벤더의 DNS Health Check 기능을 사용해 GSLB를 구현할 수 있습니다.
ECMP(Equal Cost Multi-Path)
여기 또 다른 로드밸런싱이 있습니다. 위에서 알아봤던 로드밸런싱은 모두 상위 계층(L7~L4)에서의 로드밸런싱이었습니다. L3, 즉 네트워크 계층에서도 로드밸런싱이 동작할 수 있습니다.
처음에 알아봤듯이 라우터는 패킷을 원격 네트워크로 라우팅 합니다. 라우팅 경로는 정확도, 거리, 비용의 우선순위로 결정됩니다. 그런데, 이 세 가지 요소가 모두 같으면 라우터는 어디로 패킷을 보내야 할까요?
이때는 라우터가 5-튜플이라 불리는 5가지 정보를 가지고 트래픽을 라우팅 합니다. 출발지 IP, 출발지 포트번호, 목적지 IP, 목적지 포트번호, 프로토콜 번호 이 5가지가 같으면 하나의 흐름이라고 생각하고 트래픽을 같은 경로로 전송합니다. 모든 비용이 같을 경우 여러 경로로 라우팅 하는 방법이기 때문에 Equal Cost Multi-Path라는 이름이 붙었습니다. 나름 괜찮은 방법이지만, 균등한 부하 분산이 되지 않을 수 있습니다.
예를 들어 위 그림처럼 4가지의 작업을 해야 한다고 가정하겠습니다. 텍스트 전송에는 HTTP 프로토콜을, 동영상 전송에는 FTP 프로토콜을 사용한다고 하면 5 튜플 중 목적지 포트에 대한 정보가 다르므로, R1은 흐름이 다른 트래픽이라 생각해 부하를 분산합니다. 하지만 ECMP는 해당 경로의 대역폭이나 지연시간을 고려하지 않으므로, A 동영상을 전송하고 있는데 B 동영상 전송 트래픽을 또 전달할 수 있습니다.
UCMP(Unequal Cost Multi-Path Routing)
그래서 UCMP 가 등장했습니다. Un-equal Cost Multi-Path의 약자로, 비용이 다른 경로에 부하를 분산하는 기능입니다. 위의 그림으로 예를 들면 A1에서 C1으로 가는 경로는 90 Gbps의 대역폭을 가지는 반면 C2로 가는 경로는 120 GBps의 경로를 가지므로 C2로 더 많은 트래픽을 보내는 방식입니다.
하지만 이 또한 문제가 있습니다. C2쪽으로의 경로만 트래픽이 전달되므로 사용량이 많아지면 C1 쪽으로의 경로보다 성능이 떨어질 수 있습니다. 그럼에도 라우터는 여전히 C2쪽으로만 트래픽을 전송하므로, 부하분산의 의미가 없어질 수 있습니다.
UCMP는 가중치를 기반으로 트래픽을 전송합니다. 따라서 관리자가 주기적으로 경로의 성능을 파악하고 가중치를 조정해야 합니다. 그래야 유의미하게 로드밸런싱이 되기 때문입니다. 즉 수동 로드밸런싱인 셈입니다. 하지만 관리자가 라우팅 경로를 모니터링하고 수동으로 가중치를 설정함으로써 얻는 이점이 클지는 따져봐야 합니다.
마치며
이번 글에서는 컴퓨터 네트워크에 대한 기초와 로드밸런싱에 대해 알아봤습니다. 오늘 소개한 GSLB와 ECMP, UCMP 이외에도 Gateway Load Balancer(GWLB), Firewall Load Balancer(FWLB) 등 다양한 로드밸런서가 있습니다. 애플리케이션 개발자에게 생소할 수 있는 내용이지만 인프라는 개발과 뗄 수 없는 관계이므로, 네트워크와 로드밸런싱에 대한 이해가 수반된다면 더 나은 프로덕트를 만들 수 있습니다.
감사합니다.
참고자료
- https://se-juno.tistory.com/1 — L3 스위치 동작
- https://se-juno.tistory.com/6 — TCP 동작
- https://se-juno.tistory.com/7 — SSL Hand Shake
- https://se-juno.tistory.com/8 — 암호화 알고리즘
'Network > L4' 카테고리의 다른 글
| 암호화 방식과 암호화 알고리즘 (0) | 2024.09.09 |
|---|---|
| TCP와 TLS의 동작 원리 #2 (2) | 2024.09.07 |
| TCP 와 TLS의 동작 원리 #1 (0) | 2024.09.06 |