SaaS on AWS を成功に導くためのポイントとは ? 第 1 回

BtoB における SaaS では、高い頻度で「テナント」という概念が出てきます。ここでいう「テナント」とは、SaaS をご利用のお客様の契約の単位になります。たとえば、勤怠管理の SaaS だったとすると、会社単位で 1 テナント、という形になるかもしれませんし、大手企業が導入する場合だと、1 事業部で 1 テナントとなる場合もあるかと思います。この、テナント間でアクセスできてしまうと、他社や他組織のデータが見えてしまうことになるので、テナント間でのアクセスができないように、テナントの分離を行う必要があります。

SaaS アプリケーションは、多様なストレージ要件があるかと思います。例えば、コンプライアンス、性能要件、セキュリティなどです。これらはテナント分離と共に検討する必要があります。

SaaS においてノイジーネイバー問題と呼ばれる性能問題がよく話題にあがります。共有リソースを利用したマルチテナント構成において、とても利用率の高いテナントによってリソースを圧迫され、他テナントの性能が落ちてしまう、という問題への対処が必要になりがちです。

セキュリティにおいては、テナント共有で同一ストレージに格納した場合、アプリケーションのバグによって他テナントのデータへのアクセスができてしまうことへ予防をどのようにするのか ? という部分があります。これらを実現するために、適切なストレージを選択し、どのようにテナント単位でパーティショニングや分離をするのか、共有するのか ? どのデータはどこにどのような形で格納し、どうテナントを識別するのか ? アプリケーションレイヤーとインフラレイヤーでのセキュリティ実装のバランスはどうするか？という部分を考える必要がでてきます。たとえば Amazon RDS や Amazon Aurora ではインスタンスごと分離するのか、論理データベース・スキーマ単位で行うのか、同一テーブルに格納し行単位でセキュリティをかけるのか、などが候補になります。

新しいお客様が利用を開始する時に、新しいテナントを作成する必要があります。このテナント作成をいかに確実に素早く手間暇をかけずにできるのか、というのも SaaS におけるポイントのひとつです。特に BtoB の SaaS においては、実際に SaaS を提供する「提供者」と SaaS を使う「利用者」、そしてテナント単位での利用者や権限を管理する「テナント管理者」と、少なくとも 3 種類の登場人物が出てきます。

「提供者」が「テナント管理者」へ ID を発行し、「テナント管理者」は「利用者」の ID を発行する、というようなフローもよくあるパターンの 1 つかと思います。

こういったオンボーディングのプロセスと、テナント分離のパターンと合わせていかに自動化していくかがポイントです。ここも AWS アカウント単位での AWS Organizations や AWS CloudFormation StackSets を利用したシングルテナント自動プロビジョニングや、アプリケーションレイヤーでのマルチテナント オンボーディンングなどが候補になります。

オンボーディングで ID を発行するということは、認証基盤に ID を登録するということになります。シングルテナントであれば、各テナント用の ID 基盤があるかもしれませんし、マルチテナントであれば、全体共有の ID 基盤もあるはずです。

ID にも種類があり、前述の「提供者」「テナント管理者」「利用者」がそれぞれ異なった権限をもったログインができる必要があります。表示される画面も変わってきますし、使える機能も全くことなったものになりますので、認可をどこで行うのかもポイントになります。

また、スケーラビリティも重要です。たとえば勤怠管理の打刻のようなシステムにおいては、ほとんどすべての利用者が、朝 9 時前後に一斉に認証・打刻、を行うかもしれません。ここで認証がさばききれなかったり遅延してしまうと、UX (ユーザー体験) は格段に落ちてしまいます。AWS サービスでは Amazon Cognito をうまく使う、AD 系サービスを使う、もしくは認証系パートナーソリューションを活用する、などが候補になります。

SaaS においては、どのような料金プランにするのかも重要なポイントです。完全に利用時間に応じた課金もあるでしょうし、サブスクリプションのように階層化された機能別プランを選択し、その中では使い放題というのもあるかと思います。

プラン設定によっては、ユーザーの利用状況を正確に把握する必要があり、それを元に請求金額を算出することになります。この「ユーザーの利用状況を正確に把握する」のは難易度が高く、間違ったときには請求額が変わってしまうのでリスクも高いです。そのため、実際の利用量と請求額はなるべく疎結合にするのも検討事項になります。

請求額が確定したら、それをどのように課金・請求するかというのもポイントになります。テナントの数や料金設定によっては、請求書払は現実的ではない可能性も出てきます。メータリングでは、各 AWS サービスごとにどれくらい利用されているかを測り、その値がどのように SaaS 利用の請求額に関係してくるのかがポイントになってきます。

SaaS では、お客様がどのような利用を行っていてどのような機能を求めているのか、またどのような部分を不満に思っているのか、ということをいかに早く捉え、プロダクトの改善に生かすことができるかが重要です。直接お話を伺えればよいのですが、数多くのご意見を集めるのは難しいですし、対面だとなかなか本音を聞くのも難しく、本音を引き出すための手法も必要になってきます。

そこで、SaaS のシステムでは、いかにユーザーの行動を正確に把握できるかという部分を考え、行動を把握するためのログやメトリクスを取って蓄積していくことが重要になってきます。

サイレントマジョリティーのように、だれも見向きもしていない機能というのは話題にも上がってこないので、それを把握するのはヒアリングでは困難です。しかし、ログやメトリクスはそれを教えてくれます。そのログやメトリクスから正確な分析をするのももちろん重要です。データレイクやアナリティクスの手法を使い分析し、プロダクトや経営にフィードバックを行っていくことがとても重要です。Amazon CloudWatch や AWS X-Ray、 Amazon Managed Service for Prometheus などの AWS サービスをうまく組み合わせる、またはオブザーバビリティ系パートナーソリューションを活用するというのが候補になります。

事業のフェーズにあったアーキテクチャというのが重要と書かせていただきましたが、シングルテナントからマルチテナントへの移行は大きなシステム変更やアーキテクチャ変更が伴います。

既存のアプリケーションをすでにお持ちであれば、それをベースに SaaS 化をするのが現実的かつ低リスクかと思いますが、いきなりマルチテナントというわけにはいかない場合が多いかと思います。その場合は、まずは既存のアプリケーションをシングルテナントで提供開始し、事業的に先の見通しがたったり、シングルテナントでは運用の限界が見えてきた時にマルチテナントの検討が始まるはずです。しかし、その変更はなかなか難しく大きな改修が必要になります。

ではどのように移行の戦略を立てていけばよいのか ? というのも SaaS でのポイントのひとつです。