[レポート] Supporting extensibility in SaaS environments #SAS302 #reinvent

AWS re:Invent 2022

#SaaS

#AWS

hayashi.masaya

2022.12.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは。大阪オフィスの林です。

今回のエントリでは「Supporting extensibility in SaaS environments（SaaS環境における拡張性のサポート）」というセッションについてレポートしていきたいと思います。

セッション紹介

セッション概要

SaaSプロバイダーは、顧客やパートナーに拡張性を提供する方法を探していることがよくあります。しかし、マルチテナントのSaaS環境で拡張性をサポートすることは、困難な場合があります。ノイジーネイバーの防止、テナントの分離、サードパーティコードの検証やサンドボックス化などは、SaaS開発者が取り組まなければならない検討事項の一部です。このセッションでは、SaaSソリューションの可用性、スケール、セキュリティ、パフォーマンスを損なうことなく拡張性を導入するために、どのようなパターンと戦略を用いることができるかを検討します。

スピーカー

Bill Tarr（with AWS SaaS Factory）

セッション動画

レポート

拡張性が重要な理由

SaaSの拡張性とは何かについて簡単な定義から始める。
- SaaSの拡張性とはプラットフォームを拡張するプロセスである。
  - プラットフォームのエッジ周辺の機能を構築する部分を助けるために外部の開発者を連れてきたりもする。
なぜSaaSの拡張性が重要なのか。
- SaaSソリューションの全体的な機能セットを成長させ、市場全体と顧客を維持するのに役立つ機能も拡張させて収益も伸ばす。

拡張性に関する課題

拡張性の課題はテナントエクスペリエンスから始まる。
- テナントエクスペリエンスを可能な限り優れたものにする。
- 提供するテナントエクスペリエンスが一致していることをどのように確認するのか。例えば下記。
  - 『顧客に提示できるコードであることを検証するために何をしなければなりませんか?』
  - 『その体験が顧客の期待に応えるものであることをどのように確認しますか?』
  - 『恐らく最大の問題。SaaSプラットフォームに移行することで達成した俊敏性をどのように維持するのでしょうか?』
  - 俊敏性と柔軟性との間には、綱引きのような関係にある。

コミュニティの拡張性

私たちに代わってこれらのアプリを開発しているビルダーは、私たちの直接の開発者の輪の外にある。
- 彼らは多くの独立性を持っている。
- 拡張性は単なるソリューションの1つのタイプではない。
- 市場を見て、拡張性に関して優れたストーリーを既に持っているいくつかの SaaSプロバイダーを調べて、これらのさまざまなモデルをどのように実装したかを考える。
拡張性を実装する方法は実際には数多くあり、その多くは実際の SaaS製品を実装する方法に依存する。
- 表示されているロゴはすべて、最初に使用するSaaSの良い例である。
- 彼らがどのように拡張性を構築したかを見てから、独自に拡張性を実装する方法を考えてみる。
  - これらは様々なタイプの拡張性モデルを持っているケース。
  - これらはワークフローオーケストレーションの優れた例。
  - ワークフローオーケストレーションを実装して、内部で機能する単純な関数だけでなく、より複雑なワークフローを許可する方法について考てみる。
Twilio Segmentのもう一つの興味深い例は、プラットフォームとして拡張機能なカテゴリに分類される。
- ソースデータを受け取り、それをそのデータのソース宛先に接続するセグメントを使用すると、何かしらの方法でそのデータを変換するために貢献できる関数路の間に存在する拡張性を作成できる。
- つまり、セグメント内のある場所から別の場所にデータが移動する全体の流れは、拡張性のストーリーの一部で非常に柔軟なモデル。
Freshworksは拡張性を使用して様々なビジネスプロセスを接続し、それらのビジネスプロセスを独立させた例として気に入っている。
- 製品チーム、開発者チームはさまざまなツールを使用している。そこで彼らはFreshdeskでチケットが更新された時にJiraチケットなどの外部ソリューションとの間に任意の形式の機能を追加できるという拡張性のストーリーを作成した。
- Freshdesk内のチケットが更新されると、そのデータに依存している開発者チームは、カスタマーサポートチームのプロセスに依存することなく独自のプロセスを継続できる。

Stripeアプリマーケットプレイス

アプリのマーケットプレイスの例。
- Stripeは支払い処理プラットフォームであり、もちろんセキュリティは最も重要。
- そのためアプリマーケットプレイスを構築した時、彼らは自分たちが提供できるものとは異なる種類の機能を持っている顧客に手を差し伸べたいと考えていた。
- Stripeは顧客情報、サブスクリプション、支払情報のAPIを公開し、Intercomなどはインフラストラクチャでこのアプリケーションをバックエンドでホストしている。
- StripeにはAPIとWebフックが提供されているだけで、インフラストラクチャからコールバックできるようになっている。
- これらのAPIとアプリとサーバとの間で3方向の会話が行われ、Stripeアプリケーションのどこにいるかというコンテキストで情報を交換し、サーバからすべての情報を取得できる。
Stripeの拡張性の経験。
- Stripeが最初に言った1つのこととして、アプリマーケットプレイスを成功させるには開発者の経験がいかに重要であるかということだった。

Slack ワークフローオーケストレーション

彼ら（Slack）の拡張性についての最初に出てくるのはビルディングブロック。
- 拡張性フローを構築する場合は、これらのフローをできるだけシンプルに作成する方法を考えるべきである。
- ブロックはトリガーで始まる。それらのトリガーはまさにあなたが期待するものであり、新しいメッセージや顔文字の着信など。
- ワークフローは別のシステムから入ってくるWebフックのような特定のフローで、ワークフローをトリガーする。
- コードの経験がほとんどない、または全く無い人でも、低コードのビルダー、ブロックエクスペリエンスを作成できる。
- 今日では、コードなしでSlack内にいくつかの単純なフローを作成することができる。

コミュニティの拡張ストーリー

独自のコミュニティアプリケーションとそれを配布するマーケットプレイスを構築するには何が必要か。
- 典型的な会社のビルダーから始めて、SaaSプロバイダーにアプリケーションを提供する。
- SaaSプロバイダーはアプリを検証して公開する。
- SaaSテナントは要件をUIに取り込んで提供する。

Community code contribution

コミュニティから提供されている信頼されていないコードを提供するために、ローカルの開発環境から始める。
いずれにしてもこれらのコードはプラットフォームに貢献する必要がある。
そこからSaaSプロバイダーはコードを取得するためにいくつかの手順を実行する必要がある。
- コードを正しく検証するところから始めるかもしれない。
独自の分離ストーリーが必要であり、運用ストーリーも必要。
同じレンズを通して、これらのアプリについて考える必要がある。
コアのSaaSプラットフォームだけでなく、その周りに存在するこれらすべてのアプリをどのように運用するかを考えなければいけない。

CodePipline

このプロセスはアプリケーションを公開することころから始まる。
- アップロードされたコードを配置する妥当な場所がS3。
- S3から、コードパイプラインを使用して提案する典型的なビルドプロセスを開始する。
アップロードされたアプリケーションの状態を記録するためにコンピューティングを計算する。
ツールを使用して自動化された出力を取得できるようにするが、最終的にはこのコードをレビューして、悪意のあるコードを探して、予期しない経験の既知の脆弱性を探す。
この場合のクラウド情報は、この特定の例では実際には何でも構わないが、テスト環境と本番環境を開始する。
私たちのテナント分離モデルは、誰もがこのコードを操作できないようにするものであり、プロセスの後半まで顧客には表示されない。
テストプロセスが必要であり、アプリレビュー担当者チームとこのアプリレビュー担当者が関与する可能性がある。

Serverless app packaging

コアシステムからデータにアクセスする機能を持つ部分を構築するため、Lambda拡張機能、特に外部のLambda拡張機能を使用することを提案する。
- これは、これらの拡張機能が、ユーザーが提供したコードの実行よりも長く有効であることを意味する。
Lambda が終了する前に、てコスト分析ソリューションにテナントコンテキストを渡します。
- テナントあたりのコストソリューションで特定のテナントを運用するのにかかるコストこのようなメトリクスを発行するには、Lambdaを使用する非常に単純な例。
- 実行時間このLambdaのコストを計算します。

サーバーレスアプリの分離

コアSaaSプロダクトは別のAWSアカウントで実行する例。
- アプリケーションへの呼び出しを行うSaaSプロダクトの設定から始めて、Lambdaにルーティングする。
- DynamoDBテーブルには、各Lambdaがどこにあるのかを示す情報を含める。
- このモデルではすべてのテナントで同じLambdaを共有する。
各テナントを完全に分離するのは非常に保守的なモデル。
- 運用上のオーバーヘッドが発生する。

アカウントごとのオンボーディングテナント

2つのテナントがアプリケーションをインストールするという例。
- CodeBuildの出力を受け取り、S3バケットに格納するという別のプロセスを回避する必要がある。Lambdaでこれを行うことが出来る。
- オンボーディングLambdaはDynamoDBのテーブルを作成する。
  - どのテナントのインフラストラクチャがどこに展開されているのか。
  - デプロイされているアカウントを追跡する必要がある。（AWS Organizationsの紹介）

バックエンドサービスのホスティングの決定

インフラストラクチャがどのように機能するかについて、バックエンドのホスティングを決定する。
SaaSプロバイダーとして独自にホストすることもアプリビルダーにホストさせることもできる。
これらはあなたが操作したいものですか？
- Webhookを呼び出させたいだけですか？
- 幾つかの異なるテナントの隔離モデルを検討しましたか？
- アプリビルダーはAPIのセキュリティも組み込む必要があります。

内部拡張性

別の種類の拡張性があると言っていたが、これを内部拡張性と呼んでいる。
いくつかを掘り下げてみるが、すべてが異なるわけではなく多くの共通点もある。

container code contribution

イメージをプルして根トリビュートする準備が整う。
ECRを再度使用してクロスアカウントアクセス許可を行う必要がある。
別のツールを紹介。
- Amazon Inspectorはコンテナの脆弱性をスキャンできる。ECRの高度なスキャンに基づいて継続的に実行できる。
- サードパーティのイメージは脆弱性が含まれている可能性がある。
- 脆弱性があるとコードパイプラインがブロックされる。
- コンテナをEKSからテスト環境にデプロイし、これもブロックできる。

分離の決定 - テナントとコンピューティング

分離のための選択肢の1つはAWS Fargateを使用すること。
もう1つのオプションはノードグループの分離。
- コアアプリケーションがあり1つのノードグループで実行されているいくつかのEC2でテナント分離ストーリーが実行されていることを意味している。
プールされたアプローチにすることも出来る。
これらEKSクラスター上に存在するコンピューティングを最適化するという点で多くのコスト削減と価値を提供する非常に優れたソリューション。