SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

AWS SaaS Boost 機能検証

2021.7.6

こんにちは、NRIデジタルの島です。
既存アプリケーションをクラウドベースのSaaSに移行する「AWS SaaS Boost （以下SaaS Boost ）」がリリースされました。
SaaS Boostでどのようなことが実現できるのか、実際に動かしてみたので内容を共有させていただきます。

SaaS Boost とは

オンプレミス等で提供している既存アプリケーションの提供形態をSaaSモデルに移行するツールです。
現在オープンソースとして公開され、自由に改変、商用利用が可能です。（Apache License 2.0）
SaaS Boost License
※現時点ではまだ「Public Preview」の位置付けですので、ご認識の上ご試用いただければと思います,

通常、開発したアプリケーションをSaaS形態で提供しようとすると、下記のような機能が必要になります。

  • 各テナントへのアプリケーション、インフラストラクチャーのプロビジョニング
  • 各テナントの利用状況やメトリックのモニタリング
  • 各テナント単位での利用状況に応じた課金処理
  • 全テナントへの更新アプリケーション一斉配信
  • 一部テナントの一時的な利用停止、再開

    • 　　　etc..

を独自に開発するには相当な工数がかかります。
SaaS Boostはこれらの機能を提供し、開発者は本来のアプリケーション開発に専念できます。

実際にデプロイするアプリケーションのイメージは下記の通りで、コンテナ化したアプリケーションからRDBに接続するようなシンプルなアプリケーションが想定されています。
※アプリケーションは「Amazon Elastic Container Service（以下ECS）」で稼働する前提の為コンテナ化は必須です

テナントのオンボーディング

Amazon Web Services ブログから引用

SaaS Boostのアーキテクチャですが、各種AWSサービスをうまく連携させて構成されています。
利用しているAWSサービス

「AWS Lambda（以下Lambda）」を使用したサーバーレスアプリケーションモデルによって各種サービスが実装されており、「Amazon API Gateway（以下API Gateway）」を介して各サービスとやり取りされます。
SaaS Boostのユーザーは「Amazon Cognito」を使用して認証されます。

アーキテクチャ概要

Amazon Web Services ブログから引用

機能検証

Getting Startedに従い、SaaS Boost本体をプロビジョニングし、自前のアプリケーションをSaaS Boostへデプロイして見たいと思います。

デプロイまでの流れは下図の通りです。

Getting Startedから引用
1．ツールのセットアップ

SaaS Boostをセットアップを実行する端末（EC2サーバやローカルPC）に下記ツールをインストールします。
　　・Amazon Corretto 11
　　・Apache Maven
　　・AWS CLI version2
　　・Git
　　・Node 14 or 15
　　・Yarn
※Nodeは16以上で実施するとインストール時エラーになるので注意
※バージョン指定がないツール類は、それほど古くなければ問題ないと思われます。

2．GitリポジトリのClone

SaaS BoostのGitリポジトリをクローンします。

git clone https://github.com/awslabs/aws-saas-boost ./aws-saas-boost
3．SaaS Boostのプロビジョニング

SaaS Boost本体のプロビジョニングを行います。
管理権限を付与したIAM userを準備し、クレデンシャル設定後、「2．GitリポジトリのClone」でCloneしたルートのディレクトリ（今回の場合aws-saas-boost）へ移動し、インストールスクリプトを実行します。

./install.sh

今回は最小構成で試すので、下記設定のみで進めます。
　　・インストールタイプ : 1（新規）
　　・環境名　　　　　　　: coe
　　・管理者メールアドレス：xxxx@xxxx
　　※プロビジョニング完了後に通知が届きます。

30分程度待つと完了します。
各AWSサービス等はCloudFormationでプロビジョニングされる為、進行状況はそこで確認可能です。

4．プロビジョニング完了の通知と管理コンソールログイン

プロビジョニングが完了すると③で設定したメールアドレスに通知が届きます。

メールに記載のURLでSaaS Boostの管理コンソールのログイン画面にアクセスし、adminユーザでログインします。（初回ログイン時にパスワード変更します）

5．アプリケーションの設定

今回使用するアプリケーションはMySQLのデータベースを使用する単純なWebアプリケーションです。

実際のアプリケーションをデプロイする前に、まずコンソール上でアプリケーションの設定を実施します。

・Application
アプリケーションの基本設定です。

・Container Settings
コンテナのサイジング等の設定です。
※SaaS BoostでデプロイするアプリケーションはECS上でコンテナで動作させます。

今回は最小構成で設定します。

・FileSystem
コンテナにマウントするファイルシステムの設定です。
今回のアプリケーションでは不要の為未設定ですが、ファイルシステム上にデータを保持したい場合には必要です。

・Datadase
データベースの設定です。

・Billing
決済システム（Stripe）へ連携するAPIキーの設定です。
今回課金関連は検証対象外とした為未設定です。

設定が完了したら画面下部の「Submit」ボタンを押下します。
この後デプロイ（テナントのプロビジョニング）時に、ここで設定した各サービスが設定値に従いプロビジョニングされます。

6．アプリケーションのデプロイ（テナントのプロビジョニング）

アプリケーションのビルド
続いて、アプリケーションをDockerコンテナイメージでビルドします。
ビルドしたイメージは、コンテナレジストリの「Amazon ECR（以下ECR）」へプッシュします。

アプリケーションのプロジェクト等でDockerfileを作成後、下記のようなビルドスクリプトを作成し実行します。
※クローンしたサンプルディレクトリ配下（sample/java）にbuild.shがありますので、それを参考に作成しています

build.sh

#!/usr/bin/env bash
 
read -p "Please enter your AWS SaaS Boost Environment label: " SAAS_BOOST_ENV
if [ -z "$SAAS_BOOST_ENV" ]; then
 echo "You must enter a AWS SaaS Boost Environment label to continue. Exiting."
 exit 1
fi
 
AWS_REGION=$(aws configure list | grep region | awk '{print $2}')
echo $AWS_REGION
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --output text --query ["Account"])
ECR_REPO=$(aws ssm get-parameter --name /saas-boost/$SAAS_BOOST_ENV/ECR_REPO --output text --query ["Parameter.Value"])
if [ -z "$ECR_REPO" ]; then
    echo "Can't get ECR repo from Parameter Store. Exiting."
    exit 1
fi
DOCKER_REPO="$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPO"
DOCKER_TAG="$DOCKER_REPO:latest"
 
AWS_CLI_VERSION=$(aws --version 2>&1 | awk -F / '{print $2}' | cut -c 1)
if [ $AWS_CLI_VERSION = '1' ]; then
 echo "Running AWS CLI version 1"
 aws ecr get-login --no-include-email --region $AWS_REGION | awk '{print $6}' | docker login -u AWS --password-stdin $DOCKER_REPO
elif [ $AWS_CLI_VERSION = '2' ]; then
 echo "Running AWS CLI version 2"
 aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $DOCKER_REPO
else
 echo "Running unknown AWS CLI version"
fi
 
echo $DOCKER_TAG
mvn clean package
docker build -t $DOCKER_TAG .
docker push $DOCKER_TAG

build.shを実行

./build.sh

ECRへ正常にプッシュ出来ていれば完了です。

アプリケーションのデプロイ（テナントのプロビジョニング）

各テナントへアプリケーションをデプロイしていきます。
コンソールの左メニューより「Onboarding→Provision Tenant」と進み、表示される画面で「Tenant Name」を設定しSubmitします。

しばらくするとデプロイ完了し、「Tenants」画面に反映されます。

各テナントのアプリケーションへアクセスするLBのFQDNは「ID」を押下した詳細画面に記載されております。

上記FQDNよりアクセスすることが出来ます。

（参考）デプロイしたWebアプリケーションの画面

予想していたよりもスムーズにデプロイまで実施することが出来ました。

SaaS Boostは、各テナント毎に依存するサービスがプロビジョニングされます。
例えば、DBも1インスタンスを共有する設計ではなく、個々に立ち上がります。
つまり各テナントは完全に分離される為、デプロイするアプリケーションはリソース共有を意識した仕組みは不要で、特別アプリケーションの作りを変える必要はありません。

ただ下記点は今回考慮が必要でした。

  • DB初期化（テーブル作成、マスタの登録等）は先の「アプリケーションの設定→Database」で初期化SQLを登録するか、アプリケーション起動時に初期化するような対応が必要
  • 作成される「Amazon Elastic Load Balancing（以下ELB）」のヘルスチェックは「200」で設定される為、リダイレクトするWebアプリケーションの場合は変更が必要（200 → 200-399）

なお、「アプリケーションの設定→Database」で設定したDB情報はパラメータとしてアプリケーションに連携される為、DBのエンドポイントやDBユーザ/パスワードを動的に設定できるように構成しておいたほうが良いと思います。
また、DBユーザ/パスワードは「AWS System Manager パラメータストア」に格納し、ECSのタスク定義で定義する形でセキュアに管理されております。

7．マルチテナント運用

アプリケーションの一斉アップデート

アプリケーションは定期的にアップデートされることになります。
SaaS Boostはアップデートされたアプリケーションを全テナントへ配信する機能もサポートしております。

Developer Guideから引用

アップデートしたイメージをECRへPushすると、「Amazon EventBridge」への通知をトリガーにLambdaが起動され、そのLambdaより「Amazon CodePipeline」が実行されるという流れです。

実際にイメージをアップデートしたところ、全テナントのアプリケーションが更新されました。

テナントの一時停止・再開
運用していると一時的に特定のテナントのサービスを停止したいということもあるかと思います。
コンソール上で下図の通り「Disable」を実行することで一時的にアクセス不可にすることが可能です。

Disableにしたテナントアプリケーションにアクセスすると下記のメッセージが表示されアクセス不可となります。

仕組みは単純で、該当テナントのELBのルーティングで固定HTMLを返すように変更しています。

なお、再開する場合は「Enable」を実行することで元通り開放されます。

モニタリング
さいごにSaaS運用にて必要になるモニタリングについてもふれておきます。
コンソールの左メニューのDashboardから各テナント毎の利用状況、リソース状況等を確認可能です。

・Requests
リクエスト数、エラー数（4XX/5XX）

・Compute
CPU、メモリの利用状況

・Usage
各エンドポイント毎のリクエスト数

以上、SaaS Boostの基本機能を触ってみましたが、既存アプリケーションに大きく手を加えることなくマルチテナント対応することが出来ました。

一方、気になった点としては下記があります。

  • 「5．のアプリケーション設定」で外部リソースとして定義できるのはDBやFileSystemのみで、それ以外のリソースを使用する場合は手動で追加しなければならない
    （例えばセッション管理に「Amazon ElastiCache」を使ってる場合や、API提供で「API Gateway」と統合したい場合など）

  • 前述した通りリソース共有モデルではなく、テナント毎に共通の設定が適用される為、DBのリソースなどをテナント毎に最適化できない。
    （例えば一部のテナントのみリソースを増やしたいなど）
    また、アップデートしたアプリケーションは全テナントに一斉配信される為、一部のテナントのみバージョンを止めておくなどの個社対応が臨機応変に出来ない

前述した通り、SaaS BoostはOSSとして提供される為、ニーズにあわせて改変していくことが必要ではないかと思います。

なお、このSaaS Boostですが、今回の検証実施時点でIssue対応や改修が活発にされておりました。
検証を最初実施した際は結構不具合がありました（テナントの一時停止が出来なかったり…）が、検証を実施しているタイミングで集中的に改修されてました。

品質的にも機能的にもだいぶ改善されてきている印象ですので、これから試す方はもっとスムーズに実施できるのではないかと思います。

さいごに

SaaS Boostについて試してみましたが、AWSサービス総動員という感じで非常におもしろいと思いました。
これまで各サービスを個々に、もしくは一部をつなげて使うことが多かったのですが、これだけ多くのサービスをうまく連携させて作っているところはアーキテクチャとして大変参考になりました。

SaaS Boost自体は、単純なWebアプリケーションやパッケージをマルチテナントで横展開していく分には十分使えるツールだと思いますし、OSSなのでフィードバックしていくことでどんどん改善していくと思われますので、今後も期待していきたいと思います。

以上