[GCP] Load Balancing (2/3) - SSL/TCP Proxy Load Balancing

이 포스팅은 Google Cloud 공식 Document와 Coursera의 Networking in GCP: Defining and Implementing Networks 강의를 요약 정리 한 것 입니다.

SSL Proxy Load Balancing

SSL proxy는 유저의 SSL connection을 Load Balancing layer에서 종료하고 SSL이나 TCP 프로토콜을 통해 backend instance로 트래픽을 전달합니다. 트래픽이 HTTP(S)이 아닌 경우에 사용되며 HTTP(S) 트래픽은 HTTP(S) load balancing을 사용하는 것이 좋습니다.

IPv4, IPv6를 모두 지원하며 Global load balancing이 가능합니다. Global load balancing을 하기 위해서는 Premium Tier의 네트워크를 사용해야 합니다.

SSL Proxy Load Balancing은 Google-managed certificates를 사용 할 수 있습니다. (뒤에서 다룰 Network Load Balancing은 self-managed certificates만 사용 가능합니다.)

SSL Proxy가 지원하는 포트는 다음과 같습니다.

25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 5222. 

단, Google-managed certificates를 사용한다면 frontend 포트를 반드시 443으로 사용해야 합니다.

 SSL Proxy 의 몇가지 장점들이 있는데 대표적으로 Intelligent routing 가 있습니다. Backend location의 사용량을 체크하여 서비스 가능지역으로 트래픽을 분산합니다. 이런 사용량 체크 없이 정해진 region으로만 트래픽을 전달하는 L3/L4 load balancer보다 아주 똑똑하죠.

다음은 SSL Proxy Load Balancing의 사용 예시 입니다.

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

예시 flow를 살펴보면, 먼저 미국 Iowa와 Boston에 있는 user로 부터 SSL 트래픽을 받습니다.

SSL Proxy Load Balancing이 유저의 SSL 트래픽을 받고 SSL connection 을 종료 합니다. 

Iowa 유저의 트래픽은 US Central Region으로 전달하고

Boston 유저의 트래픽은 US East Region으로 전달합니다.

Load Balancing layer에서 instance 까지 구간의 트래픽은 SSL 또는 TCP로 선택할 수 있지만 보안상 SSL을 사용하는 것이 좋습니다.

다만 이 경우 encrypt된 트래픽을 backend instance에서 decrypt 해야하므로 CPU 사용 효율이 안좋은 암호화 방식을 사용할경우 instance의 CPU 사용량이 많이 증가합니다.

CPU 성능을 최대화 하기 위해서는 ECDSA SSL certs, TLS 1.2 를 사용하고 ECDHE-ECDSA-AES128-GCM-SHA256 암호화 스위트(cipher suite)를 사용하는 것을 권장합니다.

 

TCP Proxy Load Balancing

SSL 트래픽이냐 TCP 트래픽이냐 차이일 뿐, 기본적으로 TCP Proxy는 SSL Proxy와 기본 구조는 동일 합니다. 

HTTP 트래픽도 처리 가능하지만 HTTP 트래픽은 HTTP Load Balancing을 사용하고 non-HTTP 트래픽에 대해서 TCP Prox Load Balancing을 사용하는것을 권장 합니다.