B2BのSaaSをやっていると、いつか必ずテナンシーの問題にぶつかります。だいたいは、大口の見込み客から「うちのデータは他社と分離できますか？」と聞かれた日です。私もこの議論には何度か立ち会ってきました。答えは基本的に2つ。顧客ごとに専用インスタンスを用意する（シングルテナント・マルチインスタンス）か、全員を1つの共有インスタンスに乗せる（マルチテナント・シングルインスタンス）か。どちらが正解ということはなく、壊れ方が違うだけです。
インフラストラクチャ設計#
シングルテナント・マルチインスタンス#
こちらの魅力は「分離」に尽きます。メリットはほぼすべてそこから生まれます。顧客のデータがそれぞれ独立した環境にあるので、セキュリティレビューやコンプライアンスの話がぐっと楽になります。デプロイの失敗や重いワークロードの影響も、全顧客ではなく1顧客で済みます。インスタンスごとに独立してスケール、チューニング、カスタマイズができて、リソースが専用なので、隣のテナントの使い方次第でパフォーマンスが揺れることもありません。メンテナンスも顧客単位で計画できるのでダウンタイムを小さく抑えられますし、料金設計をきちんとすれば、インフラコストをテナントごとの実際の使用量に合わせることもできます。
その代償は、すべてをN個ずつ運用することになる点です。リソースのオーバーヘッドは積み上がり、インスタンス間で設定はドリフトし、フリート全体でバージョンとデータを揃えること自体がひとつのプロジェクトになります。スケーリング、分離、コスト管理の問題は消えるのではなく、増殖するのです。
マルチテナント・シングルインスタンス#
こちらがデフォルトになっているのには理由があります。デプロイはひとつ、バックアップするデータベースもひとつ、本番のバージョンもひとつ。リソース効率が良く、運用はシンプルで、アップデートもセキュリティパッチも全顧客に同時に届きます。
難しさは「共有」の裏返しです。あるテナントの重い使い方が全員のパフォーマンスに響きますし、顧客ごとのカスタマイズには限界があります。そしてデータの分離はインフラではなくアプリケーションコードの責務になるため、バグひとつがテナント間のデータ漏えいになりえます。スケーラビリティのボトルネックは全顧客に同時に効きますし、「この顧客だけ」という影響範囲が存在しないぶん、メンテナンスにも余計に気を使います。
SaaS ソリューションの詳細 - マルチインスタンス vs. マルチテナントアーキテクチャ
シングルテナントはどこから始めるか#
シングルテナントで行くなら、それが「管理可能」になるか「スローモーションの災害」になるかを分けるのはツールです。30個の環境を手作業で面倒見ることはできません。
核になるのはコンテナとInfrastructure as Codeです。Dockerでアプリを全テナント同一の形にパッケージし、Kubernetesで大量のインスタンスのデプロイとスケーリングを捌きます。TerraformやPulumi、AWS CloudFormationでテナント一式のスタックをコードとして定義しておけば、31社目の顧客の立ち上げは週末の徹夜作業ではなくプルリクエストになります。VM寄りの世界にいるなら、Ansible、Chef、Puppetといった構成管理ツールが同じ役割を果たしてくれます。CI/CD（Jenkins、GitLab CI/CD）はいつも以上に重要です。すべてのリリースを、付きっきりにならずに全インスタンスへ展開しないといけないからです。
その先はプロダクトの形次第です。ワークロードによってはサーバーレス（AWS Lambda、Azure Functions）でサーバー層ごと消せます。Amazon RDSやAzure SQL Databaseのようなマネージドデータベースは、テナントごとのDBを手で管理する苦行から救ってくれます。モニタリング（Prometheus、Grafana、New Relic）はフリートを持った時点で必須になります。どのインスタンスが不調かは、顧客に言われる前に知りたいですよね。認証まわりはAuth0やOktaのようなIAMサービスに任せれば、テナントごとに作り直さずに済みます。使っている言語にも、この手の配管作業を省いてくれるSaaS向けのフレームワークやライブラリがきっとあります。ホスティングはAWS、Azure、Google Cloud Platformといった大手クラウドならどこでも問題ありません。
初日から全部を揃える必要はありません。コンテナとIaCから始めて、テナントが増えるにつれてモニタリングとIAMを足し、あとは実際に痛みを感じた順に選んでいけば十分です。