ビジネスの成長を加速するB2B SaaSのスケーリングアーキテクチャ

SaaS企業の成長サイクルを多角的に支えるアンチパターン

小笹：株式会社アンチパターンの小笹佑京と申します。本日は「ビジネスの成長を加速するB2B SaaSのスケーリングアーキテクチャ」というタイトルで発表させていただきます。

アジェンダとしては、私からSaaSについて解説したあと、アマゾン ウェブ サービスジャパン（以下、AWS社）の櫻谷さんよりSaaSコントロールプレーンについてご説明いただきます。その後は、私からSaaSアプリケーションプレーンとデプロイメントモデルについてお話しします。



小笹：本題に入る前に、私自身と会社の紹介をさせてください。私は2014年からB2BマーケティングオートメーションSaaSの開発業務に従事しておりました。2019年にアンチパターンを創業したあとも、エンジニアとして開発に携わっており、B2B SaaS歴は10年目に突入しました。

株式会社アンチパターンは「日本のソフトウェアエンジニアを憧れの職業へ」を理念とするスタートアップです。スタートアップとしては珍しく、複数のサービスを提供しています。

お客様（ソフトウェア企業／SaaS企業）の成長サイクルを「プロダクト作り」「資金作り」「組織作り」といった三つの円で捉え、そのサイクルの拡大に貢献するというビジネスモデルです。

小笹：まずはプロダクト作りを通して収益を得ることで企業価値を高め、それによって資金作りが可能となります。ソフトウェア企業の場合、成長のためには組織や人に投資をすることが重要です。組織作りに資金が回ることで、組織が高度化する。組織が高度化すれば、プロダクト作りも高度化していくでしょう。

我々は、こういった循環モデルを支援するべく、BizDevOps支援と採用/教育の領域で複数のサービスを提供しています。

また、AWSアドバンストティア サービスパートナー兼SaaSコンピテンシーパートナー（※1,2）としても活動しております。

※1…サービスパスと併せてソフトウェアパスにも参加し、AWS社の認定ソフトウェアを所有する2019年1月以降創業のスタートアップ企業として、AWSアドバンストティア サービスパートナー認定を取得するのは国内初の事例（2023年8月時点）
※2…SaaS コンピテンシーの認定保持企業は国内2社のみ（2024年11月時点）

SaaSの構成を考える上で重要な「スプリットプレーンアーキテクチャ」

小笹：ここから本題に入ります。はじめに「SaaSとは」と題してお話しします。SaaSをB2B向けのアプリケーションだと思っていらっしゃる方も少なくありませんが、我々は「SaaSとはDXを促進するための起爆剤」と捉えています。

もっと言うと、SaaSに合わせて業務プロセスを変革する「Fit to Standard」を前提としたものであり、「ある業務のベストプラクティスを提供するビジネスおよびソフトウェアのデリバリーのモデル」だと定義しています。

お客様の立場から見ると、自社開発もしくはパッケージソフトを利用する場合は、1社だけがコストやリスクを抱える形となります。しかし、SaaSを活用すれば、他社に相乗りする形でコストやリスクを抑えて高機能なサービスを享受できるようになるのです。



小笹：ただ、SaaSを提供する側としては、従来型のパッケージと比べてカバー範囲が広くなります。また、ソフトウェアの場合はお客様がシステムを構築・運用する形となりますが、SaaSの場合は提供する側がシステムを構築・運用しなくてはいけません。

契約単位をテナントだとすると、複数のテナントに同時に使っていただくマルチテナントのアーキテクチャを検討して実装・運用する必要があるのです。なお、1テナント＝1企業（法人）だとは限りません。会社や部署、個人など、サービスの内容やお客様の利用方法によって単位の数え方が異なる点には注意しましょう。

話を戻すと、事業成長の鍵を握っているのは、システム構築・運用の部分をいかに効率的にスケールさせられるようにするのか、といった部分です。



小笹：この図で見ると、縦の棒が売上の推移です。売上が増えているということは、テナント数の増加を意味しています。緑のラインはユニットコストを表しています。インフラやアプリケーションのレベルで共有効果を提供することで、テナント数の増加に伴い1テナント当たりのコストが下がります。その状態が続いて、ある損益分岐点を超えた段階で急激に利益率が高まっています。こういったスケールメリットを生かすためには、マルチテナントアーキテクチャの設計が非常に重要となります。

マルチテナントの構成をアーキテクティングするために、本日お伝えするのがAWS社が提唱しているスプリットプレーンアーキテクチャという考え方です。



小笹：スプリットプレーンアーキテクチャでは、SaaSを「アプリケーションプレーン」と「コントロールプレーン」に分けて考えます。

アプリケーションプレーンとは、お客様に直接価値を提供する機能群です。会計ソフトウェアで例えると、見積書や請求書を制作して送付するといった機能ですね。

コントロールプレーンは、SaaSに必要な管理機能を表しています。ここをしっかり設計してスケールできる状態に持っていくことが、B2B SaaSにおいては非常に重要です。

SaaSビジネスのスケールを左右する「コントロールプレーン」

櫻谷：ここからは、AWS社でパートナーソリューションアーキテクトをしている櫻谷が、コントロールプレーンについてお話しします。

小笹さんのお話にあったように、コントロールプレーンはSaaSビジネスがスケールできるかどうかを左右する重要な部分です。オンボーディングをした後にテナント管理ができるようにしたあとは、ユーザーの使用方法を分析してレポートを作成して改善のサイクルを回す。テナント管理以降のループを繰り返すことで、より良いSaaSにしていく必要があります。このサイクルが自動化されているのか、統一的な仕組みで回されているのかによって、スケールの度合いが変わってきます。

そもそも、SaaSはサービス中心のアプローチが重要なビジネスモデルです。レストランで例えると「料理＝機能」「対応の速度や水汲みなどの気配り＝サービス」だと言えます。いくら料理がおいしくても、気配りが行き届いていないレストランは繁盛しませんよね。

SaaSの場合も同様で、機能の精度を高めるだけではなく、サービスの安定性や手厚いサポート体制、継続的な機能追加、外部サービスとの連携などを実現する仕組みを整えることが重要となります。

AWSパートナーの技術支援をするなかで「コントロールプレーンは全てのSaaSに必要ですか？」と質問いただくことも多いのですが、答えは「Yes」です。システムにテナントという概念が導入されると同時に、それらを取り扱う仕組みを準備しなくてはいけません。

また「いつ実装すればよいですか？」という質問もよくいただきます。こちらについては、サービスインの時点から用意するのをおすすめしています。コントロールプレーンを後から作ろうとすると大変ですし、SaaSがスケールするための基盤となるものですから。

とはいえ、全ての機能を最初から実装する必要はありません。オンボーディングなど重要度の高いものから段階的に実装していくことも可能ですし、深く考えずにMVPから作ってみていただければと思っています。

ちなみに、コントロールプレーンのベストプラクティスがまとめられた書籍『マルチテナントSaaSアーキテクチャの構築』の日本語版が来年1月に購入できるようになります。Amazonで予約もできますので、ご興味のある方はぜひチェックしてみてください。

重要度の高いコントロールプレーンの機能5選

櫻谷：コントロールプレーンの機能のなかで、重要度の高い「オンボーディング」「テナント管理」「ID管理」「請求」「デプロイ」についてご説明します。



櫻谷：オンボーディングとは、テナントがSaaSを使い始めることができるようになるまでのセットアップ作業を意味しています。

最初は、図の左上のようにテナントがランディングページから入ってアカウントを自分で作成する、もしくは左下のようにプロバイダー側が管理画面を使ってアカウント登録をしてからパスワードをメールで通知する、というざっくりと二つのパターンがあると思います。

その後のオンボーディングについてはSaaSのシステムによって細かい部分が異なると思いますが、何にしてもまずはテナントという箱を作ってメタデータを登録しなくてはいけません。テナントに紐づく管理者ユーザーを作成するだけでなく、シングルサインオンに対応している場合はユーザーのIDと紐付ける設定も必要です。

請求管理サービスについては、サードパーティのプロバイダを使用されているケースが多いと思います。その中でテナントに対応する顧客アカウントを作って請求プランを設定する作業も発生します。

サイロモデルのような形でテナントごとにデータベースやサーバーを作成する設定になっていた場合は、テナントごとのリソースを作成しなくてはいけません。

上図では、これらの作業を自動化してオーケストレーションするためのオンボーディングサービスをフロントに置いている、といった構成です。こちらを手動で設定されている方も多いと思うのですが、自動化しておく方がテナント数が急増した際にも素早く対応できるのでおすすめです。視点を変えると、スケールの基盤を作るという意味で、オンボーディングはコントロールプレーンの中で最も重要な機能だと言えるでしょう。



櫻谷：テナント管理については、名前の通り「テナントの情報を一元管理できるようにする」というものです。管理コンソールのようなものでデータベースをクラウド操作できるようにするほか、オンボーディングの状況をトラッキングするような機能をのせることも多いと思います。

他のコントロールプレーンの機能は、ここを参照してデータを操作する形になるため、テナント管理の設計も非常に重要です。



櫻谷：ID管理については、従来のシステムとは少し異なる考え方をする必要があります。

従来のシステムでは、ID管理はユーザーアイデンティティのみでした。ユーザーを認証して、そのユーザーがどのデータにどういった操作ができるのかを認可するだけで良かったのです。

しかし、SaaSにおいてはテナントという新しい概念があります。テナントアイデンティティという形で、ユーザーがどのテナントに属しているのか、テナントが契約している契約プランは何なのか、ステータスはアクティブなのかなど、さまざまな情報が認証・認可に深く関わってきます。

そうなると、ユーザーとテナントのアイデンティティを個別に扱うのは大変になってくるため、一つにまとめてSaaSアイデンティティとして中央管理する方が良いでしょう。



櫻谷：上図では、JSON Web TokenでOIDCとOAuthの仕組みを活用しています。カスタムクレームでテナントIDの情報をユーザーIDに含めて、トークンをシステム内で引き回すことでテナントを特定できるようにする形ですね。ここで得られたトークンの中のテナントIDを見て、そのあとの認可の操作を行うというのが基本のコンセプトとなっています。

他の方法でも代替はできると思いますが、トークンを引き回す方法なら、テナント管理サービスへの問い合わせやデータベースクエリがなくなるため処理が軽量になります。またヘッダーにトークンをのせるだけでサービス間の受け渡しが可能となるため、楽な仕組みで実装ができるという例でご紹介しました。



櫻谷：請求についてやることは、大きく二つあります。先ほども少し触れましたが、まずはコントロールプレーンでオンボーディングする際にテナントの情報を連携するというのが一つ。アカウントを作成して請求先を登録し、契約しているプランに応じた請求プランの設定を行います。

もう一つは、従量課金制の料金モデルになっている場合に、アプリ側で利用料を計測してそのデータを送信するプロセスを実装する必要があります。



櫻谷：デプロイについては、一般的なCICDのプラクティスに加えて、テナントという概念を意識したカスタマイズが必要となります。

例えば、契約プランによってデプロイ方法が変わる場合があると思います。上図のようにベーシックプランを利用しているテナントについては共有のプール環境を提供し、プラチナもしくはプレミアムなどの上位プランを契約しているテナントには専用のサイロ環境を作るようなケースです。

契約プランに応じてデプロイするものや使うリソースが異なる場合は、契約プラン（テナントのコンテキスト）を把握して、CI/CDのパイプラインの中でデプロイのプロセスを変えるといったケアが必要になってきます。

SBTなどのツールキットで簡略化が吉

櫻谷：コントロールプレーンの実装についてもお話しします。

「コントロールプレーンは全てのSaaSに必要だ」とお話しした通り、どのようなSaaSであっても、コントロールプレーンの機能はほとんど同じです。中のパラメータなどが変わるくらいですし、共通化しやすいものだといえます。

また、コントロールプレーンは重要であるものの、それ自体が直接的にビジネスの付加価値を生むわけではありません。うまく実装したらユーザーに喜んでもらえるといったものではなく、実装されていなければ不利になる可能性があります。

要は、SaaS開発のとても重要なパーツである一方で、スクラッチで構築するものではないということです。

そこで、アンチパターン社のSaaSサービスのようなものを含めて、ツールなどを使って実装を簡略化するのを推奨しています。



櫻谷：上図はEKSを使ってKubernetesの環境でコントロールプレーンを作成する例です。

左側がコントロールプレーンで、Kubernetesのnamespace専用のものをきっています。右側はアプリケーションプレーンで、こちらもアプリケーション用のnamespaceできっています。

こういった形で一つのクラスターの中にnamespaceで分けて実装することもできますし、分離するような要件が必要な場合は、クラスターをわけることもできます。AWSアカウントという単位で分けて、別のアカウントにコントロールプレーンを作るというような例もあります。

セキュリティやコンプライアンス上でどのような分離をしなければいけないのか、運用チームがわかれている場合は別々にするのか、いろんな考え方があると思います。

クロスアカウントになると、オンボーディングサービスにアクセスできるAPIの権限なども必要になります。そういったところで設定の手間は増えるのですが、そこはトレードオフと言いますか。自社にはどういったモデルが合っているのかを考えていただければと思ってます。



櫻谷：またリファレンスアーキテクチャもあり、AWSでは先ほどのEKSを使ったもの以外に、KubernetesベースではないコンテナのオーケストレーションのサービスとしてECSを使ったもの、Lambdaを使用したサーバーレスで構成したサンプルもご用意しています。

なお、これら三つのリファレンスアーキテクチャについては「SaaS Builder Toolkit for AWS（SBT）」としてオープンソースで提供しています。



櫻谷：コントロールプレーンの機能だけでなく、一部のアプリケーションプレーンとの連携機能も実装されています。AWSのCDKのコンポーネントとして作られているため、CDKをお使いの場合は組み込んで簡単にデプロイすることができるようになっています。

コントロールプレーンの機能がマイクロサービスベースで実装されていて、それらがAPIで利用できますし、オプションで管理コンソールがデプロイできます。アプリケーションプレーンの方で使えるユーティリティのライブラリも入っています。二つのプレーン間のやり取りは非同期で、イベントブリッジを介したイベント連携ができるのもポイントです。ポイントソリューションという形で、これを補助するようなツールもこれから増えていく予定です。

SBTの詳細については、資料からご確認いただけますと幸いです。

事業成長や提供価値の変容に合わせて変ていく「デプロイメントモデル」

小笹：ここからは、アプリケーションプレーンとデプロイメントモデルについてご説明します。

最初にお話ししたように、アプリケーションプレーンとは、お客様に価値を届ける機能群を指します。その中で特にインフラレベルで考えなくてはいけないのが、デプロイメントモデルという考え方です。

櫻谷さんのパートで「サイロ」や「プール」という単語が出てきたと思いますが、それについても改めてご説明します。

小笹：サイロとは、テナントごとにコンピュータリソースやデータベースなどを分けるようなモデルです。上図はサイロ型のマルチテナントアーキテクチャですね。当然、この場合においてもコードベースは一つに行っていくというのが重要で、テナントの分離境界が明確にあるのが特徴です。



小笹：プールは、コンピュート層やデータストアの部分で、共用のインフラであってもテナント分離は論理的に行うというモデルです。共有効果が非常に高いという意味では、事業上のメリットが出ると。



小笹：サイロとプールを組み合わせてブリッジ型のようなアーキテクチャにすることもできます。

データの分離については、データベースのサイロ型や一つのデータベースの中でスキーマやテーブルで分離するパターンもあります。もしくは、PostgreSQLなどのローレベルセキュリティを活用して、行レベルで分離することも可能です。こちらについては、セキュリティ要件や運用負荷などのバランスを見ながら選定していきましょう。

デプロイメントモデルについてもベストプラクティスがあるわけではなく、コントロールプレーンの概念も含めてどれほどの負荷がかかるかを計算しながら、都度考える必要があります。



小笹：またSaaSのアーキテクチャを検討する上では「ビジネス」「テナント」「技術」という3つの要件が重要だと考えています。

特にビジネス要件とテナント要件が重要です。例えば、SaaSの対象市場は想定テナント数を定義することにつながりますし、エンタープライズを攻めていくのであれば、コンプライアンスセキュリティに合わせていかなくてはいけないでしょう。

お客様側からテナントの分離レベルを求められる可能性もあるため、技術的なパフォーマンスだけではなく、事業計画やビジネスプランを理解した上でアーキテクティングしていかなくてはいけません。後から変えるのは難しい部分であるため、最初からしっかりと検討するべきだと思います。

運用上の課題としてよくあるのが、サイロ型で増えていってしまうパターンです。テナントごとの状況はモニタリングしやすいというメリットがある一方で、集積効果によるコストメリットが得られない上に運用コストがかかってきます。

かといって、プール型にすれば解決するものではなく。プール型の場合はノイジーネイバーという問題が発生します。



小笹：こういった問題を防ぐためには、テナントごとのリソース使用量を可視化してノイジーネイバーを検出する必要があります。またリソースを効率化するために、非同期化が可能なものはオフピーク時に実行するようにするのも大切です。テナントもしくは契約プランごとに何かしら制限を設ける必要もあります。

サイロかプールのどちらかではなく、ハイブリッドモデルを採択する方法もあります。デプロイの説明で櫻谷さんがお話しされていたように、上位プランであれば他の影響を受けないようにサイロ型にして、ベーシックプランはプール型にする、といった選択も可能です。

マイクロサービスの場合は、発展的なアプローチとしてMixed Modeデプロイメントモデルという選択肢もあります。



小笹：上図は購買のSaaSを想定しています。オーダーはコンピュート層がサイロでデータがプール。プロダクトは両方プールです。このように、マイクロサービスなら各サービスでどのようなモデルにするかを選択できます。この選択は非常に重要なポイントとなりますし、デプロイメントモデルは事業の成長や提供価値の変容に合わせて継続的に変更を加えるものだという覚悟を持つべきだと思います。

デプロイメントモデルをしっかり設計するためには、テナントのルーティング方式についても整えなくてはいけません。例えば、ドメイン駆動型やデータ駆動型など、さまざまなパターンがありますよね。各サービスの特性に合わせてどういったモデルでテナントのルーティングを設計するかという部分が、デプロイメントモデルの柔軟性を担保する部分でもあります。

昨今は生成AI活用のSaaSにおいて、デプロイメントモデルがAWSアカウントレベルにブリッジするパターンもありますし、デプロイメントモデルは今後も継続的に発展していくと思います。

アーキテクトとしては、新しい情報をキャッチアップをしながら事業の状況や技術要件を照らし合わせてベストなアーキテクチャを考えることが求められるのではないでしょうか。

コントロールプレーンはSaaS開発の第一歩

小笹：最後にまとめます。

SaaSはある業務に対するベストプラクティスを提供するビジネスおよびソフトウェアデリバリーのモデルであり、コントロールプレーンはSaaS開発の第一歩です。

アプリケーションプレーンとデプロイメントモデルは、お客様に価値を届け続けるために変化していくものであり、正解はありません。正解がないからこそ、SaaS開発はエンジニアにとって面白いものなのだと思います。またSaaSとしての価値を最大限に発揮するためにはエンジニアもビジネスについて理解することが非常に重要、ということもお伝えしておきたいです。

最後に宣伝させてください。アンチパターンでは、コントロールプレーン部分をSaaSで提供する「SaaSus Platform」を提供しています。このサービスを導入いただくことで、アプリケーションプレーンに集中できるようになるというものです。多くのSaaSに関わってきた我々だからこそできるプロダクトデザインだと自負しておりますので、関心のある方はぜひサイトからチェックしてみていただければ幸いです。


▼SaaSus Platform
https://saasus.io/

アーカイブ動画も公開しております。こちらも併せてご覧ください。

https://findy-tools.io/events/465860d2addf0cfc8e4b