Load Balancing 부하 분산


Load Balancing 부하 분산

Load Balancing 이란?

  • 부하를 고루 분담시켜 한 곳(서버, 사이트)에 과다하게 집중되는 것을 막는 기술
  • 병렬로 운용되고 있는 기기 사이에서 부하가 가능한 한 균등하게 분산 할당시키는 것
  • 부하를 분산시키는 장비, 소프트웨어를 로드밸런서(Load Balancer)라고 합나다.

출처/참고자료

Load Balancer 기능

  • Health Check(상태 확인): 서버들이 정상 작동하는지, 다운되었는지를 정기적으로 확인한다. 다운되었다면 해당 서버에는 더 이상 데이터를 보내지 않는다. 로드밸런서는 다운된 서버도 지속적으로 확인해서 서버가 살아나면 다시 데이터를 보낸다.
    • Layer 3 IP 확인: 서버가 살아있는지 확인한다.
    • Layer 4 포트 확인: 해당 포트가 살아있는지 확인한다.
    • Layer 7 애플리케이션 확인: 해당 애플리케이션이 살아있는지 확인한다. 'L4 포트 확인'과 비교하면, 포트는 살아있지만 해당 애플리케이션이 정상 작동하지 않을 수도 있다.
  • NAT(Network Address Translation): IP 주소를 변환해주는 기능입니다. 내부 네트워크에서 사용하던 사설 IP 주소를 로드밸런서 외부의 공인 IP 주소로 변경해줍니다. (반대로도 가능)
    • SNAT(Source Network Address Translation): 소스(출발지) IP를 변경합니다.
    • DNAT(Destication Network Address Translation): 목적지 IP를 변경합니다.
  • DSR(Direct Server Return/Routing): 서버에서 클라이언트로 되돌아가는 경우, 목적지 IP를 클라이언트로 설정해서 로드밸런서를 거치지 않고 바로 클라이언트로 가능 방식입니다. 로드밸런서의 부하를 줄이는 장점이 있습니다.

Load Balancing Algorithm

  • L4 로드밸런싱: 주로 IP 기반으로 로드밸런싱을 합니다.
    • Round Robin(라운드 로빈): 각 서버에 순차적으로 연결(connection)을 맺어주는 방식.
    • Least Connections(최소 연결): 가장 적은 세션을 가진 서버에 연결을 맺어주는 방식.
    • Least Response Time(최소 응답 시간): 응답 시간이 가장 빠른 서버에 연결을 맺어주는 방식.
    • Hashed IP: 해시 함수를 사용해서 특정 클라이언트는 특정 서버로만 연결을 맺어주는 방식.
    • Minimum Misses: Hashed IP 와 유사한 방식으로, 서버 한 대가 사라지는 경우 해당 서버에 할당되었던 사용자 (또는 IP) 에 대해 재할당 작업을 하는 알고리즘이다. 재할당 대상이 되는 IP 주소를 (32bit) 남은 서버의 대수로 나눈 나머지 값으로 서버를 결정한다.
    • Bandwidth Based: 대역폭을 기반으로 연결을 맺어주는 방식.
  • L7 로드밸런싱
    • URL Switching(URL 스위칭 방식): 특정 하위 URL들을 특정 서버로 분배하는 방식.
      예를 들어 '.../images' 같은 주소들은 서버가 아닌 별도의 스토리지에 바로 연결하는 방식.
    • Context Switching(컨텍스트 스위칭): 클라이언트가 요청한 특정 리소스에 대해 특정 서버 등으로 연결해주는 방식.   이미지 파일은 확장자를 참조해서 이미지 파일이 있는 서버로 직접 연결.
    • Persistence with Cookies(쿠키 지속성): 쿠키 정보를 바탕으로 클라이언트가 연결했던 동일한 서버에 계속 할당해주는 방식.   특히 사설 네트워크에서 있던 클라이언트의 IP 주소가 공인 IP 주소로 치환되저 전송(X-Forwared-For 헤더에 클라이언트 IP 주소를 기록)하는 방식으로 지원.

Load Balancer 주요 성능 지표

  • 초당 연결 수(Connections per second): 최대 처리 가능한 초당 TCP 연결 개수를 의미합니다.
  • 동시 연결 수(Concurrent Connections): 동시에 최대로 연결을 유지할 수 있는 개수를 의미합니다.
  • 처리용량(Throughput): (패킷 자체에 대한 연결이 성립되는) UDP 프로토콜에 대한 로드밸런싱 성능 지표. 단위는 bps(bit per second) 또는 pps(packter per second)를 사용.

SLB (Server Load Balancing)

  • SLB는 LB(Load Balancer)와 VIP(Virtual IP)로 구성된다.
  • VIP(Virtual IP)는 Load Balancing의 대상이 되는 여러 Server들을 대표하는 하나의 가상 IP이다. Client는 각 Server의 IP가 아닌 LB가 갖고 있는 VIP(Virtual IP)를 대상으로 요청한다.
  • 계층(layer)에 따른 분류
    • NLB(Network Load Balancing): L4에서 이루어지는 부하 분산으로, IP 주소나 목적지 포트 등의 정보에 따라 라우팅을 달리 하는 기술이다.
      여기서 Network은 TCP/IP 계층 모델에서 network(IP) 계층(layer 3)를 의미한다.
    • ALB (Application Load Balacing): L7에서 이루어지는 부하 분산으로, HTTP 헤더와 같은 요소를 계산하여 요청을 분산시키는 기술이다.
    • FWLB (FireWall Load Balancing): FWLB 는 여러 대의 방화벽을 추가하여 통신 흐름을 안정적으로 유지해주는 역할을 한다.
  • 출처/참고자료 [Ssup2 Blog] SLB (Server Load Balancing)

1. Proxy

[출처: Ssup2 Blog]
  • Server가 Client로부터 받는 Inbound Packet과 Server가 Client에게 전달하는 Outbound Packet 모두 LB를 거친다. LB에서 Inbound Packet의 Source IP는 SNAT(Src NAT)를 통해 LB의 VIP로 바뀌고, Destination IP는 DNAT(Dst NAT)를 통해 실제 Server의 IP로 바뀐다.
  • 모든 Inbound, Outbound Packet은 Proxy를 지나기 때문에 LB 수행뿐 아니라 Packet Filtering 수행에도 유리한 기법이다. 또한 Proxy기법은 별도의 Network 설정없이 구현 가능한 기법이다. 따라서 Software LB는 Proxy 기법을 이용하여 구현된다.

2. Inline (Transparent)

[출처: Ssup2 Blog]
  • Proxy 기법처럼 Inbound Packet과 Outbound Packet 모두 LB를 거친다. LB에서 Inbound Packet은 실제 Server에 전달하기 위해 DNAT(Dst NAT)만을 수행한뒤 실제 Server에게 전달된다. Server의 Default Gateway는 LB로 설정되어 있기 때문에 Outbound Packet은 LB로 전달된다. Outbound Packet은 LB에서 다시 SNAT(Src NAT)를 통해서 Src IP를 LB의 VIP로 변환한다.
  • Proxy 기법과 다르게 Client의 IP가 Server에게 전달된다. 하지만 실제 Server의 Gateway로 LB가 이용되기 때문에 LB와 Server가 같은 Network에 있어야한다.

3. DSR (Direct Server Return/Routing)

Proxy, Inline 기법은 모든 Inbound, Outbound Packet을 처리해야하기 때문에 LB에 많은 부하가 발생한다. DSR 기법은 이러한 LB 부하를 줄일 수 있는 기법이다. 대부분의 Service들은 Inbound Packet보다 Outbound Packet의 양이 더 많다. DSR 기법은 Outbound Packet이 LB를 거치지 않고 바로 Client에게 전달하게 만들어 LB 부하를 줄인다.

3.1 L2 DSR

[출처: Ssup2 Blog]
  • L2DSR은 Inbound의 Packet의 Dst Mac을 바꾸는 기법이다. LB는 Inbound Packet의 Mac Address를 Server의 Mac Address로 변환한 후 실제 Server에게 전달한다. 그 후 실제 Server는 VIP 주소를 갖고 있는 Loopback Interface를 통해 Src IP를 변환하여 Client에게 바로 Outbound Packet을 전달한다.
  • Inbound Packet의 Mac Address만 바꾸기 때문에 LB와 Server들은 반드시 같은 Network에 속해야 한다.

3.2 L3 DSR DSCP(Differenttiated Service Code Point)

[출처: Ssup2 Blog]
  • L3DSR은 L2DSR의 LB와 Server들이 반드시 같은 Network에 속해야 하는 한계점을 극복하기 위해 나온 기법이다.
  • L3DSR은 Inbound Packet의 Dst IP를 바꾸는 기법이다. 이와 더불어 Server가 VIP 정보를 알 수 있게 Inbound Packet의 DSCP Field를 변경하거나, Inbound Packet을 Tunneling한다. 위 그림은 DSCP Field를 이용하는 L3DSR을 나타내고 있다.
  • LB와 모든 Server는 DSCP/VIP Mapping Table을 알고 있다. LB는 Inbound Packet의 Dst IP를 실제 Server의 IP로 변환하고, Packet의 Dst IP 정보와 Mapaping Table 정보를 바탕으로 DSCP 값도 변경한다. 그 후 실제 Server에게 전달한다.
  • Packet을 받은 Server는 Mapaping Table과 Loopback Interface를 통해 Src IP를 변경하고 DSCP 값을 0으로 만들어 Client에게 바로 전달한다.

3.3 L3 DSR Tunnel

[출처: Ssup2 Blog]
  • Packet을 Tunneling 하는 기법도 DSCP 기법과 유사하다. LB와 Server들은 Tunnel/VIP Mapping 정보를 갖는다. 이 Mapping Table을 바탕으로 LB와 각 Server들은 L3DSR기법을 수행한다.

출처/참고자료


GSLB (Global Server Load Balancing)

  • Global Server 또는 Multi-site Load Balancing이라고 한다.
  • DNS기반의 Load Balancing 기법이다. Service를 제공하는 Server들이 여러 지역에 분리되어 완전히 다른 네트워크에서 운용 될 때 이용하는 기법이다.
  • Data Center간에 로드밸런싱을 한다. 이렇게 하면 Main Data Center 뿐만 아니라 DR Center의 컴퓨터 자원도 이용할 수 있다.
  • GSLB는 DNS와 로드밸런서의 역할을 같이 수행한다.
  • GSLB는 Data Center 또는 Site에 상태확인(health check)를 해서 통신이 단절되면 해당 사이트로 분배하지 않는다.

1. GSLB 동작 방식

[출처: vodkamitlime]

시나리오 설명   아래 "KT GSLB 자세한 흐름도"와 비교해봐도 좋다.

  • 1. 클라이언트는 브라우저 창에 도메인을 입력한다. 이때, 클라이언트에서 LDNS (Local DNS) 에 DNS 쿼리를 날린다.
    - 클라이언트: "LDNS 야, www.google.com의 IP 주소 있니?"
  • 2. LDNS에 IP 주소가 없으면, 연결되어 있는 DNS 서버에 동일한 DNS 쿼리를 날린다.
    - LDNS: "난 없는데, DNS야 넌 있니?"
  • 3. DNS에 해당 도메인에 대한 정보가 존재하는 경우, 정보를 포함한 응답을 반환한다.
    - DNS: "www.google.com에 대한 권한은 GSLB에 위임했어, GSLB한테 물어볼 수 있도록 GSLB의 IP 주소를 줄게"
  • 4. LDNS는 DNS로부터 받은 정보를 토대로 GSLB에 쿼리를 날린다.
    - LDNS: "GSLB 너에게 www.google.com에 대한 정보가 있다는 것을 들었다. IP 주소 내놔라"
  • 5. GSLB는 해당 도메인과 연결된 모든 IP 주소에 대해 헬스체크를 수행하고, 알고리즘 결과에 따라 IP 주소를 반환한다.
    - GSLB: "응 IP 주소가 총 10개 있는데, 방금 확인해본 결과 5개만 살아있네. 그 중에 우리 알고리즘 결과가 내놓은 이 IP 주소를 줄게"
  • 6. LDNS 는 GSLB로부터 www.google.com의 IP 주소를 받고, 캐싱을 한 뒤, 클라이언트에게 전달한다.
  • 7. 클라이언트는 최종 응답받은 IP 주소로 패킷을 보낸다.

2. GSLB 부하 분산 알고리즘

  • 서비스 응답 시간/지연 (RTT/Latency) : 요청에 대한 응답, 지연을 검토해 분산 처리
  • IP 에 대한 지리 정보 (Geolocation) : 서비스 제공이 가능한 각 IP 의 지리적 위치를 확인해 가까운 곳으로 분산 처리 (Multi CDN 을 사용하는 경우, 사용자에게 가장 가까운 region 의 주소를 반환할 수 있음)
  • Data Center 별로 가중치를 줄 수도 있을 것이다. 즉, Main Data Center에 60%, DR Center에서 40% 분배.
  • Main Data Center가 다운되었을 경우 DR Center로 분배한다.

참고 자료

3. GSLB Policy

[출처: NETMANIAS]
  • 1. Server Health - 살아있는 사이트 선택
    SLB(Server Load Balancing)가 서버들로 Layer 3 ICMP, Layer 4 TCP or UDP, Layer 7 HTTP Health Check 메시지를 보내어 서버 & 응용의 Health 상태를 모니터링하고, 그 결과를 GSLB로 전달하여 GSLB는 Server Health 상태를 기반으로 사이트를 선택합니다.
  • 2. SLB Session & Network Capacity Threshold - 과부하 상태가 아닌 사이트 선택
    1번 과정(Server Health 기반 사이트 선택)에서 한국과 미국 사이트 서버가 모두 살아 있는 경우, (1) SLB의 현재 Session 수와 (2) SLB의 Network Usage 값을 참조하여 과부하(Over-loaded) 상태가 아닌 사이트를 선택합니다. 여기서 SLB의 Session 수란 SLB에 오픈되어 있는(유지하고 있는) TCP 혹은 UDP 연결수이고 (예. SLB1을 통해 Sever1에 300,000개 TCP 세션 연결, Server2에 100,000개 TCP 세션이 연결되어 있으면 현재 SLB1의 Session 수는 총 400,000개임), Network Usage란 현재 SLB를 통해 송수신되는 트래픽 대역폭(bps)입니다.
  • 3. Network Proximity - 응답 속도가 빠른(Low Latency) 사이트 선택
    2번 과정(SLB Session & Network Capacity Threshold 기반 사이트 선택)에서 한국과 미국 사이트의 Session/Network Usage가 임계치를 넘지 않은 경우, Network Proximity 기반으로 사이트를 선택합니다. Network Proximity란 "네트워크 관점에서(지리적 관점이 아님)" 사용자와 가까운 사이트를 선택해 주는 것으로 여기서 "가까움"이란 Delay가 작음(Low Latency)를 의미합니다.
  • 4. Geographic Proximity - 지리적으로 가까운 사이트 선택
    3번 과정(Network Proximity 기반 사이트 선택)에서 Local DNS 서버가 ICMP에 응답을 하지 않거나 혹은 두 사이트의 RTT 결과가 유사한 경우, 지리적으로 사용자와 가까운 사이트를 선택하게 됩니다.
  • 5. SLB Connection Load - 새로운 연결 요청이 적은 사이트 선택
    지난 시간 4번 과정(Geographic Proximity 기반 사이트 선택)에서 사이트를 선택하지 못한 경우, SLB의 Connection Load가 적은 사이트를 선택합니다. SLB Connection Load란 "일정 시간 동안 SLB에 생성되는 새로운 TCP or UDP 연결수"를 의미합니다. 예를 들어, SLB의 주기가 5초로 설정되어 있고, 각 초별로 새로운 연결이 100개, 110개, 120개, 130개, 140개가 생성되었다면 SLB Connection Load는 (100 + 110 + 120 + 130 + 140) / 5초 = 120개가 됩니다.
  • 6. Site Preference - 운영자의 정책에 의해 특정 사이트 선택
    두 사이트의 SLB 모두 Connection Load 임계치를 넘지 않아 5번 과정(SLB Connection Load 기반 사이트 선택)에서 사이트를 선택하지 못한 경우, 운영자가 설정한 Site Preference 값(사이트 선호도)에 의해 사이트를 선택합니다. 운영자는 GSLB에 각 사이트 별(SLB 별)로 Preference 값을 설정하고, GSLB는 항상 그 값이 큰 사이트를 선택합니다.
  • 7. Least Selected - 균등하게 사이트 선택
    두 사이트 모두 동일 Preference로 설정되어 6번 과정(Site Preference 기반 사이트 선택)에서도 사이트 선택이 안된 경우, 사이트 부하를 균등하게 하기 위한 방법으로 선택이 덜 된 사이트(least selected site)를 선택합니다.
  • 8. Static Load Balancing - 균등하게 사이트 선택
    7번과 8번 단계는 둘 중에 하나만 사용이 가능한 최종 선택 단계입니다. 8번 과정은 Round-Robin 혹은 사이트에 가중치를 적용한 Weighted Round-Robin 방식으로 사이트를 선택합니다.

출처/참고자료 [NETMANIAS] Enterprise를 위한 GSLB

KT GSLB 개념도

[출처: NETMANIAS]

KT GSLB 자세한 흐름도

[출처: NETMANIAS]


Email 답글이 올라오면 이메일로 알려드리겠습니다.

혹시 처음이세요?
레디스게이트에는 레디스에 대한 많은 정보가 있습니다.
레디스 소개, 명령어, SQL, 클라이언트, 서버, 센티널, 클러스터 등이 있습니다.
혹시 필요한 정보를 찾기 어려우시면 redisgate@gmail.com로 메일 주세요.
제가 찾아서 알려드리겠습니다.
 
close
IP를 기반으로 보여집니다.