re:Invent 2024: AWS SaaS Factoryが語るSaaSアーキテクチャの落とし穴と対策
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - SaaS architecture pitfalls: Lessons from the field (SAS305)
この動画では、AWS SaaS Factoryチームが10年以上の経験から学んだアーキテクチャ上の落とし穴と対策について解説しています。Control PlaneとApplication Planeの分離、SaaS Builder Toolkitを活用した効率的な管理、Identity管理におけるベストプラクティス、OpenTelemetryを活用したObservabilityの実装など、SaaSアプリケーション開発における重要な知見が共有されています。特に、AIの台頭により顧客データへのアクセスが必要となる中で、AWS Nitro EnclavesやData Privacy Vaultを活用したセキュリティ対策、Revenue Leakageを防ぐための課金管理、そしてGremlinを使用したカオスエンジニアリングによるテスト手法など、最新のSaaS開発における具体的な実装方法が詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
SaaS 305: AWSが学んだアーキテクチャの落とし穴
本日は遅い時間帯にもかかわらず、ご参加いただきありがとうございます。Happy Hourが始まる時間帯ですが、私と時間を共有していただき、大変感謝しています。これはSaaS 305で、AWS SaaS Factoryチームが、AWSのお客様と10年以上にわたって協働してきた中で学んだアーキテクチャ上の落とし穴について焦点を当てていきます。これらの経験から得た学びを共有し、さまざまな進展について説明していきます。人々が犯した間違いに焦点を当てるのではなく、それらの落とし穴から学んだことと、SaaSのお客様である皆様がこれらのベストプラクティスを念頭に置いて、同じ落とし穴を避けながらアプリケーションを開発する方法に焦点を当てたいと思います。私はBill Tarrと申します。AWS SaaS Factoryチームのプリンシパルソリューションアーキテクトを務めています。
まずはSaaSの約束からお話しさせていただきます。もしYouTubeでご覧の方がいらっしゃれば、これは昨年のセッションの再演であることをお伝えしておきます。ただし、今回は新しい落とし穴を含めて、少し異なる内容となっています。変わっていないのはSaaSの約束です。 長年にわたり、私たちはSaaSで同じ目標を達成しようとしてきました。それには、チームの俊敏性と柔軟性の維持が含まれます。私たちは、お客様のために革新を届け続け、お客様を喜ばせる機能の提供に焦点を当て続けたいと考えています。 そして、それを実現しながら運用効率を維持したいと考えています。アプリケーションの管理に追われすぎて、スケールができなくなったり、イノベーションではなく運用だけに注力せざるを得なくなったりする状況は避けたいのです。
特に重要なのは、ここ数年より多く議論されるようになった持続可能な成長です。当初、SaaSについて考える際は成長に焦点を当てていました。それ自体は良かったのですが、最近では、単にアプリケーションを成長させて顧客を増やすことから、収益を上げ、持続可能な成長を達成できるかどうかに重点が移ってきています。私たちが構築したものの基本的なコスト構造を理解し、それを企業に投資するすべての人々に説明する必要があります。獲得している顧客が実際に収益を生み出しているのかを把握し、成長を続けながらも収益性のある形でソフトウェアを運用できることを証明する必要があります。
Control Planeの重要性とSaaS Builder Toolkitの紹介
さて、今年のこのトークで変更された点は、私が焦点を当てたい落とし穴です。 まず、成長のための構築方法について考えていきます。重要な落とし穴の1つは、Identityの軽視です。SaaS Factoryチームに5年以上前に参加して以来、私たちはIdentityについて話し続けてきましたが、今でも同じ落とし穴に陥る人々に出会い、同じ問題に対処せず、顧客が特定の機能を要求する前にIdentityの課題に先手を打っていない状況を目にします。 もう1つのよくある落とし穴は、不十分なTelemetryです。私たちはよく、Telemetryと可観測性を持っていると言うSaaSのお客様に出会いますが、その可観測性をどのように使用すべきか、誰がそれを消費するのか、そして彼らが適切に仕事をするためにどのようなデータが必要なのかについて、深く考えていないことが多いのです。
Revenue Leakage（収益漏れ）は、今年私が知った用語です。これは新しい概念ではありませんが、SaaSにとって特に関連性が高いものです。単にお金がどのように入ってくるかを理解するだけでなく、使用量ベースの課金やエンタイトルメントなど、潜在的な収益源を細かく理解し、契約の再交渉のタイミングを知るためにテナントの消費を確実に測定する必要があります。 そして、テストへの過小投資があります。これは昨年のトークでは全体に散りばめられていた内容ですが、SaaSのお客様にとってテストが依然として課題であり続けているため、今回は1つの落とし穴としてまとめました。
まず最初の落とし穴である「制御プレーンの制御不能」についてお話ししましょう。お客様とお話しする中で、いまだに同じような話を耳にします。発見フェーズでは、オンボーディングを行い、FinOpsやDevOpsの取り組みもあるのですが、制御プレーンについて詳しく掘り下げてみると、実際にはそれが存在していないことを認めることが多いのです。単一の視点からソリューションを運用できておらず、代わりにツールがアプリケーション全体に分散していて、システムを1つのユニットとして運用する方法が欠けているのです。
SaaSには、制御プレーンを含む異なるツールセットが必要です。 アプリケーションプレーンはさまざまな形態を取り得ます。これは、ロードバランサーを前面に配置してAmazon ECS上で動作する、非常にシンプルなSaaSアプリケーションの一例に過ぎません。アプリケーションプレーンがどのような形であれ、制御プレーンは不可欠です。
制御プレーンは、 これらの多くのアプリケーションプレーンを運用するための様々なツールで構成されています。この制御プレーンには、 管理者が顧客を簡単にオンボーディングできるようにするための管理者向けエクスペリエンスが必要です。また、制御プレーンとアプリケーションプレーンの両方に広がるアイデンティティの仕組みや、メトリクス、 課金（私たちのソリューションへの対価を得られることを願っています）、そして制御プレーンの一部となる階層やテナント、管理者ユーザー、テナントユーザーの管理方法も必要です。
SaaS Builder Toolkitの機能と利点
これは私たちが長年話してきたコンセプトです。今年の違い、そして私たちのチームの進歩という点で最も興奮していることは、SaaS Builder Toolkitというツールです。これは私たちのチームが構築したオープンソースの無料ソリューションで、 先ほど制御プレーンについて説明した多くのコンセプトを実装しています。もちろん、すべては依然としてアプリケーションが中心です - 結局のところ、SaaSソリューションとは、私たちがお客様に提供するアプリケーションなのです。
私たちが構築したのは、これらのコンセプトすべてを実証する実用的なサービスです。AWS CDKで書かれているため、実装に関しては独自の考えを持っています。オンボーディング、メトリクスと分析、課金、階層管理、テナントユーザー管理など、制御プレーンの一部と考えられるさまざまなコンセプトを実証するサービスを提供しています。また、管理者向けのユーザーエクスペリエンス、管理コンソール、UI、CLIなど、管理者が制御プレーンを使用・管理するための様々なツールも提供しています。
私たちはデプロイメントに関して独自のアプローチを取っています。アプリケーションプレーンへのデプロイを単一のコントロールプレーンが担当するのではなく、このデプロイメントソリューションの一部をアプリケーションプレーンに移行しています。これにより、コントロールプレーンからアプリケーションプレーンへのイベント発火にAmazon EventBridgeを利用するだけで、プロビジョニングを開始でき、アプリケーションプレーンを独立して運用できます。これによって、SaaS Builder Toolkitのような単一のコントロールプレーンで異なるタイプのスタックを管理できるようになり、サービスリファレンスアーキテクチャ、Amazon EKSリファレンスアーキテクチャ、Amazon ECSリファレンスアーキテクチャなどを使用できます。技術的な好みに関係なく、同じSaaS Builder Toolkitですべてのアプリケーションプレーンを管理できるのです。
また、SaaSの実装でよく見られるベストプラクティスを示すポイントソリューションもいくつか用意しています。 TVMはトークンベンディングマシンで、Amazon SQSとAmazon S3のベストプラクティスを含んでいます。ソフトウェアの監視に使えるダッシュボードも用意しており、これらは今後も追加していく予定です。重要なのは、SaaS Builder Toolkitがプラグイン方式のソリューションだということで、後ほどいくつかのプラグインをデモでお見せします。アイデンティティ用のプラグインや課金用のプラグインを用意しており、今後もコントロールプレーンとアプリケーションプレーンの様々な側面を管理するためのサードパーティソフトウェアを使用できるよう、開発を続けていきます。
ここでQRコードをお見せしますが、小さすぎて写真を撮れないかもしれません。ご心配なく、これらはすべてオンラインで公開されます。動画はすぐに公開され、これらのリンクをすべて含むPDFも公開される予定です。先ほどお話しした標準化、SaaS Builder Toolkitのプラグ可能性が、ここで重要になってきます。そしてSaaS Builder Toolkitだけがこのような革新を行っているわけではありません。Omnistrateというコントロールプレーンをサービスとして提供するツールもあり、私も非常に気に入っているのですが、これも同様に必要な機能を補完するプラグインを提供することで、何を自社で構築し、何をサードパーティツールで代用できるかを理解できるようにしています。
これには課金も含まれ、これらの個々のトピックは多くの場合、複数のトピックに分かれます。複数の決済プロバイダーが必要になったり、特にエンタープライズ顧客向けに販売する場合はAWS Marketplaceとの統合が必要になったりするかもしれません。メトリクスと分析は、可観測性の話であり、分析の話であり、場合によってはSREの役割のための学習にもなるかもしれません。セキュリティには多くの異なる実装がありますが、アイデンティティ、コンプライアンス、セキュリティストーリー、認可ストーリーに加えて、CI/CDツールやFinOpsツールを使用したDevOpsストーリーも関係してきます。
これらはすべて、チームが取り組みたくないような特定のタスクをより適切に処理できる個別のサードパーティ製品を表している可能性があります。SaaS Builder Toolkitとこれらのサードパーティソリューションの様々な実装例があることで、これらのアプリケーションをテストしてSaaS環境でどのように機能するかを確認するという、差別化されていない重労働の一部を取り除くことができます。
Tenant管理とControl Planeの関係性
さて、Tenant管理は、Control Planeで見てきたトピックの1つです。Control Planeを持たないことがなぜ落とし穴になり得るのかについて、SaaS Builder Toolkitでこのテナント管理を構築する際に私たちが考えていた概念と、それが実際のSaaSアプリケーションでどのように展開されるのかをお見せしたいと思います。なぜなら、SaaSアプリケーションは通常、CI/CDツールなど、多くの異なる領域をカバーする大きなフットプリントを持っているからです。
バージョン管理やCI/CDからの出力を理解する際には、様々な側面を考慮する必要があります。私たちのインフラはコードとして管理されているため、Terraformを実行する際の出力の場所、実際のスタックの出力内容、そしてそれらの状態をどのように管理するかを把握する必要があります。また、Identity Provider、Tenant Identity Provider、分析ダッシュボード、顧客に提供するURL、Payment Processor、FinOpsツール、機能管理ツールについても把握が必要です。Launch Darklyを使用している場合、特定のTenantに対する機能フラグの状態はどうなっているのでしょうか？ソリューションの運用者として、これらを単一の視点からどのように理解し、確認すればよいのでしょうか？
これらのコンポーネントはすべて、オンボーディングとオフボーディングのプロセスに関わっています。顧客をオンボーディングしてこれらのインフラストラクチャをすべて作成する際には、これらのツールをオフボーディングすることもできなければなりません。Payment Processorを選択した場合、余分なリスクを避けるため、残されたものをすべてクリーンアップする必要があります。すべてが相互に接続されており、Control Planeがこれらすべてを機能させています。Tenantは中心となるエンティティであり、Control Planeがこれらすべてをテナントに接続しているのです。
SBTセッションがあと2つ残っています。今日は水曜日なので、幸運なことに両方とも明日開催されます。1つは12:30からのTodd GoldingによるSAS406で、もう1つはワークショップのSAS304です。木曜日なので、並んで待っていただければ、参加できる可能性が高いと思います。これらのセッションでは、私が数枚のスライドで説明できる以上の深い内容に踏み込むので、ぜひ参加してみてください。
2つ目の落とし穴は、アイデンティティの危機です。私たちは最初から、Amazon Cognito、Okta、Auth0、Ping Identityなど、様々なSaaSプロバイダーと協力してきましたが、同じような問題が繰り返し発生しています。シンプルなアイデンティティの話から始まり、他の課題が出てきます。ユーザー認証だけでなく、マシン間認証についてはどうでしょうか？顧客ごとに異なるアイデンティティポリシーをどのように処理するのでしょうか？このアイデンティティの話は非常に複雑で、最初から正しく構築しないと、後々問題が発生する可能性のある一連の落とし穴を表しています。
Identityの重要性とAmazon Cognitoを活用したソリューション
シンプルなIdentityのストーリーから始めましょう。SaaSアプリケーションがあり、SaaS管理者とテナントユーザーが同じアプリケーションにログインするというケースです。 最初はユーザー名とパスワードを含むデータベースから始めるかもしれませんが、できるだけ早くIdentity Providerを使用する方向に移行することが望ましいでしょう。Identity Providerを導入すると、ユーザーがログインした際に何らかの形式の Identityトークンが返されます。どのユーザーがどのテナントに属しているかを管理するために、テナントマッピングツールを作成するかもしれません。これが最適な解決策だとは言いませんが、最初のアプローチとしてはありえます。また、Admin Consoleを提供して、 テナント管理者が同じコンソールにログインできるようにすることもあるでしょう。
これらの要素は初期段階では許容できるかもしれませんが、後で対処が必要な技術的負債を抱え込んでしまう可能性があります。これから新しい概念をいくつか紹介していきますが、これらは最初から考慮すべきこと、あるいはすでにこのような方法で構築してしまっている場合は、いつ対処すべきかを検討する必要がある点です。 最初に考慮すべき点の1つは、Identityを複数の部分から成るストーリーとして捉えることです。実際には単一のアプリケーションを構築しているわけではありません。先ほど説明したControl PlaneとApplication Planeは、Identity の観点からは2つの異なるドメインなのです。
Admin ConsoleとSaaSアプリケーションは引き続き存在しますが、 ここでIdentityの観点からこれらを区別して考えてほしいと思います。テナントユーザーは引き続き私たちのIdentity Providerにログインし、 テナントマッピングも行うかもしれません（これは後で変更される可能性があります）。ここで、SaaS管理者用に別のIdentityストーリーを用意し、これらをできるだけ分離しておきたいと考えています。なぜなら、 私たちは実際に2種類のアプリケーションを構築しているからです。Application Planeはマルチテナントアプリケーションで、各顧客やテナントがそのアプリケーションのバージョンを使用します。一方、Control Planeのテナントは私たち自身であり、そのアプリケーションを使用するのは私たちだけです。
これらの2つのものを管理する方法において、Identityストーリーは大きく異なるべきです。同じツールを使用する場合でも、例えばAmazon Cognitoを両方で使用する場合でも、別々のUser Poolを使用し、場合によってはCognitoが存在する別のアカウントを使用するなど、これらを明確に区別しておく必要があります。テナントが誤ってControl Planeにログインしてしまうことは絶対に避けたいからです。この分離によって、これらの異なるツールを構築する際の柔軟性も維持できます。コンソールも別々にすべきです。Control Planeをテナントがアクセスするものだと考えてしまうことは、私が遭遇してきた落とし穴の1つです。使用している用語が異なる場合や、Control Planeを複数の目的で使用している場合があるかもしれませんが、テナントがユーザー体験を管理する方法は、実際にはそのテナントドメインの一部なのです。
さて、テナントマッピングツールについて何度か言及してきましたが、テナントマッピングツールを使用しない場合について話してみましょう。ここで、もう少し具体的なアプリケーションの話に入っていきます。
では、API GatewayとLambda Authorizerの導入について説明していきましょう。Lambda Authorizerについてご存知ない方のために説明すると、JWTトークンを受け取って解析することができます。具体的な例を後ほどのスライドでお見せします。 ここで、Amazon Cognitoを導入します。SaaSプロバイダーが利用できるIdentity Providerは他にもたくさんありますが、今回はCognitoを使用した例をご紹介します。Cognitoのユーザープールは、Cognito内で分離環境を作成する便利な方法です。 この例では、各テナントに個別のユーザープールを割り当てます。これはCognitoでマルチテナンシーを実現する唯一の方法ではありませんが、テナントごとの認証パターンに柔軟性を持たせることができる便利な方法です。
これらの個別のプールを使用し、JWTトークンにテナントIDを組み込むことで、テナントマッピングを別途行う必要がなくなります。Cognitoが実際にテナントマッピングを代行してくれるわけです。ここでその仕組みをご覧いただけます。これらのプールには個々のIDが含まれており、それらはJWTトークンを通じて私たちに渡されます。このテナントID、つまりテナントトークンを使って、各テナントのIDをマッピングできるようになりました。JWTトークンが流れてくると、個々のユーザーがどのテナントに属しているかが分かり、 IAMを使用してポリシーでユーザーのアクセス権限を定義できるようになります。
AWS STSを使用してIAM内のロールを引き受けることができます。そのロールは次のようになります。 見づらいかもしれませんが、特に下の行に注目してください。ソフトウェアで使用する他の変数と同じように、変数が含まれています。あの波線のような部分は、Principal Tagと呼ばれるタグの一種で、Tenant IDと名付けられています。このタグは、次のスライドで説明する具体的な値に置き換えられます。これが完了すると、 AWSのCLIにログインする時と同じような一時的なセキュリティ認証情報が返されます。Secret KeyやAccess Keyなど、まさにそのような値が返され、それらを使ってAWSサービスへのテナントアクセスを制限することができます。
Amazon DynamoDBやAmazon S3など、特にネイティブストレージを持つサービスに対して使用できます。また、この同じ値を使って他の機能も実現できます。このように、最初の列にテナント識別子がある例のように、AWSサービスのネイティブな機能を活用できることは非常に価値があります。このIAMポリシーを見返すと、DynamoDBのリーディングキー、つまり最初の列を見ることで、どのテナントがそのレコードにアクセスできるかが分かります。これは行レベルセキュリティと呼ばれる非常に強力な手法です。
もちろん、ABAC（属性ベースのアクセス制御）と呼ばれるセキュリティ用語を使用してこれらの戦略を実装する方法についても、ブログで詳しく解説しています。このブログでは、テンプレートを使用せずにIAMで動的なロールを管理する方法について詳しく説明しています。では、コード側でどのように実装されるのか、もう少し詳しく説明していきましょう。深く掘り下げすぎないようにします。普段コーディングをされない方でも、概念としては十分理解していただけると思います。
Cognitoについてもう少し詳しく見ていきましょう。先ほど説明したように、各テナントは独自のUser Poolを持ち、その中にテナントユーザーが存在します。このテナントユーザーには、テナントID、ステータス、所属するTier、さらには所属するリージョンなどのカスタム属性が設定されています。これらの変数をそこに含めることができます。これらはCognitoが生成するJWTトークンに含まれることになります。ここに示しているのは、JWTトークンの簡略版です。完全なJWTトークンではありませんが、これらのカスタムクレームが私たちのJWTトークンに追加されているのがわかります。
Federated Identityとフリクションレスオンボーディング
次に、サーバーリファレンスアーキテクチャから取得したコード例を紹介します。ただし、後ほど説明する小さな例外があります。これはTenant Authorizerクラスからのもので、ここでJWTトークンを取得し、テナントの識別情報を抽出します。これは先ほどのスライドで示したものと全く同じで、比較的簡単に実行できます。そして、先ほど説明したように、STSを使用してロールを引き受けます。ここで少し変更点があると申し上げましたが、これは実際にはサービスリファレンスアーキテクチャとは完全に一致していません。なぜなら、そちらではABACを使用せず、カスタムテンプレートを使用しているからです。
そこで、コードを少し変更してABACストラテジーを使用するようにしました。ご覧のように、タグを渡しています。テナント変数をタグとしてIAMに渡し、「この変数を見つけてこの値に置き換えて」と指示しています。これがテナント1に戻ります。テナント1を渡すと、これが返されます。現在Lambda Authorizerの中にいることを覚えておいてください。つまり、これはAPI Gatewayを通過しています。JWTトークンを取得し、テナントIDを抽出し、そしてセキュリティキーとアクセスキーを指定する認証情報を作成しました。これにより、他のAWSサービスから情報を取得する際に使用するAWS SDKのすべてのバージョンへのアクセスが制限されます。
仮想的な意味で、IAMロールは以下のように置き換えられ、先ほど見た変数がテナント1に置き換えられています。データアクセスオブジェクトに関しては、Amazon DynamoDBのAWS SDKを初期化する際に、そのコンテキストを渡すだけで、DynamoDBへのすべての呼び出しがテナント変数によってスコープされます。アクセスできるのは、自分が権限を持つテナントのデータだけです。たとえコード内でこれらのクエリを制限し忘れたとしても（DynamoDBには厳密にはWHERE句はありませんが、概念的にはご理解いただけると思います）、自分のテナントのデータにしかアクセスできません。
これで一通りの説明は終わりです。こちらがサービスリファレンスアーキテクチャへのリンクです。これらが実際のファイルなので、ABACを使用していない点を除けば、ファイルベースのポリシーを使用して同じことを実現する方法を確認できます。同じファイルで、同じトークンベンディングマシンのコンセプトを実現する22の異なる方法を見ることができます。このコンセプトの別の重要な部分で、テナントの一部がよく直面する問題として、SaaSにおけるポリシーとパーミッションの考え方があります。私たちは通常、テナントIDの観点からほぼすべてを考えています。先ほどと同様に、テナントは私たちのSaaSアプリケーションにログインし、Amazon Cognitoを使用し、User Poolsを持っています。
しかし、実際のビジネスユースケースが単なるテナント分離だけではない場合はどうでしょうか？複数のテナントが同じデータを共有する必要がある場合はどうでしょうか？サプライチェーンのようなビジネスユースケースを想像してみてください。私たちは異なる会社で働いていますが、Amazon S3バケットに存在する同じサプライチェーンのデータを扱っています。私はある時点でそのデータにアクセスする必要があり、あなたは別の時点でアクセスする必要がありますが、いつアクセスできるかを定めるルールが必要です。 ここでは少し異なる目的で、Amazon DynamoDBを使用して説明したいと思います。これを使用して、ポリシーストアと呼ばれるものをマッピングします。これらのポリシーストアは、AWS Verified Permissions（略してAVP）と呼ばれるツールに存在します。
AVPではポリシーストアを持つことができ、ここで私が使用している方法は、テナントごとに1つのポリシーストアを設定するというものです。つまり、各テナントが独自のポリシーストアを持ち、その中にCedarと呼ばれるカスタム言語が含まれます。Cedarは非常にシンプルなルールを定義します。このコンテキストでは、特定のテナント（すでにテナントコンテキスト内にいるため）が、期待される主体タイプと一致する場合に特定のドキュメントを取得できるというものです。これはCedarの非常にシンプルな例です。もちろん、もっと複雑にすることもできますが、これにより純粋なテナント分離以外の分離パターンを作成できます。テナント固有のデータを保護するテナント分離は維持したいものの、これらのきれいなルールに当てはまらない他のタイプのデータがある場合、AVPを使用してテナントが必要とするデータへのマッピングルールを定義できます。
Federated Identityは、あまり深く説明できない別のコンセプトですが、エンタープライズ顧客に販売する場合には理解しておく必要があります。非常に高いレベルで説明すると、複数のテナントを持つシンプルなSaaSアプリケーションがあり、User Poolsを使用していますが、ここで新しい変数が導入されます。テナントが私たちのところにやってきて、テナント1はDescopeを彼らのIdentity Providerとして使用したいと言います。彼らはすでに何千ものユーザーを持っており、それらすべてのユーザーを私たちのIdentity Poolで作成したくない - 彼らのものに接続してほしいと言います。幸いなことに、テナント2もOktaを使用したいかもしれませんし、接続したい様々なIdentity Providerがあるかもしれません。Amazon CognitoやOIDCなど、私たちが主要なIdentity Providerとして使用するこれらのツールは、これらの他のデータストアとフェデレーションすることができます。
OIDCを使用してDescopeに接続し、ユーザーは単にDescopeログインを行うだけで、DescopeはAmazon Cognitoと会話を行います。Cognitoは、これがネイティブのCognitoユーザーであった場合と同じタイプのJWTトークンを発行します。Oktaやその他の認証フローでも同じことが言えますが、今回はSAMLを使用するかもしれません。これは、これら2つの異なるアイデンティティストアが互いに通信できるようにする別のオープンスタンダードです。私が考える今後の方向性と興味深いイノベーションについて、フリクションレスオンボーディングという概念を紹介したいと思います。オンボーディングについて考えるとき、テナントができるだけ早くアプリケーションの価値を実感できるようにしたいと考えています。
私が遭遇した障壁の1つは、サインアップ時のフェデレーションです。通常起こることは、ソフトウェアにサインアップして、SAML IDPを使用することを示します。SAML IDPに行ってファイルを取得し、手動セットアップのために渡す必要があります。その間、評価したいソフトウェアから何の価値も得られないまま1週間が過ぎ、他のソリューションの評価に移っているかもしれません。
このプロセスをスムーズにして、テナント管理者が自身で対応できるようにする方法を考える必要があります。ここでDescopeの事例を取り上げたいと思います。というのも、彼らが実装した機能が素晴らしいからです。オンボーディングプロセスの中でIdentity Providerを選択できる機能を提供しているのです。テナント管理者は単にソフトウェアにサインアップし、ユーザーを追加する必要が出てきた時に、アプリケーションのUI上でIdentity Providerを選択してフェデレーションを設定できます。SAMLファイルをアップロードするだけで、SaaS管理者の介入なしにユーザーがアプリケーションを使い始めることができます。この機能を提供しているのはDescopeだけではありませんが、私が使い慣れているのがDescopeで、その完成度は非常に高いと感じています。特に印象的なのは、Descopeが個々のテナントごとに異なるIdentityフローを扱える点です。
Observabilityの重要性とOpenTelemetryの活用
次に、Observabilityについて見ていきましょう。このマイクロスコープの参照が示唆するように、アプリケーションから発信される様々なテレメトリーデータによって、異なるユーザーロールがアプリケーションを観察・運用できるようになります。SaaSプロバイダーと話をすると、よく「Observabilityの対策はできています」と言われますが、詳しく聞いてみるとSREの対策しかできていないことが多いのです。Amazon EKSのCPU使用率やEC2インスタンスの健全性は監視できているものの、ビジネスメトリクスや異なるロールがアプリケーションの運用状態を確認する方法については「まだ開発中です」という回答がほとんどです。Observabilityが実際には何を意味するのか、そして柔軟で堅牢なObservability戦略を構築するためのプラクティスについて見ていきましょう。
まず、なぜObservabilityが重要なのか、そしてこのデータを発信する際に考慮すべき異なるロールについて考えてみましょう。コスト管理はその一つです。コストデータを発信するFinOpsの観点は、SaaSの成功に不可欠です。財務チームがテナント関連の支出データを可視化し、テナントや特定の機能の運用における単位経済性を理解できなければ、継続的な投資やターゲット顧客セグメントについて、どうやって適切な判断を下せるでしょうか？トラブルシューティングは依然としてSREの領域です。アプリケーションの健全性を監視し、任意の時点での状態を理解する必要があります。これらの側面は重要ですが、プロダクト開発も同様に重要な要素です。日々の運用管理は行わないものの、アプリケーションの戦略的な進化を計画するビジネスユーザー向けにメトリクスを発信する必要があります。
プロダクトオーナーは、どの機能が特定のテナント層を引き付けているのか、なぜそのアプリケーションを購入しているのかを理解する必要があります。使用パターンに基づいて新機能の優先順位付けやソフトウェア開発投資の方向性を決定するための洞察が必要です。セキュリティとコンプライアンスの観点では、監査担当者やセキュリティチーム向けに、インスタンスの状態やパッチレベルに関するデータを発信する必要があります。パフォーマンス監視に関しては、問題を予測し、特定のテナントの体験を確認する機能を含めて、ユーザー体験を理解する必要があります。最終的には、アプリケーションが必要なメンテナンス措置を事前に特定したり、問題が顕在化する前にSREに警告を出したりできる予測的メンテナンス機能を目指しています。
SaaSにおけるObservabilityの基本は、テナントのコンテキストを含めたアクティビティの可視化です。アプリケーションから発信されるログ、トレース、アプリケーションの使用状況を示すイベントなど、すべてのデータにテナントのコンテキストを適切に含めなければ、テナント固有の問題を調査することはできません。アプリケーションからの全ての出力にテナントのコンテキストを含めることで、このような種類のダッシュボードを作成し、異なるロールに必要な運用体験を提供することができます。これらの異なるロールはテナントのコンテキストを確認でき、Thin Opsのストーリーを構築したい場合には、特定のテナント、特定のテナント層、特定の地域のテナントの正確な状態をThin Opsユーザーに簡単に伝えることができます。
テナントのコンテキストと適切な運用コンテキスト、そして優れたObservabilityの仕組みがあれば、異なる単位で測定したいものは何であれ、それらを様々な単位で分解することができます。
より良い方法でこれを構築することについて、現在見られていない点について考えてみたいと思います。多くの場合、CloudWatchを使用したり、PrometheusのようなAWSの基本的なスタックを使用したりと、比較的シンプルな運用から始めます。これはしばらくの間は問題ないかもしれません。しかし、私がよく出会うのは、自社のObservabilityスタックが必要な機能をすべて満たしていないことに気づいたSaaSの顧客です。では、その解決策の1つは何でしょうか？ OpenTelemetryはどうでしょうか？ OpenTelemetryの優れている点は、 Amazon EC2やAmazon EKS、Amazon ECS、さらにはAWS Lambdaなど、どのようなスタックでも同じ方法でObservabilityデータを発信できることです。これらすべてが優れたOpenTelemetryのサポートを提供しています。オープンソースのOpenTelemetryを使用することも、AWS Distro for OpenTelemetryを使用することもできます。今回は、すべてのデータをAmazon S3に出力したいので、オープンソース版を使用します。現時点では、トレースをS3に出力するにはオープンソース版が必要だからです。
これは近い将来変更される可能性があると思います。そのため、最初から非常に柔軟なスタックを構築できるかもしれません。例えば、AWS GlueとAmazon Athena 、その上にAmazon QuickSightを載せるだけで、今のところはそれで十分かもしれません。ただし、OpenTelemetryを使用して、すべてのデータをAmazon S3に流し込んでいます。マルチテナント、マルチアカウントのOpenTelemetryに関するブログも公開していますが、そちらの特定のバージョンではオープンソース版ではなく、AWS Distro for OpenTelemetryを使用しています。これについて説明する新しいブログも近日公開予定です。
OpenTelemetryは柔軟性をもたらします。私たちが話してきたこのAWSスタック、つまりAmazon S3、Amazon Managed Service for Prometheus、Amazon CloudWatch、AWS X-Ray、AWS Distro for OpenTelemetryなどの様々なツールを使用している場合、必要な限りそれらを使用でき、OpenTelemetryを複数のソースに送信できるため、複数のツールを同時に使用することも可能です。しかし、これらのツールのいずれかが要件を満たさなくなった場合は、Datadogのようなパートナー企業のサードパーティソリューションも検討できます。現在の方法と比べて、Datadogのログ管理に優れている点はありますか？ Dynatraceはどうでしょうか？ トレースやその他の機能について、Dynatraceの方が好ましい点はありますか？ Honeycombはアプリケーションのデバッグに優れた方法を提供しています。特定のユースケースでそれを使用できないでしょうか？ New Relicは？ Sumo Logicは？これらのパートナーソリューションの利点は、すべてがAWSとの堅牢なOpenTelemetry統合を既に実現していることです。
これを使用することで、今日構築したテレメトリの仕組みが来年や5年後も必要になるかどうかをそれほど心配する必要がなくなります。代わりに、必要に応じて異なるテレメトリを異なるソースに送信し、特定のユースケースに応じて異なるツールを使用することができます。これがOpenTelemetryの本当に気に入っている点の1つです。今から新規に構築を始める場合で、スタックでOpenTelemetryを使用できるのであれば、将来的に大きな恩恵を受けることができると思います。これは、このスタックにそれほど投資せずとも、今日から回避できる落とし穴の1つだと考えています。
SaaSにおける価格設定と課金の課題
私たちが陥りがちなもう一つの落とし穴は、Agileな価格設定の管理方法について考えていないことです。価格設定というと、通常はビジネスの観点から考えます - 製品の価格設定はビジネスチームに任せておけばいいと。しかし問題は、アーキテクチャの観点からそれをサポートできる必要があるということです。例えば、ビジネスチームがAPIの呼び出し回数に応じて課金すると言ってきても、そもそもAPIの呼び出し回数をカウントしていなければ意味がありません。私が最近よく目にする事例の一つで、今年も何度か遭遇しているのですが、製品を販売しているにもかかわらず、実際のアプリケーションの使用量を計測していないお客様がいます。例えば、このサービスは100回まで呼び出せますと言っているのに実際にはカウントしていなかったり、従量課金制だと言っているのに請求すべき使用量の半分が取りこぼされていたりするのです。これは収益漏洩と呼ばれるもので、純粋な成長だけでなく持続可能な成長を意識するようになった今の市場では、特に重要な問題となっています。
それでは、これを実践とツールの観点から見ていきましょう。まずは簡単な例から始めましょう。SaaSを始めた時の課金は比較的シンプルです。SaaSソリューションから課金イベントを発行するか、手動で課金イベントを作成して、Stripeのような優れた課金プロバイダーに送信します。イベントは次のようなシンプルなもので、テナントと使用量を記述します。これらを手作業で入力する場合もあれば、アプリケーションから自動的に発行できる場合もありますが、これも悪くない出発点です。
このアプローチでお客様への請求や請求書の作成はできますが、このようなソリューションでは、耐障害性と柔軟性に関して対処すべき本質的な問題がいくつかあります。
これらの課題に先手を打つため、課金イベントを発行しつつも、Amazon EventBridgeやその他の柔軟なキューベースのシステムに送信するソリューションについて考えてみましょう。これにより耐障害性が確保され、途中で発生する障害にも対応でき、課金サービスへの確実な配信が保証されます。これは、Amazon DynamoDBに書き込むシンプルなAWS Lambda関数かもしれません。そこで発行したデータに対して計算を実行し、現在の状態と発行した内容を正確に捕捉することができます。
ここで言う柔軟性は、課金プロバイダーにも関係します。Stripeは引き続き好ましいプロバイダーで、特定のお客様向けにはそこにデータを送信したいと考えていますが、考慮すべき異なるユースケースもあるかもしれません。例えば、Amber Flowのようなツールを使えば、価格設定を実験することができます。既存のお客様向けにはStripeを使いながら、新しい層のお客様向けに異なる価格設定を試すことができます。Amber Flowを使えば、最終的にすべてのデータはStripeに送られながらも、価格設定を調整したり、異なる料金プランを試したりすることができ、柔軟性が得られます。
異なる2つのBillingプロバイダーがある場合、エンタープライズ顧客向けのAWS Marketplaceについてはどうでしょうか？最終的に、一部の顧客はAWS Marketplaceを通じて請求されることを求めてくるでしょう。Marketplaceを通じた一元的な支払いインターフェースを好むだけでなく、AWSは実際に、顧客自身のEDPコミットメントを消化する形でインセンティブを提供しています。SaaS製品を販売している場合、これは必ず学ぶことになり、いずれはAWS Marketplaceとの統合が必要になるでしょう。私たちには、このテレメトリーを収集して複数の送信先に送ることができる柔軟なシステムが必要です。Stripeとの統合方法を説明する、これに似たサードパーティシステムへのBillingテレメトリーの送信に関するブログがあります。
収益の漏れを追跡し防止することは、先ほど言及したデータに関連します。このデータはAmazon DynamoDBに保存しますが、生データだけを保存するわけではありません。計算も実行し、テナントが使用したさまざまな利用状況から得られるはずの収益の正確な状態を把握します。これは、エンタイトルメントのモニタリングを意味する場合があります。というのも、テナントが特定の量のアプリケーション使用を許可されているケースが出てくるからです。例えば、テナント1はOrder Serviceを10回、Product Serviceを100回呼び出すことができるはずですが、ご覧の通り、すでにProduct Serviceを105回呼び出してエンタイトルメントを超過しています。
特定のBillingプロバイダーの文脈でこれを見てみましょう。AWS Marketplaceを使用している場合、各テナントのエンタイトルメントを設定できる契約があります。これは、テナントが特定の使用回数を許可される従来の文脈ですが、私は制限に達したらすぐにテナントがアプリケーションの使用を停止するようなことは望みません。それを監視し、理解した上で、開始すべきプロセスについてビジネス上の判断を下したいと考えています。エンタイトルメントを超過した時に顧客に通知すべきでしょうか？製品のティアを上げることについてカスタマーサービスに相談するよう促すべきでしょうか？これらは、この状況に対処する異なる方法です。制限を超えたからといって、Billingプロバイダーがテレメトリーの収集を停止することは避けたいところです。
もちろん、従量課金制も導入します。特にAI機能の導入により、従量課金制がますます一般的になっていることは誰もが理解しています。エンタイトルメントと並行して従量課金制を導入することもあり、一部のテナントは両方を持つことになるかもしれません。テナント2がこれら2つの異なるテーブルにまたがっているのがわかります。AWS Marketplaceには、Contracts Plus Consumptionと呼ばれる別タイプのSaaS製品があり、これによってエンタイトルメントと従量課金の両方を実装できます。テナントにProduct Serviceの100回の呼び出しエンタイトルメントを与え、それを超えた呼び出しごとに1ドルを課金するといった形で、これらの概念を組み合わせることができます。
テナント2は制限なしで製品の使用を継続しています - これは純粋な従量課金制です。テナント3は従量課金制のみを採用しており、AWS MarketplaceではSubscription Type Listingと呼ばれることもあります。AWS MarketplaceでDatadogやSnowflakeのような製品でよく見かけるのがこのタイプです。完全な従量課金制で、アクションを実行するたびにSnowflakeユニットを使用し、Snowflakeが監視している内容が全てSnowflakeユニットとしてカウントされます。AWS Marketplaceはこのモデルもサポートしており、私たちが構築したControl PlaneとAWSを統合する方法についてのブログもあります。
無料トライアルとプライシングのラストマイル
昨年お話しできなかったことの中で、少し心残りだったのが、価格設定に無料体験を組み込むことについてもっと詳しく説明すべきだったということです。 これは具体的にどういうことかというと、例えばStandardティアがあって、いくつかの機能がオンになっており、いくつかがオフになっているという状態で、標準的なアーキテクチャがあるとします。 例えば、これはサイロ型のアーキテクチャで、各ユーザーが独自のECSクラスター、独自のデータベース、独自のAmazon OpenSearchインスタンスを持つような構成です。
では、無料トライアルの観点からこれを考えてみましょう。ユーザーに製品を試してもらい、購入を促すためには、どのような点を考慮すべきでしょうか？ まず、オンオフする特定の機能によって、Standardティアとより高度で高価なティアの製品との間で選択を促せるでしょうか？また、これらの機能を制限付きで試せるようにできるでしょうか？例えば、StandardティアではアクセスできないFeature 2について、非常に優れた生成AIの機能を月に1、2回程度、試用できるようにして、StandardティアとAdvancedティアのどちらを購入するか判断材料を提供するといった具合です。
私にとってより興味深いのは、アーキテクチャの部分です。無料ティアではより費用対効果の高いインフラのバージョンをサポートする必要があります。本番環境と同じような完全なスタックを無料ティアで実行していたら、コストが法外に高くなってしまいます。どのような選択肢があるでしょうか？ まず、分離レベルについて選択できます。完全に独立したAmazon EKSインスタンスの代わりに、Namespace分離を採用するのはどうでしょうか？あるいは、同じサービスを共有するランタイム分離はどうでしょうか？ SLAの見直しについてはどうでしょう？保証された実行時間を提示する代わりに、Neon DBが無料ティアで行っているようなアプローチを取ることができます。Neon DBでは、無料ティアでは少し遅くなる可能性があり、データベースの起動に1分ほどかかる可能性があると説明しています。これは、瞬時に起動する本番環境での体験とは全く異なります。
データの耐久性を下げることも検討してください。無料ティアのデータをバックアップする必要があるでしょうか？このデータは本番データに変換する予定のあるものなのか、それとも破棄してもよいデータなのでしょうか？複数のアベイラビリティーゾーンに配置する必要はありません。テナントごとにインスタンスを用意する代わりに、行レベルのセキュリティを採用するなど、コストを下げる判断ができます。Amazon DynamoDBで行ったように、すべてのデータを同じテーブルに共有して保存することもできますし、Amazon OpenSearch Serviceでもテナントごとにインデックスを作成することができます。 これらはすべて選択肢であり、アーキテクチャによっては、テナントが購入を決断するのに十分な品質を維持しながら、無料ティアの体験のコストを削減するためのさまざまな手段があり得ます。
ここでもう一つ、「プライシングのラストマイル」という概念があります。私はSchematicというチームと仕事をしていますが、彼らは機能フラグや価格設定のどちらかに特化した他のチームとは異なり、これら2つの概念を組み合わせています。彼らのアプリケーション内で機能を管理できるようにしていますが、Launch DarklyやAWS AppConfigなどの純粋な機能フラグ主導のツールとは異なり、テナントがこれらの機能を使用できるようにし、その使用状況を価格設定に反映させています。つまり、価格モデルは完全に、顧客がこれらの機能フラグにヒットした回数によって決定されるのです。
アプリケーションの使用状況を料金プランと連携させる便利な方法です。これらの料金プランはSchematicで作成できるため、アプリケーション内に料金に関する知識を持つ必要がありません。すべてはダウンストリームで処理されます。これにより、ビジネスユーザーは別のツールで料金を管理でき、開発者はその仕組みについて考える必要すらありません。この2つの概念を完全に切り離すことができるのです。もちろん、StripeなどのBillingプロバイダーとの連携も行い、顧客への請求書も提供します。
SaaSにおけるテストの重要性とカオスエンジニアリング
私の講演全体を通じて「失敗しないことの失敗」というテーマがあります。昨年は各セクションの最後にテストについて触れ、ほとんど同じスライドを使用しました。今回も説明しますが、十分な深さまで掘り下げられたかどうかはわかりません。私のところには今でも、基本的な総合テストや本番環境に移行する直前に実行する統合テストといった単体テストを行うSaaS顧客が多く来ています。しかし、ソフトウェア全般、特に問題の影響範囲が非常に大きくなる可能性のあるSaaSプロバイダーにおいて、文化としてのテストがまだ十分に浸透していないと感じています。
では、昨年話し合ったことは何だったでしょうか？ポリシーの仕組みや、人工的なTenantを作成してアプリケーションの限界を試すことで、この人工Tenantがアプリケーションのエッジに負荷をかけてもNoisy Neighbor問題が発生しないことをテストする方法について話しました。Amazon API GatewayのURLが実際に公開されているかどうか、誰かがアプリケーションのエッジの背後に回り込んでそのAPI Gatewayを攻撃し、トランザクション毎秒の制限を超過させて、他のすべてのTenantにNoisy Neighbor問題を引き起こす可能性がないかテストできるでしょうか？さらにその背後まで回り込んで、AWS Lambda自体を見つけ出し、作成した偽のペイロードや他のTenantから傍受したペイロードを使ってシステムに送り込むことができないでしょうか？
私のデータが外部に漏れる可能性はないでしょうか？データが確実にロックダウンされ、外部からのアクセスが一切ないことを確認する必要があります。これらすべてのことを、顧客に提供するSLAを含むすべてのリリースにわたって継続的にテストしたいと考えています。
例えば、異なるインフラストラクチャを持つ異なる種類のTierがあるとします。これらのインフラのSLAは、Enterpriseの顧客に約束している専用インフラのSLAとは大きく異なる可能性があります。あるTierでは1秒で応答する必要があるかもしれませんが、完全な共有環境では3秒かかるかもしれません。私たちは、リリースするたびにこれらのSLAに影響を与えていないことをどのようにテストしているでしょうか？日中に起こりうる極端な負荷状況を再現する異なる負荷プロファイルを作成していますか？1つのスパイクの多いTenantがいた場合はどうなるでしょうか？それが5つや10つのスパイクの多いTenantに広がり、同時にアプリケーションにアクセスした場合はどうなるでしょうか？SLAは引き続き満たされるでしょうか？満たされない場合のペナルティは何でしょうか？そのペナルティを支払う用意はありますか？アプリケーションに対して適切に設定されているでしょうか？
私たちは個々のワークロードの部分をテストできるでしょうか？実際に非同期ワークロードを検証して、同期ワークロードが非同期ワークロードにかかる負荷の影響を受けないことを証明できるでしょうか？これは私が最も考えてきた分野の1つです。昨年お話ししたように、機能のオン・オフを切り替えて、すべての機能がオフになっても、アプリケーションが機能し続けることを証明する方法について議論しました。これは今でも良い方法だと思いますが、次のスライドで説明するように、実際には証明できないことがあります。既存の製品機能をテストに使い続け、Blue-Greenデプロイメントをテストに活用し続けてください。これは素晴らしいパターンです。もしまだロールアウトやウェーブベースのデプロイメントを実施していないのであれば、システムの回復力を向上させるための優れたパターンとなります。
同じフラグを使って、パッケージングや価格設定で実験することもできるかもしれません。新しい製品層をダークローンチして、既存のアプリケーションに大きな混乱を引き起こすことなく、舞台裏でイノベーションと実験を続けることができます。しかし、今年私が多く考えてきたのはカオスについてです。どうすれば確実に信頼性を確保できるのでしょうか？私が話し始めた興味深いツールがあり、これはいくつかの異なる側面で優れた適合性を持っています。
まず、テストのシナリオを設定してみましょう。シンプルなアプリケーション、いや、そこまでシンプルではないかもしれませんが、テナントの認証のためのLambda認証機能を備えたAmazon API Gatewayがあります。そして、Amazon DynamoDBを呼び出し、サードパーティのサービスを呼び出す他のビジネスロジックがLambdaに含まれています。これらの部分のいずれかが失敗した場合、どうなるでしょうか？ここで、以前私が主張していたフィーチャーフラグの議論が崩れてしまいます。なぜなら、そのフィーチャーフラグはおそらくアプリケーションの多くの異なる部分をカバーしているからです。
そこで、カオスエンジニアリングツールでSaaSソリューションを提供するGremlinというツールを調査し始めました。Gremlinでは、実際に実験を設定することができ、それらの実験の中にFailure Flagsと呼ばれる概念があります。これはテストの方法と障害の導入方法について考える上で、素晴らしいイノベーションだと思います。これらのFailure Flagsを使用して、アプリケーションの特定の部分を攻撃することができるからです。彼らが構築したLambda拡張機能は、SDKを通じて接続され、アプリケーションがこれらの各Failure Flagsの状態を監視します。
もちろん、ここでは示していない制御コードが必要です。DynamoDBを呼び出さないようにするための最もシンプルなステートメントでも、この障害状態を設定するには十分かもしれませんが、Amazon Cognitoが利用できない場合や、特定のテナントが認証できない場合など、さまざまなシナリオをテストできます。ここで気に入っているのは、コンテキストを渡して異なるテナントシナリオを攻撃できることです。最大のテナントをダウンさせた場合はどうなるのか？その体験はどのようなものか？ローンチ直後により多くの負荷をかけた場合はどうなるのか？Lambdaにアクセスできない場合はどうなるのか？これは実際にはテストがほぼ不可能です。なぜなら、実際にLambdaをダウンさせることはできないからです。
このように、ビジネス機能がダウンしたと仮定してテストを行う障害関数を用意することで、アプリケーションがどのように応答するのか、完全にダウンしてしまうのか、それともこれらの障害状態に対して適切に対応できるのか、データベースが利用できない場合はどうなるのか、サードパーティのサービスが利用できない場合はどうなるのか、を確認できます。先ほど話題に出た課金のシナリオについても、本当に非同期になっているのか、すべての課金イベントが正しくバックアップされ、課金プロバイダーに送信されているのか、といったことを確認する必要があります。アプリケーションのあらゆる部分にChaosを導入してみましょう。
Gremlinについて私が特に気に入っているのは、このようなツールを提供しているだけでなく（確かに、同様のツールは自分たちでも作れるでしょう）、彼らが毎週自社のSaaSシステムにGremlinを使って攻撃を仕掛けているという点です。完璧なDog-foodingの事例ですね。実際に、この取り組みによって最大手の顧客のシステムをダウンさせたこともあり、毎週CTOを含めたミーティングを開いて、自社のアプリケーションへの攻撃から学んだことや、今後の改善点について話し合っています。これは非常に優れたツールであり、また自社製品を使って製品をテストするという素晴らしい事例でもあります。
AIの登場によるSaaSデプロイメントの変化とセキュリティ対策
これは今年に特に関連する話題です。
より複雑なデプロイメントを想定していなかったというのが問題です。私がチームに加わって以来、顧客のアカウントへのデプロイメントについて話し続けてきました。最初に関わった顧客の一つであるDr Oは、自社のインフラの一部を顧客のアカウントにデプロイしているということを公に話しています。私たちは彼らと協力してきましたし、それは彼らにとって重要な戦略でしたが、当時はどちらかというと特異なケースでした。多くのSaaS顧客は、依然としてSalesforceモデル、つまりすべてのインフラを自社のアカウント内に置くというモデルに従っていました。
何が変わったのでしょうか？AIの登場により変化が起きています。なぜなら、AIには顧客データへのアクセスが必要だからです。これにより、ますます多くのSaaSプロバイダーがインフラをエッジに向けて展開するようになっています。これは何を意味し、どのように対処すべきなのでしょうか？これは重要な問題です。なぜなら、最大手の顧客から「あなたのアプリケーションは気に入っているし使いたいけれど、私たちのアカウントに置かないなら使用しない」と言われた場合、その顧客を諦めるのでしょうか？「ありがとうございます。でも、その1000万ドルの支払いは結構です」と言うのでしょうか？いいえ、おそらく何らかの形でサポートせざるを得ないでしょう。
このセキュリティ対策について、エッジに向かって進んでいますが、そのエッジへの移行にはさまざまな段階があるので、使用可能なモデルについて考えてみましょう。まずは従来型の保護モデルから始めましょう。これはとてもシンプルで、カスタマー管理キーを使用します。例えば、Amazon S3バケットがあるとします。顧客がデータを私たちに渡し、私たちはそのキーでデータを復号化します。顧客が私たちのアプリケーションの使用を終了したい場合、そのキーを無効にすれば、彼らのデータは私たちにとって使用不可能になります。このモデルはある程度機能し、顧客に安心感を与えることができます。しかし、すでに復号化されたデータがCloudWatchや他のデータベースのどこかに存在している場合はどうでしょうか？つまり、これですべての問題が解決するわけではありません。
他にもさまざまな解決策があります。その1つがAWS Nitro Enclavesです。これはかなり複雑なソリューションです。別のスライドで説明しますが、Nitro Enclavesは特定のコンテキスト内でデータを保護・セキュア化し、そのコンテキスト内でのみデータを復号化することができます。データプライバシーボールトを使用することもできます。Skyflowというデータプライバシーボールトを使用して、データを非識別化し、顧客が個人情報を共有せずにデータを共有できる方法の例を説明します。
もちろん、リモートエージェントを使用することもできます。これは長年一般的な方法で、Dr Oの仕組みに似ています。彼らはアプリケーションの一部をデプロイし、データを収集し、Dr Oがビジネスインテリジェンスツールとして必要とする関連データのみを送信します。顧客のアカウントに完全なリモート機械学習環境をデプロイし、ビジネスインテリジェンスや派生データ、つまり個人情報を含まない機密性のないデータのみを私たちのアプリケーションにエクスポートすることもできます。
あるいは、AIアプリケーション全体を顧客のアカウントにデプロイして、「はい、これで完了です」と言うこともできます。コントロールプレーンは維持し、可観測性も所有しますが、運用は顧客側で管理する必要があります。ソフトウェアの運用負担を顧客側に移すことは理想的ではないかもしれませんが、実際に今、SaaSプロバイダーと話をする中で、このモデルを強いられているケースもあります。
これはオープンソースに関する興味深い議論です。エンタープライズ企業がオープンソースのソフトウェアにより安心感を持つケースが増えているのを目にしています。このスライディングスケールに関する議論は、実際にコードをどのようにデプロイするか、そしてそれがオープンソースかどうかによって影響を受ける可能性があります。これはすべてのSaaSプロバイダーにとって選択肢となるわけではありませんが、考慮に入れておく価値はあります。このスケールを検討する際、オープンソースの場合はどうなるでしょうか？顧客のアカウントで実行されるコードがオープンソースである場合、エンタープライズ顧客はそのコードをより信頼するでしょうか、それとも信頼度は下がるでしょうか？
さて、Data Privacy Vaultについてお話ししようと申し上げましたが、これは比較的シンプルなコンセプトです。私たちにはSaaSアプリケーションがあり、SaaSテナントがそのアプリケーションを直接利用します。 もちろん、テナントのデータは彼ら自身のアカウントに存在します。ここではDPCと略して表現していますが、これは彼らが所有するアカウントのことです。S3バケットやデータベースなどを持っています。 Data Privacy Vaultを使用することで、これらのVaultをテナントが所有するリソースにデプロイすることができます。データはData Privacy Vaultを通過する際に匿名化が解除され、個人情報が抽出されます。例えば、「Bill Tar」という名前が「XYZ123」に置き換えられ、一貫性を持って置換されるため、XYZ123が一人の人物を示していることは分かりますが、それがBill Tarという名前の人物であることは分かりません。
このようなツールでは、再識別機能を導入することも可能で、この再識別機能によってロールベースの制御が可能になります。例えば、医療機関の管理者が「患者データが必要だ」と言った場合、このツールを通じてデータを再識別することができます。一方、コールセンターのスタッフなどは、居住する州や住所の一部しか見ることができないといった具合です。Skyflowはこの良い例です。 この仕組みの難しい部分は、暗号化とロールベースのアクセス制御の両方です。現在、Skyflowが取り組んでいる興味深い取り組みの一つは、Generative AIを使用してこれらのモデルを学習させ、プライベートデータを理解させることです。彼らはすべてのデータを分析し、プライベートデータと思われるものを提示します。
これにより、保護したいデータを選択することができます。差別化されていない重労働の一部を取り除くことができるのです。このモデルの欠点は、個人情報を特定してそれらをすべて取り除く必要があることと、人間が関与するプロセスであるため、ミスが発生する可能性があることです。私たちはSkyflowに関するブログをいくつか持っており、その例の1つがここにあります。
もう一つのアプローチとして、機械学習のワークロードをお客様のアカウントにプッシュダウンする方法があります。これは、昨年のブレイクアウトセッションでも話題に上がった、これまでお話ししてきたSaaSモデルにより近いものです。私たちのSaaSアプリケーションは今日とほぼ同じような形になりますが、Amazon SageMaker、AWS Glue、機械学習をお客様のアカウントにプッシュダウンします。そこでデータにアクセスし、必要な処理を実行し、ビジネスインテリジェンスを抽出します。このBIを私たちのSaaSアカウントに戻し、テナントユーザーがそこにアクセスするという形になります。これは私たちが行っていることと似ていますが、機械学習の側面が非常に興味深いところです。テナントのデータがアカウントから出ることができないけれども、機械学習で処理する必要がある場合、これは有効なモデルかもしれません。
ただし、これにはまだ多くの運用上のオーバーヘッドが伴います。すべてを遠隔で管理するか、テナント自身がこのスタック全体を管理する必要があります。そして当然、これを多くのテナントに対して繰り返す必要があります。結果として、ここで行うことすべてがサイロモデルに制限されてしまいます。 AWS Nitro Enclavesは、おそらくこの話題の中で最も新しい部分であり、すべてのシナリオに対する完璧なソリューションではないかもしれませんが、興味深い選択肢です。 Nitro Enclavesの良い点は、アカウントに流入するデータが非常に限られた範囲でのみ見ることができるという保証を提供することです。
Nitro Enclavesの仕組みについて説明しますと、まず Amazon EC2インスタンスを作成し、そのEC2の一部をAWSに返却する形になります。AWSがこの部分を管理するのですが、これはアクセスできないDockerコンテナのようなものです。このEnclaveには、内外の通信を可能にする単一のvsockパイプが設置されています。 このフローの一部としてEnclaveを作成し、署名を生成します。これはTLSに似ていて、このマシン固有の署名を生成し、それをお客様と共有します。これがAWS KMSで暗号化する際に使用するキーになると伝えます。これがKMSが使用する署名の一部となります。
これにより、Amazon S3バケット内でAWS KMSを使って署名したものは、作成したこのNitro Enclaveでのみ復号化が可能になります。エンベロープベースの暗号化を返しますが、暗号化の詳細を全て理解する必要はありません。データを暗号化する際にキーを作成したということだけ覚えておいてください。暗号化されたデータを持っていて、それら両方をNitro Enclaveに渡すと、Attestation Documentを交換します。これは自身が何者であるかを示すもので、「私はこのエンティティです」と主張し、AWS KMSとの間でやり取りを行います。KMSは「あなたが誰かわかっているので、このデータの復号化を許可します」というような処理を行います。このデータを復号化できるのは、Nitro Enclave自身だけです。
これは興味深いパターンですが、いくつかの潜在的な課題もあります。その一つは、Nitro Enclaveからデータを外部に送信できてしまうことです - このvsockは開いていて、データを送信することができます。そのため、そこで実行されるコードについて、お客様との間で合意が必要です。通常はこのように進めます - Nitro Enclave内で実行するコードを提示し、機密情報を外部に送信しないことについて同意を得ます。もう一つの考慮点は、これが単なるEC2インスタンスであるということで、アプリケーション全体としてどこまで拡張できるかに制限があります。大規模なフットプリントを単一のEC2内に収めたくない場合もあるでしょう。とはいえ、これは非常に興味深いモデルで、お客様のデータがどこでどのように読み取られるかということだけが懸念事項である場合、この方式によって懸念を払拭し、反対意見を解消できるかもしれません。
まとめと今後のSaaSセッションの案内
これらのモデル全てに共通して私が強調したいのは、可観測性を維持することです。以前のパッケージソフトウェアのように「うまく動くことを祈って」放置するのではなく、このソフトウェアの運用データや動作状況を確実に把握してください。これはAmazon CloudWatchを使用して全てのCloudWatchデータを集約し、中央のダッシュボードに表示する方法などが考えられます。
さて、時間が迫ってきましたが、明日いくつかのセッションがあることをお伝えしたいと思います。水曜日なので多くはありませんが、Todd GoldingによるSaaS Builder Toolkitのブレイクアウトセッションは素晴らしい内容です。可能であれば是非参加してください。白色で表示されている他のトークのほとんどは既に終了していますが、ブレイクアウトセッションは既にYouTubeで公開されています。今朝、今週初めのものから2つのセッションを既にYouTubeで見ました。また、明日はワークショップとビルダーセッションの再演も予定されています。機会があれば、ぜひチェックしてみてください。
最後に、ありがとうございました。アンケートへのご記入をお願いします。これは非常に重要で、re:Inventでどのようなトピックを取り上げるかを決める際の参考にさせていただきます。もしよろしければ、私に関する良い評価を、あるいは少なくともSaaSについて、そしてもっとSaaSのトピックを聞きたいということをお書きいただければ大変ありがたく存じます。そうすれば、来年もまたここでSaaSについて取り上げることができるでしょう。皆様、ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion