【第04回】Deep Dive マルチテナントSaaS on AWS - 第3章振返り

はじめに

本記事では、「マルチテナント SaaS アーキテクチャの構築 ― 原則、ベストプラクティス、AWS アーキテクチャパターンの第 3 章「マルチテナントのデプロイモデル」の内容を振り返り、自分なりに要点を整理していきます。

3 章では、マルチテナント SaaS アプリケーションで取り得る様々なデプロイモデルを紹介し、それらのモデルの特徴と、SaaS アプリケーションに及ぼす影響を整理していきます。

デプロイモデルとは

ここでの「デプロイモデル」とは、様々な形態のマルチテナント SaaS アプリケーションの要件に対応するために、リソースをどのように配置するかを表現するための概念です。
非常に簡単に例を挙げれば、各テナントごとに占有リソースを用意するか、全テナント共有のリソースを構築すべきか、といった事項を検討するための概念です。

全てのアプリケーションにとって最適な唯一のデプロイモデルは存在せず、各自の SaaS アプリケーションにとってどのモデルが最適であるかは様々な要因によって決定されます。
例えば既存のソフトウェアをマルチテナント SaaS アプリケーションに移行する場合、市場投入までの時間やレガシー技術によって取り得るデプロイモデルに制約が設けられる可能性があります。一方で、ゼロからマルチテナント SaaS アプリケーションを構築する場合であれば、より顧客体験に比重をおいてデプロイモデルを検討出来ます。また、どのような背景の SaaS アプリケーションであっても、ティアリングやコスト・運用効率といった要素は共通してデプロイモデルを左右する検討事項となります。
加えて、デプロイモデルは顧客の需要やビジネス戦略の変化といった時間の経過に伴って進化させていく必要があるという点も重要です。

サイロモデルとプールモデル

ここでは、専用リソースと共有リソースを分類する方法をより詳細に説明するために、「サイロ」と「プール」という用語が新たに導入されます。
サイロはリソースが特定のテナントに専用に割り当てられているモデルであり、プールは 1 つまたは複数のテナントがリソースを共有するモデルを意味します。
下図は複数のマイクロサービスでサイロモデルとプールモデルが混在して利用されているアーキテクチャ図です。

これらの用語は、テナントがアーキテクチャの構成要素にどのように割り当てられるかを明確にし、テナントに対してリソースの集合がどのようにデプロイされるかを説明するために使用されます。

各デプロイモデルの特徴

フルスタックのサイロデプロイモデル

フルスタックのサイロデプロイモデルとは、テナントごとに全てのリソース群が完全にサイロ化されたデプロイモデルです。
このモデルは、SaaS の目指すべき俊敏性や運用・コスト効率性に反しているように感じる一方、全ての環境で同一バージョンのアプリケーションを実行している限り、一部の SaaS の原則は引き続き遵守していると言えます。

このモデルが適していると言える典型的なケースは、コンプライアンスやレガシー技術を考慮する必要がある場合です。
規則が厳しい業界向けの SaaS では、(多少のコスト効率性を犠牲にしても、)アーキテクチャを簡素化し、コンプライアンス要件への対応を容易にするのが賢明である場合があります。
また、既存のレガシーシステムを SaaS アプリケーションとして移行する場合にも、フルスタックのサイロデプロイモデルは既存システムの改修を最小限に抑え、移行を迅速化出来るというメリットが考えられます。
フルスタックのサイロデプロイモデルはまた、ティアリング戦略としても利用可能です。例えばプレミアムなティアリングの一種として、テナントに完全に個別のリソース群を提供する、といった具合です。

このデプロイモデルの主な短所は以下の通りです。

• コントロールプレーンの複雑性 : 単一のコントロールプレーンから各テナントのフルスタックのサイロリソースを全て管理する必要があるため、コントロールプレーンの複雑性が増します
• 拡張性への影響 : フルスタックのサイロデプロイモデルでは、テナント数の増加に比例してリソースをプロビジョニングする必要があり、テナント数が数百、数千と増加した際に効果的なリソースの拡張が難しくなります。それ故、一般にテナント数が膨大になる B2C 向けの SaaS アプリケーションではフルスタックのサイロデプロイモデルは実用的ではありません
• コスト面への影響 : 各テナントのために専用のリソースが必要であるため、コストが嵩みます。また、前述したコントロールプレーンの複雑性に伴い、運用面のコストも増加する可能性があります。一般にはこのコストを補うために、高いベースの価格設定にするか、前述したような特別なティアリングとプライシング設定を設ける等する必要があります。
• ルーティングの考慮事項 : テナントコンテキストに基づいて、アプリケーションへのトラフィックを適切なサイロリソースにルーティング出来る仕組みを検討する必要があります。具体的には、各テナントごとにサブドメインを設けるか、共有ドメインを使用しつつリクエストにテナントコンテキストを注入するか、といった具合です。

一方で、長所もあります。

• 可用性と影響範囲 : 各テナントごと専用の環境にリソースがデプロイされるため、インフラストラクチャやアプリケーションの障害をより狭い範囲に限定することが期待できます。また、アプリケーションを一部のテナントにカナリアリリースすることで、リリースに伴う不具合の影響をより限定することが可能です。
• よりシンプルなコストの配賦 : 各テナントごとに専用のリソースが割り当てられていることから、テナントごとのコストを計測することが容易になります。

AWS 上でフルスタックのサイロデプロイモデルを実現する場合、テナントごとにアカウントを分けるモデルや、テナントごとに VPC を分けるモデルが考えられます。

フルスタックのサイロデプロイモデルにおいて重要なマインドセットは、例えばテナントごとに専用の環境が用意されているとしても、それをテナントごとにアプリケーションをカスタマイズして提供出来ると考えるべきではない、という点です。アプリケーションやインフラストラクチャを更新する必要がある場合は、全てのテナント環境にその更新をリリースするべきです。
あくまでも SaaS の最大の目的は、テナントをまとめて管理・運用して、ビジネスの俊敏性やイノベーション、規模の経済性や効率性を実現する点にあります。

フルスタックのプールデプロイモデル

フルスタックのプールデプロイモデルは、アプリケーションプレーン上のリソース全てが共有インフラストラクチャとして、全てのテナント間で共有されるデプロイモデルです。
このモデルは、第 1 章で述べたマルチテナント SaaS アプリケーションの目的である俊敏性や効率性に直感的に適用していると感じられます。
このデプロイモデルでは、テナントコンテキストの役割が非常に大きくなります。フルスタックのサイロデプロイモデルでは、主にテナントを専用のスタックにルーティングする用途でのみテナントコンテキストが使用されていましたが、フルスタックのプールデプロイモデルでは、データへのアクセス、メッセージのロギング、メトリクスの収集等あらゆる面で、テナントコンテキストとのマッピングが不可欠になります。

フルスタックのプールデプロイモデルの特徴は、基本的にはサイロデプロイモデルとの真逆になります。

• 分離 : サイロデプロイモデルでは実現が比較的容易だったテナント分離の要件が、プールモデルではより複雑になります。
• 可用性と影響範囲 : フルスタックのプール環境で発生する障害や問題は全てのテナントに影響を及ぼすことから、その際の SaaS ビジネスに与える悪影響も大規模になります。
• ノイジーネイバー : 一部のテナントによる突発的なトラフィックの増加によって他のテナントの体験が損なわれる、所謂ノイジーネイバー問題が、フルスタックのプールデプロイモデルではより深刻な問題となります。リソースの過剰なプロビジョニングをせず対応するには、リソースの柔軟なサイジングや伸縮設定が必要になります。
• コストの配賦 : フルスタックのプールデプロイモデルでは、リソースの使用状況とコストとの関連付けをテナントレベルで行うことは非常に難しい課題となります。
• 運用の簡素化 : 全てのテナントが共有インフラストラクチャを利用するフルスタックのプールデプロイモデルでは、より簡素化された運用体験を実現可能です。また、アプリケーションやインフラストラクチャの更新処理もよりシンプルに実現可能です。

ハイブリッドなフルスタックのデプロイモデル

フルスタックのサイロデプロイモデルとプールデプロイモデルは、互いに排他的という訳ではなく、両者を同時にサポートすることがビジネス上の価値に繋がるような場合があります。
例えばフルスタックのプールデプロイモデルのアプリケーションをベーシックティアとして提供し、フルスタックのサイロデプロイモデルをプレミアムティアとして提供する、というイメージです。
前者のティアでは大多数の顧客のために SaaS アプリケーションを安価に提供する一方、ノイジーネイバー問題やコンプライアンス要件を気にする一部の顧客のために、専用の SaaS アプリケーション環境をより高価な価格で提供する、といった具合です。

混合モードのデプロイモデル

ここまではフルスタックのデプロイモデルの特徴を整理してきましたが、現実のマルチテナント SaaS アプリケーションではしばしば、柔軟なビジネスモデルを実現するために下図のようにより細かな粒度でサイロデプロイモデルとプールデプロイモデルの混合が採用されることがあります。

ポッドのデプロイモデル

ここでの「ポッド」とは、Kubernetes の Pod の概念とは別物であり、「テナントの集団をデプロイの何らかの単位にグループ化する方法」のことを指します。

このようなデプロイモデルは以下の様な状況に対応するために有効となります。

• SaaS アプリケーションをクラウドの特定のアカウント内にデプロイしており、テナントの増加に伴ってリソース数がクラウドの設定している上限値に抵触するような場合
• 地理的な要件やレイテンシーの問題で、地域ごとに異なるポッドを設けたい場合
• ノイジーネイバー問題を始めとする、テナント間の影響を減らすために、ポッド内のテナント数を一定に保ちたい場合

ポッドのデプロイモデルは上記のような問題に対応出来る利点がある反面、管理や運用の面で複雑性と非効率性をもたらすため、マルチテナント SaaS アプリケーションの様々な課題に対処するための近道として捉えるべきではありません。

終わりに

この章では、様々なタイプのデプロイモデルを取り上げ、その特徴を整理しました。
どのデプロイモデルを、どの様な粒度で採用すべきかは、各 SaaS アプリケーションの特徴やドメイン、ビジネスモデル、コンプライアンス等様々な要因を考慮して決定していく必要があります。
また、どのデプロイモデルであっても、コントロールプレーンを通して一元化された管理・運用を実現することと、実行されるアプリケーションのバージョンは常に単一であるべきというマルチテナント SaaS アプリケーションの原則は遵守すべきです。