[GCP]DNS 부터 하나씩 Google cloud 로 서비스 해보기 — 2탄 Google Cloud Load Balancing(GCLB)
안녕하세요 이정운 입니다.
이번시간에는 지난 시간에 이야기한 것처럼 하나의 간단한 서비스를 Google cloud 로 적용한다는 가정에서 어떤 부분을 살펴보고 고려하면 좋을지에 대해서 더 살펴보도록 하겠으며 Cloud DNS 에 이어서 Google Cloud Load Balancing(GCLB) 을 다뤄보려고 합니다.
GCLB 의 가장 큰 특징 중의 하나는 많은 부하를 처리하기 위해서 별도로 가동 준비 과정(warm-up) 같은 것이 필요하지 않기때문에 바로 필요한 요청 처리를 위한 최대 범위까지 확장 할 수 있으며, 글로벌 서비스를 준비중이라면 LB 를 리전별로 구성하는 것이 아니라 하나의 GCLB 를 통해서 단일 Anycast IP 가 세계 각지의 모든 백엔드 인스턴스의 프론트엔드로 수행되게 할 수 있습니다.(그러면서 geo-affinity 까지 자동으로 제공가능 합니다.)
이러한 서비스를 수행하면서도 백엔드 상태가 양호하지 않을 경우 트래픽을 이동시키는 자동 다중 지역 장애 조치 등 지역을 교차하는 부하 분산을 제공가능 하며 특히, DNS 기반 글로벌 부하 분산 솔루션 형태와 달리 Cloud Load Balancing 은 사용자, 트래픽, 네트워크, 백엔드 상태와 같은 관련 조건의 변화에 즉각적으로 반응 가능합니다.
https://cloud.google.com/load-balancing/?hl=ko
그럼 지금부터 하나씩 하나씩 실제 테스트를 해보면서 살펴볼까요?
#1) Google Cloud Load Balancer 추가 하기
이번 이야기는 지난 시간에 이야기 했던 Cloud DNS 구성이 되어 있다는 가정을 하고 진행할 예정이기 때문에 지난 이야기를 수행하지 않으신 분들이 있다면 지난 이야기부터 먼저 읽어보고 테스트 해보시길 권장드립니다.
GCLB 를 추가하기 위해서는 기본적으로 대상이 되는 인스턴스 그룹이 있어야 합니다. 인스턴스 그룹은 Auto-scale 을 위한 인스턴스 템플릿을 가진 관리형 인스턴스 그룹 형태와 템플릿을 사용하지 않고 직접 VM 인스턴스를 추가할 수 있는 비관리형 인스턴스 그룹으로 나뉩니다.
간단한 테스트 목적이므로 비관리형 인스턴스 그룹을 만들고 대상 VM 인스턴스에는 지난 이야기에서 사용한 간단한 nginx 서비스가 구동되고 있는 GCE 를 선택합니다.
인스턴스 그룹이 만들어졌으면 이제 본격적으로 GCLB 를 만들도록 하겠습니다. GCLB 는 하단과 같이 크게 3가지 타입이 존재합니다.
보시면 아시겠지만 처리할 수 있는 프로토콜에 차이가 있으며 좀 더 자세한 차이가 궁금하신 분들은 하단의 링크를 참고하시기 바라겠습니다.
Choosing a Load Balancer
https://cloud.google.com/load-balancing/docs/choosing-load-balancer
이번 이야기에서는 가장 많이 사용하는 글로벌 GCLB 인 HTTP(S) 부하 분산기를 생성해보도록 하겠습니다. 간단하게 설명을 먼저 하면 HTTP(S) 부하 분산기는 이름 그대로 HTTP(S) 프로토콜을 지원하는 글로벌 LB 로 내부적으로는 하단과 같은 구성을 가집니다.
https://cloud.google.com/load-balancing/docs/https/#fundamentals
조금 어려워보이긴 하지만 일반적으로는 생성 마법사대로 만들기만 하면 바로 생성 가능하므로 너무 걱정하실 필요는 없습니다. 그럼 실제로 HTTP(S) 부하분산기를 만들어 보면서 내부를 살펴보도록 하겠습니다. 해당 메뉴의 ‘구성 시작’ 을 클릭하면 생성 마법사가 나타나며 백엔드 구성을 시작 할 수 있습니다.
백엔드 구성은 말 그대로 GCLB 가 부하를 보낼 실제 벡엔드 서비스를 생성하는 것이며 인스턴스 그룹을 지정할 수 있습니다. 분산 모드나 최대 GCP 사용률 등을 조정할 수 있으며 Cloud CDN 사용 여부를 추가 설정 할 수 있습니다. (세션 어피니티나 연결 제안 시간 설정등 좀 더 자세한 내용이 궁금하신 분들은 이 링크를 참고하시기 바라겠습니다. — https://cloud.google.com/load-balancing/docs/https/#backend_services)
백엔드 서비스 구성을 한 후에 호스트 및 경로 규칙을 구성합니다. 하나의 벡엔드만 사용할 경우에는 기본적으로 자동 설정이 되므로 문제가 없는지 확인만 하고 넘어가면 됩니다.
다음으로 프론트엔드 구성을 수행합니다. Public IP 가 필요한 경우 IP 주소를 하나 생성하고 프로토콜은 HTTP 를 선택합니다. (HTTP 이므로 기본 포트인 80 을 사용)
마지막으로 설정을 검토하고 문제가 없다면 ‘만들기’를 클릭하여 HTTP(S) 부하 분산기를 생성합니다.
HTTP(S) 부하 분산기가 정상적으로 생성 되었다면 생성된 프론트엔드 IP 주소로 호출하여 하단과 같이 결과가 동일하게 나오는 것을 확인할 수 있습니다.
#2) GCLB 와 Cloud DNS 연동하기
이전 파트에서 생성한 GCLB 와 Cloud DNS 를 연동하기 위해서는 간단히 기존의 A record 의 IP 주소만 GCLB 의 IP 주소로 변경하시면 됩니다.
해당 작업은 반영에 조금 시간이 걸리므로 nslookup 명령을 이용해서 IP 가 정상적으로 변경되었는지를 확인합니다.
Cloud DNS 에 IP 변경이 정상적으로 되었다면 브라우저로 테스트 가능하며 하단과 같은 정상 결과를 받을 수 있습니다.
#3) GCLB 에서 HTTPS 로 서비스 하기
이전 파트까지는 GCLB 서비스를 테스트해보는 목적이라 간단한게 HTTP 프로토콜로만 진행했습니다. 그러나, 실제 서비스라면 HTTP 보다는 보안적인 목적으로 HTTPS 를 더 많이 사용하실 것 입니다.
이를 가정하여 기존의 GCLB 에서 HTTPS 서비스가 가능하도록 변경해보도록 하겠습니다. 먼저 기존 HTTP(S) 부하 분산기에서 수정 메뉴를 클릭한 후 ‘프런트 앤드 구성’에서 HTTPS 프론트 엔드를 하단과 같이 추가 합니다.
이때 HTTPS 서비스이기 때문에 당연히 SSL 인증서가 필요합니다. 인증서를 코모도와 같은 외부 인증 업체를 통해서 구매한 후 업로드 해도 되지만 Google cloud 의 경우에는 Google 에서 관리하는 인증서를 별도의 추가 비용 없이 만들어서 바로 사용할 수 있습니다.
Tip #1) 참고적으로 Google 에서 관리하는 인증서는 single, non-wildcard 도메인 인증서입니다.
Using Google-managed SSL certificates
https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs
오픈소스인 Let’s Encrypt 기반으로 생성되며 실제 인증서를 확인해보면 하단과 같은 정보를 확인할 수 있습니다.
Google 에서 관리하는 인증서를 만드신 후 새로운 HTTPS 용 프런트 엔드 구성에 추가해 줍니다.
기존 HTTP 구성과 추가된 HTTPS 구성을 확인 한 후 이슈가 없다면 업데이트를 클릭합니다.
HTTPS 구성을 완료했다고 바로 서비스가 가능하지는 않으며 Google 에서 관리하는 인증서 생성에 시간이 걸립니다. 하단과 같은 명령을 사용하여 인증서 상태를 확인 가능합니다.
gcloud beta compute ssl-certificates listTip #2) 인증서 상태에 대한 좀 더 자세한 내용이 궁금하신 분들은 하단의 링크를 참고하시기 바라겠습니다.
Google-managed SSL certificate resource status
https://cloud.google.com/load-balancing/docs/ssl-certificates#certificate-resource-status
참고로 인증서 생성에서 일반적으로 30분에서 60분 정도의 시간이 걸리며 정상적으로 인증서가 발급 되었다면 하단과 같이 확인 가능합니다.
gcloud beta compute ssl-certificates describe lb-ssl-cert-01그리고 또한, GCP 의 관리콘솔 상에서도 인증서가 정상 생성 되었다는 것을 확인할 수 있습니다.
당연히 브라우저 상에서 https 로 정상테스트가 가능한 것을 확인할 수 있습니다.
추가적으로, 보안상 HTTPS 로만 서비스 하기를 원하시는 경우라면 기존의 HTTP 프론트 엔드를 하단과 같이 삭제 가능합니다.
그래도 HTTPS 프런트엔드 상태가 정상인 것을 확인 가능합니다.
실제로 테스트를 해보시면 HTTPS 는 정상적으로 서비스가 되지만 HTTP 는 서비스가 되지 않는 것을 확인 가능합니다.
Tip #3) GCLB 가 정상적으로 서비스 되고 있다면 몇 개의 샘플 호출 후에 하단과 같이 모니터링 정보도 바로 관리콘솔에서 확인해 보실 수 있습니다.
여기까지 잘 따라오셨다면 이전 이야기에서 설정한 Cloud DNS 에 이어서 GCLB 구성에 인증서까지 추가하여 HTTPS 로 서비스 해보는 것까지 무사히 테스트 해보신 것입니다. 일반적인 서비스에서 많이 사용되는 가장 앞단의 기술들이라 도움이 되셨기를 바라며 이번 이야기는 여기서 줄이도록 하겠습니다. 그럼 이만 휘리릭~~~
Disclaimer: 본 글의 작성자는 Google 직원이지만 Google cloud 를 공부하는 한 개인으로서 작성된 글입니다. 본 글의 내용, 입장은 Google 을 대변하지 않으며 Google 이 해당 콘텐츠를 보장하지 않습니다.
참고 자료 #1
Google Cloud Load Balaning
https://cloud.google.com/load-balancing/?hl=ko
Overview of Load Balancing
https://cloud.google.com/load-balancing/docs/load-balancing-overview
Google-managed SSL certificate resource status
https://cloud.google.com/load-balancing/docs/ssl-certificates#certificate-resource-status
