アーカイブ動画

「マルチテナントSaaS」って何ですか？

今回マルチテナントSaaS構築の題材となった「ENGAGE TAG」は、Microsoft Teams向けの従業員コラボレーションSaaSであり、Azure上に構築されている。ちなみに、「マルチテナントSaaS」のマルチテナントとは、複数のユーザーが同じサーバーやアプリケーション、データベースなどのシステムやサービスを共有して利用する方式である。

SaaS開発に役立つAzureのPaaSサービスとは

日本マイクロソフト株式会社　パートナー事業本部　パートナー技術統括本部
第二アーキテクト本部本部長　佐藤 直樹氏

最初に登壇した日本マイクロソフト佐藤氏は、現在パートナー向けにData＆AIおよびApp Innovationに関する技術部隊をリードしており、これまで50以上のSaaSを見てきた。

佐藤氏は、SaaSは以下の図のようなパターンやビルディングブロックで表すことができると語る。例えば、あるコンシューマサービスAを分解する場合、ブラウザに対してWebと、一部にWebAPIを用意してJavaScriptで動的に更新する構成を採用する。

機能面では、購入してもらいたい人を結びつけるパートとしてマーケットプレイスを用意し、それを通じて収益化するビリングの仕組みを設ける。マーケットプレイスにある商材に対しては、様々なコメントと返信ができるようコラボレーションの構成とする。

SaaS開発を始める際は、大きく2つの観点で考える必要がある。

まずは人とプロセス、つまり顧客に対してどのようにサービスを提供するのかという観点。ここでは課金、チーム構成、コミュニケーション戦略、マーケティング戦略、セキュリティとコンプライアンス、顧客のオンボーディング、顧客環境のマイグレーションなどの検討事項が挙げられる。

次に作り手側としての技術的な観点。テナント設計と可用性と復元性、データアクセスモデル、アーキテクチャ更新などの検討事項が挙げられる。

テナント設計における検討事項

テナントの代表的な設計例には、シングルテナントとマルチテナントがある。シングルテナントは1つのシステムで1つの企業ユーザー向けのサービスが占有できる状態になる。一方のマルチテナントは、1つのシステムで複数の企業ユーザー向けのサービスが同居する状態になる。

どのプラットフォームを選定するかについては、クラウドベンダーとの共同責任のモデルで考えていく必要がある。例えばオンプレミスで設計した場合は、すべてのレイヤーにおいて開発者自身が責任を担保する必要がある。

IaaSは、物理ホストの上部に載るOS以降は開発者側が責任を担保する。PaaSは、OSはベンダーが責任を担保し、その上に載ってくるネットワークコントロールやアプリケーション、アカウントアイデンティティはアプリケーション開発者とクラウドベンダーの共同責任となる。

ここで佐藤氏が紹介した、アプリケーションを開発する際に役立つ代表的なリファレンスアーキテクチャは、マイクロソフトの学習サイトで公開されている「AzureのマルチテナントSaaS」だ。

トラフィックのロードバランサー機能を提供する「Azure Front Door」により、リージョン障害が発生しても、別リージョンにフェイルオーバーできる。CRMソリューションの開発やコンテンツ管理システムで複数ユーザーに配信するようなサービスのアーキテクチャとして活用できる。

Microsoft AzureのPaaSプラットフォーム

Microsoft Azureが提供するアプリケーションプラットフォームは、一番上から開発ツール、コンピューティング、データおよびデータアナリティクス、セキュリティとコンプライアンスと4つのレイヤーで構成されている。

この中でもコンピューティングとデータのレイヤーについて考える際に、2つの観点が重要になる。それは「コントロール」と「開発効率」だ。共同責任の上位の部分を自由にコントロールするのであればIaaS環境となるので、Azure Virtual Machines（Azure VM）が活用できる。

「開発効率を重視するならPaaS/コンテナ環境。さらに高めたいのであれば、PaaS/サーバレス環境が選択できます」（佐藤氏）

Azureが提供する代表的なアプリ実行環境をプラットフォームに対する自由度と開発速度で表すと、次のようにマッピングされる。

自由度と開発速度だけではなく、どんなOSや言語で開発できるのかも気になるところだ。それも図に表すと次のようになる。ちなみにAzureは、すべてのPaaSプラットフォームでOSS Language Supportの項目にチェックが入っている。つまり、すべてのプラットフォームであらゆる言語をサポートしている。

このようにたくさんあるAzureのPaaS。どこから始めればいいのかについて、佐藤氏は『Azure App Service』から始めることを提案している。

「Azure App ServiceはフルマネージドのWebアプリケーションをホスティングするPaaS。あらゆる言語で開発することができ、Windows環境もしくはLinux環境にアプリケーションをホストすることで、アプリケーションが実行できます」（佐藤氏）

Azure App Serviceの最大の特徴は、オートスケールやロードバランシング、パッチマネジメントを意識することなく、開発に集中できるフルマネージド。これにより運用コストの削減も可能になる。GitHubなどDevOpsに関連する様々なサービスと緊密に連携するため、DevOpsの両方にとって高い生産性が期待できる。

また、バックアップとリカバリーのメカニズムも提供されている。そして様々なエンタープライズグレードを用意しているのもAzure App Serviceの特徴だ。

佐藤氏はさらに直近1年間で代表的な更新更新を紹介した。マネージド証明書の一般提供、さらにサービスダウンのリスクを軽減する可用性ゾーンのサポートや計画メンテナンスの通知などが挙げられる。

「月1回の計画メンテナンス前に、Service Healthにて通知されます。ベンダー側のパッチマネジメントによってアプリケーションが動かなくなる可能性をチェックに役立つので、SaaSの連続稼働にとって非常に重要です」（佐藤氏）

データ層はどのように選択していけばよいのか。SaaS開発であれば、IaaSのVMの上にデータベースを導入する方法ではなく、マネージドデータベースを組み合わせながら、アプリケーションを作っていくことが得策だ。

マネージドデータベースの選択は、構造化データか半構造化データ化、非構造化データというデータ形式、またトランザクションの有無によって変わる。例えば、ACIDトランザクションが必要な場合はSQL型（RDB）一択となる。

RDBはテーブルやデータ構造が厳密、構造化データ、整合性を意識した複数データ単位での検索・更新が得意。1箇所での更新とレプリケーションによる分散読み取り、高可用性の構造という特徴がある。

AzureではMySQL、PostgreSQL、MariaDB、SQLファミリなどが選択できる。また半構造化データや非構造化データ、複数箇所でのデータ更新・参照が得意、低い整合性で最終的に整合性がとれる、システム全体で高い整合性をとるような場合は、NoSQLを選択する。AzureではCosmos DBが選択できる。

佐藤氏はさらに、アプリケーション要件を詰めながら技術選定をしていきたい人や、クラウドレディな状態での開発体制を構築したい人に役に立つドキュメントとして、「Azure Well-Architected Framework」と「Microsoft Cloud Adoption Framework for Azure」を紹介した。

Azure Well-Architected Frameworkはワークロードの品質向上に使用できる一連の基本原則。信頼性、セキュリティ、コストの最適化、オペレーションあるエクセレンス、パフォーマンス効率という5つの柱で構成。業界の標準や条件に従って、Azureアーキテクチャのベストプラクティスがまとめられている。

Microsoft Cloud Adoption Framework for Azureは、組織がクラウドで成功を収めるために必要なビジネス戦略、およびテクノロジー戦略の作成と実装を支援することを目的とした実証済みのガイダンスである。

ビジネス上の意思決定者が短期的、および長期的な目標を無事達成するためのベストプラクティスやドキュメント、ツールが提供されている。

最後に佐藤氏は次のように呼びかけ、セッションを締めた。

「SaaSを作るときは、『何を作るか』×『技術×人×プロセス』を意識すること。Microsoft Azureは、SaaS開発のためのクラウドサービスやガイドラインを包括的に提供しているので、ぜひご活用ください」（佐藤氏）

ISIDが開発したマルチテナントSaaS「ENGAGE TAG」とは

株式会社電通国際情報サービス
Xイノベーション本部　通山 拓馬氏

続いて登壇したのは、ISIDの通山氏。Xイノベーション本部で新規事業創出プログラムの企画・運営に参画。自らもプログラムに参加し、「ENGAGE TAG」の事業創出に向けてマーケティング活動に従事している。

改めて説明すると、ENGAGE TAGはMicrosoft Teams向けの従業員コラボレーションSaaSであり、「タグでプロフィールを作成＆社内共有できるアプリ」である。ENGAGE TAGで知らなかったスキルや仲間を発見し、スキルの認め合いや新たな気づき・信頼の見える化により、組織横断型のチーミングが活性化し、貢献している人への正当な評価がなされるという世界観を目指している。

ENGAGE TAGは、2019年8月に開発プロジェクトをスタートし、2020年12月から開発を開始した。2021年8月にβ版、2022年4月に製品版の提供を開始、同年9月にはメジャーアップデートも実施した。

マルチテナントSaaSを開発するにあたっては、「変化に強いアーキテクチャが必要となる」と通山氏は語る。

「事業の変化や顧客の要望、新しいアイデアなどで次々とシステム改編要望がやってくる。それに対応するような設計実装をする必要があります」（通山氏）

SaaSはパフォーマンス効率やコスト最適化、オペレーションエクセレンス、信頼性、セキュリティという要件が求められる。通山氏は取り組むべきポイントとして、「テナントモデル」「テナントのライフサイクル」「価格モデル」「使用量の測定」「更新プログラムの展開」「テナント要求へのマップ」「ID」「ドメイン名」を抽出。今回はこの中から、テナントモデルに絞って語られた。

テナントモデルの選択の観点

テナントモデルには、「シングルテナント」「マルチテナント」「ハイブリッドテナント」という3つのパターンがある。

シングルテナントはテナントごとにリソースを占有利用するモデルで、AWSではサイロモデルと呼ばれる。マルチテナントは全テナントでリソースを共有利用するモデルで、AWSではプールモデルと呼ばれる。そしてシングルテナントとマルチテナントを合わせたモデルが、ハイブリッドテナント。特定のテナントのみリソースを占有利用でき、AWSではブリッジモデルと呼ばれる。

3つのモデルをコスト観点でのメリット・デメリットで比較してみる。

「マルチテナントはリソースを全テナントで共有するため、無駄なくリソースが使えます。一方のシングルテナントはテナントに比例して線形のコストが増えるため、コストではマルチが有利です」（通山氏）

パフォーマンス観点で比較すると、シングルテナントは他のテナントの影響を受けないが、マルチテナントは一部テナントが他のテナント分のリソースを使い尽くすリスク、いわゆるノイジーネイバー問題がある。そのためパフォーマンスではシングルが有利になる。

デプロイ観点ではどうか。マルチテナントであればデプロイは1回で完了する。一方のシングルテナントはテナントの数だけデプロイが必要となり、ロールアウト・ロールバックに時間がかかるため、並列実行の作り込みが必要になる。つまり、デプロイではマルチが有利になる。コンプライアンス観点では、テナントごとにリソースが独立しているシングルテナントが有利になる。

図に表すとわかるように、どのモデルが最適かはサービス次第というわけだ。

また、ユーザー観点でも要件は変わる。エンタープライズのお客さま対象のSaaSであれば、「他のテナントと物理的に分離したい」「高いセキュリティが必要」「高い可用性が必要だが、費用は高くても良い」という要件となるかもしれない。

ビジネス成長の観点でも、どのテナントを選ぶかは変わる。どのコースにするか、あらかじめイメージしておくことも重要だ。

テナントモデルを考えるコツは次の4点。状況に応じて、最適なモデルを見直すことも重要になると、通山氏は強調する。

1. 一つのモデルに固執せず、必要に応じて組み合わせる
2. ビジネス要件からトレードオフを理解した上で決める
3. 事業ステージに応じて、随時アーキテクチャの見直しを行う
4. マルチテナントモデルの課題を認識し、対策を行う

AzureのPaaSの分離モデル

Azure App Serviceの分離モデルには、以下の図のように3パターンある。テナント占有モデルはパフォーマンス面で有利に使えるが、運用負荷とコストが高くなる。リソース統合モデルは複数のテナントで1つのApp Serviceを共有するため、運用負荷・コストは低いが、ノイジーネイバーのリスクはある。

そしてAzureで特徴的なのが、半分離モデル。App Service Planは共有するがApp Serviceが異なるため、異なるソースのデプロイが可能になる。だが、「一見、良さそうに見えるが運用負荷は高いので、飛びつかないこと」と、通山氏は釘を刺す。

Azure Functionsというサーバーレスソリューションの分離モデルは、先のApp Serviceと仕組みは同じで、3パターンのオプションがある。
データ層の分離モデルは、インスタンスレベルで分離できるものから、データベースレベル、コンテナレベル、さらにはデータレベルで分離できるオプションがある。

コンテナレベルの分離モデルではスループットをテナント単位で設定できる専用スループットとテナント間でスループットを共有するパターンの2種類に細分化される。

SQLデータベースの分離モデルは「インスタンス分離」「データベース分離」「データベース分離（エラスティックプール）」「シャード分離」「テーブル分離」「データ分離」の6種類のオプションがある。

Storageの分離モデルはリソース分離、コンテナ分離、フォルダ分離の3種類のオプションがある。

ENGAGE TAGのテナントモデル

ENGAGE TAGの要件は、「Teamsアプリ」「開発体制は少人数」「新規事業でゼロから開発」「マーケットは国内」「デプロイはシンプルに」「ノイジーネイバーは許容」「コストは安く」「スケールしやすく」を踏まえて設計することとなった。

開発の基本原則は「シンプル」「マイクロサービス化」「コアvs非コア」。最後のコアvs非コアとは、コアの機能にフォーカスし、非コアでは極力サードパーティを活用するという意味である。

テナントモデルはマルチテナント型、Functionsはリソース統合型を採用。Cosmos DBの分離モデルはデータベース分離を採用した。データベース単位でスループット設定ができること、同じコンテナ構成ができ、管理しやすいという理由からだ。SQLデータベースはテーブル分離型を採用した。

「公式ドキュメントではテーブルでの分離はアンチパターンとされているが、総合的に判断してあえて採用しました」（通山氏）

ストレージはコンテナ分離型を採用。コンテナ単位でSASを発行できるため、テナント間のアクセス制御ができることと、オンボーディングの負荷を最小限にできるからだ。以下のように、マルチテナント型で非常にシンプルな構成となっている。

最後に通山氏はCI/CD・CosmosDB設計・ID管理・Application Gatewayのトピックについて触れ、「AzureのApplication Gatewayはオススメ！」とセッションをまとめた。

様々な質問が寄せられ、充実のQ&Aタイム

Q&Aでは様々な質問が参加者から投げかけられた。いくつか紹介する。

Q．マルチテナントよりもシングルの方がパフォーマンス有利とのことだが、ケースによっては逆転するのか

通山：一般的にシングルの方が個別にスケールの設定ができるので有利だと思います。

佐藤：パフォーマンスをどう見るのかによって変わるかもしれません。シングルテナントは想定される性能をしっかり出すことができますが、マルチテナントでは同時利用ユーザーの増減によってパフォーマンスは変わります。

つまりエンドユーザーから見たときは他にアクセスする人が少ないと、パフォーマンスは良いと感じますが、多くの人が平均的にアクセスしても安定したパフォーマンスが得られるということは言えないと思います。

Q．セキュリティ面で工夫している点は何か

通山：データ分離については、かなり練って実装しました。もう1つは、Azure ADによる認証をかけていること。この2点でセキュリティを担保できていると思います。

Q．マルチテナントで運用・提供する場合、セキュリティ面で気をつけていること

通山：アプリ実装においては、開発者がミスしそうなモデルは採用しないようにして実装しました。

佐藤：認証レベルでは独自認証を実装するとセキュリティホールになりやすいので、IDプロバイダーのサービスを活用することをお勧めします。アプリケーションレベルでは、動的にアクセスをコントロールするクラスの中に、直接文字を入れることを避けること。データレベルでは、a,b,c,d,eといったデータではなく本番を意識した明確にテストのしやすいデータを入れてテストすることで、データアクセスのセキュリティを担保しやすくなると思います。

Q．ENGAGE TAG運用の自動化などで工夫されている点について

通山：Azure DevOpsの活用することで、CI/CDはうまく機能していると思います。

Q．Azureの各コンポーネント自体のアップデートやスケール設定、Azureの運用観点で注意している点について

通山：PaaSを使っているので、アップデートはベンダーに任せています。スケール設定は自動にしています。また、CPUなどのメモリの監視も入れて、閾値を超えていないかといった監視をしています。

電通国際情報サービス株式会社
https://www.isid.co.jp/

電通国際情報サービス株式会社の採用情報
https://career.isid.co.jp/