re:Invent 2023: AWSが解説するSaaSのマルチテナントアーキテクチャ設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - SaaS deep dive: Inside a scalable, efficient multi-tenant architecture (SAS304)
この動画では、AWSのSenior Principal Solutions ArchitectであるTod Goldingが、SaaSアプリケーションのスケールとレジリエンスについて深掘りします。マルチテナント環境特有の課題や、効率性とスケーラビリティのバランス、異なるデプロイメントモデルの活用方法など、従来のアプローチを超えた視点を提供します。API Gateway、Lambda、EKSなどの具体的な実装例を交えながら、SaaSアーキテクトが考慮すべき新たな層について解説します。スケールとレジリエンスの検証方法まで踏み込んだ、包括的な内容となっています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
SaaSとマルチテナンシーの基本概念：Tod Goldingの自己紹介
本日のセッションにご参加いただき、ありがとうございます。re:Inventを楽しんでいただけていることを願っています。今日はSaaSとマルチテナンシーについて少し掘り下げていきたいと思います。スライドにもありますように、私はTod Goldingと申します。AWSのSenior Principal Solutions Architectで、過去8年間、さまざまな分野のSaaSプロバイダーと協力して、幅広い問題に取り組んできました。また、SaaS factoryチームの一員として、AWSでのSaaSの構築と提供に関する多くのリファレンスコンテンツとガイダンスを開発してきました。
これまでの取り組みの大きな部分は、具体的な例を提供することに焦点を当ててきました。多くの人から常に聞かれたのは、原則について説明するだけでなく、実際にどう構築するかを示してほしいということでした。そこで数年前から、EKS SaaSソリューションやサーバーレスSaaSソリューションの構築方法に焦点を当てた講演を始めました。コード例やトークンベンディングマシンなどを提供しました。これらは、SaaSの具体的なエンドツーエンドの例として、素晴らしいスタートを切るのに役立ちました。
しかし、今年のre:Inventに向けて準備する中で、基本的なソリューションを動作させる以上に、どのようなトピックが価値があるかを考えました。使用する技術に関係なく、本当に優れた、スケーラブルなマルチテナントSaaSソリューションを構築するとはどういうことか、探求したいと思いました。レジリエントなSaaS環境を構築する良い方法とは何か。それが今回の講演の動機であり、精神です。特定のソリューションを示すのではなく、AWSの上に素晴らしく、スケーラブルで効率的なSaaSソリューションを構築することの基本的な要素について、メンタルモデルやフレームワークを提供したいと思います。
これは非常に広範なトピックだと思います。今回はそのすべての細かい点には触れません。しかし、今日の講演では、もし私が今顧客と一緒に座って、スケールとレジリエンスについて話をするとしたら、どの部分に焦点を当てるかという大きな要素を抽出しようと試みました。また、この講演の前半はスケールとレジリエンスについてですが、後半の3分の1は、これらが実際にどのように機能しているかを証明する方法について触れます。これは私たちがこれまであまり話してこなかった分野です。つまり、カオスメカニズムをどのように構築するか、スケールが機能していることやレジリエンスが機能していることを示す検証メカニズムをどのように構築するかということです。
これは300レベルのセッションです。深掘りセッションと言っていますが、深掘りの意味について期待値を設定しておきましょう。アーキテクチャについては確実に触れます。アーキテクチャについては徹底的に説明しますが、大量のコードは示しません。この背後にある全ての動く部分を示すわけではありません。これはむしろアーキテクチャパターンと戦略に関するものです。皆さんがそのために来ていただいたことを願っています。概要で読んだ内容と一致していることを願っています。
SaaSアーキテクチャにおけるスケールとレジリエンスの重要性
まず、外側のレベルから始めたいと思います。SaaSアプリケーションを設計し構築しようとする場合、スケール、可用性、レジリエンスについて話すとき、実は多くの優れた情報が存在します。実際、このトークの補完として、AWS Well-Architectedのガイダンスを絶対に参照すべきだと言えます。そこには、レジリエンス、スケール、可用性に関する素晴らしい指針が提供されており、これらを実現する方法について優れたガイダンスとなっています。そして、これらの要素はSaaS環境でも依然として有効です。
しかし、私が気づいたのは、SaaSアーキテクトにはさらに別のレベルの考慮事項があるということです。マルチテナンシーは、スケールとレジリエンスを達成することの意味に、さまざまな新しいニュアンスを加えます。 ここで問題となるのは、はい、可用性です。誰もが可用性を求めており、システムがダウンすることは決して望みません。しかし、マルチテナント環境で可用性を目標にするとはどういう意味か想像してみてください。そして、高可用性システムを構築することがアーキテクトとしてのあなたの仕事なのです。
従来のシステムでは、可用性がなくなると、システムの特定の側面がダウンしたために1、2の顧客がダウンする可能性がありました。しかし、マルチテナントSaaS環境では、システムがダウンすると、ビジネス全体と全ての顧客をダウンさせる可能性があります。そのため、私にとって、マルチテナントSaaS環境での可用性の基準ははるかに高くなります。実際、大規模なマルチテナントSaaS企業で障害が発生すると、ニュースになります。他のビジネスがそのソリューションを利用できなくなったり、その影響が非常に広範囲に及ぶため、多くの人々が関心を持つからです。
もう一つの点は、私たちSaaSアーキテクトはコスト効率の達成を求められているということです。月曜日にコスト最適化に関する講演を行いましたが、実際、このトピックとも少し重複する部分があります。なぜなら、スケールとレジリエンスはこれらの概念と交差するからです。
SaaSでは規模の経済を達成することを求められています。人々がSaaSを選ぶ大きな理由の一つは、そこから得られる素晴らしい利益率です。ビジネスが成長するにつれて、より多くの利益を生み出します。では、インフラストラクチャにかかる費用を最小限に抑えるための素晴らしい方法を実現しながら、同時に可用性の観点から安全性を確保するためのオーバープロビジョニングやその他の対策をどのように行えばよいのでしょうか？
もう一つの課題は予測可能性です。 ソフトウェアは本質的に予測不可能ですが、マルチテナント環境を想像してみてください。新しいテナントが常に現れ、テナントが去っていき、そしてそれらのテナントのワークロードが一日や一ヶ月を通じて大きく変動する環境です。ここでは、可用性や効率性、その他多くのものを求めていますが、テナントのプロファイルやシステムの使用方法が常に変化している中で、それらすべてを達成し、環境を設計しなければなりません。
もう一つの点は、私たちは通常、一種類のアーキテクチャだけで終わることはないということです。 もし、よく理解された一つのアーキテクチャでスケールと耐障害性を達成するだけなら、少し簡単かもしれません。しかし実際には、SaaS環境は時として複数のデプロイメントモデルをサポートしなければなりません。一部のテナントはサイロ型デプロイメントで、一部はプール型デプロイメントで、そしてソリューションやアーキテクチャのフットプリントが変化します。では、このような経験全体にわたってスケール、耐障害性などを達成するとはどういうことでしょうか？
そして最後に、ビジネス側から私たちに求められているのは、 多くのセグメントに販売したいということです。小規模企業にも大規模企業にも販売したいと考えています。そして、異なる階層の体験を提供したいのです。スロットリングの体験を設けたり、顧客の体験を変更したりすることもあるかもしれません。そして、ちなみに、あなたのアーキテクチャはそのすべてを達成する必要があります。
私にとっては、これは時として大きな綱引きのように感じられます。方程式の一方では、ビジネス側が左側のすべてを求めています。 効率性を求め、必要最小限のインフラストラクチャで、最大のコスト効率を求めています。可能な限りインフラストラクチャを共有し、素晴らしい規模の経済を得たいのです。なぜなら、可能な限り大きな利益率を得たいからです。しかし一方で、他にもサポートしたい様々なバリエーションがあると言っています。複数の市場に参入できるようにしたい、階層化を提供したい、複数のデプロイメントモデルをサポートしたいのです。
これらの要求は必ずしも互いに直接的に矛盾するわけではありませんが、確かに並行してサポートするのは難しいです。これが、皆さんがこれらのシステムを構築しようとする際の課題の一部だと私は感じています。そして正直なところ、これらのシステムを構築する楽しさの一部でもあります。なぜなら、ここで機能するアプローチを考え出すには、かなりの創造性が必要だからです。
マルチテナントSaaSにおけるスケールの多面的な定義
では、スケールについて話しましょう。実際にスケーラブルなマルチテナント環境を構築するとはどういうことでしょうか？マルチテナントならではの考慮すべき点は何でしょうか？この話をするなら、スケールの意味についての視野を広げる必要があると思います。これは少し持論を展開することになりますが、多くの人がスケールを狭い枠に押し込めすぎていると感じるからです。
一般的に、特にインフラ担当者やアーキテクトは、スケールを垂直方向または水平方向にどうスケールするかという観点でとらえがちです。大量のワークロードが発生したら、クラウドの柔軟性や優れた仕組みを利用して、必要に応じて拡張すればいい。少し多めにプロビジョニングしておけば、十分なスケールが得られる。確かにその通りで、スケーラブルなSaaSソリューションを構築する上で有効なアプローチです。
しかし、それだけでは不十分だと私は考えています。その定義に加えるべき要素があります。インフラのスケールは確かに重要ですが、SaaSの世界では、好むと好まざるとに関わらず、SaaSアーキテクトとしてビジネス的な視点も持つ必要があります。SaaSビジネスがどうスケールするかを考えなければなりません。つまり、スケールの定義はインフラだけにとどまらないのです。
オンボーディングについて考えてみましょう。新しいテナントを環境に追加するとはどういうことでしょうか？多くの組織では、オンボーディングを後回しにしがちです。アプリケーションのスケールに集中し、後になって「そうだ、オンボーディングの自動化をしなきゃ」と気づくのです。しかし、オンボーディングもスケールする必要があります。明日100の新しいテナント、あるいは1000の新しいテナントを追加すると言われたとき、あなたのオンボーディングプロセスがそのニーズに対応できるかどうか、多くの企業はそれを考えたこともありません。B2C企業は考えています。なぜなら、急激なスケールに対応できなければ生き残れないからです。しかし、月に10程度のテナントしか獲得しないB2B企業では、これを重要視していないかもしれません。
私は、オンボーディングもこの経験の一部に含めるべきだと提案します。また、運用もこの話の一部だと考えています。運用をスケールさせるには、アーキテクトとして、チームにマルチテナント環境を運用してスケールを実現するためのツールやメカニズム、構造を提供する必要があります。運用面でのデータ、メトリクス、洞察がなければ、アーキテクチャが実際にどのように振る舞っているかを把握できず、効果的にスケールしているかどうかさえわからないかもしれません。
デプロイメントもこの一部です。 機能をどれだけ迅速にロールアウトできるか？フィーチャーフラグをどのようにサポートできるか？これらのSaaS環境の独自のデプロイメントフットプリントをすべてサポートしながら、それを効率的に行うにはどうすればよいか？このボックスにもっと項目を入れることもできますが、私の大きなポイントは、アプリケーションの中核的なインフラストラクチャだけでなく、スケールについて考える際には、新しい顧客を追加するにつれてスケールしなければならないビジネスのあらゆる側面について考えることです。
SaaSのスケーリング戦略：ワークロードとデプロイメントモデルの考慮
スケーリング戦略を考える際に頭に浮かぶことを1枚のスライドで表現するとしたら、ここに見られるような要素の組み合わせになります。左側には、ワークロードがあります。異なるプロファイル、異なるテナントが潜在的にシステムを飽和させ、システムの異なる部分を異なる方法で、常に異なるパターンで消費するような、あらゆる種類のワークロードをサポートしなければなりません。スケールのために何をするにしても、それを理解し、考慮に入れ、計画の一部にしなければなりません。
右側には、これらのワークロードに対処するためのオプションがあります。ここにはかなり長いオプションのリストがあります。確かに、選択するコンピュートスタックは、システムのスケール方法に大きく関係します。EC2を使うのか？Serverlessを使うのか？これらの詳細については後ほど触れます。コンテナを使うのか？そして、これらの特定のコンピュートテクノロジーが、これらの様々なワークロードや他の要件とどのように上手く整合するのか？選択するストレージスタックについても同様です。RDSを使うのか？DynamoDBを使うのか、マネージドかそうでないか？ワークロードの性質やビジネスの目標に応じて、異なる戦略を選択する必要がある様々なバリエーションがあります。
さらに、ドメイン、業界、その他の要件、コンプライアンスなど、環境で一般的なものがアプローチに影響を与えます。これらすべてに重なるのが、ここで見られる中央の部分です。ティアリング戦略や分離が見られます。スケールを考える際に分離を思い浮かべることはないかもしれませんが、実際には分離はスケールと大きく関係しています。なぜなら、リソースのデプロイ方法や選択するアーキテクチャによって、一部のものは他とは異なるスケール方法を持つからです。そして、分離に関して良い妥協点もあれば、そうでないものもあります。
ここにある「ノイジーネイバー」も同様です。どの戦略がノイジーなのか？どれがノイジーネイバーに適しているのか？非常にスパイキーな負荷がある場合、どのコンピュートスタックが適切なのか？私にとって、これはプロセスの最初の段階で、「Tod、何をするつもりですか？どこから始めますか？」と聞かれたときのようなものです。私は、ビジネスと自分自身に、これらのことについて十分に考えてもらい、選択肢の範囲と選択肢について感覚をつかむようにします。初日にすべてを正しく理解できるでしょうか？絶対に正しく理解することはできません。しかし、これを全くせずに、好きなスタックを選び、好きなデータベースを選んでしまうと、結局あまり良い選択をしていない可能性があります。少なくともここでは、プロセスに少しデータが含まれています。
さて、単に「スケール」と言った場合、最もシンプルな見方は何でしょうか？ この1枚のスライドだけでも十分かもしれません。これが、SaaSにおけるスケールの最もシンプルで分かりやすい見方です。つまり、複数のテナントを共有環境に配置するのです。ここで言う「共有プール」とは、インフラが共有されているという意味です。これは共有インフラを表現するために使用する用語です。そして、すべてのリソースがすべてのテナントに対してプールされています。ストレージは共有され、コンピューティングも共有され、これらのテナントはすべてこの環境に投入され、彼らのニーズに合わせて水平方向にスケールするだけです。私たちはこれを1つの大きな集合的なワークロードとして見ています。
おそらく、少し過剰にプロビジョニングしているでしょう。ここでの経験がすべての人にとって十分であると仮定しています。しかし、この環境ではスケーリングポリシーとメカニズムが課題になることは想像できます。なぜなら、これらのマイクロサービスの性質と、それらがどのようにスケールするかに依存するからです。スケーリングポリシーを追求するための少しの作業がここで行われていますが、ほとんどの人は過剰プロビジョニングでこれを克服するでしょう。しかし、これがあなたに必要なすべてで、あなたのSaaS環境がこのように見えると思うなら、利用可能な基本的なスケールツールをすべて使用してください。プールされたリソースの利点を活用すれば、それで完了です。
しかし、実際には私が関わる環境のほとんどはそのようには見えません。環境の一部はそのように見えるかもしれませんが、一般的にはすべてがそのようにはなりません。
複雑なSaaS環境におけるスケーリングの課題
実際、SaaS企業が運用している環境の景観は、多くの人が考えているものとはかなり異なります。それらはパターンの混合体です。ここでは、先ほど示したようなプール環境があります。オーダーと製品という2つのマイクロサービスがあります。1つはLambdaで実行されていますが、もう1つはワークロードの性質上、特定の理由でコンテナで実行されています。
そして、これらのサイロ化されたマイクロサービスがあります。サイロ化とは、個々のテナント専用という意味です。ここでは、アナリティクスサービスがSLAやコンプライアンス、あるいはソリューションの他のニーズに基づいて、別個のスタンドアロンのマイクロサービスとして分離される必要があると言っています。そして、私たちは「フルスタックサイロ」と呼ぶ一連の顧客も持っています。彼らは自分専用のサイロ全体を得ます。さて、これらのテナントとサービスはすべて、ソフトウェアの同じバージョンを実行しています。それらはすべて同じ経験を通じて管理されています。つまり、ここでは一回限りのバージョンなどは存在しませんが、異なるインフラで異なるパターンでデプロイされて実行されています。
誰かが十分に大きな金額を支払う意思があれば、そしてここで多くの企業を見てきましたが、彼らは「フルスタックサイロでなければあなたのシステムを買わない」と言います。あるいは、一部の人々はそれをプレミアム体験として提供したいと考えています。オプションとしてそれを提供するのです。さて、私にとってこれがフットプリントである場合、スケールするとはどういう意味でしょうか？なぜなら、これらすべてがあなたの全環境だからです。これらすべての戦略をサポートしなければならない場合、スケールする方法を考え出す必要があります。そして今、スケールの概念はずっと難しくなります。フルスタックサイロでのスケーリングとは何でしょうか？それはプール環境でのスケーリングとは全く異なるものです。
そこで、この問題に対する小さな公式を作ってみましょう。まずはペルソナから始めます。私なら実際にいくつかのプロファイルを作成します。消費プロファイルは何か？分離プロファイルは何か？階層化プロファイルは何か？などと自問します。そして、ペルソナのミックスと、これらのリソースを消費するさまざまな方法、分離したい方法を考慮します。
次に、利用可能な異なるオプションと並べて考えます。例えば、これらのニーズを満たすために、異なるマイクロサービス分解戦略をどのように使用するか？マイクロサービスの適切な分割方法は何か？マイクロサービスの適切な組み合わせは何か？どれをサイロ化し、どれをプール化して、これらの特定のワークロードのニーズを満たすべきか？つまり、ドメインオブジェクトを任意に取り上げたり、イベントストーミングを行ったり、他の手法を使って名詞を抽出し、それがマイクロサービスだと決めつけるのではありません。ここで見られる実際のプロファイルに基づいてマイクロサービスを選択しているのです。
ところで、時にはドメインに全く対応していないマイクロサービスが出てくることもあります。それはシステムの大きなボトルネックであり、この小さな機能を切り出したのは、スタンドアロンのマイクロサービスとして実行するのが理にかなっていたからです。他のものは予想よりもはるかに粒度が粗いかもしれません。そして、再びコンピューティング技術に話を戻しますが、何をするのでしょうか？Serverless、Lambda、コンテナ、どれが適しているでしょうか？そして、どのようなデプロイメントモデルをサポートする必要があるでしょうか？
これらすべてのものの和集合を持っていれば、私はどこに向かうべきかの良い感覚を持っていると思います。そして、コンピューティングを相互排他的なものと考えないでください。ここではコントロールプレーンとアプリケーションプレーンについては詳しく触れませんが、私たちのパターンを見れば、コントロールプレーンとアプリケーションプレーンがSaaS環境の一部であることがわかります。コントロールプレーンにServerlessを使い、アプリケーションプレーンにコンテナを使う人もいます。あるいは、一部のマイクロサービスでは、バッチワークロードか否かでコンテナかLambdaかを選択することもあります。さまざまな理由でそれらを選択できるのです。
コンピューティングリソースの選択とスケーリング
そして右下のこれ、デプロイメントモデルを見逃さないでください。今すぐプロダクトチームに聞いてみてください。「誰に売るの？フルスタックのサイロが必要な人が来るの？」今それを知っておきたいんです。そうすれば、それに合わせてスケールを考えて、スケーリング戦略を立てられますから。分解の重要性を強調するために、例えばこのオーダーサービスがあって、これは単なるLambda操作の集まりだとします。各機能が何らかの操作に対応しています。そして、私の環境での名詞として、これをマイクロサービスにするのが完全に理にかなっていて、それで終わりだと思っていました。
しかし、これらのプロファイルの消費と分離のニーズに関するデータをもっと得た後、この分解を表す4つの別々のマイクロサービスを思いつきました。これは単純化した例ですが、例えば、フルフィルメントがシステムの大きなスケーリングポイントだったり、フルフィルメントに特定の分離ニーズがあったりした場合、ワークロードの性質に基づいてスケールを達成するために、異なる方法で分解するかもしれません。
ここで見なければならないもう一つのことは、コンピュートについて話してきましたが、コンピュートの選択についてもう少し掘り下げたいと思います。簡単な例として、このオーダーマイクロサービスがあり、オーダーサービスにはGetOrderやUpdateOrderなどのいくつかの操作があります。デプロイメントの単位はマイクロサービスです。EC2では、AWSが昔からやっていることと同じで、ただスケールと弾力性があり、水平方向にスケールします。
この環境で絶対に実行できます。スケールを考えてマルチテナントのワークロードの課題に対処する場合、EC2ではマルチテナント環境でスパイキーな負荷に反応してスピンアップするのが難しい場合があります。このシナリオでは、人々がしばしばオーバープロビジョニングする理由です。これらのインスタンスをスピンアップすることの意味と、どれくらい早くスピンアップするかを考える必要があります。これはおそらくプールされたシナリオでより良く機能します。多くのテナントをそこに送り込めば、より多くのテナントスケーリングが得られ、おそらくアイドルリソースが少なくなり、おそらくより適合するでしょう。
状況が良くなり、私が多くの講演をしてきたのは、Lambda とマルチテナンシーの適合性についてです。Lambdaでは、スケールの単位がサービス全体ではなく、個々の機能になるマネージドコンピュートサービスに移行します。今日、誰かがただUpdateOrder機能を大量に消費していて、GetOrderは全く使っていない、そして明日それが逆転しても、私はあまり気にしません。テナントが何をしているかに対してだけ支払えばいいのです。サービスは依然として機能レベルでスケールするので、マイクロサービス全体のレベルではなく、サービスをどのように分解するかについてもあまり気にしなくてもいいかもしれません。
これは素晴らしいですね。適切なスケーリングポリシーや、どうやってスケールさせるかを心配する必要がなくなります。Lambdaに任せるだけでいいのです。ちなみに、これはsiloモデルとpoolモデルの両方で上手く機能します。私たちのサーバーレスリファレンスアーキテクチャには、両方の例が含まれています。ぜひそれを見て、どのように機能するか確認してみることをお勧めします。
もちろん、コンテナもあります。 多くのSaaS企業がAmazon EKSをデプロイメントモデルとして気に入っています。これは多くのツールを提供してくれます。EKSの領域で私が気に入っているのは、デプロイメントモデルについて新しい考え方ができることです。例えば、テナントごとのnamespaceがオプションとして登場します。ここにnamespaceを設定できます。node affinityのような方法を使って、特定の種類のノードにワークロードを割り当てることができます。ここでは、高速にスケーリングできる環境が得られるので、過剰にプロビジョニングする必要がありません。非常に効率的に運用できるのです。
デプロイメントモデルとスケーリングの関係
ウィンドウにAWS Fargateが表示されているのがわかりますね。Fargateを使えば、サーバーレスオプションをEKSの領域に持ち込むことができます。つまり、クラスターの下で動作しているノードについて考える必要すらないのです。Lambdaと同じ考え方で操作できます。細かな違いはありますが、一般的にはその利点を活かすことができます。
スケーリング戦略を選ぶ際、これらのうちどれか一つが絶対的に正しいとは言えません。ワークロードを見て、最適なものを判断する必要があります。繰り返しになりますが、すべては対象となる人々とワークロードの性質に帰結します。 デプロイメントモデルがスケーリングにどう影響するかを見てみましょう。siloed scalingはかなり予測可能です。これは、ライフサイクルを持つ従来のシステムのようなものです。それを利用しているビジネスの一日の終わりがあり、最後に使用が減少するかもしれません。これらの環境のスケーリング方法を考えるのにそれほど苦労することはないでしょう。
しかし、リソースをpooled環境に置き始めると、消費パターンは全く予測不可能になります。ここでのスケーリング方法を考えるには、ピークと谷の処理にもっと焦点を当てる必要があります。アイドル状態の消費についてはあまり心配する必要はありませんが、noisy neighborのような問題について考える必要があります。
最後に、私がre:Inventで今年さらに詳しく話したスケールの単位の1つは、ポッドと呼ばれる概念を作ることです。これらのテナントをポッドに入れ、一定数のテナントをそこに配置します。例えば、8つのテナントがあれば、このポッドのスケーリングポリシーを定義して、一般的にこのポッドが安全であることを確認できるでしょう。また、このポッドを分離することで、その影響範囲はこの8つのテナントに限定されます。
ポッドの境界と、そこに配置したいテナントの数に慣れてきたら、別のポッドを立ち上げることができます。ここでは単にシャーディングを行い、ポッドごとに水平方向にスケーリングしているだけです。そして、次のテナントのセットをここに配置します。一部のチームはこのアプローチを好みます。なぜなら、個々のサービスレベルまでスケーリングやポリシーの対応をする必要がなく、ポッドを十分にスケールさせることだけに集中できるからです。
うまくスケールするために、組織はテナントをポッド間で移行して、管理やスケーリングの問題に対処する必要があるかもしれません。このアプローチでは、ポッドでスケールアウトができ、マルチリージョンモデルをサポートできるという点でスケーリングに価値があります。ポッドを環境のデプロイメント単位として使用すれば、同じポッドを異なるリージョンにデプロイし、マルチリージョンのフットプリントを作成できます。
このアプローチにはコストがかかることに注意することが重要です。デプロイメントの複雑さと運用の複雑さが増します。なぜなら、運用ビューのために全てのポッドにわたって集計する必要があるからです。しかし、スケールについて議論する際には、考慮すべき別の次元を提供します。まだ議論の余地はありますが、スケーリングに対する異なるアプローチを提供します。
ストレージのスケーリングとレジリエンス
私のチームが探求している別の興味深い概念は、異なるサービスの様々なフットプリントに関連しています。計算集約型のものもあれば、バッチ処理に焦点を当てたものもあります。これは疑問を投げかけます：全てのマイクロサービスを書いて、特にコンテナベースの環境で同じインスタンスタイプに配置すべきでしょうか？それとも、特定のワークロードを特定のインスタンスタイプに接続してスケーリングを最適化できるでしょうか？
例えば、3つの異なるサービスが3つの異なるインスタンスタイプで実行されているとします。Amazon EKS（Elastic Kubernetes Service）内でノードアフィニティを使用して、特定のタイプのワークロードを特定のタイプのインスタンスにバインドすることはできるでしょうか？これにより、環境のスケーリング体験は向上するでしょうか？メモリ集約型のものやGPUの恩恵を受けるものがある場合、そのワークロードにGPUを提供した方が良いでしょうか？答えは、コストやスケーリング要件など、さまざまな要因によって異なります。その妥当性を証明するには多くの計算が必要ですが、検討に値する興味深い分野です。
EKSとクラスターのセットアップ方法を見ると、M5インスタンス上でノードが実行されています。私たちが持っているクールなツールの1つがKarpenterと呼ばれるものです。 KarpenterはEKS環境内でこの問題に対処する方法を提供します。Karpenterを使用すると、利用可能なインスタンスタイプのリストを提供し、ポッドのスケジューリング時にノードが起動する際に、異なるインスタンスタイプを割り当てるよう指示することができます。このアプローチはまだ推測の域を出ませんが、特にノードアフィニティのバージョンについては、考え始めるのに十分興味深いものです。Karpenterの側面については、適切なワークロードを適切なインスタンスタイプにマッチさせるために、十分に効果的にスケジューリングする方法をまだ見つける必要がありますが、興味をそそられます。
考慮すべきもう1つの重要な側面は、オンボーディングの規模です。オンボーディングプロセスがある場合、コントロールプレーンはテナントを作成し、テナント環境をプロビジョニングします。さまざまなデプロイメントモデルにわたって必要なすべてのサービスをセットアップするためにアプリケーションプレーンと連携し、関係を確立するために課金プロバイダーと通信します。多くの動く部分があるため、組織にとって何が重要な規模を構成するかを考慮することが不可欠です。現在約10件のオンボーディングを処理している場合、100件や1,000件をどのように処理するかを考えてみてください。組織にとって実用的だが高い上限を見つけ、その環境で効果的にスケールできるかどうかを評価してください。
ビジネスが突然多くの人々をオンボードする必要が生じたために、オンボーディングが失敗し始めるシナリオを想像してみてください。スケーリングの制限のために十分な速さでオンボードできないとビジネスに回答せざるを得ない場合、ビジネスに大きな影響を与える可能性があります。したがって、スケーリングのこの側面に重点を置くことが非常に重要です。
オンボーディングプロセス中にこれらの環境をプロビジョニングする際のマルチテナントの複雑さを見ると、コントロールプレーンはさまざまなデプロイメントモデルに対処する必要があります。 これらの環境を構築し、スケールを考慮する際の重要な側面の1つは、デプロイメントプロセスを効果的に自動化する方法を見つけることです。
SaaSにおけるデプロイメントの自動化とスケーリング
デプロイメントプロセスを効果的に自動化することは、スケールを考慮する際に非常に重要です。主な課題の1つは、異なるテナント環境のデプロイメントと設定の自動化です。例えば、プレミアムティア用のフルスタックサイロがある場合、そのティアの特定の要件を処理するために、独自のterraform、CDKビット、さまざまなDevOps自動化コンポーネントが必要になります。他のティアと共通の要素もあるかもしれませんが、それぞれに固有の特性があります。
また、1つのサービスがサイロで実行され、残りのサービスが共有プール環境で実行される、アドバンスドティアもあるかもしれません。 さらに、完全にプール化された環境に単純に移行するベーシックティアのテナントをオンボーディングするモデルもあるでしょう。ここには考慮すべき点が多くあり、例を見ると、 関連するすべての要素がわかります。実際、Helmやその他のKubernetesツールを使用してこの全体的なエクスペリエンスを自動化し制御する方法を示す、優れたビルダーセッションがあります。これにより、すべてを機能させるためのさまざまな一回限りのコードソリューションを追いかける必要がなくなります。
このプロセスが1つの顧客に対して機能することを確認したら、次の課題はそれをスケールアップすることです。システムは大量の新しいテナントをどのように処理するのでしょうか？一部のプロセスが失敗した場合、フォールバックをどのように管理するのでしょうか？システムは何かが失敗したか成功したかをどのように判断するのでしょうか？これらはすべて、SaaSアプリケーションをスケーリングする際に対処すべき重要な質問です。
デプロイメントは、テナントのプロビジョニングとは異なる、もう1つの重要な側面です。プロビジョニング中にテナントをオンボーディングし、その環境をセットアップしますが、チームの開発者が新しいマイクロサービスを書く際のエクスペリエンスも考慮する必要があります。開発者はデプロイメントモデルを気にする必要はありませんが、デプロイメントパイプラインにはテナントの認識を組み込む必要があります。
例えば、スタンダードティアとアドバンスドティアで異なる設定を管理するためにフィーチャーフラグを使用するかもしれません。 このプロセスを効果的にスケールする方法を決定する必要があります。フィーチャーフラグを使用して新機能をリリースするとはどういうことでしょうか？SaaS環境で特に人気のあるA/Bテストやカナリアリリースをどのように処理しますか？これらのプロセスが異なるデプロイメントモデルでどのように機能し、どのように効果的にするかを考慮する必要があります。
これをより具体的にするために、複数のデプロイメントモデルをサポートするサーバーレスSaaSリファレンスアーキテクチャの例を見てみましょう。 このアーキテクチャには2つのスタックがあります：プールされたテナント用の基本スタックと、プレミアムまたは上級ティアのテナント用の完全にサイロ化されたスタック（tenant1と識別されます）です。この例は、どのテナントがどのモデルに割り当てられ、そのリソースがどこに配置されているかを追跡する必要性を示しています。
AWS CodePipelineによって管理されるデプロイメントプロセスには、ソースの取得、ビルド、デプロイが含まれます。 これは、スタックに必要なエントリを作成し、特定の設定を使用します。例えば、プロビジョンドコンカレンシーは、基本ティアのテナントではゼロに、プレミアムティアのテナントでは50に設定されるかもしれません。 各テナントスタックは独自のAPI Gatewayを持つため、そのテナントのワークロードのエントリーポイントとなるURLも追跡する必要があります。
これらの動く部分をお見せしているのは、スタックの詳細を教えるためではなく、スケールする際にはこれらのメカニズムが効果的にスケールできることを確認する必要があることを強調するためです。これらが使用すべき適切なツールとメカニズムかどうかを考え、デプロイメントをスケーリング戦略の不可欠な部分として考える必要があります。
SaaSのレジリエンス：多層的なアプローチ
さて、レジリエンスについて議論し、その後、検証とカオスエンジニアリングに移りましょう。レジリエンスはあらゆる環境で重要ですが、SaaSのコンテキストでは、必要とされる特定のレジリエンスのレイヤーを考慮する必要があります。システムが障害耐性を持ち、サーキットブレーカーのようなパターンを組み込む必要があることは分かっていますが、他に何が必要でしょうか？
SaaSレジリエンスの主要な領域を分解しようと試みましたが、これは私にとってまだ発展途上の概念です。 コンピューティングリソース、コントロールプレーン、そして新規テナントを含むSaaSアーキテクチャ全体を考えると、対処すべきレジリエンスのレイヤーは何でしょうか？重要な側面の一つは、テナントが私たちの環境に負荷をかける方法をどのように制御するかです。
よくある質問として、テナントがシステムに入ってくる際に、システムに過度な負荷をかけたり、システムをダウンさせたりしないようにするにはどうすればよいか、というものがあります。 また、レジリエンスの一部とは言えないかもしれませんが、テナントの分離についても考えてみましょう。私にとって、レジリエンスの一部とは、あるテナントが他のテナントのリソースを見ることができないようにすることです。つまり、レジリエンスの観点から、あるテナントが他のテナントのデータを見ることができないよう、あらゆる対策を講じる必要があります。なぜなら、そのようなことが起これば、SaaS企業にとって大きな問題となるからです。
そして、レジリエンスの一部としてスケールも考慮する必要があります。効果的にスケールし、十分なリソースを確保しなければなりません。十分にスケールできずにシステムがダウンしてしまえば、それは問題となります。そして、意外かもしれませんが、システムの動作を十分に可視化できているかどうかも重要です。どのようにスケールしているのか？テナントはどのようにスケールしているのか？マイクロサービスはどのようにスケールしているのか？それらはシステムにどのような負荷をかけているのか？そして、その負荷に基づいてシステムはどのように動作しているのか？これらが可視化できていなければ、効果的にスケールしているかどうかわかりません。システムがレジリエントかどうかもわかりません。レジリエンスとは、問題が実際に発生する前に検知する能力でもあります。問題が発生する前に検知する方法がなければ、レジリエンスを実現するための他のアプローチを活用することはできません。
そして最後に、オンボーディングとデプロイメントのレジリエンスも重要だと考えています。 これら2つの側面についても考える必要があります。オンボーディングはどの程度問題に耐えられるか？問題からどのように回復するか？デプロイメントは障害にどのように対処し、障害からどのように回復するか、 そしてそこでどれだけ堅牢であるかを確認する必要があります。さて、フロントドアから始めて内部に進んでいくと、最も基本的なテーマから始めることになります。これは実際にはどのようなシステムにも当てはまりますが、ユーザーが単にシステムに過度の負荷をかけてダウンさせることを防ぐには、スロットリングメカニズムを導入する必要があります。
私の場合、ここで示している簡単な例の1つは、Amazon API Gatewayです。API Gatewayには、後で見るLambda authorizerという概念があり、これによってポリシーを定義し、テナントが環境に与える負荷の種類を制御することができます。しかし、この議論はさらに深いものです。スロットリングに関するこの議論全体は、層状の議論です。つまり、アプリケーションのフロントドアを通過した後でも、サービスからサービス、サービスからストレージへと移動する際に、システムのすべての部分と層で、どのようにしてスロットリングを実装するか、あるいは実装するかどうかを検討する必要があります。ストレージにプロビジョンド同時実行性があるか、あるいは誰かがメカニズムやノブ、ダイヤルを提供しているか、そうすることで、テナントが環境に与える作業負荷と要求を達成し、制御できるようにするのです。
これをより具体的にするために、これを取り出してティアを設定してみましょう。4つの異なるティアがあり、実際には3つのティアがあり、プラチナティアに2つのテナントがいるとします。彼らが私の環境に入ってきてAPI Gatewayにヒットすると、authorizerにヒットし、どのテナントがどのAPIキーにマッピングされるかを判断し、そしてLambda authorizerを使って、使用プランに接続されたAPIキーを持つことができます。つまり、ここには3つの異なるAPIキーがあります。これら3つのAPIキーは使用プランにマッピングされます。そして、Lambda authorizer内で、 入ってくるティアを使用プランに解決します。そして、その使用プランがauthorizerポリシーを設定し、下流に進むにつれてAPI Gatewayでそれを適用します。そして、クォータを超えた場合、メッセージは通過しません。
このダイアグラムに載せておきたかったもう一つの要素は、オーソライザーポリシーを使って、どのメソッドやエントリーポイントが見えるかをコントロールできるということです。つまり、ゲートウェイ上で、ある人の役割や他の条件に基づいて無効なエントリーポイントにアクセスしようとした場合、ここでそのパスをブロックできます。これは、レジリエンスの観点からも素晴らしいツールだと思います。ここで考えていただきたいのは、私がティアリングをレジリエンスと同等に扱っているということです。ティアリングはレジリエンスの一部だと考えています。もし、ベーシックティアのテナントがシステムに大きな負荷をかけ、プラチナティアのテナントの可用性に影響を与えているとすれば、それは私のシステムにとってレジリエンスの問題です。
私はこれを分類し、ベーシックティアのテナントに対して、ある一定のレベルで切断されるというポリシーを設定します。これは意図的なものです。そのため、彼らから「待ってください、スロットリングされていますが、何が起こっているのですか？」という連絡があった場合、「スタンダードティアに上がるか、より良いスループットが必要ならプラチナティアに移行してください」と答えることになります。ほとんどの場合、問題ないでしょうし、一日中そのような状況が起こらないようにポリシーを設定しますが、それでも設定は行います。なぜなら、彼らが突然暴走して他のすべてのテナントに影響を与えるような日が来ないとも限らないからです。
API Gatewayだけの話にしたくないので、別のアプローチをお見せしましょう。 ここでLambdaを使う場合、予約済みコンカレンシーを利用できます。テナントを3つの別々のティアに分け、関数の別々のコピーをデプロイしますが、それぞれ異なる予約済みコンカレンシー値を設定します。これにより、Lambda関数内で同時に実行できる数が決まります。ベーシックティアでは100で同時実行の上限に達し、アドバンスドでは300で上限に達します。そしてプレミアムでは、より多くの実行が可能になります。これは、前のスライドで説明した考え方を実装する別の方法です。
テナント分離とレジリエンスの関係
さて、分類が少し難しいレジリエンスの領域として、レジリエントなストレージという概念があります。 レジリエントなストレージをどのように構築すればよいのでしょうか。これは私が話す中でも最も難しい領域の一つです。なぜなら、ストレージを選ぶ多くの人が、同時にコンピュートサイズも選んでいるからです。彼らは「テナント1はサイロで、db.m3から始めよう」「サイロ2はdb.m5だ」「そして、プールされたテナントもすべてdb.m5で行こう」などと言います。それが適切なサイズのインスタンスなのかどうか、実際のところ分かりません。だからこそ、ここでオーバープロビジョニングすることが多いのです。それが唯一の選択肢だからです。しかし、これは私にとってレジリエンスとは言えません。単に十分な容量を用意して失敗しないことを期待しているだけです。
実際に目指すべきは、効率性とスケールのバランスです。過度にプロビジョニングしたくありません。そのため、右側に移動すると、組織が行うようにインスタンスのサイズを調整し始めます。そして、プールに関しては何をすべきか全く分かりません。プールのグラフは全体的に変動が激しいことを思い出してください。おそらく、サイズを小さくすることはできません。なぜなら、誰かが何かを暴走させた日に、プールされたすべての顧客に影響を与える可能性があるからです。それは良い状況ではありません。では、答えは何でしょうか？この問題に対する魔法のような答えはありません。あればいいのですが。
私は、答えのヒントがサーバーレスストレージにあると考えています。現在、AWSには多くの優れたストレージオプションがあり、DynamoDBやAurora Serverlessなどのサーバーレスオプションがあります。EMRにもサーバーレスがあり、Amazon OpenSearch Serviceにも現在サーバーレスがあります。このように、サーバーレスがストレージスタックにどんどん浸透してきています。ストレージをこれらのモデルに置くことができればできるほど、ストレージ戦略の回復力が高まります。なぜなら、これらに密接に結びついていないからです。これらのストレージメカニズムには、プロビジョンドスループットや容量に関する独自のノブやダイヤルもあります。オンデマンドなのか、そうでないのか？つまり、回復力に対処するためのツールがたくさんあるのです。
さて、回復力に関するもう一つの点は、環境内の障害境界がどこにあるかということです。例えば私の場合、オンボーディングを見ると、IDプロバイダーとのやり取りがあったり、テナントプロビジョニングとのやり取りがあったりします。テナントプロビジョニングは、別のサービスに全てのリソースをプロビジョニングするよう依頼します。そして、請求とのやり取りもあるかもしれません。これは第三者の請求プロバイダーかもしれません。これらの潜在的に非同期な、潜在的に第三者に依存するポイントは、システムのフォールトトレラントな接点となります。請求システムがダウンしている場合、どうしたいでしょうか？ここで、フォールバック戦略が必要になります。古典的な回復力戦略を見ると、今は請求を失敗させて、後で再試行するかもしれません。しかし、残りのオンボーディングプロセスは進めるようにします。
デプロイメントについても同じことが言えます。これらの異なるデプロイメントメカニズムを全て試して、そのデプロイメントの一部として全てのTerraformを実行し、全てのCDKコードを実行してこれを行う場合。そしてそれも恐らく少し非同期で行われているでしょう。失敗した時はどうするのでしょうか？おそらくこれについてはより多くのコントロールができるでしょう。なぜなら、これはおそらくより多くあなた自身のコードだからです。しかし、それでも戦略が必要です。再試行しますか？クリーンアップして再試行しますか？何をしますか？
また、この分離の概念全体に関する戦略も必要です。私は、回復力が分離の話の一部だと言いました。そして私にとって、分離のための回復力をどのように構築するかは、環境をどのようにデプロイしたかによって異なります。例えば、デプロイメントモデルとしてテナントごとのアカウントという概念を使用している場合、これらの間のクロスアカウントアクセスをどのように防ぐかを考える必要があります。おそらくより簡単なのは、テナントごとにVPCを使用している場合です。その場合、どのような戦略と回復力戦略を取り、これらのVPCが互いに確実に分離されるようにするのでしょうか？そのための優れた構成要素が利用可能です。
そして、より細かくなると、サービスとリソースの分離にまで至ります。そこがはるかに難しくなります。両方がサイロ化されている場合、あるサービスが別のサービスを呼び出せないようにするにはどうすればよいでしょうか？場合によっては通信させたいこともありますが、そうでない場合もあります。
他のAWSサービスと通信する際、特定のテナントとそのテナントコンテキストに対して適切なビューだけにアクセスしていることをどのように確認すればよいでしょうか？そのための戦略を考える必要があります。一般的に、テナント分離は必須だと言われています。ここでは、テナント分離をシステムのレジリエンスと関連付けて考えています。これまで通りテナント分離を行うべきですが、レジリエンスの観点から考えてみてください。
ポリシーの分離とレジリエンスの向上
レジリエンスに関する最後のポイントは、少し曖昧で楽観的かもしれませんが、コードとポリシーをビルダーから切り離すことだと考えています。 分離ポリシーを各マイクロサービスのコードに埋め込むのではなく、それを処理する汎用的なメカニズムが欲しいのです。JWTトークンからテナントコンテキストを取り出す方法や、メトリクスとログを記録する方法など、ビルダーがコード全体でポリシーを適用し続けるのは問題を引き起こし、レジリエンスの問題を生み出すでしょう。
この例ではLambdaを使用しています。Lambdaレイヤーがあります。これはEC2上のJavaライブラリでも構いません。 JARファイルなど、何でも構いません。ポイントは、アーキテクトとして、これらのポリシーを開発者の視界から外し、 単にそれらを使用するよう依頼することです。この例では、productサービスとorderサービスがあり、適用されているマルチテナントポリシーはすべてのサービスで共有されるレイヤーで適用されています。これにより、ログにテナントコンテキストを注入する方法や、トークンの扱い方、テナントスコープを取得するためのIAMとポリシーの使用方法などを変更したい場合、それらはすべて開発者の視界の外にあります。これは優れた防御戦術であり、システムのレジリエンスを高めることにつながります。また、それ自体が良い実践でもあります。
最後に話したポイントは、スケールとレジリエンスを構築した後のことです。 多くの人はここで止まってしまいます。良いコードを書いて、うまく動いているように見えれば十分だと。しかし、これらのメカニズムは非常に微妙なものなので、それらが機能しているかどうかを知らなければ、本当に目標を達成したとは言えません。 ここで、共通のノードを見てみると、これはSaaSに特有のものではありません。これはカオスエンジニアリングと良好なテストの概念です。つまり、レジリエンスプロファイルとスケールプロファイルを見つけ出すのです。先ほど話した異なる消費プロファイルや分離プロファイルは何でしょうか？
これらを経験への入力として使用し、さまざまなワークロードと異なるティアを定義します。そして、そのデータをアプリケーションへの入力として使用します。 目的のプロファイルに合わせてテナントの集団を生成し、テナントの人口を構築します。この経験への自動認証を行います。 そして、負荷ベースのテストを行うため、これらの並列ワークロードを実行して環境に負荷をかけ、これらの部分にストレスを与えます。ここでの全体的なアイデアは、これらの戦略をすべて構築することです。そして、この図の左側に注目してください。多くの人は右側に興味を持ちがちです。右側を実行するコードにすぐに取り掛かりたがります。
しかし、スケールと耐障害性に関する問題を明らかにする興味深いことは、左側で起こります。このプロセスにどのようなデータが投入されるのでしょうか？テナント数はどのくらいでしょうか？テナントのプロファイルはどうあるべきでしょうか？例えば、多数のプレミアム層テナントと少数のプールド層テナント、あるいはその逆のパターンで、システムの反応を見てみましょう。そして、その環境で実際のコードをリアルタイムで実行してみます。期待通りにスケールし、応答するでしょうか？これにより、本番環境に出す前に、システムのパフォーマンスについて多くのことがわかります。また、問題として気づいていなかったことも明らかになるでしょう。
要は、価値の高いスケーリング戦略を追求することが重要です。すべてのシナリオやすべての細部をカバーする必要はありませんが、スケーリングと耐障害性戦略の重要な部分がどこにあるかを把握し、それらにどう取り組むべきかを理解することが大切です。そして、ノイジーネイバーやスケール、耐障害性のためのテストを見てみると、ここにノイジーネイバーのシナリオがあります。異なるプロファイルを持つ多数のノイジーネイバーを作成しました。異なる色は、これらのグループで異なる行動をとる外れ値の人々を表しています。ここにノイジーネイバーオーケストレーターを作成しました。これは新しく書く必要のあるコードです。あるいはサードパーティのツールかもしれません。
このような作業を行う優れたツールも存在します。これらのツールはテナントをプロビジョニングし、これらのテナントのアプリケーションプレーンをプロビジョニングします。そして、これらの異なるワークロードを、この異なる負荷シミュレーターを通して実行します。そして、多くの人が見落としがちな重要な部分は、アプリケーションプレーンにアクセスした後、運用ビューを観察することです。
多くの人は単にテストを実行し、システムが生き残ったことを確認します。New RelicやDatadog、AppDynamicsなどを見て、すべてが健全に見えれば「OK、問題なし」としがちです。しかし、そうではありません。私が知りたいのは、運用担当者が見ているダッシュボード内で、何かが飽和状態になっている状況を作り出せるかどうかです。それが表面化しているでしょうか？期待される警告やアラームが鳴っているでしょうか？システムに異なる負荷をかけたときに、期待通りの運用ビューが得られるかどうかを知りたいのです。これが多くの人が見落としがちな部分だと思います。人々はこの経験の運用側まで十分に考慮していないのです。
スケールとレジリエンスの検証：カオスエンジニアリングの重要性
もう一つの重要な点は、先ほど話した非同期統合と、優雅で耐障害性のある体験を持つことです。これは既に話したことですが、オンボーディングがテナント管理にヒットし、テナントプロビジョニングにヒットし、アプリケーションプレーンをプロビジョニングし、課金にヒットし、そこに行きます。これらの障害に対処したいのです。そして、他の場所でも同様です。サードパーティの依存関係がある場所、他者の可用性や耐障害性があなたの制御外にある場所すべてで、フォールバック戦略は何でしょうか？これは基本的な耐障害性ですが、マルチテナント環境ではより重要です。そして、このコントロールプレーンでは、あなたがこの経験のほとんどをオーケストレーションしているので、より重要です。あなたのコントロールプレーンはこれらの部分を処理できる必要があります。
また、オンボーディングの経験を検証する必要があります。スケーラブルでレジリエントなオンボーディング体験が必要だと言いました。これは、異なるプロファイルのテナントを、これらの異なる構成で負荷を分散させて、オンボーディングプロセスを通して実行し、フルスタックのサイロを行うplatinumをオンボードする場合と、新しい環境設定を構成するだけで新しいインフラをあまりプロビジョニングしないbasicをオンボードする場合、そしてこれらの組み合わせや同時に行う場合に、システムがすべてを効果的に処理できるかどうかを自分自身に証明することを意味します。すべての部分が期待通りに機能していますか？ほとんどの場合、そうではありません。多くの人が完全なオンボーディングを構築した後でも自信を持っていますが、実際にこれらを始めると、小さな問題が発生することに気づき始めます。ただ、頻繁には起こらないので、気づかないだけです。
もう一つ、これは最も難しいものの一つだと思いますが、レジリエンスの一部として分離を設定しました。どうすればいいでしょうか？どのようにテストすればいいでしょうか？例えば、この環境があり、token vending machineを使用しているとします。テナント1がこの環境に入ってきて、テナント1のデータベースにアクセスしようとしています。テナント2のデータベースもここにあります。テナント1は明らかにテナント1のデータベースだけを見るべきです。さて、何が起こるでしょうか？token vending machineを使用し、ロールを引き受けています。それらすべてが存在します。何かがうまくいかなかった場合、それが機能することをどのように証明できるでしょうか？実際に唯一の選択肢は、コード内で、または第三者のツールを通じて、「いいえ、あなたはテナント1ではなく、テナント2です」というコンテキストを注入することです。JWTトークンを注入し、コンテキストを変更するようなことを行い、そしてIAMポリシーが「いいえ、できません。境界を越えようとしています」と言うポイントで注入したことを証明する必要があります。
そして、誰かが実際に境界を越えようとした場合、テナント間で境界を越えようとする試みがあったことを示す何かが運用ダッシュボードに表示されるでしょうか？私の環境でそれが起こった場合、知りたいと思います。境界を越えようとするものがあれば、たとえ拒否されたとしても、何かが起こっていることを意味します。おそらく誰かがシステムを破壊しようとしているのかもしれません。だから、何が起こっているのか知りたいのです。そして、この運用経験があると言いました。はい。今、この素晴らしい運用経験があります。どうすればできるだけ多くのものを投入できるでしょうか？その運用経験が期待通りに機能していることを証明するテストはすべて何でしょうか？これをあなたと運用の一部として見てください。あなたが運用担当者なら素晴らしいです。あなたはすでにそれを行っています。これを組み合わせたものとして見てください。
そして、これは開発やQAにとっても、本番環境と同じくらい価値があると皆さんに言いたいです。マルチテナントシステムを構築しようとしていて、みんなが構築しようとしていて、みんなが何かをプッシュしていて、もちろん新しいので壊れています。開発環境で使いたいツールは、このようなツールです。なぜなら、私はまだ新しいサービスが他のすべてのサービスと一緒に何をしているのかを整理しているところで、何が起こっているのかを見たいからです。そしてQA担当者として、これらの負荷の問題をシミュレートして、本当に期待通りに動作しているかどうかを確認したいのです。
マルチテナントSaaSにおけるスケールとレジリエンスの総括
さて、ここでいくつかの要点をまとめます。レジリエンスとスケールの話が、従来のスケールとレジリエンスの概念だけではないことが明確になったと思います。マルチテナンシーは、私にとって、その上に全く新しい考慮事項の層を追加します。したがって、ソリューションのスケールとレジリエンスについて考える際には、マルチテナントの側面を考慮する必要があります。
マルチテナント版のストーリーについて、そして考慮すべき新しい要素について、絶対に考えておく必要があります。効率性とスケールは常に競合関係にあることを覚えておいてください。なぜなら、これらは常に互いに引っ張り合っているからです。私たちはできる限り効率的でありたいと思っています。私は皆に効率的な環境を構築するよう伝えましたが、常に「はい、でも適度なスケールを」と考えています。システムのニーズを満たすような形でスケールしていないとか、障害が発生しないように、余裕を持たせたいと思います。
また、SaaSにおいてはすべてがビジネスと技術的目標の混合ですが、スケールは間違いなくそうです。誰かが「スケーラブルなSaaS環境を構築してください」と言ってきたら、私は「どのようなデプロイメントモデルを使用するつもりですか？」と尋ねます。彼らが何をしたいのかを理解するために、100の質問をして、どのバージョンのスケールが適切かを判断します。つまり、正しい答えを見つけるためには、ビジネスに深く関わる必要があるのです。
そして、スケールとレジリエンスのためにさまざまなデプロイメント戦略をどのように活用できるかを検討すべきだと思います。これらの環境をどのようにデプロイし、テストして、本当に機能していることを証明するか？そして、私にとってスロットリングは単なる階層化戦略ではなく、マルチテナント環境における基本的な戦略でもあります。スロットリングを行い、誰も環境に過度の負荷をかけて影響を与えないようにしたいのです。
ぜひ、興味深いワークロードプロファイルを構築してください。環境内のワークロードパターンを把握してください。あなたが行っていることとしては、それほど面白くないように聞こえるかもしれません。しかし、これらのワークロードをシミュレートし、本当に興味深いペルソナを見つけ出すことに時間を投資し、プロダクトオーナーなどを巻き込めば、スケールとレジリエンスに関する非常に興味深いデータを得ることができます。そして、これらすべての検証を後回しにしないでください。私なら、すぐに構築しようとします。テスト駆動開発のようなものです。何か本当にクールなものを作り、それが本当にクールなことをするはずです。それが本当にクールなことをしていると自分で証明するにはどうすればいいでしょうか？ここで過剰にならないようにしてください。ただし、少なくとも基本的なことが期待通りに機能していることを自分で証明するくらいはしてください。
関連セッションの紹介と講演のまとめ
さて、ここで他のセッションについていくつかハイライトをお伝えします。これらのうちのいくつかは... どれが既に行われたのか、まだ行われていないのか、私には分かりません。この時点で全てが曖昧です。しかし、ここにSaaSに関連する進行中のブレイクアウトセッションがあります。興味があれば、まだ進行中のChalk Talkもあります。アイデンティティのフェデレーションは興味深いですね。Chaosに関するトークもあります。これは私がここで話したことの変形版で、もっと深く掘り下げたい方向けです。Chalk Talkの設定で行います。私がそれを行い、この検証とテストの概念についてより深く掘り下げていきます。
素晴らしいワークショップがたくさんあります。SaaS survivorは、運用やオペレーショナルツールのテストなどに関する本当にクールなワークショップだと思います。以上です。この講演に参加していただき、本当にありがとうございます。多くの価値を得ていただけたことを願っています。マルチテナント環境におけるスケールとレジリエンスについて考える際に、考慮すべき事項の全体像をお伝えできたのではないかと思います。より具体的な処方箋的ツールと合わせて、お役立ていただければ幸いです。re:Inventの残りの日程もお楽しみください。良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion