AWS CDK Pipelines を利用した SaaS の並列かつ動的なデプロイ

こちらの記事は「Parallel and dynamic SaaS deployments with AWS CDK Pipelines」を翻訳したものです。

Software as a Service（SaaS）は、従量課金制の価格モデル、スケーラビリティ、可用性などのメリットをもたらすビジネスモデルで、独立系ソフトウェアベンダー（ISV）の間でますます人気を集めています。

SaaS サービスは、多数のアーキテクチャモデルを使用して構築できます。アーキテクチャを共有しないサイロモデルでは、各テナントごとに専用のリソースを提供します。サイロモデルでの展開は、テナント間のコンピューティングリソースとデータを分離し、ノイジーネイバー問題を排除するのにも役立ちます。一方、プールモデルには、コンピューティングリソースとキャパシティをより効率的に利用できるため、メンテナンスのオーバーヘッドの削減、管理と運用の簡素化、コスト削減の機会など、いくつかのメリットがあります。ブリッジモデルは、サイロモデルとプールモデルの両方が共存して使用されるハイブリッドなモデルです。システムの一部はサイロモデルとして、別の一部はプールモデルとして構築することができます。

エンドユーザーは、様々な点で SaaS 提供モデルのメリットを享受することができます。例えば、複数の場所からサービスを利用できるため、顧客は自分に最適なものを選択することができます。テナントのオンボーディングプロセスは、多くの場合、リアルタイムかつ円滑に行われます。エンドユーザー側のこれらのメリットを実現するために、SaaS プロバイダーは、信頼性が高く、高速で、マルチリージョンに対応したプロビジョニングとソフトウェアライフサイクル管理のための方法を必要としています。

この記事では、AWS Cloud Development Kit (AWS CDK) と CDK Pipelines を使用した、プールまたはサイロモデルにおけるワークロードコンポーネントのプロビジョニングとライフサイクル管理を自動化するためのデプロイシステムについて解説します。システムの動的でデータベース駆動型のデプロイモデルと、マルチアカウントおよびマルチリージョン対応について検討し、さらにサイロモデルとプールモデルの両方でワークロードコンポーネントのデプロイのデモを行います。

AWS Cloud Development Kit と CDK Pipelines

このソリューションでは、AWS Cloud Development Kit (AWS CDK) と CDK Pipelines コンストラクトライブラリを利用しています。AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化し、プロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK では、インフラストラクチャをコードとして定義し、AWS CloudFormation を通じてプロビジョニングできます。

CDK Pipelines は、CDK アプリケーション用の継続的デプロイメントパイプラインを独自に実装した、高レベルのコンストラクトライブラリです。完全マネージド型の継続的デリバリーサービスである AWS CodePipeline をベースに、リリースパイプラインを自動化して、高速で信頼性の高いアプリケーションおよびインフラストラクチャの更新を実現します。サーバーのプロビジョニングやセットアップは不要で、お支払いは使用した分だけの従量課金制です。このソリューションは、最近リリースされた安定版の CDK Pipelines modern API を使用しています。

ビジネスシナリオ

基礎的なユースケースとして、SaaS ビジネスモデルを実装しようとしている Unicorn 社という架空の ISV を想定し、検討事項を整理しました。

Unicorn 社は複数の国で事業を展開しており、お客様が選択したリージョン内で顧客データを保存する必要があります。主要な顧客基盤の要件を満たすために、現在は EU と US の２つのリージョンが必要です。急速な成長が期待されているので、数千のテナントに拡張できるソリューションが求められます。Unicorn 社は、異なる分離要件を満たす複数の契約プランをテナントに提供することを計画しています。計画している導入モデルでは、大半のテナントがプールインスタンスを共有し、必要に応じてテナント専用のサイロインスタンスをサポートすることも検討しています。また、Unicorn 社のビジネス拡大に伴い、ソリューションを新しいリージョンに簡単に拡張できる必要があります。

Unicorn 社は、小規模な単一の開発チームから始めており、今のところチームは SaaS ワークロードアーキテクチャのコンポーネントのみを担当しています。Unicorn 社は、業界のベストプラクティスに従って、各コンポーネントが明確な技術的所有権の境界を持つようにワークロードアーキテクチャを設計しました。選択したソリューションは、Unicorn 社と共に成長し、将来的には独立して開発およびデプロイされる複数のコンポーネントをサポートする必要があります。

ソリューション概要

現在、多くのお客様が AWS CodePipeline を利用して、クラウドアプリケーションのビルド、テスト、デプロイを行っています。Unicorn 社のような SaaS プロバイダーにとって、すべての環境を管理するために単一のパイプラインを利用しようとする場合、懸念が生じます。Unicorn 社が必要とする規模感で、数百のアクションを含む可能性のある単一のパイプラインでは、スループットが制限されるリスクがあります。さらに、単一のパイプラインでは、変更をどのようにリリースするかあまり柔軟にコントロールすることはできません。

この記事で紹介するソリューションでは、プールおよびサイロ環境ごとに個別の動的にプロビジョニングされるパイプラインを用意することで、この問題に対応します。このソリューションは、Unicorn 社の１つのワークロードコンポーネントを複数の環境に展開できるように設計されています。これによって、現在の要件を満たすとともに、今後発生する小さな変更にも対応できるようになっています。

CDK ベストプラクティスでは、AWS CDK アプリケーションは AWS Well-Architected Framework で定義されているコンポーネントにマッピングされると述べられています。コンポーネントとは、ワークロード要件に対して一緒に配信されるコード、設定、および AWS リソースです。そして、これは一般的に技術的所有権の単位となります。通常、コンポーネントには論理ユニット (API、データベースなど) が含まれ、継続的デプロイメントパイプラインを持つことができます。
CDK Pipelines を利用することには大きなメリットがあります。コードを追加することなく、クロスアカウントとクロスリージョンのデプロイを、単一のアカウントとリージョンにやるのと同じくらい簡単にできます。CDK Pipelines は、必要なクロスアカウント暗号化キーとクロスリージョンレプリケーションバケットを自動的に作成して管理します。さらに、CDK ブートストラップのプロセス中にアカウント間の信頼関係を確立するだけで済みます。

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

図１: ソリューションアーキテクチャ

サイロとプールパイプラインのプロビジョニング (１と２) とコンポーネントコードのデプロイ (３と４) という２つの主要なソリューションの大まかな流れを詳しく見てみましょう。

プロビジョニングは専用のフローとして分離されているので、コードのデプロイがテナントのオンボーディングを妨げることはありません。その逆も同様です。プロビジョニングフローの中心にあるのは、Amazon DynamoDB テーブルを使用したデプロイメントデータベース (1) です。

DynamoDB Streams と AWS Lambda トリガーを利用して、デプロイメントデータベースにレコードが挿入されると、プロビジョニング用の新しい AWS CodeBuild ビルドプロジェクト (2) が作成され、自動的にビルドが開始されます。プロビジョニングプロジェクトでは、「cdk deploy」コマンドを使用して、新しいサイロおよびプールパイプラインを直接プロビジョニングします。プロビジョニングイベントは並列で処理されるため、このソリューションは Unicorn 社のテナントオンボーディングの規模で発生し得るバーストに対応することができます。

CDK のベストプラクティスでは、インフラストラクチャとランタイムコードを同じパッケージ内に含めることを推奨しています。単一の AWS CodeCommit リポジトリ (3) には、CI/CD パイプラインの定義とワークロードコンポーネントコードなど、必要なものをすべて含めています。このリポジトリは、すべての CodePipeline パイプラインと CodeBuild プロジェクトのソースアーティファクトです。「コードとしてのアプリケーションリソースの管理」の章で、関連する実装の詳細について説明します。

CI/CD パイプライン (4) は CDK Pipelines のパイプラインで、コンポーネントのソフトウェア開発ライフサイクル (SDLC) のアクティビティを担っています。ほとんどの SaaS プロバイダーは、更新のリリースプロセス以外に追加のアクティビティも実装するかと思います。例えば、様々なテストや実稼働前の環境でのデプロイなどです。「デプロイメントの更新の制御」の章で、このトピックの詳細に入っていきます。

デプロイメントには、パイプライン (5) とパイプラインが管理するコンポーネントリソーススタック (6) の２つのパーツがあります。パイプラインは中央のツールチェーンアカウントおよびリージョンにデプロイされ、コンポーネントリソースは、デプロイメントデータベース内のレコードで指定されている AWS アカウントとリージョンにデプロイされます。

ソリューションのサンプルコードは GitHub にあります。この記事と併せてご活用ください。コードは、TypeScript で実装されています。

デプロイメントデータベース

デプロイメントデータベースは Amazon DynamoDB テーブルで、次のようなスキーマになっています。

図２: DynamoDB テーブル

「id」はデプロイメントごとの一意の識別子です。
「account」はコンポーネントリソースが存在する AWS アカウント ID です。
「region」はコンポーネントリソースが存在する AWS リージョン ID です。
「type」は ‘silo’ または ‘pool’ のいずれかで、デプロイメントモデルを表しています。

この設計は、複数のサイロおよびプールモデルの展開をサポートします。あらかじめブートストラップされ利用可能な状態になっている AWS アカウントとリージョンであればどこにでもデプロイを行うことができます。例えば、複数のプール環境を各リージョンに展開したり、一部のテナントを専用サイロ環境にデプロイすることができます。プールでは提供できるテナントの数に限界があるため、この設計では１つのリージョン内に複数のプールを持つことも可能になっています。また、契約プランの概念を取り入れるために追加の属性を使用して拡張することも簡単です。

デプロイメントデータベースにはテナント情報は含まれていないことに注意してください。このようなマッピングは、別のテナントデータベースで管理し、そちらで各テナントレコードと関連するデプロイメント ID の紐付けを行ってください。

ソリューションの設計とアーキテクチャが確認できたところで、ハンズオンの章に移りましょう。まずは、ソリューションの導入要件から始めます。

前提条件

ソリューションをデプロイするには、次のツールが必要です。

AWS CDK バージョン 1.124.0 と互換性のある NodeJS バージョン
AWS コマンドラインインターフェイス (AWS CLI)
git-remote-codecommit 拡張機能付きの Git

このチュートリアルを最後まで実行するには、少なくとも１つ、できれば２つの AWS アカウントに対する管理者アクセス権限が必要です。

ツールチェーン (Toolchain): SDLC ツールチェーン (パイプライン、プロビジョニングプロジェクト、リポジトリ、デプロイメントデータベース) 用のアカウント
ワークロード (Workload) (任意): コンポーネントリソース用のアカウント

アカウントが１つしかない場合、両方ともツールチェーンアカウントを使用してください。アカウントの認証情報は、AWS CLI プロファイルで設定されていることを想定して進めます。

この記事の手順では、次のプレースホルダを使用します。これらのプレースホルダは皆さんの環境の値に置き換える必要があります。

<TOOLCHAIN_ACCOUNT_ID>: ツールチェーンアカウントの AWS アカウント ID
<TOOLCHAIN_PROFILE_NAME>: ツールチェーンアカウントの認証情報の AWS CLI プロファイル名
<WORKLOAD_ACCOUNT_ID>: ワークロードアカウントの AWS アカウント ID
<WORKLOAD_PROFILE_NAME>: ワークロードアカウントの認証情報の AWS CLI プロファイル名

ブートストラップ

ツールチェーンアカウントとすべてのワークロードアカウントは、初回デプロイの前にブートストラップする必要があります。

始める前に、AWS CDK とソリューションの依存関係をインストールする必要があります。最も簡単な方法は、npm でローカルにインストールすることです。まず、サンプルコードをダウンロードして、package.json 設定ファイルを npm で使用できるようにする必要があります。

読みやすさのために、これらの手順の多くのコマンドを複数行に分割しています。必ず全てのコマンドを実行するようにしてください。各コードブロックをまとめて実行するのが安全です。

GitHub からサンプルコードリポジトリをクローンし、npm を使用して依存関係をインストールします。

git clone https://github.com/aws-samples/aws-saas-parallel-deployments
cd aws-saas-parallel-deployments
npm ci

CDK Pipelines では、最新のブートストラップを使用する必要があります。これを有効化するために、関連する環境変数を設定することから始めます（参考ドキュメント：CDK のブートストラップ）。

export CDK_NEW_BOOTSTRAP=1

次に、ツールチェーンアカウントをブートストラップします。ツールチェーンスタックがデプロイされるリージョンと、コンポーネントリソースを展開するすべてのリージョンの両方をブートストラップする必要があります。ここでは、最初に us-east-1 リージョンのみをブートストラップします。後からオプションでリージョンを追加することもできます。

ブートストラップするには、npx を使用して、ローカルにインストールされたバージョンの AWS CDK を実行します。

npx cdk bootstrap <TOOLCHAIN_ACCOUNT_ID>/us-east-1 --profile <TOOLCHAIN_PROFILE_NAME>

ツールチェーンアカウントとは別のワークロードアカウントがある場合は、そのアカウントもブートストラップする必要があります。ワークロードアカウントをブートストラップする際に、ツールチェーンアカウントとの信頼関係を確立します。別のワークロードアカウントがない場合は、この手順をスキップしてください。

ワークロードアカウントのブーストラップは、最小権限のセキュリティベストプラクティスに従います。まず、デモコンポーネントリソースのデプロイに必要な最小限の権限を持つ実行ポリシーを作成します。このために、ソリューションリポジトリにサンプルポリシーファイルを用意しました。次に、そのポリシーをツールチェーンアカウントとワークロードアカウント間の信頼関係の実行ポリシーとして使用します。

aws iam create-policy \
--profile <WORKLOAD_PROFILE_NAME> \
--policy-name CDK-Exec-Policy \
--policy-document file://policies/workload-cdk-exec-policy.json
npx cdk bootstrap <WORKLOAD_ACCOUNT_ID>/us-east-1 \
--profile <WORKLOAD_PROFILE_NAME> \
--trust <TOOLCHAIN_ACCOUNT_ID> \
--cloudformation-execution-policies arn:aws:iam::<WORKLOAD_ACCOUNT_ID>:policy/CDK-Exec-Policy

ツールチェーンのデプロイ

最初のデプロイを行う前に、ソリューションの AWS CodeCommit リポジトリを作成する必要があります。このリポジトリをツールチェーンアカウントで作成します。

aws codecommit create-repository \
--profile <TOOLCHAIN_PROFILE_NAME> \
--region us-east-1 \
--repository-name unicorn-repository

次に、コンテンツを CodeCommit リポジトリにプッシュする必要があります。AWS CLI の認証情報を使ってリポジトリを認証するために、git-remote-codecommit 拡張機能を git コマンドとともに使用します。パイプラインは main ブランチを使用するように設定されています。

git remote add unicorn codecommit::us-east-1://<TOOLCHAIN_PROFILE_NAME>@unicorn-repository
git push unicorn main

これで、ツールチェーンスタックをデプロイする準備が整いました。

export AWS_REGION=us-east-1
npx cdk deploy --profile <TOOLCHAIN_PROFILE_NAME>

ワークロードのデプロイ

この時点で、CI/CD パイプライン、プロビジョニングプロジェクト、およびデプロイメントデータベースが作成されました。データベースは最初は空の状態です。

以下に示す DynamoDB コマンドラインインターフェイスは、本番環境で使用する SaaS プロバイダーのプロビジョニング用インターフェイスを意図したものではないことに注意してください。SaaS プロバイダーは通常、顧客がサービスにサインアップするためのオンライン登録ポータルを持っています。新しいデプロイが必要な場合は、ソリューションのデプロイメントデータベースにレコードが自動的に挿入されるようにするべきです。

ソリューションの機能をデモするために、最初に２つの環境をプロビジョニングし、オプションで３つ目のクロスリージョン環境を用意します。

us-east-1 リージョンでのサイロ環境 (silo1)
us-east-1 リージョンでのプール環境 (pool1)
eu-west-1 リージョンでのプール環境 (pool2) (オプション)

始める前に、AWS CLI 環境変数を設定します。

export AWS_REGION=us-east-1
export AWS_PROFILE=<TOOLCHAIN_PROFILE_NAME>

最初の２つの環境をデプロイメントデータベースレコードに追加します。

aws dynamodb put-item \
--table-name unicorn-deployments \
--item '{
"id": {"S":"silo1"},
"type": {"S":"silo"},
"account": {"S":"<WORKLOAD_ACCOUNT_ID>"},
"region": {"S":"us-east-1"}
}'
aws dynamodb put-item \
--table-name unicorn-deployments \
--item '{
"id": {"S":"pool1"},
"type": {"S":"pool"},
"account": {"S":"<WORKLOAD_ACCOUNT_ID>"},
"region": {"S":"us-east-1"}
}'

これにより、プロビジョニング CodeBuild プロジェクトの２つの並列ビルドがトリガーされます。CodeBuild コンソールを使用して、各ビルドのステータスと進行状況を確認しましょう。

クロスリージョンデプロイ (オプション)

必要に応じて、クロスリージョンデプロイも試してください。皆さんのユースケースに関係しない場合は、このパートはスキップしてください。

まず、ツールチェーンとワークロードアカウントで対象のリージョンをブートストラップする必要があります。ここでの eu-west-1 のブートストラップは、先ほどの us-east-1 リージョンのものと同じです。まず、ツールチェーンアカウントをブートストラップします。

npx cdk bootstrap <TOOLCHAIN_ACCOUNT_ID>/eu-west-1 --profile <TOOLCHAIN_PROFILE_NAME>

別のワークロードアカウントをお持ちの場合は、新しいリージョン用にこちらもブートストラップする必要があります。繰り返しになりますが、アカウントが１つしかない場合は、この設定をスキップしてください。

npx cdk bootstrap <WORKLOAD_ACCOUNT_ID>/eu-west-1 \
--profile <WORKLOAD_PROFILE_NAME> \
--trust <TOOLCHAIN_ACCOUNT_ID> \
--cloudformation-execution-policies arn:aws:iam::<WORKLOAD_ACCOUNT_ID>:policy/CDK-Exec-Policy

次に、クロスリージョン環境を追加します。

aws dynamodb put-item \
--table-name unicorn-deployments \
--item '{
"id": {"S":"pool2"},
"type": {"S":"pool"},
"account": {"S":"<WORKLOAD_ACCOUNT_ID>"},
"region": {"S":"eu-west-1"}
}'

デプロイの検証

ビルドが完了したら、CodePipeline コンソールを使用して、ツールチェーンアカウントにデプロイメントパイプラインが正常に作成されたことを確認します。

図３: CodePipeline コンソール

同様に、ワークロードアカウントでは、コンポーネントリソースを含むスタックが、設定されたデプロイ先の各リージョンに作成されます。このデモでは、AWS App Runner をランタイム環境として使用する単一の「hello world」コンテナアプリケーションをデプロイします。CloudFormation コンソールからデプロイが成功したことを確認できます。

図４: CloudFormation コンソール

デモのデプロイが正常に終了したら、パイプラインとコンポーネントリソースの更新をどのように管理できるか見ていきましょう。

コードとしてのアプリケーションリソースの管理

ソリューション概要で前述したように、ソリューションのあらゆる面で単一のソースリポジトリを共有しています。すべてのコードを単一のソースにまとめることで、ソリューションの複数の側面に影響を与える複雑な変更でも簡単に反映することができます。また、これらすべてを１つの変更セットとしてパッケージング、テスト、リリースすることが可能です。例えば、CI/CD パイプラインの新しいステージの導入、サイロまたはプールパイプライン内の既存ステージの変更、コンポーネントリソースに対するコードやリソースの修正などが考えられます。

CDK Pipelines の自動再構成機能 (self-mutate) により、パイプライン定義の管理が簡単になります。一度デプロイされた後は、各 CDK Pipelines パイプラインは、自身の定義を更新することができます。これは、パイプライン定義内の分離された SelfMutate ステージを使用して実装されています。このステージはどのデプロイアクションよりも先に実行されるため、パイプラインはソースコードで定義されている最新バージョンを常に実行します。

パイプラインの実行をいつどのようにトリガーするかを管理することにも注意が必要です。CDK Pipelines は、ソースリポジトリのイベントベースのポーリングを利用するようにパイプラインをデフォルトで設定します。これは合理的な挙動で、CI/CD パイプラインには最適ですが、サイロおよびプールパイプラインには望ましくありません。これらのパイプラインがすべてソースリポジトリへのコードコミット時に自動的に実行されると、CI/CD パイプラインはリリースフローを管理できません。この問題に対処するため、サイロおよびプールパイプラインのトリガーに CodeCommitSourceOptions を NONE に設定します。

デプロイメントの更新の制御

SaaS 提供モデルにおいて、テナントへの変更のロールアウト方法を制御することは１つの重要なポイントです。一回のビッグバンですべてのテナントに変更が一度にリリースされると、重大なビジネスリスクが発生する可能性があります。

このリスクは、サイロとプールの構成を組み合わせて利用することで管理できます。テナントを複数のプールに分散し、これらのプールへの変更を徐々にロールアウトすることで、リスクを軽減しましょう。ビジネスニーズやリスクアセスメントに基づいて、特定の顧客を専用のサイロ環境にプロビジョニングすることで、顧客ごとに個別に更新を管理できるようになります。プール内のすべてのテナントは基盤となる同じ更新を同時に取得しますが、機能フラグを使用することで、環境内の特定のテナントに対してのみ新しい機能を選択的に有効化することもできます。

デモソリューションでは、CI/CD パイプラインには「updateDeployments」というカスタムステージが１つだけ含まれています。この CodeBuild アクションは、シンプルな「一度に１つずつの (one-at-a-time)」戦略を実装しています。このコードは意図的にシンプルに記述されており、ここを出発点として、独自のビジネスニーズに基づいてより複雑な独自の戦略を実装することができるようになっています。デフォルトの実装では、すべてのサイロとプールパイプラインがリポジトリの同じ「main」ブランチを追跡します。いつパイプラインを実行してリソースを更新するかを制御することによって、リリースは管理されています。

リリース戦略を設計する際には、計画されたプロセスがリリースと変更を高品質かつ頻繁に実行するのにどのように役立つかを調べましょう。一般的には、本番テナントにデプロイする前に変更を検証するために、複数のテスト環境とステージング環境を介した継続的な自動デプロイを行う CI/CD パイプラインを出発点とします。

さらに、カナリアリリース戦略を利用することで、本番環境のすべてのデプロイメントに変更を展開する前に、潜在的な問題を特定できるかどうかも検討してください。カナリアリリースでは、各変更はまずごく一部の環境にのみデプロイされます。変更の品質に満足したら、その変更を自動または手動で残りの環境にリリースできます。例えば、AWS Step Functions ステートマシンをソリューションと組み合わせることで、リリースフローの制御、検証テストの実行、承認ステップ (手動または自動) の実装、必要に応じたロールバックの実行が可能です。

さらなる考慮事項

この記事の例では、すべてのサイロとプールの環境を単一の AWS アカウントにプロビジョニングしています。ただし、このソリューションは単一のアカウントに限定されず、複数の AWS アカウントに対しても同じように簡単にデプロイできます。大規模に運用する場合は、ワークロードを複数のアカウントに分散することがベストプラクティスです。「複数アカウントを使用した AWS 環境の整理」ホワイトペーパーには、ワークロードを分散するための戦略に関する詳細なガイダンスが記載されています。

AWS Control Tower Landing Zone のような仕組みはデモソリューションとよくマッチします。AWS アカウントを払い出す仕組みと組み合わせることで、新しい AWS アカウントが自動でプロビジョニングされるようになります。これは、アカウントレベルで環境を分離するビジネス要件がある場合や、自動プロビジョニングが必要な場合に便利です。

ソリューションアーキテクチャを複数の個別のコンポーネントに分散させるという Unicorn 社の将来のニーズを満たすためには、中央管理されたデプロイサービスを提供するために、デプロイメントデータベースと関連する Lambda 関数を他のツールチェーンコンポーネントから切り離すことがよいでしょう。スタンドアロンとしてプロビジョニングされ、例えば Amazon Simple Notification Service ベースの通知がデプロイメントシステムのコンポーネントに送られて修正されるような構成の場合、この中央デプロイメントサービスは、複数のコンポーネントのデプロイを管理するために利用できます。

さらに、デプロイのライフサイクルの変化を分析し、テナントが無効化されたり削除された場合に、どのようなアクションを取るべきかを検討する必要があります。環境のアーカイブ/削除プロセスの実装は、この記事では範囲外とします。

クリーンアップ

この記事でデプロイされたすべてのリソースをクリーンアップするには、次の操作を実行してください。

ワークロードアカウントで次の操作を実行
1. us-east-1 リージョンで、CloudFormation スタック “pool-pool1-resources”, “silo-silo1-resources” および CDK ブートストラップスタック “CDKToolkit” を削除する。
2. eu-west-1 リージョンで、CloudFormation スタック “pool-pool2-resources” および CDK ブートストラップスタック “CDKToolkit” を削除する。
ツールチェーンアカウントで次の操作を実行
1. us-east-1 リージョンで、CloudFormation スタック “toolchain”, “pool-pool1-pipeline”, “pool-pool2-pipeline”, “silo-silo1-pipeline” および CDK ブートストラップスタック “CDKToolkit” を削除する。
2. eu-west-1 リージョンで、CloudFormation スタック “pool-pool2-pipeline-support-eu-west-1” および CDK ブートストラップスタック “CDKToolkit” を削除する。
3. S3 バケット “toolchain-*”, “pool-pool1-pipeline-*”, “pool-pool2-pipeline-*”, “silo-silo1-pipeline-*” をクリーンアップして削除する。

まとめ

このソリューションでは、SaaS アプリケーションコンポーネントの自動デプロイファクトリー実装をデモしました。AWS CDK のクロスリージョンおよびクロスアカウント機能と CDK Pipelines の自動再構成デプロイパイプラインを活用して組み合わせることで、SaaS モデルに踏み出した ISV が AWS CDK と CDK Pipelines を利用して、多くの差別化につながらない重労働を軽減する方法について説明しました。さらに、皆さんが書く他のコードと同じように、これらすべてをどのように記述、管理およびリリースできるかを示しました。また、単一の動的プロビジョニングシステムが、サイロとプールモデルの両方が混在する環境でも運用できることを示しました。

現在のステージに関係なく、AWS が SaaS ジャーニーをどのように支援できるのかについて、AWS SaaS Factory プログラムのページから詳細をご覧ください。

翻訳は Partner SA 櫻谷が担当しました。原文はこちらです。

Amazon Web Services ブログ