Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
© 2025 SaaS Engineering Meetup #SaaSEM AWS re:Invent 2024 セッションレポート
Slide 2
Slide 2 text
© 2025 SaaS Engineering Meetup SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315)
Slide 3
Slide 3 text
© 2025 SaaS Engineering Meetup #SaaSEM 注意 意訳/省略も多分に含みますので本編を見たい方はYouTubeをご覧ください。 結論から書くと、AWSの中身ってこうなっているんだろうな?って話です
Slide 4
Slide 4 text
© 2025 SaaS Engineering Meetup #SaaSEM SaaSデプロイモデル サーバ DB サーバ DB サーバ DB テナント A用 テナント B用 テナント C用 サイロ サイロモデルでも、コードベースは 1つ (会社ごとのカスタマイズは行わない) 4
Slide 5
Slide 5 text
© 2025 SaaS Engineering Meetup #SaaSEM SaaSデプロイモデル サーバ DB テナント A,B,C共有 プール 共用インフラでも適切な論理テナント分離を考える 5
Slide 6
Slide 6 text
© 2025 SaaS Engineering Meetup #SaaSEM SaaSデプロイモデル DB サーバ DB DB テナント A用 テナント B用 テナント C用 ハイブリッド 分離した部分を意識しないでよいプログラミングを心がける 6
Slide 7
Slide 7 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 マルチテナントSaaSアーキテクチャの課題 ①多様なワークロード(使われ方) ものすごく使うテナントもいればそうでないテナントもいる。 常にオンボーディングとオフボーデイングがなされており、変化し続けている。 ②コンピュートやストレージの調整が何回 適切なスケールとレジリエンス戦略を決定するための設定オプションは無数に存 在している。 ③業務領域や業界の要求が多様 コンプライアンスや規制上のニーズも変化する そもそもマルチテナントの設計は考えることが多いので大変
Slide 8
Slide 8 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 ワークロードを分析し各事項を検討の上、アーキテクティングし続ける必要がある。 コンピュート データベース ワークロード① ワークロード② ワークロード③ ● Tiering ● ノイジーネイバー ● コスト効率 ● 運用効率 ● 分離パターン ● 業務領域や 業界の要求 ストレージ
Slide 9
Slide 9 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 どれか一つのモデルでいくわけではなく組み合わせて提供していく
Slide 10
Slide 10 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 プール型は常にノイジーネイバーとの戦い(≒サイジングやポリシーマネジメント) テナントのリソースをプール化する場合 - ワークロードをどのように予測し、効率的にスケールさせま すか? - 環境の規模をどのように決定しますか? - どのようにして(障害の)影響範囲を抑えますか?
Slide 11
Slide 11 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 A/Bリリースやターゲットを絞ったリリースなどを実施したい場合に デプロイモデルが多様だとどうやって提供する? ターゲットを絞ったデプロイ - デプロイを段階的に進めるにはどうすればよいです か? - 特定のテナントグループをどのようにターゲットにし ますか? - 複雑な構成をどのように管理しますか?
Slide 12
Slide 12 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 ビジネスが成長してマルチリージョン運用をしたくなったとして、 リージョンごとに運用は変えたくないですよね? 分散された拠点 - 地域別のデプロイをどのようにサポートしますか? - 地域ごとのテナント環境の規模はどのように決定します か?
Slide 13
Slide 13 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 Cell-based Architectureが効果的な場合があります セルとはあくまで論理的な構成であり顧客に意識させません。
Slide 14
Slide 14 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 セルと既存のデプロイモデルの考え方は同時に活用できます。
Slide 15
Slide 15 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 セルはあくまで論理的なまとまりなのでVPCで区切ることも可能
Slide 16
Slide 16 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 サーバレスの場合、サイロはコンピュートスタックがテナントごとに存在するイメージに
Slide 17
Slide 17 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 AWSアカウントレベルでセル自体をグループ化するアプローチも存在 AWSアカウントレベ ルでクォータ制限が あるサービスを多様 する場合などに有効
Slide 18
Slide 18 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 セルをリージョンでグループ化するアプローチも可能
Slide 19
Slide 19 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 オンボーディングにも種類を設けられます テナントの属性 によってCellを 分けるパターン 属性で分けない でCellのリミット まで突っ込むパ ターン
Slide 20
Slide 20 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 ノイジーネイバーは常に発生しては消えていくのでセル間の移行も柔軟に
Slide 21
Slide 21 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 肝はセルの状態をモニタリングしてどこに配置するのか決定できるプロセス セルの状態 を確認
Slide 22
Slide 22 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 テナント分離はもちろんセル単位でも分離してセキュアに保つ 「テナントコンテキスト」に 加えて「セルコンテキス ト」を取り扱う
Slide 23
Slide 23 text
© 2025 SaaS Engineering Meetup まとめ
Slide 24
Slide 24 text
© 2025 SaaS Engineering Meetup #SaaSEM SAS315 Cell-based Architectureは複雑に変化しながらスケーリングする仕組みをマネージする方 法として有効な手段ではある。 しかし、まずはスケーリングの性質、環境内のテナント数、そして組織のスケーリングの性質 から逆算し、1手段として考えるのが大事。 同時に、「ビジネスサイドからCell型アーキテクチャが必要だ」と言われることはない。 Cell-based Architectureが適切な選択である理由を説明するのは、依然としてアーキテクト の役割である。 ビジネスとテクノロジーを一体に考えていくのが SaaSの肝ですね!