SaaS ランタイムの概要

SaaS ランタイムを使用すると、 Google Cloudで Software as a Service（SaaS）アプリケーションを保存、ホスト、管理、モニタリングできます。SaaS ランタイムによって Terraform のデプロイを大規模に管理し、SaaS アプリケーションとその実行基盤となるインフラストラクチャの両方を管理することが可能になります。

SaaS ランタイムは、SaaS パイプライン内のさまざまな関係者がさまざまな方法で使用できます。次のいずれかのロールに該当する場合は、SaaS ランタイムの使用を検討してください。

  • プラットフォーム管理者
  • アプリケーション デベロッパー
  • 建築家
  • コンプライアンス管理者
  • プラットフォーム エンジニア
  • 財務オペレーション

SaaS ランタイムには次の利点があります。

  • SaaS テナント全体でサービス管理タスク（デプロイ、ロールアウト、フィーチャー トグルの管理など）を自動化して、大規模なサービス管理を簡素化します。
  • 構成可能なユニット全体で更新とリリースを微調整して、オブザーバビリティと制御を拡張し、SaaS サービスを大規模かつ正確に管理します。
  • Google Cloud、Google Distributed Cloud、Billing、Observability、Resource Manager など、さまざまな Google Cloud プロダクトにわたってサービスを管理することで、 Google Cloud エコシステム全体で一貫性を構築します。
  • 効率と再利用性を高めるために、ユニットベースのグループ更新とデプロイを促進する柔軟でテンプレート化可能なアーキテクチャを使用します。

SaaS ランタイムの仕組み

SaaS ランタイムは、SaaS サービスを定義するアーティファクトをデプロイします。これらのアーティファクトには Terraform 構成が必要です。デプロイは、個別のユニットに編成されます。これらのユニットは、構成可能なロールアウト プロセスを通じて、サービスに対する変更を含むリリースで更新できます。

SaaS ランタイムの命名規則について詳しくは、用語集をご覧ください。

SaaS ランタイム用にワークロードを準備する

SaaS サービスをデプロイする前に、SaaS ランタイム エコシステム内での SaaS サービスの理想的な配置を決定することをおすすめします。

一緒に更新または変更する必要がある SaaS サービスのパーツを、個別の Terraform 構成に整理します。SaaS サービスを計画する際は、SaaS サービスの各グループにユニットの種類を使用します。

SaaS ランタイムでのワークロードの理想的な構造を把握したら、SaaS サービスとユニットの種類を作成し、ロールアウトを使用してユニットをデプロイできます。

SaaS ランタイムの設定例については、クイックスタートをご覧ください。

SaaS ランタイム サービス アカウント

SaaS ランタイムは、Google 管理のサービス アカウントとユーザー管理のサービス アカウントを組み合わせて使用します。

  • SaaS ランタイム サービス アカウント（Google 管理）: このアカウントは、最初の SaaS サービス リソースを作成した後に自動的に作成されます。Google によって管理されます。ユニットのプロビジョニング中に他の Google Cloud サービスとやり取りするなど、ユーザーに代わってアクションを実行します。

  • アクチュエーション サービス アカウント（ユーザー管理）: ユーザーが作成して管理するサービス アカウント。SaaS ランタイム（Infrastructure Manager 経由）は、このアカウントを使用して、ユニットのプロビジョニングまたは更新時に Terraform 構成を実行します。このアカウントは、Terraform で定義されたリソースの作成と管理の ID として機能します。アクチュエーション サービス アカウントの権限は、Terraform 構成が管理するリソースに直接関連付けられています。

    複数のアクチュエーション サービス アカウントを設定できます。テナントごとに 1 つのアクチュエーション サービス アカウントを用意することをおすすめします。

  • 省略可: アーティファクト作成サービス アカウント（ユーザー管理）: このサービス アカウントは、OCI アーティファクトにパッケージ化された Terraform のビルドとアップロードに使用されます。これは通常、Cloud Build サービス アカウントですが、SaaS サービスに適した権限を持つサービス アカウントであれば、どれでも構いません。

SaaS ランタイム サービス アカウント（Google 管理）

SaaS ランタイム サービス アカウントは、SaaS ランタイムがプロジェクト内でオペレーションを実行するために使用する、Google が管理するサービス エージェントです。

このサービス アカウントは、最初の SaaS Runtime リソースを作成するときに自動的にプロビジョニングされます。SaaS ランタイム サービス アカウントは、次の形式で作成されます。

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

次のように置き換えます。

  • PROJECT_NUMBER: プロジェクトの番号。

作動用のサービス アカウント（ユーザー管理）

アクチュエーション サービス アカウントは、作成する必要があるユーザー管理のサービス アカウントです。SaaS ランタイム（Infra Manager 経由）は、このサービス アカウントを使用して Terraform 構成を実行します。Terraform で定義されたリソースの作成、変更、削除を行う ID です。

このサービス アカウントは、プロジェクト内またはテナント プロジェクト内に作成する必要があります。

作動用のサービス アカウントの入力変数

ユニットを作成するときは、Terraform 構成の Key-Value ペアの入力変数としてアクチュエーション サービス アカウントを指定する必要があります。

  • 名前: actuation_sa
  • 変数の型: String

  • 変数の値: アクチュエーション サービス アカウントのメールアドレス:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

必要な権限

アクチュエーション サービス アカウントには、Terraform 構成で定義されたリソースを管理するための十分な権限が必要です。少なくとも、次のものが必要です。

  • roles/iam.serviceAccountTokenCreator: サービス アカウントが認証用のトークンを生成できるようにします。
  • roles/config.admin: Infra Manager リソースに対する完全な制御権限を付与します。
  • roles/storage.admin: Cloud Storage の完全な制御を付与します。

アクチュエーション サービス アカウントには、アプリケーションで使用される特定の Google Cloud リソースを作成して管理する権限も必要です。

次に例を示します。

  • Terraform で Google Kubernetes Engine（GKE）クラスタを作成する場合は、サービス アカウントに適切な GKE ロール（roles/container.admin など）が必要です。
  • Terraform が Compute Engine インスタンスを作成する場合は、サービス アカウントに roles/compute.admin ロールが必要です。
  • Terraform で Cloud SQL インスタンスを作成する場合は、サービス アカウントに適切な Cloud SQL ロール（roles/cloudsql.admin など）が必要です。

Terraform で使用する各 Google Cloud リソースのドキュメントを参照して、必要な権限を確認してください。アプリケーションが機能するために必要な最小限の権限を付与します。

アーティファクト作成サービス アカウント（ユーザー管理）

アーティファクト作成サービス アカウントは、ビルドシステム（Cloud Build など）を使用して Terraform アーティファクトをパッケージ化して Artifact Registry にアップロードするために作成するユーザー管理のサービス アカウントです。

このサービス アカウントは、SaaS ランタイムとアクチュエーション サービス アカウントとは別のもので、Terraform コードをビルドし、結果のアーティファクトを Artifact Registry に push します。多くの場合、これは Cloud Build サービス アカウントです。

アーティファクトの手動作成

Terraform アーティファクトを手動でビルドしてアップロードする場合（たとえば、Docker build と Docker push を直接使用する場合）、個別のアーティファクト作成サービス アカウントは必要ありません。

代わりに、必要な Artifact Registry の権限を持つ独自の認証情報またはサービス アカウントを使用して認証する必要があります。

必要な権限

Cloud Build を使用している場合、通常、Cloud Build サービス アカウントには次のロールが必要です。

  • roles/artifactregistry.writer: Artifact Registry にアーティファクトを push する。
  • roles/artifactregistry.repoAdmin: Artifact Registry リポジトリを管理する。
  • roles/storage.admin: Cloud Storage バケットを管理する。
  • roles/developerconnect.admin: Developer Connect を使用する権限。
  • roles/developerconnect.readTokenAccessor: Developer Connect 読み取りトークンを取得する権限。
  • roles/logging.logWriter: ログを書き込む権限。
  • Developer Connect を使用して Terraform 構成をデプロイする場合: roles/cloudbuild.builds.builder: ビルドを実行します。
  • ビルドプロセスに必要なその他の権限（ソースコード リポジトリへのアクセスなど）。

ロールアウト戦略

SaaS ランタイムは、SaaS サービスのユニットの更新方法を管理するために、いくつかのロールアウト戦略を採用しています。これらのロールアウト戦略は、SaaS サービス全体で変更のデプロイに一貫したアプローチを適用することで、Google Cloudの変更アプローチに従います。

ロールアウト戦略を使用して、お客様への悪影響を最小限に抑え、問題を個別の論理障害ドメインと物理障害ドメインに分離します。次のいずれかのロールアウト戦略を指定するロールアウトの種類を作成して、ロールアウト戦略を定義します。

  • 1 回に 1 つのロケーション（シンプル）: 1 回に 1 つのロケーションがロールアウトされ、ロケーション間の待機はありません。ユニットはロケーション内で任意に選択され、一度に更新されるユニットはロケーションのユニットの最大 20% です。

    この戦略は、開発環境と緊急シナリオにおすすめします。

  • 一括（シンプル）: すべてのロケーションで同時にロールアウトが開始されます。

    この戦略は、開発環境と緊急シナリオにおすすめします。

  • プログレッシブ（段階的）: 各地域内で、ユニットは静的な割合ベースのバッチ（1%、10%、20%、30%、～ 40% など）でロールアウトされ、バッチ間にソーク時間が設けられます。複数の地域にわたって、ロールアウトは、波間のソーク時間（18 時間など）で、同時実行の地域数の指数関数的な増加（1 つの地域、2 つの地域、4 つの地域など）で進行します。ロケーション内のユニットはランダムに選択されます。

    この戦略は、複数のロケーションに安全かつ予測可能なロールアウトを行えるよう設計されています。小さなフットプリントから開始し、信頼性が高まるにつれて徐々に拡げていきます。この戦略は、複数のロケーションがある本番環境におすすめします。

  • プログレッシブ（単一のロケーション）: ユニットは、静的な割合ベースのバッチ（1%、10%、20%、30%、40% など）で更新されます。バッチ間のソーク時間は長く（18 時間など）、問題の検出に十分な時間を確保し、ロールアウトの変更による悪影響を制限します。

    この戦略は、単一のロケーションで動作する SaaS サービス向けに調整されており、安全性と慎重さを優先しています。この戦略は、1 つの店舗がある本番環境におすすめします。

ロールアウトの種類を作成する方法については、ロールアウトの種類を作成するをご覧ください。

次のステップ