ocean

4-3. Load Balancer 본문

현대오토에버 모빌리티 SW 스쿨 - 클라우드/Network

4-3. Load Balancer

Leyeun_000 2026. 4. 13. 16:43

목차

1. 4계층 장비

2. LoadBalancer

3. L4 Loadbalancing & L7 LoadBalancing

4. L4 Switch를 이용한 부하 분산

5. ADC (L7 LoadBalancing)

6. Health Check

7. 부하 분산 알고리즘

8. 로드 밸런서 구성 방식

9. 시스템 확장 방식 🌟

4계층 장비

  • 통신 전반에 대한 정보(통신의 방향성이나 순서 등)를 Session Table에 담아 관리하고 이를 바탕으로 동작
  • 세션 장비에서 고려할 요소
    • 세션 테이블 : 세션 장비는 세션 테이블을 기반으로 동작
    • symmetric 경로 요구 : Inbound와 Outbound 경로가 일치해야 함.
    • 정보 변경 : L7 LoadBalancer는 애플리케이션 프로토콜 정보도 변경함.

LoadBalancer

  • 서버나 장비의 부하를 분산하기 위해 사용하는 장비
    ex. 웹 서버의 부하 분산
  • 사용자 천 명의 요청을 처리해주는 서버보다 5천 명의 요청을 동시에 처리하는 서버의 비용은 5배가 아니라 훨씬 많이 소모됨
    → 천 명의 요청을 처리해주는 서버 5개를 가지고 해결하는 것이 효율적임.
  • LoadBalancer는 웹 애플리케이션 뿐 아니라 FWLB(FireWall LoadBalancing)나 VPNLB(VPN LoadBalancing)와 같이 다양한 서비스를 위해 사용할 수 있음.
  • 종류
    • 서버형 LoadBalancer
    • SW형태의 LoadBalancer (ex. nginx)
    • 스위치형 LoadBalancer 등

L4 LoadBalancing & L7 LoadBalancing

  • L4 LoadBalancing
    • 일반적인 로드밸런서가 수행하는 동작
    • TCP, UDP 정보(L4)만 가지고 로드밸런싱 수행
  • L7 LoadBalancing
    • HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보(헤더 정보나 URI 등)를 기반으로 로드밸런싱을 수행
    • 이런 장비를 ADC(Application Delivery Controller)라고 부르며 Proxy 역할을 수행
    • squid나 nginx에서 수행하는 Reverse Proxy와 유사한 기능

L4 Switch를 이용한 부하 분산

  • L4 Switch
    • 4계층에서 동작해서 LoadBalancing 기능이 있는 스위치
    • 내부 동작 방식은 L4 LoadBalancer지만 외형은 스위치처럼 여러 개의 포트를 가지고 있음
    • L4 스위치는 부하 분산 및 성능 최적화 & 리다이렉션 기능을 제공
  • Virtual Server, Virtual IP, Real Server, Real IP를 설정해야 함.
    • Virtual Server : 사용자가 바라보는 서비스 (Load Balancer)
    • Virtual IP : Virtual Server의 IP. Public IP
    • Real Server : 실제 서비스를 수행하는 서버.
    • Real IP : Real Server의 IP. Private IP
  • L4 Switch는 Virtual IP를 Real IP로 변경해주는 역할을 수행
    • 사용자는 L4 Switch의 Virtual IP를 목적지로 서비스를 요청하고 L4 Switch가 Virtual IP에서 Real IP로 목적지를 다시 변경해 전송
      → 이 과정에서 부하를 어떤 방식으로 분산할지 결정할 수 있음.

ADC (L7 LoadBalancing)

  • 애플리케이션의 프로토콜의 헤더와 내용을 이해하고 동작하므로 다양한 부하 분산이나 정보 수정 그리고 정보 필터링 가능 
  • ADC는 이런 상세한 동작을 위해 Proxy로 동작

  • 기능
    • L4 스위치의 기능
    • 로드밸런싱 기능
    • FailOver(장애 극복 가능)
    • Redirection
    • 애플리케이션 프로토콜을 이해하고 최적화하는 기능
    • 캐싱, 압축, 콘텐츠 변환 및 재작성, 인코딩 변환 등
    • 플러그인 형태로 보안 강화 기능을 추가로 제공해 WAF(Web Application Firewall) 기능이나 HTML, XMl 검증과 변환을 수행할 수 있음

Health Check

  • 개요
    • 서비스 그룹에 있는 각 서버가 살아있는지 확인하는 작업
    • 정상적인 서비스 쪽으로만 부하를 분산하고 비정상적인 서버는 서비스 그룹에서 제외해서 트래픽을 보내지 않아야 함.
    • 비정상적인 서버라고 하더라도 헬스 체크를 수행해서 정상으로 확인되면 다시 서비스 그룹에 포함시켜야 함.
  • 헬스 체크 방식 (아래로 갈수록 강력한 방식. 단, 약한 것일수록 트래픽 줄일 수 있음)
    • ICMP(Internet Control Message Protocol)
      • Virtual IP에 연결된 Real Server에 ICMP(Load Balancer가 ping을 보내는 방식)로 헬스 체크를 수행하는 방법.
      • 컴퓨터가 살아있는지 여부만 확인하는 방식. 잘 사용X.
    • TCP 서비스 포트 확인
      • 가장 기본적인 헬스 체크 방법.
      • TCP 연결(3-way handshake)이 가능한지 아닌지 확인하는 방식
      • LoadBalancer에 설정된 서버의 서비스 포트를 확인하는 것
        • 로드밸런서에서 서버의 서비스 포트 2000번을 등록했다면 로드밸런서에서 Real IP:2000번 포트로 SYN을 전송하고 Real IP를 가진 서버(Real Server)에서 SYN, ACK로 응답. 로드밸런서에서는 이 응답을 받고 FIN을 보내 헬스 체크를 종료
        • 실제 서비스의 포트(80이나 443)을 확인하지 않고 헬스 체크용 포트를 지정해서 헬스 체크 수행
          • 부하를 줄여줄 수 있고 보안에도 좋다.
    • TCP 서비스 포트 (Half Open) 확인
      • 일반적인 TCP 서비스 포트와 동일하게 동작하지만 FIN 대신에 RST를 보내서 세션을 끊어버리는 방식
        • 이렇게 하면 트래픽이 줄어서 좀 더 좋다
    • HTTP 상태 코드
      • 웹 서버가 살아있는지 아닌지 확인하는 방식
      • 웹 서비스를 할 때 서비스 포트까지는 TCP로 정상적으로 열리지만 웹 서비스에 대한 응답을 정상적으로 해주지 못하는 경우 O.
      • 로드 밸런서가 서버로 3-way handshake를 거치고 나서 HTTP를 다시 요청해 정상적인 상태 코드(응답 코드: 200, OK)를 응답하는지 여부를 체크해서 헬스 체크를 수행
    • 콘텐츠 확인
      • 웹 서버 내용을 가져오는지 못하는지 확인하는 방식. 가장 강력
      • 특정 웹 페이지를 호출해서 사전에 지정한 문자열이 해당 웹 페이지 내에 포함되어 있는지 체크하는 것
      • 앞단의 서버가 백엔드로 요청을 하고 백엔드에서 정상적인 결과 값으로 웹 페이지에 특정 문자열을 출력하게 해서 백엔드 상태까지 체크하는 방식
  • 헬스 체크 주기와 타이머
    • 관련된 타이머 값
      • 주기(Interval) : 로드밸런서에서 서버로 헬스 체크 패킷을 보내는 주기
      • 응답 시간(Response) : 로드밸런서에서 서버로 헬스 체크 패킷을 보내고 응답을 기다리는 시간
      • 시도 횟수(Retries) : 최대 시도 횟수
      • 타임아웃(Timeout) : 로드밸런서에서 헬스 체크 실패 시 최대 대기 시간으로 헬스 체크 패킷을 서버로 전송한 후 이 시간 내에 성공하지 못하면 해당 서버는 다운으로 판단
      • 서비스 다운 시의 주기(Dead Interval) : 서비스가 죽은 상태에서 헬스 체크 주기를 별도로 더 늘릴 때 사용

부하 분산 알고리즘

Round Robin

  • 순차적으로 돌아가면서 트래픽을 분산
    → 모든 장비의 총 누적 세션 수는 같아짐

Least Connection (최소 접속 방식)

  • 서버가 가진 세션 부하를 확인해서 그것에 맞게 부하를 분산하는 방식
  • 로드밸런서에서는 서비스 요청을 각 장비로 보내줄 때마다 세션 테이블이 생성되므로 각 장비에 연결된 현재 세션 수를 알 수 있음
  • 장비의 세션 수를 확인해서 현재 세션이 가장 적게 연결된 장비로 서비스 요청을 보내는 방식
  • 각 장비에서 처리되는 활성화 세션 수가 비슷하게 분산되면서 부하를 분산

Hash

  • 서버의 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속하도록 하기 위해 사용하는 부하 분산 방식
  • 해시 알고리즘을 이용해서 얻은 결과 값으로 어떤 장비로 부하를 분산할지 결정
    → 항상 동일한 결과 값을 가지고 서비스를 분산할 수 있음
  • 장점
    • 항상 동일한 장비로 서비스가 분산되므로 세션을 유지해야 하는 서비스에 적합
    • Round Robin이나 Least Connection : 부하를 비교적 비슷한 비율로 분산시킬 수 있다는 장점이 있지만 동일한 출발지에서 로드밸런서를 거친 서비스 요청이 처음에 분산된 서버와 그 다음 요청이 분산된 서버가 달라질 수 있어 각 서버에서 세션을 유지해야 하는 서비스는 정상적으로 서비스되지 않음.
  • 단점
    • 알고리즘의 결과값이 특정한 값으로 치우치면 부하 분산 비율이 한쪽으로 치우칠 수 있음
  • 장바구니 문제나 A/B 테스트를 할 때 이 방식을 이용

로드 밸런서 구성 방식

  • 서버로 가는 트래픽이 모두 로드 밸런서를 경유하는지 경유하지 않아도 되는지에 대한 트래픽 흐름으로 구분
    • 원암 구성 : 외부에서 보내는 트래픽만 LB를 거치고, 내부 트래픽은 LB를 거치지 않음.
    • 인라인 구성 : 모든 트래픽이 LB를 거침.

시스템 확장 방법

  • 데이터 양이 늘거나 CPU나 메모리 사용량이 늘어 서버 하나로 서비스가 불가능해지면 시스템을 확장
  • 스케일업 🌟
    • 용량을 키우는 방법.
      : 기존 시스템에 CPU, 메모리 ,디스크 같은 내부 컴포넌트 용량을 키우거나 새로 더 큰 용량의 시스템을 구매해서 서비스를 옮기는 방법.
    • 파일 저장소인 디스크는 어느 정도까지는 쉽게 확장이 가능하지만 CPU나 메모리는 확장하기 쉽지 않음
    • 스케일 업은 확장을 미리 고려해 시스템을 구축하면 초기 비용이 커지고 서비스에 적합한 시스템을 구매하면 확장이 필요할 때 기존 시스템을 버리고 더 큰 시스템을 새로 구매해야 하므로 기존 시스템 비용이 낭비되는 문제가 있음
      → 클라우드를 쓰는 이유
    • 스케일 업은 필요한 용량만큼 시스템을 늘리는데 비용이 기하급수적으로 증가하는 문제가 있음.
      저가형 CPU보다 성능이 2배 우수한 CPU는 10배 이상의 비용이 많이 들 수 있음.
      → 일정 시점이 지나면 비용 대비 성능의 증가폭이 떨어짐.
  • 스케일 아웃 🌟
    • 같은 용량의 시스템(실제로는 용량 달라도 됨)을 여러 대 배치
    • 사용자 천 명의 요청을 처리하는 시스템이 한 대 구동 된다면 5천 명을 위해서 5대의 시스템을 병렬로 구성해서 운영하는 방법
    • 스케일 아웃을 위해 새로 시스템 설계를 하거나 분산을 위한 별도의 프로세스를 운영하거나 Load Balancer와 같이 부하를 분산해주는 별도의 외부 시스템이 필요

'현대오토에버 모빌리티 SW 스쿨 - 클라우드 > Network' 카테고리의 다른 글

Etc. 네트워크 실습 - GNS3 (2) GNS3 기본 사용법  (0) 2026.04.13
Etc. 네트워크 실습 - GNS3 (1) 실습 환경 생성  (1) 2026.04.13
4-2. Router & L3 Switch  (1) 2026.02.06
4-1. Switch(2) - VLAN  (0) 2026.02.04
4-1. Switch(1)  (0) 2026.02.02
'현대오토에버 모빌리티 SW 스쿨 - 클라우드/Network' Related Articles more