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（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 つにつき、100 mcpu しか必要としません。より小さなマシンを使用するようにノードプールを構成すると、合計 CPU が少ないノードプールを使用できる可能性があります。ただし、スケーリングが必要な Deployment の数と、スケーリングの程度も考慮する必要があります。

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

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

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

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

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

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

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

1. フロントエンド Deployment に Pod 停止予算を設定します。

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

3. Deployment の最小可用性を「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 から最大 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 自動スケーリングを適用すると、負荷テスト中にアプリケーションを利用できるようになりますが、他のワークロードを監視すると、特定のリソースに対して一部のワークロードが大幅に push されていることがわかります。

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

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

お疲れさまでした

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

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

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

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

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

マニュアルの最終更新日: 2024 年 3 月 22 日

ラボの最終テスト日: 2023 年 7 月 27 日

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