Compute Engine 및 Cloud Storage를 사용하여 복구 가능한 웜 웹 서버 배포

Last reviewed 2021-06-23 UTC

---

이 문서는 운영팀 및 관리팀에 근무하는 설계자와 사용자를 대상으로 합니다. 이 문서에서는 Google Cloud에서 고유한 배포에 사용할 수 있는 패턴의 예시를 설명합니다.

이 아키텍처에서 부하 분산기는 콘텐츠를 제공하는 관리형 인스턴스 그룹의 Compute Engine 인스턴스로 트래픽을 전달합니다. 서비스 중단 시 외부 애플리케이션 부하 분산기 구성을 업데이트하고 Cloud Storage의 정적 사이트로 장애 조치합니다.

이 솔루션을 배포하려면 본인이 제어하고 있으며 이 문서에서 사용하려는 등록된 도메인 이름이 필요합니다.

프로덕션 배포 시 웹사이트에는 이 문서에 나와 있는 것보다 더 많은 파일과 관리형 인스턴스 그룹 가상 머신(VM)의 추가 애플리케이션 코드가 포함될 수 있습니다. 그러면 Cloud Storage가 최소한의 기능을 제공하는 보다 제한된 정적 버전을 호스팅합니다. 웜 장애 조치 시나리오에서는 관리형 인스턴스 그룹이 복구되고 전체 웹사이트 환경을 위해 트래픽을 제공할 수 있을 때까지 사용자에게 이 제한된 웹사이트가 표시됩니다.

아키텍처

이 아키텍처에서는 다음 이미지와 같이 리소스를 배포하여 환경을 만듭니다.

장애 조치를 수행해야 하는 경우 다음 이미지와 같이 Cloud Storage로 트래픽을 보내도록 부하 분산기 구성을 업데이트합니다.

이 웜 장애 조치 패턴은 기본 리전에 장애가 발생할 때만 사용하는 다른 리전에서 다른 관리형 인스턴스 그룹을 실행하는 비용의 균형을 맞춥니다. Cloud Storage를 사용하는 정적 사이트의 비용은 다른 관리형 인스턴스 그룹을 실행하는 비용보다 저렴하지만 호스팅 옵션 간 부하 분산기 구성을 업데이트할 때 약간의 지연이 발생합니다. Cloud Storage의 제한된 웹사이트 환경은 사용할 수 없는 웹사이트와 열악한 고객 경험을 제공하는 것보다 낫습니다.

장애 조치 제어를 위해 외부 애플리케이션 부하 분산기 대신 Cloud DNS를 사용하는 대체 접근 방법은 Compute Engine 및 Cloud Storage와 함께 Cloud DNS를 사용하여 복구 가능한 웜 웹 서버 배포를 참조하세요. 이 패턴은 Cloud DNS가 있거나 이를 사용하려는 경우에 유용합니다.

Google Cloud에서 안정적인 애플리케이션을 실행하려면 서비스 중단을 처리하도록 애플리케이션 인프라를 설계하는 것이 좋습니다. 애플리케이션 및 비즈니스 요구사항에 따라 콜드 장애 조치, 웜 장애 조치 또는 핫 장애 조치 패턴이 필요할 수 있습니다. 고유 애플리케이션별로 최적의 방법을 결정하는 방법에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.

이 문서에서는 기본 Apache 웹 서버를 사용하지만 인프라 배포에 적용되는 동일한 접근 방식이 만들어야 하는 다른 애플리케이션 환경에도 적용됩니다.

목표

• 커스텀 VM 이미지를 사용하여 리전 관리형 인스턴스 그룹을 만듭니다.
• Cloud Storage 버킷 만들기
• 외부 애플리케이션 부하 분산기를 만들고 구성합니다.
• 업데이트된 부하 분산기 구성으로 웜 웹 서버 장애 조치를 테스트합니다.
• 업데이트된 부하 분산기 구성으로 복구 및 장애 복구를 테스트합니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

• Compute Engine
• 네트워킹
• Cloud Storage

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

시작하기 전에

1. Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

2. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

   참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

   프로젝트 선택기로 이동

3. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

4. Compute Engine API 사용 설정

   API 사용 설정

5. Google Cloud CLI를 설치합니다.

6. gcloud CLI를 초기화하려면 다음 명령어를 실행합니다.

   gcloud init

7. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

   참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

   프로젝트 선택기로 이동

8. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

9. Compute Engine API 사용 설정

   API 사용 설정

10. Google Cloud CLI를 설치합니다.

11. gcloud CLI를 초기화하려면 다음 명령어를 실행합니다.

    gcloud init

Google Cloud CLI를 설치하지 않고도 Google Cloud 콘솔에서 Google Cloud CLI를 실행할 수 있습니다. Google Cloud 콘솔에서 gcloud CLI를 실행하려면 Cloud Shell을 사용합니다.

환경 준비

이 섹션에서는 리소스 이름과 위치에 대한 몇 가지 변수를 정의합니다. 이러한 변수는 리소스를 배포할 때 Google Cloud CLI 명령어에서 사용됩니다.

이 문서에서 달리 명시하지 않는 한, 모든 명령어를 Cloud Shell 또는 로컬 개발 환경에 입력합니다.

1. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다. 원하는 경우 app과 같이 리소스를 검색하고 식별하는 데 도움이 되는 자체 이름 서픽스를 리소스에 제공합니다.

   us-west1 및 us-west2과 같은 두 개의 리전과 이러한 리전 중 하나 내에 있는 영역(예: us-west1-a)을 지정합니다. 이 영역은 관리형 인스턴스 그룹의 이미지를 만드는 데 사용되는 초기 기본 VM이 생성되는 위치를 정의합니다.

   마지막으로 정적 웹사이트에 사용되는 도메인을 설정합니다(예: example.com).

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION1=us-west1
   REGION2=us-west2
   ZONE=us-west1-a
   DOMAIN=example.com
   

VPC 및 서브넷 만들기

VM에 대한 네트워크 액세스 권한을 제공하려면 Virtual Private Cloud(VPC) 및 서브넷을 만듭니다. 두 리전에 관리형 인스턴스 그룹이 필요하므로 각 리전에 하나의 서브넷을 만듭니다. 환경에서 사용 중인 IP 주소 범위를 관리하기 위한 커스텀 서브넷 모드의 이점에 대한 자세한 내용은 커스텀 모드 VPC 네트워크 사용을 참조하세요.

1. 커스텀 서브넷 모드로 VPC를 만듭니다.

   gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
   

2. 이제 새 VPC에서 각 리전에 하나씩 두 개의 서브넷을 만듭니다. 네트워크 범위에 적합한 자체 주소 범위(예: 10.1.0.0/20 및 10.2.0.0/20)를 정의합니다.

   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION1 \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION1
   
   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION2 \
       --network=network-$NAME_SUFFIX \
       --range=10.2.0.0/20 \
       --region=$REGION2
   

방화벽 규칙 만들기

VPC에서 네트워크 트래픽 흐름을 올바르게 하려면 방화벽 규칙을 사용합니다.

1. 부하 분산기 및 관리형 인스턴스 그룹의 웹 트래픽 및 상태 확인을 허용하는 방화벽 규칙을 만듭니다.

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   HTTP 규칙은 http-server 태그가 적용되는 모든 VM에 대한 트래픽과 0.0.0.0/0 범위를 사용하는 모든 소스로부터의 트래픽을 허용합니다. 상태 확인 규칙의 경우 Google Cloud의 기본 범위는 플랫폼이 리소스 상태를 올바르게 확인할 수 있도록 설정됩니다.

2. 기본 VM 이미지의 초기 구성에 대해 SSH 트래픽을 허용하려면 --source-range 매개변수를 사용하여 해당 환경에 대한 방화벽 규칙 범위를 지정합니다. 조직에 사용되는 소스 범위를 결정하려면 네트워크 팀과 협력이 필요할 수 있습니다.

   주의: 모든 트래픽을 허용하는 포괄적인 0.0.0.0/0 범위는 사용하지 않는 것이 좋습니다. 단일 IP 주소로 트래픽 범위를 지정하려면 /32 네트워크 마스크(예 35.230.62.163/32)를 사용합니다.

   IP_ADDRESS_SCOPE를 고유 IP 주소 범위로 바꿉니다.

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. 방화벽 규칙을 만든 후 다음 세 가지 규칙이 추가되었는지 확인합니다.

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   다음 예시 출력은 3개 규칙이 올바르게 생성된 것을 보여줍니다.

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

기본 VM 이미지 만들기 및 구성

추가 구성 없이 배포하는 VM을 만들려면 커스텀 VM 이미지를 사용합니다. 이 이미지는 OS 및 Apache 구성을 캡처하며 다음 단계에서 관리형 인스턴스 그룹에 각 VM을 만드는 데 사용됩니다.

참고: 이 문서에서는 기본 VM 및 이미지를 수동으로 만들고 구성합니다. 프로덕션 배포에서는 기존 배포 도구와 파이프라인을 사용하여 이 프로세스를 최대한 자동화하세요. 자세한 내용은 Terraform, Cloud Build, GitOps를 사용하여 인프라를 코드로 관리를 참조하세요.

VM에서 영구 디스크에 기본 index.html 파일을 만들고 /var/www/example.com에 마운트합니다. /etc/apache2/sites-available/example.com.conf의 Apache 구성 파일은 마운트된 영구 디스크 위치로부터 웹 콘텐츠를 제공합니다.

다음 다이어그램은 영구 디스크에 저장된 Apache에서 제공하는 기본 HTML 페이지를 보여줍니다.

다음 단계에서 이 환경을 빌드합니다.

1. 연결된 영구 디스크가 있는 기본 VM을 만듭니다.

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION1 \
       --tags=http-server \
       --image=debian-10-buster-v20210420 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
   

   이 문서의 시작 부분에 정의된 매개변수를 사용하여 VM의 이름을 지정하고 올바른 서브넷에 연결합니다. 또한 부팅 디스크 및 데이터 디스크에 대한 매개변수로부터 이름을 할당합니다.

2. 간단한 웹사이트를 설치하고 구성하려면 SSH를 사용하여 기본 VM에 연결합니다.

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
   

3. VM에 대한 SSH 세션에서 원하는 편집기로 VM을 구성하는 스크립트를 만듭니다. 다음 예시에서는 Nano를 편집기로 사용합니다.

   nano configure-vm.sh
   

   다음 구성 스크립트를 파일에 붙여넣습니다.

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-base-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

   NAME_SUFFIX를 이 문서의 시작 부분에서 설정한 값과 일치하도록 업데이트합니다(예: app).

4. 파일을 작성하고 편집기를 종료합니다. 예를 들어 Nano에서 Ctrl-O를 사용하여 파일을 작성하고 Ctrl-X로 종료합니다.

5. 구성 스크립트를 실행 가능하게 만든 다음 실행합니다.

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

6. VM에 대한 SSH 세션을 종료합니다.

   exit
   

7. VM의 IP 주소를 가져오고 curl을 사용하여 기본 웹페이지를 확인합니다.

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   다음 예시 출력에 표시된 것처럼 기본 웹사이트가 반환됩니다.

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

   이 단계는 Apache가 올바르게 구성되었고 페이지가 연결된 영구 디스크에서 로드되었는지 확인합니다. 다음 섹션에서는 이 기본 VM을 사용하여 이미지를 만들고 시작 스크립트로 인스턴스 템플릿을 구성합니다.

Compute Engine 리소스 배포

이 웜 장애 조치 패턴은 관리형 인스턴스 그룹을 사용하여 VM을 실행합니다. 관리형 인스턴스 그룹은 두 리전에서 실행되며 각 그룹은 VM의 상태를 모니터링합니다. 서비스 중단이 발생하여 VM 중 하나가 실패하면 관리형 인스턴스 그룹이 VM을 다시 만듭니다. 이 구성은 Cloud Storage의 정적 사이트로의 웜 장애 조치 없이도 가용성이 높은 애플리케이션을 만듭니다.

1. 이미지를 만들려면 먼저 VM을 중지해야 합니다.

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
   

2. 다음 명령어 집합을 실행하여 VM 이미지, 인스턴스 템플릿, 관리형 인스턴스 그룹을 만듭니다.

   # Create the base VM images
   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   gcloud compute images create image-disk-$NAME_SUFFIX \
       --source-disk=disk-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   # Create instance templates
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   # Create a health check for VM instances
   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \
       --port 80
   
   # Create the managed instance groups
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \
       --template=template-$NAME_SUFFIX-$REGION1 \
       --size=2 \
       --region=$REGION1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \
       --template=template-$NAME_SUFFIX-$REGION2 \
       --size=2 \
       --region=$REGION2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

부하 분산기 만들기 및 구성

사용자가 웹사이트에 액세스하기 위해서는 관리형 인스턴스 그룹에서 실행되는 VM으로의 트래픽을 허용해야 합니다. 또한 관리형 인스턴스 그룹에 영역 오류가 발생할 경우 새로운 VM으로 트래픽을 자동으로 리디렉션해야 할 수 있습니다.

다음 섹션에서는 포트 80에서 HTTP 트래픽에 대한 백엔드 서비스를 사용하여 외부 부하 분산기를 만들고, 이전 단계에서 만든 상태 확인을 사용하고, 외부 IP 주소를 백엔드 서비스에 매핑합니다.

자세한 내용은 간단한 외부 HTTP 부하 분산기 설정 방법을 참조하세요.

1. 애플리케이션의 부하 분산기를 만들고 구성합니다.

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --named-ports http:80 \
       --region $REGION1
   
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --named-ports http:80 \
       --region $REGION2
   
   # Create a backend service and add the managed instance groups to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \
       --instance-group-region=$REGION1 \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \
       --instance-group-region=$REGION2 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. 웹 트래픽에 대한 전달 규칙의 IP 주소를 가져옵니다.

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. curl을 사용하거나 웹브라우저를 열어 이전 단계의 부하 분산기 IP 주소를 사용하여 웹사이트를 확인합니다.

   curl $IP_ADDRESS
   

   부하 분산기 배포가 완료되고 백엔드로 트래픽을 올바르게 연결하려면 몇 분 정도 걸립니다. 부하 분산기 배포가 계속 수행되면 HTTP 404 오류가 반환됩니다. 필요한 경우 몇 분 정도 기다린 후 웹사이트 액세스를 다시 시도합니다.

   다음 예시 출력에 표시된 것처럼 기본 웹사이트가 반환됩니다.

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

스토리지 버킷 만들기 및 구성

Cloud Storage는 정적 웹사이트 파일을 저장하는 데 사용됩니다. 이 기본 예시에서는 VM과 약간 다른 텍스트를 사용하여 단일 파일을 만듭니다.

프로덕션 배포 시 웹사이트에는 이 문서에 나와 있는 것보다 더 많은 파일과 관리형 인스턴스 그룹 VM의 추가 애플리케이션 코드가 포함될 수 있습니다. Cloud Storage에서 호스팅되는 정적 버전은 최소한의 기능을 제공하는 좀 더 제한된 버전인 경우가 많습니다. 웜 장애 조치 시나리오에서 관리형 인스턴스 그룹이 복구되고 전체 웹사이트 환경을 위해 트래픽을 제공할 수 있을 때까지 Cloud Storage의 이 제한된 웹사이트가 표시됩니다.

1. Cloud Storage 버킷에 사용할 도메인을 확인합니다.

2. 소유하고 있으며 사용하려는 도메인의 이름과 일치하는 Cloud Storage 버킷을 만듭니다.

   gsutil mb gs://static-web.$DOMAIN
   

   이 문서의 시작 부분에서 정의한 DOMAIN 변수가 사용됩니다(예: example.com). 이 예시에서는 정적 파일을 static-web.example.com에 저장합니다.

3. 다음 단계에서 Cloud Storage 버킷으로 복사할 로컬 파일을 만듭니다.

   cat <<EOF > index.html
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   EOF
   

4. 기본 HTML 파일을 Cloud Storage 버킷에 업로드합니다.

   gsutil cp index.html gs://static-web.$DOMAIN
   

5. 사용자가 정적 웹 콘텐츠를 볼 수 있도록 Cloud Storage 버킷에서 적절한 권한을 설정합니다.

   gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
   

6. index.html 파일을 기본 웹페이지로 제공하도록 Cloud Storage 버킷을 구성합니다.

   gsutil web set -m index.html gs://static-web.$DOMAIN
   

Cloud Storage 버킷을 부하 분산기에 추가

정적 웹 콘텐츠를 호스팅하도록 Cloud Storage 버킷을 만들고 구성한 경우 부하 분산기에는 해당 버킷에 트래픽을 전달하는 방법에 대한 정보가 필요합니다.

부하 분산기 생성 및 구성에서 관리형 인스턴스 그룹을 위한 백엔드 서비스를 만들었습니다. 백엔드 서비스에는 URL 맵이 있고 HTTP 대상 프록시는 부하 분산기를 통해 VM으로 사용자를 연결하는 데 도움이 됩니다.

Cloud Storage 버킷으로 트래픽을 전달할 수 있도록 스토리지 버킷의 새 백엔드와 URL 맵으로 부하 분산기를 구성합니다. 장애 조치를 해야 하는 경우 이 구성을 사용하도록 부하 분산기를 업데이트합니다.

1. Cloud Storage 버킷의 백엔드를 추가합니다.

   gcloud compute backend-buckets create \
       web-bucket-$NAME_SUFFIX \
       --gcs-bucket-name=static-web.$DOMAIN
   

2. 트래픽이 백엔드로 전달될 수 있도록 하는 URL 맵을 만듭니다.

   gcloud compute url-maps create \
       web-map-http-bucket-$NAME_SUFFIX \
       --default-backend-bucket=web-bucket-$NAME_SUFFIX
   

3. 영역 장애를 시뮬레이션하기 전에 리소스 배포를 검토하세요. 모든 리소스는 다음 이미지와 같이 환경을 지원하기 위해 생성되었습니다.

   

   • 부하 분산기는 2개의 관리형 인스턴스 그룹으로 트래픽을 전달합니다. 각 관리형 인스턴스 그룹에는 기본 웹사이트를 실행하는 2개의 VM이 있습니다.
   • 관리형 인스턴스 그룹에 장애가 발생하면 정적 페이지를 호스팅하도록 Cloud Storage 버킷이 구성됩니다.
   • 부하 분산기는 Cloud Storage의 정적 사이트를 사용하도록 구성되어 있지만 현재 스토리지 버킷으로 트래픽을 전달하지 않습니다.

Cloud Storage 버킷으로 장애 조치

실제 환경에서는 관리형 인스턴스 그룹에 문제가 있을 때 Cloud Monitoring 또는 다른 모니터링 솔루션을 사용하여 알림을 받을 수 있습니다. 이 알림은 Cloud Storage에서 호스팅하는 정적 웹사이트로 트래픽을 리디렉션하도록 부하 분산기를 업데이트하기 전에 오류 범위를 이해하라는 메시지를 사용자에게 표시합니다. 또 다른 방법은 모니터링 솔루션을 사용하여 관리형 인스턴스 그룹 장애에 자동으로 응답하는 것입니다.

장애 조치가 수행되면 외부 애플리케이션 부하 분산기는 다음 이미지와 같이 Cloud Storage에 호스팅되는 정적 웹사이트로 트래픽을 전달합니다.

사용자 또는 모니터링 솔루션에서 스토리지 버킷으로 트래픽을 보내도록 부하 분산기를 업데이트하는 것이 가장 적절한 것으로 확인되면 이전 섹션에서 만든 URL 맵을 사용하도록 HTTP 프록시 대상을 업데이트합니다. 이 문서에서는 트래픽을 Cloud Storage에서 호스팅되는 정적 웹사이트로 리디렉션하도록 부하 분산기를 수동으로 업데이트합니다.

1. Cloud Storage 버킷의 URL 맵을 사용하도록 기존 HTTP 프록시 대상을 업데이트합니다.

   gcloud compute target-http-proxies update \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map=web-map-http-bucket-$NAME_SUFFIX
   

2. 이제 curl을 사용하거나 웹브라우저를 열어 부하 분산기의 IP 주소에 액세스합니다.

   curl $IP_ADDRESS
   

   다음 출력 예시와 같이 Cloud Storage의 정적 웹사이트가 반환됩니다.

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   

   부하 분산기가 구성을 업데이트하고 트래픽을 Cloud Storage 버킷으로 올바르게 전달하는 데 몇 분 정도 걸릴 수 있습니다. 필요한 경우 몇 분 정도 기다린 후 웹사이트 액세스를 다시 시도합니다.

관리형 인스턴스 그룹으로 장애 복구

관리형 인스턴스 그룹 문제가 해결되면 URL 맵 구성을 다시 업데이트하여 부하 분산된 관리형 인스턴스 그룹의 콘텐츠로 장애 조치할 수 있습니다. 다시 한 번, 사람이 관리형 인스턴스 그룹의 상태에 대한 Cloud Monitoring 통계를 사용하여 이러한 결정을 내릴 수 있습니다. 또는 자동화를 사용하여 관리형 인스턴스 그룹의 복원된 상태에 응답할 수 있습니다. 이 문서에서는 부하 분산기 구성을 수동으로 업데이트합니다.

1. 관리형 인스턴스 그룹에 URL 맵을 다시 사용하도록 HTTP 프록시 대상을 업데이트합니다.

   gcloud compute target-http-proxies update \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map=web-map-http-$NAME_SUFFIX
   

2. curl을 다시 사용하거나 웹브라우저를 열어 부하 분산기의 IP 주소에 액세스합니다.

   curl $IP_ADDRESS
   

   부하 분산기가 구성을 업데이트하고 트래픽을 관리형 인스턴스 그룹으로 올바르게 전달하는 데 몇 분 정도 걸릴 수 있습니다. 필요한 경우 몇 분 정도 기다린 후 웹사이트 액세스를 다시 시도합니다.

   다음 예시 출력과 같이 관리형 인스턴스 그룹의 기본 웹사이트가 반환됩니다.

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

이 문서에서 만든 개별 리소스를 삭제하려면 다음 단계를 수행합니다.

1. Cloud Storage 버킷을 삭제합니다.

   gsutil rm -r gs://static-web.$DOMAIN
   

2. 부하 분산기 구성을 삭제합니다.

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   
   gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet
   

3. 관리형 인스턴스 그룹 및 상태 확인을 삭제합니다.

   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 --quiet
   
   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

4. 인스턴스 템플릿, 이미지, 기본 VM, 영구 디스크를 삭제합니다.

   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION1 --quiet
   
   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION2 --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-disk-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX \
       --zone=$ZONE --quiet
   

5. 방화벽 규칙을 삭제합니다.

   gcloud compute firewall-rules delete \
       allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-http-$NAME_SUFFIX --quiet
   

6. 서브넷 및 VPC를 삭제합니다.

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet
   
   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

다음 단계

• 장애 조치 제어를 위해 외부 애플리케이션 부하 분산기 대신 Cloud DNS를 사용하는 대체 접근 방법은 Compute Engine 및 Cloud Storage와 함께 Cloud DNS를 사용하여 복구 가능한 웜 웹 서버 배포를 참조하세요. 이 패턴은 Cloud DNS가 있거나 이를 사용하려는 경우에 유용합니다.
• 고유 애플리케이션의 권장사항을 확인하고 사용할 복구 방법은 재해 복구 계획 가이드를 참조하세요.
• 콜드 및 핫 장애 조치와 같은 애플리케이션의 다른 패턴을 보려면 애플리케이션 재해 복구 시나리오를 참조하세요.
• 확장성과 가용성을 처리하는 다른 방법은 확장 가능하고 복원력이 우수한 앱 패턴을 참조하세요.
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기