このガイドでは、3 階層ウェブアプリのジャンプ スタート ソリューションの概要とそのデプロイ方法について説明します。このソリューションを使用すると、多層ウェブ アプリケーション スタックを Google Cloud にすばやくデプロイできます。
この 3 階層ウェブアプリ ソリューションは、Google Cloud にタスク トラッカー アプリをデプロイします。このアプリには、ウェブベースのフロントエンドと中間層の API レイヤがあります。フロントエンドと API レイヤは、サーバーレス サービスとしてデプロイされるコンテナ化されたアプリです。バックエンドには SQL データベースがあります。このソリューションには、頻繁にアクセスされるデータを提供するインメモリ キャッシュもあります。このソリューションの各階層は独立しています。他の階層に影響することなく、どの階層も開発、更新、スケーリングができます。このアーキテクチャにより、アプリの開発と配信を効率的に実施できます。
このガイドは、多階層アプリスタックのデプロイ経験があるデベロッパーを対象としています。このドキュメントは、基本的なクラウドのコンセプトに精通していることを前提としていますが、必ずしも Google Cloud について理解している必要はありません。また、Terraform の使用経験も役に立ちます。
使用するプロダクト
このソリューションでは、次の Google Cloud プロダクトを使用します。
- Cloud Run: サーバーレスのコンテナ化アプリを構築してデプロイできるフルマネージド サービス。スケーリングなどのインフラストラクチャ タスクは Google Cloud で処理されるので、デベロッパーはコードのビジネス ロジックに集中できます。
- Memorystore for Redis: スケーラブルで優れた安全性と高可用性を備えたインメモリ サービスを使用して、Redis および Memcached 用のアプリケーション キャッシュを提供するサービス。
- Cloud SQL for PostgreSQL: Google Cloud インフラストラクチャ上でフルマネージドされる、クラウドベースの PostgreSQL データベース。
- Virtual Private Cloud（VPC）ネットワーク: すべての Google Cloud リージョンにまたがるグローバル仮想ネットワーク。クラウド リソースを相互に接続できます。
これらのプロダクトの構成と相互作用については、次のセクションをご覧ください。
アーキテクチャ
この 3 階層ウェブアプリ ソリューションがデプロイするサンプルアプリは、コードがすでに存在するタスク トラッキング アプリです。次の図は、このソリューションがデプロイするインフラストラクチャのアーキテクチャを示しています。
以降のサブセクションでは、図に示された Google Cloud リソースのリクエスト フローと構成について説明します。
リクエスト フロー
このソリューションがデプロイするタスク トラッカー アプリのリクエスト処理フローは次のとおりです。フローのステップには、上のアーキテクチャ図に対応した番号が付けられています。
- ウェブベースのフロントエンドは、クライアントからタスク トラッカー アプリへのリクエストを受信します。フロントエンドは Cloud Run サービスで、ユーザーのブラウザに HTML クライアントを表示します。
- フロントエンドは、同じく Cloud Run サービスとしてデプロイされている API レイヤにリクエストを送信します。
- 頻繁に読み取られるデータはキャッシュに保存され、Memorystore for Redis インスタンスから提供されます。
- インメモリの Redis キャッシュから提供できないリクエストは、API レイヤから Cloud SQL for PostgreSQL データベースに送信されます。
リソース構成
このセクションでは、ソリューションがデプロイする Cloud Run、Memorystore、Cloud SQL、ネットワーキング リソースの構成について説明します。Terraform 構成言語に精通している場合は、このガイドの後半で説明するように、これらの設定の一部を変更できます。
次のサブセクションをクリックして、構成の設定を表示してください。
Cloud Run サービス
| パラメータ | 事前構成済みの設定 |
|---|---|
| コンテナ インスタンスあたりのコンピューティング容量 | 1 個の vCPU、512 MiB のメモリ |
| 自動スケーリングの範囲（コンテナ インスタンスの数） | フロントエンド: 0～8 API レイヤ: 0～8 |
Memorystore for Redis インスタンス
| パラメータ | 事前構成済みの設定 |
|---|---|
| Redis のバージョン | バージョン 6.x |
| サービスティア | 基本、高可用性（HA）なし |
| メモリ | 1 GB |
| データ暗号化 | 保存時: Google が所有し管理する鍵 転送中: 暗号化されていません |
Cloud SQL for PostgreSQL データベース
| パラメータ | 事前構成済みの設定 |
|---|---|
| PostgreSQL のバージョン | バージョン 14 |
| マシンタイプ | db-g1-small: 1 個の vCPU、1.7-GB のメモリ |
| 可用性 | シングルゾーン |
| ストレージ | 10 GB の SSD、自動スケーリング有効 |
ネットワーキング リソース
Cloud SQL インスタンスは、お客様が作成した VPC ネットワークに接続します。このインスタンスには内部 IP アドレスが設定されています。
サーバーレス VPC アクセスは、API レイヤをホストする Cloud Run インスタンスから Cloud SQL インスタンスへの接続性を提供します。Cloud Run サービスから Cloud SQL インスタンスへのリクエストは、内部 DNS と内部 IP アドレスを使用します。レスポンス トラフィックも内部ネットワークを使用します。つまり、アプリとデータベース間のトラフィックはインターネットに公開されません。また、サーバーレス VPC アクセス経由のトラフィックは、インターネットを通過するトラフィックよりもレイテンシが短くなります。
Memorystore インスタンスと Cloud SQL データベース間の接続は、ダイレクト ピアリング接続を介して行われます。
費用
3 階層ウェブアプリ ソリューションで使用される Google Cloud リソースの費用については、Google Cloud 料金計算ツールで事前に計算された見積もりをご覧ください。
見積もりを出発点として使用して、デプロイの費用を計算します。見積もりを変更して、ソリューションで使用するリソースに対して行う予定の構成の変更を反映できます。
事前に計算された見積もりは、次のような特定の要因に関する前提条件に基づいています。
- リソースがデプロイされている Google Cloud のロケーション。
- リソースが使用される時間。
始める前に
このソリューションをデプロイするには、まず Google Cloud プロジェクトと IAM 権限が必要です。
Google Cloud プロジェクトを作成または選択する
ソリューションをデプロイするときに、リソースがデプロイされている Google Cloud プロジェクトを選択します。デプロイには、新しいプロジェクトを作成するか、既存のプロジェクトを使用できます。
新しいプロジェクトを作成する場合は、デプロイを始める前に作成します。新しいプロジェクトを使用すると、本番環境ワークロードに使用されるリソースなど、以前にプロビジョニングされたリソースとの競合を回避できます。
プロジェクトを作成するには、次の手順を完了します。
-
In the Google Cloud console, go to the project selector page.
-
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 権限 | 必要な権限を含む事前定義ロール |
|---|---|
|
Service Usage 管理者 （ roles/serviceusage.serviceUsageAdmin） |
|
サービス アカウント管理者 （ roles/iam.serviceAccountAdmin） |
|
プロジェクト IAM 管理者 （ roles/resourcemanager.projectIamAdmin） |
config.deployments.createconfig.deployments.list |
Cloud Infrastructure Manager 管理者 （ roles/config.admin） |
一時的なサービス アカウントの権限について
コンソールからデプロイ プロセスを開始すると、ユーザーに代わってソリューションをデプロイするために（また、必要に応じて後でデプロイを削除するために）サービス アカウントが作成されます。このサービス アカウントには、特定の IAM 権限が一時的に割り当てられます。つまり、ソリューションのデプロイと削除のオペレーションが完了すると、権限が自動的に取り消されます。ソリューションのデプロイを削除した後に、このガイドの後半で説明するように、サービス アカウントを削除することをおすすめします。
サービス アカウントに割り当てられたロールを確認する
Google Cloud プロジェクトまたは組織の管理者が必要とする場合に、以下のロールの情報を表示してください。
roles/artifactregistry.adminroles/cloudsql.adminroles/compute.networkAdminroles/iam.serviceAccountAdminroles/iam.serviceAccountUserroles/redis.adminroles/resourcemanager.projectIamAdminroles/run.adminroles/servicenetworking.serviceAgentroles/serviceusage.serviceUsageViewerroles/vpcaccess.admin
ソリューションをデプロイする
このソリューションを最小限の労力でデプロイできるように、Terraform 構成が GitHub で提供されています。Terraform 構成では、ソリューションに必要なすべての Google Cloud のリソースを定義しています。
次のいずれかの方法でソリューションをデプロイできます。
コンソールから: デフォルトの構成でソリューションを試して動作を確認する場合は、この方法を使用します。Cloud Build は、ソリューションに必要なすべてのリソースをデプロイします。デプロイされたソリューションが不要になった場合は、コンソールから削除できます。ソリューションのデプロイ後に作成したリソースは、個別に削除する必要があります。
このデプロイ方法を使用する場合、コンソールからデプロイするの手順に沿って操作します。
Terraform CLI を使用: このソリューションをカスタマイズする場合、または Infrastructure as Code（IaC）のアプローチを使用してリソースのプロビジョニングと管理を自動化する場合は、この方法を使用します。GitHub から Terraform 構成をダウンロードし、必要に応じてコードをカスタマイズしてから、Terraform CLI を使用してソリューションをデプロイします。ソリューションをデプロイした後も、引き続き Terraform を使用してソリューションを管理できます。
このデプロイ方法を使用するには、Terraform CLI を使用してデプロイするの手順に沿って操作します。
コンソールからデプロイする
事前構成済みのソリューションをデプロイするには、次の手順を完了します。
Google Cloud ジャンプ スタート ソリューションのカタログで、3 階層ウェブアプリ ソリューションに移動します。
ソリューションの概算費用やデプロイの推定時間など、ページに表示された情報を確認します。
ソリューションのデプロイを開始する準備ができたら、[デプロイ] をクリックします。
順を追って構成するペインが表示されます。
構成ペインで手順を完了します。
デプロイメントに入力する名前をメモします。この名前は、後でデプロイメントを削除するときに必要になります。
[デプロイ] をクリックすると、[ソリューションのデプロイ] ページが表示されます。このページの [ステータス] フィールドに「デプロイ中」が表示されます。
ソリューションがデプロイされるまで待ちます。
デプロイが失敗した場合、[ステータス] フィールドに「失敗」と表示されます。Cloud Build のログでエラーを診断できます。詳細については、コンソールからデプロイする際のエラーをご覧ください。
デプロイが完了すると、[ステータス] フィールドが「デプロイ済み」に変わります。
このソリューションでデプロイされるタスク トラッカー アプリを表示して使用するには、[ソリューションのデプロイ] ページの [アクション] メニューをクリックしてから、[ウェブアプリを表示] を選択します。
タスク トラッカー アプリのフロントエンド ウェブページが新しいブラウザタブに表示されます。
デプロイされた 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-google-three-tier-web-app/かどうかを確認します。このディレクトリには、ソリューションの Terraform 構成ファイルが含まれています。このディレクトリに移動する必要がある場合は、次のコマンドを実行します。cd $HOME/cloudshell_open/terraform-google-three-tier-web-app/次のコマンドを実行して Terraform を初期化します。
terraform init次のメッセージが表示されるまで待ちます。
Terraform has been successfully initialized!
Terraform 変数を構成する
ダウンロードした Terraform コードには、要件に基づいてデプロイメントをカスタマイズするために使用できる変数が含まれています。たとえば、Google Cloud プロジェクトと、ソリューションをデプロイするリージョンを指定できます。
現在の作業ディレクトリが
$HOME/cloudshell_open/terraform-google-three-tier-web-app/であることを確認します。そうでない場合は、そのディレクトリに移動します。同じディレクトリに、
terraform.tfvarsという名前のテキスト ファイルを作成します。terraform.tfvarsファイルで次のコード スニペットをコピーし、必要な変数の値を設定します。- このコード スニペットにコメントとして記載されている手順を実施します。
- このコード スニペットには、値を設定する必要のある変数のみが含まれています。Terraform 構成には、デフォルト値を持つ他の変数が含まれています。すべての変数とデフォルト値を確認するには、
$HOME/cloudshell_open/terraform-google-three-tier-web-app/ディレクトリにある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" # Google Cloud region where you want to deploy the solution # Example: us-central1 region = "REGION" # Google Cloud zone where you want to deploy the solution # Example: us-central1-a zone = "ZONE"必要な変数に割り当てできる値については、以下をご覧ください。
project_id: プロジェクトの識別region、zone: 使用可能なリージョンとゾーン
Terraform 構成を検証して確認する
現在の作業ディレクトリが
$HOME/cloudshell_open/terraform-google-three-tier-web-app/であることを確認します。そうでない場合は、そのディレクトリに移動します。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-google-three-tier-web-app/であることを確認します。そうでない場合は、そのディレクトリに移動します。Terraform 構成を適用します。
terraform apply前述のように変数定義ファイル（
terraform.tfvars）を作成しなかった場合、Terraform でデフォルト値のない変数の値の入力を求められます。必要な値を入力します。作成されるリソースのリストが表示されます。
アクションの実行を求められたら、「
yes」と入力します。Terraform でデプロイの進行状況を示すメッセージが表示されます。
デプロイを完了できない場合、失敗の原因となったエラーが表示されます。エラー メッセージを確認し、構成を更新してエラーを修正します。次に、
terraform applyコマンドを再実行します。Terraform のエラーのトラブルシューティングについては、Terraform CLI を使用してソリューションをデプロイする際のエラーをご覧ください。すべてのリソースが作成されると、Terraform から次のメッセージが表示されます。
Apply complete!次の例に示すように、Terraform の出力には、タスク トラッカー アプリのフロントエンド URL（
endpoint）と Cloud SQL インスタンスの名前（sqlservername）も一覧表示されます。endpoint = "https://three-tier-app-fe-pn4ngg7gnq-uc.a.run.app" sqlservername = "three-tier-app-db-75c2"ソリューションでデプロイされたタスク トラッカー アプリを表示して使用するには、前の手順にある
endpointの URL をコピーして、ブラウザでその URL を開きます。タスク トラッカー アプリのフロントエンド ウェブページが新しいブラウザタブに表示されます。
デプロイされた Google Cloud リソースとその構成を確認するには、インタラクティブなツアーをご覧ください。
このソリューションが不要になった場合は、デプロイメントを削除して、Google Cloud リソースに対する課金が継続しないようにします。詳細については、デプロイメントを削除するをご覧ください。
ソリューションをカスタマイズする
このセクションでは、Terraform のデベロッパーが独自の技術的要件とビジネス要件を満たすために、3 階層ウェブアプリ ソリューションを変更する際に使用できる情報を提供します。このセクションのガイダンスは、Terraform CLI を使用してソリューションをデプロイする場合にのみ該当します。
リソース構成セクション（このガイドの前半）では、3 階層ウェブアプリ ソリューションがプロビジョニングする Google Cloud リソースの構成済みパラメータが説明されています。main.tf ファイルの一部のパラメータを変更することで、ソリューションをカスタマイズできます。
ソリューションをカスタマイズするには、Cloud Shell で次の手順を完了します。
現在の作業ディレクトリが
$HOME/cloudshell_open/terraform-google-three-tier-web-app/であることを確認します。そうでない場合は、そのディレクトリに移動します。main.tfファイルを開き、次の表の例のように必要な変更を行います。パラメータ Terraform コード Cloud Run のスケーリング main.tfファイルの引数:autoscaling.knative.dev/maxScaleコード スニペット
resource "google_cloud_run_service" "api" { ... template { ... metadata { annotations = { "autoscaling.knative.dev/maxScale" = "COUNT" ... } } } }Redis のバージョン main.tfファイルの引数:redis_versionコード スニペット
resource "google_redis_instance" "main" { ... redis_version = "VERSION" ... }注意: Google 提供の Terraform 構成は、Redis バージョン 6.x で検証されています。バージョンを変更すると、デプロイしたソリューションが意図したとおりに動作しないことがあります。
Redis 階層 main.tfファイルの引数:tierコード スニペット
resource "google_redis_instance" "main" { ... tier = "TIER" ... }Redis メモリ main.tfファイルの引数:memory_size_gbコード スニペット
resource "google_redis_instance" "main" { ... memory_size_gb = SIZE ... }PostgreSQL のバージョン main.tfファイルの引数:database_versionコード スニペット
resource "google_sql_database_instance" "main" { ... database_version = "VERSION" ... ... }注意: Google 提供の Terraform 構成は、PostgreSQL バージョン 14 で検証されています。バージョンを変更すると、デプロイしたソリューションが意図したとおりに動作しないことがあります。
データベース マシンタイプ main.tfファイルの引数:settings.tierコード スニペット
resource "google_sql_database_instance" "main" { ... settings { tier = "MACHINE_TYPE" ... } ... }データベース ストレージ main.tfファイルの引数:settings.disk_sizeコード スニペット
resource "google_sql_database_instance" "main" { ... settings { ... ... disk_size = SIZE ... } ... }
設計に関する推奨事項
このセクションでは、セキュリティ、信頼性、コスト、パフォーマンスの要件を満たすアーキテクチャを構築するために、3 階層ウェブアプリ ソリューションを使用する際の推奨事項について説明します。
各領域の設計に関する推奨事項を表示するには、該当するタブをクリックしてください。
セキュリティ
| 設計のフォーカス | 推奨事項 |
|---|---|
| データ暗号化 |
|
| ソフトウェア サプライ チェーンのセキュリティ | 承認済みのコンテナ イメージのみが Cloud Run サービスにデプロイされるようにするには、Binary Authorization を使用します。 |
| アクセス制御 |
|
信頼性
| 設計のフォーカス | 推奨事項 |
|---|---|
| アプリのスケーリング | ソリューションの Cloud Run サービスは、リクエストの負荷に基づいてコンテナ インスタンスを水平方向に自動スケーリングするように構成されています。自動スケーリングのパラメータを確認し、要件に基づいて調整します。詳細については、コンテナ インスタンスの自動スケーリングについてをご覧ください。 |
| リクエスト処理 | クライアント固有の状態をコンテナ インスタンスに保存する Cloud Run サービスの応答性を向上させるには、セッション アフィニティを使用します。同じクライアントからのリクエストは、ベスト エフォート ベースで同じコンテナ インスタンスにルーティングされます。詳細については、セッション アフィニティの設定（サービス）をご覧ください。 |
| データの耐久性 | データを損失から保護するために、Cloud SQL データベースの自動バックアップを使用できます。詳細については、Cloud SQL バックアップについてをご覧ください。 |
| データベースの高可用性（HA） | ソリューション内の Cloud SQL データベースは、単一のゾーンにデプロイされます。HA の場合は、マルチゾーン構成を使用できます。詳細については、高可用性についてをご覧ください。 データベース HA が重要な要件である場合は、代替の Google Cloud サービスとして AlloyDB for PostgreSQL を検討してください。 |
| データベースの信頼性 | このソリューションの Cloud SQL インスタンスは、共有コア CPU を搭載した
|
| キャッシュ HA | このソリューションのインメモリ キャッシュ レイヤの高可用性を確保するため、Memorystore for Redis のスタンダード ティアを使用できます。このサービスは、分散読み取りオペレーション用のリードレプリカを作成し、自動フェイルオーバーを提供します。詳細については、Redis の階層の機能をご覧ください。 |
費用
| 設計のフォーカス | 推奨事項 |
|---|---|
| 効率的なリソース | Cloud Run は、CPU 使用率とメモリ使用量に基づいて、コンテナ インスタンスに送信するリクエスト数を決定します。最大同時実行数の設定を増やすと、Cloud Run で作成する必要があるコンテナ インスタンスの数を減らし、費用を削減できます。詳細については、インスタンスあたりの最大同時リクエスト数（サービス）をご覧ください。 このソリューションの Cloud Run サービスは、リクエストの処理中にのみ CPU を割り当てるように構成されています。Cloud Run サービスがリクエストの処理を完了すると、コンテナ インスタンスの CPU へのアクセスは無効になります。この構成の費用とパフォーマンスへの影響については、CPU の割り当て（サービス）をご覧ください。 |
| リソースの使用量 |
アプリでリクエストをグローバルに処理する必要がある場合は、Cloud Run サービスを複数のリージョンにデプロイすることを検討してください。クロスリージョン デプロイにより、大陸間のデータ転送トラフィックの費用を削減できます。ロードバランサと CDN を使用する場合は、クロスリージョン デプロイをおすすめします。詳細については、複数のリージョンからのトラフィックを処理するをご覧ください。 Cloud Run サービスの費用を最適化するためのその他のベスト プラクティスについては、費用の最適化: コンピューティング、コンテナ、サーバーレスをご覧ください。 |
パフォーマンス
| 設計のフォーカス | 推奨事項 |
|---|---|
| アプリ起動時間 | コールド スタートのパフォーマンスへの影響を軽減するには、Cloud Run コンテナ インスタンスの最小数をゼロ以外の値に構成します。詳細については、Cloud Run の一般的な開発のヒントをご覧ください。 |
| フロントエンドのレスポンス時間 | アプリでリクエストをグローバルに処理する場合は、クライアント リクエストへのレスポンスが速くなるように、Cloud Run サービスを複数のリージョンにデプロイすることを検討してください。グローバル ロードバランサを使用して、最も近いリージョンにリクエストを転送できます。詳細については、複数のリージョンからのトラフィックを処理するをご覧ください。 マルチリージョン デプロイは、大陸間の下り（外向き）トラフィックの量を減らすことにもつながり、アプリの運用コストを削減できます。 |
| データベースのパフォーマンス | パフォーマンス重視のアプリケーションの場合、より大きなマシンタイプを使用してストレージ容量を増やすことで、Cloud SQL のパフォーマンスを改善できます。 データベースのパフォーマンスが重要な要件である場合は、代替の Google Cloud サービスとして AlloyDB for PostgreSQL を検討してください。 |
| キャッシュ パフォーマンス | アプリのユーザー パフォーマンスを向上させるために、Memorystore for Redis インスタンスの容量を増やすことができます。容量が大きいほど、ネットワーク スループットが高くなります。詳細については、メモリ管理のベスト プラクティスをご覧ください。 |
次の点にご注意ください。
- 設計を変更する前に、費用への影響を評価し、他の機能との潜在的なトレードオフを検討します。Google Cloud 料金計算ツールを使用すると、設計変更の費用への影響を評価できます。
- ソリューションの設計変更を実装するには、Terraform のコーディングに関する専門知識と、ソリューションで使用される Google Cloud サービスに関する高度な知識が必要です。
- Google 提供の Terraform 構成を変更してエラーが発生した場合は、GitHub で問題を作成します。GitHub の問題はベスト エフォート ベースで調査します。これは、一般的な使用に関する質問を目的としたものではありません。
- Google Cloud で本番環境レベルの環境を設計して設定する方法については、Google Cloud のランディング ゾーンの設計と Google Cloud 設定のチェックリストをご覧ください。
デプロイを削除する
ソリューションのデプロイメントが不要になった場合は、作成したリソースに対して課金されないようにするため、デプロイメントを削除します。
コンソールを使用して削除する
この手順は、ソリューションをコンソールからデプロイした場合に実施します。
Google Cloud コンソールで、[ソリューションのデプロイ] ページに移動します。
削除するデプロイメントが含まれているプロジェクトを選択します。
削除するデプロイメントを見つけます。
[アクション] をクリックして、[削除] を選択します。
デプロイメントの名前を入力し、[確認] をクリックします。
[ステータス] フィールドに「削除中」が表示されます。
削除に失敗した場合は、デプロイメントの削除時のエラーのトラブルシューティング ガイダンスをご覧ください。
ソリューションに使用した Google Cloud プロジェクトが不要になった場合は、プロジェクトを削除できます。詳細については、省略可: プロジェクトを削除するをご覧ください。
Terraform CLI を使用して削除する
Terraform CLI を使用してソリューションをデプロイした場合は、次の手順に沿って操作します。
Cloud Shell で、現在の作業ディレクトリが
$HOME/cloudshell_open/terraform-google-three-tier-web-app/であることを確認します。そうでない場合は、そのディレクトリに移動します。Terraform によってプロビジョニングされたリソースを削除します。
terraform destroy破棄されるリソースのリストが表示されます。
アクションの実行を求められたら、「
yes」と入力します。進行状況を示すメッセージが表示されます。すべてのリソースが削除されると、次のメッセージが表示されます。
Destroy complete!削除に失敗した場合は、デプロイメントの削除時のエラーのトラブルシューティング ガイダンスをご覧ください。
ソリューションに使用した Google Cloud プロジェクトが不要になった場合は、プロジェクトを削除できます。詳細については、省略可: プロジェクトを削除するをご覧ください。
省略可: プロジェクトを削除する
ソリューションを新しい Google Cloud プロジェクトにデプロイした後、そのプロジェクトが不要になった場合は、次の手順で削除します。
- Google Cloud コンソールで、[リソースの管理] ページに移動します。
- プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
- プロンプトでプロジェクト ID を入力し、[シャットダウン] をクリックします。
プロジェクトを保持する場合は、次のセクションで説明するように、このソリューション用に作成されたサービス アカウントを削除します。
省略可: サービス アカウントを削除する
ソリューションに使用したプロジェクトを削除した場合は、このセクションをスキップしてください。
このガイドの前半で説明したように、ソリューションをデプロイしたときに、ユーザーに代わってサービス アカウントが作成されました。このサービス アカウントには特定の IAM 権限が一時的に割り当てられました。ソリューションのデプロイと削除オペレーションが完了した後、権限は自動的に取り消されましたが、サービス アカウントは削除されません。このサービス アカウントを削除することをおすすめします。
Google Cloud コンソールからソリューションをデプロイした場合は、[ソリューションのデプロイ] ページに移動します。（すでにページが表示されている場合は、ブラウザを更新します）。サービス アカウントが削除されるように、バックグラウンドでプロセスがトリガーされます。特に操作を行う必要はありません。
Terraform CLI を使用してソリューションをデプロイした場合は、次の手順を完了します。
Google Cloud コンソールで、[サービス アカウント] ページに移動します。
ソリューションに使用したプロジェクトを選択します。
削除するサービス アカウントを選択します。
ソリューション用に作成されたサービス アカウントのメール ID は、次の形式になります。
goog-sc-DEPLOYMENT_NAME-NNN@PROJECT_ID.iam.gserviceaccount.comメール ID には次の値が含まれます。
- DEPLOYMENT_NAME: デプロイメントの名前。
- NNN: 3 桁のランダムな数字。
- PROJECT_ID: ソリューションをデプロイしたプロジェクトの ID。
[削除] をクリックします。
エラーのトラブルシューティングを行う
エラーを診断して解決するために実行できるアクションは、デプロイ方法とエラーの複雑さによって異なります。
コンソールからデプロイする際のエラー
コンソールを使用してデプロイが失敗した場合は、次の操作を行います。
[ソリューションのデプロイ] ページに移動します。
デプロイが失敗した場合、[ステータス] フィールドに「失敗」と表示されます。
エラーの原因となったエラーの詳細を表示するには:
[アクション] をクリックします。
[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 コマンドを再度実行してください。
構成エラー
サポートされていない値を含むリソース引数がある場合は、次のようなエラーが発生します。
Error: Error creating Instance: googleapi: Error 400: Provided Redis version is
not supported: REDIS_5_X
│ com.google.apps.framework.request.StatusException:
<eye3 title='INVALID_ARGUMENT'/>
generic::INVALID_ARGUMENT: Provided Redis version is not supported: REDIS_5_X
Details:
│ [
│ {
│ "@type": "type.googleapis.com/google.rpc.BadRequest",
│ "fieldViolations": [
│ {
│ "description": "Invalid value: REDIS_5_X",
│ "field": "instance.redis_version"
│ }
│ ]
│ }
│ ]
│
│ with google_redis_instance.main,
│ on main.tf line 96, in resource "google_redis_instance" "main":
│ 96: resource "google_redis_instance" "main" {
この例では、Redis バージョン 5 を使用するために指定した main.tf ファイルの instance.redis_version 引数の値（REDIS_5_X）が無効です。Memorystore REST API ドキュメントに記載されているように、正しい値は REDIS_5_0 です。
デプロイメント削除時のエラー
デプロイメントを削除しようとして失敗することもあります。
- コンソールでソリューションをデプロイした後に、ソリューションによってプロビジョニングされたリソースを変更してからデプロイメントを削除しようとすると、削除が失敗することがあります。[ソリューションのデプロイ] ページの [ステータス] フィールドに「失敗」と表示され、Cloud Build のログにエラーの原因が表示されます。
- Terraform CLI を使用してソリューションをデプロイした後に、Terraform 以外のインターフェース（コンソールなど）を使用してリソースを変更し、デプロイメントを削除しようとすると、削除が失敗することがあります。
terraform destroyコマンドの出力にあるメッセージにエラーの原因が示されます。
エラーログとエラーの内容を確認し、エラーの原因となったリソースを特定して削除してから、もう一度デプロイメントを削除してみてください。
コンソールベースのデプロイメントが削除されず、Cloud Build ログを使用してエラーを診断できない場合は、Terraform CLI を使用してデプロイメントを削除できます。次のセクションをご覧ください。
Terraform CLI を使用してコンソールベースのデプロイメントを削除する
このセクションでは、コンソールからコンソールベースのデプロイメントを削除しようとしたときにエラーが発生した場合に、コンソールベースのデプロイメントを削除する方法について説明します。このアプローチでは、削除するデプロイメントの Terraform 構成をダウンロードし、Terraform CLI を使用してデプロイメントを削除します。
デプロイメントの Terraform コード、ログ、その他のデータが保存されているリージョンを特定します。このリージョンは、ソリューションのデプロイ時に選択したリージョンとは異なる場合があります。
Google Cloud コンソールで、[ソリューションのデプロイ] ページに移動します。
削除するデプロイメントが含まれているプロジェクトを選択します。
デプロイメントのリストで、削除するデプロイメントの行を特定します。
「行の内容をすべて表示する」をクリックします。
[場所] 列で、次の例でハイライトされているように、2 番目の場所をメモします。
In the Google Cloud console, 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出力は次のようになります。
projects/PROJECT_ID/locations/REGION/deployments/DEPLOYMENT_NAME/revisions/r-0デプロイメントの Terraform 構成の Cloud Storage のロケーションを取得します。
export CONTENT_PATH=$(curl \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ "https://config.googleapis.com/v1alpha2/${REVISION_ID}" \ | jq .applyResults.content -r) echo $CONTENT_PATHこのコマンドの出力例を次に示します。
gs://PROJECT_ID-REGION-blueprint-config/DEPLOYMENT_NAME/r-0/apply_results/contentCloud Storage から Cloud Shell に Terraform 構成をダウンロードします。
gsutil cp -r $CONTENT_PATH $HOME cd $HOME/content/次の例に示すように、
Operation completedメッセージが表示されるまで待ちます。Operation completed over 45 objects/268.5 KiBTerraform を初期化します。
terraform init次のメッセージが表示されるまで待ちます。
Terraform has been successfully initialized!デプロイされたリソースを削除します。
terraform destroy破棄されるリソースのリストが表示されます。
宣言されていない変数に関する警告が表示された場合は、警告を無視してください。
アクションの実行を求められたら、「
yes」と入力します。進行状況を示すメッセージが表示されます。すべてのリソースが削除されると、次のメッセージが表示されます。
Destroy complete!デプロイメント アーティファクトを削除します。
curl -X DELETE \ -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}?force=true&delete_policy=abandon"数秒待ってから、デプロイメント アーティファクトが削除されたことを確認します。
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 .error.message出力に
nullと表示されている場合は、数秒待ってから、もう一度コマンドを実行します。デプロイメント アーティファクトが削除されると、次のようなメッセージが表示されます。
Resource 'projects/PROJECT_ID/locations/REGION/deployments/DEPLOYMENT_NAME' was not found
フィードバックを送信する
ジャンプ スタート ソリューションは情報提供のみを目的としており、正式にサポートされているプロダクトではありません。Google は、予告なくソリューションを変更または削除する場合があります。
エラーのトラブルシューティングを行うには、Cloud Build のログと Terraform の出力を確認します。
フィードバックを送信する場合は、次の操作を行います。
- ドキュメント、コンソール内チュートリアル、またはソリューションについては、このページの [フィードバックを送信] ボタンを使用してください。
- Terraform コードを変更していない場合は、GitHub リポジトリで問題を作成します。GitHub の問題はベスト エフォート ベースで調査します。これは、一般的な使用に関する質問を目的としたものではありません。
- ソリューションで使用されているプロダクトに関する問題については、Cloud カスタマーケアにお問い合わせください。
次のステップ
このソリューションで使用されるプロダクトのアーキテクチャと運用に関するベスト プラクティスについては、次のドキュメントをご覧ください。
- コンテナ構築のベスト プラクティス
- Cloud Run: 一般的な開発のヒント
- Memorystore for Redis: メモリ管理のベスト プラクティス
- Memorystore for Redis: 一般的なベスト プラクティス
- Cloud SQL for PostgreSQL: 一般的なベスト プラクティス