GKE でフルスタックワークロードを大規模に実行する

このチュートリアルでは、高可用性のリレーショナルデータベースを基盤とするウェブアプリケーションを Google Kubernetes Engine（GKE）で大規模に実行する方法について説明します。

このチュートリアルで使用するサンプルアプリケーションは、Bank of Anthos です。これは、銀行の決済処理ネットワークをシミュレートする HTTP ベースのウェブアプリケーションです。Bank of Anthos は、複数のサービスを使用して機能します。このチュートリアルでは、ウェブサイトのフロントエンドと、Bank of Anthos サービスを支えるリレーショナル PostgreSQL データベースに焦点を当てます。アーキテクチャやデプロイするサービスなど Bank of Anthos の詳細については、GitHub の Bank of Anthos をご覧ください。

目標

GKE クラスタを作成して構成する。
サンプルウェブアプリケーションと高可用性 PostgreSQL データベースをデプロイする。
ウェブアプリケーションとデータベースの自動スケーリングを構成する。
負荷生成ツールを使用してトラフィックの急増をシミュレートする。
サービスのスケールアップとスケールダウンを確認する。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

Google Cloud プロジェクトを作成または選択します。

Google Cloud プロジェクトを作成します。
```
gcloud projects create PROJECT_ID
```
PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。
作成した Google Cloud プロジェクトを選択します。
```
gcloud config set project PROJECT_ID
```
PROJECT_ID は、実際の Google Cloud プロジェクト名に置き換えます。

Google Cloud プロジェクトで課金が有効になっていることを確認します。

GKE API を有効にします。

gcloud services enable container.googleapis.com

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

Google Cloud プロジェクトを作成または選択します。

Google Cloud プロジェクトを作成します。
```
gcloud projects create PROJECT_ID
```
PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。
作成した Google Cloud プロジェクトを選択します。
```
gcloud config set project PROJECT_ID
```
PROJECT_ID は、実際の Google Cloud プロジェクト名に置き換えます。

Google Cloud プロジェクトで課金が有効になっていることを確認します。

GKE API を有効にします。

gcloud services enable container.googleapis.com

Helm CLI をインストールします。

環境を準備する

このチュートリアルで使用するサンプルリポジトリのクローンを作成します。
```
git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
cd bank-of-anthos/
```

環境変数を設定します。

PROJECT_ID=PROJECT_ID
GSA_NAME=bank-of-anthos
GSA_EMAIL=bank-of-anthos@${PROJECT_ID}.iam.gserviceaccount.com
KSA_NAME=default

PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

クラスタとサービスアカウントを設定する

クラスタを作成します。
```
gcloud container clusters create-auto bank-of-anthos --region=us-central1
```
クラスタの起動には最大 5 分かかることがあります。
IAM サービスアカウントを作成します。
```
gcloud iam service-accounts create bank-of-anthos
```

IAM サービスアカウントへのアクセス権を付与します。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/cloudtrace.agent \
  --member "serviceAccount:bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/monitoring.metricWriter \
  --member "serviceAccount:bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com"
gcloud iam service-accounts add-iam-policy-binding "bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"

このステップでは、次のアクセス権を付与します。

roles/cloudtrace.agent: レイテンシ情報などのトレースデータを Trace に書き込みます。
roles/monitoring.metricWriter: Cloud Monitoring に指標を書き込みます。
roles/iam.workloadIdentityUser: Kubernetes サービスアカウントが GKE 用 Workload Identity 連携を使用して IAM サービスアカウントとして機能することを許可します。

作成した IAM サービスアカウントとして機能するように、default Namespace で default Kubernetes サービスアカウントを構成します。
```
kubectl annotate serviceaccount default \
    iam.gke.io/gcp-service-account=bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com
```
これにより、default Namespace で default Kubernetes サービスアカウントを使用する Pod が、IAM サービスアカウントと同じ Google Cloud リソースにアクセスできるようになります。

Bank of Anthos と PostgreSQL のデプロイ

このセクションでは、Bank of Anthos と PostgreSQL データベースを高可用性（HA）モードでインストールします。これにより、データベースサーバーのレプリカを自動スケーリングできます。このセクションで使用しているスクリプト、Helm チャート、Kubernetes マニフェストを表示する場合は、GitHub の Bank of Anthos リポジトリをご覧ください。

データベーススキーマとデータ定義言語（DDL）スクリプトをデプロイします。

kubectl create configmap initdb \
    --from-file=src/accounts/accounts-db/initdb/0-accounts-schema.sql \
    --from-file=src/accounts/accounts-db/initdb/1-load-testdata.sql \
    --from-file=src/ledger/ledger-db/initdb/0_init_tables.sql \
    --from-file=src/ledger/ledger-db/initdb/1_create_transactions.sh

サンプル Helm チャートを使用して PostgreSQL をインストールします。
```
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install accounts-db bitnami/postgresql-ha \
    --version 10.0.1 \
    --values extras/postgres-hpa/helm-postgres-ha/values.yaml \
    --set="postgresql.initdbScriptsCM=initdb" \
    --set="postgresql.replicaCount=1" \
    --wait
```
このコマンドは、開始レプリカ数が 1 の PostgreSQL クラスタを作成します。このチュートリアルの後の部分では、受信接続に基づいてクラスタをスケーリングします。このオペレーションが完了するまで 10 分以上かかることがあります。
Bank of Anthos をデプロイします。
```
kubectl apply -f extras/jwt/jwt-secret.yaml
kubectl apply -f extras/postgres-hpa/kubernetes-manifests
```
このオペレーションが完了するまで数分かかることがあります。

チェックポイント: 設定を検証する

Bank of Anthos のすべての Pod が実行されていることを確認します。

kubectl get pods

出力は次のようになります。

NAME                                  READY   STATUS
accounts-db-pgpool-57ffc9d685-c7xs8   3/3     Running
accounts-db-postgresql-0              1/1     Running
balancereader-57b59769f8-xvp5k        1/1     Running
contacts-54f59bb669-mgsqc             1/1     Running
frontend-6f7fdc5b65-h48rs             1/1     Running
ledgerwriter-cd74db4cd-jdqql          1/1     Running
pgpool-operator-5f678457cd-cwbhs      1/1     Running
transactionhistory-5b9b56b5c6-sz9qz   1/1     Running
userservice-f45b46b49-fj7vm           1/1     Running

ウェブサイトのフロントエンドにアクセスできることを確認します。
1. frontend サービスの外部 IP アドレスを探します。
```
kubectl get ingress frontend
```
  出力は次のようになります。
```
NAME       CLASS    HOSTS   ADDRESS         PORTS   AGE
frontend   <none>   *       203.0.113.9     80      12m
```
2. ブラウザで外部 IP アドレスに移動します。Bank of Anthos のログインページが表示されます。関心をお持ちの場合はアプリケーションをご覧ください。
  
  404 エラーが発生した場合は、マイクロサービスがプロビジョニングされるまで数分待ってから再試行してください。

ウェブアプリと PostgreSQL データベースの自動スケーリング

GKE Autopilot は、クラスタ内のワークロード数に基づいてクラスタのコンピューティングリソースを自動スケーリングします。リソース指標に基づいてクラスタ内の Pod 数を自動的にスケーリングするには、Kubernetes 水平 Pod 自動スケーリングを実装する必要があります。Kubernetes に組み込まれている CPU とメモリの指標を使用でき、Cloud Monitoring から取得した 1 秒あたりの HTTP リクエスト数や SELECT ステートメントの数などのカスタム指標を使用することもできます。

このセクションでは、次の操作を行います。

組み込み指標とカスタム指標の両方を使用して、Bank of Anthos マイクロサービスの水平 Pod 自動スケーリングを構成する。
Bank of Anthos アプリケーションへの読み込みをシミュレートして、自動スケーリングイベントをトリガーする。
クラスタ内の Pod とノードの数が、負荷に応じて自動的にスケールアップまたはスケールダウンされることを確認する。

カスタム指標の収集を設定する

Monitoring からカスタム指標を読み取るには、カスタム指標 - Stackdriver アダプタアダプタをクラスタにデプロイする必要があります。

アダプタをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml

GKE 用 Workload Identity 連携を使用して指標を取得するようにアダプタを構成します。

IAM サービスアカウントを構成します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer
gcloud iam service-accounts add-iam-policy-binding bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"

アダプタが使用する Kubernetes サービスアカウントにアノテーションを付けます。

kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics \
  iam.gke.io/gcp-service-account=bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com

アダプタ Deployment を再起動して変更を反映します。

kubectl rollout restart deployment custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics

データベースの自動スケーリングを構成する

このチュートリアルの前の部分で Bank of Anthos と PostgreSQL をデプロイしたときに、すべての受信 SQL ステートメントを処理する 1 つのプライマリ読み取り / 書き込みレプリカを持つデータベースを StatefulSet としてデプロイしました。このセクションでは、受信 SELECT ステートメントを処理する新しいスタンバイの読み取り専用レプリカを追加するように、水平 Pod 自動スケーリングを構成します。各レプリカの負荷を軽減するには、SELECT ステートメント（読み取りオペレーション）を分散することをおすすめします。PostgreSQL Deployment には、このロードバランシングを実現してシステムのスループットを向上させる Pgpool-II という名前のツールが含まれています。

PostgreSQL は、SELECT ステートメントの指標を Prometheus 指標としてエクスポートします。prometheus-to-sd という名前の軽量の指標エクスポータを使用して、これらの指標をサポートされている形式で Cloud Monitoring に送信します。

HorizontalPodAutoscaler オブジェクトを確認します。

# Copyright 2022 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
#
#      http://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.

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: accounts-db-postgresql
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 5
      selectPolicy: Max
  scaleTargetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: accounts-db-postgresql
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: External
    external:
      metric:
        name: custom.googleapis.com|mypgpool|pgpool2_pool_backend_stats_select_cnt
      target:
          type: AverageValue
          averageValue: "15"

このマニフェストの内容は次のとおりです。

5 へのスケールアップ時のレプリカの最大数を設定します。
スケールダウン中の最小数を 1 に設定します。
外部指標を使用してスケーリングに関する決定を行います。このサンプルでは、指標は SELECT ステートメントの数です。スケールアップイベントは、受信した SELECT ステートメントの数が 15 を超えると発生します。

マニフェストをクラスタに適用します。

kubectl apply -f extras/postgres-hpa/hpa/postgresql-hpa.yaml

ウェブインターフェースの自動スケーリングを構成する

Bank of Anthos と PostgreSQL をデプロイするでは、Bank of Anthos ウェブインターフェースをデプロイしました。ユーザー数が増加すると、userservice Service はより多くの CPU リソースを消費します。このセクションでは、既存の Pod がリクエストされた CPU の 60% 超を使用している場合の userservice と、ロードバランサへの受信 HTTP リクエストが 1 秒あたり 5 件を超える場合の frontend Deployment に対して、水平 Pod 自動スケーリングを構成します。

userservice Deployment の自動スケーリングを構成する

userservice Deployment の HorizontalPodAutoscaler マニフェストを確認します。

# Copyright 2022 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
#
#      http://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.

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: userservice
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 5
      selectPolicy: Max
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: userservice
  minReplicas: 5
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

このマニフェストの内容は次のとおりです。

50 へのスケールアップ時のレプリカの最大数を設定します。
スケールダウン中の最小数を 5 に設定します。
組み込みの Kubernetes 指標を使用してスケーリングに関する決定を行います。このサンプルでは、指標は CPU 使用率であり、目標使用率は 60% です。これにより、過剰な使用率と過小な使用率の両方が回避されます。

マニフェストをクラスタに適用します。

kubectl apply -f extras/postgres-hpa/hpa/userservice.yaml

フロントエンドデプロイの自動スケーリングを構成する

userservice Deployment の HorizontalPodAutoscaler マニフェストを確認します。

# Copyright 2022 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
#
#      http://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.

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 5
      selectPolicy: Max
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  minReplicas: 5
  maxReplicas: 25
  metrics:
    - type: External
      external:
        metric:
          name: loadbalancing.googleapis.com|https|request_count
          selector:
            matchLabels:
              resource.labels.forwarding_rule_name: FORWARDING_RULE_NAME
        target:
          type: AverageValue
          averageValue: "5"

このマニフェストでは、次のフィールドを使用します。

spec.scaleTargetRef: スケーリングする Kubernetes リソース。
spec.minReplicas: レプリカの最小数。このサンプルでは 5 です。
spec.maxReplicas: レプリカの最大数。このサンプルでは 25 です。
spec.metrics.*: 使用する指標。このサンプルでは、1 秒あたりの HTTP リクエストの数です。これは、デプロイしたアダプタによって指定される Cloud Monitoring のカスタム指標です。
spec.metrics.external.metric.selector.matchLabels: 自動スケーリング時にフィルタリングする特定のリソースラベル。

ロードバランサから frontend Deployment への転送ルールの名前を確認します。

export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}')
echo $FW_RULE

出力は次のようになります。

k8s2-fr-j76hrtv4-default-frontend-wvvf7381

転送ルールをマニフェストに追加します。
```
sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
```
このコマンドは FORWARDING_RULE_NAME を保存した転送ルールに置き換えます。

マニフェストをクラスタに適用します。

kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml

チェックポイント: 自動スケーリングの設定を検証する

HorizontalPodAutoscaler リソースの状態を取得します。

kubectl get hpa

出力は次のようになります。

NAME                     REFERENCE                            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
accounts-db-postgresql   StatefulSet/accounts-db-postgresql   10905m/15 (avg)     1         5         2          5m2s
contacts                 Deployment/contacts                  1%/70%              1         5         1          11m
frontend                 Deployment/frontend                  <unknown>/5 (avg)   5         25        1          34s
userservice              Deployment/userservice               0%/60%              5         50        5          4m56s

これで、アプリケーションを設定して自動スケーリングを構成できました。フロントエンドとデータベースが、提供された指標に基づいてスケーリングできるようになります。

負荷をシミュレーションして GKE のスケーリングを確認する

Bank of Anthos には、負荷がかかった状態でアプリケーションのスケーリングをテストするトラフィックをシミュレートできる loadgenerator Service が含まれています。このセクションでは、loadgenerator Service をデプロイし、負荷を生成して、スケーリングを確認します。

負荷テスト生成ツールをデプロイする

Bank of Anthos ロードバランサの IP アドレスを使用して環境変数を作成します。
```
export LB_IP=$(kubectl get ingress frontend -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $LB_IP
```
出力は次のようになります。
```
203.0.113.9
```

ロードバランサの IP アドレスをマニフェストに追加します。

sed -i "s/FRONTEND_IP_ADDRESS/$LB_IP/g" "extras/postgres-hpa/loadgenerator.yaml"

マニフェストをクラスタに適用します。

kubectl apply -f  extras/postgres-hpa/loadgenerator.yaml

負荷生成ツールは、毎秒 1 人のユーザーの追加を開始し、最大 250 人のユーザーを追加します。

読み込みをシミュレートする

このセクションでは、負荷生成ツールを使用してトラフィックの急増をシミュレートし、時間の経過に伴う負荷の増加に対応するためにレプリカ数とノード数がスケールアップすることを確認します。次に、テストを終了し、レスポンスでレプリカとノードの数がスケールダウンすることを確認します。

負荷生成ツールのウェブインターフェースをローカルで公開します。
```
kubectl port-forward svc/loadgenerator 8080
```
エラーメッセージが表示された場合は、Pod の実行中にもう一度お試しください。
ブラウザで、負荷生成ツールのウェブインターフェースを開きます。
- ローカルシェルを使用している場合は、ブラウザを開いて http://127.0.0.1:8080 に移動します。
- Cloud Shell を使用している場合は、[ ウェブでプレビュー] をクリックし、[ポート 8080 でプレビュー] をクリックします。
[チャート] タブをクリックして、パフォーマンスの推移を確認します。

新しいターミナルウィンドウを開き、HorizontalPodAutoscaler のレプリカ数を確認します。

kubectl get hpa -w

レプリカの数は、負荷が増加すると増加します。スケールアップには約 10 分を要する場合があります。

NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
accounts-db-postgresql   StatefulSet/accounts-db-postgresql   8326m/15 (avg)   1         5         5
contacts                 Deployment/contacts                  51%/70%          1         5         2
frontend                 Deployment/frontend                  5200m/5 (avg)    5         25        13
userservice              Deployment/userservice               71%/60%          5         50        17

別のターミナルウィンドウを開き、クラスタ内のノード数を確認します。

gcloud container clusters list \
    --filter='name=bank-of-anthos' \
    --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
    --region="us-central1"

ノードの数は、新しいレプリカに対応するために、最初の 3 つのノードから増えました。
負荷生成ツールのインターフェースを開き、[停止] をクリックしてテストを終了します。
レプリカ数とノード数を再度チェックし、負荷が軽減されて数が減少するのを確認します。Kubernetes HorizontalPodAutoscaler リソースのレプリカの安定化に要する時間はデフォルトで 5 分であるため、スケールダウンには時間がかかることがあります。詳細については、安定化に要する時間をご覧ください。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

リソースを個別に削除する

Google Cloud は、作成した Kubernetes オブジェクトに基づいて、ロードバランサなどのリソースを作成します。このチュートリアルのすべてのリソースを削除する手順は次のとおりです。

サンプル Kubernetes リソースを削除します。

kubectl delete \
    -f extras/postgres-hpa/loadgenerator.yaml \
    -f extras/postgres-hpa/hpa \
    -f extras/postgres-hpa/kubernetes-manifests \
    -f extras/jwt/jwt-secret.yaml \
    -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml

PostgreSQL データベースを削除します。

helm uninstall accounts-db
kubectl delete pvc -l "app.kubernetes.io/instance=accounts-db"
kubectl delete configmaps initdb

GKE クラスタと IAM サービスアカウントを削除します。

gcloud iam service-accounts delete "bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com" --quiet
gcloud container clusters delete "bank-of-anthos" --region="us-central1" --quiet

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

次のステップ

垂直 Pod 自動スケーリングについて確認する。自動スケーリングを使用すると、長時間実行ワークロードのリソースリクエストを自動的に調整し、過去の使用状況に基づく推奨事項を取得できます。
水平 Pod 自動スケーリングの詳細を確認する。

GKE でフルスタック ワークロードを大規模に実行する

目標

費用

始める前に

環境を準備する

クラスタとサービス アカウントを設定する

Bank of Anthos と PostgreSQL のデプロイ

チェックポイント: 設定を検証する

ウェブアプリと PostgreSQL データベースの自動スケーリング

カスタム指標の収集を設定する

データベースの自動スケーリングを構成する

ウェブ インターフェースの自動スケーリングを構成する

userservice Deployment の自動スケーリングを構成する

フロントエンド デプロイの自動スケーリングを構成する

チェックポイント: 自動スケーリングの設定を検証する

負荷をシミュレーションして GKE のスケーリングを確認する

負荷テスト生成ツールをデプロイする

読み込みをシミュレートする

クリーンアップ

リソースを個別に削除する

プロジェクトを削除する

次のステップ

GKE でフルスタックワークロードを大規模に実行する

クラスタとサービスアカウントを設定する

ウェブインターフェースの自動スケーリングを構成する

フロントエンドデプロイの自動スケーリングを構成する