GSP343

はじめに

チャレンジラボでは、シナリオと一連のタスクが提供されます。手順ガイドに沿って進める形式ではなく、コース内のラボで習得したスキルを駆使して、ご自身でタスクを完了していただきます。タスクが適切に完了したかどうかは、このページに表示される自動スコアリング システムで確認できます。

チャレンジラボは、Google Cloud の新しいコンセプトについて学習するためのものではありません。デフォルト値を変更する、エラー メッセージを読み調査を行ってミスを修正するなど、習得したスキルを応用する能力が求められます。

100% のスコアを達成するには、制限時間内に全タスクを完了する必要があります。

このラボは、「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（vCPU 2 個、8 GB メモリ）のマシンサイズから始めます。
• Rapid の release-channel を使用するようにクラスタを設定します。

タスク 1. クラスタを作成してアプリをデプロイする

1. アプリケーションをデプロイするには、 ゾーンでクラスタを作成し、 という名前を付けます。

2. 小規模なクラスタから開始し、ノードが 2 つのみのゾーンクラスタを作成します。

3. ショップをデプロイする前に、dev と prod の 2 つの環境に合わせて、クラスタ上のリソースを分離するための名前空間を設定します。

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 名前空間に正常にデプロイしたら、ノードの詳細を確認します。

あなたは、クラスタのノードプールに変更を加える必要があるという結論に達しました。

• 現在の Deployment では RAM に十分な空きがあるため、より RAM の少ないマシンを使用したノードプールに切り替えることができそうです。
• 将来的にレプリカ数を増やす可能性のある Deployment のほとんどにおいて、追加の Pod 1 つにつき必要な CPU はわずか 100 mcpu です。より小さなマシンを使用するようにノードプールを構成すると、合計 CPU が少ないノードプールを使用できる可能性があります。ただし、スケーリングが必要な Deployment の数と、スケーリングの程度も考慮する必要があります。

2. custom-2-3584 をマシンタイプとして使用し、 という名前の新しいノードプールを作成します。

3. ノード数を「2」に設定します。

4. 新しいノードプールの設定が完了したら、default-pool を閉鎖してドレインすることによって、アプリケーションの Deployment を新しいノードプールに移行します。

5. Deployment が正常に移行されたら、default-pool を削除します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 最適化されたノードプールに移行する

タスク 3. フロントエンドの更新を適用する

すべてのデプロイが完了しましたが、開発チームから、土壇場での更新を今回のリリース前に push してもらえないかと依頼されました。問題ありません。ダウンタイムを発生させることなく実行できます。

1. フロントエンド Deployment に Pod Disruption Budget を設定します。

2. onlineboutique-frontend-pdb という名前を付けます。

3. Deployment の min-availabilit を「1」に設定します。

これで、チームの更新を適用できます。ホームページのバナー用ファイルが変更になったため、更新版の Docker イメージが提供されました。

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

4. フロントエンド Deployment を編集し、イメージを更新版に変更します。

5. Deployment の編集時に、ImagePullPolicy を Always に変更します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 フロントエンドの更新を適用する

タスク 4. 推定トラフィックをもとに自動スケーリングを行う

OnlineBoutique ショップのトラフィック急増につながりそうなマーケティング キャンペーンが予定されています。通常、予測されるトラフィックの急増に対応するために、事前に追加のリソースをスピンアップします。しかし、トラフィックが想定よりも大きく増えた場合は、夜中に起こされて、負荷を処理するためにさらに多くのリソースをスピンアップすることになるかもしれません。

また、追加リソースを必要以上に長く実行することは避けたいと考えています。コストを削減し、心配の種を減らすために、負荷が急増し始めたときに自動的にスケールするように Kubernetes Deployment を構成できます。

1. トラフィックの急増に対応するため、水平 Pod 自動スケーリングをフロントエンド Deployment に適用します。

2. CPU 使用率 50% をターゲットとしてスケーリングします。

3. Pod のスケーリングを最小 1 から最大 の間に設定します。

Deployment のスケーリング中にダウンタイムが発生するのを防ぐ必要もあります。

4. スケーリング中にダウンタイムが発生しないようにするには、ターゲット CPU 使用率を 50% として Deployment のスケーリングを設定します。これにより、自動スケーリング中に負荷を処理するための十分な余裕が確保されます。

5. Deployment のスケーリングを最小 1 Pod から最大 の間に設定します。

しかし、トラフィックの急増が現在プロビジョニング済みのコンピューティング リソースを超えた場合はどうなるでしょうか。コンピューティング ノードを追加する必要が生じます。

6. そこで次に、必要に応じて自動的にクラスタが追加のコンピューティング ノードをスピンアップできるようにします。ただし、自動スケーリングで処理できるのは、スケールアップだけではありません。

7. 先を見越して、ノードの最小数とノードの最大数の両方を構成します。こうすると、クラスタはトラフィックが多いときにノードを追加し、トラフィックが少ないときにノードの数を減らすことができます。

8. クラスタ オートスケーラーを、最小 1 ノードから最大 6 ノードの間でスケールするように更新します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 推定トラフィックをもとに自動スケーリングを行う

9. 最後に、負荷テストを行ってトラフィックの急増をシミュレートします。

幸いなことに、OnlineBoutique は負荷生成ツールが組み込まれた設計になっています。現在、dev インスタンスは同時接続ユーザーが 10 人程度のトラフィックをシミュレートしています。

10. このイベントで予想されるトラフィックをより適切に再現するには、次のコマンドを使用して、より多い同時接続ユーザーを指定して loadgenerator Pod から負荷生成ツールを実行します。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. 水平 Pod 自動スケーリングを recommendationservice の Deployment に適用します。CPU 使用率 50% をターゲットとしてスケーリングし、Pod のスケーリングを最小 1 から最大 5 の間に設定します。

注: 負荷テストの後にスケーリングを行い、新しいノードをプロビジョニングするプロセスには、全体で数分かかります。

タスク 5. （任意）その他のサービスを最適化する

フロントエンド サービスに水平 Pod 自動スケーリングを適用すると、負荷テスト中にもアプリケーションを利用できますが、他のワークロードをモニタリングすると、一部のワークロードでは特定のリソースに大きな負荷がかかっていることがわかります。

ラボの時間がまだ残っている場合は、他のワークロードをいくつか調べて、リソース指標が適切になるように自動スケーリングを適用して最適化してみてください。

ノード自動プロビジョニングを使用してリソースの使用率をさらに最適化できるか確認することもできます。

お疲れさまでした

これで完了です。このラボでは、OnlineBoutique アプリを Google Kubernetes Engine にデプロイし、コスト最適化のために推奨されているいくつかの構成変更を行いました。また、トラフィックの急増に対応するために、frontend と recommendationservice の 各 Deployment に水平 Pod 自動スケーリングを適用しました。さらに、他のサービスでもリソース指標が適切になるように自動スケーリングを適用して最適化を行いました。

次のスキルバッジを獲得する

このセルフペース ラボは、「Google Kubernetes Engine の費用の最適化」スキルバッジ コースの一部です。このコースを完了すると成果が認められて上のようなバッジが贈られます。獲得したバッジを履歴書やソーシャル プラットフォームに掲載し、#GoogleCloudBadge を使用して成果を公表しましょう。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2024 年 4 月 29 日

ラボの最終テスト日: 2024 年 4 月 29 日

Copyright 2025 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。