GSP343

소개

챌린지 실습에서는 시나리오와 일련의 작업이 주어집니다. 단계별 안내를 따르는 방식이 아니라 퀘스트의 실습에서 학습한 기술을 사용해 작업을 완료할 방법을 스스로 찾아야 합니다. 이 페이지에 표시되어 있는 자동 채점 시스템에서 작업을 제대로 완료했는지 피드백을 제공합니다.

챌린지 실습을 진행할 때는 새로운 Google Cloud 개념에 대한 정보가 제공되지 않습니다. 학습한 기술을 응용하여 기본값을 변경하거나 오류 메시지를 읽고 조사하여 실수를 바로잡아야 합니다.

100점을 받으려면 시간 내에 모든 작업을 성공적으로 완료해야 합니다.

이 실습은 Optimize Costs for Google Kubernetes Engine 과정에 등록한 수강생에게만 권장됩니다. 챌린지에 도전할 준비가 되셨나요?

설정 및 요건

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

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

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

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

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

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

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

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

챌린지 시나리오

여러분은 OnlineBoutique 온라인 매장을 관리하는 팀의 Google Kubernetes Engine 리드 관리자입니다.

팀의 사이트를 Google Kubernetes Engine에 배포할 준비가 되었으나 비용은 낮추고 성과는 높일 방법이 있는지 찾고 있습니다.

OnlineBoutique 앱을 GKE에 배포해야 하며 비용 최적화를 위해 권장된 구성 변경사항을 적용해야 합니다.

배포 시 따라야 할 가이드라인은 다음과 같습니다.

• 영역에서 클러스터를 만듭니다.
• 이름 지정 스키마에 따라 team-resource-number 형식이어야 합니다(예: 클러스터의 이름을 (으)로 지정).
• 첫 클러스터의 경우 머신 크기를 e2-standard-2(2 vCPU, 8GB 메모리)로 시작합니다.
• 빠른 release-channel을 사용하도록 클러스터를 설정합니다.

작업 1. 클러스터 생성 및 앱 배포

1. 애플리케이션을 배포하기 전에 클러스터를 만들고 이름을 (이)라고 지어야 합니다.

2. 작은 크기로 시작해서 노드가 2개뿐인 영역 클러스터를 만듭니다.

3. 온라인 매장을 배포하기 전에 2가지 환경, 즉 dev와 prod에 따라 클러스터의 리소스를 구분하기 위해 네임스페이스를 설정해야 합니다.

4. 마쳤으면 다음 명령어를 사용하여 애플리케이션을 dev 네임스페이스에 배포합니다.

git clone https://github.com/GoogleCloudPlatform/microservices-demo.git && cd microservices-demo && kubectl apply -f ./release/kubernetes-manifests.yaml --namespace dev

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 클러스터 생성 및 앱 배포

작업 2. 최적화된 노드 풀로 마이그레이션

1. dev 네임스페이스에 앱을 배포한 후에는 노드 세부정보를 살펴봅니다.

클러스터의 노드 풀을 변경해야 한다는 결론에 이르게 됩니다.

• 현재 배포에는 RAM이 많이 남기 때문에 더 적은 RAM을 제공하는 머신으로 노드 풀을 사용할 수 있습니다.
• 복제본 수 증가 고려 대상이 되는 배포에는 대부분 추가 포드당 100mcpu만 필요합니다. 더 작은 머신을 사용하도록 구성한다면 더 적은 총 CPU로 노드 풀을 사용할 수 있습니다. 그러나 조정해야 하는 배포의 수와 조정 규모 또한 고려해야 합니다.

2. 머신 유형이 custom-2-3584이고 이름이 인 새로운 노드 풀을 만듭니다.

3. 노드 수를 2로 설정합니다.

4. 새로운 노드 풀이 설정되면 default-pool을 차단하고 드레이닝하여 애플리케이션의 배포를 새로운 노드 풀로 마이그레이션합니다.

5. 배포가 안전하게 마이그레이션되면 default-pool을 삭제합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 최적화된 노드 풀로 마이그레이션

작업 3. 프런트엔드 업데이트 적용

방금 모두 배포했는데 개발팀에서 예정된 출시 전에 마지막 업데이트를 푸시하고 싶어 합니다. 그래도 괜찮습니다. 다운타임을 야기하지 않고 진행할 수 있습니다.

1. 프런트엔드 배포에 포드 중단 예산을 설정합니다.

2. 이름을 onlineboutique-frontend-pdb로 지정합니다.

3. 배포의 min-availability를 1로 설정합니다.

이제 팀의 업데이트를 적용할 수 있습니다. 개발팀에서 홈페이지의 배너에 사용되는 파일을 변경하고 업데이트된 Docker 이미지를 제공했습니다.

gcr.io/qwiklabs-resources/onlineboutique-frontend:v2.1

4. 프런트엔드 배포를 수정하고 프런트엔드 이미지를 업데이트된 이미지로 변경합니다.

5. 배포를 수정하는 동안 ImagePullPolicy를 Always로 변경합니다.

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

작업 4. 예상 트래픽에 따라 자동 확장

OnlineBoutique 온라인 매장의 트래픽을 급증시킬 마케팅 캠페인이 곧 시작됩니다. 일반적으로는 트래픽 급증을 예상하고 대처하기 위해 미리 여유 리소스를 가동합니다. 그러나 트래픽 급증 규모가 예상보다 크면 한밤중에 연락을 받고 일어나 로드를 처리할 리소스를 더 가동해야 하는 불상사가 생길 수 있습니다.

여유 리소스가 필요 이상으로 오래 실행되는 일도 피하고자 합니다. 비용을 낮추면서 골치 아픈 일을 예방하기 위해서는 로드가 급증하기 시작할 때 Kubernetes 배포가 자동으로 조정되도록 구성하면 됩니다.

1. 수평형 포드 자동 확장을 프런트엔드 배포에 적용하여 트래픽 급증을 처리합니다.

2. 목표 CPU 비율 50%를 기준으로 조정합니다.

3. 포드 확장을 최소 1에서 최대 (으)로 설정합니다.

물론 배포가 확장되는 동안 사용자가 다운타임을 겪지 않도록 해야 합니다.

4. 다운타임 없이 확장 작업이 이루어지도록 목표 CPU 비율인 50%를 기준으로 배포가 조정되도록 설정합니다. 그러면 자동 확장이 실행되는 동안 로드를 처리할 공간이 충분해집니다.

5. 배포가 최소 포드 1개에서 최대 개 범위로 조정되도록 설정하세요.

하지만 현재 프로비저닝한 컴퓨팅 리소스를 초과하여 트래픽이 급증하면 어떻게 해야 할까요? 컴퓨팅 노드를 더 추가해야 할 수도 있습니다.

6. 다음으로, 클러스터가 필요에 따라 자동으로 컴퓨팅 노드를 더 가동할 수 있도록 합니다. 그러나 자동 확장으로 수직 확장만 처리할 수 있는 것은 아닙니다.

7. 사전에 대비하면서 노드의 최소 개수와 최대 개수를 구성하면 클러스터에서 트래픽이 높을 때는 노드를 추가하고 트래픽이 낮을 때는 노드를 줄일 수 있습니다.

8. 클러스터 자동 확장 처리를 업데이트하여 최소 노드 1개에서 최대 노드 6개로 조정되도록 하세요.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 예상 트래픽에 따라 자동 확장

9. 마지막으로, 트래픽 급증을 시뮬레이션하기 위해 로드 테스트를 실행합니다.

다행히도 OnlineBoutique에는 로드 생성이 내장되어 있습니다. 현재 dev 인스턴스가 약 10명의 동시 사용자를 기준으로 온라인몰의 트래픽을 시뮬레이션하고 있습니다.

10. 이 이벤트에 예상되는 트래픽을 더 정확하게 반영하기 위해서는 loadgenerator 포드에서 다음 명령어를 사용해 더 많은 동시 사용자를 기준으로 로드 생성을 실행합니다. YOUR_FRONTEND_EXTERNAL_IP를 frontend-external 서비스의 IP로 대체합니다.

kubectl exec $(kubectl get pod --namespace=dev | grep 'loadgenerator' | cut -f1 -d ' ') -it --namespace=dev -- bash -c 'export USERS=8000; locust --host="http://YOUR_FRONTEND_EXTERNAL_IP" --headless -u "8000" 2>&1'

11. 이제 워크로드를 관찰하고 클러스터가 트래픽 급증을 어떻게 처리하는지 모니터링합니다.

수요가 늘어나면서 recommendationservice가 다운되거나 적어도 정체되는 것을 볼 수 있을 겁니다.

12. 수평형 포드 자동 확장을 recommendationservice 배포에 적용합니다. 목표 CPU 비율인 50%를 기준으로 조정하고 포드 확장을 최소 1에서 최대 5로 설정합니다.

참고: 로드 테스트를 통해 확장하고 새로운 노드를 프로비저닝하는 과정에는 총 몇 분 정도 소요될 수 있습니다.

작업 5. (선택사항) 다른 서비스 최적화

프런트엔드 서비스에 수평형 포드 자동 확장을 적용하면 로드 테스트 중에 애플리케이션을 사용할 수 있지만 다른 워크로드를 모니터링하면 일부 애플리케이션이 특정 리소스에 대해 과도하게 푸시되는 것을 보게 됩니다.

실습 시간이 남았다면 다른 워크로드를 살펴보고 적절한 리소스 측정항목에 자동 확장을 적용하여 워크로드를 최적화해 보세요.

노드 자동 프로비저닝을 통해 리소스 사용을 더 최적화할 수 있는지도 확인해 볼 수 있습니다.

수고하셨습니다

수고하셨습니다. 이 실습에서는 OnlineBoutique 앱을 Google Kubernetes Engine에 성공적으로 배포하고 비용 최적화에 권장되는 구성 변경사항을 적용했습니다. 또한 프런트엔드 및 recommendationservice 배포에 수평형 포드 자동 확장을 적용하여 트래픽 급증을 처리했습니다. 적절한 리소스 측정항목에 자동 확장을 적용하여 다른 서비스도 최적화했습니다.

다음 기술 배지 획득

이 사용자 주도형 실습은 Optimize Costs for Google Kubernetes Engine 기술 배지 과정의 일부입니다. 이 기술 배지 과정을 완료하면 위의 배지를 획득하여 수료를 인증할 수 있습니다. 이력서 및 소셜 미디어 플랫폼에 배지를 공유하고 #GoogleCloudBadge 해시태그를 사용해 스스로 달성한 업적을 널리 알리세요.

Google Cloud 교육 및 자격증

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

설명서 최종 업데이트: 2024년 3월 22일

실습 최종 테스트: 2023년 7월 27일

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