「マルチテナント」で SaaS を作るってどういうことなんですか？

© 2025, Amazon Web Services, Inc. or its affiliates. All
rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「マルチテナント」で SaaS を作るってどういうことなんですか︖ Hiroto Sakuraya Senior Partner Solutions Architect, SaaS Amazon Web Services Japan G.K.

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾃⼰紹介櫻⾕広⼈ Senior Partner Solutions Architect, SaaS Amazon Web Services Japan G.K. さくらや主な仕事 AWS パートナー (特に ISV/SaaS 企業) の技術⽀援、パートナープログラムおよび共同マーケティング/販売に関する⽀援を担当ひろと専⾨分野 SaaS、サーバーレス、マイクロサービス界隈

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. “SaaS（Software as a Service）とは、ソフトウェアをクラウド環境などでホストし、ユーザーにサービスとして提供する形態のビジネスモデルです。マルチテナントとは、複数のユーザーが同⼀のリソースを共有するモデルや、それらを統⼀された体験を通じて管理する仕組みを指します。セキュリティや可⽤性、運⽤⾯などで独⾃の考慮事項が必要となりますが、インフラストラクチャコストの削減や運⽤効率の向上が⾒込めるため、近年その採⽤件数は右肩上がりに増加しています …”

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 「SaaS である」とはどういうことか • MSP (マネージドサービスプロバイダー) との違い • SaaS の本質はビジネスモデル • 製品 (Product) ではなくサービス (Service) 1章 SaaS マインドセット

rights reserved. 提供形態としての SaaS ソフトウェアパッケージを購⼊し、⼿元の PC や会社のサーバーにインストール従来のパッケージ販売のモデル SaaS モデルブラウザなどからネットワーク越しに利⽤ソフトウェアの実体は SaaS 事業者側に存在 SaaS 事業者の環境場所を問わず利⽤可能モバイル端末からも

rights reserved. ビジネスモデルとしての SaaS イノベーション運⽤効率俊敏性成⻑特定のビジネス⽬標を達成するための⼿段、⽅法として導⼊するものスムーズなオンボーディングレベニュー特定の技術要素やツールを指す概念ではない

rights reserved. ソフトウェアは上物に過ぎない事業計画営業マーケティング CS (カスタマーサポート/サクセス) 開発運⽤ソフトウェア ü ビジネスで実現したいことがベース ü ソフトウェアは⼿段

rights reserved. なぜ人類は SaaS ビジネスをやろうとするのか？ • 最近のトレンドだから︖ • 顧客に頼まれたから︖ • 競合が SaaS をやってるから︖ • 利益率を向上させたいから︖ • 社⻑が「でぃーえっくすだ︕」って⾔ってるから︖

rights reserved. 中小企業、社長の7割が「SaaS聞いたことがない」デジタル化はなぜ進まない？近年、多くの⽇本企業が労働⽣産性を上げるために「DX」「リスキリング」「SaaS」などに投資をしてきた。ビジネス領域において、これらのキーワードの存在感も⾼まっているように思えるが、Chatwork（東京都港区）の調査から、中⼩企業（従業員規模300⼈未満）の4割以上が、DX、リスキリング、SaaSそれぞれに対して「聞いたことがない」と回答していることが分かった。 SaaSについては70.6％が「聞いたことがない」と回答。DXとリスキリングと⽐較して、⼀層認知度が低いことが明らかになった。 https://www.itmedia.co.jp/business/articles/2312/04/news041.html ITmedia ビジネスオンライン

rights reserved. あらゆる SaaS に共通する目的 ◯◯◯◯ の ◯◯◯◯

rights reserved. あらゆる SaaS に共通する目的ビジネスのスケール

rights reserved. なぜスケールが重要なのか︖ ソフトウェアの販売、導⼊、運⽤には⼈⼿がかかる → ビジネスを成⻑させるためには⼈的リソースのスケールが不可⽋ → 成⻑に応じて既存顧客のサポートの負荷も増え続ける → イノベーションに投資できる時間が少なくなる → 顧客体験が向上せず、離反が増える⾃動化標準化 SaaS

rights reserved. MSP モデル顧客A専⽤のアプリケーション顧客A専⽤の運⽤＋顧客B専⽤のアプリケーション顧客B専⽤の運⽤＋顧客C専⽤のアプリケーション顧客C専⽤の運⽤＋顧客D専⽤のアプリケーション顧客D専⽤の運⽤＋ Pros: 顧客ごとの要件に柔軟に対応できる Cons:個別の運⽤管理によってコストや複雑性が増す v1.0 v1.2 v1.3 v2.0

rights reserved. SaaS モデル共通のアプリケーション共通の運⽤全ての顧客に対して共通のアプリケーションを運⽤し、標準化された業務ナレッジをサービスとして提供する管理の効率化ビジネスのスケーラビリティ

rights reserved. 朝オフィスに着き、仕事を始めようとしたら、昨晩 10,000 社から契約の申込みが来ていることに気づきました。これらの顧客全員に対して迅速に導⼊作業を進め、サービスを提供し始めることができますか︖ 御社の SaaS、それ本当に SaaS ですか︖

rights reserved. それ、SaaS だったらできるはずですよ u 各顧客と商談して契約を結ぶのに時間がかかる… → なぜセルフサインアップの仕組みがないんですか︖ → なぜ料⾦プランが公開されていないんですか︖ u 導⼊作業を⾏う担当者が⾜りない… → なぜ⾃動化されていないんですか︖ u インフラのリソースが⾜りない… → なぜ⾃動でスケールしないんですか︖ u 顧客と話さないと提供すべきものがわからない… → なぜカスタマイズ前提なんですか︖ソフトウェアは標準化されてないんですか︖

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 「テナント」という概念の導⼊ • SaaS アーキテクチャの 2 つの要素 - コントロールプレーン - アプリケーションプレーン • ティアリングをうまく活⽤する • テナントコンテキストの取り回し⽅ • SaaS における「ユーザー」の役割 2章マルチテナントアーキテクチャの基礎

rights reserved. “テナント”とは︖ SaaS 企業A 企業B システムが取り扱う SaaS を利⽤する顧客の論理的な単位。実体はサービスによって様々。 1 つのテナントが企業を表す場合もあれば、事業部、ユーザーといった単位になる場合も例︓企業がテナント SaaS 事業部X 事業部Y 例︓事業部がテナント企業A

rights reserved. SaaS を作るとはどういうことか ü システムにテナントの概念を導⼊し、セキュリティ、パフォーマンス、可⽤性、コスト、運⽤など、さまざまな観点からテナントがもたらす課題に取り組み、効率的にテナントを取り扱えるようにすること。 ü それでも、開発者にテナントの存在を意識させないようにすること。 ü テナントをすべての考慮事項の中⼼に置き、データドリブンで意思決定ができるようにすること。その根拠となるオブザーバビリティをテナントレベルで確保すること。

rights reserved. SaaS アーキテクチャを構成する 2 つのパーツコントロールプレーン管理コンソールオンボーディング請求テナント管理 ID 管理監視デプロイユーザー管理分析マイクロサービス Web フロントエンドマイクロサービスマイクロサービスマイクロサービスアプリケーションプレーン

rights reserved. SaaS Builder Toolkit for AWS (SBT) • SaaS のベストプラクティスを実装するために使⽤できる開発者向けツールキット • AWS Cloud Development Kit (CDK) をベースに構成されている • 再利⽤可能なコンポーネントを使⽤して、AWS 上にコントロールプレーンのリソースを構築 • アプリケーションプレーンとの接続をサポートするライブラリも提供 • サードパーティの ISV 製品との連携も • オープンソース (Apache-2.0 ライセンス) GitHub: awslabs/sbt-aws

rights reserved. SBT で構築されるコントロールプレーン Amazon API Gateway UserMgmt TenantDetails Amazon Cognito Amazon EventBridge Iauth Interface TenantMgmt CLI / API SaaS 管理者 TenantConfig Amazon CloudFront Amazon S3 AWS WAF 管理画⾯ (オプション) AWS Lambda Amazon DynamoDB プロビジョニングなど各種イベントを通知アプリケーションプレーン

rights reserved. 詳しくは YouTube の解説動画で YouTube | SaaS Builder Toolkit for AWS (SBT) の紹介【AWS Black Belt】

rights reserved. ティアリング (tiering) による体験の差別化 SaaS テナント1︓数千名規模のエンタープライズ企業テナント2︓10~15 名のスタートアップ • データは他のテナントとは物理的に分離してほしい • プライベートなネットワークでサービスを利⽤したい • 可⽤性は 99.999 %以上が必要 • コストは惜しまない • セキュリティは最低限でOK • 可⽤性は 99 % 以上であればよい • なるべくコストを抑えたい • ⼀度に⼤量のデータをアップロードできるようにしてほしい

rights reserved. ティアリング (tiering) による体験の差別化テナント1︓数千名規模のエンタープライズ企業テナント2︓10~15 名のスタートアップ • データは他のテナントとは物理的に分離してほしい • プライベートなネットワークでサービスを利⽤したい • 可⽤性は 99.999 %以上が必要 • コストは惜しまない • セキュリティは最低限でOK • 可⽤性は 99 % 以上であればよい • なるべくコストを抑えたい • ⼀度に⼤量のデータをアップロードできるようにしてほしい Enterprise ティア Basic ティアティア → 契約プランと読み替えるとわかりやすい

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • デプロイモデルの種類とPros/Cons - サイロモデル - プールモデル - ハイブリッドモデル • ティアリングとデプロイモデルの関係性 • ポッドベースのデプロイ (≒セルベース) 3章マルチテナントのデプロイモデル

rights reserved. デプロイモデルの考え⽅サイロモデルプールモデル

rights reserved. 現実はもっと複雑なわけで

rights reserved. 「シングルテナント」って⾔葉やめませんかサイロモデルコントロールプレーン管理コンソールオンボーディング請求テナント管理 ID 管理監視デプロイユーザー管理分析アプリケーションプレーン中央管理

rights reserved. ティアリングとデプロイモデルの設計上位のティアの顧客にはサイロモデルで提供下位のティアの顧客にはプールモデルで提供

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • マルチテナントの出発点 • テナントの導⼊をいかにスムーズに⾏うか - オンボーディングの基本要素、パターン - モニタリング - テスト • これまでのアイデンティティの概念を拡張する - テナントコンテキストの付与 - フェデレーション - テナントとのマッピング 4章オンボーディングとアイデンティティ

rights reserved. スムーズなオンボーディングフローの確⽴が鍵 • オンボーディングにかかる時間はユーザー体験の質を⼤きく左右する。Time to Value (TTV) を最⼩化するためにも、可能な限りフロー全体を⾃動化するのが望ましい • テナントがセルフサービスでサインアップできる⽅式と、SaaS 事業者が管理者⽤のコンソールから登録する⽅式の 2 種類が考えられる • フローに含まれる各ステップは、システムによって異なる ex. データベースのプロビジョニング、初期データの登録、外部の請求プロバイダーの設定

rights reserved. 例: オンボーディングのワークフロー登録サービス /reg • ユーザープール • 管理ユーザー • カスタムクレーム ID プロバイダーユーザー管理サービス • リソースへのアクセス • ロールテナント分離ポリシーテナント管理サービスプロビジョニングサービス 1 3 4 2 8 5 請求管理サービス 6 7 テナント登録画⾯請求プロバイダー

rights reserved. SaaS アイデンティティの作成ユーザーアイデンティティテナントアイデンティティ • テナント ID • 会社名 • ステータス • ティア (契約プラン) SaaS アイデンティティ • ユーザーとテナントに関する情報を集約し、 IdP で中央管理 • トークンベースの認証で複数サービス間での利⽤をサポートする • 名前 • 電話番号 • メールアドレス • ロール

rights reserved. JWT を活⽤したテナントコンテキストの伝達 IdP リダイレクト 3 Web サーバー 2 1 4 5 テナント初回アクセス認証成功認証済みアクセス Ø ヘッダーでトークンを共有するだけでサービス間でのコンテキストの受け渡しが可能 Ø テナント管理サービスへの問い合わせ、データベースのクエリが不要で軽量にバックエンドの呼び出し HTTP ヘッダー Authorization: Bearer <Token> マイクロサービスマイクロサービステナントのメタデータを合わせて IdP に登録しておく { "custom:tenant_id": "tenant1", "custom:tenant_tier": "basic" … }

rights reserved. • このユーザーはどのテナントに属しているか︖ • このテナントがアクセス可能なデータの範囲は︖ • システムに⼤きな負荷をかけているのはどのテナントか︖ • このログレコードはどのテナントの操作によるものか︖ • １テナントあたりのインフラコストはどれくらいか︖ etc. システムのあらゆる側⾯を”テナント”というコンテキストを通して捉えるようにするあらゆるビジネス上の意思決定にはテナント単位でのデータポイントが不可⽋

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • サインインページの設計 • テナントコンテキストをどう解決するか • 認証フローのカスタマイズ • 顧客が持つ IdP とのフェデレーション • サーバーレスやコンテナにおけるルーティング実装の違い 6章テナントの認証とルーティング

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 何をマルチテナントにするべきか • ノイジーネイバーへの対策 • マイクロサービス化のすゝめ • テナントの隠蔽と⼀元管理 - アスペクト - サイドカー - ミドルウェア - Lambda レイヤー/Extensions 7章マルチテナントサービスの構築

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • テナントのデータをどのように分割するか • サービスごとのパーティショニングモデル - リレーショナルデータベース - NoSQL - オブジェクトストレージ - OpenSearch • データのライフサイクル管理 8章データパーティショニング

rights reserved. データパーティショニングとは Product Id Name SKU Cost 1940-939-94 Glove 939301 12.39 3538-819-11 Shirt 194193 7.83 1464-992-12 Hat 539294 15.41 8810-098-53 Scarf 793891 130.84 商品データ Oder Id Product Id Qty 9314-114-91 1940-939-94 1 7544-325-98 8810-098-53 4 8755-069-24 1940-939-94 2 4991-630-04 3538-819-11 1 注⽂データテナント1 テナント2 テナント3 テナント4 各テナントのデータをどこに、どのように分離して保存するかに関する検討事項。物理的または論理的にどのように分離されているかによって、テナント分離の⽅法や、ユーザーに提供できる体験も変わってくる。また、利⽤できるパーティショニングの戦略は、データベースやストレージの性質にも左右され、サービス特有の機能が活⽤できることも。

rights reserved. RDS のデータパーティショニングモデルサイロモデルテナント1 テナント2 テナントごとに個別のインスタンス/データベースプールモデルテナント1 テナント2 TenantID Name SKU Cost Tenant1 Glove 939301 12.39 Tenant2 Shirt 194193 7.83 Tenant1 Hat 539294 15.41 Tenant2 Pants 490023 17.45 すべてのテナントで共通のデータベーステナント ID を使ってパーティショニング

rights reserved. S3 のデータパーティショニングモデルバケット単位テナント1 テナント2 プレフィックスベーステナント1 テナント2 /my-bucket/tenant1 /my-bucket/tenant2 オブジェクトタグ個別のアクセスポイントテナント1 テナント2 Tenant1 テナント1 アクセスポイント Tenant3 テナント2 アクセスポイント

rights reserved. プールモデルにおけるテナント分離の課題 • アプリケーションはすべてのテナントからのリクエストを⼀箇所で引き受けている • データベースはすべてのテナントで共有されている • つまりアプリケーションは、すべてのテナントのデータにアクセスできる状態として構成しなければならない (リクエスト元のテナントが特定されるまで) Web サーバー App サーバー DB すべてのテナント TenantID Name SKU Cost Tenant1 Glove 939301 12.39 Tenant2 Shirt 194193 7.83 Tenant1 Hat 539294 15.41 Tenant3 Scarf 793891 130.84 Tenant2 Pants 490023 17.45

rights reserved. Amazon DynamoDB におけるプール分離モデル { "Sid": "TenantReadOnlyOrderTable", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:DescribeTable" ], "Resource": [ "arn:aws:dynamodb:[region]:table/Order" ], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": [ "tenant1" ] } } } Partition Key SKU Name Tenant1 93529-94 Black T-shirt Tenant2 24411-01 Blue hoodie Tenant1 76235-92 Wool socks Tenant3 95419-37 Green polo Tenant2 88314-99 White hat Tenant1 24598-72 Tennis shoes DynamoDB テーブル

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • EKS を使⽤したリファレンスアーキテクチャ - Namespace による分離 - Ingress ルーティング - Helm によるオンボーディング - Argo/Flux によるデプロイ⾃動化 • ノードタイプの選択 • サーバーレスコンピューティングとの相性 10章 EKS SaaS: アーキテクチャパターンと戦略

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • サーバーレスを使⽤したリファレンスアーキテクチャ - Lambda 関数のデプロイモデル - API Gateway によるルーティング実装 - 使⽤量プランによるスロットリング - 予約済み同時実⾏数によるノイジーネイバー対策 - 動的ポリシーによるテナント分離 • サーバーレスと SaaS は相性が良い 11章サーバーレス SaaS: アーキテクチャパターンと戦略

rights reserved. AWS リファレンスアーキテクチャの紹介 https://aws.amazon.com/jp/builders-flash/202501/eks-multi-tenant-saas-pattern/ https://aws.amazon.com/jp/builders-flash/202410/multi-tenant-saas-pattern/ （来⽉、サーバーレス編も出るよ）

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 移⾏の⽬的/⽬標を明確にする • フィッシュモデルとは • ⽬標に合わせた移⾏パターン - サイロ型リフトアンドシフト - レイヤー型移⾏ - サービスごとの移⾏ - 段階的なハイブリット型 • 移⾏対象をどう選定するか 13章 SaaS 移⾏戦略

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • SaaS の境界線を拡張する • アーキテクチャパターン - リモートデータ - リモートアプリケーションサービス - リモートアプリケーションプレーン • リソースの管理、アクセスコントロール、運⽤ • オーナーシップの考え⽅ 15章 SaaS Anywhere

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • SaaS と⽣成 AI の可能性 • テナントごとのカスタマイズをどのように導⼊するか - RAG - ファインチューニング • ノイジーネイバー対策、テナント分離 • ⽣成 AI の価値をどのように値付けするか 16章⽣成 AI とマルチテナント

rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon https://amzn.asia/d/hHCPeU8 楽天ブックス https://books.rakuten.co.jp/rb/18076428/ オライリー https://www.oreilly.co.jp/books/9784814401017/

「マルチテナント」で SaaS を作るってどういうことなんですか？

「マルチテナント」で SaaS を作るってどういうことなんですか？

More Decks by NemOps

Featured

Transcript