[네트워크] 로드 밸런싱(Load Balancing)

둘 이상의 CPU나 저장 장치와 같은 컴퓨터 자원들에게 작업을 나누는 것

로드밸런서 (Load Balancer)

로드 밸런서의 필요성

• 한 서버에 트래픽 과다로 인한 시스템 성능 저하 문제 
  
  • 현대의 모든 정보는 인터넷으로 연결되어 있고, 인터넷이 발전하면서 데이터 통신량이 폭발적으로 증가했고, 이는 트래픽의 증가로 이어진다.
  • 이때 서버가 사용자가 원하는 정보를 빠르게 응답해야 하는데, 아무리 뛰어난 성능의 서버라도 한 대의 서버가 모든 트래픽을 감당할 수는 없다.
  • 서버가 하나인데, 수천만개의 들어온 요청을 처리하려면 과부하가 걸려 서비스가 중단될 수 있다. (문제 발생)
• 해결 방법
  • Scale-Up(수직적 확장) : 서버가 더 빠르게 동작하기 위해 하드웨어 성능을 높이는 방법
    • 기존 서버 자체의 성능 향상(확장)
    • ex) CPU나 메모리 업그레이드, 저장 장치 교체 등
    • 한계 : 일정 수준 이상으로 성능을 높이는데 한계가 있고, 비용이 많이 든다.
  • Scale-Out(수평적 확장) : 하나의 서버보다는 여러 대의 서버가 나누어서 일을 처리하는 방법
    • 기존 서버와 동일하거나 낮은 성능의 서버를 두 대 이상 증성하여 운영하는 것
    • 장점 : 비용이 비교적 적게 들고 확장성이 뛰어나다.
    • 문제점 : 여러 대의 서버에 트래픽을 균등하게 분배해야 한다.
    • 이때 서버가 여러 대이기 때문에 각 서버로 쏟아지는 트래픽을 여러 대의 서버로 균등하게 분산해주는 로드 밸런싱 기술이 필요하고, 이 역할을 하는 것이 로드 밸런서 이다.

 

로드 밸런서의 개념 및 역할

부하 분산 또는 로드 밸런싱(Load Balancing)은 컴퓨터 네트워크 기술의 일종으로, 둘 이상의 중앙처리장치 혹은 저장 장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다. 이때 그 역할을 하는 것을 로드 밸런서라고 한다.

https://github.com/jmxx219/CS-Study/blob/main/network/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C.md

개념

• 서버에 가해지는 부하(로드)를 분산(밸런싱)해주는 장치 또는 기술을 통칭
  • 로드밸런싱 기술을 제공하는 서비스 또는 장치
  • 클라이언트와 서버풀 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리
    • 서버풀(Server Pool) : 분산 네트워크를 구성하는 서버들의 그룹
  • 서버가 최적의 성능(Performance)를 유지할 수 있도록 트래픽을 효율적으로 분배
     

VIP(Virtual IP)와 함께 구성

• VIP : 로드밸런싱의 대상이 되는 여러 서버들을 대표하는 가상의 IP
• 클라이언트들은 서버에게 IP로 직접 요청하는 것이 아니라 로드밸런서가 가지고 있는 VIP를 대상으로 요청을 한다.
• 이후 로드밸런서는 VIP를 통해 받은 요청을 설정된 부하 분산 방법에 따라 각 서버로 요청을 분산시킨다.

역할

1. 부하 분산 (Load Distribution)
   
   • 특정 서버의 과부하를 방지
   • 네트워크 트래픽 또는 클라이언트의 요청을 여러 서버에 적절하게(균형있게) 분배
   • 트래픽이 많아질 경우에도 여러 서버로 나누어 안정적인 서비스 제공
2. 높은 가용성(Availability)과 신뢰성(Reliability) 보장한다.
   • Active한(정상적인) 서버에게만 요청을 전달하고, 장애가 발생하면 서버로 리다이랙트
   • 서버 장애에도 서비스가 지속되도록 Failover 기능 제공

📌 리다이렉트(Redirect)와 리다이렉션(Redirection) 개념

리다이렉트(Redirect)와 리다이렉션(Redirection)은 같은 의미이며, 요청을 다른 경로로 자동 전환하는 과정을 뜻한다.

1️⃣ 리다이렉트(Redirect)란?
클라이언트(브라우저)가 A라는 주소(URL)로 요청을 보냈을 때, 서버가 응답을 통해 다른 주소(B)로 이동하도록 안내하는 것 웹 페이지 이동뿐만 아니라 네트워크 트래픽 관리나 서버 장애 대응에도 사용된다.

📌 예제
example.com → www.example.com으로 자동 이동 http:// 요청을 https://로 강제 이동 old-site.com에서 new-site.com으로 리디렉션


2️⃣ 리다이렉션(Redirection) 방식

🔹 301 Moved Permanently (영구 이동)
페이지가 영구적으로 이동했을 때 사용 검색 엔진이 변경된 주소를 기억함 (SEO에 영향) 예: old-site.com → new-site.com

🔹 302 Found (일시적 이동)
임시로 다른 페이지로 이동할 때 사용 사용자가 원래 URL을 다시 방문하면 기존 페이지로 연결됨

🔹 307 Temporary Redirect (일시적 리다이렉트, 요청 유지)
302와 비슷하지만, 요청 메서드(GET, POST 등)를 유지

🔹 308 Permanent Redirect (영구 리다이렉트, 요청 유지)
301과 유사하지만, 요청 방식(GET, POST 등)을 유지


3️⃣ 리다이렉트 vs 로드 밸런서의 리다이렉션 차이

웹 리다이렉트: 사용자가 요청한 페이지를 다른 페이지로 이동시키는 것 (SEO, 보안 등 목적) 로드 밸런서의 리다이렉션: 특정 서버가 다운되었을 때, 트래픽을 정상적인 서버로 자동 전환하는 것

즉, 일반적인 리다이렉트는 웹 페이지 이동을 위한 것이고, 로드 밸런서에서의 리다이렉션은 트래픽 분산과 가용성을 보장하기 위한 것

3. 확장성(Scalability) & 유연성(Flexibility) 제공

• 서비스 중단 없이 서버를 추가하거나 제거할 수 있다. (자동 확장 지원)
• 클라우드 환경에서는 Auto Scalingr과 함께 사용하여 동적으로 서버 수를 조절한다.

4. 보안(Security) 기능 강화

• DDOS 공격 완화 : 트래픽 분산을 통해 특정 서버가 공격당하는 것을 방지
• SSL/TLS 종료(Offloading) : 암호화 / 복호화 작업을 로드 밸런서가 처리하여 서버 부담 감소
• 방화벽 및 접근 제어 : 특정 IP 또는 지역의 트래픽을 제한하여 보안 강화

 

 

로드밸런서 기본 기능

1. Health Check (상태 확인)
   • 서버들에 대한 주기적인 Health Check를 통해 서버들의 장애 여부를 판단하고, 정상 동작 중인 서버에만 트래픽을 전달한다.
   • L3 체크 (네트워크 계층)
     • ICMP(Echo Request/Reply, 핑)를 이용하여 서버의 IP 주소가 통신 가능한 상태인지를 확인
     • 네트워크 연결 상태만 확인할 뿐, 실제 서비스 운영 가능 여부는 알 수 없다.
   • L4 체크 (전송 계층)
     • TCP 3 Way-Handshaking를 수행하여 서버의 포트 상태를 검사
     • 특정 포트(ex. 80, 443)가 응답 가능한지 확인하여 서비스 가용성을 체크
   •  L7 체크 (어플리케이션 계층)
     • 실제 웹 페이지에서 통신을 시도하여 이상 유무 파악
       실제 웹페이지 요청을 보내서 정상적인 응답(200 OK 등)이 오는지 확인
     • HTTP(S) 요청을 직접 보내기 때문에 서비스 장애를 보다 정확히 감지 가능
2. Tunneling (터널링)
   • 데이터 스트림을 인터넷 상에서 가상의 파이프를 통해 전달시키는 기술
   • 패킷 내에서 터널링할 대상을 캡슐화(encapsultation)를 통해 보호하여 목적지까지 전송
   • 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제하게 한다.
     
     
   • 터널링 과정
     1. 데이터를 특정 프로토콜(ex. IP, TCP, GRE)로 감싸서 캡슐화
     2. 인터넷을 통해 터널링된 데이터 전송
     3. 수신 측에서 캡슐화를 해제하여 원본 데이터 복원
   • 터널링 ex
     • VPN (Virtual Private Network): 공용 인터넷을 통해 사설 네트워크와 안전하게 연결
     • SSH 터널링: 보안이 필요한 원격 연결을 위해 사용
     • IPSec 터널링: IP 패킷을 암호화하여 안전하게 전송

📌 데이터 스트림

데이터 스트림(data stream)은 연결지향통신에서, 전송된 정보를 수집하거나 정보를 전송할 때 사용되는 디지털 방식으로 암호화 된 일관된 신호의 흐름을 말한다. 데이터 스트림은 데이터 제공자로부터 추출된 정보의 집합이다.
 
전자 및 컴퓨터 구조 분야에서, 데이터의 흐름은 재구성 가능한 데이터경로 배열 다른 비슷한 파이프 네트워크나 다른 처리 블럭, 처리 유닛들의 포트로 언제, 어떤 정보들이 들어오거나 밖으로 나가는 지를 관할한다. 
폰 노이만 구조의 컴퓨터는 명령 스트림기반인 반면, 안티머신은 데이터스트림 기반이기 때문에 종종 데이터 스트림을 명령 스트림으로 보기 쉽다.

3. NAT (Network Address Translation)

• 내부 네트워크에서 사용하는 사설 IP 주소와 로드밸런서 외부(외부 네트워크)의 공인 IP 주소 간의 변환 역할
• 로드밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소(VLAN or VIP)를 통해 접속하는 것이 주 목적
  • SNAT(Source Network Address Translation, 출발지 주소 변환) : 내부 사설 IP 주소 → 외부 공인 IP 주소로 변환
    ex. 내부 클라이언트가 인터넷을 사용할 때 로드밸런서를 거쳐 공인 IP로 나간다.
  • DNAT(Destination Network Address Translation) : 외부 사설 IP 주소 → 내부 공인 IP 주소로 변환
    ex. 외부 사용자가 특정 도메인으로 접근할 때, 로드밸런서가 트래픽 내부 서버로 전달

4.DSR (Direct Server Return, 직접 서버 응답)

• 서버 → 클라이언트로 트래픽이 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트로 찾아가는 방식
• 장점
  • 로드밸런서의 부하 감소 : 응답 트래픽이 로드밸런서를 통하지 않아 네트워크 부하가 줄어든다.
  • 응답 속도 향상 : 클라이언트로 직접 응답하여 지연 시간 감소
• 동작 예시
  1. 클라이언트 → 로드밸런서(VIP) 요청
  2. 로드밸런서 → 서버로 트래픽 전달
  3. 서버 → 클라이언트로 직접 응답 (로드밸런서 경유 없음)
• 주의점 : 서버는 클라이언트의 요청을 받을 때, 원래의 VIP 주소로 응답을 보내야 하므로 특정 네트워크 설정(ARP 설정 등)이 필요

 

 

로드밸런서 종류

• 로드밸런서는 OSI 7 Layer 모델을 기준으로 트래픽을 분산하는 방식에 따라 구분된다.
  • 하위 계층(L2 ~ L4) : 단순하고 빠른 부하 분산 가능, 상대적으로 저렴
  • 상위 계층(L7) : 더 정교한 부하 분산 가능 but 복잡하고 비용이 높음
• 종류
  • L2(Data Link 계층) : MAC 주소를 바탕으로 Load Balancing
  • L3(Network 계층) : IP 주소를 바탕으로 Load Balancing
  • L4(Transport 계층) : Transport Layer(IP와 Port) Level 에서 Load Balancing
  • L7(Application 계층) : Application Layer(사용자의 Request) Level 에서 Load Balancing

계층	방식	부하 분산 기준	특징
L2 (데이터링크 계층)	MAC 기반	MAC 주소를 기반으로 트래픽을 분산	- 같은 네트워크 내에서 작동 (브로드캐스트 도메인 유지) - ARP 테이블을 활용
L3 (네트워크 계층)	IP 기반	IP 주소를 기준으로 부하 분산	- 라우터처럼 동작하며, 서브넷을 구분 가능
L4 (전송 계층)	TCP/UDP 기반	IP 주소 + 포트 정보를 활용	- 포트별 트래픽 분산 가능 - HTTP, HTTPS, FTP 등 다양한 프로토콜 지원
L7 (애플리케이션 계층)	콘텐츠 기반	사용자의 요청 내용 (URI, 헤더, 쿠키 등) 분석	- 가장 정교한 부하 분산 가능 - 웹 애플리케이션에서 자주 사용됨

 

• 보통 부하 분산에는 L4 로드밸런서와 L7 로드밸런서를 가장 많이 활용
  • L4 로드밸런서부터 포트 정보를 바탕으로 로드를 분산 가능하기 때문
  • 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드밸런서 이상을 사용해야 한다.
    
    
  • 같은 서버에서 여러 개의 서비스(프로그램)을 포트 별로 운영할 경우 → L4 이상 필요
  • 웹 어플리케이션에서 특정 URL에 따라 다른 서버로 요청을 보내고 싶은 경우 → L7 필요

 

L4 로드밸런서 VS. L7 로드밸런서

L4 Load Balancer (Transport Layer, 전송 계층)

• 특징
  • 네트워크 계층(L3 : IP, IPX)이나 전송 계층(L4 : TCP, UDP)의 정보를 바탕으로 로드 분산
  • 즉, IP 주소나 포트번호, MAC 주소, 전송 프로토콜(TCP/UDP) 등을 기준으로 트래픽을 특정 서버에 분배
  • 로드밸런싱의 기준점이 IP와 Port이기 때문에 TCP/UDP의 Header를 분석해 로드밸런싱에 활용하지는 않음
  • 단순히 패킷을 빠르게 전달하는 역할 수행
  • 프로토콜 헤더를 통해 로드밸런싱을 하기 보다는 해당 프로토콜 특성으로 인한 행동 제어
    EX. 3-way handshake 제어, 커넥션 해제 시점 조정, 세션 유지 시간 관리 등
• 장점
  • 빠른 처리 속도 : 데이터(패킷) 안을 들여다보지 않고 패킷 레벨에서만 로드를 분산하기 때문에 속도가 빠르고 효율이 높다.
  • 높은 보안성
    • 데이터 내용을 복호화할 필요가 없기 때문에 안전
    • 암호화된 트래픽(HTTPS)도 그대로 전달 가능
    • L7에 비해 보안 공격 면적이 작음
  • L7 로드밸런서보다 가격이 저렴, 자원 소비가 적다.
• 단점
  • 세밀한 트래픽 분배 불가
    • 패킷 내용을 살펴볼 수 없기 때문에 섬세한 라우팅이 불가능
    • url, 쿠키, 헤더 기반의 정교한 트래픽 분산 불가
  • 사용자의 IP가 수시로 바뀌는 경우라면 연속적인 서비스를 제공하기 어렵다.
    • ex. 모바일 네트워크(4G, 5G) 사용자의 경우 IP가 자주 변경되면 세션 유지가 어렵다.

 

L7 Load Balancer (Application Layer, 애플리케이션 계층)

• 특징
  • 애플리케이션 계층(HTTP, FTP, SMTP 등)에서 로드를 분산
  • 단순한  IP/Port 기반이 아니라 URL, 쿠키, HTTP 헤더 정보 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. 
    • 즉, packet의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분해하는 것이 가능하다.
    • 따라서 클라이언트의 요청을 보다 세분화해서 서버에 전달할 수 있다.
  • 패킷을 검사하여 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호 가능
  • DoS / DDoS 와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용
    
    
  • L4와 같이 IP와 Port를 사용하는 것은 같으나 Layer7 프로토콜을 사용해 사용자 정의 로드밸런싱을 실시하거나 Layer7 프로토콜 헤더를 조작/활용할 수 있다.
• 장점
  • 정교한 트래픽 분배 가능 : 상위 계층에서 로드를 분산하기 때문에 훨씬 섬세한 routing이 가능하다.
    • ex1. /images 요청은 서버 A, /videos 요청은 서버 B로 전달 가능
    • ex2. 사용자의 쿠키 값을 확인하여 VIP 고객의 요청을 특정 서버에 전달 가능
  • 캐싱 기능 제공
    • 정적인 컨텐츠 (ex. 이미지, CSS, JS)를 캐싱하여 서버 부하를 줄이고 응답 속도를 높일 수 있다.
  • 보안 강화
    • 비정상적인 트래픽을 사전에 필터링할 수 있어 서비스 안정성이 높다.
    • DDoS 공격 차단, 특정 요청 차단 가능
    • 웹 애플리케이션 방화벽(WAF)과 함께 사용하여 보안 위협에 대한 대응력 증가
• 단점
  • 처리 속도가 상대적으로 느리다.
    • 패킷의 내용을 복호화해야하기 때문에 L4보다 성능이 낮고, 더 높은 비용을 지불해야 한다.
    • SSL/TLS 트래픽을 처리할 경우 더 많은 CPU 자원 필요
  • L4 로드밸런서에 비해 비싸다 : 정교한 기능을 제공하는 만큼 L4보다 구축 비용이 높다.
  • 보안상의 위험 요소 존재
    
    • 클라이언트가 로드밸런서와 인증서를 공유해야하기 때문에, 공격자가 로드밸런서를 통해 클라이언트에 데이터에 접근할 보안상의 위험이 존재한다.

상위 레벨의 역할을 수행하는 스위치는 하위 역할의 프로토콜을 모두 이해해야 한다.
L7 또한 모든 레벨을 해석할 수 있지만, 각자의 역할에 집중된 처리로 불필요한 리소스 소모를 줄이고자 L4와 분리

 

 

로드밸런싱 알고리즘

클라이언트의 요청을 특정 서버에 분배하는 로드밸런싱 기법으로, 로드밸런서가 서버를 선택하는 기준
서버의 능력을 고려하여 분해해야 하기 때문에 서버의 상황에 맞춰 적절한 방법을 선택해야 한다.

1. 라운드 로빈 (Round Robin)
   • 특징
     • 서버에 들어온 요청을 순서대로 돌아가면서 배정하는 방식
     • 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 가지고 있다.
     • 모든 서버가 동일한 스펙을 가지고 있다고 가정하고, 요청을 고르게 분배
     • 서버와의 연결(세션)이 오래 지속되지 않거나, 각 서버의 부하가 비슷할 때 적합
   • 단점
     • 서버의 성능 차이가 있을 경우, 성능이 떨어지는 서버에 지나치게 많은 요청이 분배될 수 있다.
2. 가중 라운드로빈 방식 (Weighted Round Robin Method)  
   • 특징
     • 각 서버에 가중치를 부여하고, 가중치가 높은 서버에 클라이언트 요청을 우선적으로 분배하는 방식
     • 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 로드밸런싱 방식
     • 서버의 트래픽 처리 능력이나 성능 차이를 고려하여, 서버 자원의 차이에 맞게 트래픽을 분배
     • ex. 서버 A의 가중치가 5이고, 서버 B의 가중치가 2일 때, 서버 A에게 5개의 요청을 보내고 서버 B에게 2개의 요청을 할당
   • 단점
     • 서버의 성능이나 자원 상태가 급격하게 변할 경우, 정기적으로 가중치를 업데이트해야 하므로 관리가 필요
3. IP 해시 방식 (IP Hash Method)
   • 특징
     • 클라이언트의 IP 주소를 특정 서버로 매핑(해싱)하여 요청을 고정 배정하는 방식
     • 사용자의 IP를 해싱(Hashing)하여 부하를 분산하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장
     • 경로가 보장되며, 접속자 수가 많을 수록 분산 및 효율이 뛰어나다.
     • 사용자 고정 서버 배정을 보장하므로 세션 유지가 중요한 환경에 적합하다.
       ex. 사용자가 항상 같은 서버에 연결되어야 하는 환경, 로그인 상태 유지 등
   • 단점
     • IP 해시가 분배 기준이므로 많은 사용자가 동일한 서버에 연결되면 트래픽이 집중될 수 있다.
     • 특히 네트워크 환경에서 IP 주소가 자주 바뀌는 경우 (ex. 모바일 네트워크) 부하 분산에 문제가 될 수 있다.
4. 최소 연결 방식 (Least Connections) 
   • 특징
     • Request가 들어온 시점에 연결(세션) 상태가 가장 적은 서버에 우선적으로 트래픽을 할당
     • 서버의 부하가 동적으로 변화할 때 유용
     • 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우 (서버 간 트래픽 차이가 클 때) 적합
   • 단점
     • 세션 유지가 중요한 환경에서는 세션을 지속하는 서버가 자주 변경되어 문제가 될 수 있다.
     • 짧은 요청이 자주 들어오는 경우 최소 연결 방식을 과도하게 적용할 수 있다.
5. 최소 응답 시간 방식 (Least Response Time Method)
   • 특징
     • 서버의 현재 연결 상태와 응답시간(Response Time)을 모두 고려하여, 가장 짧은 응답 시간을 가진 서버로 트래픽을 분배하는 방식
     • 각 서버들의 가용한 리소스와 성능, 처리 중인 데이터 양 등이 상이할 경우 적합
     • 서버의 리소스, 성능, 처리 중인 데이터 양에 따라 다르게 적용되며, 성능이 중요한 서비스에 적합
     • 요청을 빠르게 처리할 수 있는 서버에 우선 분배되어 최적화된 성능을 제공
   • 단점
     
     • 응답 시간 측정에 추가적인 비용이 발생하며, 서버 상태를 실시간으로 확인해야 하므로 모니터링 관리가 필요
     • 응답 시간에 큰 차이가 나는 서버가 있으면, 효율적으로 트래픽을 분배하는데 한계가 있을 수 있다.

각 로드밸런싱 알고리즘은 서버 환경과 서비스 특성에 맞춰 선택하는 것이 중요하다.
예를 들어, 동적 트래픽 처리가 중요한 경우 최소 연결 방식이나 응답 시간 기준의 알고리즘을 사용하는 것이 좋은 반면,
세션 유지가 중요하거나 트래픽 집중을 피해야 한다면 IP 해시 방식이나 가중 라운드로빈 방식이 유리합니다.

 

 

DNS Round Robin (대용량 세션을 위한 로드밸런서)

DNS : 도메인 이름을 IP 주소로 변환하는 기술

개념

DNS Round Robin (DNS RR)은 일반적인 로드밸런서처럼 실시간으로 트래픽을 관리하지 않고, 도메인 이름을 여러 서버 IP 주소로 변환하여 트래픽을 분배하는 방법이다. DNS를 이용해 부하 분산을 수행하며, 별도의 로드밸런서 하드웨어나 소프트웨어를 사용하지 않는다.

대용량 서비스에서 대용량 트래픽을 장애 없이 처리하려면 부하 분산은 필수이다. (여러 대의 서버에 적절한 트래픽 분배 필요)
이때 몇 개의 노드만 있다면 DNS 라운드 로빈 방식이 합리적이다.

특징

• 간단한 부하 분산 : 하나의 도메인 이름을 여러 대의 서버 IP 주소로 변환하여 부하를 분산한다.
• 비용 효율성: DNS만으로 부하 분산이 가능하여 로드밸런서 장비나 소프트웨어를 도입할 필요가 없다.
• 적은 인프라 비용: 로드밸런서를 사용하는 것보다 비용이 적게 드는 경우가 많다.
  (로드밸런서 자체는 비용이 높고 불필요한 복잡함을 증가시킬 수 있기 때문)
• 상태 확인 부재: DNS 자체는 주기적인 상태 확인을 하지 않으므로, 서버 장애를 감지하거나 해당 서버를 빠르게 제외하는데 한계가 있다.

장점

1. 비용 절감: 추가적인 로드밸런서 장비나 소프트웨어를 사용하지 않고 DNS 만으로 트래픽 분산
2. 단순 구현: 서버를 추가하거나 변경할 때 DNS만 수정하면 되므로 구현이 단순
   DNS에서는 하나의 도메인 이름을 라운드 로빈 방식으로 여러 대의 서버 ip 주소 중에 하나로 변환한다면 이 것만으로 쉽게 부하 분산이 가능하다.
3. DNS RR은 지리적으로 N개의 서버가 멀리 떨어져 있어 실시간으로 Health Check (상태 확인)가 어렵거나, 적은 비용으로 구현이 필요할 때 사용한다.

 단점

1. 부하 분산의 균등성 부족
   • DNS는 서버의 부하를 줄이고 성능을 향상시키기 위해, 한 번 받은 IP를 일정 시간 동안 결과를 캐싱 (재사용)
   • → 모든 요청이 고르게 분배되지 않을 수 있다. (일부 서버에 트래픽이 집중될 가능성이 있다.)
   • DNS는 요청이 들어올 때마다 순차적으로 IP를 제공하지만, 사용자의 네트워크 환경이나 DNS 캐싱으로 인해 특정 서버에 더 많은 요청이 몰릴 수 있다.
2. 장애 감지 부족 : 서버 장애가 발생해도 DNS에서 해당 서버를 즉시 제거할 수 없기 때문에, 장애 발생 시 서비스 중단이 발생할 수 있다.
3. 상태 확인 미지원 : DNS는 주기적인 상태 확인(Health Check)을 수행하지 않으므로, 서버가 장애 상태에 있어도 트래픽을 계속 보낼 수 있습니다.

 

 

🚀 DNS Round Robin 부하 분산 방식

1. DNS 요청 발생
   • 사용자가 example.com에 접속하려고 하면, 브라우저는 해당 도메인의 IP 주소를 알아내기 위해 DNS 서버에 요청을 보냅니다.
2. DNS 서버 응답 (IP 주소 제공)
   • DNS 서버에는 example.com에 대한 여러 개의 IP 주소(서버 목록)가 등록되어 있습니다.
   • 예를 들어, example.com이 아래와 같은 여러 서버를 갖고 있다고 가정합니다.
   • example.com → 192.168.1.1 example.com → 192.168.1.2 example.com → 192.168.1.3
3. 라운드 로빈 방식으로 IP 선택
   • DNS 서버는 매 요청마다 등록된 IP 주소 중 하나를 순차적으로 제공합니다.
   • 요청 1 → 192.168.1.1 반환
   • 요청 2 → 192.168.1.2 반환
   • 요청 3 → 192.168.1.3 반환
   • 요청 4 → 다시 192.168.1.1 반환 (반복)
4. 사용자의 브라우저가 해당 IP로 접속
   • DNS 서버가 제공한 IP 주소를 기반으로 사용자의 브라우저는 해당 서버로 접속하여 웹 페이지를 요청합니다.
   • 여러 사용자의 요청이 자동으로 여러 서버로 분산되므로 부하가 줄어듭니다.

 

🔥 DNS Round Robin vs. 일반적인 로드밸런서 차이점

비교 항목 DNS Round Robin 일반적인 로드밸런서 (예: AWS ELB)

부하 분산 방식	DNS 응답 시 여러 IP 중 하나를 반환하여 트래픽을 분산	실시간으로 요청을 분석하고 부하를 고려하여 트래픽을 분배
Health Check	없음 ❌ (서버가 다운돼도 트래픽을 계속 보냄)	있음 ✅ (장애 감지 후 비정상 서버 제외)
트래픽 흐름	클라이언트가 직접 서버에 연결	로드밸런서가 중간에서 요청을 관리
캐싱 문제	클라이언트의 DNS 캐싱으로 인해 부하 분산이 불균형할 수 있음	부하 상태를 실시간으로 반영
장점	간단하고 비용이 저렴함 💰	정밀한 부하 분산 가능 🎯
단점	장애 감지가 어렵고 균등 분배가 어려움 ⚠️	추가적인 비용과 설정이 필요함 💲

 

✅ DNS Round Robin을 보완하는 방법

1. Low TTL(Time-To-Live) 설정
   • TTL 값을 짧게 설정하면 클라이언트와 ISP가 DNS 정보를 자주 갱신하여 트래픽 불균형을 줄일 수 있음.
   • 하지만 TTL이 너무 짧으면 DNS 쿼리가 증가하여 성능에 영향을 줄 수 있음.
2. Health Check가 가능한 DNS 서비스 사용
   • AWS Route 53과 같은 DNS 서비스는 상태 확인(Health Check)을 수행하여 장애가 발생한 서버를 제외하고 살아있는 서버로만 트래픽을 분배 가능.
   • 단순한 DNS RR보다 안정적인 부하 분산이 가능함.
3. GSLB(Global Server Load Balancing) 도입
   • 위치 기반 트래픽 분배를 지원하는 **글로벌 로드밸런서(GSLB)**를 사용하면, 사용자의 지리적 위치에 따라 가장 가까운 서버로 연결 가능.
   • 예: AWS Global Accelerator, Cloudflare Load Balancer.

 

✨ 결론

1. DNS Round Robin은 간단한 부하 분산 기법으로, 여러 서버에 대한 트래픽을 분산하는 역할을 합니다.
2. 하지만 일반적인 로드밸런서처럼 실시간 부하 분산이나 장애 감지를 하지 않으므로, 중요한 서비스에서는 단독으로 사용하기 어렵습니다.
3. 이를 보완하려면 TTL 값을 조정하거나, Health Check가 가능한 DNS 서비스(AWS Route 53 등)를 사용하는 것이 좋습니다. 🚀

 

 

AWS 로드밸런서 유형

1. ELB (Elastic Load Balancer)

개념

• AWS에서 제공하는 로드밸런서를 통칭하는 용어
• 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 다양한 대상을 대상으로 수신된 트래픽을 자동으로 분산

특징

• ELB의 종류로 ALB, NLB, GLB, CLB 등이 있으며, 각기 다른 기능과 특성에 따라 사용
• → 확장성과 유연성: 다양한 요구 사항과 환경에 맞게 확장할 수 있는 유연성 제공

 

2. ALB (Application Load Balancer)

개념

ALB는 HTTP 헤더, SSL 세션 ID 등의 요청 콘텐츠를 기반으로 트래픽을 리다이렉션하는 L7 기반 로드밸런서

특징

• L7 로드밸런싱 : 애플리케이션 계층에서 로드밸런싱을 제공(지원)하며, HTTP/HTTPS 트래픽을 처리하는 데 적합
• SSL 적용 가능 : HTTPS 트래픽에 SSL 인증서를 적용할 수 있다.
• 다양한 전송 규칙 : HTTP 요청에 따라 다양한 규칙을 설정하여 트래픽을 분배
• 느린 성능 : L4 기반인 NLB에 비해 성능이 상대적으로 느릴 수 있으나, 세밀한 요청 규칙을 처리할 수 있는 장점이 있다.

 

3. NLB (Network Load Balancer)

개념

NLB는 네트워크 계층에서 트래픽을 (최적으로) 리다이렉션하며, IP 주소 및 기타 네트워크 정보를 기반으로 로드밸런싱을 수행

특징

• L4 로드밸런싱 : L4 기반 로드 밸런서 지원 하며, 전송 계층에서 TCP/UDP 프로토콜 기반으로 트래픽을 분배 및 전송할 타겟을 지정할 수 있다.
• 고성능 : 초당 수백만 건의 요청을 처리할 수 있어 실시간 스트리밍, 화상 회의, 채팅 애플리케이션과 같이 고성능이 요구되는 환경에서 유용
• 고정 IP : 각 서버에 고정 IP를 할당할 수 있어, 특정 소스에서 발생하는 트래픽을 추적할 수 있다.
• 낮은 레이턴시 : 성능이 매우 뛰어나며, 빠른 응답 속도가 요구되는 서비스에 적합

 

4. GLB (Global Load Balancer)

개념

글로벌 트래픽 분배를 위해 사용하는 로드밸런서입니다. AWS의 여러 리전에서 제공되는 서버에 트래픽을 분배하여, 지리적으로 분산된 리소스에서 효율적인 부하 분산 지원

특징

• 지리적 분산: 여러 리전에서 분산된 서버에 트래픽을 분배하여, 글로벌 서비스를 지원하는 데 유용
• 고가용성 및 장애 복구: 리전 간 트래픽 분배와 장애 복구를 자동으로 처리하여, 글로벌 서비스를 안정적으로 운영할 수 있다.

 

5. CLB (Classic Load Balancer)

개념

이전 버전의 AWS 로드밸런서로, 전통적인 L4와 L7 기반 로드밸런싱을 모두 지원하는 방식입니다. 현재는 ALB와 NLB로 대체되고 있지만, 여전히 일부 환경에서 사용되고 있다.

특징

• 구식 로드밸런서: L4 및 L7 로드밸런싱 기능을 모두 제공하지만, ALB와 NLB가 출시되면서 사용이 줄어듦
• 호환성: AWS의 초기 로드밸런서로, 레거시 시스템과의 호환성을 제공할 수 있다.

 

ELB는 AWS에서 제공하는 전체 로드밸런서 서비스를 지칭하는 이름이며, ALB와 NLB는 / ELB의 하위 카테고리로 구체적인 기능에 맞춰 구분된다. 현재 ELB = ALB/CLB로 언급되기도 합니다.
ALB가 추가로 개발되면서 ELB는 CLB(Classic Load Balancer)로 명칭이 변경되었다.

용어적으로는 ALB=ELB=CLB로 이해하면 되며 현재는 NLB(Network Load Balancer)의 추가로 기능이 더욱 강화되었다. 보통 ELB라 하면 AWS의 로드 밸런싱 서비스 전체를 통틀어 칭하는 말이기도 하다.

ALB는 애플리케이션 계층의 특성을 활용하여 HTTP 요청을 더 세부적으로 분배할 수 있지만, 성능 측면에서 NLB보다는 느릴 수 있습니다.
NLB는 고성능 트래픽 처리가 요구되는 환경에 적합하여, 낮은 레이턴시와 빠른 처리 능력이 중요한 서비스에 최적입니다.

 

 

 

REFERENCE

https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0_%EC%8A%A4%ED%8A%B8%EB%A6%BC

데이터 스트림 - 위키백과, 우리 모두의 백과사전

https://github.com/jmxx219/CS-Study/blob/main/network/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C.md

CS-Study/network/로드밸런서.md at main · jmxx219/CS-Study