[レポート] Optimizing your multi-tenant SaaS architecture #PEX310 #reinvent

AWS re:Invent 2022

#SaaS

#AWS

hayashi.masaya

2022.12.23

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

はじめに

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

今回のエントリでは「Optimizing your multi-tenant SaaS architecture（マルチテナントSaaSアーキテクチャの最適化）」というセッションについてレポートしていきたいと思います。

セッション紹介

セッション概要

マルチテナントのソリューションを構築し、提供することは良いスタートです。しかし、運用を開始した後も、SaaS環境を最適化する方法を継続的に検討し、ソリューションを改良し、SaaS提供の運用効率、成長、俊敏性、革新性を最大化する機会を特定する必要があります。このセッションでは、SaaSアプリケーションのフットプリントを改善するために使用できる、具体的なデザインおよびアーキテクチャのパターンとプラクティスを学びます。このセッションでは、SaaSビジネスの成功に直接影響を与えることができる特定のテクニックとアーキテクチャ戦略を強調します。

スピーカー

Tod Golding（with AWS SaaS Factory）
Peter Yang（with AWS SaaS Factory）

セッション動画

レポート

SaaSのあるべき姿

SaaSソリューションのライフサイクルがどのようなものかを特徴付けるためにFish Modelと呼ばれるモデルがある。
- これはSaaSソリューションの最適化のストーリーを考えるための優れたフレームワークを提供している。
- 破線は、ある種の投資、追加のコスト、および追加の労力を表している。
  - これは単なる金銭的投資ではなく、チームへの投資であり、SaaSソリューションを提供および運用できるようにするための新しいツールの作成、新しいメカニズムの作成への投資である。
  - SaaSに移行するプロセスでは、必然的により多くの投資が行われ、その曲線は上向きになる。
  - 理想的には、時間の経過とともに効率が向上し曲線は下降し始める。
- 実線は収益を表している。
  - サブスクリプションモデルまたは新しい SaaSベースの価格モデルに移行する多くの場合、移行の一環として顧客からの収益が減少する可能性がある。
  - 新しい顧客を獲得する能力、新しい市場に対処する能力ならびに新しいセグメントへのリーチが加速していき収益が伸びていく。

メトリクスを使用して最適化を推進する

最適化の議論を推進するための正確なデータを本当に持っているかどうかが重要である。
- 特定のソリューション内で何が起こっているかについて十分な洞察が得られなければ、何をすべきか分からない。
最適化の議論全体は、システムに組み込まれたデータと洞察から始まる。
- 新しいテナントがシステムに参加するのにどれくらいの時間がかかるか知っているか?
- それらがどれほど早く価値を得るか知っているか?
- それが顧客にとって良い経験なのか?良い経験ではないのか?
Time to Valueが顧客にとって重要である場合、それはビジネスの可動部分の多くに影響を与えることになる。
テナント費用も多くに影響を与える。
- 私たちは物事のコストやインフラストラクチャのコストなども知りたい。
- マルチテナント環境では、コストが実際にどのように発生しているかについて、より高度な洞察を得る必要がある。

多様な体験をサポート

マイクロサービスのアーキテクチャ設計を作成し始めるときにSaaSプロバイダーが直面する課題
- 一連のマイクロサービスで構成されるSaaSソリューションがあり、環境にはさまざまなテナントがある。
- SaaSソリューションが、さまざまなテナントからのこの多様で非常に異なるエクスペリエンスをサポートできることを確認する必要がある。
- 将来のテナントについても考える必要がある。
- テナントのペルソナは何か?
- アプリケーションやマイクロサービスを設計するときは、複数の層、さまざまなペルソナをサポートできるようにする。
- ノイジーネイバー効果を軽減するソリューションまたは戦略を用意する。 -　ここで強調したいことの1つは、すべての理想に適合することは避けるべきである。
- なぜならば、柔軟性に関していくつかのオプションが失われることになる。
最初のテナントには、特定の使用パターンなどがあるため、そのユーザー、テナントプロファイルに合わせた一連のサービスを作成し、その展開モデルを作成する。
- ペルソナ2が登場すると、ニーズが変わる。
- そして、その後、特定のペルソナ3、4 などに適合する展開モデルを作成する。
- 私のソリューションにこの柔軟性を持たせることで、組織は、顧客に提供できる可能性のある追加の利点を定義し、新しい価格戦略を作成し、提供する利点にある程度の柔軟性を生み出したり提供したりできるようになる。

規模、コスト、エクスペリエンスの最適な組み合わせを見つける

サイロ化されたストレージとコンピューティング
- 各テナントにはコンピューティングの独自のインスタンスがあり、サービスはプールされたストレージを使用する。
- つまり、すべてのテナントが同じものを共有している。
注文サービスは製品サービスと通信する場合、プールされたコンピューティングモデルとプールされたストレージモデルがあり、Invoiceのマイクロサービスと通信する。
ここで強調しているのは、個々のサービスを見て、個々のサービスごとに適切な展開モデルを選択しているということ。

展開モデルと柔軟性のトレードオフ

マイクロサービスまたは基本サービスへの追加を開始すると、テナントのペルソナに適合する展開モデルの作成する。これが最初のテーマ。
- 柔軟性にはトレードオフがある。
- プロビジョニングやオンボーディングプロセスにも潜在的な複雑さを追加する必要がある。
- どのテナントがどのデプロイモデル、サービスセット、構成などを使用しているかを追跡する必要がある。
- これは、テクノロジスタック、またはコンポーネント内にある最適化の機会を検討する際に意識しておく必要がある。
2つ目のテーマは、消費とアクティビティを一致させること。
- これは、インフラストラクチャのリソースアクティビティとテナントの消費のこと。
- コストの最適化を考える場合、SaaSプロバイダーとして、私たちはソリューションのマージンに注意を払う。
- リソースが使用パターンに合わせてスケールアップおよびスケールダウンできることを確認する。
- ギャップが大きくなりすぎて、オーバープロビジョニングのリスクが発生する場合、アイドル状態のリソースに対して料金を支払っていることを意味する。
- これは、利益を減らし、運用コストに影響を与えることになる。

SaaSの理想的な関係

テナント消費とリソースアクティビティの理想的な関係を示す図。
- ここの赤い線はリソースアクティビティを示し、青い線はテナントの消費を示している。
- テナントの消費量が増減すると、リソースアクティビティも増減する。
- 赤い線が青い線よりも大幅に高くなるギャップが大きくなりすぎると、マージンが侵食され、利益に影響を与える。
- 赤い線が青い線よりも下になるようにスケーリングポリシーを積極的に使用すると、プロビジョニング不足のリスクが発生し、アプリケーションのパフォーマンスやユーザーエクスペリエンスに悪影響を及ぼす。
SaaSプロバイダーとして、システムにはさまざまなテナントがあり、さまざまな使用パターンがあるため、使用パターンがどのようになるかを予測することは困難。
- そのため、時間ごと、または分ごとに変化する可能性のある使用パターンに基づいてリソースをスケールアップおよびスケールダウンできる必要がある。

適切なサイジングの課題

プールされたマイクロサービスを使用するテナント番号 1 とテナント番号 2 があり、それらはマイクロサービスの同じインスタンスと通信してる。
パフォーマンスを考慮して、テナント 1 を独自の専用ストレージインスタンスにサイロ化し、Amazon RDS を使用しているため、この RDS インスタンスを起動するときに特定のインスタンスタイプを指定する必要がある。
- 2 番目のテナントには、独自のサイロ化されたストレージもあり、RDSインスタンスもあり、インスタンスタイプも指定する必要がある。
- 3 番目のテナントは、プールされたインフラストラクチャに配置する。
- つまり、プールされたデプロイモデルを意味する。
- プールモデルに含まれる他のテナントと同じデプロイ、同じストレージを共有することになる。
- テナント 1 でパフォーマンスの問題が発生すると、インスタンスを別のインスタンスタイプにアップサイズし、データを移行し、インスタンスを移行する必要がある。
テナント番号 2 については、オーバープロビジョニングされている。
- アイドル状態のリソースにお金を払っているので、インスタンスタイプを縮小したい。
- 同じプロセスを経て、インスタンスタイプを切り替え、テナントを移動する。
- 3 番目のテナントは、プールにあるため、適切なインスタンスタイプは何かという点で、より大きな課題になる。
- アンダープロビジョニングすると、パフォーマンスの問題が発生するため、そのプールインフラストラクチャをオーバープロビジョニングする可能性がある。
適切なサイジングを管理するためのスクリプトの作成に伴う労力について考えると、DevOps または運用チームがシステムを監視し、適切な使用パターンで適切なトリガーを特定し、スクリプトを作成し、スクリプトをテストする必要がある。

Making right-sizing someone else's problem

サーバーレスは、AWS 内のテクノロジーを検討する際に検討すべき優れたオプションになる。
- サーバーレスでは、コンピューティングを管理する必要がなく、AWS がその下のコンピューティングを管理できるので、コードだけを考えればいい。
- アイドル状態のリソース、それらを管理するためのコスト、および運用コストへの影響について心配する必要はない。
- ストレージには、Amazon Aurora Serverless、Amazon DynamoDB、Amazon S3 などがある。
- SaaSで人気のあるコンピューティングの一部は、EKSとECSになる。
- AWS Fargate を使用すると、Fargate がそのコンピューティングを管理するので、コンピューティングについて心配する必要はない。
- もう1つ人気のあるのはAWS Lambda。関数を作成し、その関数をLambdaにデプロイする。
- 分析には、Athena、Amazon QuickSight、Amazon EMRなどがある。
システムを監視するために必要なプロセスに関して以前に説明した DevOps と運用チームのリソースを節約し、それらのスケーリングポリシーを維持するための適切なトリガーを作成する。
サーバーレスも素晴らしいオプションですが、すべての状況やユースケースに適しているとは限らない。

消費とコストの相関

ECSやRDSやストレージにもお金を払っている。
インフラストラクチャのコストは把握し出来ているが、個々のテナントの費用にどのように影響するかは分からない。
各テナントが均等にリソースを消費しているわけでもない。
ツールがこれらの問題を解決してくれる。

It starts with tenant-aware system health

システムの健全性について考える場合に重要なのはアプリケーションが稼働しているかどうか。
SaaSプロバイダーとして、テナントを意識したシステムの正常性が必要であることを知っておく必要がある。
すべてのテナントに対して全面的にシステムで何が起こっているかを、特定のテナントのレンズを通して、テナントの層について、またはグローバルなアプリケーションとして見れるようにする。
データを保存するために使用できるさまざまなテクノロジスタックがありRedshiftが利用できる。ログにはCloudWatchを使用できる。

テナントの価値とエンゲージメントの測定

ここでは、オンボーディングプロセスと、アプリケーション内のユーザーエンゲージメントレベルについて説明する。
Time to Valueを記録して、そしてそれをカスタマーサクセスチームに明らかにすることで、システムにサインアップし、システムにログインし、システムを頻繁に利用し始めているユーザーを確認できる
運用チームの効率を改善し、組織レベルで影響を与えるために SaaS アプリケーションができることを考えるときに、いくつかの指標または考慮すべき事項
サイロとプールについて話したように、さまざまなレベルのエクスペリエンスを提供する場合、実際にはさまざまな展開プロファイルを提供できるため、プレミアムレベルのテナントには 1 つのエクスペリエンスが提供されますが、ベーシックレベルのテナントには別のエクスペリエンスが提供されると言える。
スロットリングの古典的な種類の概念であり、特別なことは何もない. この場合、API ゲートウェイがこれらのさまざまな層の顧客からこれらの呼び出しを取得し、カスタムオーソライザーを使用することを示している。
呼び出しをインターセプトし、トークンを抽出し、それに関連付けられている API キーを特定し、次に APIキーには使用プランが添付されている。
プレミアムなどに基づいたその使用プランは、その階層に基づいてあなたを抑制する。したがって、プレミアム層のテナントは、基本層のテナントよりも優先されるスロットリング戦略を取得する。
基本層のテナントは、100 万個のパーツをカタログにアップロードするようなものであり、API を飽和させており、システム内のすべての人に影響を与えている。