Google Cloud Load Balancer 핵심만 빠르게 훑어보기

이번에는 GCLB( Google Cloud Load Balancer )에 대해서 살펴보는 시간을 갖겠습니다. 일반적으로 LB는 서비스로 유입되는 부하를 분산시키는 역할을 수행합니다. AWS, Google, Azure 퍼블릭 클라우드 3사 모두 해당 기능을 제공하지만 가격 등의 이유로 HAProxy 등을 가상 머신에 설치해서 LB 역할로 사용하기도 합니다. 하지만 이 경우에는 머신의 정해진 스펙 때문에 급격하게 증가하는 트래픽에 빠른 대응이 어렵다는 단점이 있겠습니다. 또한 조직의 누군가가 서버를 관리해야 하는 만큼 고가용성 보장이 어렵습니다. LB는 프러덕트 최전방에 있는 만큼 절대적으로 고가용성이 보장되어야 하는데요, 이런 서비스일수록 클라우드에서는 Managed service, 여기서는 GCLB를 사용하는게 좋겠습니다. 그렇다면 GCLB의 특징에는 무엇이 있는지 하나씩 설정을 통해 알아보도록 하겠습니다. 

---

GCLB는 아래처럼 네트워크 서비스 페이지에서 처음 설정을 시작할 수 있습니다. Create load balancer를 눌러봅시다. 

Create load balancer

GCLB는 network layer에 따라서 HTTP(S), TCP, UDP Load Balancing으로 나뉘는데 여기서는 HTTP(S)에 대해서 살펴봅니다. 나머지 차이에 대해서는 여기 페이지를 참고하도록 하세요.

다음으로는 네트워크 구성 측면에서 LB의 위치에 대한 설정을 해줘야 합니다. Public 망으로부터 VMs으로 전달되는지, 내부 VMs간의 통신인지에 따라 설정이 나뉘게 되는데 일반적인 용도를 생각해서 From Internet to my VMs 를 선택하고 Continue 합니다.

From Internet to my VMs

 

HTTP(S) LB 설정은 다음과 같이 Backend configuration, Host and path rules, Frontend configuration 세 개의 파트를 설정해야 합니다. 화면 우측에 설명이 잘 되어있는데 Backend configuratin은 들어오는 트래픽을 인스턴스 그룹이나 스토리지 버킷으로 전송하도록 하는 설정이고 Host and path rules에서는 트래픽을 전송하는 규칙을 정하게 됩니다. 특별한 규칙이 없으면 기본 backend 서비스로 전송됩니다. 끝으로 Frontend configuration은 트래픽이 들어오는 IP와 프로토콜을 설정하게 됩니다. 보다 상세한 내용은 하나씩 설정하면서 알아보도록 하겠습니다.

New HTTP(S) load balancer

 

# Backend configuration

먼저 Backend configuration입니다. 설정을 위해 선택하면 우측에 Backend services, Backend buckets을 선택할 수 있고 생성까지 하도록 되어 있습니다. Create a backend service를 선택하기 전에 혹시 인스턴스 그룹에 대한 개념이 없다면 이전에 작성한 인스턴스 그룹과 템플릿, 그리고 이미지 글을 먼저 읽어보시기를 바랍니다. Backend 서비스를 구성하기 위해서는 인스턴스 그룹을 선택해야 하는데 없다면 미리 생성해줘야 하기 때문이죠.

Backend configuration

 

이 글에서는 미리 생성해 놓은 sp-group 인스턴스 그룹으로 설명합니다. 인스턴스 그룹은 특별한 설정이 있는게 아니라서 어렵지 않게 생성하실 수 있을 겁니다. 자, 아래와 같이 인스턴스 그룹을 선택해줬습니다. 그리고 Protocol을 추가할 수 있지만 일반적으로 LB 밑에 서비스는 HTTP로 통신합니다. HTTPS는 LB에서 처리될 예정이므로 여기서는 손대지 않기로 합니다. 

Create backend service

 

화면 스크롤을 아래로 내려보면 추가 설정을 할 수 있는 Advanced configurations (Session affinity, connection draining timeout, security policies) 메뉴가 보입니다. 선택하도록 합니다.

Create backend service

 

여기서 놓치지 말고 봐야 하는 부분은 LB의 중요한 특징인 Session affinity 입니다. 쉽게 이야기해서 트래픽을 분산시키는 기준을 정하는 겁니다. 기본은 None으로 되어 있는데 이 상태대로라면 RR( Round Robin ) 방식으로 부하를 균등하게 분산시킵니다. Client IP와 Generated cookie를 선택할 수 있는데 동일한 IP에서 들어오는 트래픽은 같은 머신에서 처리한다는 개념으로 생각하시면 됩니다. Generated cookie도 마찬가지입니다. 세션이 한번 맺어지면 Affinity cookie TTL 시간까지 트래픽을 같은 머신에서 처리하게 됩니다. 같은 세션에 대해서 항상 동일한 머신이 처리해야 하는 이유가 있을 때 유용할 수 있지만 부하를 균등하게 분산시키지 못한다는 단점이 있습니다. 

Session affinity

 

부하가 균등하게 분산되지 못하는건 어떤 경우일까요? 처음 서비스가 시작되는 시점에는 모두 균등하게 잘 분배가 되겠지만 scale-in/out을 반복하다 보면 결국 특정 서버에 부하가 몰리게 될 겁니다. 어차피 그렇다고 해도 다시 scale-out이 되서 서비스에는 영향도가 적겠지만 불필요한 scale-out 이 발생하는 겁니다. 충분히 여유로운 머신이 있음에도 말이죠. 이 부분에 대해서는 추후에 별도의 포스팅을 통해 조금 더 상세히 알아보도록 하겠습니다. 

 

자, 끝으로 Health check까지 아래와 같이 작성해주고 Create로 backend service를 생성하도록 합니다.

Health check

 

# Host and path rules

사실 이 부분은 딱히 작성할 내용이 없습니다. 왜냐하면 위에서 Backend service를 생성하면 기본값이 설정되기 때문인데요, 특정 Hosts와 Paths를 정할 것이 아니라면 건너뛰어도 괜찮습니다. 자동 등록된 내용이 기본값으로 동작해서 매치되는 Rules이 없으면 여기 기본값에 매핑됩니다. 추가를 하게 되면 Hosts에는 foo.example.com과 같은 형식으로 작성할 수 있습니다. wildcard가 지원되기 때문에 *. example.com처럼 쓸 수도 있습니다. 한 개의 LB에서 여러 개의 Backend를 운영할 때 사용될 수 있겠습니다. 등록 가능한 Quota는 여기 페이지를 참고하세요.

Host and path rules

 

혹시 Host and path rules 개념이 잘 이해가 안되면 아래 이미지가 도움이 될 수 있습니다. 결국 접속하는 Host와 Path에 따라서 backend service 구분하게 됩니다.

https://cloud.google.com/load-balancing/docs/https/url-map-concepts

 

# Frontend configuration

끝으로 Frontend configuration입니다. HTTP(S) Load Balancer를 선택한 것처럼 Protocol은 HTTP와 HTTPS를 설정할 수 있습니다. 우선 HTTP는 별다르게 설정할게 없습니다. 고정 IP를 사용할지 임시 IP( Ephemeral IP )를 사용할지 정도를 선택해주면 되겠습니다. 작성이 끝났으면 하단에 Add Frontend IP and port를 선택하고 HTTPS를 추가로 설정해보도록 합시다.

Frontend configuration - HTTP

 

아래처럼 Protocol을 HTTPS를 선택해보면 조금전에 HTTP 설정한 화면에서 추가로 인증서 관련해서 설정할 수 있는 메뉴가 나옵니다. 

Frontend configuration - HTTPS

 

인증서는 두 가지 방식으로 설정할 수 있습니다. 첫 번째는 이미 보유하고 있는 인증서를 업로드하는 방식과 GoogleGoogle-managed certificate를 사용하는 방식인데 Google-managed certificate의 경우에는 Letsencrypt로 인증서가 생성되며 이때는 wildcards를 지원하지 않습니다. 즉, *.example.com 같은 형식을 입력할 수 없습니다. 한편 그럼에도 managed의 장점은 인증서 갱신을 자동으로 해준다는 점입니다. 서버에서 Letsencrypt를 사용할 때 crontabs 등으로 renew 하는 등 여러 가지 tricky 한 방식을 사용했었는데 그러지 않아도 된다는 거죠. 기본 Quota로는 9개까지 등록 가능합니다.

 

비용을 지불하고 인증서를 구매한 경우가 아니라 Letsencrypt를 사용해야 하지만 wildcards를 포기할 수 없는 경우에는 직접 생성한 Letsencrtpt 인증서를 업로드해서 사용해도 됩니다. 이때는 Google-managed가 아니기 때문에 wildcards를 입력할 수 있습니다. 또한 인증서는 Add certificate 버튼을 통해 추가로 9개까지 등록 가능합니다. 이 수치는 증설 가능한 Quota입니다. 인증서에 대한 더 자세한 이야기는 아래 링크에서 확인하실 수 있습니다.

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

Creating and Using SSL Certificates  |  Load Balancing  |  Google Cloud

내용 진행을 위해 Google-managed로 임의의 인증서를 생성해줬으며 모든 설정을 마쳤으면 Done을 선택합니다.

Done

 

여기까지 잘 끝냈으면 이제 Review and finalize를 선택하고 앞서 설정한 것들에 대한 리뷰를 진행합니다.

Review and finalize

 

별다른 이상이 없으면 Create를 선택해서 Load Balancer를 생성하도록 합시다. 기다리면 아래와 같이 LB 리스트에 방금 생성한 ss-lb가 확인됩니다.

Load balancer 생성 완료

 

이 페이지에 Region은 Global이라고 표기되어 있는데 HTTP(S) External의 Frontend 설정에서 가져온 IP는 Global로 잡힙니다. 즉, 리전의 특성을 타지 않는다는 거죠.

https://cloud.google.com/load-balancing/docs/load-balancing-overview#types_of_cloud_load_balancing

 

아래처럼 External IP 발급 현황에도 좀 전에 Frontend에서 생성한 IP의 Region은 빈칸으로 잡히는데 내부적으로 고정 IP를 RESERVE 할 때 Type을 Global로 설정했다는 겁니다. 이게 HTTP(S) External LB의 주목할만한 특징입니다.

LB가 생성되면 뒷단에 Backend service가 돌기 시작하고 인스턴스 그룹의 설정에 따라 인스턴스가 자동으로 생성/수평 확장됩니다.

자동 생성된 sp-group-4pv6 인스턴스

 

# 마무리

여기까지 해서 Google Cloud에서 제공하는 Load Balancer를 살펴봤습니다. GCLB의 또 하나 중요한 특성은 Autoscaling 조건이 충족되었을 때 확장되는 인스턴스의 개수는 점진적으로 증가한다는 겁니다. 축소도 마찬가지고요. 사용자가 설정할 수 없지만 이런 부분은 gmail, youtube 등 다양한 글로벌 서비스를 하고 있는 구글이 알아서 해준다라고 생각하는게 편할 듯합니다. 누군가에게는 불편함일 수도 있지만요. 모든 옵션에 대해서 살펴본 게 아니기 때문에 더 자세한 내용이 궁금하신 분은 공식 홈페이지 도큐먼트를 참고하시면 좋습니다.