マルチテナントSaaSを正しく作りたい！
5.1K Views
March 16, 25
スライド概要
2025/03/14 第41回 JAWS-UG札幌 勉強会登壇資料
関連スライド
各ページのテキスト
マルチテナントSaaSを 正しく作りたい！ 2025/03/14 第41回 JAWS-UG札幌 勉強会 1
自己紹介 もりやま 所属： 役割：Backend 属性：#ゲーム音楽 #筋トレ #早起き 2
JAWS初登壇です！ ● 機会をいただけて嬉しいです！ ● 下手な発表ですが、よろしくお願いします。 ○ 特に今回はちょっと纏まりが良くなくて、、 3
1 きっかけ 本日のテーマを選んだきっかけ。 4
きっかけ ある日こんなポストを見つけました。。 5
「MySQLを使うと、会社が潰れる。」 6
倒産だ〜！ 7
「MySQLを使うと、会社が潰れる。」 それは冗談として、 きちんと問題ない理由を当時言えなかった。 8
「MySQLを使うと、会社が潰れる。」 おそらくPostgreSQLと比べると、MySQLはRLSのネイティブ サポートがないことを言いたかったのでは。。 （マルチテナントSaaSの技術選定のお話） ※Row-Level Security データベースのテーブル内で、ユーザーやロールごとに参照・操作できる行（レコード）を制限す るセキュリティ機能 9
そういえば、、、 10
そういえば、、、 ※省略 https://cybersecurity-jp.com/news/97043 11
マルチテナントSaaSを 正しく作りたい！ 2025/03/14 第41回 JAWS-UG札幌 勉強会 12
「マルチテナント」＝「SaaS」？ SaaS： ビジネスモデル。 「俊敏性」「運用効率」「スムーズなオンボーディング」など。 マルチテナント： SaaSを構成するアーキテクチャの総称。 シングルテナント、マルチテナント、その中間 SaaS はビジネスモデルである https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/saas-is-a-business-model.html 13
2 マルチテナントの メリット・デメリット 14
コスト面 SaaS アーキテクチャ 入門編~マルチテナント SaaS とは~ 【AWS BlackBelt】 15
可用性面 SaaS アーキテクチャ 入門編~マルチテナント SaaS とは~ 【AWS BlackBelt】 16
パフォーマンス面 SaaS アーキテクチャ 入門編~マルチテナント SaaS とは~ 【AWS BlackBelt】 17
パフォーマンス面 マルチテナントはリソース・運用コストに優れている。 ・・・が、それ以外はデメリットになる。 SaaS アーキテクチャ 入門編~マルチテナント SaaS とは~ 【AWS BlackBelt】 18
テナント分離戦略 ● どのようにテナント間を分離する？ ● どのようにロールを付与する？ ● サービス ○ アカウント単位？ ○ VPC単位？ ● S3 ○ バケット単位？ ○ パーティション単位？ ● DynamoDB ○ テーブル単位？ ○ スキーマ単位？ ● RDS ○ テーブル単位？ ○ スキーマ単位？ ○ 行単位? 19
テナント分離戦略 ● どのようにテナント間をどう分離する？ ● どのようにロールを付与する？ ● サービス ○ アカウント単位？ ○ VPC単位？ ● S3 ○ バケット単位？ ○ パーティション単位？ 意図せぬクロステナントアクセスは本当に会社が潰れるかも。。。 ● DynamoDB ○ テーブル単位？ ○ スキーマ単位？ ● RDS ○ テーブル単位？ ○ スキーマ単位？ ○ 行単位? 20
こうなります。（再掲） ※省略 https://cybersecurity-jp.com/news/97043 21
「統合」と「分離」の バランスが難しい。。 22
「統合」と「分離」の バランスが難しい。。 なお、シングルテナント or マルチテナントの二者択一ではない、 ＝ メリデメを理解し、使い分ける。 23
3 アーキテクチャパターン サイト、プール、ブリッジ、Celled 24
サイロモデル(シングルテナント) AWS re:Invent 2022 - SaaS architecture patterns: From concept to implementation (SAS305-R) 25 https://www.youtube.com/watch?v=xlAXldBt7I0
サイロモデル(シングルテナント) AWSでは、シングルテナントという言葉は使わない。 （マルチテナントの一つの構成方法として「サイロ」を使う） ・シングルテナントという用語の削除 https://docs.aws.amazon.com/ja̲jp/whitepapers/latest/saas-architecture-fundamentals/removing-the-single-tenant-term.html AWS re:Invent 2022 - SaaS architecture patterns: From concept to implementation (SAS305-R) 26 https://www.youtube.com/watch?v=xlAXldBt7I0
プールモデル(マルチテナント) AWS re:Invent 2022 - SaaS architecture patterns: From concept to implementation (SAS305-R) 27 https://www.youtube.com/watch?v=xlAXldBt7I0
ブリッジモデル AWS re:Invent 2022 - SaaS architecture patterns: From concept to implementation (SAS305-R) 28 https://www.youtube.com/watch?v=xlAXldBt7I0
ブリッジモデル いずれかを選択するだけではなく、 例えばTierで分類して、使い分けていく。 例： Basic プラン ：プールモデル Proプラン ：ブリッジモデル Premiereプラン ：サイロモデル AWS re:Invent 2022 - SaaS architecture patterns: From concept to implementation (SAS305-R) 29 https://www.youtube.com/watch?v=xlAXldBt7I0
Cell-based architecture re:invent2024で新しい考え方が出てきました。 30
Cell-based architecture 「セル」＝自己完結型のデプロイメントユニット（？） 例１(障害の障壁化)： 可用性の観点でセルを分けるパターン。 （ノイジーネイバー問題の影響反映の縮小） AWS re:Invent 2024 - SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315) https://www.youtube.com/watch?v=wYm_PJc2U8c 31
Cell-based architecture 「セル」＝自己完結型のデプロイメントユニット（？） 例２(複雑さの解消）： 複雑性の観点でセルを分けるパターン。 （特定の属性（地理や適用される法律、規則）で分別したい場合など） AWS re:Invent 2024 - SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315) https://www.youtube.com/watch?v=wYm_PJc2U8c 32
Cell-based architecture 「セル」＝自己完結型のデプロイメントユニット（？） 例２(複雑さの解消）： セルという境界で複雑性解消や、耐障害性を高めたアーキテクチャ。 複雑性の観点でセルを分けるパターン。 （特定の属性（地理や適用される法律、規則）で分別したい場合など） 最新だから使う・・・ではなく、 サービスの性質から逆算して適用を判断する。 ※これはこれで、更なる複雑性を生む可能性もあり。 AWS re:Invent 2024 - SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315) https://www.youtube.com/watch?v=wYm_PJc2U8c 33
4 コントロールプレーンと アプリケーションプレーン 34
Control plane と Application plane コントロールプレーン ● テナントを管理および操作するのに役立つ共通ツール群 ○ マルチテナント環境のオンボーディング、認証、管理、運用、分析 アプリケーションプレーン ● サービス、アプリケーション固有な機能 35
Control plane と Application plane https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/control-plane-vs.-application-plane.html 36
Control plane と Application plane コントロールプレーン ＝ SaaS実装に必要な多くの「退屈な」部分（毎回作るところ） アプリケーションプレーン ＝ ビジネス価値を生む、楽しいところ。 https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/control-plane-vs.-application-plane.html 37
Control plane と Application plane この２つを分けて考えよう！ （関心の分離） https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/control-plane-vs.-application-plane.html 38
Control plane と Application plane 直接的に顧客体験を産まないところ は、AWSに任せよう！ ・・・ということで、、 https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/control-plane-vs.-application-plane.html 39
SaaS Builder Toolkit for AWS（SBT） ● SaaS開発における一般的な課題を解決し、開発速度を向上させるた めのオープンソース開発者ツールキットです。 ● AWS Cloud Development Kit (CDK)の上に構築されており、SaaS の実装に必要な多くの「退屈な」部分を自動化します。 40
SaaS Builder Toolkit for AWS ● 現時点で、v0.5.24 ● ワークショップもあります！ ○ https://catalog.workshops.aws/sbt-aws/en-US 41
SaaS Builder Toolkit for AWS ● 現時点で、v0.5.24 ● ワークショップもあります！ ○ https://catalog.workshops.aws/sbt-aws/en-US ・まだ使える機能は限定的とのこと。 ・本番ワークロードに適用する場合は、AWSに要相談！ 42
5 ABAC実装パターン 属性（テナント）ベースのアクセスコントロール 43
DynamoDBのアクセス制限 ● ユーザの属性にテナントIDを持たせる ● IDプールにて、 テナントIDをPrincipalTagに指定 44
DynamoDBのアクセス制限 ● ユーザの属性にテナントIDを持たせる ● IDプールにて、 テナントIDをPrincipalTagに指定 "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": [ "${aws:PrincipalTag/TenantID}" ] } 45
RDSのアクセス制限 ● プールモデルならPostgreSQLのRLSが楽ちん。 MySQLさんは・・・😭 46
RDSのアクセス制限 ● スキーマ分離は？ Database Schema： tenant_123 Schema： Schema： tenant_456 tenant_456 ● DBユーザを分ける必要がある。 ● コネクションプーリングどうする？ ● 集計は？DDL適用は？ TBL1 TBL2 TBL1 TBL2 47
RDSのアクセス制限 ● スキーマ分離は？ Database RLS以外で良い方法があまり思い浮かびませんでした。。 Schema： Schema： Schema： tenant_123 tenant_456 tenant_456 良い方法あれば教えて頂きたいです。。 ● DBユーザを分ける必要がある。 TBL1 TBL2 TBL1 TBL2 ● コネクションプーリングどうする？ 48
6 まとめ 49
まとめ ● 考慮点が多すぎて難しい・・・。 ○ テナント固有の機能実装方法(フューチャフラグ)などなど ● できる範囲でしっかり調べておかないと、いきなり技術的負債たっぷりな サービスを作ってしまいそう。。 ● 脆弱なマルチテナントSaaSは会社を潰してしまう・・・かも。 50
Thanks!! ご清聴ありがとうございました！ 51