Report of 「SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315)」

SaaS Engineering Meetup
第8回 AWS re:Invent 2024 SaaS関連報告会
https://saas-engineering-meetup.connpass.com/event/338031/

Transcript

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