re:Invent 2023: AWSが語るSaaSのコスト最適化戦略とアーキテクチャ設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Building cost-optimized multi-tenant SaaS architectures (ARC311)
この動画では、AWSのSenior Principal Solutions ArchitectであるTod Goldingが、SaaSのコスト最適化について深く掘り下げます。インフラ共有だけでなく、効率的な成長、運用効率、ワークロード理解の重要性を説明します。また、テナントごとのコスト計算、ティアリング戦略、運用ダッシュボードの必要性など、SaaSアーキテクトが直面する具体的な課題と解決策を紹介します。コスト効率化の本質を理解し、成功するSaaSビジネスを構築するための貴重な洞察が得られます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
SaaSコスト最適化の全体像：インフラを超えた視点
おはようございます、皆さん。re:Inventへようこそ。月曜日の朝9時にスケジュールを見たとき、この部屋はがらがらになるだろうと思っていました。でも、ようこそいらっしゃいました。この良いセッションで、皆さんのre:Inventが良いスタートを切れることを願っています。スライドにもありますように、私はTod Goldingで、AWSのSenior Principal Solutions Architectです。約8年間、AWSでSaaS分野に携わり、様々な顧客やドメイン、ユースケースに取り組んできました。移行プロジェクトやグリーンフィールドプロジェクトも含まれます。
SaaSに移行する様々な段階にある多くのソリューションや組織を見てきました。明らかに、SaaSについてのほぼすべての議論は、どのようなプロファイルの方でも、コストを中心としたテーマを持っています。実際、どのような状況や経済状況にあっても、コストはしばしばSaaSデリバリーモデルへの移行の大きな動機の一つです。人々はSaaSのスケールメリットを本当に求めています。多くの場合、コストが組織にとって大きな問題となっている環境から来ており、SaaSをその問題を解決する方法として見ています。
私のチームは、これらのコスト問題を解決するために、長年にわたって様々なソリューションを構築してきました。テナントごとのコスト戦略を構築し、テナントごとのコストの計算方法や、テナントがインフラのどの部分を消費しているかを把握する方法について、長年にわたって講演してきました。また、より良いコスト体験を実現するために、階層化や価格設定、その他の戦略についても話してきました。しかし、これらは部分的なものでした。今年のre:Inventでは、このコストの話から一歩引いて、コストの全体像を見ることにしました。
すべての動く部分を見てみましょう。もし私が今日、皆さんの立場にいたら、コスト最適化のために考えるべき大きなアーキテクチャパターン、テーマ、戦略は何でしょうか？このアプローチを進めていくと、私が考えるコスト最適化の範囲が、皆さんの予想よりも大きいかもしれません。ここでの目標は、単に「Xをしなさい」や「Yをしなさい」といった具体的な指示を与えることではありません。コスト最適化をどのように考えるべきかについての思考モデルを提供することです。
これは、アーキテクチャに踏み込まないという意味ではありません。むしろ、アーキテクチャの詳細に深く踏み込みます。アーキテクチャのどの領域に焦点を当てるべきか、そしてより良いコスト体験を実現するためにソリューションのアーキテクチャ体験をどのように設計するかを見ていきます。しかし、それをより広範な概念やアイデアと結びつけ、コスト最適化についての考え方を広げていきたいと思います。
これは300レベルのセッションですので、ここではIDEを開いたり、大量のコードを書いたり、たくさんのデモを行ったりはしません。アーキテクチャ図、パターン、戦略について見ていきます。絶対に技術的な内容ですが、300レベルです。ですので、アブストラクトと皆さんがここにいる理由と一致していることを願っています。もし一致していなくて、他のもっと良いセッションに行きたいと思われるなら、それで全く問題ありません。皆さんにとって適切なセッションに参加していただきたいと思います。
SaaSにおけるコスト最適化の真の意味
さて、コスト最適化について話すとき、ほとんどの人が持っているコスト最適化に関する非常に典型的な見方があります。 私が訪れるほぼすべてのチームが言うのは、「我々には何らかの環境があるか、これから構築しようとしている環境があります。そしてその環境には、基本的に自分たちのサービスやリソースのスタックを実行している顧客がいます。それは彼らの環境の一部です。彼らは管理サービス環境にいるかもしれませんが、一部の顧客は同じソリューションを実行し、一部はそうでないかもしれません。」
そして、この環境を持つことで生じる痛みを感じています。顧客ごとに何か特別なものがあると、コストの面では良い話にはなりません。アイドル状態のリソースが発生したり、環境の一部が過剰にプロビジョニングされたりすることになります。これらの一回限りの環境をサポートすることは、どの組織にとってもコスト面では良い話ではありません。これが、多くの人々がSaaSを大規模に採用している理由の背景にあります。実際、これはこのような課題を克服するための戦略なのです。
そこで、このような考え方から、人々はSaaSのコスト最適化とは、これらの顧客をマルチテナント環境に注ぎ込み、すべてを共有することだと考える傾向があります。コンピューティングを共有し、ストレージを共有し、クラウドのスケールと弾力性を活用するためにできることをすべて行います。そして、テナントのニーズに基づいて水平方向にスケールアウトするだけです。これで、テナントが消費しているものと我々が実際に支払っているものの間に、はるかに良い整合性が生まれます。
これは絶対に素晴らしいコストの話であり、SaaSに移行する100%の良い理由です。しかし、私はSaaSのコスト最適化の話はインフラを共有することだけではないと考えています。もしそうだったら、基本的に前のスライドで止めて、「ありがとうございました、素晴らしいショーでした、今日はこれで終わりです」と言えるでしょう。いいえ、インフラを共有している場合でも、この話にはもっと多くの動く部分があるのです。
アーキテクトとして考えてほしいのです。ビジネスパーソンとしてではありません。これはビジネスのように聞こえるかもしれませんが、技術的な話だと保証します。アーキテクトとして、インフラ費用を超えて考えてほしいのです。コストについて考えるときは、単に「AWSの請求書が先月より10%減ったから、コスト最適化は完了」というだけではありません。それで終わりではないのです。マルチテナント環境でコストを考える際、特に注目してほしい点の一つが成長をどうサポートするかです。SaaSデリバリーモデルに移行する全体的な考え方は、新しい市場や新しいセグメントにリーチし、ビジネスをより速く、より効率的に成長させることです。
効率的な成長と運用効率：SaaSコスト最適化の鍵
つまり、コストの観点から我々が試みているのは、従来のテナントごとのリソースで吸収していた余分なコストを吸収せずに、ビジネスが急速に成長できるようにすることです。そして、我々は確実にその方法に焦点を当てます。どうすればその効率的な成長を達成できるでしょうか？それが我々のストーリーの一部です。もう一つ、驚くかもしれませんが、全体的に見落とされがちな大きな部分は運用効率です。特に大規模なB2C SaaS企業を見て、彼らが構築したものや環境で運用しているテナント数を見ると、運用チームの少なさを誇りにしていることがわかります。
彼らは素晴らしいツールや構造を構築し、ビジネスの成長に合わせて運用チームをスケールできるようにしています。実際、これは最初の項目である効率的な成長にも繋がります。運用チームもその効率モデルに合わせたいのです。しかし、これは会計の括弧の反対側に置かれてしまうことがあります。つまり、運用チームがいて、予算に含まれ、誰かが支払っているけれど、コスト最適化のストーリーの一部ではない、というように。いいえ、それは大きな部分なのです。実際、SaaS環境では通常、運用チームと開発チーム、その他のチームの境界線がかなりぼやけています。
したがって、コストのストーリーを考える際は、運用チームの規模、チームをサポートするのにどれだけの労力が必要か、問題を見つけてトラブルシューティングするのにどれだけの労力が必要かを考えてください。それらすべてがこのコストのストーリーの一部なのです。そして、ここでもう一つ見落とされがちだと思うのは、環境内のワークロードを理解するという考え方です。すべてのテナントを平等にサポートしているわけではありません。多くの人が「システムを構築し、何らかのパラメータやシステムの次元の消費に基づいて構築すれば、それで完了。これでコスト効率が良くなった。消費が多ければ多く支払い、そうでなければ終わり」と言います。
しかし、それは通常、実際に裏で起こっていることの現実を本当には考慮していません。なぜなら、これから見ていく例でわかるように、システムにほとんど支払っていないのに、環境に大きなワークロードをかけ、インフラ費用を大幅に上げているテナントがいる一方で、プレミアムを支払っているのに、システムをほとんど消費せず、インフラ費用にほとんど寄与していないテナントもいるからです。環境内のワークロード、サポートしているテナントのペルソナ、そしてそれらが環境にどのようにコストを課しているかの間には、良い整合性がなければなりません。
これを意図的に追求する必要があります。もしこのテナントが本当にシステムを過剰に消費しているのに、それほど支払いをしていないのであれば、自分のアーキテクチャでどうすべきか考える必要があります。システムの過剰消費を防ぐために、どのような戦略を立てるべきでしょうか？これが重要な部分です。私にとって、これは明らかに効率性のゲームだと考えています。この話の終わりには「効率性」という言葉を使いすぎて飽きてしまうかもしれません。なぜなら、コスト最適化はインフラ費用の大きさだけの問題ではないからです。コスト最適化とは、ビジネスの成長に伴ってコストがどれだけ効率的に増加するかということなのです。
コストは依然として上昇しますが、ビジネスの成長に比例して、ビジネスにとって良い方向に上昇しているでしょうか？ここで簡単なグラフを使ってこの点を説明します。特に魔法のようなものではありません。収益を表すこの上の線を見てみましょう。「私たちはこれらの自動化に投資し、素晴らしいマルチテナンシーを実現し、新しい市場に進出できるようになりました」と言えるでしょう。
そして、ビジネスの成長が急激に加速しています。私がコスト戦略で正しいことをしたかどうかの本当の指標は、この下の線です。適切な運用メカニズムを構築できたでしょうか？アーキテクチャのスケーリング方法にコスト効率を適切に組み込めたでしょうか？ビジネスの成長に合わせて効率的にスケールできるよう、環境に必要なメカニズムをすべて組み込めたでしょうか？本質的に、新しいテナントを追加してもコストが比例して上がらないモードに到達することが目標です。これが効率性のテーマです。したがって、コスト最適化を単なる数字として考えるのではなく、パターンやテーマとして考えてください。
変動するワークロードへの対応：SaaSコスト最適化の課題
もう一つの側面は、変動性の概念です。テナントのワークロードが常に変化するという概念です。マルチテナント環境を考えると、常に新しいテナントが現れ、テナントごとにシステムの消費パターンが異なります。さまざまなワークロードとパターンが存在します。あるテナントはシステムの一部を他のテナントよりも多く消費し、あるテナントはストレージよりもコンピューティングを多く使用し、またあるテナントはAPIを集中的に使用しますが他はそれほどでもありません。システムの消費方法は多岐にわたっています。そして、これは今日の消費状況です。
明日この分布を見直すと、まったく異なる可能性があります。私にとって、コスト最適化の課題の大きな部分は、この変動にどう対応するかということです。これはビジネスにとって自然なことであり、実際ビジネスはこの変動をサポートしたいと考えています。しかし、どうすればこれを実現しつつ、優れたスケーリングモデルを構築できるでしょうか？どうすれば優れた回復力モデルを構築できるでしょうか？この動的なモデルをサポートしつつ、環境のコストを損なわずに、すべての基盤となるアーキテクチャをどのように構築すればよいでしょうか？
コストを気にしないのであれば、簡単に「はい、それらをサポートできます。最悪のシナリオに備えてオーバープロビジョニングすれば、すべてうまくいきます」と言えるでしょう。しかし、これは明らかにコスト最適化の観点からは良くありません。私にとって、この全体的な問題で人々が最も苦労しているのは、これらのワークロードの変動にどう対処するかということです。まず取り組むべき最も明白な領域は、テナントのアクティビティをどのようにしてリソース消費と連携させるかということです。これがこの道を歩み始める際の最優先目標ですが、唯一の目標ではありません。
ご覧の通り、これから運用やティアリング、その他の戦略についても触れていきますが、確かに最初の仕事は、テナントが私たちの環境をどのように消費しているかを見て、その消費がアクティビティにほぼ連携していることを確認することです。これは他の講演でも何度か示したグラフですが、これは私の理想的なアーキテクチャのバージョンです。究極のSaaSアーキテクチャを構築するとしたら、ここで青い線はテナントの消費を表しています。マルチテナント環境では、先ほど述べたような様々なワークロードがあるため、これは全体的に変動が激しく、グラフは毎日変化し続けるでしょう。
私の理想の世界では、本当に優れたアーキテクチャ、コスト最適化されたアーキテクチャを構築すれば、赤い線（これは実際にかかるコスト、つまりこの体験をサポートするためにプロビジョニングされるインフラストラクチャの量や必要なリソースの量を表しています）が青い線に非常に近く追従するはずです。青と赤の線の間のギャップは非常に小さくなります。これは、リソースをほとんどオーバープロビジョニングせず、テナントが必要とするだけのリソースを提供していることを意味します。そして、消費がゼロになれば、私の請求もほぼゼロになるという体験です。これが全てのSaaSアーキテクトの夢です。
しかし、これは全てのSaaSアーキテクトの現実ではありません。このダイアグラムを見せると、みんな「素晴らしい、これを実現しよう」と言います。サーバーレスの講演では、サーバーレスコンピューティングを使えばこれにかなり近づけることができる領域もありますが、現実はそうではありません。なぜなら、常に動的にスケールするわけではない様々なリソースを実行する必要があるからです。全てのリソースが望み通りに正確にスケールできるわけではありません。そのため、システムの一部がオーバープロビジョニングされたり、ギャップが予想よりも大きくなる領域が出てくるでしょう。それでも構いません。
これが現実の一部なのです。問題は、そのギャップをできるだけ小さくしようとしているかどうか、そしてギャップが必要以上に大きい場合は、それが必要だからなのか、環境に必要だと計算した結果なのかということです。そして、常に別の方法を探し続けています。実際、このグラフの何らかのバージョンを持っている多くの組織を訪れ、「これを修正できますか？」と尋ねられます。そして今、私たちは「何に移行できるでしょうか？どのテクノロジーに移行できるでしょうか？」と考えています。
インフラストラクチャの最適化：プール型とサイロ型の混在
では、この体験に近づくために、どのような戦略に変更できるでしょうか？私にとって、このインフラストラクチャの最適化はいくつかのカテゴリーに分かれます。ここで、コスト最適化が少し面白くなります。リソースがどのように環境にデプロイされるかについて、複数のモデルがあり得ます。
一つのモデルは、私が「プール型」と呼ぶものです。多くのコンテンツでご覧になったかもしれませんが、プール型とは、インフラストラクチャが多くのテナントによって共有されることを意味します。プール型環境がある場合、これらの共有リソースをどのように最適化するかという戦略全体があります。これは、より古典的な動的スケーリング、古典的な弾力性、多くの人が知っている古典的なモデルです。しかし、同じソリューション内の一部のテナントがサイロ、つまり専用環境で実行されているシナリオもあり得ます。
このモデル、特に「フルスタックサイロ」と呼ばれるものは、テナントが自身の完全なリソーススタックを持つことを意味します。なぜSaaS環境でこれを行うのでしょうか？ちなみに、人々はこれを頻繁に行っています。私が出会う多くのソリューションは、サイロ型とプール型が混在しています。なぜなら、あるテナントが「独自のシステムを実行させてくれるなら、十分な金額を支払う用意がある」と言ってくるからです。そうなると、私たちはそれを許可することになります。それでも、プール型環境のインスタンスですが、1つのテナントだけが使用することになり、異なるコスト最適化プロファイルを持つことになります。
複数のテナントが実行されている環境と比べて、このワークロードの最適化は非常に異なります。ここで実装する戦略、スケールへのアプローチが異なります。なぜなら、このサイロ型モデルでは、より予測可能な消費パターンがあるからです。アイドル状態のリソースについてより考える必要があり、スパイク的なリソースについてはあまり心配する必要がありません。プール型モデルで心配しなければならないことと、ほぼ逆のことを考える必要があります。
そして現実には、通常、完全にサイロ型かプール型かのどちらかではありません。サイロ型環境やプール型環境の中でも、実際にはサイロ型とプール型が混在しています。この例で、その点を強調すると、Webアプリケーション層がプール型で、マイクロサービスがサイロ型という環境があります。そして、ストレージレベルでは、サイロ型のものとプール型のものが混在しています。
このことを指摘するのは、インフラストラクチャだけのコスト最適化を考えるアプローチでは、これらすべての経験にまたがるポリシーと戦略を検討する必要があることを明確にするためです。行うべきことの範囲と複雑さは増しますが、これはSaaSアーキテクトとしてビジネスにイエスと言うことの一部です。サイロ化されたモデルをサポートできる、一部のリソースや一部のマイクロサービスだけをサイロ化し、一部をプールすることができる、そしてそれに対して良好なコスト最適化のストーリーを構築する方法を見つけ出すということです。
コンピューティングリソースの最適化戦略
私が言いたいのは、これらのどれを使っているか、あるいはどの組み合わせを使っているかに関係なく、すべてにわたってコスト効率を考えるべきだということです。ここでコンピューティングだけに焦点を当てると、これはおそらく皆さんが最もよく知っている分野なので、かなり手短に説明します。コンピューティングから良好なコスト最適化を得るにはどうすればよいでしょうか？ここで最も単純なのは、古典的な水平スケーリングです。
例えば、EC2上で動作している注文マイクロサービスがあるとします。その注文マイクロサービスにかかる負荷に応じて、EC2インスタンスをスケールアップするだけです。そして、過剰にプロビジョニングされたインフラストラクチャが大量に発生しないように、十分に効率的にそれを行おうとします。これは非常にオーソドックスなアプローチで、マルチテナント的な要素はほとんどありません。ただし、ここでのスケールの単位は注文マイクロサービス全体であることに注意してください。つまり、マイクロサービス内のすべての操作が、そのマイクロサービスの負荷に関係なく対象となります。負荷が大きくなりすぎると、より多くのEC2インスタンスをスピンアップする必要があります。
また、EC2の場合、スパイク的な負荷に対応してインスタンスをスピンアップするのは、他の技術と比べてやや遅い傾向があります。そのため、ここではより多くの過剰プロビジョニングを考慮する必要があります。スパイクに備えて、他の技術よりも準備を整えておく必要があるかもしれません。しかし、これは十分に有効なアプローチです。
一方、Lambdaを見てみると、同じ注文マイクロサービスを取り上げた場合、ここがサーバーレスの世界がSaaSの世界と完璧に一致する部分です。同じ注文マイクロサービスがあり、get orderとupdate orderの関数がありますが、環境内のスケールの単位は個々の関数です。現在の負荷がどうなっているかはあまり気にしません。明日の負荷がget orderばかりで、update orderがほとんどなく、翌日にはそれが逆転したとしても問題ありません。
気にしません。なぜなら、実際に消費した分だけ支払えばいいからです。これがサーバーレスの素晴らしさであり、SaaSにおいてサーバーレス、サーバーレス、サーバーレスと常に言う理由です。ここではポリシーを追いかける必要はなく、マネージドサービスにスケーリングを任せるだけです。どのようなコンピューティングインスタンスを選ぶかさえ気にする必要はありません。そういったことは全く関係ありません。私にとって、このモデルは運用の観点からもデザインの観点からも、多くの負担を取り除いてくれます。
マイクロサービスをどのように分解するか、適切なマイクロサービスを完全に把握しているかどうかを心配する必要もありません。なぜなら、実際にスケールする単位は、マイクロサービス内の個々の関数だからです。そのため、はるかに適しており、アイドル状態のコンピューティングについて心配する必要もありません。ただし、Lambdaがすべてのワークロードに適しているわけではありません。すべてのワークロードをLambdaに入れることはできません。つまり、一つのハンマーですべてを解決し、Lambdaで終わりというわけではありません。しかし、非常に適しています。これらの機能の多くを紹介するLambdaの優れたリファレンスアーキテクチャがあります。
そしてもちろん、コンピューティングについて話すなら、コンテナについて触れないわけにはいきません。確かにAmazon EKSはSaaSプロバイダーの間で非常に人気があり、また、LambdaとEC2の間の良い妥協点を表していると私は考えています。コンテナは非常に速く起動するからです。マルチテナント環境でスパイク的な負荷や変化するワークロードに対応しつつ、良好なコスト効率を得ることができます。明らかに、ここではより基盤となるノードとクラスターのスケーリングが重要になります。しかし一般的に、非常に優れたメカニズムを得られるので、迅速な水平スケーリングが可能で、通常はこの領域で過剰なプロビジョニングを行うことはありません。また、コンテナ環境の一部である素晴らしいツールにアクセスでき、環境に追加のコスト最適化をもたらすことができます。
例えば、cube costなどのツールを使用して、コストの可視化が可能です。また、テナントごとの名前空間の使用など、複数のデプロイメント戦略を利用できます。これらはすべてコスト削減モデルを実装するための異なるメカニズムです。ここで注目すべき点は、Fargateが言及されていることです。実際に、コンテナの世界にサーバーレスの良さを持ち込むことができます。「EKSクラスターの下にあるノードを気にせず、Fargateで実行し、基盤となるクラスターのスケーリング方法を心配する必要はない。ポリシーを書く必要もなく、基本的に環境のコンピューティングをすべてサーバーレスモデルに依存させる」ということができます。
つまり、ある意味で両方の良いところを得られます。コンテナを使いたい場合はコンテナを使えますが、Lambdaの経験の良さも得られます。まだ一対一だとは思いませんが、関数レベルの粒度はスケーリングにおいてより強力ですが、それでも非常に適しています。おそらくこれらのことは既にご存知だったと思いますが、ここで触れておく必要がありました。そして、EKSのもう一つの側面について触れたいと思います。私のチームのメンバーと話していたときに、コスト最適化戦略について話題になりました。そこで議論し始めたのは、例えばEKSでクラスター内で実行しているインスタンスのタイプまで最適化できるのかということでした。
例えば、EKSクラスターがあり、これらのノード上でポッドが実行されていて、そのノードがM5インスタンスで動作しているとします。なぜなら、そのタイプのワークロードにはM5が適しているからです。ここで、別のノードを追加して、そのノードを異なるインスタンスタイプで実行したいと言えるでしょうか？ 要するに、ここで最適化したいのです。 つまり、これは非常にコンピューティング集約型であるとか、この特定のマイクロサービスはM5ではなくGPUで実行するのが最適だと言えるのです。ここでのポイントは、実行時により細かいレベルでワークロードを適切なインスタンスタイプとマッチングさせることができ、それによってコスト最適化もさらに向上させることができるということです。
選択的サイロ化：コスト効率とコンプライアンスの両立
これはある程度まだ議論の余地がある点だと思います。本当にお金を節約できたことを証明するには、インスタンスタイプとワークロードの間で良好な一致を得る必要があります。明らかに、問題に対してGPUを無闇に投入するわけにはいきません。それはコストがかかるからです。しかし、GPUが適切なソリューションであり、そのGPUと同等のことを行うためにC5インスタンスをたくさんスケールアップしているのであれば、おそらくある時点でコスト削減が実現できるでしょう。少し飛躍した考えかもしれませんが、コンテナ環境でも、 実行しているインスタンスのタイプに至るまで、考慮すべき点だと思います。
ここでもう一つ注目すべき点は、システムの一部を選択的にサイロ化する方法です。時々、組織と話をすると、「一部の顧客がサイロを望んでいるので、彼らにはフルスタックサイロを提供しています」と言います。そして、「プールかフルスタックサイロのどちらかしか提供していない」と言います。サイロという言葉を聞いた途端に、「彼らは分離を必要としていて、コンプライアンス上の要件があるから、サイロに入れなければならない」と考えるのです。それが唯一の方法だと。もちろん、フルスタックをサイロに入れた瞬間、システムのコスト最適化の利点が失われ始めます。
その代わりに、私が言いたいのは、システムのどの部分をサイロ化する必要があるのかということです。なぜなら、システムが行うすべてのことの中で、彼らが主に懸念しているのはその一部であり、そのコンプライアンスや規制、あるいは分離の側面だけだからです。そこで、システムの一部だけを切り離してサイロ化し、リソースの一部をプールし、一部をサイロ化するミックスを提供できないでしょうか？
このようにすれば、特定のマイクロサービスだけがサイロ化され、私にとってはより良いコスト最適化のストーリーが得られます。なぜなら、システム全体を一括してサイロ化するのではなく、サイロ化が必要な部分だけをサイロ化しているからです。これは最も活用されていない機能の一つ、つまり人々が使うべきデザインパターンの一つだと思います。人々はますます、システムのサービスをどのように本当に分解するか、そしてビジネスのさまざまなニーズをより細かいアプローチでワークロードを分解することでどのようにサポートできるかを考えるべきだと思います。
ポッドベースの最適化：新たなスケーリングアプローチ
さて、これに対する別のアプローチとして、全く異なる角度から考えるものがあります。それはポッドという概念です。セルラーアーキテクチャに馴染みのある方もいるかもしれませんが、これが厳密にセルラーアーキテクチャと同じかどうかはわかりません。私たちはこれをポッドベースの最適化と呼んでいます。ここでは、コンピューティングを望むように正確にスケールさせる方法や、ストレージをコスト効率よくスケールさせる方法を考えるのではなく、テナントのグループを取り、それらをポッドに入れるのです。
つまり、初日に10のテナントがあり、それらのプロファイルがあるとします。これらを集合的にこのポッドに入れ、スケールの単位はポッドになります。テナントが実行しているすべてのものがポッド内にあり、そのテナントのためにポッドを可能な限り効果的にスケールする必要があります。しかし、スケールの単位は、ポッド内のすべての細かいノブやダイヤルを調整することではありません。ポッド自体が効果的にスケールする限り大丈夫です。ちなみに、これはある程度影響範囲も制限します。なぜなら、これらのテナントは互いにしか影響を与えられないからです。
そして、そのポッドの限界に達したと判断したら、もうそれ以上拡張したくないと思います。うまく調整できたので、別のポッドを立ち上げ、次のラウンドのテナントをそのポッドに入れます。ここでポッドがスケールの単位になります。今度は、ポッドに基づいて水平方向にスケールします。しかし、ここでコスト最適化されたスケール方法を見つけるための労力とエネルギーは、すべてのテナントのアーキテクチャ全体を同時に考えるのではなく、ポッドレベルでより集中します。実際、ポッド1とポッド2で別々のスケーリング戦略を持つこともできます。
テナントをポッド間で移動させることもできます。例えば、ポッド2のテナントが突然すべてを飽和させ、急に異なるプロファイルになったとします。そのテナントを別のポッドに移行し、それでもポッドをスケールの単位として維持できます。これには長所と短所があります。すべてを単純化するように聞こえるので素晴らしく思えますが、実際にはオペレーションをやや難しくします。なぜなら、このような分散したポッドをどのように成功裏に運用するかを考える必要があるからです。デプロイメントもここでは少し厄介です。考慮すべき点は確かにありますが、検討する価値はあります。
また、マルチリージョンを考えている場合、より大きなグローバルフットプリントを持つ場合には、これはマルチリージョンに移行したい人にとって自然な出発点になり得ます。なぜなら、ポッドを使用して個々のリージョンにデプロイできるからです。すでにポッドという概念があれば、リージョンへの移行はそれほど大変な作業ではありません。
ストレージのサイズ調整：SaaSにおける難題
さて、最も難しくて、私が一番話したくないのが、ストレージのサイズ調整です。なぜなら、Amazon RDSや他の仕組みを使っている場合、テナントがあり、これらのテナントには複数のワークフローがあります。例えば、この場合、プールされたマイクロサービスのようなものがあり、そこにRDSインスタンスがあります。RDSインスタンスを設置する際、コンピュートサイズを選択せざるを得ません。
どのサイズを選ぶのが正解でしょうか？消費量がXかYになると予想しますが、いずれにしても多少のオーバープロビジョニングを含めて、何らかのサイズを選ぶ必要があります。これは1つのテナント用であり、この例ではサイロ型です。ここでは消費量をある程度推測できるかもしれません。そして別のテナントがあり、別のサイロで、そのサイズも選ぶ必要があります。そして、プールモデルで動作しているテナントがあり、ここで何をすべきか全く分かりません。つまり、初日にはどうしてもインスタンスのサイズを大きめに設定せざるを得ません。コスト最適化を目指す組織にとって、特にRDSの場合（RDSを例に挙げていますが、コンピュートインスタンスを選択する必要のあるサービスは多くあります）、そのようなサービスでは、特定のコンピュートインスタンスサイズを割り当てる際、プロファイルが変化したときにどうするかを考えなければなりません。
特にコスト最適化に関して言えば、例えばテナント1のワークロードが増加した場合、より大きなインスタンスサイズに移行する必要があるかもしれません。テナント2の場合、ワークロードが減少したら、移行するでしょうか？そうなると、DevOpsツールを作ることになります。私が以前働いていた組織では、コストを調整するためだけにRDSインスタンスのサイズを変更する作業を専門に行うチームがありました。これを多数のテナントに適用すると、どれほど問題になるか想像できるでしょう。
時間の経過とともにこのサイクルがどうなるか想像してみてください。テナント1のワークロードが減少し、数ヶ月間そのままだったら、サイズを小さくしましょう。そして時間が経つと？プール環境が変化します。この問題全体を解決する単純な「Xをすれば良い」という方法がないため、私はこの解決策があまり好きではありません。これは考えなければならない現実の問題です。後ほど戦略について話しますが、この問題に直面することは避けられません。無料トライアルなどの場合は、無料環境での負荷を制限するなど、対策を講じることができます。しかし、これはコストを追跡するのが難しい領域です。
この方向に進むのであれば、serverlessが最適な方法だと私は考えています。存在する様々なストレージサービスを見ると、Auroraがあります。Auroraを使用することも可能です。ただし、Aurora MySQLがRDS MySQLで行っていたことと全く同じことができるかどうか、細かい部分まで確認する必要があります。マッピングを行って、すべてが揃っているか確認しなければなりません。しかし、良いニュースは、これらのストレージサービスがserverlessの概念をますます取り入れていることです。なぜなら、その価値と重要性を認識しているからです。SaaSソリューションのストレージに対して、どのインスタンスサイズを選ぶべきか考えたくありません。消費した分だけ支払い、運用チームが常にRDSインスタンスのサイズを追いかけ回す必要がないようにしたいのです。
このようなモデルはストレージだけでなく、他の分野にも適用できるというのも良いニュースです。例えばメッセージングを例に取ってみましょう。 メッセージングの分野でも、多くの優れたサーバーレスの要素があります。私がこの問題で苦労しているお客様と話をする際、最初に尋ねるのは「サーバーレスモデルに移行する可能性はありますか？」ということです。自己管理型のシステムを使用している場合、この問題はさらに難しくなります。なぜなら、インスタンスタイプだけでなく、自己管理に伴う他の運用上のオーバーヘッドにも対処しなければならないからです。
スケールに関するこのセクションの最後のスライドは、私が強調したいものです。消費とコストを整合させる際に考えるべき主要なテーマは何でしょうか？どうすればそのグラフに到達できるでしょうか？明らかに、一つの戦略だけではなく、複数の戦略の組み合わせが必要です。確かに、効率的なリソース消費が望ましいです。つまり、実践的に達成可能な範囲で、必要なリソースを必要なタイミングで確保することです。これはすべてに適用できるわけではありません。また、システムの分割方法や展開方法も検討する必要があります。どのような展開パターンがあるでしょうか？何が分離されていて、何が共有されているでしょうか？より費用対効果の高い体験を得るために、システムをどのように分解できるでしょうか？
そして最後に、このエクスペリエンス全体でスケーリングポリシーの作成にどれだけの労力とエネルギーを費やしているかを考える必要があります。今日のスケールを決定するのに多大な時間を費やしていませんか？最悪のシナリオは、運用チームが日々常に調整を行っている状況です。「今日はXで苦戦しているから、システムのこの特定の部分のスケーリングポリシーを書き直そう」というような具合です。このように常に追いかけっこをしているような状態では、組織として効果的にスケールすることはできません。そのため、安定していて、成長に合わせて拡張できる戦略を選択してください。
運用効率の重要性：SaaSコスト最適化の隠れた側面
冒頭で運用について注目すべき分野として言及しましたが、ここで皆さんは「ああ、そうだね。でも、私たちはそれを気にしていない」と思うかもしれません。私は多くの組織で、運用効率の重要性について話をしてきました。彼らは「はい、メトリクスが必要です。分析が必要です。インサイトが必要です。チームの効率を上げるためにこれらすべてが必要です」と言います。しかし、私が去って6ヶ月後に戻ってくると、それらを構築するための何の対策も取られていないのです。その理由は分かります。機能や基本的なスケール、環境が優先されるのです。しかし、私に言わせれば、ビジネスとコストについて議論するのであれば、この点について話し合うべきです。アーキテクトとして、そして場合によっては運用チームと協力して、この投資がいかに重要であるかを彼らに理解させるのが、あなたの仕事かもしれません。
実際、先ほどのグラフを見てみましょう。 将来を見据えて、収益を金色で示し、コストを分解しました。下部にインフラストラクチャコストがあります。
インフラのコストを抑えることができれば、請求額は下がり、適切なペースで増加していきます。インフラから素晴らしいコスト効率を得られているのです。しかし、運用にはほとんどエネルギーを費やしていません。運用のコストと経費を見てみると、運用のオーバーヘッドが収益とほぼ同じペースで増加していることに気づきます。これでは、ビジネスにとって本当の意味でのコスト効率を達成できていません。新しいテナントが加わるたびに、新たなオーバーヘッドが発生しているからです。
デプロイメントの複雑さ、自動化の複雑さ、あるいはマルチリージョンが関係しているかもしれません。または、マルチテナント環境で何か問題が発生したときに、何が起きているのかを把握するための適切なツールがないのかもしれません。いずれにせよ、この状況をコントロールするために何かしなければならないという事実に注目する必要があります。そして、運用のスケーリングと言うときに、私が意味しているのは何でしょうか？これは非常に漠然としたものになる可能性があります。なぜなら、優れた運用を実現するために「Xをしなさい」や「Yをしなさい」といった具体的な指示はないからです。
しかし私にとって、運用チームに対して尋ねる質問があります。例えば、特定のタスクを実行するのがどれくらい難しいか、どの程度の可視性があるかなどです。そして、その可視性はどこから来るのでしょうか？それはあなたがアーキテクチャに組み込んだものから来ています。運用チームは、スケール、分離、デプロイメントの自動化についての可視性を持っていますが、それは限られています。そして、彼らが本当に充実した運用体験を作り出すために必要な情報を組み込むのは、あなたの仕事なのです。
では、問題が発生したときに事前に知らせてくれるアラートや警告はありますか？問題のトラブルシューティングはどれくらい難しいでしょうか？システムに問題があり、テナントから「システムのこの部分が今動作していない」という連絡があった場合、運用チームがログを調べ、すべてのメカニズムを確認して「ああ、3時にこれが起こって、3日かけてログを見れば、最終的に何が問題だったかわかる」というのでは大変です。そうではなく、テナントのコンテキストでログを見たい、特定のサービスがテナントやティアのコンテキストでどのように消費されているかを見たいのです。
一般的に、私には運用体験が本当に良好で、運用が効率的に行われていることを示す多くの質問があります。これは主観的なものですが、それでも目標にはなります。つまり、私が言っているのは、この作業を行う必要があるということです。これは環境を計測することを意味します。そしてここで壁にぶつかるのです。誰かが「X個の機能があり、X量の新規ビジネスを競っている」と言うでしょう。そして、product ownerや開発チーム、あるいは運用の誰かが「テナントがあなたの環境をどのように消費しているかについての良い可視性がありません。新しくリリースしたい機能を誰が消費しているのか、どのように消費しているのか、あるいはそもそも消費しているのかさえ、あなたに伝えることができません」と言うのです。
これを実現する唯一の方法は、誰かがバックログに入れることです。つまり、これらのメトリクスに投資し、これらのメトリクスと分析、可視性を機能と同じくらい重要なものとして扱う必要があります。長期的にはこれは報われますが、まずはメトリクスとその実現方法を理解する必要があります。もう一つ明らかなのは、ログにテナントのコンテキストを織り込む必要があるということです。ログにはあらゆる種類のテナントコンテキストが必要です。 そうすることで、1時にテナント2で何が起こったのかを見たときに、テナント2に関することだけを確認できます。
そして、「ああ、このマイクロサービスで問題が発生していたんだな」と気づいたら、2時のマイクロサービスXのスケーリング状況を確認できます。そこで、予期していなかった特定のワークロードが発生していることがわかります。チームがこれを素早く行えれば、テナントの問題を先回りして解決できるだけでなく、はるかに効率的になります。より良いツールがあるので、少ない人数で対応できるのです。私にとって、これはすべてダッシュボードに関することです。下手な絵ですが、マルチテナント固有の運用ダッシュボードを持つことが重要です。 はい、AppDynamics、New Relic、Datadogなど、素晴らしいツールがたくさんあります。これらを引き続き使用してください。
しかし、それらを使用しても、システムのマルチテナントビューとして どのようなビューが必要かを考える必要があります。リソースがどのように消費されているか、環境にどのような負荷がかかっているかを示すマルチテナントビューです。マルチテナントのアラートや警告はどこにありますか？ 単に全体的にコンピューティングがこのように消費されている、メモリがこのように消費されているというのを見るだけでなく、どのテナントが何をしているかを見たいのです。これらのツールを使うか、GrafanaやQuickSightなどを使って、独自のダッシュボードを構築してください。これらのツールの組み合わせで、必要なビューを得られるようにしてください。運用チームがこれらを手元ですぐに利用できるようにしたいのです。
テナントのワークロード理解とティア別スロットリング
これらのツールなしでその仕事をすることを想像してみてください。はるかに難しい仕事になり、ビジネスのコスト効率を損なうことになります。では、これをどのように測定できるでしょうか？ 漠然としたままにしたくないので、いくつか例を挙げたいと思います。確かに、運用の一環として知りたいのは、テナントがどれくらい速くシステムにオンボードできるかということです。
これは見落とされがちな重要な指標です。 通常、チームはアプリケーションインフラ全体をスケールさせ、それをうまく機能させます。しかし、明日100のテナントが現れてオンボーディングプロセスを通過したらどうなるかと尋ねると、オンボーディングプロセスは効果的にスケールするでしょうか？ 運用チームはそのスケーリング状況を把握できるでしょうか？ そして、ビジネスサイドはオンボーディングの容易さを把握できているでしょうか？ 適切な自動化とツールがあれば、非常に効率的でコスト効果の高い体験になります。
デプロイメントの効率性についても見ていきたいと思います。デプロイメントは特にサイロモデルやプールモデルでは難しい場合があります。新しいバージョンのソリューションをロールアウトするとはどういうことでしょうか？そのロールアウトはどれくらい効果的に行われたのでしょうか？平均故障間隔はどれくらいでしょうか？不具合がどれくらいの速さで発見されているでしょうか？これらは全て知りたいことです。さらに、テナントのライフサイクルに関する指標も重要です。更新時期が近づいているテナントをどのように把握しているでしょうか？これはSaaSのカスタマーサクセスの部分と運用が接する部分です。テナントが基本プランからプレミアムプランへと、システムの異なるティア間を移動する様子をどのように把握しているでしょうか？このためにどのようなツールを持っているでしょうか？SaaSで最も難しい部分の1つはティア間の移動で、これは本当に難しい問題です。そのための優れたツールやメカニズムを持っているでしょうか？それとも、ユーザーを移行するのに運用チームの4人が1週間かかるのでしょうか？それはあまりコスト効率が良くありません。
必ずしもこれらの指標だけに注目する必要はありません。私がこれらを挙げたのは、運用の話に指標を結びつけることで、優れたツールやメカニズムを持つことの重要性とコストへの影響をより明確にできると考えているからです。また、テナントのワークロードやプロファイル、システムの使用状況も見る必要があります。これは投資が不足している分野だと思います。多くの人は、初日にテナントがどのようにシステムを使用するかを知っていると思い込み、それがコストの全てだと考えています。テナントのペルソナについて難しい質問を自問することに投資しない人は、しばしば課題に直面することになると私は感じています。
例として、AWSに入る前に私が携わったeコマースソリューションの話をしましょう。これは非常に成功したeコマースプラットフォームで、大規模なテナントプールと多くのアクティビティがありました。しかし、システムのコストがビジネスの収益を侵食していました。テナントが私たちの環境をどのように使用しているかを本当に教えてくれる指標がありませんでした。そこで、3つの異なる方法で消費をプロファイリングしました：異なるティアのテナントがインフラコストにどのような影響を与えているか、ビジネスにどれだけの収益をもたらしているか、そして彼らの製品カタログの規模です。
基本ティアでは、テナントは私たちに50ドルを支払っているかもしれません。一方、上級ティアのテナントは5,000ドルを支払っているかもしれません。私たちの収益は、彼らのサイトでの取引数に基づいて、ある程度彼らの収益と連動していました。基本ティアのテナントのデータを見ると、彼らは巨大なカタログを持っており、時には何百万もの製品を販売していました。彼らは私たちの環境のAPIを適切に使用する方法を知らないことが多く、そのため私たちのインフラに大きな負荷をかけていました。しかし、実際にはあまり多くの製品を売っていませんでした。私たちにとっての彼らの収益は低かったのですが、インフラコストは非常に高かったのです。
一方、上級ティアでは、本当に小さな、焦点を絞ったカタログを持つテナントがいました。彼らは本当に上手に販売できる少数の製品を販売し、大量の収益を生み出していましたが、私たちにとってのインフラのオーバーヘッドはあまり大きくありませんでした。このような状況を見て、コスト最適化を考えると、ビジネスにかけているコスト負荷が、生み出している収益と逆相関になっていることがわかります。そのため、環境にかける負荷と彼らが得ている体験の間でより良いバランスを生み出すティア構造を作るために、何をすべきかを考える必要があります。
ここで完璧なバランスを取ることは不可能です。 しかし、明らかにこの問題に対処する一つの方法は、ティア別のスロットリングです。ここで私たちがお勧めするのは、これらのテナントがあなたの環境をどのように消費できるかに明確な境界を設けることです。 ここでは、Basic、Standard、Platinumティアのテナントがあります。これらはすべて私の環境に入り、API gatewayにある数のリクエストを送っています。
そして、ここで私が行うこと（これは私たちのLambdaリファレンスアーキテクチャから直接取られています）は、これらの各ティアのAPI keyに使用プランを関連付けることです。使用プランは基本的に、Basicティアではこのレベルで消費できる、Platinumティアではこのレベルで消費できる、というように定義します。これらのティアは異なる体験をすることになります。例えば、毎日100万個の商品をカタログにアップロードしたいと考えている人は、おそらくBasicティアではスロットリングされるでしょう。なぜなら、過剰な負荷をかけているからです。そしてもし、その状況でスロットリングされて不満を感じ、カスタマーサポートに電話をかけて「100万個のカタログ部品をアップロードできない」と言ってきたら、「それをするにはPlatinumティアに上がる必要がありますよ」と答えることになります。これは、彼らがあなたの環境をどのように消費しているかを管理する明確な方法であり、それが経験の幅を生むことに罪悪感を感じる必要はありません。それがティア制の意図であり、コストのバランスを取るための全ポイントなのです。
テナントペルソナのモデル化：コスト予測の基礎
もう一つのアプローチとして、別のモデルを紹介します。申し訳ありませんが、これは少しLambda寄りの話になります。ここでは、API gatewayを使う代わりに、Lambda functionsの同時実行数の消費に焦点を当てています。ここでは基本的に、BasicティアにはそこにデプロイされたLambda functionsで処理できる100の同時リクエスト、Advancedは300、Premiumは残りすべてを割り当てることができます。これもまたスロットリングに関するものですが、スロットリングを適用する異なる方法です。これを含めたのは、使用している各スタック、各ツールチェーンにはこれを行う異なる方法があることを理解してほしいからです。しかし、ほぼすべてのツールには、何らかの形で体験をコントロールする方法があります。
ここにAmazon EKSの例も含めました。 テナントのnamespaceを作成し、それぞれに異なるresource quotaを関連付けることができます。これらの異なるresource quotaは、基本的にテナント1がBasicティア、テナント2がAdvancedティアといった具合に、異なる体験を定義します。そこで、これを理解するために人々に勧めていることの一つは、テナントのペルソナをモデル化することです。 私はテクニカルチームとビジネスチームに座ってもらい、「消費の基本的な見方はどうですか？最初の1年でシステム内にBasic、Advanced、Platinumティアのテナントをそれぞれどれくらい見込んでいますか？そして、それらのテナントの消費活動はどのようなものになると予想していますか？一般的に、彼らはシステムをどのように使うと予想していますか？負荷はどのくらいになるでしょうか？そして、そのモデルに関連する予想される利益とコストはどのくらいでしょうか？」と尋ねます。
繰り返しになりますが、SaaS環境にTCO（Total Cost of Ownership）の概念はありません。人々は「SaaS環境を構築する前にTCOを教えてください」と言いますが、私にはわかりません。なぜなら、それは動的であり、すべてシステム内のテナントの数に基づいているからです。ある日のコストは翌日のコストとは異なります。そのため、私たちにできる最善のことは、モデル化し、そのモデルが望むものと一致するかどうかを確認することです。そして、それを1年先に投影し始め、「Xだけ成長したらどうなるか？1年目にBasicティアはどれくらい成長するか？Advancedティアはどれくらい成長するか？Platinumはどれくらい成長するか？そして、それが消費プロファイルをどのように変化させるか？そして、それが基本的に利益にどのような影響を与えるか？私たちはそれを好むかどうか？」と考えます。
私たちのティアが、システムの使用方法に基づいて適切でないことに気づくかもしれません。境界線を間違った場所に引いてしまったのです。そこで、この考えを基に複数年のパスを作成するよう人々に伝えます。消費パターンがXだった場合、このようになり、コストにこのような影響を与えるでしょう。消費パターンがこのトレンドに従うなら、 このようになります。これは、コストに関する絶対的な基準がない環境でコストを予測するために、ビジネスに戻る方法です。 また、適切なペルソナとプロファイルを持っているか、期待するワークロードを把握しているかを確認する方法でもあります。最悪のケースは、これらを計画し、ティアを設定したのに、テナントが予想外の方法でシステムを消費することです。これは必ず起こりますが、少なくとも可能な限り考え抜いて、ワークロードがどのようなものになるか、境界線をどこに引くべきかを予測しようとしたのです。境界線を設定しないことが、この問題の難しい部分です。
テナントレベルの消費測定：SaaSコスト最適化の要
さて、最後に重要なのは、これらのことを行う場合でも、自分たちが何をしているかを測定する必要があるということです。ここで私たちが本当に望むのは、先ほど話した運用側のコスト効率をいくつかの指標で測定することです。
しかし、一般的にビジネスにとっては、テナントレベルの消費をどのように測定できるかを知ることが重要です。最近出会うすべてのビジネスが、テナントあたりのコスト指標をどのように得られるかを尋ねています。テナントあたりのコストを知るために必要なデータをどのように取得できるでしょうか？答えは、特にプールされたリソースを使用している場合、難しいということです。リソースがテナント間で共有されている場合、複雑になります。
コストを従来のインフラストラクチャの観点から見て、Amazon ECS、Amazon RDS、RDSのストレージにいくら支払っているかを確認すれば、それらの個々のリソースのコストを判断できます。しかし、マルチテナント環境では、複数のテナントがそのECS環境やRDS環境を消費し、ストレージ内のデータを共有しているため、AWSの請求書から直接得られるコスト単位では、テナントあたりのコストを把握できません。代わりに、テナントがあなたの環境をどのように消費しているかの近似値を得る必要があります。
環境に、異なる指標をキャプチャして公開するためのツールやメカニズムを組み込む必要があります。例えば、「テナントが今ECSを消費しており、この操作を実行している」というようなメトリクスを公開し、それらを集計して割り当てを行います。システム全体をカバーする必要はなく、超精密である必要もありませんが、このデータがなければ、インフラストラクチャの消費ラインや、eコマースソリューションの数値が何であるかを知ることはできません。
AWSから毎月請求書を受け取って、すべてが問題ないと思い込むのは避けるべきです。一部のテナントが予想以上にシステムを消費し、過剰なコストを発生させている一方で、他のテナントが予想外に消費を抑えていることに気づくかもしれません。少し持論を述べさせていただくと、ビジネス側にこの重要性を理解してもらう必要があります。これはソリューションの価格設定方法にまで影響を与えるべき価値があるのです。
もちろん、次のステップはその消費を請求書と照らし合わせ、両者の関係を把握することです。これには多くの要素が絡んできます。私はこのトピックだけで丸々1回分の講演をしたこともありますが、コスト最適化について語る上で、コスト効率化には測定も含まれることを強調しないわけにはいきません。インフラの各要素を測定する必要があるのです。
他のソリューションも検討することをお勧めします。このスペースでは、パートナーソリューションも登場し始めています。先ほどKubecostに触れましたが、Cloud Zeroもコスト追跡に興味深いアプローチを提供しています。私が最後にこの話をしてから、おそらく多くのツールが登場していると思いますが、それでも核となるデータを取得するための投資は必要です。
SaaSコスト最適化の要点：効率性、ティアリング、測定
では、いくつかの要点をまとめて締めくくりましょう。ここまでで、コスト最適化とコスト効率化の違いがおわかりいただけたと思います。SaaSビジネスを構築するアーキテクトとして、私の仕事は単に優れたアーキテクチャを構築することではなく、SaaSビジネスを成功に導くことだと考えています。そのアーキテクチャを効率的にスケールさせ、異なるワークロードやデプロイメントモデルをサポートし、コストを妥協することなく、ビジネスがより多くのセグメントや市場にリーチするために必要なツールを提供できるように、変動に対応する方法を見出す必要があります。実際、成長とともにスケールのメリットを得られるはずです。
また、すべてのスケール問題を解決する万能のソリューションは存在しないことも明らかでしょう。コンピューティングスタック、デプロイメントモデル、環境、コンプライアンスモデル、規制モデル、そして移行なのかゼロからの開始なのかによって、コスト最適化へのアプローチは異なります。 そして、インフラはパズルの一片に過ぎないことがおわかりいただけたと思います。インフラコストに多くの時間を費やすことになりますが、運用面にも注目し、構築したアーキテクチャに基づいてビジネス全体のコストプロファイルがどのように反応し、応答するかにも焦点を当てるべきです。
コスト最適化戦略の一部としてティアリングの重要性を過小評価しないでください。ティアリングは単に製品に対して異なる金額を請求する方法ではありません。これはコスト最適化を推進し、テナントの行動とアクティビティを彼らが消費しているリソースの量と一致させるために使用される戦略です。これらが一致していない場合、私のコスト最適化の全体像が損なわれる可能性があります。
最後に、測定、測定、測定です。これらのことを行っても測定しなければ、成功しているのか失敗しているのか全くわかりません。具体的なデータは、チームの他のメンバーにあなたの主張を伝え、トレンドを示し、課題を明確に説明するのに役立ちます。おそらく、運用へのより良い投資の必要性や、取り組んでいる作業の優先順位の見直しなどです。これらすべてが重要なポイントです。
re:Inventの関連セッションと締めくくり
今日はre:Inventの最初の部分に過ぎません。いくつかのSaaSセッションが行われています。私も他のセッションを行っています。興味がある方は、ここにブレイクアウトセッションのリストがあります。AI/MLの良いセッション、コスト最適化のチョークトーク、ワークショップ、ビルダーセッションがあります。そして、これらを最後にもう一度表示します。誰かが見たい場合のためです。
以上です。このセッションが価値あるものであり、皆さんがここに来た目的に合致していることを願っています。そして、残りのre:Inventも素晴らしいものになることを願っています。どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion