체크포인트
Create GCS bucket
/ 10
Copy startup script and code to Cloud Storage bucket
/ 10
Deploy instances and configure network
/ 20
Create managed instance groups
/ 20
Create HTTP(S) load balancers
/ 10
Update the frontend instances
/ 10
Scaling GCE
/ 10
Update the website
/ 10
Compute Engine을 사용하여 Google Cloud에 웹 앱 호스팅
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 콘솔 열기 버튼
- 남은 시간
- 이 실습에 사용해야 하는 임시 사용자 인증 정보
- 필요한 경우 실습 진행을 위한 기타 정보
-
Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).
실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.
팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.
참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다. -
필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.
{{{user_0.username | "Username"}}} 실습 세부정보 패널에서도 사용자 이름을 확인할 수 있습니다.
-
다음을 클릭합니다.
-
아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.
{{{user_0.password | "Password"}}} 실습 세부정보 패널에서도 비밀번호를 확인할 수 있습니다.
-
다음을 클릭합니다.
중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다. -
이후에 표시되는 페이지를 클릭하여 넘깁니다.
- 이용약관에 동의합니다.
- 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
- 무료 체험판을 신청하지 않습니다.
잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.
Cloud Shell 활성화
Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.
- Google Cloud 콘솔 상단에서 Cloud Shell 활성화
를 클릭합니다.
연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 PROJECT_ID로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.
gcloud
는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.
- (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.
-
승인을 클릭합니다.
-
다음과 비슷한 결과가 출력됩니다.
출력:
- (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.
출력:
출력 예시:
gcloud
전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참조하세요.
리전 및 영역 설정하기
특정 Compute Engine 리소스는 여러 리전과 영역에 상주합니다. 리전은 리소스를 실행할 수 있는 특정한 지리적 위치로, 각 리전에는 영역이 하나 이상 있습니다.
Cloud 콘솔에서 다음 gcloud 명령어를 실행하여 실습의 기본 리전과 영역을 설정합니다.
작업 1. Compute Engine API 사용 설정
- 다음을 실행하여 Compute Engine API를 사용 설정합니다.
작업 2. Cloud Storage 버킷 만들기
Cloud Storage 버킷을 사용하여 빌드한 코드와 시작 스크립트를 저장합니다.
- Cloud Shell에서 다음을 실행하여 새로운 Cloud Storage 버킷을 만듭니다.
$DEVSHELL_PROJECT_ID
환경 변수를 사용하면 고유한 객체 이름을 사용하는 데 도움이 됩니다. Google Cloud 내의 모든 프로젝트 ID는 고유해야 하므로 프로젝트 ID를 추가하면 다른 이름의 고유성도 유지됩니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
작업 3. 소스 저장소 클론
monolith-to-microservices
저장소를 기반으로 하는 기존 Fancy Store 전자상거래 웹사이트를 웹사이트의 기초로 사용합니다.
Compute Engine에 배포하는 작업에 집중할 수 있도록 소스 코드를 클론합니다. 잠시 후 이 실습에서 이 코드를 약간 업데이트하여 Compute Engine에서 업데이트하기가 얼마나 간단한지 시연해 봅니다.
- 소스 코드를 클론한 다음
monolith-to-microservices
디렉터리로 이동합니다.
- 코드의 초기 빌드를 실행하여 애플리케이션을 로컬로 실행할 수 있게 합니다.
이 스크립트가 완료되는 데 몇 분 정도 걸릴 수 있습니다.
- 완료되면 다음 명령어를 사용하여 Cloud Shell이 호환 가능한 nodeJS 버전을 실행할 수 있게 합니다.
- 그리고 다음 명령어를 실행하여 애플리케이션을 테스트하고
microservices
디렉터리로 전환한 다음 웹 서버를 시작합니다.
다음과 같은 출력이 표시됩니다.
- 웹 미리보기 아이콘을 클릭하고 포트 8080에서 미리보기를 선택하여 애플리케이션을 미리 봅니다.
그러면 Fancy Store의 프런트엔드를 볼 수 있는 새 창이 열립니다.
- 웹사이트를 본 후에 이 창을 닫은 다음 터미널 창에서 Ctrl+C를 눌러 웹 서버 프로세스를 중지합니다.
작업 4. Compute Engine 인스턴스 만들기
이제 Compute Engine 인스턴스 배포를 시작할 차례입니다.
다음 단계에서는 다음을 수행합니다.
- 인스턴스를 구성하는 시작 스크립트를 만듭니다.
- 소스 코드를 클론하여 Cloud Storage로 업로드합니다.
- Compute Engine 인스턴스를 배포하여 백엔드 마이크로서비스를 호스팅합니다.
- 백엔드 마이크로서비스 인스턴스를 활용하도록 프런트엔드 코드를 재구성합니다.
- Compute Engine 인스턴스를 배포하여 프런트엔드 마이크로서비스를 호스팅합니다.
- 통신을 허용하도록 네트워크를 구성합니다.
시작 스크립트 만들기
시작 스크립트는 인스턴스가 시작될 때마다 수행할 작업을 인스턴스에 지시하는 데 사용됩니다. 이렇게 하면 인스턴스가 자동으로 구성됩니다.
- Cloud Shell에서 다음 명령어를 실행하여
startup-script.sh
라는 이름의 파일을 만듭니다.
- Cloud Shell 리본에서 편집기 열기를 클릭하여 코드 편집기를 엽니다.
-
monolith-to-microservices
폴더로 이동합니다. -
다음 코드를
startup-script.sh
파일에 추가합니다. 코드를 추가한 후에 일부를 수정합니다.
- 파일에서
[DEVSHELL_PROJECT_ID]
라는 텍스트를 찾아서 프로젝트 ID()로 바꿉니다.
그러면 startup-script.sh
안에서 해당 코드 줄이 다음과 같이 됩니다.
-
startup-script.sh
파일을 저장하지만 아직 닫지 않습니다. -
Cloud Shell 코드 편집기의 오른쪽 하단에서 '줄 끝 시퀀스'가 'CRLF'가 아니라 'LF'로 설정되어 있는지 확인합니다.
- CRLF로 설정되어 있으면 CRLF를 클릭한 다음 드롭다운에서 LF를 선택합니다.
- 이미 LF로 설정되어 있으면 그대로 둡니다.
-
startup-script.sh
파일을 닫습니다. -
Cloud Shell 터미널로 돌아가서 다음을 실행하여
startup-script.sh
파일을 버킷에 복사합니다.
이제 다음 주소에서 액세스할 수 있습니다. 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
파일 안에 일부 구성 변수를 저장할 수 있습니다.
- 클론 코드를 버킷에 복사합니다.
node_modules
종속 항목 디렉터리는 삭제됩니다. 이 디렉터리는 인스턴스가 시작될 때 인스턴스에서 다시 생성됩니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
백엔드 인스턴스 배포
가장 먼저 배포할 인스턴스는 주문 및 제품 마이크로서비스를 저장할 백엔드 인스턴스입니다.
- 다음 명령어를 실행하여 시작 스크립트를 사용하도록 구성된
e2-standard-2
인스턴스를 생성합니다. 나중에 특정 방화벽 규칙을 적용할 수 있도록backend
인스턴스 태그가 지정됩니다.
백엔드에 대한 연결 구성
애플리케이션의 프런트엔드를 배포하기 전에 방금 배포한 백엔드를 가리키도록 구성을 업데이트해야 합니다.
- 다음 명령어를 사용하여 백엔드의 외부 IP 주소를 검색하고
EXTERNAL_IP
탭에서 백엔드 인스턴스를 확인합니다.
출력 예시:
-
백엔드의 외부 IP를 복사합니다.
-
Cloud Shell 탐색기에서
monolith-to-microservices
>react-app
으로 이동합니다. -
코드 편집기에서 보기 > 숨은 파일 전환을 선택하여
.env
파일을 확인합니다.
다음 단계에서는 백엔드의 외부 IP를 가리키도록 .env
파일을 수정합니다. [BACKEND_ADDRESS]는 위의 gcloud
명령어로 확인된 백엔드 인스턴스의 외부 IP 주소를 나타냅니다.
-
.env
파일에서localhost
를[BACKEND_ADDRESS]
로 바꿉니다.
-
파일을 저장합니다.
-
Cloud Shell에서 다음을 실행하여
react-app
을 다시 빌드해서 프런트엔드 코드를 업데이트합니다.
- 그런 다음 애플리케이션 코드를 Cloud Storage 버킷에 복사합니다.
프런트엔드 인스턴스 배포
코드가 구성되었으니 이제 프런트엔드 인스턴스를 배포합니다.
- 앞서 사용한 것과 유사한 명령어로 다음을 실행하여
frontend
인스턴스를 배포합니다. 이 인스턴스에는 방화벽 용도로frontend
태그가 지정됩니다.
네트워크 구성
- 프런트엔드의 경우 포트 8080에, 백엔드의 경우 포트 8081~8082에 대한 액세스를 허용하는 방화벽 규칙을 생성합니다. 다음 방화벽 명령어는 애플리케이션의 인스턴스 생성 중에 지정된 태그를 사용합니다.
이제 웹사이트가 완전히 작동합니다.
-
frontend
의 외부 IP로 이동하려면 주소를 알아야 합니다. 다음을 실행하고frontend
인스턴스의 EXTERNAL_IP를 찾습니다.
출력 예시:
인스턴스를 시작하고 구성하는 데 몇 분 정도 걸릴 수 있습니다.
-
3분간 기다렸다가 새 브라우저 탭을 열고
http://[FRONTEND_ADDRESS]:8080
으로 이동하여 웹사이트에 액세스합니다. [FRONTEND_ADDRESS]는 위에서 확인한 프런트엔드 EXTERNAL_IP입니다. -
제품 및 주문 페이지로 이동합니다. 이제 해당 페이지가 작동합니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
작업 5. 관리형 인스턴스 그룹 만들기
애플리케이션을 확장할 수 있게 하기 위해 관리형 인스턴스 그룹을 만들고 frontend
및 backend
인스턴스를 인스턴스 템플릿으로 사용합니다.
관리형 인스턴스 그룹(MIG)에는 동일한 인스턴스가 포함되어 있어 단일 영역에서 단일 항목으로 관리할 수 있습니다. 관리형 인스턴스 그룹은 인스턴스를 사용할 수 있는 상태, 즉 RUNNING 상태를 선제적으로 유지하여 앱의 고가용성을 유지합니다. 프런트엔드 및 백엔드 인스턴스의 관리형 인스턴스 그룹을 사용하여 자동 복구, 부하 분산, 자동 확장, 순차적 업데이트를 제공해 봅니다.
소스 인스턴스에서 인스턴스 템플릿 만들기
관리형 인스턴스 그룹을 만들려면 먼저 그룹의 기반이 될 인스턴스 템플릿을 만들어야 합니다. 인스턴스 템플릿은 새로운 VM 인스턴스를 만들 때 사용할 머신 유형, 부팅 디스크 이미지 또는 컨테이너 이미지, 네트워크, 기타 인스턴스 속성을 정의하는 데 사용할 수 있습니다. 인스턴스 템플릿을 사용하면 관리형 인스턴스 그룹에 인스턴스를 만들거나 개별 인스턴스를 만들 수도 있습니다.
인스턴스 템플릿을 만들기 위해 이전에 만든 기존 인스턴스를 사용합니다.
- 먼저 두 인스턴스를 중지합니다.
- 그런 다음 각 소스 인스턴스에서 인스턴스 템플릿을 만듭니다.
- 생성된 인스턴스 템플릿을 확인합니다.
출력 예시:
- 인스턴스 템플릿이 생성된 상태에서 리소스 공간을 절약하기 위해
backend
VM을 삭제합니다.
- 메시지가 표시되면 y를 입력하고 Enter 키를 누릅니다.
일반적으로 frontend
VM도 삭제할 수 있지만 이 실습에서는 나중에 인스턴스 템플릿을 업데이트하는 데 사용합니다.
관리형 인스턴스 그룹 만들기
- 다음으로 두 개의 관리형 인스턴스 그룹을 만듭니다. 하나는 프런트엔드용이고 다른 하나는 백엔드용입니다.
이러한 관리형 인스턴스 그룹은 인스턴스 템플릿을 사용하며 각 그룹 내에서 두 개의 인스턴스가 각각 시작되도록 구성됩니다. 인스턴스 이름은 base-instance-name
을 기반으로 임의의 문자가 추가되도록 자동 지정됩니다.
- 애플리케이션을 위해
frontend
마이크로서비스가 포트 8080에서 실행되고,backend
마이크로서비스는orders
의 경우 포트 8081에서, products의 경우 포트 8082에서 실행됩니다.
이는 비표준 포트이므로 식별하기 위해 이름이 지정된 포트를 명시해야 합니다. 이름이 지정된 포트는 서비스 이름과 서비스가 실행되는 포트를 나타내는 키-값 쌍 메타데이터로 인스턴스 그룹에 할당될 수 있습니다. 즉, 그룹의 모든 인스턴스에서 서비스를 이용할 수 있음을 나타냅니다. 이 정보는 나중에 구성할 HTTP 부하 분산 서비스에서 사용됩니다.
자동 복구 구성
애플리케이션 자체의 가용성을 개선하고 애플리케이션이 응답하는지 확인하기 위해 관리형 인스턴스 그룹의 자동 복구 정책을 구성합니다.
자동 복구 정책은 애플리케이션 기반 상태 점검을 사용하여 앱이 예상대로 응답하는지 확인합니다. 단순히 인스턴스가 RUNNING 상태인지 확인하는 기본 동작보다 앱이 응답하는지 확인하는 것이 더 정확합니다.
- 인스턴스가
frontend
및backend
에 대해 3번 연속으로 'unhealthy'를 반환하면 인스턴스를 복구하는 상태 점검을 만듭니다.
- 상태 점검 프로브가 포트 8080~8081의 마이크로서비스에 연결되도록 허용하는 방화벽 규칙을 만듭니다.
- 이 상태 점검을 해당 서비스에 적용합니다.
- 실습을 계속 진행하여 자동 복구를 통해 그룹의 인스턴스를 모니터링할 시간을 확보합니다. 이 실습의 마지막 단계에 자동 복구를 테스트하기 위해 장애를 시뮬레이션합니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
작업 6. 부하 분산기 만들기
관리형 인스턴스 그룹을 보완하기 위해 HTTP(S) 부하 분산기를 사용하여 프런트엔드 및 백엔드 마이크로서비스에 트래픽을 제공하고, 매핑을 사용하여 경로 지정 규칙에 따라 적절한 백엔드 서비스에 트래픽을 보냅니다. 이렇게 하면 모든 서비스를 위한 단일 부하 분산 IP가 노출됩니다.
Google Cloud에서 사용할 수 있는 부하 분산 옵션에 대한 자세한 내용은 부하 분산 개요를 참조하세요.
HTTP(S) 부하 분산기 만들기
Google Cloud는 다양한 유형의 부하 분산기를 제공합니다. 이 실습에서는 트래픽을 위한 HTTP(S) 부하 분산기를 사용합니다. HTTP 부하 분산기는 다음과 같이 구성됩니다.
- 전달 규칙이 수신되는 요청을 대상 HTTP 프록시로 보냅니다.
- 대상 HTTP 프록시는 각 요청과 URL 맵을 대조해 요청에 맞는 백엔드 서비스를 결정합니다.
- 백엔드 서비스는 각 요청을 연결된 백엔드의 처리 용량, 영역, 인스턴스 상태를 바탕으로 적절한 백엔드로 보냅니다. HTTP 상태 점검을 사용하여 각 백엔드 인스턴스의 상태를 확인합니다. 백엔드 서비스가 HTTPS 또는 HTTP/2 상태 점검을 사용하도록 구성된 경우에는 요청이 백엔드 인스턴스로 가는 도중에 암호화됩니다.
- 부하 분산기와 인스턴스 간의 세션은 HTTP, HTTPS 또는 HTTP/2 프로토콜을 사용할 수 있습니다. HTTPS 또는 HTTP/2를 사용하는 경우 백엔드 서비스의 각 인스턴스에 SSL 인증서가 있어야 합니다.
- 각 서비스의 트래픽을 처리할 수 있는 인스턴스를 결정하는 데 사용할 상태 점검을 만듭니다.
- 부하 분산된 트래픽의 대상인 백엔드 서비스를 만듭니다. 이 백엔드 서비스는 앞에서 만든 상태 점검과 이름이 지정된 포트를 사용합니다.
- 부하 분산기의 백엔드 서비스를 추가합니다.
- URL 맵을 만듭니다. URL 맵은 어떤 URL을 어떤 백엔드 서비스로 전달할지를 정의합니다.
-
/api/orders
및/api/products
경로가 해당 서비스로 라우팅되도록 허용하는 경로 일치자를 만듭니다.
- URL 맵에 연결되는 프록시를 만듭니다.
- 공개 IP 주소와 포트를 프록시에 연결하는 전역 전달 규칙을 만듭니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
구성 업데이트
새로운 고정 IP 주소가 생겼으니 이제 frontend
의 코드를 업데이트하여 이전에 backend
인스턴스를 가리키는 데 사용된 임시 주소 대신 이 새 주소를 가리키도록 합니다.
- Cloud Shell에서 구성이 저장된
.env
파일이 있는react-app
폴더로 이동합니다.
- 부하 분산기의 IP 주소를 찾습니다.
출력 예시:
- Cloud Shell 편집기로 돌아가서
.env
파일을 다시 수정하여 부하 분산기의 공개 IP를 가리키도록 합니다. [LB_IP]는 위에서 결정된 백엔드 인스턴스의 외부 IP 주소를 나타냅니다.
-
파일을 저장합니다.
-
react-app
을 다시 빌드해서 프런트엔드 코드를 업데이트하도록 합니다.
- 애플리케이션 코드를 버킷에 복사합니다.
프런트엔드 인스턴스 업데이트
이 새로운 코드와 구성이 생겼으니 이제 관리형 인스턴스 그룹 내의 프런트엔드 인스턴스로 새 코드를 가져오려고 합니다.
인스턴스는 시작할 때 코드를 가져오므로 순차적 다시 시작 명령어를 실행할 수 있습니다.
--max-unavailable
파라미터를 사용하여 모든 머신을 즉시 교체할 수 있다고 명시합니다. 이 파라미터가 없으면 이 명령어는 인스턴스를 활성 상태로 유지하면서 다른 머신을 다시 시작하여 가용성을 보장합니다. 테스트를 목적으로 속도를 위해 모두 즉시 교체하도록 지정합니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
웹사이트 테스트
- 인스턴스가 처리될 시간을 주기 위해
rolling-action replace
명령어를 실행한 후 3분간 기다렸다가 관리형 인스턴스 그룹의 상태를 확인합니다. 다음을 실행하여 서비스가 HEALTHY로 표시되는지 확인합니다.
- 2개의 서비스가 HEALTHY로 표시될 때까지 기다립니다.
출력 예시:
잠시 기다린 후에도 HEALTHY 상태로 전환되는 인스턴스가 없으면 프런트엔드 인스턴스 설정에 문제가 있어서 포트 8080에서 해당 인스턴스에 액세스할 수 없는 것입니다. 포트 8080에서 직접 이 인스턴스로 이동하여 이를 테스트합니다.
- 목록에서 두 항목이 모두 HEALTHY로 나타나면 Ctrl+C를 눌러
watch
명령어를 종료합니다.
gcloud compute forwarding-rules list --global
작업 7. Compute Engine 확장
지금까지 각각 2개의 인스턴스가 있는 2개의 관리형 인스턴스 그룹을 만들었습니다. 이 구성은 완벽하게 작동하지만 부하와 관계없이 정적 구성입니다. 다음으로는 사용률을 기준으로 각 관리형 인스턴스 그룹을 자동으로 확장하는 자동 확장 정책을 만듭니다.
사용률을 기준으로 자동 크기 조정
- 자동 확장 정책을 만들기 위해 다음을 실행합니다.
이 명령어는 관리형 인스턴스 그룹에 대한 자동 확장 처리를 만들어 부하 분산기의 사용률이 60%가 넘으면 자동으로 인스턴스를 추가하고, 사용률이 60% 미만이면 인스턴스를 삭제합니다.
콘텐츠 전송 네트워크 사용 설정
확장에 도움이 될 수 있는 또 다른 기능은 콘텐츠 전송 네트워크 서비스를 사용 설정하여 프런트엔드에 캐싱을 제공하는 것입니다.
- 프런트엔드 서비스에 대해 다음 명령어를 실행합니다.
사용자가 HTTP(S) 부하 분산기에서 콘텐츠를 요청하면 이 요청은 Google 프런트엔드(GFE)에 도착하여 먼저 Cloud CDN 캐시에서 사용자 요청에 대한 응답을 찾습니다. GFE가 캐시된 응답을 찾으면 사용자에게 캐시된 응답을 보냅니다. 이를 캐시 적중이라고 합니다.
GFE가 요청에 대한 캐시된 응답을 찾지 못하면 백엔드에 직접 요청을 보냅니다. 이 요청에 대한 응답이 캐시 가능한 경우 GFE는 응답을 Cloud CDN 캐시에 저장하여 이후 요청이 있을 때 해당 캐시가 사용되도록 합니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
작업 8. 웹사이트 업데이트
인스턴스 템플릿 업데이트
기존 인스턴스 템플릿은 수정할 수 없습니다. 그러나 인스턴스가 스테이트리스(Stateless)이고 모든 구성이 시작 스크립트를 통해 수행되므로 템플릿 설정을 변경하려는 경우에만 인스턴스 템플릿을 변경하면 됩니다. 이제 더 큰 머신 유형을 사용하도록 간단히 변경하고 변경사항을 내보냅니다.
다음 단계를 완료합니다.
-
인스턴스 템플릿의 기반 역할을 하는
frontend
인스턴스를 업데이트합니다. 업데이트하는 동안 인스턴스 템플릿 이미지의 업데이트된 버전에 파일을 넣고 나서 인스턴스 템플릿을 업데이트하고 새로운 템플릿을 적용한 다음 관리형 인스턴스 그룹 인스턴스에 해당 파일이 있는지 확인합니다. -
e2-standard-2
머신 유형을e2-small
로 전환하여 인스턴스 템플릿의 머신 유형을 수정합니다.
- 다음 명령어를 실행하여 프런트엔드 인스턴스의 머신 유형을 수정합니다.
- 새 인스턴스 템플릿을 만듭니다.
- 업데이트된 인스턴스 템플릿을 관리형 인스턴스 그룹에 적용합니다.
- 3분간 기다린 후에 다음을 실행하여 업데이트 상태를 모니터링합니다.
몇 분 정도 걸릴 수 있습니다.
다음 조건에 해당하는 인스턴스가 하나라도 있어야 합니다.
- STATUS: RUNNING
- ACTION: None으로 설정됨
- INSTANCE_TEMPLATE: 새로운 템플릿 이름(fancy-fe-new)
-
다음 명령어에 사용할 수 있게 나열된 머신 중 하나의 이름을 복사합니다.
-
Ctrl+C를 눌러
watch
프로세스를 종료합니다. -
다음을 실행하여 가상 머신이 새로운 머신 유형(e2-small)을 사용하고 있는지 확인합니다. [VM_NAME]은 새로 생성된 인스턴스입니다.
예상되는 출력 예시:
웹사이트 변경
시나리오: 마케팅팀에서 사이트의 홈페이지를 변경해 달라고 요청했습니다. 마케팅팀은 홈페이지에서 어떤 회사이며 무엇을 판매하는지에 대해 더 많은 정보를 제공해야 한다고 생각합니다.
작업: 마케팅팀이 만족할 수 있도록 홈페이지에 텍스트를 추가합니다. 개발자 한 명이 이미 index.js.new
라는 파일 이름에 변경사항을 작성했습니다. 이 파일을 index.js
에 복사하기만 하면 변경사항이 적용됩니다. 아래 지침에 따라 적절하게 변경하세요.
- 다음 명령어를 실행하여 업데이트된 파일을 올바른 파일 이름에 복사합니다.
- 파일 콘텐츠를 출력하여 변경사항을 확인합니다.
결과 코드는 다음과 같습니다.
React 구성요소를 업데이트했지만 정적 파일을 생성하려면 React 앱을 빌드해야 합니다.
- 다음 명령어를 실행하여 React 앱을 빌드한 다음 모놀리식 공개 디렉터리에 복사합니다.
- 그런 다음 이 코드를 다시 버킷으로 내보냅니다.
순차적 교체가 포함된 변경사항 내보내기
- 이제 모든 인스턴스를 강제로 교체하여 업데이트를 가져옵니다.
참고: 이 순차적 교체의 예시에서 --max-unavailable
파라미터를 사용하여 모든 머신을 즉시 교체할 수 있다고 명시하세요. 이 파라미터가 없으면 명령어는 인스턴스를 활성 상태로 유지하면서 다른 머신을 교체합니다. 테스트를 목적으로 속도를 위해 모두 즉시 교체하도록 지정합니다. 프로덕션에서는 버퍼를 남겨두면 업데이트하는 동안에도 계속 웹사이트를 제공할 수 있습니다.
내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.
- 인스턴스가 처리될 시간을 주기 위해
rolling-action replace
명령어를 실행한 후 3분간 기다렸다가 관리형 인스턴스 그룹의 상태를 확인합니다. 다음을 실행하여 서비스가 HEALTHY로 표시되는지 확인합니다.
- 두 서비스가 모두 나타나고 HEALTHY가 될 때까지 잠시 기다립니다.
출력 예시:
-
목록에 HEALTHY 상태의 항목이 나타나면 Ctrl+C를 눌러
watch
명령어를 종료합니다. -
http://[LB_IP]
를 통해 웹사이트로 이동합니다. [LB_IP]는 부하 분산기에 지정된 IP_ADDRESS이며 다음 명령어로 확인할 수 있습니다.
이제 새로운 웹사이트 변경사항이 표시됩니다.
장애 시뮬레이션
상태 점검이 작동하는지 확인하기 위해 인스턴스에 로그인하여 서비스를 중지합니다.
- 인스턴스 이름을 찾으려면 다음을 실행합니다.
- 인스턴스 이름을 복사한 후에 다음을 실행하여 셸을 INSTANCE_NAME에 고정합니다. INSTANCE_NAME은 목록의 인스턴스 중 하나입니다.
-
'y'를 입력하여 확인하고 Enter를 두 번 눌러 비밀번호를 사용하지 않도록 합니다.
-
인스턴스 안에서
supervisorctl
을 사용하여 애플리케이션을 중지합니다.
- 인스턴스를 종료합니다.
- 복구 작업을 모니터링합니다.
완료되기까지 몇 분 정도 걸립니다.
다음과 같은 출력 예시를 찾아봅니다.
관리형 인스턴스 그룹이 인스턴스를 다시 만들어 복구했습니다.
- 또한 탐색 메뉴 > 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의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.