re:Invent 2023: AWSが提案するSaaS anywhereモデルと分散マルチテナント設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - SaaS anywhere: Designing distributed multi-tenant architectures (SAS308)
この動画では、SaaS anywhereという新しいデプロイメントモデルについて詳しく解説しています。従来のSaaSの境界を押し広げ、リモート環境にアプリケーションコンポーネントをデプロイする方法や、その設計上の考慮事項を学べます。分散データストア、分散アプリケーションプレーン、リモートアプリケーションプレーンという3つの主要なデプロイメント戦略を紹介し、AWS CloudFormationやAWS STSなどのサービスを活用した具体的な実装方法にも触れています。SaaSの核となる価値を損なわずに、より柔軟なSaaSソリューションを構築するヒントが満載です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
SaaS Anywhereセッションの概要と背景
本日のセッション SAS308「SaaS anywhere: 分散型マルチテナントアーキテクチャの設計」にお越しいただき、ありがとうございます。私は Peter と申します。今日は同僚の Dhammika と一緒にこのセッションを進行させていただきます。
Dhammika と私は、AWS SaaS Factory というチームに所属する partner solution architect です。この役割では、新しい SaaS アプリケーションの構築、既存の SaaS アプリケーションの変革、あるいは SaaS アプリケーションの最適化を検討しているパートナーと協力する機会に恵まれています。partner solution architect として、私たちはパートナーと技術的なソリューションについて協力しています。
パートナーと SaaS ソリューションについて話し合う際、通常は従来の展開モデルについて議論します。このモデルでは、SaaS アプリケーションは純粋に SaaS プロバイダーの環境内に展開され、プロバイダーが SaaS アプリケーションへの完全なアクセスと制御を持ちます。しかし、最近のパートナーとの対話の中で、新しい展開モデルを考えさせるような共通の質問や懸念事項が出てきています。そのため、SaaS の境界を拡大し、リモートコンポーネントを SaaS の展開に組み込むことを検討し始めています。
今日のセッションでは、SaaS anywhere とは何か、私たちの定義、設計上の考慮事項、そしてトレードオフについてお話しします。これは 300 レベルのセッションですので、パターンや実装についても議論します。ただし、今日お話しするパターンと実装は包括的なリストではありません。私たちがまだ考えていない、あるいは今日カバーしないパターンが他にもたくさんあります。実際、このセッション後に皆さんとお話しすれば、私たちが今日カバーしていないパターンや実装アプローチをお持ちの方もいらっしゃるかもしれません。
300 レベルのセッションですので、パターンと実装について話します。コンソールでのライブデモや IDE を開いてコードを書くことはしませんが、コードのスニペットはお見せします。今日のセッションでこのような内容を期待されていた方は、ご参加いただき大変うれしく思います。もし期待していた内容と異なる、あるいは別のものを求めていた場合は、退出して別のセッションをお探しいただいても構いません。私たちは気にしません。re:Invent での皆さんの時間を最大限に活用していただきたいと思っています。
SaaSの核となる価値とその重要性
それでは、SaaSの核となる価値について見ていきましょう。SaaS anywhereの話に入る前に、そもそもなぜSaaSを作ったのかについて少しお話ししたいと思います。これがSaaSの約束、つまり私たちがSaaSソリューションを設計する際に達成したいことです。
最初の核となる価値は俊敏性です。顧客のニーズや市場に対応できるソリューションを確保したいと考えています。素早くイノベーションを起こし、迅速に顧客の手元に届けられる機能を生み出せるソリューションを目指しています。
次の核となる価値はスケールメリットです。コスト最適化されたソリューションを確保したいと考えています。SaaS環境では、これを通常、少なくとも部分的にはマルチテナント環境と関連付けています。つまり、複数の顧客が同じインフラを共有することで、ソリューションの運用コストを最適化できるのです。
コスト最適化されたソリューションを確保するだけでなく、運用効率も確保したいと考えています。これは、ソリューションの管理・運用コストを最小限に抑えたいということです。 新しいテナントを追加するたびに、追加の運用リソースを雇わなければならないような状況は避けたいのです。
もちろん、成長も核となる価値の一つです。成長とは、収益や財務だけでなく、組織の拡大や新規顧客の獲得をどのように支援するかということです。新しいパッケージや機能を柔軟かつ俊敏に作成できるソリューションを作り出し、組織がこれまで到達できなかった市場やセグメントに参入できるよう支援したいと考えています。
最後のコアバリューは、サイクルタイムの短縮です。SaaSプロバイダーとして、顧客を獲得したら、その顧客のロイヤルティを得て、できるだけ長く利用し続けてもらいたいと考えています。そのため、優れたフィードバックループを持つことが非常に重要です。これにより、機能リクエストを収集したり、顧客が問題を報告したりすることができます。そして、その情報を機能に変換し、顧客に還元します。顧客が良好なフィードバックループに関与していると感じることで、顧客ロイヤルティが高まり、結果として長期間サービスを利用し続けてくれることが期待できます。
これらがSaaSのコアバリューです。今日のセッションを通して、新しいデプロイメントモデルについて考える際に、これらの核となる特性を見失わないよう、何度も立ち返っていきます。
コントロールプレーンとアプリケーションプレーン：SaaSの2つの主要コンポーネント
次に、コントロールプレーンとアプリケーションプレーンについて説明します。これらは、パートナーと協力する際に議論するSaaSソリューションの2つの主要コンポーネントです。 1つ目はコントロールプレーンで、SaaSプロバイダーがすべてのテナントとアプリケーションプレーンのすべてのインスタンスを管理するために使用する共有サービスのセットです。これは、すべてのメトリクスと可観測性データの中央集約点となり、データを集約して必要な分析を行うことができます。SaaSプロバイダーにとって、SaaS環境で何が起こっているかを完全に把握するためのワンストップショップとして機能します。
2つ目のコンポーネントは、アプリケーションプレーンで、これはアプリケーションのマルチテナント部分です。 これは、顧客やテナントがソリューションの価値提案を認識し、実際に利用する部分です。
イントロダクションで述べたように、従来のデプロイメントモデルでは、SaaS環境のアプリケーションプレーンとコントロールプレーンの両方が、 SaaSプロバイダーのアカウントまたは作業環境内で稼働しています。これは重要なポイントで、SaaSプロバイダーがSaaSアプリケーションをサポートするために必要なインフラストラクチャリソースに完全にアクセスし、制御できるようになっています。しかし、私たちは新しいデプロイメントモデルを考えるきっかけとなる、よくある質問や懸念事項も耳にしており、その境界線を拡大しようとしています。
この新しいデプロイメントモデルの最初の動機は、コンプライアンスです。これはSaaSソリューションのセキュリティ面に関連しています。顧客は今、自分たちのデータがどこに保存されているか、そのデータを扱うプロセスがどこで実行されているか、そしてデータストアやこれらのアプリケーションやプロセスを実行するサーバーやインフラリソースをどのようにコントロールできるかを問い始めています。次の動機は、コスト効率です。 今日の環境でデータが急速に増加していることや、組織が現在扱っているデータ量を考えると、SaaSソリューションがこのデータを扱う必要があるのは当然です。データの転送コストが大きくなる可能性があるため、データを行ったり来たりさせずに大量のデータを扱えるような新しいデプロイメントモデルを考える必要があります。
ドメイン要件も重要な要素です。組織のエコシステム内に複数のビジネスクリティカルなアプリケーションがあるのは珍しくないため、SaaSソリューションはしばしばこれらの外部システムと統合して動作する必要があります。これらの統合をどのように最適化するかを考える必要があります。 これらの外部システムの中には、レガシーな要件を持つものもあるかもしれません。つまり、すべてのアプリケーションがAPIやフックのような簡単な統合ポイントを持っているわけではありません。古いレガシーアプリケーションの場合、そのシステムのデータベースやファイルから読み取るコンポーネントをそのアプリケーションの隣に置く必要があるかもしれません。
レイテンシーも重要な考慮事項です。外部システムやデータベースとの統合を改善するためにリモートコンポーネントをデプロイすることについて話しましたが、パフォーマンスを向上させ、レイテンシーを最小限に抑えるためにどのようなデプロイメントモデルが考えられるかを考える必要があります。 アプリケーションができるだけ高性能であることを確保することが重要です。 すべての質問や懸念が技術関連ではないことに注意することが重要です。SaaSの採用を検討している多くの組織は、すべてが自社のデータセンターの自社のサーバーで動作し、完全なアクセスとコントロールを持つ従来のソフトウェアデプロイメントモデルにより慣れています。今、彼らは新しいサブスクリプションモデルに移行するだけでなく、データの保存場所やプロセスの実行場所に対するコントロールを手放すよう求められています。
SaaS Anywhereの定義と視覚化
一部の顧客は「あなたのSaaSソリューションを使いたいのですが、データを保持したり、これらのプロセスを自社のデータセンターや自社のコントロール下で実行する必要があります」と言うかもしれません。これらの繰り返される質問が、SaaSのデプロイメントの境界を押し広げる「SaaS anywhere」デプロイメントモデルについて考えさせています。次のスライドにはたくさんのテキストが含まれていて申し訳ありませんが、私たちが全員同じページにいるように、SaaS anywhereの明確な定義を持つことが重要だと思いました。 SaaS anywhereは、システムリソースの一部がSaaSプロバイダーのコントロール下にない可能性のあるリモート環境でホストされるアーキテクチャモデルを表します。これは、これらのリモートアプリケーションリソースの集中的なプロビジョニング、設定、運用、デプロイメントをサポートするマルチテナントソリューションを作成するために使用される一連のパターンと戦略を概説しています。強調すべき点として、私たちはすべてがSaaSプロバイダーのアカウントに置かれる従来のデプロイメントモデルについて話してきました。
SaaS anywhereでは、アプリケーションの一部をSaaSプロバイダーのコントロール下にないリモート環境でホストすることを検討しています。これらのリモートアプリケーションリソースをリモート環境にデプロイしていても、集中的なプロビジョニング、設定、運用などのコア属性を損なうことはありません。
私はどちらかというと視覚的な人間なので、ここにスライドを用意しました。これは定義を視覚化したもので、理解の助けになればと思います。従来のSaaSデプロイメントモデルでは、SaaSソリューションはSaaSプロバイダーの環境で稼働しています。SaaSプロバイダーはインフラストラクチャリソースに対して完全なアクセス権と制御権を持っています。SaaSアニーホワデプロイメントモデルでは、リモート環境という概念を導入します。リモート環境には、お客様が所有・管理するリモートインフラストラクチャがあります。しかし、アプリケーションコンポーネント、つまりリモートアプリケーションリソースは、これらのリモート環境内のリモートインフラストラクチャリソース内にデプロイ、実行、稼働させる必要があります。
SaaSアニーホワでは、リモートコンポーネントをどのようにデプロイするかだけでなく、これらのリモートコンポーネントとどのように接続を維持し、可視性を保つかについても考える必要があります。SaaSアニーホワについて説明したところで、SaaSアニーホワソリューションを設計する際の設計上の考慮事項と、念頭に置くべき影響について説明したいと思います。
SaaS Anywhereの設計上の考慮事項と影響
最初の考慮事項は、可用性と信頼性です。SaaSプロバイダーにとって、SaaSアプリケーションが常にユーザーに利用可能で、かつ耐障害性があることを確保することは非常に重要です。従来のモデルでは、インフラストラクチャリソースに対して完全なアクセス権と制御権があるため、これは簡単です。可用性を制御し、フェイルオーバーの方法などを理解しています。しかし、SaaSアニーホワデプロイメントモデルでは、責任を共有することになります。
SaaSプロバイダーは引き続きアプリケーションに関連するタスクに責任を持ちますが、テナントはインフラストラクチャリソースに関連するすべてのことに責任を持つことになります。テナントのプロビジョニング、アプリケーションの更新、デプロイメント、アプリケーションとリソーステンプレートの管理などのタスクはSaaSプロバイダーが担当します。リソーステンプレートは、SaaSアプリケーションをサポートするために必要なリモートインフラストラクチャをデプロイする方法をテナントに指示する一連の手順です。
インフラストラクチャに責任を持つテナントは、可用性要件、DR要件、インフラストラクチャを複数のAvailability Zoneにデプロイする必要があるかどうかを理解する必要があります。また、これらのインフラストラクチャのセキュリティにも責任を持ち、悪意のあるユーザーから保護しつつ、SaaSプロバイダーがアプリケーションを継続的に管理できるよう、適切なレベルの権限と接続性を提供する必要があります。テナントはまた、冗長性、データベースのバックアップ、バックアップ戦略、インフラストラクチャリソースが故障した場合にどれだけ迅速に新しいリソースを立ち上げられるかについても考慮しなければなりません。この責任共有モデルは、お客様とSaaSソリューションについて話し合う際のSLAに影響を与えます。
もう1つの重要な考慮事項は、スムーズなオンボーディングです。SaaSプロバイダーが常に念頭に置くべき重要な要素の1つは、価値実現までの時間です。これは、テナントがSaaSアプリケーションにサインアップし、システムにログインし、操作を行い、その価値を実感し始めるまでにかかる時間を指します。私たちは、この価値実現までの時間をできるだけ短くしたいと考えており、そのためには優れたスムーズなオンボーディングプロセスが必要です。
従来のデプロイメントモデルでは、サインアップページがあります。 ユーザーはサインアップページにアクセスし、情報を入力します。これにより、複数のタスクを実行するオーケストレーションプロセスが開始されます。 オンボーディングプロセスの一部として最初に実行するタスクは、テナント管理です。テナントIDを作成し、ステータスやティアレベルなど、テナントに関連するメタデータを保存します。
次のタスクはユーザー登録かもしれません。Amazon Cognitoを Identity Provider (IdP) として使用している場合、 新しいテナント用に新しいユーザープールを作成することがあります。最初の管理者ユーザーを作成します。これは重要です。なぜなら、このユーザーはできるだけ早く作成される必要があり、テナントがシステムにログインして必要な設定を行えるようにするためです。その後、彼らは必要な設定を行うことができます。
もちろん、SaaS環境内でテナントの分離ポリシーを実装する際に使用する、適切なIAMポリシーも作成します。
テナントのプロビジョニングは、オンボーディングプロセスの重要な部分です。オンボーディングプロセスの一環としてプロビジョニングが必要なリソースがある場合、例えばプレミアムティアのテナントで独自のインフラストラクチャを持つ場合など、この段階で行います。最後のステップの1つは課金統合です。通常、課金はSaaSアプリケーションの外部で行われ、これはサードパーティの課金プロバイダーや自社の財務部門である可能性があります。 いずれにせよ、課金は通常SaaSアプリケーションの外部で行われます。
SaaS Anywhereがオンボーディングプロセスに与える影響
従来のモデルでは、すべてが自動化され、摩擦のないプロセスであることがおわかりいただけると思います。ユーザーがサインアップすると、魔法のように物事が進みます。しかし、SaaS anywhereでは、リモート環境とリモートインフラストラクチャを導入することで、オンボーディングプロセスに影響を与えることになります。 ここで、前提条件としてのデプロイメントについて考える必要があります。外部アカウントと外部のリモートインフラリソースが存在するため、テナントはサインアップの一環として、我々が知っておくべきアカウント情報を提供する必要があります。また、リモートインフラをプロビジョニングするために、先ほど説明したAWS CloudFormationテンプレート、つまりリソーステンプレートをダウンロードします。
リモートインフラがプロビジョニングされた後、テナントはその情報をSaaSプロバイダーに提供する必要があります。これにより、プロバイダーはリモート環境とリモートインフラリソースに関する必要な情報を得ることができます。そして、これがオンボーディングタスクのオーケストレーションを開始します。テナント管理、ユーザー登録、テナントプロビジョニングなどです。そして今度は、リモートアプリケーションリソースのプロビジョニングがあります。 オンボーディングプロセスの一環として、これらのリモート環境にログインし、リモートインフラにアクセスして、SaaSアプリケーションのリモートコンポーネントをこれらのリモート環境にプッシュする必要があります。そして、課金統合も行います。
ご覧のように、SaaS anywhereソリューションを考える際には、オンボーディングプロセスから始まり、SaaSアプリケーション全体に影響を与えることになります。そして、これらがソリューションを設計する際に念頭に置くべき変更点であり、オンボーディングプロセスにどのような影響を与えるかを考慮する必要があります。次はリモート管理と更新についてです。 SaaSアプリケーションはSaaSプロバイダーで実行されるべきだと話しましたが、SaaS anywhereによってリモート環境が加わりました。ここで強調したいのは、リモートコンポーネントがあるとはいえ、それはアプリケーションプレーンであり、コントロールプレーンは依然としてSaaSプロバイダーに存在するということです。これが、先ほど言及したSaaSプロバイダーが使用する共有サービスのセットになります。
SaaS anywhereでは、SaaSプロバイダーがアプリケーションの管理に引き続き責任を負います。そのため、SaaSプロバイダーアカウントでコントロールプレーンを実行する場合、 SaaSプロバイダーアカウントからリモート環境やリモートインフラへの接続をどのようなサービスや方法で確立するかを考える必要があります。また、接続性だけでなく、前提条件のデプロイメントの一部として、テナントやお客様からどのような権限が必要かも考慮しなければなりません。これらにアクセスできるようにするためです。SaaSプロバイダーがソリューションを設計する際にこれらの決定を行うことが重要です。そうすることで、使用する技術スタックを正確に把握し、それらの要件をテナントに伝えることができます。テナントは、これらのリモートコンポーネントを実行するために何に同意しているのかを理解できるようになります。
メトリクスとモニタリングは SaaS環境において非常に重要ですが、SaaS anywhereのデプロイメントではさらに重要になります。リモート環境で実行されるリモートコンポーネントが加わったため、 これらすべてのリモート環境で何が起こっているかを完全に把握し、可視化することが極めて重要です。リモートコンポーネントのパフォーマンスはどうか？問題は発生していないか？ユーザーはどのように操作しているか？このような情報を収集し、中央の場所、つまりコントロールプレーンに送り返す必要があります。そうすることで、各アカウントに個別にログインして状況を確認するという状況を避けることができます。
その情報を集中管理された場所にプッシュすることで、先ほど申し上げたように、情報を集約し、分析して、全体像を把握することができます。ここでも、これを実現するための方法や実装アプローチ、利用できるサービスはさまざまですが、これが事前デプロイメントの一部であることを認識しておくことも重要です。そうすることで、顧客は自分たちが何に同意しているのか、そしてデータをSaaSプロバイダーに送り返すためにどのような接続やサービスを実装する必要があるのかを理解できます。
さて、設計上の考慮事項と実装アプローチについて話しましたので、次はトレードオフについて議論しましょう。SaaS anywhereソリューションを設計する際には、考慮しなければならないトレードオフがあります。
リモート管理と更新：SaaS Anywhereの課題
まず、SaaSの約束から始めましょう。私たちは中核となる属性について話しました。俊敏性、イノベーション、アプリケーションの可用性の確保、そして簡単かつ効率的に管理できるコスト効率の高いソリューションの実現について議論しました。
また、SaaS anywhereの動機についても話し合いました。SaaS anywhereのアーキテクチャやデザインが絶対に必要となる会話や要件があることを理解しています。しかし、これは慎重にバランスを取る必要のあるスケールです。複雑さについて、そしてそれがオンボーディングプロセス、接続、共有責任モデルでのデプロイに必要な権限をどのように変えるかについて話しました。
SaaS anywhereのデプロイメントモデルを考える際には、実際にどれだけの「anywhere」の作業が必要なのかを真剣に考える必要があります。アプリケーション全体をリモートにデプロイする必要があると思い込まないでください。そうすると、すべてのサービスに追加の複雑さが加わってしまいます。取り組んでいる要件や顧客が提起している懸念事項を注意深く見極め、それらの要件を満たしたり懸念に対処したりするために、どのサービスやストレージをリモートにデプロイする必要があるかを決定してください。つまり、SaaS anywhereに関しては、必要性は理解していますが、慎重に進めることが大切なのです。
SaaS anywhereのパターンと実装について詳しく説明する前に、「anywhere」の種類について触れておきたいと思います。これは、お客様が実行する環境や、統合が必要な第三者システムがどこで動作しているかを指します。
最初のタイプは、別のAWSアカウントです。お客様が別のAWSアカウントで運用している場合、アカウント間の接続やVPC接続に使用できるサービスを把握しておく必要があります。2つ目のタイプはハイブリッドクラウドです。お客様、テナント、 あるいは統合が必要な第三者システムが別のクラウドプロバイダーで動作している可能性があります。AWSで動作するSaaSソリューションを、ハイブリッドクラウド環境で確実に機能させるには何を考慮すべきでしょうか。
3つ目のタイプはオンプレミスです。統合が必要なレガシーアプリケーションや、お客様の環境やデータセンターで動作する外部システムについて話しました。これらの「anywhere」の種類を念頭に置き、どのタイプを扱うかを決定することが重要です。なぜなら、それによってテクノロジースタックや実装アプローチが大きく影響を受けるからです。今日の議論では、AWSアカウント内のソリューション、パターン、実装アプローチに焦点を当て、ハイブリッドやオンプレミスのシナリオには踏み込みません。
SaaS Anywhereの3つの主要デプロイメントモデル
では、Dhammikaが異なるパターンと実装アプローチについて説明します。 SaaS anywhereとは何か、設計上の考慮事項、そしてSaaS anywhereソリューションの構築を検討する必要がある理由について理解が深まったところで、実装の部分に入っていきましょう。まずはデプロイメントモデルを見て、そしてこれらのユースケースの構築にAWSマネージドサービスをどのように活用できるかを見ていきます。
SaaS anywhereのリモートコンポーネントの性質に基づいて、 主に3つのカテゴリーについて議論できます。最初のデプロイメントモデルは、分散データストアを持つSaaS anywhereです。このモデルでは、お客様やテナントが自身の環境でデータ、特にビジネスデータの管理と所有権を要求します。SaaSプロバイダーとして、アプリケーションプレーンからデータベースコンポーネントの一部をテナント環境に持ち込んでデプロイする必要があります。一方で、アプリケーションの残りの部分は引き続きSaaS環境で動作します。
2番目のデプロイメントモデルは、分散アプリケーションプレーンです。このモデルでは、テナントが自身の環境でビジネスロジックを持つことを要求しています。SaaSプロバイダーとして、アプリケーションプレーンから一部のマイクロサービスを抽出し、リモート環境にデプロイする必要があります。一方で、残りのアプリケーションプレーンとコントロールプレーンはSaaS環境内に留まります。
3番目のモデルは、リモートアプリケーションプレーンです。 このモデルでは、アプリケーションプレーンをスタンドアロンのエンティティとしてコンパイルし、テナントに対して自身の環境内にデプロイするよう依頼します。
次のモデルに移りましょう。分散データストアモデルでは、SaaSプロバイダーとして、 アプリケーションプレーンから一部のデータベースをテナント環境に移行します。これは主に、テナントがセキュリティ、コンプライアンス、規制、データレジデンシーの要件により、 自身の環境でビジネスデータの完全な所有権と管理を求めているためです。さらに、テナント環境のデータセット（データプラットフォームやデータレイクなど）との統合が必要なSaaSソリューションを構築するシナリオも考慮してください。 これらは多くの場合、大量のデータを扱うため、統合のためにすべてのデータをSaaS環境に転送するのは現実的ではなく、コストがかかります。
これらのデータストアの中には、モダナイズ やSaaSソリューションとの統合の準備ができていないレガシーシステムもあるかもしれません。そのような場合、アプリケーションプレーンから一部のデータストアをテナント環境に移行し、テナントの製品開発チームと協力してSaaSソリューションに必要なデータを抽出することを検討するかもしれません。 このモデルでは、テナントは主に自身の環境で稼働するリモートデータベースのストレージ管理と管理タスク（バックアップの取得、DRプランの実行、これらのデータベースがSaaS環境のアプリケーションプレーンと協調して動作するよう安全かつ利用可能な状態を確保することなど）に責任を持ちます。
例を見てみましょう。 お客様向けのeコマースSaaSソリューションを構築していると想像してください。従来のSaaSアーキテクチャでは、SaaSコントロールプレーンとアプリケーションプレーンをコンパイルし、テナントが使用するための単一のデプロイメントユニットとして自社環境でホストします。しかし、SaaS Anywhereのユースケースでは、テナントが支払い情報などのデータの管理を求めています。このようなシナリオでは、テナントに自身の環境（例えば、自身のAWSアカウント）をセットアップするよう依頼し、 SaaSプロバイダーとして、支払いデータベースをテナント環境にデプロイします。そして、支払いサービスが各テナント環境の支払いデータベースとリモートで連携してデータベース操作を実行し、アプリケーションプレーンの機能を提供できるようにアーキテクチャを設計します。
分散データストアモデルの実装と課題
実装方法は使用するデータベース技術によって異なります。例えば、Amazon DynamoDBを使用する場合、各テナント環境に支払い用のDynamoDBテーブルをプロビジョニングします。支払いサービスがそのDynamoDBテーブルに適切に接続できるようにするため、テナントのオンボーディング時に、テナントの環境内にこの特定のデータベーステーブルへのアクセスを提供するIAMロールを作成します。これにより、支払いサービスはアプリケーションプレーンからそのIAMロールを引き受け、AWS Security Token Serviceを使用してDynamoDBテーブルにアクセスし、リモートでのDB操作を行うことができます。
後続のテナントに対しても、同じメカニズムを踏襲します。SaaSプロバイダーとして、テナントのオンボーディング時にCloudFormationテンプレートを共有します。管理者はこれを自身の環境で実行して、支払いテーブルと必要なIAMロールを作成できます。その後、IAMロールのARNを取得し、支払いサービスがそのリモートデータベースに接続する必要がある際に、そのロールを引き受けることができるようにします。これらのIAMロールとポリシーがどのように構成されているかを見るのも興味深いですね。
この構造をより詳しく理解するために、例を見てみましょう。テナント側で行うべきことがいくつかあります。まず、クロスアカウントIAMロールを作成します。これは、SaaSプロバイダーにリソース（この例ではテナント1の支払いテーブル）に対して提供できる最小限の特権アクセスを定義します。この設定の2つ目の部分は、IAMロールに信頼ポリシーを付与することです。これは、誰がこのIAMロールをリモートで引き受けられるかを定義します。この例では、支払いLambdaサービスの実行ロールを使用し、アプリケーションプレーンからこのロールをリモートで引き受ける権限を提供しています。
これらはすべてテナント環境で行われます。支払いサービス側でもいくつかの設定が必要です。まず、支払いサービスに、先ほど作成したテナント1のロールに対してassumeRole APIを呼び出す権限を与えます。これには、このようなポリシーを使用し、それを支払いサービスの実行ロールにアタッチします。複数のテナントがある場合、このような複数のポリシーを管理し、それに応じて権限を提供することになります。これで設定は完了です。あとは支払いサービスにコードを実装するだけです。
ここで、実装を示すためにPythonコードを用意しました。テナント1が支払いサービスからリモート操作をリクエストしているとします。テナントIDはtenant1です。これに基づいて、テナント1のROLE_ARN、TABLE_NAME、REGIONなどの他の設定を読み込みます。次に、AWS STSのassumeRoleを呼び出し、パラメータとしてROLE_ARNを渡します。これにより、元々IAMロールで定義した権限を表す短期間有効なセキュリティキーを含むクレデンシャルオブジェクトが返されます。このクレデンシャルオブジェクトを使用してDynamoDBクライアントオブジェクトを作成し、テナント1環境でリモートでのDB操作を行うことができます。
ご覧の通り、関数の外部から、例えばHTTPヘッダーパラメータを使ってこれらのパラメータを上部に注入すれば、この関数をより汎用的にし、各テナントのすべての支払いデータベースに大規模に接続できるようになります。機能と実装は、このモデルで使用するデータベース技術によって異なりますが、SaaSプロバイダーとしては、リモートでデータベース操作を行うためのこのようなメカニズムが必要です。これにより、どこでもSaaSを利用できるユースケースを実現できます。
分散アプリケーションサービスモデルの特徴と実装
さて、ここで2番目のモデルを見てみましょう。これは分散アプリケーションサービスモデルです。このモデルでは、データベースを1つか2つ取り出すだけでなく、完全なマイクロサービスをアプリケーション層から取り出し、テナント環境にデプロイします。これは主に、テナントが自身の環境でビジネスロジックを持つことを求めているためです。パフォーマンスが最適化されたワークロードを処理し、顧客をターゲットにしたビジネス判断をより早く、より速く行うためです。
例えば、リモートエージェントを持つIoT SaaSソリューションを構築しているとします。テナント環境にリモートエージェントをデプロイすると、テレメトリーデータが生成されます。テナントがこのテレメトリーデータに対してビジネスロジックを実行し、データ分析を行い、それに基づいて顧客により迅速に対応する必要がある場合、この分散アプリケーションサービスモデルに従って、アプリケーション層からこれらの機能をすべて取り出し、テナント環境にデプロイすることになります。
SaaSプロバイダーにとっての課題の1つは、リモートワークロードを最小限に選択することです。本当に必要のないものを含めないようにする必要があります。なぜなら、ソリューション内の各テナントに対してこのリモートワークロードを維持・管理することになるからです。テナントの観点からは、より大きな責任を負うことになります。なぜなら、完全な機能を持つマイクロサービスを維持することになるからです。そのため、これらのマイクロサービスを実行するための適切なインフラストラクチャを提供する必要があります。
さらに、テナントはセキュリティ、耐障害性、可用性などの非機能要件がすべて満たされていることを確認しなければなりません。これにより、これらのマイクロサービスがSaaS環境で実行されているアプリケーション層の残りの部分と連携できるようになります。リモートの機械学習ワークロードを持つSaaSを構築していると想像してみてください。
従来のSaaSアーキテクチャに従うと、このML（機械学習）ワークロードをSaaS環境に集中させ、すべてのテナントで共有したいと考えるかもしれません。テナントがより良いテナント分離を求めている場合、テナント固有のMLワークロードを提供することになりますが、これらはサイロ化されたコンポーネントであっても、依然としてSaaS環境内に存在します。SaaS anywhereの場合、テナントはMLワークロードを自分たち自身の環境に置くことを要求しています。
つまり、SaaSプロバイダーとしては、SaaSコントロールプレーンと、アプリケーションプレーンの一部のみを自社環境に置くことになります。そして、MLワークロードや必要なマイクロサービスを含むアプリケーションプレーンの残りの部分は、テナントのオンボーディング時にテナントの環境にデプロイします。これにはいくつかの利点があります。MLワークロードは処理のためにデータストアと統合する必要がありますが、そのデータストアがテナント環境（右側に示した私的ワークロード）から来ている場合、MLワークロードがテナント1にローカルになるため、シームレスに統合しやすくなります。
2つ目の利点は、このモデルがより良いテナント分離を提供することです。例えば、ここでのMLモデルがテナント1にとってもプライベートである場合、SaaSプロバイダーにさえ公開されません。また、これらのリモートワークロードは、SaaS環境で実行されているアプリケーションプレーンと連携する必要があります。これは、計測されているメトリクスやモニタリングデータを提供するだけでなく、時にはSaaSアプリケーションサービスをリモートで利用するためでもあります。
そのため、テナントとSaaSプロバイダー間の接続性は、このユースケースでも重要です。例えば、より信頼性の高い接続を求める場合、AWS PrivateLinkのようなマネージドサービスの利用を検討することもあるでしょう。名前が示すように、PrivateLinkは各テナントがSaaSプロバイダーのアプリケーションプレーンに接続するための専用の接続性を提供します。このシナリオでは、テナントのオンボーディング時に、テナント1のVPCにVPCエンドポイントを設置し、それをPrivateLinkに接続します。これにより、Network Load Balancerを介してアプリケーションプレーンに接続できるようになります。各テナントには、それぞれ専用のVPCエンドポイントとPrivateLinkが用意されます。
これらの接続はすべて信頼性が高く、トラフィックはAWSのバックボーン内を通るため、テナントとSaaSプロバイダー間の通信の全体的なパフォーマンスとレイテンシが最適化されます。このモデルには多くのユースケースが考えられます。リモートワークロードと接続性のニーズに基づいて、複数の実装について議論することができます。しかし、SaaSプロバイダーにとって重要なのは主に2つのことです。1つ目は、適切な、あるいは最小限のワークロードをリモートワークロードとして選択すること。2つ目は、テナントとSaaSプロバイダー間の接続性を含め、アーキテクチャを構築するための適切な技術を選択することです。
リモートアプリケーションプレーンモデルの概要と適用例
最後のデプロイメントモデルは、リモートアプリケーションプレーンです。ここでは、完全なアプリケーションプレーンをテナント環境にデプロイし、SaaSプロバイダーとしては、自身のSaaS環境でコントロールプレーンのみを管理します。この方式の主な理由、つまり主要な推進要因は、テナントがデータとビジネスロジック、そしてアプリケーションプレーンに実質的に含まれるすべてのものの完全な所有権を要求していることです。これは主にセキュリティとコンプライアンスの懸念によるものです。
また、SaaS環境で密接に結合されたローカル統合がある場合、近接性も推進要因となる可能性があります。テナントはこれらのワークロードを顧客により近い場所に置く必要があり、そこでエンドカスタマーにより最適化されたパフォーマンスや低レイテンシーの価値提案を提供できます。
時には、組織文化や非技術的な制約がこのアプリケーションモデルを推進することもあります。これは、誰もがより良いテナント分離を必要とする場合があるためで、時には正当な理由があります。しかし、レガシーな組織文化的マインドセットもこれらのデプロイメント戦略を推進することがあります。結果として、完全なアプリケーションプレーンを各テナントに個別にデプロイすることになります。テナントは最大の責任を負うことになります。なぜなら、データベース1、2個や少数のマイクロサービスだけでなく、完全なアプリケーションプレーンが現在テナントの環境で動作しているからです。彼らはDevOpsチームを持ち、SaaSプロバイダーが指定したとおりにこのアプリケーションプレーンの周りに適切なインフラを提供する必要があります。さらに、セキュリティ、回復力、スケーラビリティ、高可用性などのすべての非機能要件を維持し、このアプリケーションプレーンがSaaS環境で動作するコントロールプレーンと適切に連携して動作するようにする必要があります。
例えば、クラウドベースのコアバンキングSaaSソリューションを構築している場合を考えてみましょう。SaaSプロバイダーとして、自身の環境にはコントロールプレーンのみを持ち、アプリケーションプレーンをコンパイルしてテナントの環境（この例では銀行）にデプロイします。右側のプライベートワークロードボックスは、SaaSソリューションでコアバンキング機能を正しく実現するために統合する必要があるクラウドベースのバンキング機能を表しています。テナントのオンボーディングプロセス中に、これらの統合を適切に行うために銀行の製品開発チームと協力する必要があるかもしれません。
テナントユーザーは今や、テナント環境自体にすべての必要なものを持っています。彼らはSaaSソリューションを利用するために、テナント環境で動作するアプリケーションプレーンに接続します。もはやSaaSプロバイダーのアカウントや環境に接続する必要はありません。このアプリケーションプレーンは、依然としてSaaSプロバイダーのアカウントでホストされているコントロールプレーンと連携して動作する必要があります。これにより、計測されているメトリクス、アプリケーションインサイト、トレース、そしてSaaSプロバイダーが必要とするすべてのメタデータを提供します。これにより、SaaSプロバイダーは適切なコントロールプレーン機能を提供し、アプリケーションプレーンを今後管理・運用することができます。
このモデルには、多くのユースケースが考えられます。ユースケースに応じて、アプリケーションプレーンの実装も異なってきます。例えば、患者情報や健康履歴、その他の規制対象データに接続する必要がある医療系SaaSソリューションを考えてみましょう。また、医療提供者の既存ITシステムとの連携も必要かもしれません。これには多くのドメイン固有の統合が含まれます。このようなユースケースでは、SaaSアプリケーションプレーンをコンパイルし、このモデルに従ってテナントの環境全体にデプロイすることを検討するかもしれません。
SaaS Anywhereの運用面での課題と解決策
これらが、SaaS anywhereのコンテキストで説明したい3つの主要なデプロイメント戦略です。これらは、SaaSソリューションを構築し、リモートコンポーネントや環境と接続してソリューションを稼働させるためのメカニズムを提供します。 SaaS operationsの側面も課題となり、大規模なSaaS anywhereユースケースの運用には多くの側面があります。Peterがいくつかの側面について触れましたが、ここでは重要な点をいくつか掘り下げてお話ししたいと思います。
まず、リモートデプロイメントについて話しましょう。 SaaS anywhereユースケースを実装するためにどのデプロイメントモデルを使用するにしても、リモートワークロードを管理・維持する必要があります。ここでは例として、左側にCI/CDパイプラインを持つSaaSプロバイダーのDevOpsアカウントを示しています。製品開発チームがリモートワークロードに新機能をリリースしたい場合、最新のコードや設定をcode commitにプッシュすると、
CloudWatchイベントが発生し、CI/CDパイプラインが開始されます。 コードは最新のコードと設定を取得して新しいアーティファクトをビルドし、中央リポジトリにアップロードします。その後、制御がAWS CloudFormationに引き渡されます。ここで、CloudFormationは Tenant 1の環境に接続して最新のワークロードをデプロイする方法が必要になります。
これを実現するために、Tenant 1のオンボーディングプロセス中に、そのテナント環境に別のIAMロールを作成します。このロールは、Tenant 1環境でCloudFormationスタックをリモートで実行する権限を提供します。そして、先ほど説明したAWS STS AssumeRoleを使用して、アプリケーションまたはSaaSプロバイダーの環境から このIAMロールを引き受け、Tenant 1環境でCloudFormationスタックをリモートで実行してアクセスを得ることができます。 これにより、リポジトリから最新のアーティファクトを取得し、リモートワークロードを更新することが可能になります。
SaaS プロバイダーとして確実に行う必要があることがいくつかあります。まず、SaaS プロバイダーのアカウントと連携して、デプロイメントのステータスを伝達し、問題が発生した場合のロールバックを処理するための追加の仕組みが必要かもしれません。 次に、すべてのテナント環境を同じ最新バージョンに更新する必要があります。CI/CD パイプラインは、各リモート環境に最新バージョンをループしてデプロイできるようにする必要があります。これは、SaaS anywhere ソリューションの全体的な俊敏性と運用効率を維持するために極めて重要です。
次に考慮すべき点は、クロスアカウントの可観測性です。SaaS プロバイダーとして、テナントが何をしているかをどのようにモニタリングし、 生成されるメトリクスにどのようにアクセスするか、また他の可観測性やモニタリングの側面について疑問に思うでしょう。クロスアカウントの可観測性のためのオープンソースツールやパートナーソリューションを活用することができます。Amazon CloudWatch を活用するのも一つのアプローチです。 ここでのアイデアは、リモートワークロードが、計測されているすべてのメトリクス、アプリケーションインサイト、トレース、ログを各テナント専用の CloudWatch インスタンスにプッシュするように開発されているということです。
そして、CloudWatch のクロスアカウント可観測性機能を有効にすることで、 各テナントからのすべてのデータを SaaS プロバイダーアカウントのコントロールプレーン上で実行されている CloudWatch インスタンスに同期させることができます。これにより、DevOps チームは各テナントのリモート環境から送られてくるこれらのメトリクスやアプリケーションインサイトにアクセスできるようになります。また、このデータセットを拡張して、クロスアカウントのモニタリング ダッシュボードやプラットフォームを構築し、DevOps 管理を向上させることも容易です。
SaaS 運用の側面には他にも懸念事項や課題がありますが、これらの点と我々が検討してきたデプロイメントモデルを通じて、SaaS anywhere のユースケースを効果的に構築・運用できるはずです。今日は SaaS anywhere について多くのことを取り上げました。定義から始まり、設計上の考慮事項や SaaS anywhere を構築する背景となる要因について説明しました。3つのデプロイメント戦略を探り、これらのユースケースの構築に AWS サービスをどのように活用できるかを見てきました。最後に、SaaS 運用の観点について議論しました。
SaaS Anywhereの総括：メリットと課題
まとめると、SaaS anywhere は、 従来の SaaS アーキテクチャの境界を押し広げるメカニズムを SaaS プロバイダーに提供します。データベース、マイクロサービス、さらにはアプリケーションプレーン全体といったアプリケーションプレーンのコンポーネントを取り出し、テナント環境にデプロイすることができます。これにより、エンドカスタマーであるテナントにとってより良い価値提案が可能になります。そのため、すべての SaaS anywhere ユースケース には、リモート環境にデプロイされるリモートコンポーネントが存在することになります。SaaS プロバイダーにとっての課題は、これらのリモート環境を制御できない可能性があることです。
これらのリモート環境では、SaaSプロバイダーはテナントに属するため、最小限の特権アクセスしか持ちません。そのため、アーキテクチャにはこれらのリモート環境をデプロイするだけでなく、リモートワークロードを操作し、すべてのテナントに対して更新や運用を行うための追加の複雑さが必要になります。この部分を実現するためには、アーキテクチャに計装が必要になります。
SaaS anywhereのユースケースを構築しなければならない理由は多々ありますが、本番環境にSaaS anywhereのユースケースを展開するために必要な、アーキテクチャへの追加の計装についても考えていただきたいと思います。主な展開戦略は3つあります。ユースケースに基づいて適切な戦略を選択することが重要です。適切なマネージドサービスやパートナーソリューションを選択することで、リモート環境への必要なアクセスを提供し、望むように管理・運用できるようにするための関連機能をアーキテクチャに構築するのに役立ちます。適切な技術やツールを選択することが重要です。
SaaS anywhereを構築するのは、テナントに追加の価値提案を提供するためです。同時に、運用効率、コスト効率、規模の経済、俊敏性、イノベーションなど、元のSaaSのコアバリュープロポジションがSaaS anywhereのユースケースでも維持されるようにしたいと考えています。これらの価値がSaaS anywhereのユースケースにも含まれるようにしたいのです。これはまだ新しいトピックです。現在、お客様やパートナーがSaaS anywhereのユースケースの開発モードに入っているのを目にします。前回のre:Inventでは、このトピックについて初めてChalk Talkを行いました。お客様やパートナーがどれほど多くのSaaS anywhereユースケースを構築しているかを見られて素晴らしかったです。
SaaSに関する追加リソースと締めくくり
以上が本日のプレゼンテーションの内容です。このセッションが役立ち、SaaS anywhereのユースケース構築についてより良い視点を得られたことを願っています。締めくくる前に、いくつか注意点を共有させていただきます。これらは私たちのチームがre:Inventで行っているSaaSセッションの一部です。これらのセッションIDをメモしておくと、ここでのセッションや録画が利用可能になったときに参照できるでしょう。また、参加して対話的に価値を加えられるChalk Talkもいくつかあります。ハンズオンの5つのワークショップも行っています。これらのSaaSソリューションがどのように構築されているかを実際に見たい場合は、これらのワークショップへの参加を強くお勧めします。Builder's SessionとBusiness Sessionもあります。
ここで、この画面をもう少し長く表示しておきます。写真を撮りたい方のためです。これらのQRコードは、私たちがAWSで取り組み、公開してきたSaaSに関する先進的な考え方にアクセスするためのものです。SaaSのリファレンスアーキテクチャ、ブログ投稿、ホワイトペーパー、そして私たちが作成したすべてのコンテンツへのリンクが含まれています。また、SaaS Competencyパートナー、SaaSジャーニーを加速させるのに役立つドメインエキスパートにアクセスすることができます。さらに、SaaSビジネスの構築と成長に関する多くの規範的なガイダンスも提供されています。
SaaS anywhereについて十分に理解していただけたことを願っています。今後、組織内でSaaSソリューションを構築したり近代化したりする際には、SaaS anywhereのコンテキストに取り入れることを検討していただければと思います。ご参加いただき、ありがとうございました。共同発表者のPeterにも感謝します。素晴らしい夜をお過ごしください。そして、re:Inventの残りの部分も素晴らしいものになりますように。 良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion