SaaS ランタイムの概要

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

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

  • プラットフォーム管理者
  • アプリケーション デベロッパー
  • アーキテクト
  • コンプライアンス管理者
  • プラットフォーム エンジニア
  • 財務部門

SaaS ランタイムには次のようなメリットがあります。

  • SaaS テナント全体でサービス管理タスク（デプロイ、ロールアウト、フィーチャー トグル管理など）を自動化することで、大規模なサービス管理を簡素化します。
  • 構成可能なユニット全体で更新とリリースを微調整することで、オブザーバビリティと制御を拡張し、SaaS サービスを大規模かつ正確に管理します。
  • Google Distributed Cloud、Billing、Observability、Resource Manager など、さまざまな Google Cloud プロダクトでサービスを管理することで、エコシステム全体の一貫性を確保します。 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 ランタイム リソースを作成するときに自動的にプロビジョニングされます。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 ビルドと 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's の変更に対するアプローチに従います。

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

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

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

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

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

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

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

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

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

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

SaaS ランタイムのリージョン化

SaaS サービスリソースは、SaaS ランタイム ユニットが存在できる場所と、ロールアウトの管理方法を定義します。SaaS サービスを作成すると、選択したリージョンが、SaaS サービスでサポートされているリージョンの信頼できる唯一の情報源として機能します。選択したリージョンは、SaaS サービス用に定義した 使用可能なリージョンです。

コンソールから SaaS ランタイムを使用すると、SaaS ランタイムは、SaaS オファリングで定義したリソースのリージョン間のレプリケーションを自動化します。 Google Cloud これにより、SaaS サービスで定義した使用可能なすべてのリージョンで、SaaS ランタイム リソースの一貫性と可用性が確保されます。

SaaS ランタイムは次のリソースを複製します。

  • SaaS サービス（Saas）
  • ユニットの種類（UnitKind）
  • リリース（Release）

global をリージョンとして使用する

SaaS サービス内に global をリージョンとして含めることは、通常、デプロイ ターゲットには おすすめしません。SaaS ランタイムは global リージョンを使用して、リージョン ロールアウトを伝播します。リージョン ロールアウトは global リージョンでは実行できません。

ロールアウトのリージョン化

ロールアウトでサポートされるロケーションは、SaaS サービスの使用可能なリージョンで定義されている最上位のリージョンによって決まります。

ロールアウトは、関連付けられた SaaS サービスから使用可能なリージョンのリストを読み取ります。

リソースのレプリケーション

SaaS ランタイムは、SaaS サービスの使用可能なすべてのリージョンに対するリソースの作成と更新を処理します。

SaaS サービスの使用可能なリージョンを更新すると、SaaS ランタイムがレプリケーションを処理します。

  • ロケーションを追加しました: リソースは、新しく追加されたロケーションに複製されます。
  • 古いコピーがあるロケーション: コンテンツが更新されます。

Artifact Registry と Developer Connect のロケーション

Artifact Registry リポジトリと Developer Connect インスタンスのロケーションには、特定の要件があります。

  • Artifact Registry リポジトリと Developer Connect インスタンスのリージョンは、任意の有効な Google Cloud リージョンにできます。SaaS サービスの使用可能なリージョンに含める必要はありません。

  • Artifact Registry リポジトリのリージョンは、Developer Connect インスタンスのリージョンと一致 している必要があります。

    そのため、Artifact Registry と Developer Connect が単一の（異なる可能性のある）リージョンに存在する場合でも、SaaS オファリングで定義されたすべてのリージョンに SaaS オファリング、リリース、ユニットの種類のリソースが存在する必要があります。

  • ユニットは、SaaS サービスで指定されたリージョンでのみ作成できます。

SaaS ランタイムのリージョン構成の例

この例では、SaaS ランタイムを管理対象リソースのレプリケーションで使用する場合のリージョン化の仕組みを示します。

たとえば、SaaS サービスを us-central1 と europe-west4 にデプロイし、Artifact Registry リポジトリと Developer Connect インスタンスを us-east1 にホストする場合、SaaS ランタイムのリージョン インフラストラクチャは次のようになります。

  • SaaS サービスの使用可能なリージョン: ['us-central1', 'europe-west4']
  • Artifact Registry リポジトリ リージョン: us-east1
  • Developer Connect インスタンス リージョン: us-east1
  • ユニットの種類とリリース のリソース: SaaS ランタイムは、global、us-central1、europe-west4 リージョン全体でこれらのリソースの作成と更新を管理します。
  • ユニット: ユニットは us-central1 または europe-west4 のいずれかに作成できます。

この構成では、アーティファクト管理を 3 つ目の個別のリージョンに集中させ、リソースのレプリケーションを自動化しながら、2 つのリージョンにわたってデプロイを管理できます。リージョンを選択する際は、レイテンシ、コンプライアンス、データ所在地要件を慎重に検討する必要があります。

次のステップ