GSP662

개요

Google Cloud 내에서 웹사이트를 배포하는 방법에는 여러 가지가 있습니다. 각 솔루션은 서로 다른 특징, 기능, 제어 수준을 제공합니다. Compute Engine은 웹사이트를 운영하는 데 사용되는 인프라에 대한 심층적인 제어 기능을 제공하지만 Google Kubernetes Engine(GKE), App Engine 등의 다른 솔루션에 비해 운영 관리가 조금 더 필요합니다. Compute Engine을 사용하면 가상 머신, 부하 분산기 등을 포함하여 인프라의 여러 측면을 세밀하게 제어할 수 있습니다.

이 실습에서는 'Fancy Store' 전자상거래 웹사이트인 샘플 애플리케이션을 배포하여 Compute Engine으로 웹사이트를 얼마나 쉽게 배포하고 확장할 수 있는지 확인해 봅니다.

학습할 내용

이 실습에서는 다음을 수행하는 방법에 대해 알아봅니다.

• Compute Engine 인스턴스 만들기
• 소스 인스턴스에서 인스턴스 템플릿 만들기
• 관리형 인스턴스 그룹 만들기
• 관리형 인스턴스 그룹 상태 점검 만들기 및 테스트
• HTTP(S) 부하 분산기 만들기
• 부하 분산기 상태 점검 만들기
• 캐싱을 위해 콘텐츠 전송 네트워크(CDN) 사용

이 실습을 마치면 관리형 인스턴스 그룹 안에 웹사이트의 자동 복구, 부하 분산, 자동 확장, 순차적 업데이트를 제공하는 인스턴스를 생성하게 됩니다.

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머에는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지 표시됩니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 직접 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학생 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간---실습을 시작하고 나면 일시중지할 수 없습니다.

참고: 계정에 추가 요금이 발생하지 않도록 하려면 개인용 Google Cloud 계정이나 프로젝트가 이미 있어도 이 실습에서는 사용하지 마세요.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 팝업이 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 패널이 있습니다.

   • Google Cloud 콘솔 열기 버튼
   • 남은 시간
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보
   • 필요한 경우 실습 진행을 위한 기타 정보

2. Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).

   실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.

   {{{user_0.username | "Username"}}}

   실습 세부정보 패널에서도 사용자 이름을 확인할 수 있습니다.

4. 다음을 클릭합니다.

5. 아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.

   {{{user_0.password | "Password"}}}

   실습 세부정보 패널에서도 비밀번호를 확인할 수 있습니다.

6. 다음을 클릭합니다.

   중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

7. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의합니다.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
   • 무료 체험판을 신청하지 않습니다.

잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.

참고: Google Cloud 제품 및 서비스 목록이 있는 메뉴를 보려면 왼쪽 상단의 탐색 메뉴를 클릭합니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 PROJECT_ID로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

2. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

3. 승인을 클릭합니다.

4. 다음과 비슷한 결과가 출력됩니다.

출력:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = <project_ID>

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참조하세요.

리전 및 영역 설정하기

특정 Compute Engine 리소스는 여러 리전과 영역에 상주합니다. 리전은 리소스를 실행할 수 있는 특정한 지리적 위치로, 각 리전에는 영역이 하나 이상 있습니다.

Cloud 콘솔에서 다음 gcloud 명령어를 실행하여 실습의 기본 리전과 영역을 설정합니다.

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

작업 1. Compute Engine API 사용 설정

• 다음을 실행하여 Compute Engine API를 사용 설정합니다.

gcloud services enable compute.googleapis.com

작업 2. Cloud Storage 버킷 만들기

Cloud Storage 버킷을 사용하여 빌드한 코드와 시작 스크립트를 저장합니다.

• Cloud Shell에서 다음을 실행하여 새로운 Cloud Storage 버킷을 만듭니다.

gsutil mb gs://fancy-store-$DEVSHELL_PROJECT_ID 참고: Cloud Shell 내에서 $DEVSHELL_PROJECT_ID 환경 변수를 사용하면 고유한 객체 이름을 사용하는 데 도움이 됩니다. Google Cloud 내의 모든 프로젝트 ID는 고유해야 하므로 프로젝트 ID를 추가하면 다른 이름의 고유성도 유지됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Cloud Storage 버킷 만들기

작업 3. 소스 저장소 클론

monolith-to-microservices 저장소를 기반으로 하는 기존 Fancy Store 전자상거래 웹사이트를 웹사이트의 기초로 사용합니다.

Compute Engine에 배포하는 작업에 집중할 수 있도록 소스 코드를 클론합니다. 잠시 후 이 실습에서 이 코드를 약간 업데이트하여 Compute Engine에서 업데이트하기가 얼마나 간단한지 시연해 봅니다.

1. 소스 코드를 클론한 다음 monolith-to-microservices 디렉터리로 이동합니다.

git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices

2. 코드의 초기 빌드를 실행하여 애플리케이션을 로컬로 실행할 수 있게 합니다.

./setup.sh

이 스크립트가 완료되는 데 몇 분 정도 걸릴 수 있습니다.

3. 완료되면 다음 명령어를 사용하여 Cloud Shell이 호환 가능한 nodeJS 버전을 실행할 수 있게 합니다.

nvm install --lts

4. 그리고 다음 명령어를 실행하여 애플리케이션을 테스트하고 microservices 디렉터리로 전환한 다음 웹 서버를 시작합니다.

cd microservices npm start

다음과 같은 출력이 표시됩니다.

Products microservice listening on port 8082! Frontend microservice listening on port 8080! Orders microservice listening on port 8081!

5. 웹 미리보기 아이콘을 클릭하고 포트 8080에서 미리보기를 선택하여 애플리케이션을 미리 봅니다.

그러면 Fancy Store의 프런트엔드를 볼 수 있는 새 창이 열립니다.

참고: 미리보기 옵션으로 프런트엔드를 볼 수는 있지만 제품 및 주문 기능은 해당 서비스가 아직 노출되지 않았기 때문에 작동하지 않습니다.

6. 웹사이트를 본 후에 이 창을 닫은 다음 터미널 창에서 Ctrl+C를 눌러 웹 서버 프로세스를 중지합니다.

작업 4. Compute Engine 인스턴스 만들기

이제 Compute Engine 인스턴스 배포를 시작할 차례입니다.

다음 단계에서는 다음을 수행합니다.

1. 인스턴스를 구성하는 시작 스크립트를 만듭니다.
2. 소스 코드를 클론하여 Cloud Storage로 업로드합니다.
3. Compute Engine 인스턴스를 배포하여 백엔드 마이크로서비스를 호스팅합니다.
4. 백엔드 마이크로서비스 인스턴스를 활용하도록 프런트엔드 코드를 재구성합니다.
5. Compute Engine 인스턴스를 배포하여 프런트엔드 마이크로서비스를 호스팅합니다.
6. 통신을 허용하도록 네트워크를 구성합니다.

시작 스크립트 만들기

시작 스크립트는 인스턴스가 시작될 때마다 수행할 작업을 인스턴스에 지시하는 데 사용됩니다. 이렇게 하면 인스턴스가 자동으로 구성됩니다.

1. Cloud Shell에서 다음 명령어를 실행하여 startup-script.sh라는 이름의 파일을 만듭니다.

touch ~/monolith-to-microservices/startup-script.sh

2. Cloud Shell 리본에서 편집기 열기를 클릭하여 코드 편집기를 엽니다.

3. monolith-to-microservices 폴더로 이동합니다.

4. 다음 코드를 startup-script.sh 파일에 추가합니다. 코드를 추가한 후에 일부를 수정합니다.

#!/bin/bash # Install logging monitor. The monitor will automatically pick up logs sent to # syslog. curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash service google-fluentd restart & # Install dependencies from apt apt-get update apt-get install -yq ca-certificates git build-essential supervisor psmisc # Install nodejs mkdir /opt/nodejs curl https://nodejs.org/dist/v16.14.0/node-v16.14.0-linux-x64.tar.gz | tar xvzf - -C /opt/nodejs --strip-components=1 ln -s /opt/nodejs/bin/node /usr/bin/node ln -s /opt/nodejs/bin/npm /usr/bin/npm # Get the application source code from the Google Cloud Storage bucket. mkdir /fancy-store gsutil -m cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/ # Install app dependencies. cd /fancy-store/ npm install # Create a nodeapp user. The application will run as this user. useradd -m -d /home/nodeapp nodeapp chown -R nodeapp:nodeapp /opt/app # Configure supervisor to run the node app. cat >/etc/supervisor/conf.d/node-app.conf << EOF [program:nodeapp] directory=/fancy-store command=npm start autostart=true autorestart=true user=nodeapp environment=HOME="/home/nodeapp",USER="nodeapp",NODE_ENV="production" stdout_logfile=syslog stderr_logfile=syslog EOF supervisorctl reread supervisorctl update

5. 파일에서 [DEVSHELL_PROJECT_ID]라는 텍스트를 찾아서 프로젝트 ID()로 바꿉니다.

그러면 startup-script.sh 안에서 해당 코드 줄이 다음과 같이 됩니다.

gs://fancy-store-{{{project_0.project_id | Project ID}}}/monolith-to-microservices/microservices/* /fancy-store/

6. startup-script.sh 파일을 저장하지만 아직 닫지 않습니다.

7. Cloud Shell 코드 편집기의 오른쪽 하단에서 '줄 끝 시퀀스'가 'CRLF'가 아니라 'LF'로 설정되어 있는지 확인합니다.

• CRLF로 설정되어 있으면 CRLF를 클릭한 다음 드롭다운에서 LF를 선택합니다.
• 이미 LF로 설정되어 있으면 그대로 둡니다.

8. startup-script.sh 파일을 닫습니다.

9. Cloud Shell 터미널로 돌아가서 다음을 실행하여 startup-script.sh 파일을 버킷에 복사합니다.

gsutil cp ~/monolith-to-microservices/startup-script.sh gs://fancy-store-$DEVSHELL_PROJECT_ID

이제 다음 주소에서 액세스할 수 있습니다. https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh

[BUCKET_NAME]은 Cloud Storage 버킷의 이름을 나타냅니다. 이 파일은 기본적으로 승인된 사용자와 서비스 계정만 볼 수 있으므로 웹브라우저를 통해 액세스할 수 없습니다. Compute Engine 인스턴스는 자동으로 해당 서비스 계정을 통해 파일에 액세스할 수 있습니다.

시작 스크립트는 다음 작업을 수행합니다.

• Logging 에이전트를 설치합니다. 이 에이전트는 syslog에서 자동으로 로그를 수집합니다.
• Node.js와 Supervisor를 설치합니다. Supervisor는 앱을 데몬으로 실행합니다.
• Cloud Storage 버킷에서 앱의 소스 코드를 클론하고 종속 항목을 설치합니다.
• 앱을 실행하도록 Supervisor를 구성합니다. Supervisor는 앱이 예기치 않게 종료되거나 관리자 또는 프로세스에 의해 중단된 경우 앱이 다시 시작되도록 합니다. 또한 앱의 stdout 및 stderr을 syslog에 전송하여 Logging 에이전트가 수집할 수 있게 합니다.

코드를 Cloud Storage 버킷에 복사

인스턴스가 시작되면 Cloud Storage 버킷에서 코드를 가져오기 때문에 코드의 .env 파일 안에 일부 구성 변수를 저장할 수 있습니다.

참고: 다른 곳에서 환경 변수를 가져오도록 코딩할 수도 있지만 여기에서는 시연을 위해 구성을 처리하는 간단한 방법을 사용합니다. 프로덕션에서는 환경 변수가 코드 외부에 저장될 가능성이 높습니다.

1. 클론 코드를 버킷에 복사합니다.

cd ~ rm -rf monolith-to-microservices/*/node_modules gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/ 참고: 최대한 빠르고 효율적으로 복사되도록 node_modules 종속 항목 디렉터리는 삭제됩니다. 이 디렉터리는 인스턴스가 시작될 때 인스턴스에서 다시 생성됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 시작 스크립트와 코드를 Cloud Storage 버킷에 복사

백엔드 인스턴스 배포

가장 먼저 배포할 인스턴스는 주문 및 제품 마이크로서비스를 저장할 백엔드 인스턴스입니다.

참고: 프로덕션 환경에서는 각 마이크로서비스를 고유한 인스턴스와 인스턴스 그룹으로 분리하여 독립적으로 확장할 수 있습니다. 여기에서는 시연을 위해 두 백엔드 마이크로서비스(주문 및 제품)를 동일한 인스턴스 및 인스턴스 그룹에 둡니다.

• 다음 명령어를 실행하여 시작 스크립트를 사용하도록 구성된 e2-standard-2 인스턴스를 생성합니다. 나중에 특정 방화벽 규칙을 적용할 수 있도록 backend 인스턴스 태그가 지정됩니다.

gcloud compute instances create backend \ --zone=$ZONE \ --machine-type=e2-standard-2 \ --tags=backend \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

백엔드에 대한 연결 구성

애플리케이션의 프런트엔드를 배포하기 전에 방금 배포한 백엔드를 가리키도록 구성을 업데이트해야 합니다.

1. 다음 명령어를 사용하여 백엔드의 외부 IP 주소를 검색하고 EXTERNAL_IP 탭에서 백엔드 인스턴스를 확인합니다.

gcloud compute instances list

출력 예시:

NAME: backend ZONE: {{{project_0.default_zone | zone}}} MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.142.0.2 EXTERNAL_IP: 35.237.245.193 STATUS: RUNNING

2. 백엔드의 외부 IP를 복사합니다.

3. Cloud Shell 탐색기에서 monolith-to-microservices > react-app으로 이동합니다.

4. 코드 편집기에서 보기 > 숨은 파일 전환을 선택하여 .env 파일을 확인합니다.

다음 단계에서는 백엔드의 외부 IP를 가리키도록 .env 파일을 수정합니다. [BACKEND_ADDRESS]는 위의 gcloud 명령어로 확인된 백엔드 인스턴스의 외부 IP 주소를 나타냅니다.

5. .env 파일에서 localhost를 [BACKEND_ADDRESS]로 바꿉니다.

REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8081/api/orders REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8082/api/products

6. 파일을 저장합니다.

7. Cloud Shell에서 다음을 실행하여 react-app을 다시 빌드해서 프런트엔드 코드를 업데이트합니다.

cd ~/monolith-to-microservices/react-app npm install && npm run-script build

8. 그런 다음 애플리케이션 코드를 Cloud Storage 버킷에 복사합니다.

cd ~ rm -rf monolith-to-microservices/*/node_modules gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

프런트엔드 인스턴스 배포

코드가 구성되었으니 이제 프런트엔드 인스턴스를 배포합니다.

• 앞서 사용한 것과 유사한 명령어로 다음을 실행하여 frontend 인스턴스를 배포합니다. 이 인스턴스에는 방화벽 용도로 frontend 태그가 지정됩니다.

gcloud compute instances create frontend \ --zone=$ZONE \ --machine-type=e2-standard-2 \ --tags=frontend \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh 참고: 배포 명령어와 시작 스크립트는 간결성을 위해 프런트엔드 및 백엔드 인스턴스 모두에 사용되는데 그 이유는 코드가 기본적으로 모든 마이크로서비스를 시작하도록 구성되어 있기 때문입니다. 따라서 이 샘플에서는 모든 마이크로서비스가 프런트엔드 및 백엔드 모두에서 실행됩니다. 프로덕션 환경에서는 각 구성요소에 필요한 마이크로서비스만 실행합니다.

네트워크 구성

1. 프런트엔드의 경우 포트 8080에, 백엔드의 경우 포트 8081~8082에 대한 액세스를 허용하는 방화벽 규칙을 생성합니다. 다음 방화벽 명령어는 애플리케이션의 인스턴스 생성 중에 지정된 태그를 사용합니다.

gcloud compute firewall-rules create fw-fe \ --allow tcp:8080 \ --target-tags=frontend gcloud compute firewall-rules create fw-be \ --allow tcp:8081-8082 \ --target-tags=backend

이제 웹사이트가 완전히 작동합니다.

2. frontend의 외부 IP로 이동하려면 주소를 알아야 합니다. 다음을 실행하고 frontend 인스턴스의 EXTERNAL_IP를 찾습니다.

gcloud compute instances list

출력 예시:

NAME: backend ZONE: us-central1-f MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.128.0.2 EXTERNAL_IP: 34.27.178.79 STATUS: RUNNING NAME: frontend ZONE: us-central1-f MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.128.0.3 EXTERNAL_IP: 34.172.241.242 STATUS: RUNNING

인스턴스를 시작하고 구성하는 데 몇 분 정도 걸릴 수 있습니다.

3. 3분간 기다렸다가 새 브라우저 탭을 열고 http://[FRONTEND_ADDRESS]:8080으로 이동하여 웹사이트에 액세스합니다. [FRONTEND_ADDRESS]는 위에서 확인한 프런트엔드 EXTERNAL_IP입니다.

4. 제품 및 주문 페이지로 이동합니다. 이제 해당 페이지가 작동합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 인스턴스 배포 및 네트워크 구성

작업 5. 관리형 인스턴스 그룹 만들기

애플리케이션을 확장할 수 있게 하기 위해 관리형 인스턴스 그룹을 만들고 frontend 및 backend 인스턴스를 인스턴스 템플릿으로 사용합니다.

관리형 인스턴스 그룹(MIG)에는 동일한 인스턴스가 포함되어 있어 단일 영역에서 단일 항목으로 관리할 수 있습니다. 관리형 인스턴스 그룹은 인스턴스를 사용할 수 있는 상태, 즉 RUNNING 상태를 선제적으로 유지하여 앱의 고가용성을 유지합니다. 프런트엔드 및 백엔드 인스턴스의 관리형 인스턴스 그룹을 사용하여 자동 복구, 부하 분산, 자동 확장, 순차적 업데이트를 제공해 봅니다.

소스 인스턴스에서 인스턴스 템플릿 만들기

관리형 인스턴스 그룹을 만들려면 먼저 그룹의 기반이 될 인스턴스 템플릿을 만들어야 합니다. 인스턴스 템플릿은 새로운 VM 인스턴스를 만들 때 사용할 머신 유형, 부팅 디스크 이미지 또는 컨테이너 이미지, 네트워크, 기타 인스턴스 속성을 정의하는 데 사용할 수 있습니다. 인스턴스 템플릿을 사용하면 관리형 인스턴스 그룹에 인스턴스를 만들거나 개별 인스턴스를 만들 수도 있습니다.

인스턴스 템플릿을 만들기 위해 이전에 만든 기존 인스턴스를 사용합니다.

1. 먼저 두 인스턴스를 중지합니다.

gcloud compute instances stop frontend --zone=$ZONE gcloud compute instances stop backend --zone=$ZONE

2. 그런 다음 각 소스 인스턴스에서 인스턴스 템플릿을 만듭니다.

gcloud compute instance-templates create fancy-fe \ --source-instance-zone=$ZONE \ --source-instance=frontend gcloud compute instance-templates create fancy-be \ --source-instance-zone=$ZONE \ --source-instance=backend

3. 생성된 인스턴스 템플릿을 확인합니다.

gcloud compute instance-templates list

출력 예시:

NAME: fancy-be MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: CREATION_TIMESTAMP: 2023-07-25T14:52:21.933-07:00 NAME: fancy-fe MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: CREATION_TIMESTAMP: 2023-07-25T14:52:15.442-07:00

4. 인스턴스 템플릿이 생성된 상태에서 리소스 공간을 절약하기 위해 backend VM을 삭제합니다.

gcloud compute instances delete backend --zone=$ZONE

5. 메시지가 표시되면 y를 입력하고 Enter 키를 누릅니다.

일반적으로 frontend VM도 삭제할 수 있지만 이 실습에서는 나중에 인스턴스 템플릿을 업데이트하는 데 사용합니다.

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

1. 다음으로 두 개의 관리형 인스턴스 그룹을 만듭니다. 하나는 프런트엔드용이고 다른 하나는 백엔드용입니다.

gcloud compute instance-groups managed create fancy-fe-mig \ --zone=$ZONE \ --base-instance-name fancy-fe \ --size 2 \ --template fancy-fe gcloud compute instance-groups managed create fancy-be-mig \ --zone=$ZONE \ --base-instance-name fancy-be \ --size 2 \ --template fancy-be

이러한 관리형 인스턴스 그룹은 인스턴스 템플릿을 사용하며 각 그룹 내에서 두 개의 인스턴스가 각각 시작되도록 구성됩니다. 인스턴스 이름은 base-instance-name을 기반으로 임의의 문자가 추가되도록 자동 지정됩니다.

2. 애플리케이션을 위해 frontend 마이크로서비스가 포트 8080에서 실행되고, backend 마이크로서비스는 orders의 경우 포트 8081에서, products의 경우 포트 8082에서 실행됩니다.

gcloud compute instance-groups set-named-ports fancy-fe-mig \ --zone=$ZONE \ --named-ports frontend:8080 gcloud compute instance-groups set-named-ports fancy-be-mig \ --zone=$ZONE \ --named-ports orders:8081,products:8082

이는 비표준 포트이므로 식별하기 위해 이름이 지정된 포트를 명시해야 합니다. 이름이 지정된 포트는 서비스 이름과 서비스가 실행되는 포트를 나타내는 키-값 쌍 메타데이터로 인스턴스 그룹에 할당될 수 있습니다. 즉, 그룹의 모든 인스턴스에서 서비스를 이용할 수 있음을 나타냅니다. 이 정보는 나중에 구성할 HTTP 부하 분산 서비스에서 사용됩니다.

자동 복구 구성

애플리케이션 자체의 가용성을 개선하고 애플리케이션이 응답하는지 확인하기 위해 관리형 인스턴스 그룹의 자동 복구 정책을 구성합니다.

자동 복구 정책은 애플리케이션 기반 상태 점검을 사용하여 앱이 예상대로 응답하는지 확인합니다. 단순히 인스턴스가 RUNNING 상태인지 확인하는 기본 동작보다 앱이 응답하는지 확인하는 것이 더 정확합니다.

참고: 부하 분산과 자동 복구에는 별도의 상태 점검을 사용합니다. 부하 분산에 사용되는 상태 점검은 인스턴스가 사용자 트래픽을 수신하는지 여부를 확인하므로 더 엄격하게 설정할 수 있으며 더 엄격해야 합니다. 이 경우에는 필요하면 트래픽을 리디렉션할 수 있도록 응답하지 않는 인스턴스를 빠르게 파악해야 합니다. 반면에 자동 복구용 상태 점검을 사용하면 Compute Engine이 장애가 발생하는 인스턴스를 사전에 교체하므로 이 상태 점검은 부하 분산 상태 점검보다 보수적이어야 합니다.

1. 인스턴스가 frontend 및 backend에 대해 3번 연속으로 'unhealthy'를 반환하면 인스턴스를 복구하는 상태 점검을 만듭니다.

gcloud compute health-checks create http fancy-fe-hc \ --port 8080 \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3 gcloud compute health-checks create http fancy-be-hc \ --port 8081 \ --request-path=/api/orders \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3

2. 상태 점검 프로브가 포트 8080~8081의 마이크로서비스에 연결되도록 허용하는 방화벽 규칙을 만듭니다.

gcloud compute firewall-rules create allow-health-check \ --allow tcp:8080-8081 \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --network default

3. 이 상태 점검을 해당 서비스에 적용합니다.

gcloud compute instance-groups managed update fancy-fe-mig \ --zone=$ZONE \ --health-check fancy-fe-hc \ --initial-delay 300 gcloud compute instance-groups managed update fancy-be-mig \ --zone=$ZONE \ --health-check fancy-be-hc \ --initial-delay 300 참고: 자동 복구가 그룹의 인스턴스 모니터링을 시작하려면 15분 정도 걸릴 수 있습니다.

4. 실습을 계속 진행하여 자동 복구를 통해 그룹의 인스턴스를 모니터링할 시간을 확보합니다. 이 실습의 마지막 단계에 자동 복구를 테스트하기 위해 장애를 시뮬레이션합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 관리형 인스턴스 그룹 만들기

작업 6. 부하 분산기 만들기

관리형 인스턴스 그룹을 보완하기 위해 HTTP(S) 부하 분산기를 사용하여 프런트엔드 및 백엔드 마이크로서비스에 트래픽을 제공하고, 매핑을 사용하여 경로 지정 규칙에 따라 적절한 백엔드 서비스에 트래픽을 보냅니다. 이렇게 하면 모든 서비스를 위한 단일 부하 분산 IP가 노출됩니다.

Google Cloud에서 사용할 수 있는 부하 분산 옵션에 대한 자세한 내용은 부하 분산 개요를 참조하세요.

HTTP(S) 부하 분산기 만들기

Google Cloud는 다양한 유형의 부하 분산기를 제공합니다. 이 실습에서는 트래픽을 위한 HTTP(S) 부하 분산기를 사용합니다. HTTP 부하 분산기는 다음과 같이 구성됩니다.

1. 전달 규칙이 수신되는 요청을 대상 HTTP 프록시로 보냅니다.
2. 대상 HTTP 프록시는 각 요청과 URL 맵을 대조해 요청에 맞는 백엔드 서비스를 결정합니다.
3. 백엔드 서비스는 각 요청을 연결된 백엔드의 처리 용량, 영역, 인스턴스 상태를 바탕으로 적절한 백엔드로 보냅니다. HTTP 상태 점검을 사용하여 각 백엔드 인스턴스의 상태를 확인합니다. 백엔드 서비스가 HTTPS 또는 HTTP/2 상태 점검을 사용하도록 구성된 경우에는 요청이 백엔드 인스턴스로 가는 도중에 암호화됩니다.
4. 부하 분산기와 인스턴스 간의 세션은 HTTP, HTTPS 또는 HTTP/2 프로토콜을 사용할 수 있습니다. HTTPS 또는 HTTP/2를 사용하는 경우 백엔드 서비스의 각 인스턴스에 SSL 인증서가 있어야 합니다.

참고: 시연을 목적으로 SSL 인증서의 복잡성을 피하기 위해 HTTPS 대신 HTTP를 사용하세요. 프로덕션에서는 가능하면 암호화에 HTTPS를 사용하는 것이 좋습니다.

1. 각 서비스의 트래픽을 처리할 수 있는 인스턴스를 결정하는 데 사용할 상태 점검을 만듭니다.

gcloud compute http-health-checks create fancy-fe-frontend-hc \ --request-path / \ --port 8080 gcloud compute http-health-checks create fancy-be-orders-hc \ --request-path /api/orders \ --port 8081 gcloud compute http-health-checks create fancy-be-products-hc \ --request-path /api/products \ --port 8082 참고: 이러한 상태 점검은 부하 분산기용이므로 부하 분산기의 직접 트래픽만 처리하며, 관리형 인스턴스 그룹에서 인스턴스를 재생성하도록 만들지 않습니다.

2. 부하 분산된 트래픽의 대상인 백엔드 서비스를 만듭니다. 이 백엔드 서비스는 앞에서 만든 상태 점검과 이름이 지정된 포트를 사용합니다.

gcloud compute backend-services create fancy-fe-frontend \ --http-health-checks fancy-fe-frontend-hc \ --port-name frontend \ --global gcloud compute backend-services create fancy-be-orders \ --http-health-checks fancy-be-orders-hc \ --port-name orders \ --global gcloud compute backend-services create fancy-be-products \ --http-health-checks fancy-be-products-hc \ --port-name products \ --global

3. 부하 분산기의 백엔드 서비스를 추가합니다.

gcloud compute backend-services add-backend fancy-fe-frontend \ --instance-group-zone=$ZONE \ --instance-group fancy-fe-mig \ --global gcloud compute backend-services add-backend fancy-be-orders \ --instance-group-zone=$ZONE \ --instance-group fancy-be-mig \ --global gcloud compute backend-services add-backend fancy-be-products \ --instance-group-zone=$ZONE \ --instance-group fancy-be-mig \ --global

4. URL 맵을 만듭니다. URL 맵은 어떤 URL을 어떤 백엔드 서비스로 전달할지를 정의합니다.

gcloud compute url-maps create fancy-map \ --default-service fancy-fe-frontend

5. /api/orders 및 /api/products 경로가 해당 서비스로 라우팅되도록 허용하는 경로 일치자를 만듭니다.

gcloud compute url-maps add-path-matcher fancy-map \ --default-service fancy-fe-frontend \ --path-matcher-name orders \ --path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"

6. URL 맵에 연결되는 프록시를 만듭니다.

gcloud compute target-http-proxies create fancy-proxy \ --url-map fancy-map

7. 공개 IP 주소와 포트를 프록시에 연결하는 전역 전달 규칙을 만듭니다.

gcloud compute forwarding-rules create fancy-http-rule \ --global \ --target-http-proxy fancy-proxy \ --ports 80

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. HTTP(S) 부하 분산기 만들기

구성 업데이트

새로운 고정 IP 주소가 생겼으니 이제 frontend의 코드를 업데이트하여 이전에 backend 인스턴스를 가리키는 데 사용된 임시 주소 대신 이 새 주소를 가리키도록 합니다.

1. Cloud Shell에서 구성이 저장된 .env 파일이 있는 react-app 폴더로 이동합니다.

cd ~/monolith-to-microservices/react-app/

2. 부하 분산기의 IP 주소를 찾습니다.

gcloud compute forwarding-rules list --global

출력 예시:

NAME: fancy-http-rule REGION: IP_ADDRESS: 34.111.203.235 IP_PROTOCOL: TCP TARGET: fancy-proxy

3. Cloud Shell 편집기로 돌아가서 .env 파일을 다시 수정하여 부하 분산기의 공개 IP를 가리키도록 합니다. [LB_IP]는 위에서 결정된 백엔드 인스턴스의 외부 IP 주소를 나타냅니다.

REACT_APP_ORDERS_URL=http://[LB_IP]/api/orders REACT_APP_PRODUCTS_URL=http://[LB_IP]/api/products 참고: 부하 분산기가 이 전달을 자동으로 처리하도록 구성되었기 때문에 새 주소에서 포트가 삭제되었습니다.

4. 파일을 저장합니다.

5. react-app을 다시 빌드해서 프런트엔드 코드를 업데이트하도록 합니다.

cd ~/monolith-to-microservices/react-app npm install && npm run-script build

6. 애플리케이션 코드를 버킷에 복사합니다.

cd ~ rm -rf monolith-to-microservices/*/node_modules gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

프런트엔드 인스턴스 업데이트

이 새로운 코드와 구성이 생겼으니 이제 관리형 인스턴스 그룹 내의 프런트엔드 인스턴스로 새 코드를 가져오려고 합니다.

인스턴스는 시작할 때 코드를 가져오므로 순차적 다시 시작 명령어를 실행할 수 있습니다.

gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --zone=$ZONE \ --max-unavailable 100% 참고: 이 순차적 교체의 예시에서는 --max-unavailable 파라미터를 사용하여 모든 머신을 즉시 교체할 수 있다고 명시합니다. 이 파라미터가 없으면 이 명령어는 인스턴스를 활성 상태로 유지하면서 다른 머신을 다시 시작하여 가용성을 보장합니다. 테스트를 목적으로 속도를 위해 모두 즉시 교체하도록 지정합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 프런트엔드 인스턴스 업데이트

웹사이트 테스트

1. 인스턴스가 처리될 시간을 주기 위해 rolling-action replace 명령어를 실행한 후 3분간 기다렸다가 관리형 인스턴스 그룹의 상태를 확인합니다. 다음을 실행하여 서비스가 HEALTHY로 표시되는지 확인합니다.

watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global

2. 2개의 서비스가 HEALTHY로 표시될 때까지 기다립니다.

출력 예시:

backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151 ipAddress: 10.128.0.7 port: 8080 - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt ipAddress: 10.128.0.11 port: 8080 kind: compute#backendServiceGroupHealth 참고: 인스턴스 하나에 문제가 발생하면 UNHEALTHY로 나타나고 자동으로 복구됩니다. 이렇게 될 때까지 기다립니다.

잠시 기다린 후에도 HEALTHY 상태로 전환되는 인스턴스가 없으면 프런트엔드 인스턴스 설정에 문제가 있어서 포트 8080에서 해당 인스턴스에 액세스할 수 없는 것입니다. 포트 8080에서 직접 이 인스턴스로 이동하여 이를 테스트합니다.

3. 목록에서 두 항목이 모두 HEALTHY로 나타나면 Ctrl+C를 눌러 watch 명령어를 종료합니다.

참고: 애플리케이션은 http://[LB_IP]를 통해 액세스할 수 있습니다. [LB_IP]는 부하 분산기에 지정된 IP_ADDRESS이며 다음 명령어로 확인할 수 있습니다.

gcloud compute forwarding-rules list --global

이 실습에서 잠시 후 애플리케이션을 확인해 봅니다.

작업 7. Compute Engine 확장

지금까지 각각 2개의 인스턴스가 있는 2개의 관리형 인스턴스 그룹을 만들었습니다. 이 구성은 완벽하게 작동하지만 부하와 관계없이 정적 구성입니다. 다음으로는 사용률을 기준으로 각 관리형 인스턴스 그룹을 자동으로 확장하는 자동 확장 정책을 만듭니다.

사용률을 기준으로 자동 크기 조정

• 자동 확장 정책을 만들기 위해 다음을 실행합니다.

gcloud compute instance-groups managed set-autoscaling \ fancy-fe-mig \ --zone=$ZONE \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60 gcloud compute instance-groups managed set-autoscaling \ fancy-be-mig \ --zone=$ZONE \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60

이 명령어는 관리형 인스턴스 그룹에 대한 자동 확장 처리를 만들어 부하 분산기의 사용률이 60%가 넘으면 자동으로 인스턴스를 추가하고, 사용률이 60% 미만이면 인스턴스를 삭제합니다.

콘텐츠 전송 네트워크 사용 설정

확장에 도움이 될 수 있는 또 다른 기능은 콘텐츠 전송 네트워크 서비스를 사용 설정하여 프런트엔드에 캐싱을 제공하는 것입니다.

• 프런트엔드 서비스에 대해 다음 명령어를 실행합니다.

gcloud compute backend-services update fancy-fe-frontend \ --enable-cdn --global

사용자가 HTTP(S) 부하 분산기에서 콘텐츠를 요청하면 이 요청은 Google 프런트엔드(GFE)에 도착하여 먼저 Cloud CDN 캐시에서 사용자 요청에 대한 응답을 찾습니다. GFE가 캐시된 응답을 찾으면 사용자에게 캐시된 응답을 보냅니다. 이를 캐시 적중이라고 합니다.

GFE가 요청에 대한 캐시된 응답을 찾지 못하면 백엔드에 직접 요청을 보냅니다. 이 요청에 대한 응답이 캐시 가능한 경우 GFE는 응답을 Cloud CDN 캐시에 저장하여 이후 요청이 있을 때 해당 캐시가 사용되도록 합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Compute Engine 확장

작업 8. 웹사이트 업데이트

인스턴스 템플릿 업데이트

기존 인스턴스 템플릿은 수정할 수 없습니다. 그러나 인스턴스가 스테이트리스(Stateless)이고 모든 구성이 시작 스크립트를 통해 수행되므로 템플릿 설정을 변경하려는 경우에만 인스턴스 템플릿을 변경하면 됩니다. 이제 더 큰 머신 유형을 사용하도록 간단히 변경하고 변경사항을 내보냅니다.

다음 단계를 완료합니다.

• 인스턴스 템플릿의 기반 역할을 하는 frontend 인스턴스를 업데이트합니다. 업데이트하는 동안 인스턴스 템플릿 이미지의 업데이트된 버전에 파일을 넣고 나서 인스턴스 템플릿을 업데이트하고 새로운 템플릿을 적용한 다음 관리형 인스턴스 그룹 인스턴스에 해당 파일이 있는지 확인합니다.

• e2-standard-2 머신 유형을 e2-small로 전환하여 인스턴스 템플릿의 머신 유형을 수정합니다.

1. 다음 명령어를 실행하여 프런트엔드 인스턴스의 머신 유형을 수정합니다.

gcloud compute instances set-machine-type frontend \ --zone=$ZONE \ --machine-type e2-small

2. 새 인스턴스 템플릿을 만듭니다.

gcloud compute instance-templates create fancy-fe-new \ --region=$REGION \ --source-instance=frontend \ --source-instance-zone=$ZONE

3. 업데이트된 인스턴스 템플릿을 관리형 인스턴스 그룹에 적용합니다.

gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \ --zone=$ZONE \ --version template=fancy-fe-new

4. 3분간 기다린 후에 다음을 실행하여 업데이트 상태를 모니터링합니다.

watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig \ --zone=$ZONE

몇 분 정도 걸릴 수 있습니다.

다음 조건에 해당하는 인스턴스가 하나라도 있어야 합니다.

• STATUS: RUNNING
• ACTION: None으로 설정됨
• INSTANCE_TEMPLATE: 새로운 템플릿 이름(fancy-fe-new)

5. 다음 명령어에 사용할 수 있게 나열된 머신 중 하나의 이름을 복사합니다.

6. Ctrl+C를 눌러 watch 프로세스를 종료합니다.

7. 다음을 실행하여 가상 머신이 새로운 머신 유형(e2-small)을 사용하고 있는지 확인합니다. [VM_NAME]은 새로 생성된 인스턴스입니다.

gcloud compute instances describe [VM_NAME] --zone=$ZONE | grep machineType

예상되는 출력 예시:

machineType: https://www.googleapis.com/compute/v1/projects/project-name/zones/us-central1-f/machineTypes/e2-small

웹사이트 변경

시나리오: 마케팅팀에서 사이트의 홈페이지를 변경해 달라고 요청했습니다. 마케팅팀은 홈페이지에서 어떤 회사이며 무엇을 판매하는지에 대해 더 많은 정보를 제공해야 한다고 생각합니다.

작업: 마케팅팀이 만족할 수 있도록 홈페이지에 텍스트를 추가합니다. 개발자 한 명이 이미 index.js.new라는 파일 이름에 변경사항을 작성했습니다. 이 파일을 index.js에 복사하기만 하면 변경사항이 적용됩니다. 아래 지침에 따라 적절하게 변경하세요.

1. 다음 명령어를 실행하여 업데이트된 파일을 올바른 파일 이름에 복사합니다.

cd ~/monolith-to-microservices/react-app/src/pages/Home mv index.js.new index.js

2. 파일 콘텐츠를 출력하여 변경사항을 확인합니다.

cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

결과 코드는 다음과 같습니다.

/* Copyright 2019 Google LLC Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ import React from "react"; import { Box, Paper, Typography } from "@mui/material"; export default function Home() { return ( <Box sx={{ flexGrow: 1 }}> <Paper elevation={3} sx={{ width: "800px", margin: "0 auto", padding: (theme) => theme.spacing(3, 2), }} > <Typography variant="h5">Welcome to the Fancy Store!</Typography> <br /> <Typography variant="body1"> Take a look at our wide variety of products. </Typography> </Paper> </Box> ); }

React 구성요소를 업데이트했지만 정적 파일을 생성하려면 React 앱을 빌드해야 합니다.

3. 다음 명령어를 실행하여 React 앱을 빌드한 다음 모놀리식 공개 디렉터리에 복사합니다.

cd ~/monolith-to-microservices/react-app npm install && npm run-script build

4. 그런 다음 이 코드를 다시 버킷으로 내보냅니다.

cd ~ rm -rf monolith-to-microservices/*/node_modules gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

순차적 교체가 포함된 변경사항 내보내기

1. 이제 모든 인스턴스를 강제로 교체하여 업데이트를 가져옵니다.

gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --zone=$ZONE \ --max-unavailable=100%

참고: 이 순차적 교체의 예시에서 --max-unavailable 파라미터를 사용하여 모든 머신을 즉시 교체할 수 있다고 명시하세요. 이 파라미터가 없으면 명령어는 인스턴스를 활성 상태로 유지하면서 다른 머신을 교체합니다. 테스트를 목적으로 속도를 위해 모두 즉시 교체하도록 지정합니다. 프로덕션에서는 버퍼를 남겨두면 업데이트하는 동안에도 계속 웹사이트를 제공할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 웹사이트 업데이트

2. 인스턴스가 처리될 시간을 주기 위해 rolling-action replace 명령어를 실행한 후 3분간 기다렸다가 관리형 인스턴스 그룹의 상태를 확인합니다. 다음을 실행하여 서비스가 HEALTHY로 표시되는지 확인합니다.

watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global

3. 두 서비스가 모두 나타나고 HEALTHY가 될 때까지 잠시 기다립니다.

출력 예시:

backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151 ipAddress: 10.128.0.7 port: 8080 - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt ipAddress: 10.128.0.11 port: 8080 kind: compute#backendServiceGroupHealth

4. 목록에 HEALTHY 상태의 항목이 나타나면 Ctrl+C를 눌러 watch 명령어를 종료합니다.

5. http://[LB_IP]를 통해 웹사이트로 이동합니다. [LB_IP]는 부하 분산기에 지정된 IP_ADDRESS이며 다음 명령어로 확인할 수 있습니다.

gcloud compute forwarding-rules list --global

이제 새로운 웹사이트 변경사항이 표시됩니다.

장애 시뮬레이션

상태 점검이 작동하는지 확인하기 위해 인스턴스에 로그인하여 서비스를 중지합니다.

1. 인스턴스 이름을 찾으려면 다음을 실행합니다.

gcloud compute instance-groups list-instances fancy-fe-mig --zone=$ZONE

2. 인스턴스 이름을 복사한 후에 다음을 실행하여 셸을 INSTANCE_NAME에 고정합니다. INSTANCE_NAME은 목록의 인스턴스 중 하나입니다.

gcloud compute ssh [INSTANCE_NAME] --zone=$ZONE

3. 'y'를 입력하여 확인하고 Enter를 두 번 눌러 비밀번호를 사용하지 않도록 합니다.

4. 인스턴스 안에서 supervisorctl을 사용하여 애플리케이션을 중지합니다.

sudo supervisorctl stop nodeapp; sudo killall node

5. 인스턴스를 종료합니다.

exit

6. 복구 작업을 모니터링합니다.

watch -n 2 gcloud compute operations list \ --filter='operationType~compute.instances.repair.*'

완료되기까지 몇 분 정도 걸립니다.

다음과 같은 출력 예시를 찾아봅니다.

NAME TYPE TARGET HTTP_STATUS STATUS TIMESTAMP repair-1568314034627-5925f90ee238d-fe645bf0-7becce15 compute.instances.repair.recreateInstance us-central1-a/instances/fancy-fe-1vqq 200 DONE 2019-09-12T11:47:14.627-07:00

관리형 인스턴스 그룹이 인스턴스를 다시 만들어 복구했습니다.

7. 또한 탐색 메뉴 > Compute Engine > VM 인스턴스로 이동하여 콘솔을 통해 모니터링할 수도 있습니다.

수고하셨습니다

Compute Engine에서 웹사이트를 배포, 확장, 업데이트했습니다. 이렇게 해서 Compute Engine, 관리형 인스턴스 그룹, 부하 분산기, 상태 점검을 사용해 보았습니다.

다음 단계/더 학습하기

• 관리형 인스턴스 그룹의 자동 복구 및 상태 점검

• Google Cloud의 확장 가능한 웹 애플리케이션 호스팅에서 이 동영상 우수사례를 시청하세요.

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2024년 4월 26일

실습 최종 테스트: 2023년 12월 15일

Copyright 2024 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.