Skip to content

読書:マルチテナントSaaSアーキテクチャの構築 原則、ベストプラクティス、AWSアーキテクチャパターン

Posted on:2025年3月15日

仕事上必要になりそうで、おすすめされたこともあり読んでみた。

マルチテナントSaaSアーキテクチャの構築 原則、ベストプラクティス、AWSアーキテクチャパターン
マルチテナントSaaSアーキテクチャの構築 原則、ベストプラクティス、AWSアーキテクチャパターン

目次

感想

マルチテナントSaaSのシステムアーキテクチャを設計するにあたって、考慮するべきポイントや設計パターンをかなり網羅的に紹介してくれている書籍。

自分がSaaSを提供している企業で経験したことや学んだこと、行った設計上の意思決定を思い出しながら、答え合わせをしているような感覚で読めた。もちろん答え合わせだけでなく、直感や経験則でわかっているつもりだけど、うまく自分の言葉で言語化できない概念についてもしっかり整理された上で紹介されていた。自分が今後再びSaaSの設計・開発に取り組むときは、これまでよりもよりパワーアップした状態で取り組めそう。

これからSaaSの設計開発に初めて挑戦しようとするエンジニアにとっても、本書一冊で必要な観点や気をつけるべきポイントについて網羅的に学ぶことができるので、教科書的な使い方をするのもおすすめ。書籍のタイトルには「AWS」という言葉が入っている通り、アーキテクチャの例はAWSの各種サービスを使って解説されるけど、Google Cloud など他のクラウドにも簡単に読み替えて活用することができるはず。チームでSaaSの設計・開発に取り組むにあたっての共通言語作りにもいいと思う。

本書の主題としては「マルチテナント」。なので、異なる企業・組織が一つのSaaSにどのように相乗りするか、そのパターンについて重点的に紹介されていた。

大きくは、複数のテナントが全てを共有するプール型、テナントごとに専用のリソースをアサインするサイロ型、その両方の利点を組み合わせたハイブリッド型の3パターンがあるが、どれを採用すべきかは事業の特性やコンピューティングの特性によって最適解は変わる。「データベースはプール型だけど、アプリケーションサーバはサイロ型」のように、一つのSaaSの中で複数のパターンが混在することもある。

それらのパターンを、事業や顧客が置かれた状況に応じて適切に組み合わせながら、なるべく最適なものを選択し、状況の変化に応じてアーキテクチャ自体を変化させていくことが重要。でも、必要以上に複雑化させることなく、アーキテクチャ特性を満たすために必要十分なシンプルな選択をするべきだと、再実感できた。

最後の章の「指針となる原則」では、SaaSを事業として展開していく際の企業としての心構えに関することが書かれていた。本書全体を通して、SaaSの開発提供すること自体を目的として捉えるのではなく、会社のミッションや事業の目的達成のための手段であることが強調されていて、自分としてはとても共感できた。

「サービス」を構成するのはソフトウェアプロダクトだけではなくて、それを支えるさまざまな職種の人たちも含めて「サービス」。SaaSによって生まれる価値を持続的に顧客に提供し、事業をぐんぐん成長させていくためには、営業、カスタマーサクセス、プロダクト開発、バックオフィスなど、さまざまな役割の人たちがそれぞれの仕事を全うしつつ、全体最適を意識して時には越境していく必要がある。

システムアーキテクチャの良し悪しも、開発生産性や開発の運用効率の良し悪しに加え、売りやすさ、サクセスしやすさ、アップセル・クロスセルしやすさ、などSaaSの事業を取り巻くさまざまな要素を踏まえて判断されるべきもの。その観点を考慮して設計をする必要がある。

個人的には、ここの部分は過去の経験上の反省点・もっと上手くやれたかもしれないポイントだと考えているので、次の機会では前よりも意識して取り組むぞ、と改めて決心するいい機会になった。