내부 HTTP(S) 부하 분산 설정

이 문서에서는 Compute Engine VM에서 실행되는 서비스에 대해 내부 HTTP(S) 부하 분산을 구성하는 방법을 설명합니다.

GKE pod에서 실행되는 서비스에 대한 부하 분산을 구성하려면 독립형 NEG를 사용한 컨테이너 기반 부하 분산내부 HTTP(S) 부하 분산기를 독립형 NEG에 연결을 참조하세요.

내부 HTTP(S) 부하 분산 설정에는 다음 두 단계가 있습니다.

  • 필요한 계정에 올바른 권한이 있는지 확인하고 Virtual Private Cloud(VPC) 네트워크를 준비하는 등의 필수 작업을 수행합니다.
  • 부하 분산기 리소스 설정

이 가이드를 진행하기 전에 다음 사항을 숙지하세요.

권한

이 가이드를 진행하려면 프로젝트에서 인스턴스를 만들고 네트워크를 수정할 수 있어야 합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나 다음 Compute Engine IAM 역할을 모두 보유해야 합니다.

작업 필요한 역할
네트워크, 서브넷, 부하 분산기 구성요소 만들기 네트워크 관리자
방화벽 규칙 추가 및 삭제 보안 관리자
인스턴스 만들기 인스턴스 관리자

자세한 내용은 다음 가이드를 참조하세요.

설정 개요

다음과 같은 상위 수준 구성 흐름에서 설명하는 대로 내부 HTTP(S) 부하 분산을 구성할 수 있습니다. 번호가 매겨진 단계는 다이어그램의 번호를 나타냅니다.

내부 HTTP(S) 부하 분산 번호가 매겨진 구성요소(확대하려면 클릭)
내부 HTTP(S) 부하 분산 번호가 매겨진 구성요소(확대하려면 클릭)

다이어그램에서 볼 수 있듯이 이 예시에서는 하나의 백엔드 서비스와 두 개의 백엔드 그룹이 있는 us-west1 리전의 VPC 네트워크에 내부 HTTP(S) 부하 분산기를 만듭니다.

다이어그램에 표시된 항목은 다음과 같습니다.

  1. 두 개의 서브넷이 있는 VPC 네트워크:

    1. 서브넷 하나는 백엔드(인스턴스 그룹 및 NEG) 및 전달 규칙에 사용됩니다. 기본 IP 주소 범위는 10.1.2.0/24입니다.

    2. 다른 서브넷은 us-west1 리전의 프록시 전용 서브넷입니다. 내부 HTTP 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 하나의 프록시 전용 서브넷을 만들어야 합니다. 해당 리전의 프록시 전용 서브넷은 해당 리전의 모든 내부 HTTP 부하 분산기 간에 공유됩니다. 내부 HTTP(S) 부하 분산기에서 서비스의 백엔드로 보낸 패킷의 소스 주소는 프록시 전용 서브넷에서 할당됩니다. 이 예시에서 리전의 프록시 전용 서브넷의 기본 IP 주소 범위는 권장 서브넷 크기인 10.129.0.0/23입니다. 자세한 내용은 내부 HTTP(S) 부하 분산기용 프록시 전용 서브넷을 참조하세요.

  2. 네트워크에서 프록시 전용 서브넷 트래픽 흐름을 허용하는 방화벽 규칙입니다. 즉, 10.129.0.0/23의 TCP 포트 80, 443, 8080 트래픽을 허용하는 하나의 규칙을 추가합니다. 상태 확인 프로브의 또 다른 방화벽 규칙입니다.

  3. 백엔드 인스턴스. 이 예시 다이어그램은 다음 백엔드 배포를 보여줍니다.

    1. Compute Engine VM
    2. 독립형 네트워크 엔드포인트 그룹(NEG)에 추가된 Google Kubernetes Engine(GKE) 백엔드
  4. 인스턴스 그룹 및 NEG:

    1. Compute Engine VM 배포를 위한 관리형 또는 비관리형 인스턴스 그룹
    2. GKE 배포를 위한 NEG

    각 영역에서 배포 요구 사항에 따라 여러 백엔드 그룹 유형을 조합할 수 있습니다.

  5. 백엔드 준비 상태를 보고하는 리전별 상태 확인입니다.

  6. 백엔드의 사용 및 상태를 모니터링하는 리전별 백엔드 서비스입니다.

  7. 리전별 URL 맵은 요청의 URL을 파싱하고 요청 URL의 호스트와 경로에 따라 특정 백엔드 서비스로 요청을 전달합니다.

  8. 사용자로부터 요청을 수신하여 URL 맵에 전달하는 리전별 대상 HTTP 또는 HTTPS 프록시입니다. HTTPS의 경우 리전별 SSL 인증서 리소스를 구성합니다. HTTPS 부하 분산을 구성할 경우 대상 프록시는 SSL 인증서를 사용하여 SSL 트래픽을 복호화합니다. 대상 프록시는 HTTP나 HTTPS를 사용하여 트래픽을 인스턴스에 전달할 수 있습니다.

  9. 각 수신 요청을 대상 프록시로 전달하기 위한 부하 분산기의 내부 IP 주소를 가진 전달 규칙입니다.

네트워크 및 서브넷 구성하기

부하 분산기의 백엔드를 위한 서브넷 한 개와 부하 분산기의 프록시를 위한 서브넷 한 개, 총 두 개 서브넷이 있는 VPC 네트워크가 필요합니다. 내부 HTTP(S) 부하 분산기는 리전 기준입니다. 트래픽 소스가 부하 분산기와 동일한 리전의 서브넷에 있는 경우 VPC 네트워크 내의 트래픽이 부하 분산기로 라우팅됩니다.

이 예시에서는 다음 VPC 네트워크, 리전 및 서브넷을 사용합니다.

  • 네트워크. 네트워크는 커스텀 모드 VPC 네트워크이며 이름은 lb-network입니다.

  • 백엔드 서브넷. us-west1 리전에 있는 backend-subnet이라는 이름의 서브넷은 기본 IP 범위로 10.1.2.0/24를 사용합니다.

  • 프록시 서브넷. us-west1 리전에 있는 proxy-only-subnet이라는 이름의 서브넷은 기본 IP 범위로 10.129.0.0/23을 사용합니다.

백엔드 네트워크 및 서브넷 구성

Cloud Console

  1. Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.
    VPC 네트워크 페이지로 이동
  2. VPC 네트워크 만들기를 클릭합니다.
  3. 이름lb-network를 입력합니다.
  4. 서브넷 섹션에서 다음을 수행합니다.
    • 서브넷 생성 모드커스텀으로 설정합니다.
    • 새 서브넷 섹션에 다음 정보를 입력합니다.
      • 이름: backend-subnet
      • 리전: us-west1
      • IP 주소 범위: 10.1.2.0/24
    • 완료를 클릭합니다.
  5. 만들기를 클릭합니다.

gcloud

  1. gcloud compute networks create 명령어를 사용하여 커스텀 VPC 네트워크를 만듭니다.

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. gcloud compute networks subnets create 명령어를 사용하여 us-west1 리전의 lb-network 네트워크에 서브넷을 만듭니다.

    gcloud compute networks subnets create backend-subnet \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-west1
    

API

networks.insert 메서드에 대해 POST 요청을 수행합니다. 여기서 project-id는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/project-id/global/networks

{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

subnetworks.insert 메서드에 대해 POST 요청을 수행합니다. 여기서 project-id는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks

{
  "name": "backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "region": "projects/project-id/regions/us-west1",
}

프록시 전용 서브넷 구성

프록시 전용 서브넷은 us-west1 리전의 모든 내부 HTTP(S) 부하 분산기에 사용됩니다.

Cloud Console

Google Cloud Console을 사용하는 경우에는 기다렸다가 나중에 부하 분산 페이지에서 프록시 전용 서브넷을 만들 수 있습니다.

gcloud

gcloud compute networks subnets create 명령어로 프록시 전용 서브넷을 만듭니다.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

subnetworks.insert 메서드로 프록시 전용 서브넷을 만듭니다. 여기서 project-id는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/projects/project-id/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

방화벽 규칙 구성

이 예시에서는 다음과 같은 방화벽 규칙을 사용합니다.

  • fw-allow-ssh. 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로 TCP 포트 22에 임의의 주소로부터 수신되는 SSH 연결을 허용합니다. 이 규칙에 더 제한적인 소스 IP 범위를 선택할 수 있습니다. 예를 들어 SSH 세션을 시작할 시스템의 IP 범위만 지정할 수도 있습니다. 이 예시에서는 allow-ssh 대상 태그를 사용하여 방화벽 규칙이 적용되는 VM을 식별합니다.

  • fw-allow-health-check. 부하 분산된 인스턴스에 적용되는 인그레스 규칙으로 Google Cloud 상태 확인 시스템(130.211.0.0/2235.191.0.0/16)의 모든 TCP 트래픽을 허용합니다. 이 예시에서는 load-balanced-backend 대상 태그를 사용하여 인그레스 규칙을 적용해야 할 인스턴스를 식별합니다.

  • fw-allow-proxies. 부하 분산되는 인스턴스에 적용되는 인그레스 규칙입니다. 내부 HTTP(S) 부하 분산기의 관리형 프록시로부터의 포트 80, 443, 8080 TCP 트래픽을 허용합니다. 이 예시에서는 load-balanced-backend 대상 태그를 사용하여 방화벽 규칙이 적용되는 인스턴스를 식별합니다.

이러한 방화벽 규칙이 없으면 기본 거부 인그레스 규칙은 백엔드 인스턴스로 들어오는 트래픽을 차단합니다.

Cloud Console

  1. Google Cloud Console에서 방화벽 규칙 페이지로 이동합니다.
    방화벽 규칙 페이지로 이동
  2. 방화벽 규칙 만들기를 클릭하여 수신 SSH 연결을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-ssh
    • 네트워크: lb-network
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-ssh
    • 소스 필터: IP ranges
    • 소스 IP 범위: 0.0.0.0/0
    • 프로토콜 및 포트:
      • 지정된 프로토콜 및 포트를 선택합니다.
      • tcp를 확인하고 포트 번호에 22를 입력합니다.
  3. 만들기를 클릭합니다.
  4. 방화벽 규칙 만들기를 다시 한 번 클릭하여 Google Cloud 상태 확인을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-health-check
    • 네트워크: lb-network
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: load-balanced-backend
    • 소스 필터: IP ranges
    • 소스 IP 범위: 130.211.0.0/2235.191.0.0/16
    • 프로토콜 및 포트:
      • 지정된 프로토콜 및 포트를 선택합니다.
      • tcp를 확인하고 80을 입력합니다.
        권장사항에 따라서 상태 확인에 사용되는 것과 일치하는 프로토콜 및 포트로 이러한 규칙을 제한합니다. 프로토콜 및 포트에 tcp:80을 사용하면 Google Cloud가 포트 80에서 HTTP를 사용하여 VM에 연결할 수 있지만 포트 443에서 HTTPS를 사용하여 연결할 수는 없습니다.
  5. 만들기를 클릭합니다.
  6. 방화벽 규칙 만들기를 세 번째로 클릭하여 부하 분산기의 프록시 서버를 백엔드에 연결하도록 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-proxies
    • 네트워크: lb-network
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: load-balanced-backend
    • 소스 필터: IP ranges
    • 소스 IP 범위: 10.129.0.0/23
    • 프로토콜 및 포트:
      • 지정된 프로토콜 및 포트를 선택합니다.
      • tcp를 확인하고 포트 번호에 80, 443, 8080을 입력합니다.
  7. 만들기를 클릭합니다.

gcloud

  1. allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용하는 fw-allow-ssh 방화벽 규칙을 만듭니다. source-ranges를 생략하면 Google Cloud가 모든 소스를 의미하는 것으로 규칙을 해석합니다.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. fw-allow-health-check 규칙을 만들어 Google Cloud 상태 확인을 허용합니다. 이 예시에서는 상태 확인 프로버의 모든 TCP 트래픽을 허용합니다. 그러나 필요에 따라 더 좁은 포트 집합을 구성할 수 있습니다.

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. 내부 HTTP(S) 부하 분산기의 프록시를 백엔드에 연결하도록 허용하는 fw-allow-proxies 규칙을 만듭니다.

    gcloud compute firewall-rules create fw-allow-proxies \
      --network=lb-network \
      --action=allow \
      --direction=ingress \
      --source-ranges=10.129.0.0/23 \
      --target-tags=load-balanced-backend \
      --rules=tcp:80,tcp:443,tcp:8080
    

API

firewalls.insert 메서드에 POST 요청을 수행하여 fw-allow-ssh 방화벽 규칙을 만듭니다. 여기서 project-id는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/project-id/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

firewalls.insert 메서드에 POST 요청을 수행하여 fw-allow-health-check 방화벽 규칙을 만듭니다. 여기서 project-id는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/project-id/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

firewalls.insert 메서드에 대해 프록시 서브넷 내에서 TCP 트래픽을 허용하도록 fw-allow-proxies 방화벽 규칙을 만듭니다. 여기서 project-id는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8080"
      ]
    }
  ],
  "direction": "INGRESS"
}

VM 기반 서비스로 내부 HTTP(S) 부하 분산 구성

이 섹션에서는 Compute Engine VM에서 실행되는 서비스에 필요한 구성을 보여줍니다. 클라이언트 VM은 전달 규칙에 구성된 IP 주소와 포트에 연결합니다. 클라이언트 애플리케이션에서 이 IP 주소 및 포트로 트래픽을 전송할 때 내부 HTTP(S) 부하 분산기의 URL 맵에 따라 요청이 가상 머신(VM)으로 전달됩니다.

이 페이지의 예시에서는 임시 내부 IP 주소 할당을 허용하는 대신 내부 HTTP(S) 부하 분산기의 전달 규칙에 예약된 내부 IP 주소를 명시적으로 설정합니다. 권장사항에 따라서 전달 규칙에 IP 주소를 예약하는 것이 좋습니다.

전달 규칙의 IP 주소는 backend-subnet을 사용합니다. 프록시 전용 서브넷을 사용하려고 하면 전달 규칙 생성에 실패합니다.

관리형 인스턴스 그룹 만들기

이 섹션에서는 템플릿 및 관리형 인스턴스 그룹 생성 방법을 보여줍니다. 관리형 인스턴스 그룹은 내부 HTTP(S) 부하 분산기 예시의 백엔드 서버를 실행하는 VM 인스턴스를 제공합니다. 클라이언트에서 전송된 트래픽은 이러한 백엔드 서버로 부하 분산됩니다. 여기에서는 데모용으로 백엔드에서 자체 호스트 이름을 제공합니다.

Cloud Console

  1. Cloud Console에서 인스턴스 그룹 페이지로 이동합니다.

    인스턴스 그룹 페이지로 이동

  2. 인스턴스 그룹 만들기를 클릭합니다.
  3. 왼쪽에서 새 관리형 인스턴스 그룹을 선택합니다.
  4. 이름l7-ilb-backend-example을 입력합니다.
  5. 위치에서 단일 영역을 선택합니다.
  6. 리전으로 us-west1을 선택합니다.
  7. 영역으로 us-west1-a를 선택합니다.
  8. 인스턴스 템플릿에서 새 인스턴스 템플릿 만들기를 선택합니다.

    1. 이름l7-ilb-backend-template을 입력합니다.
    2. 부팅 디스크가 Debian GNU/Linux 9(stretch)와 같은 Debian 이미지로 설정되었는지 확인합니다. 이 안내에서는 apt-get처럼 Debian에서만 사용할 수 있는 명령어를 사용합니다.
    3. 관리 탭의 관리, 보안, 디스크, 네트워킹, 단독 테넌시에서 시작 스크립트 필드에 다음 스크립트를 삽입합니다

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'
      
    4. 네트워킹에서 네트워크lb-network를, 서브넷으로 backend-subnet을 선택합니다.

    5. allow-sshload-balanced-backend 네트워크 태그를 추가합니다.

    6. 저장 후 계속을 클릭합니다.

  9. 그룹에 만들 인스턴스의 수를 지정합니다.

    이 예시에서는 자동 확장 모드에서 다음을 선택할 수 있습니다.

    • 자동 확장 구성 안함
    • 인스턴스 수2를 입력합니다.

    원할 경우 UI의 자동 확장 섹션에서 인스턴스 그룹을 구성하여 인스턴스 CPU 사용량을 기준으로 인스턴스를 자동 추가 또는 삭제할 수 있습니다.

  10. 만들기를 클릭하여 새 인스턴스 그룹을 만듭니다.

gcloud

이 가이드의 gcloud 안내에서는 Cloud Shell 또는 bash가 설치된 다른 환경을 사용한다고 가정합니다.

  1. gcloud compute instance-templates create 명령어로 HTTP 서버가 포함된 VM 인스턴스 템플릿을 만듭니다.

    gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'
    
  2. gcloud compute instance-groups managed create 명령어로 영역에 관리형 인스턴스 그룹을 만듭니다.

    gcloud compute instance-groups managed create l7-ilb-backend-example \
        --zone=us-west1-a \
        --size=2 \
        --template=l7-ilb-backend-template
    

API

instanceTemplates.insert 메서드로 인스턴스 템플릿을 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/instanceTemplates
{
  "name":"l7-ilb-backend-template",
  "properties":{
     "machineType":"n1-standard-1",
     "tags":{
        "items":[
           "allow-ssh",
           "load-balanced-backend"
        ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
              "key":"startup-script",
              "value":"#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
           "network":"projects/[project-id]/global/networks/lb-network",
           "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
           "accessConfigs":[
             {
                 "type":"ONE_TO_ONE_NAT"
             }
           ]
       }
     ],
     "disks":[
       {
           "index":0,
           "boot":true,
           "initializeParams":{
              "sourceImage":"projects/debian-cloud/global/images/family/debian-9"
           },
           "autoDelete":true
       }
     ]
  }
}

instanceGroupManagers.insert 메서드로 각 영역에 관리형 인스턴스 그룹을 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/zones/{zone}/instanceGroupManagers
{
  "name": "l7-ilb-backend-example",
  "zone": "projects/[project-id]/zones/us-west1-a",
  "instanceTemplate": "projects/[project-id]/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

부하 분산기 구성

이 예시에서는 다음 내부 HTTP(S) 부하 분산기 리소스를 만드는 방법을 보여줍니다.

  • HTTP 상태 확인
  • 관리형 인스턴스 그룹이 백엔드인 백엔드 서비스
  • URL 맵
    • 대상 HTTP(S) 프록시에 리전이 정의되어 있으면 리전별 URL 맵을 참조해야 합니다. 리전별 URL 맵은 수신 URL의 호스트 및 경로에 대해 정의한 규칙에 따라 리전별 백엔드 서비스로 요청을 라우팅합니다. 리전별 URL 맵은 동일한 리전의 리전별 대상 프록시 규칙에서만 참조할 수 있습니다.
  • SSL 인증서(HTTPS용)
  • 대상 프록시
  • 전달 규칙

전달 규칙의 IP 주소는 backend-subnet을 사용합니다. 프록시 전용 서브넷을 사용하려고 하면 전달 규칙 생성에 실패합니다.

프록시 가용성

경우에 따라 Google Cloud 리전에 새로운 내부 HTTP(S) 부하 분산기의 프록시 용량이 부족할 수 있습니다. 이 경우 부하 분산기를 만들 때 Cloud Console에서 프록시 가용성 경고 메시지를 제공합니다. 이 문제를 해결하려면 다음 중 하나를 수행하면 됩니다.

  • 부하 분산기에 다른 리전을 선택합니다. 다른 리전에 백엔드가 있으면 이 방법이 편리합니다.
  • 프록시 전용 서브넷이 이미 할당된 VPC 네트워크를 사용합니다.
  • 용량 문제가 해결될 때까지 기다립니다.

Cloud Console

부하 분산기 유형 선택

  1. Google Cloud Console의 부하 분산 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. HTTP(S) 부하 분산에서 구성 시작을 클릭합니다.
  3. VM 사이에서만 분산을 선택합니다. 이 설정은 부하 분산기가 내부용이라는 의미입니다.
  4. 계속을 클릭합니다.

부하 분산기 준비

  1. 부하 분산기 이름l7-ilb-map을 입력합니다.
  2. 리전으로 us-west1을 선택합니다.
  3. 네트워크lb-network를 선택합니다.
  4. 계속하려면 창을 열어둡니다.

프록시 전용 서브넷 예약

내부 HTTP(S) 부하 분산의 경우 다음과 같이 프록시 서브넷을 예약합니다.

  1. 서브넷 예약을 클릭합니다.
  2. 이름proxy-only-subnet을 입력합니다.
  3. IP 주소 범위10.129.0.0/23을 입력합니다.
  4. 추가를 클릭합니다.

백엔드 서비스 구성

  1. 백엔드 구성을 클릭합니다.
  2. 백엔드 서비스 만들기 또는 선택 메뉴에서 백엔드 서비스 만들기를 선택합니다.
  3. 백엔드 서비스의 이름l7-ilb-backend-service로 설정합니다.
  4. 백엔드 유형인스턴스 그룹으로 설정합니다.
  5. 새 백엔드 섹션에서 다음을 수행합니다.
    1. 인스턴스 그룹l7-ilb-backend-example로 설정합니다.
    2. 포트 번호80으로 설정합니다.
    3. 분산 모드사용률로 설정합니다.
    4. 완료를 클릭합니다.
  6. 상태 확인 섹션에서 상태 확인 만들기의 매개변수를 다음과 같이 선택합니다.
    1. 이름: l7-ilb-basic-check
    2. 프로토콜: HTTP
    3. 포트: 80
    4. 저장 후 계속을 클릭합니다.
  7. 만들기를 클릭합니다.

URL 맵 구성

호스트 및 경로 규칙을 클릭합니다. l7-ilb-backend-service가 일치하지 않는 모든 호스트 및 일치하지 않는 모든 경로에 대한 유일한 백엔드 서비스입니다.

트래픽 관리에 대한 자세한 내용은 트래픽 관리 설정을 참조하세요.

프런트엔드 구성

HTTP의 경우:

  1. 프런트엔드 구성을 클릭합니다.
  2. 프런트엔드 IP 및 포트 추가를 클릭합니다.
  3. 이름l7-ilb-forwarding-rule로 설정합니다.
  4. 프로토콜HTTP로 설정합니다.
  5. 서브네트워크backend-subnet으로 설정합니다.
  6. 내부 IP에서 고정 내부 IP 주소 예약을 선택합니다.
  7. 표시되는 패널에 다음 세부정보를 입력합니다.
    1. 이름: l7-ilb-ip
    2. 고정 IP 주소 섹션에서 직접 선택을 선택합니다.
    3. 커스텀 IP 주소 섹션에 10.1.2.99를 입력합니다.
    4. 예약을 클릭합니다.
  8. 포트80으로 설정합니다.
  9. 완료를 클릭합니다.

HTTPS의 경우:

클라이언트와 부하 분산기 사이에 HTTPS를 사용하는 경우 프록시를 구성할 하나 이상의 SSL 인증서 리소스가 필요합니다. SSL 인증서 리소스를 만드는 방법에 대한 자세한 내용은 SSL 인증서를 참조하세요. 내부 HTTP(S) 부하 분산기에서는 현재 Google 관리 인증서가 지원되지 않습니다.

  1. 프런트엔드 구성을 클릭합니다.
  2. 프런트엔드 IP 및 포트 추가를 클릭합니다.
  3. 이름 필드에 l7-ilb-forwarding-rule을 입력합니다.
  4. 프로토콜 필드에서 HTTPS (includes HTTP/2)를 선택합니다.
  5. 서브네트워크backend-subnet으로 설정합니다.
  6. 내부 IP에서 고정 내부 IP 주소 예약을 선택합니다.
  7. 표시되는 패널에 다음 세부정보를 입력합니다.
    1. 이름: l7-ilb-ip
    2. 고정 IP 주소 섹션에서 직접 선택을 선택합니다.
    3. 커스텀 IP 주소 섹션에 10.1.2.99를 입력합니다.
    4. 예약을 클릭합니다.
  8. HTTPS 트래픽을 허용하도록 포트443으로 설정되어 있는지 확인합니다.
  9. 인증서 드롭다운 목록을 클릭합니다.
    1. 이미 기본 SSL 인증서로 사용할 자체 관리형 SSL 인증서 리소스가 있다면 드롭다운 메뉴에서 선택합니다.
    2. 그 이외의 경우 새 인증서 만들기를 선택합니다.
      1. l7-ilb-cert이름을 입력합니다.
      2. 해당 필드에 다음 PEM 형식의 파일을 업로드합니다.
        • 공개 키 인증서
        • 인증서 체인
        • 비공개 키
      3. 만들기를 클릭합니다.
  10. 기본 SSL 인증서 리소스 외에 인증서 리소스를 추가하려면 다음 안내를 따르세요.
    1. 인증서 추가를 클릭합니다.
    2. 인증서 목록에서 인증서를 선택하거나 새 인증서 만들기를 클릭하고 위의 안내를 따릅니다.
  11. 완료를 클릭합니다.

구성 완료

만들기를 클릭합니다.

gcloud

  1. gcloud compute health-checks create http 명령어로 HTTP 상태 확인을 정의합니다.

    gcloud compute health-checks create http l7-ilb-basic-check \
       --region=us-west1 \
       --use-serving-port
    
  2. gcloud compute backend-services create 명령어로 백엔드 서비스를 정의합니다.

    gcloud compute backend-services create l7-ilb-backend-service \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=l7-ilb-basic-check \
      --health-checks-region=us-west1 \
      --region=us-west1
    
  3. gcloud compute backend-services add-backend 명령어로 백엔드 서비스에 백엔드를 추가합니다.

    gcloud compute backend-services add-backend l7-ilb-backend-service \
      --balancing-mode=UTILIZATION \
      --instance-group=l7-ilb-backend-example \
      --instance-group-zone=us-west1-a \
      --region=us-west1
    
  4. gcloud compute url-maps create 명령어로 URL 맵을 만듭니다.

    gcloud compute url-maps create l7-ilb-map \
      --default-service=l7-ilb-backend-service \
      --region=us-west1
    
  5. 대상 프록시를 만듭니다.

    HTTP의 경우:

    내부 HTTP 부하 분산기의 경우 gcloud compute target-http-proxies create 명령어로 대상 프록시를 만듭니다.

    gcloud compute target-http-proxies create l7-ilb-proxy \
      --url-map=l7-ilb-map \
      --url-map-region=us-west1 \
      --region=us-west1
    

    HTTPS의 경우:

    SSL 인증서 리소스를 만드는 방법에 대한 자세한 내용은 SSL 인증서를 참조하세요. 내부 HTTP(S) 부하 분산기에서는 현재 Google 관리 인증서가 지원되지 않습니다.

    파일 경로를 변수 이름에 할당합니다.

    export LB_CERT=path to PEM-formatted file
    
    export LB_PRIVATE_KEY=path to PEM-formatted file
    

    gcloud compute ssl-certificates create 명령어를 사용하여 리전별 SSL 인증서를 만듭니다.

    gcloud compute ssl-certificates create l7-ilb-cert \
      --certificate=$LB_CERT \
      --private-key=$LB_PRIVATE_KEY \
      --region=us-west1
    

    리전별 SSL 인증서를 사용하여 gcloud compute target-https-proxies create 명령어로 대상 프록시를 만듭니다.

    gcloud compute target-https-proxies create l7-ilb-proxy \
      --url-map=l7-ilb-map \
      --region=us-west1 \
      --ssl-certificates=l7-ilb-cert
    
  6. 전달 규칙을 만듭니다.

    커스텀 네트워크의 경우 전달 규칙에서 서브넷을 참조해야 합니다. 이때 참조할 서브넷은 프록시 서브넷이 아니라 VM 서브넷입니다.

    HTTP의 경우:

    올바른 플래그와 함께 gcloud compute forwarding-rules create 명령어를 사용합니다.

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=lb-network \
      --subnet=backend-subnet \
      --address=10.1.2.99 \
      --ports=80 \
      --region=us-west1 \
      --target-http-proxy=l7-ilb-proxy \
      --target-http-proxy-region=us-west1
    

    HTTPS의 경우:

    올바른 플래그와 함께 gcloud compute forwarding-rules create 명령어를 사용하여 전달 규칙을 만듭니다.

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=lb-network \
      --subnet=backend-subnet \
      --address=10.1.2.99 \
      --ports=443 \
      --region=us-west1 \
      --target-https-proxy=l7-ilb-proxy \
      --target-https-proxy-region=us-west1
    

API

regionHealthChecks.insert 메서드에 POST 요청을 수행하여 상태 확인을 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/[project-id]/regions/{region}/healthChecks
{
  "name": "l7-ilb-basic-check",
  "type": "HTTP",
  "httpHealthCheck": {
    "portSpecification": "USE_SERVING_PORT"
  }
}

regionBackendServices.insert 메서드에 POST 요청을 수행하여 리전별 백엔드 서비스를 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/backendServices
{
  "name": "l7-ilb-backend-service",
  "backends": [
    {
      "group": "projects/[project-id]/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
      "balancingMode": "UTILIZATION"
    }
  ],
  "healthChecks": [
    "projects/[project-id]/regions/us-west1/healthChecks/l7-ilb-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

regionUrlMaps.insert 메서드에 POST 요청을 수행하여 URL 맵을 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/urlMaps
{
  "name": "l7-ilb-map",
  "defaultService": "projects/[project-id]/regions/us-west1/backendServices/l7-ilb-backend-service"
}

regionTargetHttpProxies.insert 메서드에 POST 요청을 수행하여 대상 HTTP 프록시를 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/targetHttpProxy
{
  "name": "l7-ilb-proxy",
  "urlMap": "projects/[project-id]/global/urlMaps/l7-ilb-map",
  "region": "us-west1"
}

forwardingRules.insert 메서드에 POST 요청을 수행하여 전달 규칙을 만듭니다. 여기서 [project-id]는 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/forwardingRules
{
  "name": "l7-ilb-forwarding-rule",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/[project-id]/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/[project-id]/regions/us-west1/subnetworks/backend-subnet",
  "network": "projects/[project-id]/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

테스트

VM 인스턴스를 생성하여 연결 테스트

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

부하 분산기 테스트

위에서 만든 인스턴스에 로그인한 후 내부 HTTP(S) 부하 분산기의 전달 규칙 IP 주소를 통해 백엔드의 HTTP(S) 서비스에 연결할 수 있는지와 백엔드 인스턴스 전체에 트래픽이 부하 분산되는지 테스트합니다.

각 클라이언트 인스턴스에 SSH를 통해 연결

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

IP의 호스트 이름 제공 여부 확인

curl 10.1.2.99

HTTPS 테스트의 경우 curl을 다음으로 바꿉니다.

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443

-k 플래그로 인해 curl이 인증서 유효성 검사를 건너뜁니다.

100개의 요청 실행 및 부하 분산 여부 확인

HTTP의 경우:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

HTTPS의 경우:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

추가 구성 옵션

이 섹션에서는 대체 및 추가 구성 옵션을 제공하는 구성 예시를 살펴봅니다. 모든 작업은 선택사항입니다. 원하는 순서대로 수행할 수 있습니다.

세션 어피니티 사용 설정

이 절차에서는 백엔드 서비스가 생성된 쿠키 어피니티, 헤더 필드 어피니티 또는 HTTP 쿠키 어피니티를 사용하도록 예시 내부 HTTP(S) 부하 분산기의 백엔드 서비스를 업데이트하는 방법을 보여줍니다.

생성된 쿠키 어피니티가 사용 설정되면 부하 분산기는 첫 번째 요청에서 쿠키를 생성합니다. 동일한 쿠키를 사용하는 각 후속 요청의 경우 부하 분산기는 같은 백엔드 VM 또는 엔드포인트로 요청을 전달합니다. 내부 HTTP 부하 분산기의 경우 쿠키는 이름이 GCILB로 지정됩니다.

헤더 필드 어피니티가 사용 설정되면 부하 분산기는 --custom-request-header 플래그에 이름이 지정된 HTTP 헤더의 값에 따라 NEG의 백엔드 VM 또는 엔드포인트로 요청을 라우팅합니다. 헤더 필드 어피니티는 부하 분산 지역 정책이 RING_HASH 또는 MAGLEV이고 백엔드 서비스의 일관된 해시가 HTTP 헤더의 이름을 지정하는 경우에만 유효합니다.

HTTP 쿠키 어피니티가 사용 설정되면 부하 분산기는 선택 사항인 --affinity-cookie-ttl 플래그와 함께 HTTP_COOKIE 플래그에 이름이 지정된 HTTP 쿠키에 따라 NEG의 백엔드 VM 또는 엔드포인트로 요청을 라우팅합니다. 클라이언트가 HTTP 요청에 쿠키를 제공하지 않으면 프록시가 쿠키를 생성하여 Set-Cookie 헤더에 있는 클라이언트로 반환합니다. HTTP 쿠키 어피니티는 부하 분산 지역 정책이 RING_HASH 또는 MAGLEV이고 백엔드 서비스의 일관된 해시가 HTTP 쿠키를 지정하는 경우에만 유효합니다.

Cloud Console

백엔드 서비스의 세션 어피니티를 사용 설정하거나 변경하려면 다음 안내를 따르세요.

  1. Google Cloud Console의 부하 분산 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. 백엔드를 클릭합니다.
  3. l7-ilb-backend-service(이 예시에서 만든 백엔드 서비스 이름)를 클릭하고 수정을 클릭합니다.
  4. 백엔드 서비스 세부정보 페이지에서 고급 구성을 클릭합니다.
  5. 세션 어피니티에서 원하는 세션 어피니티 유형을 선택합니다.
  6. 업데이트를 클릭합니다.

gcloud

다음 gcloud 명령어를 사용하여 l7-ilb-backend-service 백엔드 서비스를 다른 유형의 세션 어피니티로 업데이트합니다.

gcloud compute backend-services update l7-ilb-backend-service \
    --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP]
    --region=us-west1

API

세션 어피니티를 설정하려면 regionBackendServices/patch 메서드에 PATCH 요청을 수행합니다.

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service
{
  "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
}

다음 단계