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