네트워크 인프라 15. 로드 밸런서 (Load Balancer)

로드 밸런서 (Load Balancer / L4 스위치)

: 동일한 서비스를 하는 다수의 서버를 실행하면서 사용자의 요청을 받아 처리해 부하를 분산 시키는 서버

: 서비스를 위한 VIP (Virtual IP / 가상 아이피) 하나로 사용자의 모든 요청을 처리

: 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 요청을 분산

 

- SLB (Server Load Balancer)

: 서버 부하 분산

 

- FWLB (FireWall Load Balancer)

: 방화벽 부하 분산

: 이중화된 방화벽의 경우 비대칭 동작으로 인해 응답 패킷을 비정상적인 패킷으로 간주하여 폐기하는 버그가 발생할 수 있음

: FWLB를 이용하면 세션을 인식하고 일정한 규칙으로 세션을 분산시켜 한 번 방화벽을 지나갔던 세션이 같은 방화벽을 거치도록 트래픽을 분산

: 방화벽끼리 세션 테이블을 동기화 하거나 방화벽에서 첫 패킷이 SYN이 아니어도 허용하는 기능을 통해 기존 세션 테이블에 없던 트래픽이 들어오더라고 처리할 수 있도록 설정 필요 (장애 방지를 위함)

 

 

 

 

 

부하 분산 방법

: LACP의 경우 두 개 이상의 인터페이스를 하나의 논리 인터페이스로 묶어 회선의 부하를 부산 시킴

: 로드 밸런서는 부하를 다수의 장치에 분산 시키기 위해 VIP를 RIP (Real IP, 각 서버들의 실제 IP)와 바인딩 하여 VIP로 들어온 요청을 RIP로 변환하여 서버에서 처리되도록 함

 

- 로드 밸런서에서의 부하 분산 방법

: 부하 분산 그룹을 지정하여 목적이나 프로토콜에 따라 요청을 적절한 서버로 보낼 수 있음

: 부하 분산 그룹은 IP 뿐만 아니라 포트 번호까지 지정 (L4 스위치)

: 애플리케이션 계층 정보까지 확인하여 처리하는 경우 L7 스위치라고함 

 

 

 

 

 

헬스 체크 (Health Check)

: 로드 밸런서에서 서버의 서비스 정상 여부를 판단하는 기능

 

- ICMP

: VIP에 바인딩된 서버에 대해 ICMP로 헬스체크 수행

: 서버가 살아있는 여부만 확인 가능하기 때문에 잘 사용하지 않음

 

- TCP 서비스 포트

: 가장 기본 적인 헬스 체크 방법

: RIP의 서비스 포트로 SYN을 보내고 해당 RIP를 가진 서버로 부터 SYN, ACK를 받으면  ACK로 응답하고 FIN을 보내 헬스체크를 종료 (4-Way Handshake)

 

- TCP Half Open

: 헬스체크로 인한 부하를 줄이기 위해 SYN을 보내고 SYN, ACK를 받고 나서 RST를 보내 세션을 끊는 방법

 

- HTTP 상태코드

: 웹 서비스에 대해 3방향 핸드셰이크로 확인하고 나서 HTTP를 요청해 정상적인 상태 코드를 응답하는지 확인

 

- 콘텐츠 확인

: 로드 밸런서에서 서버로 콘텐츠를 요청하고 응답받은 내용을 확인하여 지정한 콘텐츠가 정상적으로 왔는지 확인

: 보통은 웹 페이지를 호출해 사전에 지정한 문자열이 웹 페이지니 내에 포함되어 있는지 체크

: 서버의 백엔드 (WAS, DB)의 상태도 같이 체크할 수 있음

: 에러 코드인 문자열에 대해서도 정상으로 판단할 수 있으므로 정상 코드 값까지 체크하거나 문자열 자체를 특정 ㅜㅁㄴ자열로 지정해 정상일 때만 체크하도록 설정 필요

 

 

 

 

 

헬스 체크의 시간 관련 옵션

- 주기 (Interval)

: 로드 밸런서에서 서버로 패킷을 보내는 주기

 

- 응답 시간 (Response)

: 로드 밸런서에서 서버로 패킷을 보내고 응답을 기다리는 시간

 

- 시도 횟수 (Retries)

: 로드 밸런서에서 헬스 체크 실패 시 최대 시도 횟수

 

- 타임아웃 (Timeout)

: 로드 밸런서에서 헬스 체크 실패 시 최대 대기 시간

: 헬스체크를 n초 간격을 보냈을 때 n+@초안에 한 번이라도 성공하지 못했을때 실패처리하는 시간

: 3초 간격일때 10초의 타임아웃아면 3번 보내고 3번째 체크에서 1초 후 서버 다운으로 처리

 

- 서비스 다운 시의 주기 (Dead Interval)

: 서비스 다운 시에 대한 헬스 체크 주기

: 서비스가 죽은 상태에서 헬스 체크

 

 

 

 

 

 

부하 분산 알고리즘

: 로드 밸런서에서 부하를 분산할때 기준이 되는 알고리즘

 

- 라운드 로빈

: 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산

: 모든 장비에 순차적으로 분산 하므로 장비당 총 누적 세션 수는 동일

 

- 최소 접속 방식 (Least Connection)

: 서버가 가진 세션 부하를 확인해 그것에 맞게 부하를 분산

: 로드 밸런서에서 서비스 요청을 장비로 보내줄때마다 생성되는 세션 테이블을 통해 부하를 확인

: 현재 세션이 가장 적게 연결된 장비로 요청을 전송

 

- 해시

: 서버의 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속하도록 함

: 해시 알고리즘을 통해 얻은 결과값으로 어떤 장비로 부하를 분산할지 결정

: 알고리즘 계산에 사용되는 출발지 및 목적지의 IP 주소와 포트를 지정하여 설정 가능

 

- 해시 + 최소 접속 방식

: Sticky 옵션을 주어 한 번 접속한 커넥션을 지속적으로 유지

: 처음 들어온 서비스 요청을 세션 테이블에 두고 같은 요청이 들어오면 같은 장비로 분산해 세션을 유지

: 세션 타임아웃 이후에는 장비가 달라질 수 있음

 

- 알고리즘의 선택

: 라운드 로빈이나 최소 접속 방식은 비슷한 비율로 부하를 분산 시킬 수 있지만 같은 세션에 대해 처음 요청을 처리한 서버와 다음 요청을 처리한 서버가 다를 수 있어 세션을 유지해야하는 서비스의 경우 문제가 발생할 수 있음

: 해시 방식은 항상 동일한 장비에 서비스를 분산하므로 세션을 유지해야하는 서비스에 적합

 

 

 

 

 

 

로드 밸런서 구성 방식

- 원암 (One-Arm)

: 로드 밸런서가 스위치 옆에 연결되는 구성

: 부하 분산을 수행하는 트래픽에 대해서만  로드 밸런서를 경유하는 구성

: 트래픽은 로드 밸런서에 등록된 서비스 IP로의 트래픽인지로 구분

: 로드 밸런서에 대한 부하와 스위치와 로드 밸런서간 대역폭을 최소화 할 수 있음

: 대역폭이 부족한 경우 스위치와 로드 밸런서간 대역폭만 늘리면 되므로 확장에 유리함

: 로드 밸런서의 장애 영향도도 줄일 수 있음

 

- 인라인 (Inline)

: 서버로 가능 경로 상에 로드 밸런서가 위치한 구성

: 모든 트래픽이 로드 밸런서를 경유하는 구성

: 4계층 이상의 데이터를 처리하기 때문에 처리 가능한 용량이 L3 스위치 보다 적으며 더 높은 성능이 필요

: 로드 밸런싱 성능과 패킷 스루풋 성능을 구별해 디자인 해야함 

 

 

 

 

 

 

로드 밸런서 동작 모드

- 트랜스 패런트 (Trans-Parent) 또는 브릿지 (Bridge) / L2 구조

: VIP와 실제 서버가 동일한 네트워크를 사용하여 로드 밸런서가 2계층 스위치 처럼 동작하는 구성

 

: 기존에 사용하던 네트워크 대역을 그대로 사용하므로 기존 망의 트래픽 흐름에 영향 없이 손쉽게 로드 밸런서를 구성할 수 있음

: 부하 분산을 수행할 서비스에 대해서만 4계층 이상의 데이터를 처리하고, 그 외 서비스의 경우 스위칭 기능만 수행

: 원암과 인라인 구성에서 사용 가능

 

- Routed

: 로드 밸런서가 라우팅 역할을 수행하는 모드

: 로드 밸런서를 기준으로 Client Side와 Server Side가 서로 다른 네트워크로 분리된 구성

: 로드 밸런서는 Client Side와 Server Side 네트워크를 라우팅으로 연결함

: 원암과 인라인 구성에서 사용 가능

 

- DSR (Direct Server Return)

: 사용자의 요청이 로드 밸런서를 통해 서버로 전송되고 서버에서 사용자에게 직접 응답 하는 모드

: 로드 밸런서는 요청에 대한 패킷만 처리하므로 로드 밸런서 전체의 부하가 감소됨

: 로드 밸런서에서 서버까지의 통신이 L2 통신인지 L3 통신인지에 따라 L2 DSR 모드와 L3 DSR 모드로 구분

: 스트리밍 서비스와 같이 응답 트래픽이 큰 경우 유용하나, 문제 발생 시 문제 확인이 어려움

: 서버에서도 추가 설정이 필요 (응답 시 출발지 주소를 VIP로 설정하기 위한 루프백 인터페이스 설정  및 ARP MAC 테이블 갱신과 브로드캐스트 방지를 위한 서버 커널 파라미터 수정)

: 원암에서만 사용 가능

 

※ ARP 관련 참조: https://2mukee.tistory.com/437

 

 

 

 

 

 

원암 구성의 로드 밸런서 구성 시 유의 사항

- 서비스를 위한 VIP와 서버의 네트워크 대역이 동일한 경우

: 응답 시 로드 밸런서를 거치지 않고 사용자에게 바로 응답하게 되고 클라이언트 측에서는 응답한 IP가 요청한 IP와 달라 패킷을 폐기 처분 할 수 있음

 

- 해결 방법 (3가지)

: 서버에서 게이트웨이를 로드 밸런서로 설정하여 외부에서의 요청을 항상 로드 밸런서에서 처리할 수 있도록 설정

: 혹은 로드 밸런서에서 사용자 요청에 대해 Source NAT를 하여 응답 패킷을 처리할 수 있도록 설정 (서버에서의 사용자 구분을 위해 HTTP 헤더의 X-Forwarded-For를 통해 사용자 IP를 확인)

: 혹은 DSR 모드를 사용

 

- 동일 네트워크 내에서의 VIP 호출

: 동일 네트워크에 있는 서버에서 로드 밸런서를 통해 요청 했을 때 요청을 받은 서버에서 동일 네트워크 임을 확인하고 요청한 서버로 응답을 바로 보내는 문제

 

- 해결 방법

: 로드 밸런서에서 Source NAT를 하거나 DSR 모드를 사용

: 혹은 로드 밸런서와 서버를 물리적으로 연결하여 모든 요청과 응답이 로드 밸런서를 지나도록 구성

 

 

 

 

 

HAProxy

: 기존 하드웨어 로드 밸런서의 역할을 일반 서버에서 직접 수행할 수 있도록 해주는 오픈 소스 SW 로드 밸런서

: 하드웨어 로드 밸런서에서 제공하는 기능을 소프트웨어로 제공하므로 일종의 NFV (Network Function Virtualization)라 볼 수 있음

: 추가 적인 서비스 모듈과 도구, 지원 서비스를 포함한 엔터프라이즈 버전과 HAProxy를 적용한 하드웨어 어플라이언스인 ALOHA 로드 밸런서도 제공

 

 - 장점

: 간단한 설정 만으로 바로 사용할 수 있어 신속한 로드 밸런싱이 가능

: SW 형태이기 때문에 가상화나 클라우드 환경에서 사용하기 용이

: 쿠버네티스의 인그레스 컨트롤러 역할도 가능

 

 

 

 

 

 

 

 

Reference

IT 엔지니어를 위한 네트워크 입문 | 고재성 - 교보문고