[GCP] Load Balancing (1/3) - HTTP(S) Load Balancing

Load Balancing (이하 LB)는 분산 시스템에서 중요한 요소 중 하나 입니다.

서버 cluster에  traffic을 분산하여 성능과 가용성을 높이고, 주기적으로 서버들의 상태를 체크하여 부하가 높거나 에러가 발생하거나 반응이 늦는 서버 쪽으로 traffic을 보내지 않는 등의 역할을 합니다.

GCP의 Cloud Load Balancing은 여러가지 타입의 LB를 제공하는데 각 타입별 용도가 상이하고 요구 사항도 다르기 때문에 클라우드 시스템 설계시 어떤 LB를 사용해야 하는 지 확실히 알아 둘 필요가 있습니다.

이 포스팅은 GCP Documentation과 Coursera 강의 내용을 기반으로 Google Cloud Load Balancing에 대해 정리한 것 입니다.

 

HTTP Load Balancing

HTTP LB는 OSI모델의 Layer 7인 어플리케이션 Layer의 Load Balancing을 제공합니다.

HTTP request에 대해서 Global Load Balancing을 제공하고 하나의 Anycast IP 주소를 사용합니다. 따라서 여러 region에 분산되어 있는 Backend에 모두 동일한 ip를 통해 접근이 가능합니다. 

HTTP는 80 혹은 8080 포트를 사용하고 HTTPS는 443 포트를 사용 합니다.

IPv4 와 IPv6 주소를 모두 지원하며 Managed instance group을 통해 Autoscaling 기능도 제공합니다.

Global LB여서 Premium Network Tier를 사용해야 합니다. 

HTTP의 기본 구조는 다음과 같습니다.

출처: https://cloud.google.com/load-balancing/docs/https/

제일 먼저 Global Forwarding Rule이 Internet에서 받은 request를 Target HTTP Proxy에 전달합니다. 

Target HTTP Proxy는 전달받은 각각의 request를 Url Map과 비교하여 어느 Backend Service로 보낼지 결정하고 forwarding 합니다. 

( 예를들어 www.example.com/audio 는 audio backend service로 보내고 www.example.com/video는 video backend service로 보낸다던지, 어플리케이션 layer의 LB여서 message 내용과 url 기반의 Load Balancing이 이런식으로 가능합니다. )

Backend Service는 serving capacity, instance health check 등을 고려하여 가장 적절한 Backend로 request를 보냅니다.

Instance group은 managed/unmanaged instance group으로 나뉘는데 managed instance group을 사용하여 Autoscaling 기능을 활성화 할 수 있습니다.

또한 CPU 사용량과 초당 request 횟수를 기반으로 Balancing mode를 셋팅할 수 있는데, Balancing mode는 region에 몰리는 request가 셋팅한 request 허용량을 초과하면 자동으로 아직 여유있는 가장 가까운 region으로 traffic을 보냅니다.

 

HTTPS Load Balancing

기본적으로 HTTP LB와 HTTPS LB의 구조는 동일 합니다.

다만 Target HTTP proxy 대신 Target HTTP(S) proxy를 사용하고 최소 하나 이상의 SSL certification이 Target HTTP(S) proxy에 설치가 되어야 하며 최대 10개까지 설정 가능합니다.

Client로 부터 받은 SSL session은 LB에서 종료됩니다.

 

Cloud Armor

Cloud Armor는 HTTP(S) Load Balancing과 함께 사용할 수 있는 DDoS 방어 서비스 입니다.

Blacklist 와 Whitelist 를 설정하여 특정 ip에서 들어온 request를 원천적으로 봉쇄하거나 (해당 request가 LB에 도달하지 못함)

특정 ip들만 접근을 허가하는 security policy를 만들 수 있고 403, 404, 502 에러코드를 보여주는 deny rule을 설정할 수도 있습니다.

 

Cloud CDN

CDN (Content Delivery Network)은 여러 지역에 proxy 역할을 하는 분산 서버들을 두고 html, javascript, css  등의  web page 나  image, video  같은  static media 를 user와 가까운 위치의 서버에서 제공 할 수 있도록 합니다.

큰 용량의 static 파일이나 web contents 를 바다 건너 서버에서 직접 받을 필요 없이 user와 가장 가까운 local cache 서버에서 받을 수 있도록 하는 것 입니다.

대표적 사용 예로, Netflix는 자체 제작 CDN 서버를 Cloud infra와 결합하여 전 세계 어디서든 안정적인 속도로 영화 streaming 서비스를 제공합니다.

Google의 Cloud CDN 은 전세계 90개 넘는 Google Edge Point of Presence (PoP)를 Cache site로 사용합니다. 내년 초에 한국에도 데이터 센터가 들어오면 PoP 목록에 조만간 서울도 포함 될 것이라 생각합니다.

Cloud CDN은 HTTP(S) LB 설정할 때 체크박스 클릭 한번으로 간단하게 설정 할 수 있습니다.

Cloud CDN의 장점은 Backend 까지 request가 갈 필요없이 가장 가까운 cache site에서 바로 request를 처리하니 Web site의 load time 이 크게 향상됩니다. 

또한 그만큼 Bandwidth cost도 절약 할 수 있고 contents의 가용성 향상까지 1석 3조의 효과가 있습니다.

다만 Cloud CDN도 Global LB와 마찬가지로 Premium Network Tier에서만 사용 가능 합니다.

 

 

 

SSL/TCP Proxy Load Balancing

Network Load Balancing (TCP/UDP)

Internal Load Balancing 에 대한 내용은 다음글에서 이어집니다.