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

2020-04-02
ビジネス x クラウド

矢ヶ崎 哲宏

こんにちは ! ふだんは SaaS (Software as a Service) のことばかりに関わっているパートナーソリューションアーキテクトの矢ヶ崎です !

このたび、SaaS on AWS のテーマで連載をさせていただくことになりました。今回は初回ということで、概要とポイントを書かせていただき、次回からは各テーマに Dive Deep して行きたいと思います !

昨今、SaaS をテーマとしてお声がけをいただくことが多くなってきており、日本にも SaaS の波がやってきているということを、ひしひしと体感しております。SaaS 担当としてはとても嬉しい限りです。しかし、これから SaaS 提供をはじめたいという時に、どこから手をつけてよいかわからない、どのような点を注意すればよいかわからない、というご相談をいただくことが多いです。

SaaS というのは提供形態のお話なので、業種業態や事業のステージ・状況によって気をつける部分というのは変わってきます。たとえば、これから SaaS をはじめるのに、いきなり 5 年先の利用に備えてアーキテクチャを考えていくというのは危険です。SaaS は利用をはじめやすいのが特徴ですが、それは他社 SaaS への乗り換えもしやすいということにもなります。そのため、継続的改善を行っていかないと解約 (チャーン) され乗り換えられてしまう可能性があがります。5 年先の利用を考えるのは重要ですが、そのアーキテクチャを最初から考えるのではなく、5 年後まで継続的改善をし続けそのアーキテクチャにしていく「計画」を練る方が重要です。テクノロジーの進化はとてもはやいので、5 年後には想像もしていないようなアーキテクチャになっているかもしれません。

img_saas-on-aws_02

それでも、現時点で SaaS のかたちでサービスを提供する場合には、共通の特徴というものもあります。これらを、ご自身のサービスの状況に踏まえて検討していくと、SaaS をうまく展開していくための近道になるかもしれませんので、我々 SaaS 担当としてはこれらを知っていただきたいと思います。以下にポイントとなる部分の例を書いていきます。


テナント分離 :

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

テナント単位にアプリケーションもインフラも分離し提供するのを、ここでは「シングルテナント」提供と呼び、テナント共用でアプリケーションもインフラも使って提供するのを「マルチテナント」提供と呼びます。

テナントごとに個別に管理すると分離レベルがあがり、他社に影響を与えなくなるのですが、管理が煩雑になります。たとえば、100 テナントくらいまでは個別に管理できたとしても、サービスがとても好評で 10,000 テナントになったとしたら、なかなか現実的に管理するのは厳しいかと思います。そのため SaaS のスケールを考えつつ、テナント分離も考える必要がでてきます。AWS のサービスでは、マルチアカウント分離、VPC 分離、ネットワーク分離などの粒度が候補になります。

img_saas-on-aws_01

データパーティショニング :

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

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

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


オンボーディング :

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

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

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


認証・認可 :

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

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

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


料金プランと課金、メータリング :

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

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

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


メトリクスと分析 :

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

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

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


シングルテナントからマルチテナントへの移行 :

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

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

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


まとめ

このように、SaaS 特有の考慮事項だけでも結構な量があります。これらをゼロから個別に考えていくのは気が遠くなりますので、どのようなプラクティスがあるのかをご紹介し、それをいかに自社 SaaS に活かしていただくかがポイントになってきます。

次回からは、SaaS 担当のソリューションアーキテクトたちが、みなさんのご意見をもとにご興味が多そうなものから順番に、各項目ごとにより具体的な内容を書いていきたいと思います ! お楽しみに !

img_saas-on-aws_03

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

プロフィール

photo_yagasaki_akihiro

矢ヶ崎 哲宏
アマゾン ウェブ サービス ジャパン株式会社
SaaS パートナーソリューションアーキテクト

幼少時のマイコン時代からプログラミングを続け、近年では中国での IaaS サービス立ち上げや、マルチリージョン・マルチサービスの統合インフラ設計・構築などに従事。その後、SaaS ベンダーでの技術責任者を従事。現在はパートナーソリューションアーキテクトとして、今までの経験から AWS の持つ多くのサービスを SaaS 提供のステージに合った形でのアーキテクティングを支援。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する