로드밸런서(Load Balancer) - Part 1 (부하분산이란)
Today Keys : 로드밸런서, L4, L7, 부하분산, Load Balancer, Load Balancing, 가용성, 이중화, SLB, FWLB, LB
본 포스팅은 'IT 엔지니어를 위한 네트워크 입문' [길벗] 서적에 포함된 '12. 로드밸런서'의 내용 중 소개 및 12.1, 12.2장의 내용입니다
12.1. 부하 분산이란?
서비스 규모가 커지면 물리나 가상 서버 한 대로는 모든 서비스를 수용할 수 없게 됩니다. 서버 한 대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션，운영체제，하드웨어에 장애가 발생했을 때，정상적인 서비스를 제공할 수 없습니 다. 서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데 각 서버 ip 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 ip로 서비스를 요청할지 결정해야 합니 다. 사용자에 따라 호출하는 서버의 ip가 다르면 특정 서버에 장애가 발생했을 때，전체 사용자에 게 영향을 미치지 않아 장애 범위는 줄어들겠지만 여전히 부분적으로 서비스 장애가 발생합니다. 그림 u-i은 이런 서비스 장애의 예시입니다.
이런 문제점을 해결하기 위해 L4나 L7 스위치라는 로드 밸런서(Load Balancer)를 사용합니다. 로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로 드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산합니다. 대규모 서비스 제공을 위해 이런 로드 밸런서는 필수 서비스입니다. 로드 밸런서에서는 서비스를 위한 가 상 IP(VIP)를 하나 제공하고 사용자는 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근합니다. 이 외에도 로드 밸런서는 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산하므로 서버에서 장애가 발생하더라도 기존 요청을 분산하여 다른 서버에서 서비스를 제공할 수 있습니다.
참고
FWLB
서버에 대한 부하 분산뿐만 아니라 방화벽을 액티브-액티브로 구성하기 위해 로드 밸런서를 사용하기도 합니다. 서버 부하 분산을 SLB(Server Load Balancing), 방화벽 부하 분산을 FWLB(FireWall Load Balancing)라고 합니다.
방화벽은 자신을 통과한 패킷에 대해 세션을 관리하는 테이블을 갖고 있습니다. 즉，방화벽을 통 과하는 패킷에 대해서는 방화벽 정책을 확인해 허용되는 정책이면 방화벽을 통과시키면서 그 정 보를 세션 테이블에 기록합니다. 응답 패킷은 방화벽 정책을 확인하는 것이 아니라 세션 테이블에 서 해당 패킷을 먼저 조회합니다. 세션 테이블에 있는 응답 패킷이라면 이미 정책에서 허용된 패 킷이므로 방화벽을 바로 통과할 수 있습니다.
하지만 세션 테이블에 응답 패킷이 없다면 요청한 적이 없는 패킷에 대한 응답으로 간주하고 공격 성으로 판단해 해당 패킷은 폐기(Drop)됩니다. 이런 경우는 출발지와 목적지 간 경로가 두 개 이 상 있어 비대칭 경로가 만들어질 때도 발생할 수 있습니다.
방화벽 장비를 이중화할 경우，이런 비대칭 동작으로 인해 방화벽이 정상적으로 동작하지 않을수 있습니다. 이런 문제를 해결하고 동시에 이중화된 방화벽을 모두 사용하기 위해 FWLB가 사용됩 니다. FWLB가 세션을 인식하고 일정한 규칙을 이용하여 방화벽 세션을 분산하는데 (뒤에서 다룰 해시 알고리즘을 이용) 한 번 방화벽을 지나갔던 세션이 다시 같은 방화벽을 거치도록 트래픽을 분산합니다.
FWLB를 사용하더라도 방화벽에 장애가 발생하는 경우를 대비하기 위해 방화벽에서 설정이 필요 합니다. 방화벽끼리 세션 테이블을 동기화하거나 방화벽에서 첫 번째 패킷이 SYN이 아니어도 허용하는 기능을 사용해 방화벽의 장애로 인해 기존 세션 테이블에 없던 트래픽이 들어오더라도 처 리할 수 있도록 설정해야 합니다.
12.2. 부하분산방법
로드 밸런서는 부하를 다수의 장비로 어떻게 분산시킬까요? 앞에서 다룬 LACP는 두 개 이상의 인터페이스를 하나의 논리 인터페이스로 묶어 회선의 부하를 분산시켰습니다. LACP는 다수의 물 리 인터페이스를 하나의 논리 인터페이스로 구성하기 위해 LACP를 위한 가상의 MAC 주소를 만 들게 됩니다. 로드 밸런서도 이와 유사하게 부하를 다수의 장비에 분산시키기 위해 가상 IP 주소 를 갖게 됩니다. 이 IP 주소는 가상 IP 주소이므로 VIP(Virtual IP)라고도 하고 서비스를 위해 사용 되는 IP 주소이므로 서비스 IP 주소라고도 합니다.
가상 IP 주소가 있다면 실제 IP도 있을 것입니다. 각 서버의 실제 IP 주소를 리얼(Real) IP라고 하 고 로드 밸런서의 가상 IP에 실제 서버들이 바인딩(Binding)됩니다. 실무에서 가상 IP는 VIP라고 부르고 로드 밸런서에 바인딩되어 있는 서버 IP는 리얼 IP 혹은 RIP라고 합니다. 여기서도 VIP와 리얼 IP로 표기하겠습니다.
정리하면 로드 밸런서에는 서비스를 제공하는 서버의 IP인 리얼 IP와 로드 밸런서에서 서비스를 대표하는 VIP가 있습니다. VIP에는 리 얼 IP가 바인딩되어 있고 사용자가 VIP로 서비스를 요청하 면 해당 VIP에 연결된 리 얼 IP로 해당 요청을 전달합니다.
그림 12-4의 예를보면서 앞의 내용을 다시 정리해보겠습니다.
현재 서버 세 대가 있습니다. 서버의 각 IP 주소는 10.10.20.11，10.10.20.12, 10.10.20.13입 니다. 서버 1번은 http, 3번은 https 서비스 데몬이 동작하고 서버 2번만 http와 https 서비스 데몬이 모두 동작합니다. 사용자가 http와 https 서비스로 접근하기 위한 VIP 주소인 10.10.10.1 이 로드 밸런서에 설정되어 있습니다. VIP에는 사용자의 서비스 요청이 들어올 때，어느 서버로 요청을 전달할 것인지 부하 분산 그룹을 설정합니다. 여기서 http 서비스는 서버 1 번과 2번으로， https 서비스는 서버 2번과 3번으로 부하 분산 그룹이 있습니다.
로드 밸런서에서 부하 분산을 위한 그룹을 만들 때는 앞의 예제처럼 OSI 3계층 정보인 IP 주소뿐 만 아니라 4계층 정보인 서비스 포트까지 지정해 만듭니다. 그래서 로드 밸런서를 L4 스위치라고 도 합니다. 7계층 정보까지 확인해 처리하는 기능이 포함되는 경우도 있어 L7 스위치라고도 하지만 보통 로드 밸런서를 L4 스위치라고 부릅니다.
앞의 예제에서는 HTTP와 HTTPS 서비스에 대해 각각 동일한 VIP를 사용했지만 서로 다른 VIP 로도 구성할 수 있습니다. 또한, 로드 밸런서의 VIP에 설정된 서비스 포트와 실제 서버의 서비스 포트는 반드시 같을 필요가 없습니다. 즉，실제 서버에서는 서비스 포트 8080으로 웹 서비스를 수 행하면서 VIP에서는 일반 HTTP 서비스 포트인 80으로 설정할 수 있습니다. 이렇게 되면 사용자는 VIP의 80 서비스 포트로 접근하고 로드 밸런서에서는 해당 서비스 요청을 실제 서버의 8080 서비스 포트로 포트 변경까지 함께 수행하게 됩니다.
