App Lifecycle Manager（旧称 SaaS Runtime）を使用すると、 Google Cloudで Software as a Service（SaaS）アプリケーションを保存、ホスト、管理、モニタリングできます。App Lifecycle Manager によって Terraform のデプロイを大規模に管理し、SaaS アプリケーションとその実行基盤となるインフラストラクチャの両方を管理することが可能になります。
App Lifecycle Manager は、SaaS パイプライン内のさまざまな関係者がさまざまな方法で使用できます。次のいずれかの役割に該当する場合は、App Lifecycle Manager の使用を検討してください。
- プラットフォーム管理者
- アプリケーション デベロッパー
- アーキテクト
- コンプライアンス管理者
- プラットフォーム エンジニア
- 財務オペレーション
App Lifecycle Manager には次の利点があります。
- SaaS テナント全体でサービス管理タスク（デプロイ、ロールアウト、フィーチャー トグル管理など）を自動化することで、大規模なサービス管理を簡素化します。
- 構成可能なユニット全体でアップデートとリリースを微調整することで、オブザーバビリティと制御を拡張し、App の提供を大規模かつ正確に管理できます。
- Google Cloud、Google Distributed Cloud、Billing、Observability、Resource Manager などのさまざまな Google Cloud プロダクトでサービスを管理することで、 Google Cloud エコシステム全体で一貫性を構築します。
- ユニットベースのグループの更新とデプロイを促進する、柔軟でテンプレート化可能なアーキテクチャを使用して、効率性と再利用性を向上させます。
App Lifecycle Manager の仕組み
App Lifecycle Manager は、アプリの提供を定義するアーティファクトをデプロイします。これらのアーティファクトには Terraform 構成が必要です。デプロイは、構成可能なロールアウトを通じて、サービスへの変更を含むリリースで更新できる個別のユニットに編成されます。
App Lifecycle Manager の命名規則の詳細については、用語集をご覧ください。
App Lifecycle Manager 用にワークロードを準備する
App サービスをデプロイする前に、App Lifecycle Manager エコシステム内で App サービスの最適な配置を決定することをおすすめします。
一緒に更新または変更する必要がある App サービスの部分を、個別の Terraform 構成に整理します。アプリの提供を計画する際は、アプリの提供のグループごとにユニットの種類を使用します。
App Lifecycle Manager でワークロードの理想的な構造を決定したら、App オファリングとユニットの種類を作成し、ロールアウトを使用してユニットをデプロイできます。
App Lifecycle Manager の設定例については、クイックスタートをご覧ください。
App Lifecycle Manager で複合テンプレートを使用する
Application Design Center で複合テンプレートを使用すると、App Lifecycle Manager アプリケーション サービスのインフラストラクチャを定義できます。
複合テンプレートを App オファリングに接続すると、App Lifecycle Manager はテンプレートで定義されたユニットの種類を自動入力します。これにより、複合テンプレートで定義された構造とリソースに基づいてユニットをデプロイできます。
App Design Center で複合テンプレートを編集し、App Lifecycle Manager のアプリ オファリングに変更を反映できます。
複合テンプレートの詳細については、複合テンプレートを設計するのドキュメントをご覧ください。複合テンプレートを App Lifecycle Manager サービスにアタッチする方法については、デプロイのモデル単位とパッケージ単位をご覧ください。
App Lifecycle Manager サービス アカウント
App Lifecycle Manager は、Google 管理のサービス アカウントとユーザー管理のサービス アカウントを組み合わせて使用します。
App Lifecycle Manager サービス アカウント（Google 管理）: このアカウントは、最初の App Offering リソースの作成後に自動的に作成されます。Google によって管理されます。ユニットのプロビジョニング中に他の Google Cloud サービスとやり取りするなど、ユーザーに代わって操作を実行します。
作動サービス アカウント（ユーザー管理）: このサービス アカウントは、ユーザーが作成して管理します。App Lifecycle Manager（Infrastructure Manager 経由）は、このアカウントを使用して、ユニットのプロビジョニングまたは更新時に Terraform 構成を実行します。このアカウントは、Terraform で定義されたリソースを作成して管理するための ID として機能します。作動サービス アカウントの権限は、Terraform 構成が管理するリソースに直接関連付けられています。
複数の作動サービス アカウントを使用できます。テナントごとに 1 つの作動サービス アカウントを用意することをおすすめします。
省略可: アーティファクト作成サービス アカウント（ユーザー管理）: このサービス アカウントは、OCI アーティファクトにパッケージ化された Terraform のビルドとアップロードに使用されます。これは多くの場合、Cloud Build サービス アカウントですが、App サービスに適切な権限を持つサービス アカウントであれば、どのサービス アカウントでもかまいません。
App Lifecycle Manager サービス アカウント（Google 管理）
App Lifecycle Manager サービス アカウントは、App Lifecycle Manager がプロジェクト内でオペレーションを実行するために使用する Google 管理のサービス エージェントです。
このサービス アカウントは、最初の App Lifecycle Manager リソースを作成するときに自動的にプロビジョニングされます。App Lifecycle Manager サービス アカウントは、次の形式で作成されます。
service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.
次のように置き換えます。
- PROJECT_NUMBER: プロジェクトの番号。
作動用のサービス アカウント（ユーザー管理）
作動サービス アカウントは、ユーザーが作成する必要があるユーザー管理のサービス アカウントです。App Lifecycle Manager（Infra Manager 経由）は、このサービス アカウントを使用して Terraform 構成を実行します。これは、Terraform で定義されたリソースを作成、変更、削除する ID です。
このサービス アカウントは、プロジェクト内またはテナント プロジェクト内に作成する必要があります。
作動用のサービス アカウントの入力変数
ユニットを作成するときに、Terraform 構成の Key-Value ペア入力変数として作動サービス アカウントを指定する必要があります。
- 名前:
actuation_sa - 変数タイプ:
String 変数値: 作動サービス アカウントのメールアドレス:
my-actuation-sa@my-identifier.
必要な権限
作動サービス アカウントには、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 にアップロードするために作成するユーザー管理のサービス アカウントです。
このサービス アカウントは、App Lifecycle Manager と動作用のサービス アカウントとは別のもので、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: ビルドを実行します。 - ビルドプロセスに必要なその他の権限（ソースコード リポジトリへのアクセスなど）。
ロールアウト戦略
App Lifecycle Manager は、複数のロールアウト戦略を使用して、アプリ サービスのユニットの更新方法を管理します。これらのロールアウト戦略は、Google Cloudの変更アプローチに沿って、App サービス全体に変更のデプロイに一貫したアプローチを適用します。
ロールアウト戦略を使用して、お客様への悪影響を最小限に抑え、問題を個別の論理障害発生ドメインと物理障害発生ドメインに分離します。次のいずれかのロールアウト戦略を指定するロールアウトの種類を作成して、ロールアウト戦略を定義します。
1 回に 1 つのロケーション（シンプル）: 1 回に 1 つのロケーションが更新され、ロケーション間に待機時間はありません。ユニットはロケーション内で任意に選択され、特定の時点で更新されるユニットはロケーションの最大 5% です。
この戦略は、開発環境と緊急シナリオに推奨されます。
一括（シンプル）: すべてのロケーションで同時に更新が開始されます。
この戦略は、開発環境と緊急シナリオに推奨されます。
プログレッシブ（段階的）: 各ロケーション内で、ユニットは静的な割合ベースのバッチ（1%、10%、20%、30%、～ 40% など）で更新され、バッチ間にソーク時間が設けられます。ロケーション全体で、ロールアウトは同時ロケーションの数を指数関数的に増やしながら（たとえば、1 つのロケーション、2 つ、4 つ）、ウェーブ間のソーク時間（たとえば、18 時間）を設けて進行します。ロケーション内のユニットはランダムに選択されます。
この戦略は、複数のロケーションに安全かつ予測可能なロールアウトを行えるよう設計されています。小さなフットプリントから開始し、信頼性が高まるにつれて徐々に拡げていきます。この方法は、複数のロケーションがある本番環境で推奨されます。
プログレッシブ（単一ロケーション）: ユニットは、静的な割合ベースのバッチ（1%、10%、20%、30%、～ 40% など）で更新されます。バッチ間のソーク時間は長く（18 時間など）、問題の検出に十分な時間を確保し、ロールアウト変更の悪影響を制限します。
この戦略は、単一のロケーションで運用されるアプリ サービス向けに調整されており、安全性と慎重さを優先しています。この戦略は、1 つのロケーションを使用する本番環境におすすめします。
ロールアウトの種類を作成する方法については、ロールアウトの種類を作成するをご覧ください。
App Lifecycle Manager のリージョン化
アプリ提供リソースは、App Lifecycle Manager ユニットを配置できる場所と、ロールアウトの管理方法を定義します。アプリ サービスを作成するときに選択したリージョンは、アプリ サービスのサポート対象リージョンの信頼できる唯一の情報源として機能します。選択したリージョンは、App サービスに定義した利用可能なリージョンです。
Google Cloud コンソールで App Lifecycle Manager を使用すると、App Lifecycle Manager は、App オファリングで定義したリソースのリージョン間レプリケーションを自動化します。これにより、App サービスで定義したすべての利用可能なリージョンで、App Lifecycle Manager リソースの整合性と可用性が確保されます。
App Lifecycle Manager は、次のリソースを複製します。
- アプリの提供（
Saas） - ユニットの種類（
UnitKind） - リリース（
Release）
リージョンとして global を使用する
一般的に、App サービス内のリージョンとして global を含めることは、デプロイ ターゲットとして推奨されません。App Lifecycle Manager は、global リージョンを使用してリージョン ロールアウトを伝播します。リージョン ロールアウトは global リージョンでは実行できません。
ロールアウトのリージョン指定
ロールアウトでサポートされているロケーションは、アプリ サービスの利用可能なリージョンで定義されている最上位リージョンによって決まります。
ロールアウトは、関連付けられたアプリ オファリングから利用可能なリージョンのリストを読み取ります。
リソースのレプリケーション
App Lifecycle Manager は、アプリ サービスが利用可能なすべてのリージョンでリソースの作成と更新を処理します。
アプリ サービスが利用可能なリージョンを更新すると、App Lifecycle Manager がレプリケーションを処理します。
- 追加されたロケーション: リソースは、新しく追加されたロケーションに複製されます。
- 古いコピーがある場所: コンテンツが更新されます。
Artifact Registry と Developer Connect のロケーション
Artifact Registry リポジトリと Developer Connect インスタンスのロケーションには、特定の要件があります。
Artifact Registry リポジトリと Developer Connect インスタンスのリージョンは、任意の有効な Google Cloud リージョンにできます。アプリの提供対象の利用可能なリージョンに含める必要はありません。
Artifact Registry リポジトリのリージョンは、Developer Connect インスタンスのリージョンと一致する必要があります。
このため、Artifact Registry と Developer Connect が単一の（場合によっては異なる）リージョンに存在する場合でも、アプリの提供、リリース、ユニットの種類のリソースが、アプリの提供で定義されているすべてのリージョンに存在する必要があります。
ユニットは、アプリのサービスで指定されたリージョンでのみ作成できます。
App Lifecycle Manager のリージョン構成の例
この例では、マネージド リソース レプリケーションで App Lifecycle Manager を使用する場合のリージョン化の仕組みを示します。
たとえば、App オファリングを us-central1 と europe-west4 にデプロイし、Artifact Registry リポジトリと Developer Connect インスタンスを us-east1 でホストする場合、App Lifecycle Manager リージョンのインフラストラクチャは次のようになります。
- アプリを利用できる地域:
['us-central1', 'europe-west4'] - Artifact Registry リポジトリのリージョン:
us-east1 - Developer Connect インスタンスのリージョン:
us-east1 - ユニットの種類とリリースリソース: App Lifecycle Manager は、
global、us-central1、europe-west4リージョン全体でこれらのリソースの作成と更新を管理します。 - ユニット: ユニットは
us-central1またはeurope-west4のいずれかで作成できます。
この構成では、2 つのリージョンにまたがるデプロイを管理しながら、自動化されたリソース レプリケーションを使用して、3 つ目の異なるリージョンでアーティファクト管理を一元化できます。リージョンを選択する際は、レイテンシ、コンプライアンス、データ所在地の要件を慎重に検討する必要があります。
次のステップ
- クイックスタートを試して、App Lifecycle Manager を使用して VM をデプロイする方法を確認する。
- App Lifecycle Manager の使用を開始するには、まずアプリのオファリングを作成します。