Amazon Web Services ブログ
AWS SaaS Boost を利用したモノリスアプリケーションの SaaS 移行
AWS SaaS Factory で Principal Partner Solutions Architect を務める Tod Golding による記事です。
SaaS (Software-as-a-Service) モデルへの移行は多くの企業にとって魅力的ですが、新しいマルチテナントアーキテクチャへの移行に必要な時間、労力、投資は大きな障壁となる場合があります。
多くの企業にとって、SaaS への移行には、新しいテクノロジーの習得、マルチテナント構造の実装、新しい運用ツールの作成、新しい課金体型の採用、といった作業を伴います。
こういった障壁は、SaaS への移行がビジネスを成長させ将来の成功の鍵になると考えている企業にとって、特に深刻な問題になる可能性があります。そのような企業の多くは、わざわざアプリケーションの再構築やコードの書き換えを行うことなく、そして時間やコストも奪われることなく、SaaS への移行を加速する方法を模索しています。
そういったニーズに対応するために、アマゾンウェブサービス (AWS) では、AWS SaaS Boost をリリースしました。これは、開発者が既存のアプリケーションを SaaS 製品化する手間を省くためのオープンソースのリファレンス環境です。
この記事では、SaaS Boost 環境を立ち上げて実行するための全体的な流れを見ていきます。また、基盤となるアーキテクチャ、マルチテナントデプロイモデル、運用エクスペリエンス、請求の統合、SaaS Boost 管理アプリケーションでサポートされているコア機能についても説明します。
この記事の目標は、主要な概念を紹介することです。プレビューにサインアップしてさらに詳細を確認するには、AWS SaaS Boost を参照してください。
モノリスから SaaS への移行に当たっての考え方
AWS SaaS Boost の詳細を見る前に、まずは概念モデルを見ていきましょう。
この初回リリースでは、すぐに利用可能な SaaS アーキテクチャの全要素をまとめた環境の作成にフォーカスしています。これにより、ソリューションの SaaS モデルへの移行に伴う手間のかかる作業の大部分を行う必要が無くなります。
ここで行われる変換について理解するために、モノリスを SaaS サービスに移行するとはどういうことか、概念図を示します。図１は、SaaS Boost への移行前と移行後の状態を示しています。
図１ – モノリス からマルチテナント環境へ
図の左側には、従来のソフトウェアデプロイモデルが描かれており、各顧客がスタンドアロン環境で運用しています。この場合は、クラウドにデプロイすることも、オンプレミスにデプロイすることもできます。
ここで着目していただきたいのは、各テナントが個別に管理および運用されていることです。そして多くの場合、これらの環境を使っている顧客は、さまざまな製品バージョンを実行しています。
このやり方はシンプルで取り入れやすいかもしれませんが、ビジネスの成長に伴って大きな問題が発生し始めます。多くの顧客がこのモデルを利用してオンボーディングするにつれて、企業は、運用効率、コスト、俊敏性の課題に直面し始めます。最終的に、これは組織のスケールとイノベーション能力に影響を与えることになります。
このようなニーズに対応するために、AWS SaaS Boost を利用すると、企業は自分たちのモノリシックアプリケーションを簡単にフルマネージド型のマルチテナント対応環境 (図１の右側を参照) に落とし込むことができます。モノリスがこの構築済みの SaaS アーキテクチャに移行することで、すべてのテナントは一貫したエクスペリエンスを通じて管理および運用されることになります。
たとえば、テナントのオンボーディングは SaaS Boost 環境によって完全に自動化されています。SaaS ソリューションの管理と運用に必要なあらゆるコンポーネントを含む環境に、企業がアプリケーションをプラグインできるようにすることによって、できる限りスムーズな移行を可能にするという考え方です。
既存のアプリケーションを SaaS Boost にインストールするだけで、テナント管理、デプロイ、テナントごとの分析、ビリング（請求）、メータリングがすべてセットアップされ、すぐに使用できるようになります。これにより、ソリューションを再構築するコストをかけることなく、より迅速に、製品を SaaS モデルで市場に提供することが可能になります。
SaaS Boost の価値提案の根底にあるのは、加速をお手伝いすることです。SaaS Boost を使うことで、企業は速やかに SaaS モデルに移行できます。移行後には、ソリューションをさらにモダナイズする方法（あるいはそもそもモダナイズすべきか）について検討することができます。
開発者体験
基本を理解できたと思いますので、AWS SaaS Boost を活用し、これらの機能を使い始めるにはどうすればよいか見ていきましょう。図２は、アプリケーションを SaaS モデルに移行する際の手順の概要を示しています。
図２ – SaaS Boost のフロー
- まず初めに、SaaS Boost リポジトリからコードをダウンロードします。SaaS Boost 自体は、開発が不要な簡素化されたプロセスを提供していますが、中には、要件に応じてこのエクスペリエンスを変更または強化したいという開発者の方々もいるかと思います。今後の SaaS Boost の進化は、AWS の知見と、コミュニティによる貢献が一体となって推進されていくことを期待しています。
. - コードをダウンロードしたら、インストールプロセスを実行して、お持ちの AWS アカウントに SaaS Boost 環境をセットアップします。
. - 次に、各自の環境に合わせた全般的な設定を行います。ここでは、ポート、ドメイン、データベース、ビリングおよびメータリングに関する設定などを行います。
. - 以上で、基本的な SaaS Boost の環境がセットアップされました。ここからは、各自のモノリシックアプリケーションのパッケージングと SaaS Boost へのデプロイにフォーカスしていきます。まず、開発者は既存のアプリケーションをコンテナ化し、そのコンテナイメージを AWS にアップロードする必要があります。
. - アプリケーションがアップロードされ、環境が設定されたら、SaaS Boost による自動化されたテナントオンボーディング機能を使い始めることができます。このオンボーディングプロセスでは、各テナント環境に固有のすべてのコンポーネントを設定します。
. - 最後に、SaaS Boost の管理機能についてです。テナントがデプロイされて稼働が開始すると、SaaS Boost アプリケーションの管理機能を使用して、各テナント環境を管理し、分析ビューを使用してシステムを利用しているテナントのアクティビティを評価できます。
SaaS Boost でプロビジョニングされるコンポーネント
これである程度感触はつかめたかと思いますので、SaaS Boost 環境をインストールする際に何がデプロイされるか見てみましょう。図３は、SaaS Boost 環境のセットアップ時にプロビジョニングされる主要なコンポーネントの概要図になります。
図３ – SaaS Boost アーキテクチャの概要
SaaS Boost の管理サービスとコアサービスは、 AWS Lambda を使用するサーバーレスアプリケーションモデルによって構築されています。管理アプリケーションは React で構築され、Amazon Simple Storage Service (Amazon S3) と Amazon CloudFront を使用してホスティングされます。
このアプリケーションは、 Amazon Cognito を使用して管理者ユーザーを認証します。また、REST API を介してバックエンドサービスと連携し、SaaS Boost の複雑な作業の大部分を処理する一連のマイクロサービスにルーティングされます。
図３の右側は、アプリケーションを表しています。ここに皆さんのアプリケーションが配置され、 Amazon API Gateway を介して SaaS Boost の各サービスとやり取りすることができます。
このアプリケーションには、ビリングとメータリングとの統合も含まれています。SaaS Boost には、コアシステムの一部としてこれらのサービスが含まれますが、何を計測 / 請求するか、また、どんなメトリクスを生成するかはアプリケーションごとに様々かと思います。つまり、これらのイベントを発行するためには、皆さんのアプリケーションにコードを追加する必要があります。
アプリケーションの設定
SaaS Boost がインストールされたら、管理アプリケーションにログインし、それぞれの SaaS 環境に合わせた設定をしていく必要があります。ここでは、アプリケーションに固有のポート、ドメイン、コンピューティングリソース、データベース、ファイルシステム、請求オプションを設定します。
これらのデータは、デプロイ時のフットプリントを定めるために必要となります。そのため、テナントをシステムにオンボーディングする前に、これらの設定を完了させておく必要があります。
図４は、SaaS Boost 管理アプリケーションでこれらのオプションを設定するページのキャプチャです。
図４ – SaaS アプリケーションの設定
テナントのオンボーディング
テナントのオンボーディングを開始すると、SaaS Boost の価値をより実感できるようになります。ここは、SaaS Boost のマルチテナント特性が、従来のソフトウェアアプリケーションの単発のデプロイモデルとかなり大きな対比をなしている部分です。
SaaS Boost では、通常は顧客ごとにアプリケーションをインストールおよび設定する「インストーラ」という考え方から意図的に離れて、マルチテナント環境で、すべての顧客を単一の一元管理された環境でホスティングするモデルを採用しています。
新規テナントは、環境構築に必要な項目すべてがオーケストレーションされたスムーズなオンボーディングプロセスを通じて、この環境に導入されます。このスムーズな体験は、運用の手を煩わせることなく迅速に新規テナントを受け入れ、SaaS ビジネスの成長を可能とする土台となります。
この方法において、オンボーディングは、どちらかと言えばテナントの設定オプションを収集しオンボーディングプロセスを開始する、対エンドユーザーのエクスペリエンスとなります。その後、オンボーディングオートメーションは、繰り返し可能でスケーラブルな方法でテナントのすべての要素を設定します。
図５は、SaaS Boost のオンボーディングに関わる構成要素の一部を示しています。
図５ – テナントのオンボーディング
- このフローでは、全体的なオンボーディングプロセス（ステップ１）の一部として、アプリケーションのアップロードが含まれています。これは、テナントを初めてプロビジョニングする際には、そのテナント用にデプロイされるアプリケーションのインスタンスが用意されていないとプロビジョニングが進まないためです。
. - また、テナントをオンボーディングする前にアプリケーションの設定を行う必要があります。これは、ステップ２で表しているように、各マイクロサービスの設定が、アプリケーションの全般的な設定データで更新されます。
. - アプリケーションがアップロードされたら、オンボーディングを開始できます（ステップ３a）。SaaS Boost 管理アプリケーションには、オンボーディング機能が含まれていて、この組み込みのオンボーディングメカニズムを使用して、新規テナントの設定を行い、オンボーディングプロセスを立ち上げることができます。
.
このオンボーディングフローは、セルフサービスでの提供が難しい企業向けに用意されています。セルフサービスによるオンボーディングを実現したい場合は、アプリケーションにページを追加して、そこから SaaS Boost のオンボーディング機能をトリガーすることができます（ステップ３b）。
. - オンボーディングサービスには多数の可変部分がありますが、ここで重要な項目はテナント環境のプロビジョニングです。ステップ４では、新しいテナント環境のインフラストラクチャを作成するために必要なすべてのオートメーションと AWS CloudFormation スクリプトが SaaS Boost に含まれていることがわかります。
. - この新規テナントは、一元管理された SaaS 環境（ステップ５）にデプロイされ、このテナントを SaaS Boost 環境で管理および運用するために必要なすべてのルーティングとインフラストラクチャ構成が設定されます。
.
SaaS Boost 環境を可能な限りシンプルにするために、各テナントはいわゆる「サイロ」モデルでデプロイされ、それぞれ独自のリソーススタックを持つことがわかるかと思います。完全にリソースを共有するマルチテナントインフラストラクチャに比べ、コスト効率はいくらか制限されますが、サイロモデルを用いることによって、既存のアプリケーションを書き直すことなく SaaS Boost に移行することができます。
.
幸い、テナントは同じエクスペリエンスを通じて一元管理されるため、このようなモデルでも、企業は SaaS が持つ運用効率の利点の多くを実現できるというわけです。
. - オンボーディングパズルの最後の１ピースは、請求の統合です。オンボーディングサービスは、ここで請求システム内に新規顧客を作成します。企業は、任意の請求モデルに基づいて顧客に請求を開始することができます（ステップ６）。
テナント環境のアーキテクチャ
内部で何が起こっているのかをより良く理解するために、AWS 上でテナント環境がどのように実現されているかを詳しく見てみましょう。図６は、複数テナントをサポートするためにプロビジョニングされるアーキテクチャ要素の一部を示しています。
図６ – テナントアーキテクチャ
この図を上から見ていくと、SaaS Boost 環境に２つのテナントがプロビジョニングされていることがわかります。各テナントは、基盤となるアーキテクチャにルーティングするためのサブドメインを持っています。
この場合、 Amazon Route 53 は、各テナント環境用に作成された個々の仮想プライベートクラウド (VPC) にルーティングするために使用されます。テナントに必要なすべてのリソースは、そのテナントの VPC 内に配置されています。
アプリケーションは Amazon Elastic Container Service (Amazon ECS) クラスターにデプロイされます。これらの各クラスターでホスティングされるテナントのワークロードは、個別にスケールされます。
上の図には、アプリケーションによっては必要となるデータベースやファイルシステムのプレースホルダーも含まれています。アプリケーションが必要とする特定のリソースは、上記のアプリケーション設定プロセス中にセットアップされます。
アプリケーションの更新をデプロイする
マルチテナント環境で各テナントを稼働させることができました。次は、これらのテナントにアプリケーションの更新をデプロイする方法を検討する必要があります。SaaS の全体的な価値体系と整合性を保つためにも、アプリケーションの更新は、１回のデプロイプロセスによってすべてのテナントに適用されるようにする必要があります。
独自の DevOps デプロイツールを作成する必要はありません。アプリケーションのデプロイについても、SaaS Boost が責任を持って行ってくれます。
アプリケーションの新しいバージョンが SaaS Boost 環境にアップロードされるたびに、この更新は自動的にすべてのテナント環境にデプロイされます。
請求の統合
SaaS への移行は、多くの場合、新しい請求モデルへの移行を伴います。企業は、例えば、長期契約請求モデルから、サブスクリプションや消費ベースの請求モデルに移行する場合があります。
図７ – 請求の統合
この移行に対応するために、SaaS Boost には請求をサポートする機能が含まれています。具体的には、サードパーティーの請求サービス（この場合は Stripe）と統合された、すぐに利用可能な請求ソリューションが提供されます。これにより、自分たちで実装しなければいけない部分を減らすこともできますし、SaaS Boost 自体を変更して、別の請求プロバイダーを利用することも可能です。
この請求エクスペリエンスの概要を図７に示します。基本的なフローは、Stripe でアカウントを作成し、API キーを取得するところから始まります（ステップ１と２）。次に、SaaS Boost 管理アプリケーションを通じて API キーを設定します（ステップ３）。そしてこれが、アプリケーションの製品または請求単位の設定をトリガーします（ステップ４）。
請求エクスペリエンスのすべての点を線でつなげるには、アプリケーションから請求イベントを発行する必要があります（ステップ７）。これらのイベントの性質は、選択した請求モデルによって様々です。イベントが発行されるたびに、請求システムは、これを特定のサブスクリプションに解決して、Stripe に送信します（ステップ８および９）。
運用分析
SaaS ビジネスを成功させるためには、テナントが環境をどのように利用しているかを理解できる運用ビューが必要となります。これらのテナントを意識したインサイトは、テナントの正常性に関する問題やテナントの傾向を特定するためのデータを提供します。SaaS Boost 環境の設定を管理および進化させる方法を検討するにあたり、これらのデータを参考にすることができます。
このニーズに対応するために、SaaS Boost には、テナントの傾向分析に利用できる、テナントに焦点を当てた一連のグラフが含まれています。図８は、SaaS Boost にビルトインされている分析機能の一部であるいくつかのグラフのサンプルを示しています。
図８ – ビルトインの分析機能
また、多くの SaaS プロバイダーは、幅広いメトリクスを収集するためにそれぞれの環境に合わせてカスタマイズをする傾向があります。そういったニーズに対応するために、SaaS Boost では、 Amazon QuickSight を使用してそれらのカスタムメトリクスビューを集約および表示できる、事前にプロビジョニングされたインフラストラクチャとの統合が可能になっています。
ご利用開始にあたって、および今後の展望
このブログでは、AWS SaaS Boost の主要なポイントについて簡単にご説明しました。詳細については、AWS SaaS Boost をご覧ください。このページには、プレビュー申請のリンクも掲載されています。
SaaS Boost の今回のリリースは、貴社のソリューションを SaaS モデルでの提供に移行するための出発点にすぎない点にご注意ください。最小限の労力でアプリケーションを SaaS Boost に移行できる企業もあるでしょう。一方で、ソースコードの深くまで潜って、特定のニーズに合ったモデルにソリューションを作り直すことを選択する企業もあるかもしれません。
SaaS Boost チームは、このリファレンスの次なるバージョン、進化をコミュニティが推進することを期待しています。このバージョンを拡張し、モダナイゼーションのための追加パスへの対応や、より共有されたインフラストラクチャ、マイクロサービスベースの戦略へのサポートも追加されることを見込んでいます。
プレビューにサインアップすることで、SaaS Boost イニシアチブに関わり、前進への道筋を描くための手助けをすることができるでしょう。
AWS SaaS Factory について詳しく知るには
AWS テクノロジーパートナーは、AWS パートナーネットワーク (APN) の担当者に、AWS SaaS Factory チームとの連携についてお問い合わせいただくことをお勧めします。AWS SaaS Factory では、追加の技術的およびビジネス上のベストプラクティスにアクセスできます。
ISV は、APN に登録されていない場合でも、SaaS on AWS メーリングリスト に登録し、今後のイベントやコンテンツ、およびプログラムの提供に関する最新情報を受け取ることができます。
翻訳は Partner SA 櫻谷が担当しました。原文はこちらです。