こんにちは！岡本です。
ハンズオンイベントに参加してきましたのでレポート記事と学んだことを少し紹介させていただきます。
【はじめに：この記事は誰に向けたもの？】
この記事は、どんなイベントだったんだろう？という方から、AWSを活用したSaaS開発に興味があるエンジニアや、マルチテナント構成を検討している開発者・アーキテクトの方に向けて書いています。
この記事だけで設計をすべて学べるわけではないですがキャッチアップの取っ掛かりになれば幸いです。
イベントの雰囲気だけ気になる！という方は適宜読み飛ばしてもらえればと思います。
今回は、JAWS-UG京都支部 × KyotoLT共催のハンズオンイベントに参加し、AWS CDKを使ったアプリケーション構築や、SaaS Builder Toolkit for AWSの実践的な活用について学んできました。
本記事では、その内容をセクションごとに整理して紹介します。とくに「SaaSの構築・運用をどこから始めれば良いかわからない」という方にとって、SBTは非常に有用性のあるツールキットです。
【イベント参加のきっかけ - 概要】
昨年10月に参加したAWS GameDayの懇親会で名刺交換させていただいた
本イベントの登壇者でもある方からお声がけいただきました。
内容は
- AWS CDKハンズオン
- SaaS Builder Toolkit for AWSの解説
- AWS CDKで実際にSaaSシステムを構築
- 懇親会（技術書争奪ジャンケン大会あり！）
でした。
とても密度の高い内容で、特にSaaSをこれから設計・構築する方にとって、多くの学びがあるイベントでした。
また、ハンズオン用として$25分のAWSクレジットも配布されました。ありがたい！
【1. AWS CDKハンズオン】
AWS CDKを使ってアプリケーションをデプロイしてみようというものでした。
ハンズオンではCreate/Readができるシンプルなサーバーレスアプリケーションのデプロイでした。
SageMaker StudioでCode Editorを作成してアプリケーションのgitをクローンして cdk deployするだけ！
これで上図のアプリケーションがデプロイされました。
動作確認は作成されたAPI GatewayのAPIキーを使ってcurlでDBへのデータ投入と参照を行いました。
【2. SaaS Builder Toolkit for AWSの解説】
↑の記事の著者でもあるAWS 櫻谷さんが解説してくださいました。
今回のイベントの内容を網羅しておりこの記事でも学ぶことができます。
さて、AWS CDKを使ってアプリケーションを構築する流れを体験した後は、「本格的なSaaS構築では何が必要か？」という次のステップへ移りました。
ここで紹介されたのが、SaaS Builder Toolkit for AWS（SBT）です。
SBTは、AWS上でSaaSアーキテクチャを設計・運用するための開発者向けツールキットで、特に以下のような方におすすめです：
- AWS上でSaaSサービスを構築したいが、どこから手をつけていいか分からない
- マルチテナント対応をしっかり設計したい
- アーキテクチャやセキュリティのベストプラクティスに則った構成をしたい
GitHub：SaaS Builder Toolkit for AWS
次のセクションである「AWS CDKで実際にSaaSシステムを構築」ハンズオンでもこのSBTが使用されています。
SBTの特徴と構成要素
SBTはSaaSに求められる多くの機能をあらかじめテンプレート化しており、以下のような特徴を備えています
-
コントロールプレーン機能のテンプレート
- テナント管理、オンボーディング、ユーザー認証、課金処理など、SaaSに共通する機能を簡単に導入可能。
-
AWSベストプラクティスを反映
- セキュリティやスケーラビリティに関する設計がAWSの公式ガイドラインに準拠。
-
マルチテナント対応
- テナントごとのデータ分離、権限制御が考慮された設計が可能。
-
再利用可能なCDKスタック
- SaaS特有のインフラ構成がCDKベースで提供され、開発者はゼロから構築する手間を大幅に削減できます。
認証・認可の設計パターン
SaaSにおいて「誰がどのテナントにアクセスできるか」という認可設計は非常に重要です。SBTではこの点もサポートしています。
-
JWT（JSON Web Token）によるアクセス制御
- SaaS環境では、ユーザーやテナントに紐づく情報（ID・ロール・アクセススコープなど）を安全に伝達するために JWT が用いられます。API にアクセスするたびにこのトークンが使われ、"テナントごとのアクセス制御"が可能になります。
-
TVM（Token Vending Machine）
- TVMは、認証済みのユーザーに対して"AWSリソースへの一時的なアクセス権限"を発行するコンポーネントです。たとえば、ユーザーが自分のテナント用のS3バケットにアクセスする際、TVMがSTSトークンを発行することで、安全にかつ最小権限でアクセスできるようになります。
-
STS（AWS Security Token Service）との連携
- TVM が内部で利用している仕組みが"STSトークン"です。
STSトークンは、"IAMロールなどの権限を一時的に付与するトークン"で、有効期限付きで安全なアクセスを実現します。
たとえば「あるテナントのユーザーが自分のデータだけにアクセスする」ような場面では、TVM が STS を使って一時的なクレデンシャル（アクセスキー、シークレット、セッショントークン）を発行し、そのユーザーにだけ限定的なアクセスを許可します。
- TVM が内部で利用している仕組みが"STSトークン"です。
【3. AWS CDKで実際にSaaSシステムを構築】
いよいよサンプルSaaSシステムの構築です！
※このサンプルをデプロイすると約1,000円/日かかるそうなので注意です。
環境構築はCDKハンズオンと同様にSageMaker StudioのCode Editorから行いました。
ハンズオンに使用したアプリケーション：Amazon ECS SaaS リファレンスアーキテクチャ
今回作成するシステム構成図
引用：Amazon ECS SaaS リファレンスアーキテクチャ
前提としてマルチテナントSaaSの概念と設計を理解するため
別日に「AWSを活用したマルチテナントSaaSの設計と実践~座学編~」を開催されています。
岡本は都合が合わず座学編には参加できませんでしたが事前に資料も展開いただいていたのである程度理解してから"実践編"に臨むことができました。
サンプルとして作成されるWebアプリケーション
管理者用アプリケーション画面
- テナントの管理機能が備わっています。
- 新テナントの追加
- 契約ティアの選択により必要なリソースを自動でプロビジョニング…etc
テナント用アプリケーション画面
- テナントが利用する機能が備わっています。
- 商品と注文に関するダッシュボード表示や登録などシンプルな CRUD 機能
- 他のテナントのリソースやデータにはアクセスできない制約機能…etc
引用：AWS におけるマルチテナント SaaS の実装パターン
特に問題なく構築でき、ホストされているWeb画面からテナントの登録や参照で動作確認ができました。
構築中(約40分ほど)に"座学編"の振り返りも入れながら構成図に出てくる設計上の概念などを丁寧に解説していただきました。
個人的にマルチテナントSaaSを理解するため、用語集的に構成図と照らし合わせる形でメモとして以下のようにまとめました。キャッチアップの取っ掛かりになれば幸いです。
マルチテナントSaaSを理解する上での重要な概念の例
-
-
SaaS(Software as a Service)
- ソフトウェアをクラウド環境などでホストし、ユーザーにサービスとして提供する形態のビジネスモデル
-
テナント
- SaaSサービスを利用する個々の「顧客（組織・企業・ユーザーグループ）」のこと
-
-
マルチテナント
- 複数のテナントが同一のリソースを共有するモデル(フルスタックプール)や、テナントごとにリソースを分けるモデル(フルスタックサイロ)などで管理する仕組み
- 複数のテナントが同一のリソースを共有するモデル(フルスタックプール)や、テナントごとにリソースを分けるモデル(フルスタックサイロ)などで管理する仕組み
-
シングルテナントとフルスタックサイロの違い
- シングルテナントはテナントごとにカスタマイズが入るなどテナントごとに管理する必要があるが、フルスタックサイロでは"同じアプリバージョンで環境の構築作業が完全自動化されていること"が重要
-
コントロールプレーン
- 複数のテナントを効率的に管理・運用するための仕組み。テナントを管理する中心的な機能を配置する場所。つまり管理者向け
- 例
- オンボーディング (新規テナント登録)
- テナント(テナントのポリシー、属性、および状態を一元管理)
- 認証
- 請求
- メトリクス
- 管理者ユーザー管理(SaaS プロバイダーの管理者)
- 例
- 複数のテナントを効率的に管理・運用するための仕組み。テナントを管理する中心的な機能を配置する場所。つまり管理者向け
-
アプリケーションプレーン
- SaaS製品の機能などを具体化する部分。つまりユーザー向け
-
ティアリング
- 各ティアでサービスの制限や求める要件などで差別化を図る目的で設定
- 例
- 今回作成するシステム構成図では"ティアごとにそれぞれ異なるデプロイモデルの環境に割り当てられます。"
- Basicティア ・・・ すべてのテナントは専用の ECS クラスターにデプロイされている"単一の" ECS サービスを共有する。ノイジーネイバー問題への対策や可用性、冗長性、テナント分離の設計管理が必要になります。
- Advancedティア・・・テナントが追加されるたびに"各テナント専用"の ECS サービスがデプロイされます。
- Premiumティア・・・テナントごとに"専用の ECS クラスターと ECS サービス"が割り当てられ、他のテナントから完全に分離された環境を作成する。
- 例
- 各ティアでサービスの制限や求める要件などで差別化を図る目的で設定
-
ノイジーネイバー問題
- 一部のユーザーやテナントが過剰にリソースを消費することで、同じインフラストラクチャを共有するほかのユーザーに悪影響を与える現象。
詳しく調べたい方はAWS におけるマルチテナント SaaS の実装パターンやAmazon ECS SaaS リファレンスアーキテクチャを参照することをお勧めします。
(後述する書籍もオススメです！)
【4. 懇親会】
まずは技術書争奪の"じゃんけん大会"が行われました。
景品は「マルチテナントSaaSアーキテクチャの構築」というオライリー・ジャパンから出版されている書籍でした。今回登壇されていたAWSの櫻谷さんが翻訳されているようでご提供いただいたようでした。
岡本がなんとゲットしちゃいました、ありがとうございます！
そのあとは近くのレストランへ移動して運営・参加者の皆さんと乾杯！
テーブルが同じになった方々と最近の生成AI事情やAWSサービスについての意見交換、プライベートなお話などでとても盛り上がりました。
【参加しての感想】
JAWS-UG 京都支部・KyotoLTの共催イベントに初めて参加しましたが、和やかな雰囲気の中で進行し、非常に居心地が良かったです。
SaaSに関する新たな知識を得ることができ、とても有意義な時間を過ごしました。
この記事では触れませんでしたが、有志の方々による3つのLTも内容が非常に興味深く、登壇者と参加者の温かなやり取りが印象的でした。
懇親会では新たな出会いがたくさんあり、嬉しく感じました。
今後もこのようなイベントには積極的に参加していきますのでまたレポート記事書こうと思います。
最後まで読んでいただきありがとうございました。