re:Invent 2024: AWSが提供するSaaS Builder Toolkitの概要と実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerating multi-tenant development with the SaaS Builder Toolkit (SAS406)
この動画では、AWSのSolutions ArchitectのTod Goldingが、SaaS Builder Toolkit (SBT)の概要と実装方法について解説しています。SBTは、Control PlaneとApplication Planeという2つの主要コンポーネントを持ち、CDKを活用して柔軟なSaaSアプリケーションの構築を可能にします。Control Planeはテナント管理やメトリクス分析、課金などの共通機能を提供し、Application PlaneではAmazon EKSやServerlessなど、様々なテクノロジースタックに対応可能です。特筆すべきは、SBTが完成品のプロダクトではなく、必要な部分だけを選んで利用できるツールとして設計されており、独自のControl PlaneやApplication Planeの実装も可能な拡張性の高さです。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
SaaS Builder Toolkit (SBT)の概要と目的
皆様、本日はお集まりいただき、誠にありがとうございます。長い1週間の木曜日にもかかわらず、このように多くの方にご参加いただき、大変感謝しております。スライドにもございます通り、私はAWSのSolutions ArchitectのTod Goldingと申します。私はここ8-9年間、SaaS分野で活動しており、様々な段階にあるお客様やパートナー様と共に、AWSでのSaaSソリューションの構築、提供、運用に携わってまいりました。
これらのソリューションを構築してきた中で、私たちは、SaaS開発者が直面する一般的な課題にどのように対応できるか、またどのようなツールを提供できるかを検討してきました。リファレンスアーキテクチャやライブラリ、その他の仕組みを構築することで、皆様のSaaS開発を加速させる、あるいは少なくとも、スライドでお話しする多くの内容の具体的な実装例を提供することを目指してきました。ここ数年で私たちはAmazon EKSのリファレンスアーキテクチャを構築し、それについて素晴らしいコンテンツを公開してきました。いくつかのSaaSの実装例も作成され、それらは実際に活用された組織にとって非常に価値のあるものとなっています。
私たちは、さらに何かできることはないかと考え始めました。Amazon EKSやServerlessの具体例を超えて、さらに一歩進めることはできないだろうか？より柔軟な組み合わせが可能な形で提供できないだろうか？オールオアナッシングではない形でSaaSのコンポーネントを提供できないだろうか？Amazon EKSのリファレンスアーキテクチャには多くの要素が含まれていますが、そのリファレンスアーキテクチャや一部の機能だけを使いたい場合、簡単に分解して一部だけを使うことは難しい状況でした。
このような考えから、SaaS Builder Toolkit（以下、SBTと呼びます）というコンセプトが生まれました。SBTの全体的なビジョンは、優れたエンジニアリング組織やチームが行うように、より使いやすいツールを提供することでした。私たちは、これらのSaaSの原則のためのツール群を作成し、より細かな単位で利用しやすくすることを目指しました。さらに、サードパーティが拡張機能を追加できる機会も作りたいと考えました。実際に、すでにそのような動きが始まっています。
私たちは、SaaS Builder Toolkitを親しみやすいものにしたいと考えました。開発環境でツールを使用し、変更やカスタマイズが必要になった時に、何千行もの複雑なコードの中をさまよい、何を変更すれば何が壊れるかを悩む必要がないようにしたかったのです。確かに、価値のあるものを作るためには、相当量のコードが必要になりますが、私たちは、人々が変更を加え、部分的に利用できるような設計と構造を心がけました。
本日のセッションの目標は、このツールの概要とスコープをご理解いただくとともに、その内部まで深く掘り下げることです。これは400レベルのセッションですので、この導入部を終えた後は、SBTを使って環境を構築する方法について、多くのコードと実例をお見せします。これにより皆さんは一歩先に進むことができ、セッションの最後にはSBTのダウンロードリンクをお伝えしますので、ご自身で確認していただけます。
Control PlaneとApplication Planeの構造と役割
さて、SBTについて詳しく説明する前に、よく受ける質問について触れておく必要があります。私が多くのプレゼンテーションで言及している「SaaSのブループリントは存在しない」という話についてです。これは事実で、異なるドメイン、テクノロジースタック、環境、チームによって、SaaSソリューションの形や性質が変わってきます。確かにSaaSアプリケーションの構築は非常にコンテキスト依存ですが、ほとんどのアーキテクチャに共通する構成要素やテーマが存在します。繰り返し見られる核となる概念があり、これがSBTの背景にあるものです。私たちは、これらの核となるテーマを構成要素として取り出し、部分的に利用できるように組み合わせ可能なものにできないかと考えました。
ここでControl PlaneとApplication Planeについて示していますが、SaaSではこれらについてよく話題に上ります。Control Planeには、SaaS環境の一部として、水平方向の横断的な懸念事項がすべて含まれており、その内容については後ほど詳しく説明します。Application Planeは、ビジネス機能が存在する場所で、テナント分離やデータパーティショニングなどの典型的な課題に対処する場所です。
これらはしばしばSaaSの両輪と呼ばれています。SaaS Builder Toolkit（SBT）の本質と機能を考えるとき、Control PlaneとApplication Planeという概念が表面に現れるのは、これらが大きな上位レベルの構成要素だからです。どのような場合でも、Control PlaneとApplication Planeが必要だということは分かっています。そこでSBTは、Control PlaneとApplication Planeを提供し、さらにそれらの構成要素間の組み合わせ可能性を提供しようとしています。
では、SBTの主要な部分を高レベルで見てみましょう。箱の中には何が入っているのでしょうか？私たちはこれを3つの異なる領域に分けました。まず、Control Planeがあります。SaaSのControl Planeについて話を始めると、多くの人から「すぐに使えるControl Planeを提供してくれないか」という要望がありました。Control Planeは、その中身の多くが共通しているため、すぐに使えるツールの最適な候補の1つです。多くのソリューションでは、テナント管理、メトリクスと分析、課金が必要です。私たちはSBTで、パッケージ化された使いやすいControl Planeを作ることに力を入れてきました。本番環境用グレードを意図したものではありませんが、必要な要素はすべて揃っています。それを各組織の特性に合わせて本番環境向けのバージョンに作り上げるのは、ユーザーの役割となります。
また、Control Planeには、サードパーティの統合機能も見ることができます。Control Planeには、Billing、Metering、認証など、多くのプロバイダーを持つ可能性のある非常に具体的な概念があります。誰かが異なるプロバイダーをソリューションに導入したいと考える可能性のある領域では、サードパーティが統合できる仕組みを作ろうと試みました。そして、実際にいくつかのサードパーティがこれらのオファリングに参加しているのを見ることができます。ここで特に理解していただきたい概念は、「Bring Your Own Control Plane」という考え方です。現在のSBTのControl Planeは、あくまでも一つのControl Planeであり、唯一のControl Planeになることを意図したものではありません。私たちは既に、異なるテクノロジースタックを使用して、より多くのControl Planeを構築することを検討しています。例えば、現在のControl Planeはサービスとして実装されていますが、コンテナベースのバージョンを実装したり、Identityやその他のコンポーネントにサードパーティ製品を導入したりする可能性もあります。
Application Planeは、Amazon EKSやServerlessなど、これまで構築してきたリファレンスアーキテクチャをすべて取り入れる自然な場所でした。既存のバージョンを取り出し、分解して、Application Plane部分をSBTに組み込み、SBTの基準に準拠するように作り直しました。そして、共通のControl Planeを使用できるようにしました。これは、Application PlaneとControl Planeの全体的な仕組みが機能するかどうか、新しいスタックを導入できるか、そしてそれらの間に適切な境界を作れたかどうかを確認するための実証実験のようなものでした。今日、SBTを入手して、Control PlaneとAmazon EKSリファレンスアーキテクチャをApplication Planeとして使用したい場合、これら両方を出発点として入手することができます。
また、実験の一環として、以前にはなかったAmazon ECSリファレンスアーキテクチャを新たに導入しました。新しいApplication Planeの導入がどれほど容易かをテストしたかったのですが、そのチームはわずか2-3週間で新しいAmazon ECS Application Planeの例を導入しました。これは、Control Planeを分離したことで、これらのリファレンスアーキテクチャを作成する負担が大幅に軽減されたことを証明しています。サードパーティ統合と「Bring Your Own Application Plane」の概念は、ここでは自明のはずです。Application Planeは、多くの種類のテクノロジースタックやソリューションのための場所なのです。私たちは最初のきっかけとしていくつかを用意しましたが、今後さらに増えていくことを期待しています。
一番下には、LibrariesとUtilitiesがあります。ここには、私たちが構築してきた多くのものが含まれています。Token Vending Machineは、テナント分離を支援するために構築した非常に人気のあるライブラリです。このような概念を取り上げ、パッケージ化して、このライブラリ領域に配置しました。私たちのものを使用するにせよ、独自のものを構築するにせよ、Application Planeを構築する際に、テナント分離やToken Vending Machineを使用したい場合、環境に簡単に取り込んで適用できる方法を提供しています。LibrariesとUtilities領域は、優れたApplication Planeを構築しやすくするためのツールを提供することが本当の目的なので、今後さらに大きく成長すると予想しています。
さて、これをある程度組み合わせ可能にし、必要な部分だけを取り出して使えるようにしたいと考えていたため、緩やかな結合の体験にしたいと考えていました。しかし、Control PlaneとPlaneを持つ場合、意図的にそれらの間で相互作用が発生することを認識する必要があります。そのため、これはおそらく、私たちが動作方法について非常に明確な指示を出している数少ない場所の1つです。なぜなら、このレベルで明確な指示を出す必要があったからです。そこで、ここにインターフェースを定義しました。このインターフェースを機能させる技術について、これから見ていきましょう。
SBTのControl Planeの詳細と実装
基本的に、Control PlaneとApplication Plane間でやり取りされる共通のイベントを定義しました。オンボーディングはApplication Planeにイベントを送信してオンボーディングを完了させ、メトリクスや分析データはApplication PlaneからControl Planeに戻って集計されます。また、この統合に独自のイベントやプロトコルを追加できるよう、十分な余地を残しています。ただし、これを機能させるためには、どこかでこの統合を実装する必要があります。
Control Plane内では、課金やメータリング、その他の領域について、私たちが規定のControl Planeを提供し、それらの実装を提供できると考えていました。しかし、ユーザーが独自のソリューションを持ち込みたい場合や、パートナーが自社のサービスを提供したい場合があることも認識しています。ここでご覧いただけるように、Control Planeの拡張性モデルとこれらのインターフェースを活用して、これを実現しています。そしてライブラリの領域では、ファーストパーティまたはサードパーティのライブラリやツールをこの環境に取り込むことができます。
ただし、スイッチを入れるだけで何でも動くような究極のプラグ体験を作ったとは言いたくありません。これらのインターフェースを機能させ、インターフェースに準拠するコードを書く必要があります。私たちは拡張可能な環境を目指していますが、その拡張性の一部は規約によっても実現されています。どこで何が起こるかをしっかりと定義していますが、それを機能させるために環境を調整する必要があるかもしれません。ですので、すべてが自己完結していて、スイッチを切り替えるだけで機能のオン・オフができるというような印象は持っていただきたくありません。
ここでSBTについての重要なポイントは、SBTがCDKを重視した体験だということです。インフラストラクチャのプロビジョニングと設定を記述するために、CDKのパワー、強み、表現力を大いに活用しています。Application PlaneとControl Planeの両側で、オンボーディングや初期セットアップなど、環境の設定やプロビジョニングに関する作業が多いためです。CDKは完全な表現力を持つ言語で、TypeScriptで書かれていますが多くの言語をサポートしており、その根幹にCDK Constructという概念があるため、とても優れています。
CDK Constructは、CDKライブラリが知っている最も抽象的な基本オブジェクトです。私たちが行ったのは、基本的にこのConstructを継承して、SBT Constructsという一連のConstructライブラリを作成したことです。ここでご覧いただけるように、Control Plane Constructがあり、そのConstructの中にはControl Planeを構築・プロビジョニング・設定するためのすべての要素が含まれています。Tenant Management ConstructやUser Management Constructなど、さまざまなConstructを使用しています。動作を変更したり調整したりする方法を検討する際には、単に独自のTenant Management Constructを作成して組み込むだけでよいのです。
ここでもう1つ重要なポイントは、SBTはツールであってプロダクトではないということです。私たちは、ダウンロードしてインストーラーを実行し、UIを使ってSaaSアプリケーションや環境をどのように構築したいかを指定するような、ポイント＆クリック式の体験を作ろうとしているわけではありません。これは、CDKを通じて望む体験を組み立てていく、エディター上での作業なのです。そういう意味で、SBTはビルダーやCDKの扱い方、これらのコーディングの概念を理解している人向けに設計されています。これらの構造やプログラミング言語の構文について理解が深まれば深まるほど、より使いやすくなっていくでしょう。
では、SBTを使ってSaaSソリューションを構築する様子をご覧いただきましょう。まず最初に、SaaS Builder Toolkitをインストールします。多くの方がご存じかと思いますが、npmを使ってパッケージとしてインストールできます。基本的に、SBTを環境にインストールするだけです。
エディターを開いたら、どのConstructを使用し、何を実現したいかを決めていきます。これが私たちが提供しているConstructの全体像です。最もシンプルな方法で、すぐに使える機能だけを利用することもできますし、より細かいレベルで独自のカスタマイズを加えることもできます。
この例では、最もシンプルなモデルを選びました。 例えば、Control Planeを作成して起動したい場合、これは擬似コードですが、まずToolkitからControl Planeをインポートして、エディター内で参照できるようにします。次に、Stackを宣言します。CDKに馴染みのある方はご存知だと思いますが、インフラストラクチャをプロビジョニングまたは設定する際、Cloud Formationスタックと同様に、周りを囲む構造体をStackと呼びます。 このStackの中で、Control Planeをどのように構成したいかを指定します。ここで、App Planeのコンストラクトやライブラリ、その他必要なものを全て取り込むことができます。
Application Planeの構造とAmazon EKSアーキテクチャの実装例
エディターで必要な要素を全て設定し終えたら、 CDK deployを使用して、これらのConstructと設定をデプロイし、環境をセットアップするように指示するだけです。素晴らしいのは、CDKの変更処理機能も活用できることです。差分を処理し、変更を適用してくれます。私たちの考えでは、これは本当に優れたメカニズムだと言えます。
SBTの全体的な体験と、私たちが達成しようとしていることについては、これくらいにしましょう。では実際にControl Planeの中身を見ていきましょう。その内部構造がどうなっているのか、見ていきましょう。 まずは最もシンプルなモデルから始めます。ここではControl Planeの設定をほとんど行わず、単にControl Planeを宣言して、デフォルトの動作のほとんどをそのまま使用し、どうなるか見てみましょう。
ここで見ていくと、最初に環境でnpm installを既に実行済みなので、上部でSBTをインポートしているのが分かります。次にControl Plane Stackを作成します。何らかのStackが必要で、これは単なるCDK Constructです。Control Planeのセットアップの一部として、Control Plane自体にはシステム管理者のための認証とIDが必要で、それにはプロバイダーが必要です。この場合、Amazon Cognitoを使用したデフォルトの実装を提供しています。このCognito認証を環境の一部としてセットアップする必要があります。ここでセットアップが必要な理由は、Control Planeをプロビジョニングする際の初期システム管理者ユーザーを指定する必要があるからです。
そして、 ここで新しいSBT Control Planeを作成します。ここで見えるSBT.ControlPlaneは、すぐに使える状態で提供されているデフォルト実装を含むControl Plane Constructで、このライブラリから取り出したものです。もしすぐに使える実装をそのまま使いたい場合は、このような形になります。 認証の一部として、管理者ユーザーのメールアドレスを提供するだけです。これが私にとって最もシンプルな方法です。ダウンロードして「既存のControl Planeをそのまま使わせて」と言うだけで、このStackをCDK deployすれば、動作するControl Planeが手に入ります。
このControl Plane Constructの内部では実際に何が起きているのでしょうか？何を作成し、何を設定しているのでしょうか？先ほど、Cognitoのセットアップについて話しました。 その中にはTenant Management Service Constructがあります。すべてのControl Planeには、テナントの状態やテナントポリシー、その他のテナント属性を管理する場所が必要です。そのため、テーブルを作成し、その他の要素をセットアップするConstructが用意されています。システム管理者のためのUser Managementも必要で、これらは初期作成時だけでなく、 これらのサービスと対話するためのマイクロサービスやAPIなども作成します。例えば、Control Planeの上に管理コンソールやCLIがある場合、このUser Management Systemのインターフェースを使用して、新しいユーザーの作成やユーザー管理などを行います。Tenant Management Serviceも同様で、作成時だけでなく、テナントの状態を確認して何かを行いたい場合もあります。そのため、それを機能させるためのAPIとサービスが全体的に用意されています。
Control Plane API自体も作成する必要があり、API Gatewayやその他の必要な要素をセットアップします。Event Manager Constructもあり、 このEvent Manager Constructは、先ほど説明したControl PlaneとApplication Plane間の通信を可能にするためのものです。前のスライドで見たコードはほとんど何もしていないように見えましたが、実際には内部でかなり多くのことが行われています。そこで、その一部を取り出して、詳しく見てみましょう。
Control Planeの仕組みについて、その一部を詳しく見ていきましょう。Control Planeの中からTenant Managementの構成要素を取り出してみました。Control Planeの中を見ていくと、このTenant Management構成要素を更新し、テナント管理環境を初期化しているのが分かります。その過程で、すべての状態を保存するためのDynamoDBテーブルを作成するなどの処理を行います。このように、構成要素が階層的にこの仕組みの中に組み込まれているのが分かります。
DynamoDBテーブルを作成するための生のコマンドを直接実行するのではなく、IAMの設定やテーブルの構成など、必要なすべての要素を含むTenant Management Tableというラッパーを作成しました。もし将来、DynamoDBを使用したくない、あるいは別の方法を採用したいと考えた場合、このTenant Management Table構成要素を独自のものに置き換えて、好きなように実装することができます。もちろん、その変更が他の部分にどのような影響を与えるかは検討する必要がありますが、動作を変更するためのポイントがどこにあるのかをご理解いただけると思います。
また、このServerless環境ではTenant Management Lambdaも確認できます。テナント管理に関連するさまざまな操作をサポートする一連のLambda関数として、Tenant Management Microserviceを起動しています。このTenant Management Lambda呼び出しから返されるLambda変数は、HTTP統合のセットアップ時に参照されます。これは、API Gatewayで関数へのルートを設定している部分です。Lambda関数をセットアップする際、下の方にあるこのTenant Management関数が、返されたLambda関数になります。
ここで少し戻って説明させていただきます。Lambda.TenantManagementFuncは、HTTP統合のセットアップ時に参照されますが、実際にはここで取り込まれているコードを参照しており、そのコードは私の環境内にある全てのPythonコードが置かれている場所を指しています。これが、様々なLambda関数の実装となっています。この仕組みは、変更したい場合でも比較的簡単に介入できると考えていますが、同時にこの仕組み全体のアプローチやデザインモデルの特徴もご理解いただけると思います。
もう一つ別の部分をお見せしたいと思います。 Control Planeを作成して稼働させることに加えて、オンボーディングイベントを処理する際の動作があります。これは全て、Control Plane内に作成されるRegistration Serviceによって管理されています。Registration Serviceは基本的に、テナントをシステムにオンボードするために呼び出す必要のある様々なサービスのオーケストレーションを処理します。また、オンボーディング処理の一環として、Application Planeが必要とする処理を実行できるよう、送信すべきイベントのオーケストレーションも行います。
また、登録の状態と進捗を追跡するテーブルも備えています。テナントがオンボーディングを開始し、様々なコンポーネントを作成するために呼び出しを行う際、このRegistrationsテーブルが更新されます。RegistrationsへのAPIを通じて、CLIやコンソールから登録の進捗状況を確認したり、進行が止まっているように見える場合は現在の状態を調査したりすることができます。ここでは、登録に一意の識別子を割り当て、環境に入ってきたメッセージのボディから必要なデータを取得します。
ご覧の通り、状態を保存するテーブルがあり、これらの項目をテーブルに格納して、この登録の現在の状態を保持しています。その後、先ほど説明したTenant Management Serviceにメッセージを送信して、システム内でそのテナントを作成するよう指示します。テナントの最初のエントリを作成し、ユーザーやその他の必要な要素をセットアップしているわけです。その処理が完了すると、テナントの登録情報が更新され、テナントIDや作成時に返された情報が反映されます。
前のスライドに収まりきらなかった最後の部分として、アプリケーションプレーン側でテナントを作成するためのコマンドも実行します。ここでControl Plane Eventを作成しているのがわかります。このControl Plane Eventを作成する際、オンボーディング中のテナントに関する情報（プラン、テナント情報、オンボーディング対象のユーザー）をイベントに設定し、新しいテナントのオンボーディングを行っているというイベントの種類をアプリケーションプレーンに伝えています。
このイベントが発行され、処理が戻ってくると、成功したか失敗したかを示すデータを受け取ります。これらが全て連携されると、アプリケーションプレーンでのテナントのプロビジョニングが成功したかどうかで登録情報が更新されます。動作する部分が多すぎて、もしかしたら必要以上に詳しい説明になってしまったかもしれませんが、アプリケーションプレーンとコントロールプレーンの間でどのようなやり取りが行われ、内部でどのように実装されているのかをイメージしていただければと思います。
SBTのカスタマイズと拡張性
さて、コントロールプレーンについて説明する最後の部分です。先ほど言及したインターフェースについてです。課金やメータリングなど、全てのコンポーネントがあります。それぞれのコンポーネントで、コントロールプレーンに必要な基本的な操作をサポートできるように、インターフェースの抽象化を試みています。コントロールプレーンが必要とする以上の機能を持っている場合もありますが、私たちはコントロールプレーンとの統合に必要と思われる基本的な操作を導入しようとしているだけです。ここにはシステム管理者向けの認証機能があり、その実装としてAmazon Cognitoを使用しています。ここにはOktaやPing、その他の実装を組み込むこともできます。課金面では、この仕組みが実際に機能するかどうかを確認するために、Moesifが統合を実装してくれました。また、メータリングについては、Amberfloが完全なメータリングソリューションを実装してくれました。これらのインターフェースは適切な拡張ポイントを提供していると感じていますが、今後、より多くの機能や能力をサポートするためにどのように進化させていくかを考えていく必要があります。
これがControl Planeの内部の様子です。 もっと詳しく見ていくこともできますが、App Plane側で何が起きているのかについても説明したいと思います。App Planeは少し異なる特徴を持っているからです。先ほど申し上げたように、Control Planeにあるこれらの紫色のボックスは、ほとんどのControl Planeで何らかの形で見られるものです。一方、右側のApp Planeに表示されるものは、何でも構いません。どのようなテックスタックを使用しているのか、フルスタック方式でデプロイされているのか、フルスタックプールなのか、それともその変形なのか。ルーティングに影響を与えるティア戦略やパラメータはどうなっているのか。Amazon EKSでテナントごとにNamespaceを分けているのか、Serverlessの場合は個別の関数なのか。デプロイメントは全く異なる形を取る可能性があります。
App Planeに制約を設けたくはありませんでしたが、同時に、App Planeを構築する場合、私たちが提供するものを使用しなくても独自のものを構築できるように、少しでもスタートを切りやすくできないかと考えました。App Planeを構築する際の一般的な要素を特定し、それを簡単にするためのツール、ライブラリ、メカニズムを提供できないかと考えたのです。 SBT以前から、すべてのリファレンスアーキテクチャを構築する際に、私たちは常にベースラインアプリケーションプレーンインフラストラクチャと呼ぶものの概念を持っていました。これは、テナントが現れる前に、VPCの作成、クラスターの作成、Gatewayの作成、そして場合によってはその他のインフラストラクチャの作成が必要だということを意味します。完全にプールされた環境では、ベースラインの作成の一部として、必要なサービスを起動するか、最初のテナントのオンボーディングまで待つかを選択できます。基本的に、私たちのApp Planeの実装のほぼすべてがこのベースラインConstructを持っており、ConstructというのはAWS CDKがこれを駆動しているからです。
これが完了すると、ベースライン環境が得られ、もう一つの共通部分があります。 では、このような環境にテナントを導入するとはどういうことでしょうか？ これは、テナントごとのConstructがどこにあるか、あるいはないかによって異なります。すべてがプールされていて、テナントごとにやることが少ない場合、これは非常にシンプルなプロセスになるかもしれません。テナントごとにサイロ化された専用インフラストラクチャがある場合、このモデルでは、オンボーディング時に各テナントに何を作成する必要があるかを判断するためのより複雑な処理が必要になります。このモデルでは、テナントプロビジョニングConstructも用意されており、このベースライン環境にテナントを導入するために必要なことを実行します。このConstructを通じて、テナントごとに必要なものの作成をオーケストレーションします。私たちはこれに関するライブラリとヘルパーを作成し、配線とイベント処理を支援するための要素もすべて作成しました。オンボーディングイベントを受け取ると、必要なすべての処理をトリガーし、そしてアプリケーションプレーンの具体的な部分を組み込めるようにしています。
もちろん、これらすべてを自分で書きたい、独自のベースラインコードを書きたい、テナントをプロビジョニングするコードをどのようにしたいか自分で決めたいと考えることもできます。App Planeはどのような実装でも受け入れます。単に、私たちが用意した部品や規約を活用して、それをより簡単にしたいかどうかの問題です。
このモデルを持っていて、これをセットアップした状態で、例えばフルスタックサイロモデルを採用し、各テナントが独自の専用モデル環境を持つとします。Control Planeとオンボーディングを通じたテナントのプロビジョニングConstructは、必要なすべてのリソースをプロビジョニングし、すべてのルーティングを設定し、そのテナントを環境に導入するために必要なことを行います。そしてこれを繰り返すだけです。このスライドのポイントは、このApp Planeが、あなたが望むものを自由に構築できる場であっても、SBTが提供する標準機能を確認して、その領域でのスタートを切りやすくすることを検討すべきだということです。
それでは、ベースライン環境の導入やプロビジョニング、そしてテナントのプロビジョニングという抽象的な概念を、より具体的なものに落とし込んでみましょう。まずはApplication PlaneとしてAmazon EKSアーキテクチャを実装した場合の基本的な構成を見ていきましょう。Control Planeを導入し、これまで説明してきた手順でControl Planeを稼働させます。ベースライン環境のプロビジョニングとは、基本的に作成するすべてのリソースを定義することです。つまり、テナントを受け入れる準備が整ったAmazon EKS環境の枠組みを用意するということです。
オンボーディングイベントを受け取ると、オンボーディングプロセスがプロビジョニングスクリプトを実行し、テナント用のNamespaceを作成して、必要なサービスを起動します。以降のテナントも同様の方法で導入されます。最終的に、右側にはControl PlaneからのオンボーディングイベントをすべてサポートするApplication Planeが構築されることになります。
このCDKコードの内部を見てみると、実はControl Planeでうまく機能した方法は、Application Plane側でも同様にうまく機能するだろうという考えに基づいています。ここでは、先ほど見たAmazon EKSクラスターの作成や、必要なリソースの作成、テナントのプロビジョニングとセットアップに必要なApplication Planeスタックの作成などが表現されています。このApplication Planeスタック全体が、個々のテナントをプロビジョニングする際に使用するものです。その後、これら全体のAPIをセットアップし、各種設定を行います。基本的に、これは開発者が自分で書けるCDKコードですが、私たちはControl Plane側で見たコードと同じように、パッケージ化して提供しているだけなので、一貫した使用感が得られます。
では、このAmazon EKSアーキテクチャで実際にプロビジョニングされるものと、作成されるものを見ていきましょう。ここではテナントごとにサブドメインを使用し、Ingress Controllerを通じてルーティングを行い、個々のテナント用のNamespaceをセットアップしています。これは私たちが選択した方法の一つです。各Namespaceではすべてのルートをセットアップする必要があります。オーダーテーブルはテナントごとに分離されているため、テナントごとに作成する必要があります。一方、プロダクトテーブルは作成後、すべてのテナントで共有されます。
ここで重要なのは、テナントごとのプロビジョニングを行うための実装方法と、独自の実装を行う際にSBTをどのように活用できるかを理解することです。現在の実装がどのように機能しているか、概念的に見ていきましょう。オンボーディングリクエストを受け取ると、Application Planeがオンボーディングイベントを受信し、先ほど説明したApplication Planeスタックが動作します。このApplication Planeスタックは、オンボーディング時にテナントごとに必要なリソースを作成するために必要なすべての処理を調整するConstructとして作成されています。
Tenant Lifecycle Managementの構造があり、AWS CodeBuildのジョブが起動します。これは基本的に、皆さんの代わりに重要な作業を行うということです。イベントを取得し、ジョブを作成し、そしてプロビジョニングの内容に関係なく、そのライフサイクルを管理します。その後、このプロビジョニングスクリプトを実行します。
アプリケーションプレーンを、お持ちのものとは全く異なる形にしたい場合でも、それは可能です。実際、私のアプリケーションプレーンは、皆さんのものとは全く異なる可能性があります。ここで止めて、このプロビジョニングスクリプトに独自のコードを書いて、何をすべきかを指示することもできます。ただし、少なくともイベント処理、ジョブの作成、起動と実行、そしてコントロールプレーンへのメッセージ送信は、すべて配管済みの状態で提供されます。
この場合、EKSの例で何をしているかわかっているので、先ほど見たサブドメインをルーティング処理の一部として設定します。この過程でTenantアイデンティティを設定し、Namespaceをプロビジョニングし、Namespaceとサービスをセットアップするためのマニフェストやその他のコンポーネントを設定し、Service Accountをプロビジョニングします。この実行が完了してコントロールプレーンにメッセージを送り返すと、Tenantに必要なすべてのリソースが作成されているはずです。このモデルの良いところは、これらの一部を変更したい場合、見つけやすく、場所を特定しやすく、どこでどのように経験を調整したいかを決められるほど粒度が細かいということです。
CDKの視点からこれを見ると、先ほど説明したジョブがこちらです。このジョブを起動して、基本的にインフラストラクチャのプロビジョニングの実行とオーケストレーションを管理します。前のスライドで言及したプロビジョニングスクリプトへの参照がここにあります。そのプロビジョニングスクリプトを実行すると、処理が開始されます。これは実際の処理の一部で、このファイルはもっと大きいものです。ここでは、環境での認証のセットアップ、Cognitoやその他の設定を行っているのが分かります。また、EKSを使用しているため、サービスやそのフットプリント、起動方法を記述するマニフェストも確認できます。さらに、この過程の一部としてService Accountも設定する必要があるため、それも行っています。
これは皆さんが日々書いているようなコードです。SBTを全く見なくても、このようなコードの何らかのバージョンを書くことになります。ただし理想的には、私たちから入手した場合、ニーズに合わせてカスタマイズや設定する方法をより素早く理解できるような規約が見られるはずです。アプリケーションプレーンのもう一つの重要な点で見落とされがちなのは、コントロールプレーンとアプリケーションプレーンの間に双方向の統合があるということです。アプリケーションプレーンからコントロールプレーンにイベントを送り返す必要があります - オンボーディングの成功や失敗、請求書生成に役立つ課金単位や課金情報、メタリングデータ、ログデータ、メトリクスなどです。これらのメッセージをEventBridgeを通じて公開・送信し、コントロールプレーンと簡単に統合できるようにサポートしています。先ほどお見せしたMoesifのような既製の課金サービスを使用している場合、これらのイベントは自動的に取り込まれ、課金機能がすぐに使える状態になります。
SBTの柔軟な活用方法と今後の展望
では、このエクスペリエンスをどのようにカスタマイズすればよいのでしょうか？カスタマイズとは具体的に何を意味するのでしょうか？ これは、ライブラリがあってそこに拡張機能として自分のコードを追加するという従来の拡張モデルとは異なります。むしろ、コード全体が対象となり、インターフェースを通じて拡張できる部分もあれば、実際にコードを修正して拡張する必要がある部分もあります。これは、製品ではなくツールとしての私たちの考え方に沿っています。 SBTには核となる部分があり、新機能を活用し続けたい場合は、意図された実装から外れることが後方互換性に影響を与える可能性を考慮する必要があります。
例えば、独自のControl Planeを作成し、独自のTenant Management Serviceを実装したいとします。ここでは、 標準で提供されているものではなく、独自のControl Planeを用意しています。 ここで私が構築したいのは、デフォルトのTenant Management Serviceではなく、独自のTenant Management Serviceです。また、完全に新しいTenant Serviceを実装するのではなく、既存のTenant Management Constructを継承して、変更したい属性だけをオーバーライドする方法についても説明しました。これは、完全な置き換えか、現在の動作の一部修正かによって選択が変わってきます。
また、すでにTenant Configuration Serviceは存在していますが、このControl Planeを立ち上げる際に、Tenant Configuration Serviceの動作の一部を追加・変更することもできます。さらに、User Management Serviceについては、既存のものをそのまま使用します。ユーザーの管理や作成方法について、現状のままで十分だと考えているからです。スライドには収まりきれない要素がまだたくさんありますが、ポイントは、独自のコードを導入し、独自のConstructを作成する場所を選択し、既存のConstructの動作を設定変更によって少し変更し、また一部はそのままの状態で使用するという選択ができるということです。これらすべてを独自のControl Planeスタックとして構成し、デプロイすると、そのフレーバーのスタックがControl Planeとして実現されます。
このように、Application PlaneをControl Planeと統合してライフサイクル全体を管理しやすくするためのConstructsについて説明してきました。このパズルの各ピースは、コードを置き換えたり変更したりできるポイントを表しています。例えば、標準のServerless SaaSアプリケーションの実装やAmazon EKSソリューションは気に入っているけれど、実装のある側面が好ましくない、あるいはアプリケーションが異なる動作を必要とする場合、Provisioningスクリプトの一部を変更するだけで望む動作を実現できます。
もう一つの側面は、SBT環境自体の拡張です。 拡張の方法には複数のアプローチがあります。一つは、これらのインターフェースを通じた拡張です。独自のBilling Constructや独自のMetering Constructを導入したい場合は、自由に行うことができます。 さらに、独自の拡張性に興味がある場合、独自のインターフェースを導入することも可能です。そのようなケースは多くないかもしれませんが、これも確実にカスタマイズ可能な領域の一つです。
独自のControl Planeを作成することもできます。Control Plane全体を置き換えて、コンテナ化されたバージョンを構築し、必要とする異なるソリューションを使用することもできます。ただし、Application Planeとの統合のために存在するインターフェースモデルには準拠します。既存のApplication Planeの1つを使用するわけです。これも拡張性の一形態だと私は考えています。なぜなら、Control PlaneとApplication Plane間のインターフェースを活用して、Control Planeを全体的な体験に適合させているからです。
もう1つの方法は、独自のApplication Planeを持ち込むことです。ほとんどの場合、開発者は私たちが提供する既存のApplication Planeをカスタマイズするか、完全に独自のものをゼロから作成するでしょう。このモデルのおかげで、私たちのチームでもSBTにより多くのApplication Planeを素早く追加できるようになるでしょう。テナントごとのアカウント、テナントごとのVPCなど、私たちは以前からそういった方式について話してきましたが、実際に使える具体的な例があまりありませんでした。
Application Plane内でこのモデルを実装し、既存のControl Planeの優れた機能を取り入れることで、コードをそれほど書かなくても、エンドツーエンドのソリューションを提供できます。実は月曜日にCell-basedアーキテクチャとその新しい使用方法について講演したのですが、このCell-basedアーキテクチャを使用したApplication Planeを構築することは十分可能だと考えています。そして最後に「SaaS Anywhere」という概念があります。これは、Application Planeにリモートリソースを持つ場合はどうなるかという考え方です。例えば、Application Planeの大部分はSaaSプロバイダーのアカウントで実行されるが、ストレージは顧客のアカウントで実行する必要がある場合などです。特に生成AIの分野では、このようなケースが増えています。
私が管理するApplication Planeで実行される部分と、リモートで実行されるリソースとやり取りする部分を持つApplication Planeを、独自に構築することもできます。これらはすべてSBTなしでも実現可能です。しかし、重要なポイントは、環境全体を一から作り直す必要なく、これらの新しいモデルに取り組めるということです。URLを共有すると約束しましたので、興味のある方はぜひご覧ください。現在、多くのパートナーが開発に取り組んでおり、企業のモダナイゼーションや変革を支援している人々が、これを出発点として活用しています。この先の発展は、より大きな拡張性をどのように、どこにもたらすかにかかっていると考えています。
ただし、常に心がけているのは、あまりに複雑にせず、すぐに使い始められ、それぞれの環境に適した作業ができるようにすることです。
SBTの利用方法と今後の発展に向けて
ここまでの話から、SBTの使い方は一通りではないということが明確にわかったと思います。全ユーザーがSBTを導入し、Control Planeをインストールし、Application Planeを選んで導入し、実装時に必要なライブラリを取り込む...といった画一的な流れではありません。むしろ、Control Planeだけを使用したり、Application Planeだけを使用したり、独自のControl Planeと組み合わせたり、特定のライブラリだけを使用したりと、必要に応じて選択できることこそが、非常に価値のある点なのです。
多くの方々がControl Planeだけの利用を求めており、それが最適な出発点となるケースも多いでしょう。Control PlaneとApplication Planeを同じチームが構築する場合でも、Control Planeは別製品として扱うべきだと私たちは多くの組織にアドバイスしています。Control PlaneとApplication Planeで何を行うか、そしてソリューションのライフサイクルを通じてそれぞれをどのように改訂・更新していくかには、重要な違いがあるからです。私たちが協力している多くの組織にとって、この2つの間に境界を設けることは非常に価値があります。Control PlaneとApplication Planeの間のインターフェースを設けることで、これらを異なるコンポーネントとして考えるようになり、そのような行動を促進することになるのです。
すでに強調した点ですが、CDKの経験からも明らかなように、どのConstructsを使用するか、それらをどのように設定するか、その他の要素をどうするかを考えながら、エディタベースで作業を進めていく - それこそがSBTの力であり価値なのです。今後の成熟に伴い、より多くの機能がCLI主導になっていくでしょう。私たちは、すべてにUIを設けて、インストールしてクリックするだけの完成品のように扱うことは避けていく方針です。
CDKが好きでない方は、おそらくSaaS Builder Toolkitも好きにはならないでしょう。Terraformバージョンを作ることも可能だと思います - TerraformバージョンとCDKバージョンの両方を用意できれば素晴らしいですね。それはかなり大変な作業になりますが、どちらが優れているというよりも、私たちはこのアプローチの一つに全力を注ぐ必要があったのです。SBTの良さの多くは、CDKで実現できることに組み込まれています。個人的には、SBTが独立したCDKライブラリとして存在することを強く望んでいます。なぜなら、それがSBTの本質の多くを表しているからです。ただし、SBTはそれ以上のものです。より広範なSaaSアプリケーションで達成しようとしている全体的な目標を理解する必要があるからです。
そして、アプリケーションに最適なコンポーネントを選んで組み合わせてください。 最後に、このプロジェクトの成長に協力してください。どのような方向に進むべきか、フィードバックをいただき、必要であれば私にメールを送ってください。このプレゼンテーションの最後に連絡先をお伝えします。ぜひ実験的に使ってみることをお勧めします。今年のre:Inventでは、SBTのワークショップが開催され、セットアップから、デプロイ、Control Planeの作成など、基本的なハンズオン作業を体験できる内容でした。
本日はご参加いただき、誠にありがとうございます。コードの部分については、画面上の大量のコードを見て目が疲れてしまうような状況は避けたかったので、駆け足で説明させていただきました。しかし、この裏側で何が起きているのかを少し掘り下げてご説明することで、私たちが目指していることと、皆様が帰宅後にさらに探求される際にどのように活用できるかについて、より良く理解していただけたのではないかと思います。それ以外については、残りのre:Inventを存分にお楽しみいただければと思います。本日はご参加いただき、ありがとうございました。よい一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion