『マルチテナントSaaSアーキテクチャの構築』を読んだ

『マルチテナントSaaSアーキテクチャの構築』を読んだ。

マルチテナントSaaSアーキテクチャの構築 oreilly.co.jp

SaaS（Software as a Service）とは、ソフトウェアをクラウド環境などでホストし、ユーザーにサービスとして提供する形態のビジネスモデルです。マルチテナントとは、複数のユーザーが同一のリソースを共有するモデルや、それらを統一された体験を通じて管理する仕組みを指します。セキュリティや可用性、運用面などで独自の考慮事項が必要となりますが、インフラストラクチャコストの削減や運用効率の向上が見込めるため、近年その採用件数は右肩上がりに増加しています。本書は、エンジニア向けの本格的なSaaS解説本として、マルチテナントSaaSの概念、実践的なテクニックなど、総合的なノウハウをまとめ、ベストプラクティスとパターンに沿った効率的な開発を提案しています。

内容

マルチテナントSaaSを設計するうえで、そのアーキテクチャについて考慮すべき側面を網羅的に解説している本だった。

アプリケーションプレーンとコントロールプレーン

アーキテクチャをアプリケーションプレーンとコントロールプレーンに分けるという考えかたが、この本で紹介されているアイデアのうち最も基本的かつ重要なものだと思った。

アプリケーションプレーンはSaaSのビジネスドメインを扱うサービスのまとまり。後述のとおり、必要に応じてテナント専用のインフラリソースが用意されたりする。たとえば、レビューサービスは全テナントでDBを共用するが、注文サービスは各テナント個別のDBを使う、といった構成がある。

一方、コントロールプレーンはオンボーディング（サインアップ等のタイミングでテナントのためのリソースをすべて準備すること）や請求、認証、また内部用の管理画面など、テナントをまたがって使うサービスのまとまりだ。つまり、アプリケーションプレーンとは異なって、各サービスはマルチテナント的な要件を持たない。

これらのプレーンを分けて考えることで、それぞれ別のアーキテクチャやデプロイ戦略を採用するという方針が取れるようになる。

デプロイモデル

この本では、「マルチテナント」という用語に対して一般的に抱く「サービスを利用する全テナントでインフラリソースを共有する」という解釈をさらに広げている。具体的には、現代のSaaSだと、テナントが使うリソースは他テナントと共用しているかもしれないし、または占有しているかもしれないが、テナントはそれを意識しなくてよい。それを踏まえて「マルチテナント」を

単一の統合された体験を通じてテナントのオンボーディング、デプロイ、管理、運用を行うあらゆる環境

と定義している。

そのような環境で、サイロ型とプール型の2つのデプロイモデルを要件に応じて選択する。サイロ型はテナントごとにリソースを分離し、プール型は複数テナントでリソースを共用する。

サービスの特性やテナントのティアリング（後述）に応じて、これらのデプロイモデルが混在したアーキテクチャになるのがSaaSアーキテクチャの基本だということがわかった。

その他の興味深い箇所

本で取り上げているトピックが網羅的なので、他の箇所はかいつまんで紹介する。

サービスを作るときはアプリケーションプレーンについて優先して考えがち（顧客課題を解決できるので、ある意味自然なふるまい）だが、先んじてコントロールプレーンのインフラ構築自動化やオンボーディングや認証を作るのがベターという点を指摘していたのは勉強になった。

また、ティアリング (tiering) について1章を割いているのも興味深い。ティアリングというのは、日本国内だと「プラン」と称されることが多い、サービス料金に応じた機能提供のクラス分けのこと。ティアリングはビジネスマターに見えるが、柔軟なティアリングを実現するためにはアーキテクチャも重要というのがわかった。たとえば、プレミアムプランだと他テナントと隔離された環境が使える、という要件を満たしたい場合は、必要に応じてサイロ型の方式でインフラリソース等を自動プロビジョニングできるようにしておかないといけない。

ほか、実装寄りの観点だと、テナントのIDやロールを持つテナントコンテキストや、他テナントのリソースにアクセスさせないよう制御するための資格情報を取得するようなロジックは横断的関心事なので、アプリケーションの開発者にとって体験がよい形で、それらのしくみを提供することが重要という話も納得感があった。具体的な方法としては、AOPのアスペクトやフレームワークのミドルウェアの機構を使い、実装忘れ等が減るようにするのがよい。

感想

書籍の副題に「AWSアーキテクチャパターン」とあるように、一部の章はAWSのEKSやLambdaを前提としている。とはいえ、9章「テナント分離」までの内容や14章「ティアリング」はAWSのテクノロジーにそれほど依拠しておらず、SaaSアーキテクチャで一般に考慮すべき事柄を解説している。ここだけでもインプットしておくと、マルチテナントSaaSアーキテクチャを考えるうえでの引き出しが増やせそうだと思った。

一方で、全体を通して、開発者を指して「ビルダー」¹と呼んだりする独特の言葉選びがあり、読むうえで少し癖の強さを感じた。また、原文の時点で記述が冗長な箇所も多いと想像するが、結果的に意味の取りにくい翻訳になっている箇所が少なくなかったのが惜しかった。