ジャンプスタートソリューション: Java を使用した動的ウェブアプリケーション

Last reviewed 2023-08-21 UTC

このガイドは、Java を使用した動的ウェブアプリケーションのジャンプスタートソリューションの理解、デプロイ、使用に役立ちます。このソリューションでは、POS という動的ウェブアプリをデプロイします。POS は、小売店の実際の POS 画面を模倣した、Java で記述されたウェブアプリです。ウェブアプリをデプロイしたら、POS 画面でユーザーエクスペリエンスをテストできます。

Kubernetes の Google マネージド実装である Google Kubernetes Engine（GKE）を使用して、Google Cloud に POS ウェブアプリをデプロイします。GKE では、インフラストラクチャの運用管理の粒度を選択できます。

このソリューションでは、アプリケーションソフトウェアの設計を開始するための大まかな要件を示します。このガイドを終えると、費用、パフォーマンス、スケーラビリティが同程度のデプロイに必要な Google Cloud コンポーネントを選択できます。

このガイドでは、Java と基本的なクラウドのコンセプトを理解していることを前提としていますが、必ずしも Google Cloud について理解している必要はありません。また、Terraform の使用経験も役に立ちます。

目標

このソリューションガイドは、次のことを行うのに役立ちます。

以下の大まかなタスクを完了して、GKE を使用して一般公開されているウェブアプリケーションをデプロイします。
- クラスタのスケーリング、セキュリティ、インフラストラクチャのニーズに対応する GKE Autopilot クラスタを構成します。
- ウェブアプリケーションの受信トラフィックと送信トラフィックを有効にするように、Kubernetes Services で Google Cloud ロードバランサを構成します。
- Google Cloud が推奨するセキュリティプラクティスに従って、GKE Pod から Spanner に接続します。
- 安全にビルドと再デプロイを行います。
デプロイを確認します。
Cloud Trace を使用して問題を把握して管理します。

使用するプロダクト

このソリューションでは、次の Google Cloud プロダクトを使用します。

Google Kubernetes Engine: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを行えるマネージド環境。
Spanner: アプリケーションのスケーリングと高可用性の確保を可能にするフルマネージドのリレーショナルデータベース。
Virtual Private Cloud: すべての Google Cloud リージョンにまたがり、クラウドリソースを相互接続できるようにするグローバルな Virtual Private Cloud ネットワーク。

これらのプロダクトの構成と相互作用については、次のセクションをご覧ください。

アーキテクチャ

次の図は、このソリューションがデプロイする Google Cloud リソースのアーキテクチャを示しています。

アーキテクチャの図

コンポーネントと構成

このアーキテクチャは、次のコンポーネントで構成されます。

クライアントリクエストは Cloud Load Balancing に送信され、受信トラフィックが Virtual Private Cloud（VPC）に分散されます。
Google Cloud は VPC インスタンスに外部 IP アドレスを割り当てます。
VPC は、GKE Autopilot クラスタのリソースへの接続を提供します。クラスタには LoadBalancer タイプの Kubernetes Service があります。この Service は、3 つの Spring Boot Java サービス Pod を実行する Pod にリクエストをルーティングします。
Pod には次の特性があります。
1. api-server Pod は、Vue.js フロントエンドの静的コンテンツをホストし、フロントエンドの API を公開します。これらの API を呼び出すと、必要に応じて在庫サービスと支払いサービスへの接続がトリガーされます。
2. inventory サービス Pod は Spanner に接続して、在庫情報の保存と取得を行います。
3. payment サービス Pod は Spanner に接続して支払いの詳細を保存し、購入請求書を生成します。
Spanner インスタンスは、在庫データと支払いデータをホストします。

費用

Java を使用した動的ウェブアプリケーションソリューションで使用される Google Cloud リソースの費用を見積もるには、Google Cloud 料金計算ツールで事前に計算された見積もりをご覧ください。

見積もりを出発点として使用して、デプロイの費用を計算します。見積もりを変更して、ソリューションで使用するリソースに対して行う予定の構成の変更を反映できます。

事前に計算された見積もりは、次のような特定の要因に関する前提条件に基づいています。

リソースがデプロイされている Google Cloud のロケーション。
リソースが使用される時間。

始める前に

このソリューションをデプロイするには、まず Google Cloud プロジェクトと IAM 権限が必要です。

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

ソリューションをデプロイするときに、リソースがデプロイされている Google Cloud プロジェクトを選択します。デプロイには、新しいプロジェクトを作成するか、既存のプロジェクトを使用できます。

新しいプロジェクトを作成する場合は、デプロイを始める前に作成します。新しいプロジェクトを使用すると、本番環境ワークロードに使用されるリソースなど、以前にプロビジョニングされたリソースとの競合を回避できます。

プロジェクトを作成するには、次の手順を完了します。

In the Google Cloud console, go to the project selector page.

Go to project selector
Click Create project.
Name your project. Make a note of your generated project ID.
Edit the other fields as needed.
Click Create.

必要な IAM 権限を取得する

デプロイプロセスを開始するには、次の表に示す Identity and Access Management（IAM）権限が必要です。

このソリューション用に新規プロジェクトを作成した場合は、そのプロジェクトに roles/owner 基本ロールが付与され、必要なすべての権限を持っています。roles/owner ロールがない場合は、これらの権限（またはこれらの権限を含むロール）の付与を管理者に依頼してください。

必要な IAM 権限	必要な権限を含む事前定義ロール
`serviceusage.services.enable`	Service Usage 管理者（`roles/serviceusage.serviceUsageAdmin`）
`iam.serviceAccounts.create`	サービスアカウント管理者（`roles/iam.serviceAccountAdmin`）
`resourcemanager.projects.setIamPolicy`	プロジェクト IAM 管理者（`roles/resourcemanager.projectIamAdmin`）
`config.deployments.create` `config.deployments.list`	Cloud Infrastructure Manager 管理者（`roles/config.admin`）
`iam.serviceAccount.actAs`	サービスアカウントユーザー（`roles/iam.serviceAccountUser`）

一時的なサービスアカウントの権限について

コンソールからデプロイプロセスを開始すると、ユーザーに代わってソリューションをデプロイするために（また、必要に応じて後でデプロイを削除するために）サービスアカウントが作成されます。このサービスアカウントには、特定の IAM 権限が一時的に割り当てられます。つまり、ソリューションのデプロイと削除のオペレーションが完了すると、権限が自動的に取り消されます。ソリューションのデプロイを削除した後に、このガイドの後半で説明するように、サービスアカウントを削除することをおすすめします。

サービスアカウントに割り当てられているロールを表示する

Google Cloud プロジェクトまたは組織の管理者が必要とする場合に、以下のロールの情報を表示してください。

Compute Engine ネットワーク管理者（roles/compute.networkAdmin）
Kubernetes Engine 管理者（roles/container.admin）
GKE Hub 編集者（roles/gkehub.editor）
サービスアカウント管理者（roles/iam.serviceAccountAdmin）
サービスアカウントユーザー（roles/iam.serviceAccountUser）
プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）
Spanner 管理者（roles/storage.admin）
Service Usage 管理者（roles/serviceusage.serviceUsageAdmin）

ソリューションをデプロイする

このソリューションを最小限の労力でデプロイできるように、Terraform 構成が GitHub で提供されています。Terraform 構成では、ソリューションに必要なすべての Google Cloud のリソースを定義しています。

次のいずれかの方法でソリューションをデプロイできます。

コンソールから: デフォルトの構成でソリューションを試して動作を確認する場合は、この方法を使用します。Cloud Build は、ソリューションに必要なすべてのリソースをデプロイします。デプロイされたソリューションが不要になった場合は、コンソールから削除できます。ソリューションのデプロイ後に作成したリソースは、個別に削除する必要があります。

このデプロイ方法を使用する場合、コンソールからデプロイするの手順に沿って操作します。
Terraform CLI を使用: このソリューションをカスタマイズする場合、または Infrastructure as Code（IaC）のアプローチを使用してリソースのプロビジョニングと管理を自動化する場合は、この方法を使用します。GitHub から Terraform 構成をダウンロードし、必要に応じてコードをカスタマイズしてから、Terraform CLI を使用してソリューションをデプロイします。ソリューションをデプロイした後も、引き続き Terraform を使用してソリューションを管理できます。

このデプロイ方法を使用するには、Terraform CLI を使用してデプロイするの手順に沿って操作します。

コンソールからデプロイする

事前構成済みのソリューションをデプロイするには、次の手順を完了します。

Google Cloud ジャンプスタートソリューションカタログで、Java を使用した動的ウェブアプリケーション ソリューションに移動します。

Java を使用した動的ウェブアプリケーションソリューションに移動する
ソリューションの概算費用やデプロイの推定時間など、ページに表示された情報を確認します。
ソリューションのデプロイを開始する準備ができたら、[デプロイ] をクリックします。

順を追って構成するペインが表示されます。
構成ペインの手順を実施します。

デプロイメントに入力する名前をメモします。この名前は、後でデプロイメントを削除するときに必要になります。

[デプロイ] をクリックすると、[ソリューションのデプロイ] ページが表示されます。このページの [ステータス] フィールドに「デプロイ中」が表示されます。
ソリューションがデプロイされるまで待ちます。

デプロイが失敗した場合、[ステータス] フィールドに「失敗」と表示されます。Cloud Build のログでエラーを診断できます。詳細については、コンソールからデプロイする際のエラーをご覧ください。

デプロイが完了すると、[ステータス] フィールドが「デプロイ済み」に変わります。
デプロイした POS ウェブアプリを表示して使用するには、Java を使用してデプロイした動的ウェブアプリケーションを確認するの手順に沿って操作します。
デプロイされた Google Cloud リソースとその構成を確認するには、インタラクティブなツアーをご覧ください。

ツアーを開始

このソリューションが不要になった場合は、デプロイを削除して、Google Cloud リソースに対する課金が継続しないようにします。詳細については、デプロイを削除するをご覧ください。

Terraform CLI を使用してデプロイする

このセクションでは、Terraform CLI を使用してソリューションをカスタマイズする方法や、ソリューションのプロビジョニングと管理を自動化する方法について説明します。Terraform CLI を使用してデプロイするソリューションは、Google Cloud コンソールの [ソリューションのデプロイ] ページに表示されません。

Terraform クライアントを設定する

Terraform は、Cloud Shell またはローカルホストで実行できます。このガイドでは、Terraform がプリインストールされ、Google Cloud での認証が構成されている Cloud Shell で Terraform を実行する方法について説明します。

このソリューションの Terraform コードは、GitHub リポジトリで入手できます。

Cloud Shell に GitHub リポジトリのクローンを作成します。

GitHub リポジトリを Cloud Shell にダウンロードするよう求めるメッセージが表示されます。
[確認] をクリックします。

別のブラウザタブで Cloud Shell が起動し、Cloud Shell 環境の $HOME/cloudshell_open ディレクトリに Terraform コードがダウンロードされます。
Cloud Shell で、現在の作業ディレクトリが $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra かどうかを確認します。このディレクトリには、ソリューションの Terraform 構成ファイルが含まれています。このディレクトリに移動する必要がある場合は、次のコマンドを実行します。
```
cd $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra
```
次のコマンドを実行して Terraform を初期化します。
```
terraform init
```
次のメッセージが表示されるまで待ちます。
```
Terraform has been successfully initialized!
```

Terraform 変数を構成する

ダウンロードした Terraform コードには、要件に基づいてデプロイメントをカスタマイズするために使用できる変数が含まれています。たとえば、Google Cloud プロジェクトと、ソリューションをデプロイするリージョンを指定できます。

現在の作業ディレクトリが $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。
同じディレクトリに、terraform.tfvars という名前のテキストファイルを作成します。
terraform.tfvars ファイルで次のコードスニペットをコピーし、必要な変数の値を設定します。
- このコードスニペットにコメントとして記載されている手順を実施します。
- このコードスニペットには、値を設定する必要のある変数のみが含まれています。Terraform 構成には、デフォルト値を持つ他の変数が含まれています。すべての変数とデフォルト値を確認するには、$HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra ディレクトリにある variables.tf ファイルをご覧ください。
- terraform.tfvars ファイルで設定した各値が、variables.tf ファイルで宣言されている変数の型と一致していることを確認します。たとえば、variables.tf ファイル内の変数に定義されている型が bool の場合、その変数の値として true または false を terraform.tfvars 内で指定する必要があります。
```
# This is an example of the terraform.tfvars file.
# The values in this file must match the variable types declared in variables.tf.
# The values in this file override any defaults in variables.tf.

# ID of the project in which you want to deploy the solution
project_id = "PROJECT_ID"
```
必要な変数に割り当てできる値については、以下をご覧ください。
- PROJECT_ID: プロジェクトの識別

Terraform 構成を検証して確認する

現在の作業ディレクトリが $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。
Terraform 構成にエラーがないことを確認します。
```
terraform validate
```
コマンドからエラーが返された場合は、構成で必要な修正を行ってから、terraform validate コマンドを再度実行します。コマンドで次のメッセージが返されるまで、この手順を繰り返します。
```
Success! The configuration is valid.
```
構成で定義されているリソースを確認します。
```
terraform plan
```
前述のように変数定義ファイル（terraform.tfvars）を作成しなかった場合、Terraform でデフォルト値のない変数の値の入力を求められます。必要な値を入力します。

terraform plan コマンドの出力に、構成の適用時に Terraform がプロビジョニングするリソースのリストが表示されます。

変更を行う場合は、構成を編集してから、terraform validate コマンドと terraform plan コマンドを再度実行します。

リソースをプロビジョニングする

構成にこれ以上の変更が必要ない場合は、リソースをデプロイします。

現在の作業ディレクトリが $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。
Terraform 構成を適用します。
```
terraform apply
```
前述のように変数定義ファイル（terraform.tfvars）を作成しなかった場合、Terraform でデフォルト値のない変数の値の入力を求められます。必要な値を入力します。

作成されるリソースのリストが表示されます。
アクションの実行を求められたら、「yes」と入力します。

Terraform でデプロイの進行状況を示すメッセージが表示されます。

デプロイを完了できない場合、失敗の原因となったエラーが表示されます。エラーメッセージを確認し、構成を更新してエラーを修正します。次に、terraform apply コマンドを再実行します。Terraform のエラーのトラブルシューティングについては、Terraform CLI を使用してソリューションをデプロイする際のエラーをご覧ください。

すべてのリソースが作成されると、Terraform から次のメッセージが表示されます。
```
Apply complete!
```
デプロイした POS ウェブアプリを表示して使用するには、Java を使用してデプロイした動的ウェブアプリケーションを確認するの手順に沿って操作します。

デプロイが完了すると、出力は次のようになります。
```
pos_application_url = "http://34.27.130.180/"
```
pos_application_url は、アプリケーションフロントエンドの IP アドレスです。GKE は、アプリケーションをインターネットに公開するロードバランサのパブリックエンドポイントにこの IP アドレスを割り当てます。
デプロイされた Google Cloud リソースとその構成を確認するには、インタラクティブなツアーをご覧ください。

ツアーを開始

デプロイした動的ウェブアプリを確認する

これで、POS 動的ウェブアプリがデプロイされました。POS ウェブサイトにアクセスして、Google Cloud コンソールでソリューションの動作をご確認ください。アプリケーションのデプロイ後、指定したアドレスにサイトが表示されるまでに数分かかることがあります。

POS ウェブアプリとはどのようなものですか？

このジャンプスタートソリューションでは、POS という名前の動的ウェブアプリを使用して、Java 開発者が静的アセットと動的コンテンツでウェブアプリをビルド、デプロイ、管理する際に Google Cloud GKE インフラストラクチャがどのように役立つかについて説明します。POS は、小売店の実際の決済端末を模倣したウェブアプリです。

アプリケーションフロントエンドは、営業担当者が小売店で顧客の商品の決済を行うために使用します。この画面では、営業担当者は次の操作を行うことができます。

カートに商品を追加して、支払いに進みます。
カートをクリアするか、カートから商品を削除します。
お支払い領収書を確認します。ユーザーが支払いを行うと、ウェブアプリに請求書とともに取引の結果が表示されます。

POS UI

その他のエッジケースも扱われます。たとえば、ユーザーがカートに何も入っていない状態で支払いを行おうとすると、ウェブアプリはエラーメッセージを表示します。

デプロイされた Google Cloud リソースとその構成を確認するには、インタラクティブなツアーをご覧ください。

ツアーを開始

フロントエンドを確認する

デプロイした POS ウェブアプリフロントエンドを起動するには:

Google Cloud コンソールで [サービス] ページに移動します。

サービスに移動
api-server-lb 外部ロードバランサのエンドポイントの IP アドレスをクリックします。POS ウェブアプリのフロントエンドが新しいブラウザウィンドウで開きます。

これで、商品の追加、支払い、請求書の表示など、ユーザーに表示されるときと同じように POS ウェブアプリを操作できるようになりました。

ウェブアプリへの負荷を生成する

ウェブアプリでのトラフィックの通常の増加に GKE がどのように対応するかを調べるには、トレースされたリクエストをウェブアプリケーションに送信します。次の手順では、hey を使用して複数のリクエストを自動的に送信します。hey は Cloud Shell にプリインストールされています。

Cloud Shell で、現在の作業ディレクトリが $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。

ウェブアプリケーションにリクエストを 150 件送信します。

export LB_IP_ADDRESS=$(gcloud compute addresses list --filter=name:jss-pos-1 --format='value(address)')
hey -n 150 \
 -m POST \
 -H 'Content-Type: application/json' \
 -d '{"paidAmount":14.59865,"type":"CASH","items":[{"itemId":"19a89a67-3958-46cf-9776-c29983871c93","itemCount":1},{"itemId":"729d0dd6-950e-4098-8f70-e7144076e899","itemCount":1}]}' \
  http://$LB_IP_ADDRESS/api/pay

このスクリプトは、動的ウェブアプリのフロントエンドの IP アドレスを LB_IP_ADDRESS 変数に割り当てます。

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

Summary:
  Total:        8.7963 secs
  Slowest:      6.0000 secs
  Fastest:      0.7981 secs
  Average:      2.7593 secs
  Requests/sec: 17.0527

  Total data:   132600 bytes
  Size/request: 884 bytes

Response time histogram:
  0.798 [1]     |■
  1.318 [24]    |■■■■■■■■■■■■■■■■■■■■■■■
  1.838 [42]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  2.359 [26]    |■■■■■■■■■■■■■■■■■■■■■■■■■
  2.879 [7]     |■■■■■■■
  3.399 [0]     |
  3.919 [7]     |■■■■■■■
  4.439 [11]    |■■■■■■■■■■
  4.960 [6]     |■■■■■■
  5.480 [9]     |■■■■■■■■■
  6.000 [17]    |■■■■■■■■■■■■■■■■

Latency distribution:
  10% in 1.1932 secs
  25% in 1.5938 secs
  50% in 1.9906 secs
  75% in 4.3013 secs
  90% in 5.5936 secs
  95% in 5.8922 secs
  99% in 6.0000 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0016 secs, 0.7981 secs, 6.0000 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:    0.0004 secs, 0.0000 secs, 0.0036 secs
  resp wait:    2.7565 secs, 0.7980 secs, 5.9930 secs
  resp read:    0.0001 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200] 150 responses

Status code distribution フィールドには、150 件のレスポンスの確認が表示されます。これは、スクリプトが 150 件の支払いを正常に実行したことを意味します。

ソリューションのデプロイを削除する

ソリューションのデプロイメントが不要になった場合は、作成したリソースに対して課金されないようにするため、デプロイメントを削除します。

コンソールを使用して削除する

この手順は、ソリューションをコンソールからデプロイした場合に実施します。

Google Cloud コンソールで、[ソリューションのデプロイ] ページに移動します。

[ソリューションのデプロイ] に移動
削除するデプロイメントが含まれているプロジェクトを選択します。
削除するデプロイメントを見つけます。
デプロイメントの行で、（アクション）アイコンをクリックし、[削除] を選択します。

行にアクション アイコンが表示されない場合は、スクロールしてください。
デプロイメントの名前を入力し、[確認] をクリックします。

[ステータス] フィールドに「削除中」が表示されます。

削除に失敗した場合は、デプロイメントの削除時のエラーのトラブルシューティングガイダンスをご覧ください。

ソリューションに使用した Google Cloud プロジェクトが不要になった場合は、プロジェクトを削除できます。詳細については、省略可: プロジェクトを削除するをご覧ください。

Terraform CLI を使用して削除する

Terraform CLI を使用してソリューションをデプロイした場合は、次の手順に沿って操作します。

Cloud Shell で、現在の作業ディレクトリが $HOME/cloudshell_open/terraform-example-java-dynamic-point-of-sale/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。
Terraform によってプロビジョニングされたリソースを削除します。
```
terraform destroy
```
破棄されるリソースのリストが表示されます。
アクションの実行を求められたら、「yes」と入力します。

進行状況を示すメッセージが表示されます。すべてのリソースが削除されると、次のメッセージが表示されます。
```
Destroy complete!
```
削除に失敗した場合は、デプロイメントの削除時のエラーのトラブルシューティングガイダンスをご覧ください。

省略可: プロジェクトを削除する

ソリューションを新しい Google Cloud プロジェクトにデプロイした後、そのプロジェクトが不要になった場合は、次の手順で削除します。

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
プロンプトでプロジェクト ID を入力し、[シャットダウン] をクリックします。

プロジェクトを保持する場合は、次のセクションで説明するように、このソリューション用に作成されたサービスアカウントを削除します。

省略可: サービスアカウントを削除する

ソリューションに使用したプロジェクトを削除した場合は、このセクションをスキップしてください。

このガイドの前半で説明したように、ソリューションをデプロイしたときに、ユーザーに代わってサービスアカウントが作成されました。このサービスアカウントには特定の IAM 権限が一時的に割り当てられました。ソリューションのデプロイと削除オペレーションが完了した後、権限は自動的に取り消されましたが、サービスアカウントは削除されません。このサービスアカウントを削除することをおすすめします。

Google Cloud コンソールからソリューションをデプロイした場合は、[ソリューションのデプロイ] ページに移動します。（すでにページが表示されている場合は、ブラウザを更新します）。サービスアカウントが削除されるように、バックグラウンドでプロセスがトリガーされます。特に操作を行う必要はありません。
Terraform CLI を使用してソリューションをデプロイした場合は、次の手順を完了します。
1. Google Cloud コンソールで、[サービスアカウント] ページに移動します。
  
  [サービスアカウント] に移動
2. ソリューションに使用したプロジェクトを選択します。
3. 削除するサービスアカウントを選択します。
  
  ソリューション用に作成されたサービスアカウントのメール ID は、次の形式になります。
```
goog-sc-DEPLOYMENT_NAME-NNN@PROJECT_ID.iam.gserviceaccount.com
```
  メール ID には次の値が含まれます。
  - DEPLOYMENT_NAME: デプロイメントの名前。
  - NNN: 3 桁のランダムな数字。
  - PROJECT_ID: ソリューションをデプロイしたプロジェクトの ID。
4. [削除] をクリックします。

エラーのトラブルシューティングを行う

エラーを診断して解決するために実行できるアクションは、デプロイ方法とエラーの複雑さによって異なります。

コンソールからデプロイする際のエラー

コンソールを使用してデプロイが失敗した場合は、次の操作を行います。

[ソリューションのデプロイ] ページに移動します。

デプロイが失敗した場合、[ステータス] フィールドに「失敗」と表示されます。
エラーの原因となったエラーの詳細を表示するには:
1. デプロイメントの行で、（アクション）をクリックします。
  
  行にアクション アイコンが表示されない場合は、スクロールしてください。
2. [Cloud Build のログを表示する] を選択します。
Cloud Build のログを確認し、適切な措置を講じて失敗の原因となった問題を解決します。

Terraform CLI を使用してデプロイする際のエラー

Terraform を使用したデプロイが失敗した場合、terraform apply コマンドの出力には、問題を診断するために確認できるエラーメッセージが含まれます。

次のセクションの例では、Terraform の使用時に発生する可能性のあるデプロイエラーを示します。

「API が有効になっていない」エラー

プロジェクトを作成し、すぐに新しいプロジェクトでソリューションをデプロイすると、デプロイが失敗して次のようなエラーが発生することがあります。

Error: Error creating Network: googleapi: Error 403: Compute Engine API has not
been used in project PROJECT_ID before or it is disabled. Enable it by visiting
https://console.developers.google.com/apis/api/compute.googleapis.com/overview?project=PROJECT_ID
then retry. If you enabled this API recently, wait a few minutes for the action
to propagate to our systems and retry.

このエラーが発生した場合は、数分待ってから terraform apply コマンドを再度実行します。

「Cannot assign requested address」エラー

terraform apply コマンドを実行すると、cannot assign requested address エラーが発生し、次のようなメッセージが表示されることがあります。

Error: Error creating service account:
 Post "https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts:
 dial tcp [2001:db8:ffff:ffff::5f]:443:
 connect: cannot assign requested address

このエラーが発生した場合は、terraform apply コマンドを再度実行してください。

デプロイメント削除時のエラー

デプロイメントを削除しようとして失敗することもあります。

コンソールでソリューションをデプロイした後に、ソリューションによってプロビジョニングされたリソースを変更してからデプロイメントを削除しようとすると、削除が失敗することがあります。[ソリューションのデプロイ] ページの [ステータス] フィールドに「失敗」と表示され、Cloud Build のログにエラーの原因が表示されます。
Terraform CLI を使用してソリューションをデプロイした後に、Terraform 以外のインターフェース（コンソールなど）を使用してリソースを変更し、デプロイメントを削除しようとすると、削除が失敗することがあります。terraform destroy コマンドの出力にあるメッセージにエラーの原因が示されます。

エラーログとエラーの内容を確認し、エラーの原因となったリソースを特定して削除してから、もう一度デプロイメントを削除してみてください。

コンソールベースのデプロイメントが削除されず、Cloud Build ログを使用してエラーを診断できない場合は、Terraform CLI を使用してデプロイメントを削除できます。次のセクションをご覧ください。

Terraform CLI を使用してコンソールベースのデプロイメントを削除する

このセクションでは、コンソールからコンソールベースのデプロイメントを削除しようとしたときにエラーが発生した場合に、コンソールベースのデプロイメントを削除する方法について説明します。このアプローチでは、削除するデプロイメントの Terraform 構成をダウンロードし、Terraform CLI を使用してデプロイメントを削除します。

デプロイメントの Terraform コード、ログ、その他のデータが保存されているリージョンを特定します。このリージョンは、ソリューションのデプロイ時に選択したリージョンとは異なる場合があります。
1. Google Cloud コンソールで、[ソリューションのデプロイ] ページに移動します。
  
  [ソリューションのデプロイ] に移動
2. 削除するデプロイメントが含まれているプロジェクトを選択します。
3. デプロイメントのリストで、削除するデプロイメントの行を特定します。
4. 「行の内容をすべて表示する」をクリックします。
5. [場所] 列で、次の例でハイライトされているように、2 番目の場所をメモします。
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
プロジェクト ID、リージョン、削除するデプロイメントの名前の環境変数を作成します。
```
export REGION="REGION"
export PROJECT_ID="PROJECT_ID"
export DEPLOYMENT_NAME="DEPLOYMENT_NAME"
```
これらのコマンドで、次のように置き換えます。
- REGION: この手順でメモした場所。
- PROJECT_ID: ソリューションをデプロイしたプロジェクトの ID。
- DEPLOYMENT_NAME: 削除するデプロイメントの名前。

削除するデプロイメントの最新リビジョンの ID を取得します。

export REVISION_ID=$(curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://config.googleapis.com/v1alpha2/projects/${PROJECT_ID}/locations/${REGION}/deployments/${DEPLOYMENT_NAME}" \
    | jq .latestRevision -r)
    echo $REVISION_ID