ジャンプ スタート ソリューション: サーバーレス コンピューティングを使用した e コマース プラットフォーム

Last reviewed 2023-08-24 UTC

このガイドでは、サーバーレス コンピューティングを使用した e コマース プラットフォーム ソリューションの概要、デプロイ、使用方法について説明します。このソリューションでは、一般公開されているオンライン ショップのウェブサイトを使用して、小売業向けの e コマース アプリケーションを構築して実行する方法を紹介します。ここでは、使用量の急増（季節限定セールなどのピークスケール イベント時など）に対応してスケーリングし、訪問者の位置情報に基づいてリクエストを管理できるアプリケーションを作成する方法について説明します。この設計により、地理的に分散した顧客に対して一貫したサービスを提供することが可能になります。

このソリューションは、サーバーレス機能を使用してスケーラブルな e コマース ウェブアプリをデプロイする方法を学習したい場合に適しています。きめ細かい運用管理が必要な場合は、Kubernetes にデプロイされる e コマース ウェブアプリ ソリューションをご覧ください。

このドキュメントは、クラウドの基本的なコンセプトを理解していることを前提としていますが、Google Cloud の知識が必須というわけではありません。また、Terraform の使用経験も役に立ちます。

目標

このソリューション ガイドは次の場合に役立ちます。

  • e コマース ウェブサイトのシステム アーキテクチャの設計方法を学習する。
  • e コマース ウェブサイトのパフォーマンス、規模、応答性を最適化する。
  • 負荷の上限をモニタリングし、予測する。
  • トレースとエラーレポートを使用して問題を把握し、管理する。

プロダクト

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

  • Cloud Run: サーバーレスのコンテナ化アプリを構築してデプロイできるフルマネージド サービス。Google Cloud がスケーリングなどのインフラストラクチャ タスクを処理するので、デベロッパーはコードのビジネス ロジックに集中できます。
  • Cloud SQL: Google Cloud インフラストラクチャで完全に管理される、クラウドベースの PostgreSQL データベース。
  • Secret Manager: シークレットをバイナリ blob またはテキスト文字列として保存、管理、アクセスできるサービス。Secret Manager を使用すると、ランタイム時にアプリケーションが必要とするデータベース パスワード、API キー、TLS 証明書を格納できます。
  • Cloud Storage: 低コストで無制限のオブジェクト ストレージをさまざまなデータ型に使用する、エンタープライズ クラスのサービス。データは Google Cloud の内部および外部からアクセス可能で、地理的な冗長性をもって複製されます。
  • Firebase Hosting: ウェブ アプリケーションと静的コンテンツをデプロイし、提供するためのフルマネージド ホスティング サービス。
  • Cloud Logging: Google Cloud や他のクラウドから取得したロギングデータとイベントの保存、検索、分析、モニタリング、アラート生成を可能にするサービス。
  • Google Cloud の分散トレース システムである Cloud Trace を使用すると、ユーザーや他のアプリケーションからの受信リクエストをアプリケーションが処理するのにかかる時間や、リクエストの処理時に実行されるオペレーション（RPC 呼び出しなど）が完了するのにかかる時間を知ることができます。
  • Error Reporting: 実行中のクラウド サービスで発生したエラーを集計して表示します。Error Reporting では、根本原因が同じであると考えられるエラーをグループ化します。

アーキテクチャ

次の図は、ソリューションのアーキテクチャを示しています。

Cloud Run でデプロイされた e コマース ウェブ アプリケーション

リクエスト フロー

e コマース プラットフォームのリクエスト処理フローは次のとおりです。フロー内のステップには、上のアーキテクチャ図のように番号が付いています。

  1. Firebase Hosting クライアントのフロントエンド。フロントエンドでは、Lit とウェブ コンポーネントを使用して API データのクライアント側レンダリングを行います。
  2. ウェブ クライアントが、Cloud Run サービスとして実行されている API バックエンドを呼び出します。Cloud Run API サーバーは、Django REST Framework を使用して Django で作成されています。
  3. Python アプリケーションの構成とその他のシークレットは Secret Manager に保存されます。
  4. アプリケーションの静的アセットは、Cloud Storage に保存されます。
  5. PostgreSQL を使用する Cloud SQL データベースが、Python アプリケーションのリレーショナル データベース バックエンドとして使用されます。
  6. Cloud Logging、Cloud Trace、Error Reporting には、他のクラウド サービスや Cloud Run API サーバーから送信されたログ、OpenTelemetry トレース、エラーレポートが保存されます。このデータにより、アプリケーションの動作のモニタリングや、予期しない動作のトラブルシューティングが可能になります。

コスト

サーバーレス コンピューティング ソリューションを備えた e コマース プラットフォームで使用される Google Cloud リソースの費用の見積もりについては、Google Cloud 料金計算ツールで事前に計算された見積もりをご確認ください。

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

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

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

始める前に

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

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

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

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

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

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

    Go to project selector

  2. Click Create project.

  3. Name your project. Make a note of your generated project ID.

  4. Edit the other fields as needed.

  5. 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 プロジェクトまたは組織の管理者が必要とする場合に、以下のロールの情報を表示してください。

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

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

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

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

    このデプロイ方法を使用する場合、コンソールからデプロイするの手順に沿って操作します。

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

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

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

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

  1. Google Cloud ジャンプ スタート ソリューションのカタログで、サーバーレス コンピューティングを使用した e コマース プラットフォーム ソリューションに移動します。

    サーバーレス コンピューティングを使用した e コマース プラットフォームに移動

  2. ソリューションの概算費用やデプロイの推定時間など、ページに表示された情報を確認します。

  3. ソリューションのデプロイを開始する準備ができたら、[デプロイ] をクリックします。

    順を追って構成するペインが表示されます。

  4. 構成ペインの手順を実施します。

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

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

  5. ソリューションがデプロイされるまで待ちます。

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

    デプロイが完了すると、[ステータス] フィールドが [デプロイ済み] に変わります。

  6. デプロイした e コマース ウェブアプリを表示して使用するには、Avocano デプロイメントを確認するの手順に沿って操作します。

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

    ツアーを開始

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

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

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

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

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

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

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

    Cloud Shell で開く

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

  2. [確認] をクリックします。

    別のブラウザタブで Cloud Shell が起動し、Cloud Shell 環境の $HOME/cloudshell_open ディレクトリに Terraform コードがダウンロードされます。

  3. Cloud Shell で、現在の作業ディレクトリが $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra かどうかを確認します。このディレクトリには、ソリューションの Terraform 構成ファイルが含まれています。このディレクトリに移動する必要がある場合は、次のコマンドを実行します。

    cd $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra

  4. 次のコマンドを実行して Terraform を初期化します。

    terraform init

    次のメッセージが表示されるまで待ちます。

    Terraform has been successfully initialized!

Terraform 変数を構成する

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

  1. 現在の作業ディレクトリが $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。

  2. 同じディレクトリに、terraform.tfvars という名前のテキスト ファイルを作成します。

  3. terraform.tfvars ファイルで次のコード スニペットをコピーし、必要な変数の値を設定します。

    • このコード スニペットにコメントとして記載されている手順を実施します。
    • このコード スニペットには、値を設定する必要のある変数のみが含まれています。Terraform 構成には、デフォルト値を持つ他の変数が含まれています。すべての変数とデフォルト値を確認するには、$HOME/cloudshell_open/terraform-dynamic-python-webapp/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"

# 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"

# Container Registry that hosts the client image
client_image_host = "hsa-public/serverless-ecommerce"

# Container Registry that hosts the server image
server_image_host = "hsa-public/serverless-ecommerce"

      必要な変数に割り当てできる値については、以下をご覧ください。

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

  1. 現在の作業ディレクトリが $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。

  2. Terraform 構成にエラーがないことを確認します。

    terraform validate

    コマンドからエラーが返された場合は、構成で必要な修正を行ってから、terraform validate コマンドを再度実行します。コマンドで次のメッセージが返されるまで、この手順を繰り返します。

    Success! The configuration is valid.

  3. 構成で定義されているリソースを確認します。

    terraform plan

  4. 前述のように変数定義ファイル（terraform.tfvars）を作成しなかった場合、Terraform でデフォルト値のない変数の値の入力を求められます。必要な値を入力します。

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

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

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

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

  1. 現在の作業ディレクトリが $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra であることを確認します。そうでない場合は、そのディレクトリに移動します。

  2. Terraform 構成を適用します。

    terraform apply

  3. 前述のように変数定義ファイル（terraform.tfvars）を作成しなかった場合、Terraform でデフォルト値のない変数の値の入力を求められます。必要な値を入力します。

    作成されるリソースのリストが表示されます。

  4. アクションの実行を求められたら、「yes」と入力します。

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

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

    すべてのリソースが作成されると、Terraform によって次のメッセージが表示されます。

    Apply complete!

  5. デプロイした e コマース ウェブアプリを表示して使用するには、Avocano デプロイメントを確認するの手順に沿って操作します。

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

    ツアーを開始

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

Avocano デプロイメントを確認する

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

Avocano とは

このソリューションでは、Avocano という名前のサンプル アプリケーションを使用して、サーバーレス アプリケーションの多くのツールとプロダクトを利用したウェブアプリのデプロイと管理を行う方法を説明しています。Avocano は、e コマース ウェブアプリの実際の実装を模倣したアプリケーションです。

Avocano フロントエンドは架空のストアフロントを表示します。ここでは、カートに商品を追加して決済プロセスを完了することができますが、このストアは架空のストアであること（Avoca--no!）が表示されます。アボカドを実際に購入できませんが、アプリケーションは、提供可能な商品数を 1 つ減らして在庫管理を表示します。

Avocano のランディング ページ

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

ソリューション デプロイメントのフロントエンドを起動するには:

  1. [Firebase コンソール] を開きます。
  2. 既存のプロジェクトを選択します。
  3. [構築] > [Hosting] に移動します。
  4. 末尾が web.app のドメインを選択します。サンプル アプリケーションのフロントエンドが新しいブラウザ ウィンドウで開きます。

これで、Avocano ウェブサイトで顧客と同じように商品の閲覧、カートへの商品の追加、ゲストとしての決済などができるようになりました。

自動スケーリングと同時実行の構成を表示する

Cloud Run は、トラフィックに応じてコンテナ インスタンスをゼロから自動的にスケールアップまたはスケールダウンし、アプリの起動時間を短縮します。

自動スケーリングと同時実行の設定について

Cloud Run での自動スケーリングと同時実行の設定は、アプリのパフォーマンスとコストに影響する可能性があることを理解しておく必要があります。

  • 最小インスタンス: 最小インスタンス数を設定して、サービスでアイドル状態のインスタンスを有効にできます。トラフィックの増加に備えて最小インスタンス数の設定を引き上げると、最初の N 人のユーザーに対するレスポンス時間を最小限に抑えることができます。サービスでレイテンシを短縮する必要がある場合（特に、アクティブなインスタンス 0 からスケーリングする場合）は、ウォーム状態を維持し、いつでもリクエストを処理できるコンテナ インスタンスの最小数を指定できます。

  • 最大インスタンス数: Cloud Run で最大インスタンス数の設定値を引き上げると、トラフィックが非常に多くなると予想される状況に対応できます。このような場合は、現在の割り当ても評価し、増加のリクエストを検討する必要があります。最大インスタンス数の設定を減らすと、予期しない費用の発生や、基盤となるバッキング インフラストラクチャの使用量（データベース容量など）が増加します。

  • 同時実行: Cloud Run の同時実行設定では、特定のコンテナ インスタンスで同時に処理できるリクエストの最大数を指定します。アプリケーションの動作に合わせてメモリ、CPU、同時実行を最適化すると、各コンテナ インスタンスの使用率が最適になり、新しいインスタンスにスケールアップする必要性が最小限に抑えられます。詳細については、同時実行を最適化するをご覧ください。

自動スケーリングと同時実行の設定を表示する

Cloud Run サービスの現在の最小インスタンス数、最大インスタンス数、同時実行の設定を表示するには:

  1. Cloud Run に移動します。
  2. 目的のサービスをクリックして、[サービスの詳細] ページを開きます。
  3. [変更内容] タブをクリックします。
  4. 右側の詳細パネルの [コンテナ] タブに、現在の最小インスタンス数、最大インスタンス数、同時実行の設定が表示されます。

これらの設定を調整してアプリのパフォーマンスを最適化する方法については、Cloud Run ドキュメントの一般的な開発のヒントをご覧ください。

トラフィック ログを表示する

Cloud Run のロギングツールを使用して、アプリへのトラフィックを監視し、問題が発生したときにアラートを受け取ることができます。

Cloud Run サービスのログを表示するには:

  1. Cloud Run に移動します。
  2. 表示されたリストで、選択したサービスをクリックします。
  3. このサービスのすべてのリビジョンのリクエストログとコンテナログを取得するには、[ログ] タブをクリックします。ログの重大度でフィルタリングできます。

Cloud Run は、標準出力に書き込まれたもの、標準エラー、/var/log/ 内のものなど、多くの場所からログを自動的にキャプチャします。Cloud Logging ライブラリを使用して行われた手動ロギングもキャプチャされます。[ログ エクスプローラで表示] をクリックして、Cloud Logging でこのサービスのログを直接表示することもできます。

Avocano アプリで、次のユーザー アクションを試して、対応する出力をトリガーします。この出力はログで確認できます。

ユーザーの操作 Log output
ショッピング カートで支払いタイプとして [Collect] を使用して購入を行う。カート内の商品数が在庫数を超えていない。 ログの出力には、httpRequest ステータスが 200 の info ログが表示されます。
ショッピング カートで支払いタイプとして [Collect] を使用して購入を行う。カート内の商品数が在庫数を超えている。 ログの出力には、httpRequest ステータスが 400 の Warning ログが表示されます。
ショッピング カートで支払いタイプとして [Credit] を使用して購入を行う。 ログの出力に、httpRequest ステータスが 501 の Error ログが表示されます。

serializers.py ファイルで、400/501 HTTP レスポンスの原因となるエラーを発生させるコードを確認できます。Cloud Run はレスポンスを記録し、対応するリクエスト ログエントリを生成します。

ログベースのアラートを使用すると、含まれたログに特定のメッセージが表示されるたびに通知できます。

トレース計測とキャプチャされたトレースを表示する

このソリューションでは、Open Telemetry Python 自動計測を使用して、Avocano アプリケーションのテレメトリー データをキャプチャします。

トレースの実装方法を理解する

このソリューションでは、自動計測を使用してトレースを生成するために、次のコードと構成設定を実装します。

  1. requirements.txt ファイルに Cloud Trace の依存関係を追加します。次のような依存関係があります。
    • opentelemetry-distro: Open Telemetry API、SDK、コマンドライン ツールをインストールします。
    • opentelemetry-instrumentation: Python 自動計測のサポートを追加します。
    • opentelemetry-exporter-gcp-trace: Cloud Trace にトレースをエクスポートするためのサポートを提供します。
    • opentelemetry-resource-detector: Google Cloud リソースの検出をサポートします。
    • opentelemetry-instrumentation-django: Django アプリケーションのトレース リクエストを許可します。
  2. iam.tf ファイルで IAM バインディングを設定し、サーバーが Cloud Trace に書き込むようにします。
  3. Cloud Trace のエクスポータを使用するように、services.tf ファイルで OTEL_TRACES_EXPORTER 環境変数を構成します。
  4. server/Procfile では、Avocano アプリで opentelemetry-instrument コマンドを実行するようにサーバーを構成します。このコマンドは、Avocano のパッケージを検出し、可能であれば自動トレース計測を適用します。

Python 用の Cloud Trace データの収集について詳しくは、Python と OpenTelemetry をご覧ください。

レイテンシ データを表示する

リクエストのレイテンシ データを表示する手順は次のとおりです。

  1. Cloud Trace に移動
  2. [トレースリスト] ページの [トレースを選択] セクションで、キャプチャされたトレースを表す青い点をクリックします。[レイテンシ] 列に、キャプチャされたトレースのレイテンシが表示されます。

[トレースリスト] ページで、以下の可視化機能を使用してトレースデータを表示することもできます。

  • ウォーターフォール グラフ: アプリケーションの完全なリクエストを表します。タイムラインの各ステップはスパンで、クリックすると詳細を表示できます。Cloud Run は、リクエスト処理やロード バランシングなどの内部オペレーション用のスパンを自動的に作成します。これらのスパンは、Avocano で生成されたスパンと同じウォーターフォール グラフに表示されるため、リクエストの全期間を表示できます。
  • スパンの詳細: Trace 用にアプリのコードを計測したときにアプリのコードに追加したラベルやアノテーションが表示されます。

カスタマイズされたトレースを追加する場合は、Open Telemetry ドキュメントの手動計測をご覧ください。

設計に関する推奨事項

このセクションでは、セキュリティ、信頼性、費用、パフォーマンスの要件を満たすアーキテクチャを開発するために、サーバーレス コンピューティング ソリューションで e コマース プラットフォームを使用する際の推奨事項について説明します。

各領域の設計に関する推奨事項を表示するには、該当するタブをクリックしてください。

セキュリティの強化

設計のフォーカス 推奨事項
データ暗号化

デフォルトでは、Cloud Run は Google が所有し Google が管理する鍵を使用してデータを暗号化します。お客様が管理する鍵を使用してコンテナを保護するには、顧客管理の暗号鍵を使用します。詳細については、顧客管理の暗号鍵の使用をご覧ください。

ソフトウェア サプライ チェーンのセキュリティ 承認済みのコンテナ イメージのみが Cloud Run サービスにデプロイされるようにするには、Binary Authorization を使用します。

信頼性の向上

設計のフォーカス 推奨事項
アプリケーションのスケーリング ソリューションの Cloud Run サービスは、リクエストの負荷に基づいてコンテナ インスタンスを水平方向に自動スケーリングするように構成されています。自動スケーリングのパラメータを確認し、要件に基づいて調整します。詳細については、コンテナ インスタンスの自動スケーリングについてをご覧ください。
リクエスト処理 クライアント固有の状態をコンテナ インスタンスに保存する Cloud Run サービスの応答性を向上させるには、セッション アフィニティを使用します。同じクライアントからのリクエストは、ベスト エフォート ベースで同じコンテナ インスタンスにルーティングされます。詳細については、セッション アフィニティ（サービス）の設定をご覧ください。
データの耐久性 データを損失から保護するために、Cloud SQL データベースの自動バックアップを使用できます。詳細については、Cloud SQL バックアップについてをご覧ください。
データベースの高可用性（HA）

ソリューション内の Cloud SQL データベースは、単一のゾーンにデプロイされます。HA の場合は、マルチゾーン構成を使用できます。詳細については、高可用性についてをご覧ください。

データベース HA が重要な要件である場合は、AlloyDB for PostgreSQL を代替の Google Cloud サービスとして検討できます。

データベースの信頼性

このソリューションの Cloud SQL インスタンスは、db-custom-2-4096 マシンタイプを使用します。このマシンタイプは 4 GB のメモリを搭載した 2 個の CPU を使用します。このマシンタイプは、テスト環境と開発環境にのみ適している、低コストのデータベース用のリソースを提供するように設計されています。本番環境レベルの信頼性が必要な場合は、より多くの CPU とメモリを提供するマシンタイプの使用を検討してください。

db-g1-small マシンタイプを使用する Cloud SQL インスタンスは、Cloud SQL サービスレベル契約（SLA）に含まれていません。SLA から除外される構成の詳細については、オペレーション ガイドラインをご覧ください。

割り当てと上限

Cloud Run のリソース数には上限が適用されます。季節ごとのイベントやセールイベントなどにより、トラフィックの急増が予想される場合は、割り当ての増加をリクエストする必要があります。詳細については、割り当てを増やす方法をご覧ください。

一部の割り当てリクエストでは手動での承認が必要になるため、事前に計画を立てる必要があります。また、割り当ての進捗状況に関するアラートを設定することもできます。

費用の最適化

設計のフォーカス 推奨事項
資源効率

Cloud Run は、CPU 使用率とメモリ使用量に基づいて、コンテナ インスタンスに送信するリクエスト数を決定します。最大同時実行数の設定を増やすと、Cloud Run で作成する必要があるコンテナ インスタンスの数を減らし、費用を削減できます。詳細については、インスタンスあたりの最大同時リクエスト数（サービス）をご覧ください。

このソリューションの Cloud Run サービスは、リクエストの処理中にのみ CPU を割り当てるように構成されています。Cloud Run サービスがリクエストの処理を完了すると、コンテナ インスタンスの CPU へのアクセスは無効になります。この構成の費用とパフォーマンスへの影響については、CPU の割り当て（サービス）をご覧ください。

パフォーマンスを改善する

設計のフォーカス 推奨事項
アプリ起動時間 コールド スタートのパフォーマンスへの影響を軽減するには、Cloud Run コンテナ インスタンスの最小数をゼロ以外の値に構成します。詳細については、Cloud Run の一般的な開発のヒントをご覧ください。
同時実行を調整する このソリューションは、個々のコンテナのスループットを最大化するように調整されています。Cloud Run は、複数のリクエストを処理するために同時実行を自動的に調整します。ただし、コンテナが多くの同時リクエストを処理できない場合、またはコンテナが大量のリクエストを処理できる場合は、デフォルトの最大同時実行を調整する必要があります。詳細については、同時実行を最適化するをご覧ください。
データベースのパフォーマンス

パフォーマンス重視のアプリケーションの場合、より大きなマシンタイプを使用してストレージ容量を増やすことで、Cloud SQL のパフォーマンスを改善できます。

データベース HA が重要な要件である場合は、AlloyDB for PostgreSQL を代替の Google Cloud サービスとして検討できます。

次の点にご注意ください。

  • 設計を変更する前に、費用への影響を評価し、他の機能との潜在的なトレードオフを検討します。Google Cloud 料金計算ツールを使用すると、設計変更の費用への影響を評価できます。
  • ソリューションの設計変更を実装するには、Terraform のコーディングに関する専門知識と、ソリューションで使用される Google Cloud サービスに関する高度な知識が必要です。
  • Google 提供の Terraform 構成を変更してエラーが発生した場合は、GitHub で問題を作成します。GitHub の問題はベスト エフォート ベースで調査します。これは、一般的な使用に関する質問を目的としたものではありません。
  • Google Cloud で本番環境レベルの環境を設計して設定する方法については、Google Cloud のランディング ゾーンの設計と Google Cloud 設定のチェックリストをご覧ください。

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

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

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

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

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

    [ソリューションのデプロイ] に移動

  2. 削除するデプロイメントが含まれているプロジェクトを選択します。

  3. 削除するデプロイメントを見つけます。

  4. デプロイメントの行で、（アクション）アイコンをクリックし、[削除] を選択します。

    行にアクション アイコンが表示されない場合は、スクロールしてください。

  5. デプロイメントの名前を入力し、[確認] をクリックします。

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

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

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

Terraform CLI を使用して削除する

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

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

  2. Terraform によってプロビジョニングされたリソースを削除します。

    terraform destroy

    破棄されるリソースのリストが表示されます。

  3. アクションの実行を求められたら、「yes」と入力します。

    進行状況を示すメッセージが表示されます。すべてのリソースが削除されると、次のメッセージが表示されます。

    Destroy complete!

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

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

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

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

  1. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. プロンプトでプロジェクト 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. エラーの原因となったエラーの詳細を表示するには:

    1. デプロイメントの行で、（アクション）をクリックします。

      行にアクション アイコンが表示されない場合は、スクロールしてください。

    2. [Cloud Build のログを表示する] を選択します。

  3. 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 を使用してデプロイメントを削除します。

  1. デプロイメントの Terraform コード、ログ、その他のデータが保存されているリージョンを特定します。このリージョンは、ソリューションのデプロイ時に選択したリージョンとは異なる場合があります。

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

      [ソリューションのデプロイ] に移動

    2. 削除するデプロイメントが含まれているプロジェクトを選択します。

    3. デプロイメントのリストで、削除するデプロイメントの行を特定します。

    4. 「行の内容をすべて表示する」をクリックします。

    5. [場所] 列で、次の例でハイライトされているように、2 番目の場所をメモします。

      デプロイメント コード、ログ、その他のアーティファクトの場所。

  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.

  3. プロジェクト ID、リージョン、削除するデプロイメントの名前の環境変数を作成します。

    export REGION="REGION"
export PROJECT_ID="PROJECT_ID"
export DEPLOYMENT_NAME="DEPLOYMENT_NAME"

    これらのコマンドで、次のように置き換えます。

    • REGION: この手順でメモした場所。
    • PROJECT_ID: ソリューションをデプロイしたプロジェクトの ID。
    • DEPLOYMENT_NAME: 削除するデプロイメントの名前。

  4. 削除するデプロイメントの最新リビジョンの 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

  5. デプロイメントの 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/content

  6. Cloud Storage から Cloud Shell に Terraform 構成をダウンロードします。

    gcloud storage cp $CONTENT_PATH $HOME --recursive
cd $HOME/content/infra

    次の例に示すように、Operation completed メッセージが表示されるまで待ちます。

    Operation completed over 45 objects/268.5 KiB

  7. Terraform を初期化します。

    terraform init

    次のメッセージが表示されるまで待ちます。

    Terraform has been successfully initialized!

  8. デプロイされたリソースを削除します。

    terraform destroy

    破棄されるリソースのリストが表示されます。

    宣言されていない変数に関する警告が表示された場合は、警告を無視してください。

  9. アクションの実行を求められたら、「yes」と入力します。

    進行状況を示すメッセージが表示されます。すべてのリソースが削除されると、次のメッセージが表示されます。

    Destroy complete!

  10. デプロイメント アーティファクトを削除します。

    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"

  11. 数秒待ってから、デプロイメント アーティファクトが削除されたことを確認します。

    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 の出力を確認します。

フィードバックを送信する場合は、次の操作を行います。

  • ドキュメント、コンソール内チュートリアル、またはソリューションについては、このページの [フィードバックを送信] ボタンを使用してください。

  • コードが変更されていない場合は、適切な GitHub リポジトリで問題を作成します。

    GitHub の問題はベスト エフォート ベースで審査されます。これは、一般的な使用に関する質問を目的としたものではありません。

  • ソリューションで使用されているプロダクトに関する問題については、Cloud カスタマーケアにお問い合わせください。

次のステップ

このソリューションでは、Cloud Run を使用して e コマース ウェブ アプリケーションをデプロイする方法について説明しました。Google Cloud のプロダクトと機能の詳細については、以下をご覧ください。