GCP 로드밸런서

GCP 외부 HTTP 로드밸런서에서 방화벽 설정을 할 수 없음. 그러면 기본은 어디서나 GCP 로드밸런서에 접근할 수 있음. Google Cloud Armor 를 이용해야 IP 제한을 할 수 있음.

 

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

 

로드밸런서 선택하기

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

https://cloud.google.com/load-balancing/docs/choosing-load-balancer

외부 HTTP 부하 분산기

https://cloud.google.com/load-balancing/docs/https?hl=ko

https://cloud.google.com/load-balancing/docs/https/ext-https-lb-simple?hl=ko

로드밸런서를 만들때 비관리형 인스턴스 그룹을 이용했음. 비관리형 인스턴스 그룹에서는 zone 을 지정하는 부분이 있다. 비관리형 인스턴스 그룹에서는 멀티 영역 지원을 하지 않는다.
https://cloud.google.com/compute/docs/instance-groups
"비관리형 인스턴스 그룹은 자동 확장, 자동 복구, 순차적 업데이트 지원, 멀티 영역 지원 또는 인스턴스 템플릿 사용을 제공하지 않으므로 가용성이 높고 확장 가능한 워크로드를 배포하는 데는 적합하지 않습니다."

 

관리형 인스턴스 그룹을 이용하는 경우에는 영역 MIG보다 리전 MIG가 있는데 리전 MIG가 여러 영역에 분산할 수 있다.

https://cloud.google.com/compute/docs/instance-groups/regional-migs

비관리형 인스턴스 그룹 - 로드밸런서 설정

테스팅을 위해서 비관리형 인스턴스 그룹 만든다.

(여기에서 설정한 인스턴스 그룹의 VM에서는 해당 port 방화벽 설정 필요함) https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances?hl=ko#gcloud

gcloud compute instance-groups unmanaged create lb-web-instance-group \ --zone=asia-northeast3-a gcloud compute instance-groups unmanaged add-instances lb-web-instance-group \ --zone=asia-northeast3-a \ --instances=gw-web-dev-1 # 인스턴스 그룹에 이름이 지정된 포트 추가 gcloud compute instance-groups set-named-ports lb-web-instance-group \ --named-ports http:80 \ --zone asia-northeast3-a

 

# 인스턴스 템플릿 생성 REGION="asia-northeast3" HOST_PROJECT="sample-gw-shared-vpc" SUBNET="sample-gw-web-ne3-dev-subnet" GCP_TEMPLATE="sample-gw-web-template" TAGS="webserver" project="sample-gw-dev-00000" sa_for_web="sample-web-general-sa" web_image=`gcloud compute images list --filter=name:sample-gw-web-ubuntu-2004-focal --uri | awk -Fimages/ '{ print $2 }'` WEB_IMAGE_PROJECT="sample-gw-dev-00000" gcloud beta compute instance-templates create $GCP_TEMPLATE \ --machine-type=e2-medium \ --network-interface=subnet=projects/$HOST_PROJECT/regions/$REGION/subnetworks/$SUBNET \ --image=$web_image \ --image-project=$WEB_IMAGE_PROJECT \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk-device-name=$GCP_TEMPLATE \ --reservation-affinity=any \ --no-address \ --tags=$TAGS

로드밸런스에서 tcp 80,443 (http,https)로 들어오는 트래픽을 네트워크태그 webserver 에만 허용. https://cloud.google.com/load-balancing/docs/https?hl=ko#firewall-rules

gcloud compute firewall-rules create sample-gw-lb-web-tcp-http-allow \ --project sample-gw-shared-vpc \ --network sample-gw-shared-vpc-1 \ --action allow \ --direction ingress \ --rules tcp:80,tcp:443 \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --target-tags webserver

고정 외부 IP 주소 할당 (인스턴스 또는 부하 분산기에 연결되지 않은 고정 IP 주소는 더 높은 시간 단위 요금으로 청구됩니다.)

 

로드밸런서 설정 : 프로토콜 선택, 백엔드 구성, 호스트 및 경로 규칙 설정, 프런트엔드 구성

상태 확인을 만듭니다.

백엔드 서비스를 만듭니다.

백엔드 서비스에 인스턴스 그룹을 백엔드로 추가합니다.

 

프런트엔드에서 HTTPS를 사용하는 경우에도 백엔드에서 HTTP를 사용할 수 있습니다. Google은 Google Cloud VPC 네트워크 내에 있는 Google 프런트 엔드(GFE)와 백엔드 간의 트래픽을 자동으로 암호화합니다.

 

연결 드레이닝 connection draining 활성화를 합니다.

연결 드레이닝은 VM이 인스턴스 그룹에서 삭제되거나 엔드포인트가 영역 NEG에서 삭제될 때 진행 중인 기존 요청에 완료될 시간을 제공하는 프로세스입니다. 연결 드레이닝을 사용 설정하려면 백엔드 서비스에서 연결 드레이닝 제한 시간을 설정합니다. 제한 시간은 0~3,600초여야 합니다. 지정된 제한 시간 동안 삭제된 VM 또는 엔드포인트에 대한 기존 요청에 완료할 시간이 제공됩니다. 부하 분산기는 삭제된 VM에 새로운 요청을 보내지 않습니다. 제한 시간에 도달하면 VM에 남아있는 모든 연결이 닫힙니다.
https://cloud.google.com/load-balancing/docs/enabling-connection-draining#gcloud

HTTP 프런트엔드 설정

  1. HTTP의 경우 URL 맵을 만들어 수신 요청을 기본 백엔드 서비스로 라우팅합니다.

  2. HTTP의 경우 대상 HTTP 프록시를 만들어 URL 맵에 요청을 라우팅합니다.

  3. HTTP의 경우 전역 전달 규칙을 만들어 수신 요청을 프록시로 라우팅합니다.

HTTPS 프런트엔드 설정

HTTPS 프런트엔드 설정하기 전에 자체 관리형 SSL 인증서가 없으면 만든다.

자체 관리형 SSL 인증서를 wildcard-sample-co-kr 로 지정한 경우임.

 

 

로드밸런서를 구성한 후 설정한 IP를 통해서 VM의 http나 https 접속이 잘 되는지 확인을 해야 한다.

이제 웹브라우저에서 로드밸런서의 ip 로 잘 접속이 되는지 확인을 한다. nginx 를 사용하는 것이 아니라면 nginx는 삭제를 한다.

 

로드밸런서의 여러 리소스를 한꺼번에 삭제하는 명령어는 없는 것 같음. 웹에서 로드밸런서 지우면 백엔드, 프론트엔드 모두 함께 삭제를 함. https://stackoverflow.com/questions/48930737/how-to-delete-load-balancer-using-gcloud-command

내부 HTTP 부하 분산기

SG

상태 확인 프로버의 모든 TCP 트래픽을 허용. https://cloud.google.com/load-balancing/docs/https?hl=ko#firewall-rules 등의 문서를 보면 구글 로드밸런서의 IP 대역에서의 접근을 허용해야 함.

내부 HTTP(S) 부하 분산기의 프록시를 백엔드에 연결하도록 허용

LB

https://cloud.google.com/load-balancing/docs/l7-internal?hl=ko 내용을 보면 내부 HTTP 부하 분산기는 프록시 전용 서브넷을 만들어야 함.

공유 VPC에서 내부 HTTP 부하분산 설정하는 방법은 https://cloud.google.com/load-balancing/docs/l7-internal/l7-internal-shared-vpc?hl=ko

 

https://cloud.google.com/load-balancing/docs/l7-internal/setting-up-l7-internal?hl=ko

비관리형 인스턴스 그룹 - 로드밸런서 설정

비관리형 인스턴스 그룹 구성

로드밸런서 구성

backend

health-checks의 경우 서버 정상작동 여부를 확인하는 Path가 존재한다면 해당 --request-path옵션으로 설정해주면 된다.

frontend

gcloud compute forwarding-rules create was-lb-forwarding-rule 에서 subnet은 해당 VM 이 있는 sample-gw-was-ne3-dev-subnet 를 이용해야 하며 전달 규칙의 IP 주소(address 옵션) 또한 마찬가지이다.

이제 web 서버에서 WAS - Internal HTTP 로드밸런서로 접속이 잘 되는지 확인을 해본다.

사전에 was 서버에 nginx 를 설치한다.

web 에서 was-lb-forwarding-rule 에 지정하였던 IP로 http 접속을 확인해 보면 된다.

 

로드밸런서 Redirect 설정

로드밸런서의 URL 맵을 사용해 호스트 및 경로 규칙을 설정하고 트래픽의 전달 방식을 결정할 수 있다. 일반 모드의 경우 백엔드 별로 트래픽을 전달할 수 있고 고급 모드를 사용하면 URL을 재작성 하거나 URL을 리다이렉션할 수도 있다.

고급 모드의 호스트/경로 리다이렉션이 아니라면 백엔드 단위로 트래픽을 전달하기 때문에 다른 서버로 트래픽을 전달하고 싶다면 백엔드 서비스를 추가로 생성해야 한다.

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

같은 서버내 다른 포트(80, 3002)로 트래픽을 전달한다고 하면 아래와 같이 구성한다.

  • 인스턴스 그룹에 named-port(80, 3002) 생성

  • 백엔드 서비스 2개 생성 후 각각 다른 named-port로 백엔드 추가

  • 로드밸런서 백엔드 구성에 방금 생성한 백엔드 서비스 2개 같이 지정

  • 호스트 및 경로 규칙을 설정해 규칙에 따라 다른 백엔드로 트래픽이 가도록 설정

 

인스턴스 그룹에 named-port 생성

백엔드 서비스 2개 생성 후 각각 다른 named-port로 백엔드 추가

로드밸런서 백엔드 구성에 방금 생성한 백엔드 서비스 2개 같이 지정

호스트 및 경로 규칙을 설정해 규칙에 따라 다른 백엔드로 트래픽이 가도록 설정

이렇게 하면 Host 기준으로 트래픽을 나눠 보낼수 있다.

HTTP(S) 부하 분산 로깅 및 모니터링

 https://cloud.google.com/load-balancing/docs/https/https-logging-monitoring#logging

LOG 활성화

--enable-logging은 해당 백엔드 서비스의 로깅을 사용 설정. --logging-sample-rate를 사용하면 0.0부터 1.0까지 값을 지정할 수 있습니다. 0.0은 요청이 로깅되지 않음을 의미하고 1.0은 요청이 100% 로깅됨을 의미

https://cloud.google.com/load-balancing/docs/https/https-logging-monitoring#enabling_logging_on_an_existing_backend_service 문서에서는 --load-balancing-scheme 옵션이 들어가 있는데 해당 옵션을 넣으면 작동 안함. https://cloud.google.com/sdk/gcloud/reference/compute/backend-services/update 문서에서도 해당 옵션이 없는 것으로 봐서는 문서가 잘못된 듯 함.

HTTP 부하 분산기 로그보기

로그를 보려면 로그탐색기에서 리소스를 Cloud HTTP 부하 분산기로 선택해서 보면 됨.

 

resource.type="http_load_balancer" 으로 검색.

HttpRequest  에는 http 요청사항이 있음

enforcedSecurityPolicy 에 적용된 policy가 있고 statusDetails 에 부하 분산기가 해당 HTTP 상태를 반환한 이유를 설명하는 문자열이 들어 있다.

아래는 policy를 변경하여 허용을 했다가 거부를 한 경우임.

 

backend 에서 응답한 경우

enforcedSecurityPolicy: {

configuredAction: "ALLOW"

name: "tj-clients-test-policy"

outcome: "ACCEPT"

priority: 1500

}

statusDetails: "response_sent_by_backend"

 

security policy에서 거부를 한 경우

enforcedSecurityPolicy: {

configuredAction: "DENY"

name: "tj-clients-test-policy"

outcome: "DENY"

priority: 1500

}

statusDetails: "denied_by_security_policy"

 

로그탐색기에서 쿼리에 필요한 검색조건을 넣으면 됨. 쿼리 각 줄에 검색 내용을 넣으면 AND 조건이 됨. 각종 연산자에 대한 설명 : https://cloud.google.com/logging/docs/view/logging-query-language

로드밸런서의 로그 보기 : https://cloud.google.com/load-balancing/docs/https/https-logging-monitoring#viewing_logs

로그탐색기 사용 : https://cloud.google.com/logging/docs/view/logs-viewer-interface

 

개발환경에서 외부 http 로드밸런서의 로그 보기

로깅되는 내용

HTTP(S) 부하 분산 로그 항목은 HTTP(S) 트래픽 모니터링과 디버깅에 유용한 정보를 제공합니다. 로그 항목은 다음과 같은 유형의 정보를 담고 있습니다.

  • 심각도, 프로젝트 ID, 프로젝트 번호, 타임스탬프와 같은 일반 정보

  • HttpRequest 로그 필드. 단, HTTP(S) 부하 분산 Cloud Logging 로그의 경우 HttpRequest.protocol이 채워지지 않습니다.

  • structPayload 안의 statusDetails 필드. 이 필드에는 부하 분산기가 해당 HTTP 상태를 반환한 이유를 설명하는 문자열이 들어 있습니다. 아래 표에서 이러한 로그 문자열에 대한 자세한 설명을 확인할 수 있습니다.
    리전 외부 HTTP(S) 부하 분산기에 statusDetails 필드를 사용할 수 없습니다.

  • 부하 분산기에서 발급된 리디렉션(HTTP 응답 상태 코드 302 찾음)은 로깅되지 않습니다. 백엔드 인스턴스에서 발행된 리디렉션은 기록됩니다.

내부 http 로드밸런서의 로그 보기

https://cloud.google.com/load-balancing/docs/l7-internal/monitoring#gcloud

  • 모든 내부 HTTP(S) 부하 분산기의 로그를 보려면 첫 번째 풀다운 메뉴에서 내부 HTTP/S 부하 분산 규칙을 선택합니다.

  • 네트워크 한 개의 로그만 보려면 내부 HTTP/S 부하 분산 규칙을 선택한 다음 네트워크 이름을 선택합니다.

  • 네트워크의 한 리전에 대해서만 로그를 보려면 내부 HTTP/S 부하 분산 규칙 > NETWORK > REGION을 선택합니다.

 

resource.type="internal_http_lb_rule"

SSL 인증서

현재 있는 SSL 인증서에서 인증서, private key 파일을 만든다.

https://cloud.google.com/load-balancing/docs/ssl-certificates/self-managed-certs#gcloud

gcloud 를 이용하여 인증서 파일, private key 파일을 이용하여 자체 관리형 SSL 인증서를 만든다.

추가한 인증서 확인

 

 

SSL 인증서를 대상 프록시와 연결한다.

target-https-proxies, forwarding-rules 을 생성.

아래는 테스팅을 하던 내용임.

https 로 호출을 하여 확인을 함.