re:Invent 2023: AWS SaaS Factoryが語るSaaSアーキテクチャの落とし穴と解決策
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - SaaS architecture pitfalls: Lessons from the field (SAS305)
この動画では、AWS SaaS Factoryのシニアソリューションアーキテクト、Bill Tarrが、SaaSアーキテクチャの落とし穴について解説します。テナント分離、ノイジーネイバー問題、コスト管理、DevOpsプラクティス、カスタマイズvs設定など、実際の顧客事例を交えながら具体的な課題と解決策を紹介。SaaSプロバイダーが陥りがちな技術的負債を避け、スケーラブルで効率的なSaaSソリューションを構築するための貴重な洞察が得られます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
SaaS Factoryが学んだSaaSアーキテクチャの落とし穴
さて、皆さん、始めましょう。まず、皆さんに感謝したいと思います。re:Inventの最終日だということは承知しています。おそらく、皆さんにとって参加できる最後のセッションでしょう。今日、時間を割いて参加してくださってありがとうございます。今日は、SaaSのアーキテクチャに関する落とし穴について話します。これは、私たちのチーム、 AWS SaaS Factoryが、ここ数年間で何百ものSaaS企業と協働して学んだ教訓です。これらの教訓は、様々な段階や種類の企業にわたっているので、皆さん全員にとって何か得るものがあるはずです。
では、SaaSの約束から始めて、すぐに本題に入りましょう。あ、そうそう、私はBill Tarrです。AWS SaaS Factoryのシニアソリューションアーキテクトです。まずはSaaSの約束から始めて、SaaSを構築する際に期待されることについて話しましょう。私にとって、それはアジリティと柔軟性から始まります。 開発背景をお持ちの方は、すぐに「ああ、アジャイル手法のことを言っているんだな」と思われるかもしれません。しかし、SaaSの場合、それが本質ではありません。私たちが目指しているのは、組織のアジリティです。市場間、地域間を移動し、市場条件の変化に容易に適応できる製品を構築する能力について話しています。
そのアジリティは、アジャイル手法で考えていたのと同じ意味でも現れます。つまり、急速なイノベーションを提供する能力です。SaaS製品を構築している場合、顧客に継続的に価値を提供することができます。私たちは、顧客が四半期ごとや月ごとのリリースを期待するのではなく、新しいリリースや機能を継続的に目にすることで、プラットフォームに満足し、解約率を減らすポイントに到達したいのです。これらすべては、単一のビュープレーンを通じてすべてのテナントのためにプラットフォームを運用できるという利点と責任の両方をもたらします。これを「シングルペインオブグラス」と呼ぶこともありますが、すべてのテナントとその体験を見ることができ、比較的少人数のチームで比較的低コストでそれらの体験をその場で調整できる能力のことです。
私たちは長年、SaaSを成長モデルとして語ってきました。 2023年は多くのSaaSプロバイダーにとって非常に興味深い年となりました。多くの経済的課題が私たちの状況を変えました。最近では、持続可能な成長という観点で成長を考えるようになってきています。投資家、ステークホルダー、そして経営陣は、私たちが構築しているものが実際に時間とともに収益を上げるようになることを証明するよう求めています。つまり、新しい企業を獲得し、ロゴを増やすだけでは十分ではありません。代わりに、私たちが構築しているものが収益性があり、時間とともにそれらの顧客を成長させ続けることを証明しなければなりません。
もちろん、それにはコスト効率が関係します。コスト効率の良いSaaS製品を構築していなければ、長期的に成功する運営はできません。したがって、コスト効率に焦点を当てる必要があります。しかし、SaaSの場合、その約束は単に収益のためのコスト効率ではありません。むしろ、プラットフォームの構築方法におけるコスト効率であり、それが今日お話しする内容の一つです。すべてのSaaSの旅は個別のものですが、私たちはこれを一連のステップとして考える傾向があります。 そして、落とし穴もそれらのステップに分類されます。
SaaSの構築段階と継続的な最適化の重要性
SaaSの構築を検討する際、まず最初に行うのが構想段階です。我々が構築しようとしている製品とSaaSの提供モデルに適合性があるかどうかを考え始めます。あるいは、別の提供モデルの方が適しているかもしれません。SaaSへの投資に見合うだけの十分な顧客や市場規模がないかもしれません。我々のチームは、顧客と話をして、SaaSを構築する際に、単に次の大きなトレンドだと思って構築するのではなく、SaaSの価値提案を理解し、顧客が製品から得られる価値について明確なアイデアを持っていることを確認しようとします。
設計段階でも同様のことが起こります。ホワイトボードにマーカーで描き始めると、多くのソリューションアーキテクトが部屋に集まります。これも多くの落とし穴が生じる可能性のある領域です。ホワイトボードに描いたり、何を構築するかを考えたりする際には、十分先を見据え、顧客が我々に求めるものについてのロードマップを持つ必要があります。顧客がどの市場や地域にいるかを考慮し、開発の後期段階で発生する可能性のある技術的負債を回避するための計画を立てなければなりません。
そしてもちろん、構築段階です。製品を構築する際、顧客が期待し、我々が約束しているものを本当に構築しているでしょうか？セールスチームがこの製品を顧客に販売する際、SLAについてどのような約束をしているでしょうか？パフォーマンスに関する期待はどのようなものでしょうか？顧客にとってのその体験がどうあるべきか、顧客が我々の製品をどのように消費することを期待しているかについて、本当に十分に考え抜いているでしょうか？
製品の運用段階は、おそらく最も興味深い段階の一つかもしれません。運用は、SaaS製品において最も多くの時間が費やされる部分です。もちろん、構築には6ヶ月から12ヶ月かかりますが、その後は永遠に運用し続けなければなりません。そのため、効率的に運用する方法、繰り返しの作業を続けることなくチームが維持できる製品を作る方法を考える必要があります。構築したものすべてを自動化する方法を検討しなければなりません。
製品を継続的に最適化し、改善し続ける必要があります。単に構築して運用するだけでは十分ではありません。時間の経過とともに行ったすべての決定を再検討し、顧客が求めているものをより深く理解し、もちろん、コストプロファイル、運用プロファイル、そして構築したもののセキュリティについても継続的に改善していく必要があります。
SaaSの約束と俊敏性・柔軟性の実現への挑戦
さて、私はこのスライドを見て、SaaSの具体的な約束に挑戦するいくつかの要素について考えてみました。それはエンビジョニングの段階から始まります。 私たちはしばしば、顧客プロフィールについて考える時間を取りません。どのような種類の顧客がいるのか？アプリケーションを使用する役割は何か？彼らはどの業界で、どの地域にいるのか？これらすべてのことを事前に考慮しなければ、俊敏性と柔軟性を達成することはできません。代わりに、顧客が私たちのところに来て、「実は、HIPAAコンプライアンスが必要なんです。それにはどのくらい時間がかかりますか？」と言われて驚くことになります。SaaSで約束された俊敏性と柔軟性を達成したいのであれば、これらの問題に先手を打って対応する必要があります。
私たちが構築しているものをエンビジョニングする段階では、ソフトウェアの単一バージョンを維持するという考え方を持つ必要があります。これは、特にSaaSの初期段階で多くの人が見落としがちなことです。プロダクトマーケットフィットに向かい、製品が本当に成功し、顧客に採用されるかどうかを見極める過程で、時には譲歩しなければならないこともあります。しかし、すべての顧客に対して単一のバージョンを運用することが目標であるという視点を維持しなければ、SaaSの約束であった迅速なイノベーションには決して到達できません。代わりに、開発者たちは個々のテナントのために構築したさまざまなバージョンのソフトウェアの運用にますます引き込まれ、プラットフォームの成長がますます困難になっていきます。
先ほど話した運用の卓越性、つまりoperational excellenceに投資しなければ、それは人的プロセスになってしまいます。個人がオンボーディングプロセスに巻き込まれ、アカウント間を行き来して異なるテナントの経験を理解しようとする状況に陥ります。そして、SaaSの目標である顧客に価値を提供することに集中するチームを持つ代わりに、運用に投資するチームができてしまい、それがどんどん遅くなり、チームはどんどん大きくなり、彼らがやっていることは報われず、顧客にも報われず、顧客に価値を加えることもありません。
私たちはSaaSの約束の一つとして持続可能な成長を挙げました。ですから、ターゲットを絞った成長戦略を持たないこと、製品をどのように成長させるかを理解せず、このエンビジョニングの段階で先を見越して考え、どのようなロゴ（有名企業）にアプローチしたいのか、ターゲット業界以外で将来この製品が対応できる可能性のある業界は何かを考えることが重要です。製品をどのように成長させるかを先取りして考えることは、製品をエンビジョニングする重要なステップです。それができなければ、つまり、この製品がどのように成功するかを考えられなければ、計画がなければ、成功することはありません。
これは私たちが話した約束に直接挑戦するもう一つの要素です。多くの顧客から「経営陣がAWS料金が高すぎると言っている」という話を聞きます。これはSaaSについて持つべき会話ではありません。SaaS製品を構築している場合、AWS料金は全体的な問題ではありません。問題は、私たちが構築しているものとその中のユニットのコスト効率をどのように考えるかです。これは後ほど詳しく時間をかけて話す落とし穴の一つになります。
デプロイメントの一方通行性とテナント分離の課題
さて、これからいくつかのアーキテクチャ上の落とし穴について見ていきましょう。構想段階は過ぎたので、ここからは構築とデザインの段階で顧客がよく陥る課題について話します。デプロイメントは一方通行の扉のようなものです。テナント分離という概念をご存知だと思いますが、つまり各顧客が独自のスタックを持つか、全員でインフラスタックを共有するかということです。これらがデプロイメントです。デプロイメントについては、多くの場合設計段階で考えます。「うちの顧客は完全に分離されたバージョンを求めているはずだ」とか「共有バージョンを作ろう」といった具合に。そして、これが最後の決定だと考えてしまうことが、落とし穴の一つなのです。
現場でよく出会う顧客は、この引用のような状況に陥っています。「素晴らしい大企業のロゴを多数獲得し、新規顧客も増えているのに、成長が難しくなっている。現在の市場から抜け出せず、他の市場にも進出できない。無料プランの提供も、Product-led growthへの戦略転換もできない」。これについてもう少し話せるかもしれません。自分たちを箱の中に閉じ込めてしまい、顧客にリーチする新しい方法が見つからなくなっているのです。この落とし穴をどう回避すればいいのでしょうか。
まず、一つのアーキタイプがどのようなものか説明しましょう。
これは極めて妥当なスタックです。顧客はAmazon EKSクラスターを構築し、その背後にAmazon Auroraデータベースを置き、顧客が要求する特定の検索機能のためにAmazon OpenSearch Serviceインスタンスを追加しました。これは今年初めに私が実際に関わった顧客の例です。彼らは新しい顧客が来るたびに新しいスタックを作成していました。 SaaSに詳しくない方のために説明すると、ここではテナントと顧客を同じ意味で使っています。場合によっては、内部の運用チームやSaaSの異なるバージョンを指すこともありますが、ここでは顧客と考えてください。
彼らは顧客を獲得し続け、新しいスタックを作り続けましたが、 やがてこれらの異なるスタックの運用が高コストで困難になりました。運用効率が上がらなかったのですが、彼らにとって主な問題は、各顧客のために立ち上げていたAmazon OpenSearch Serviceインスタンスが実際にかなり高価だったことでした。採算の取れるレベルでソリューションを運用することがますます難しくなっていました。顧客は価格に不満を示し始め、彼らは現在のターゲット以外の新しい顧客を見つけて下方市場に進出することができなくなっていたのです。
コスト効率を考慮したSaaSアーキテクチャの再設計
では、彼らとどのような話をしたのでしょうか？このような落とし穴を回避するために、どのような戦略を用いたのでしょうか？もしあなたがこのような状況にあり、データベースやストレージがコストの主な争点となっているのであれば、データパターンを見直してみましょう。なぜそのデータをそこに保存しているのでしょうか？PII（個人を特定できる情報）やコンプライアンスへの影響について考えたことはありますか？この顧客の場合、 Amazon OpenSearch Serviceには実はそういった問題はありませんでした。彼らは単に検索を容易にするために大量のデータをそこに入れていただけで、コンプライアンス上の要件やデータを分離する必要性は実際にはありませんでした。
まず最初に行ったのは、統合されたAmazon OpenSearch Serviceインスタンスを作成し、そのインスタンス内でテナントごとにインデックスを使用することでした。新しい言葉も登場しましたね。以前は「テナント」と言っていたところに「advanced tier」という言葉が見えます。つまり、ここで価格帯の概念も導入しています。これらは当社のプレミアム層の顧客であり、プレミアム顧客であっても「コスト削減のために、スタックの一部を共有することができます」と伝えています。もちろん、advanced tierがあるということは、他のtierもあるはずですよね？
そこで、standard tierも設けました。 残りのデータについても検討し、「一部の顧客は、データの保存方法についてあまり気にしていません。安全に保存されている限り、データを分離して保存することを求めていません」ということがわかりました。そこで、新しいstandard tierの価格を設定し、「すべてのデータは共有されます。もし顧客が本当にデータの分離を求めているなら、advanced tier製品を提供しましょう」と提案しました。これにより、全体的なプロファイルにおいて大幅なコスト削減を実現しました。これで、顧客のニーズに応える複数の価格帯ができました。
さらに、コンピューティングについても検討を進めました。 ここでは、テナントごとのnamespaceモデルを採用しています。これは、ご存じない方のために説明すると、Amazon EKSの構成要素の一つです。同じEKSクラスターを使用しながら、特定の顧客向けに特定のnamespaceを作成し、ネットワークの観点から互いに保護することができます。これらのコンテナをより密に詰め込むことで、EKSの基盤となるコンピューティングコストを削減できます。これで、顧客のニーズに応えるさらに低価格のbasic tierができました。
これは共有ストレージを考慮した一つの選択肢です。もちろん、これが唯一の方法というわけではありません。お気づきかもしれませんが、最後のスライドでcatalogサービスが消えていました。このサービスが実際に何をしていたのか考えてみました。それは単に1日に数回非同期で実行され、カタログデータを取得するだけのものでした。これは比較的非構造化されたデータで、リレーショナルなものではなく、全体的なコンピューティングスタックの一部である必要は実際にはありませんでした。
ワークロードを分割し、ワークロード分解を行うことを考えることができます。マイクロサービスという言葉を使う人もいるかもしれません。それが当てはまる場合もあれば、そうでない場合もあります。この例では、マイクロサービスのように見えます。個々のワークロードについて、それらが何をするのか、非同期なのか、イベント駆動型にできるのか、異なるコンピューティングプロファイルや異なるデータストレージを使用できるのかを考えることが重要です。これは特に、デプロイメントが SaaS 製品としての可能性を制限するようになった場合の SaaS にとって興味深い戦略です。
SaaSソリューションのテスト戦略と信頼性の確保
ここでは、カタログサービスを管理するシンプルなサーバーレススタックがあります。しかし、もちろん複雑さも導入しました。今や、スタックに2つの異なるテクノロジーと異なるデプロイメントモデルがあります。新たな一連の落とし穴を解決策に導入していないことを証明するために、何をする必要があるでしょうか？ソフトウェアエンジニアなら誰でも、テストが私たちの行うすべてのことの中核にあることを理解しています。私たちが構築したものが持続可能であり、顧客に代わって安全に運用でき、信頼性があることを証明できなければなりません。
では、SaaS 製品にとってそれが何を意味するのか話しましょう。当然、ほとんどすべてのテスト戦略の中心にはロードテストがあります。解決策の能力の上限をテストできなければなりません。これらの異なるデプロイメントモデルを導入したので、異なる期待があるかもしれません。そして、顧客もそれらのレベルに対して異なる期待を持つかもしれません。例えば、製品サービスでは、上級顧客には平均1秒、基本層の顧客には3秒の期待があるかもしれません。これは一例に過ぎません。
アーキテクチャのさまざまな部分に対してロードテストを行うことができます。それは重要ですが、もう一つの重要な側面は、異なるロードプロファイルを作成することです。SaaS ソリューションを構築している場合、顧客が予想もしなかった方法でシステムを使用する方法を見つけ出すことは間違いありません。そのため、並行してテストできるさまざまなシナリオを考え出す必要があります。
例えば、金融業界のシナリオを考えてみましょう。多くの銀行が毎日同じ地域で午後5時に更新情報を送信する傾向があります。これはシステムに予期せぬ負荷をかけますが、予測可能な負荷かもしれません。先を見越して、これらの異なるプロファイルがどのようなものかを考えることができるかもしれません。すべての顧客が同様の時間に突発的なワークロードを持つ場合、システムはどのように反応するでしょうか？これらの異なるロードプロファイルを作成し、リリース時や定期的な間隔で継続的にテストすることで、システムが最悪の状況でも顧客に対する SLA を満たしているかどうかを評価することができます。
最後に、先ほど申し上げたように、私たちは作業を少し分解しました。新しい複雑さが加わったのです。そのため、個々のワークロードをテストできる必要があります。例えば、この非同期ワークロードが本当に非同期であり、発生するイベントが他の同期ワークロードを妨げていないことを確認するようなテストが必要です。また、この外部システムに依存するようになった他のシステムが引き続き機能できることをテストする必要があります。もし何らかの理由でそのカタログサービスが停止した場合、私たちはカタログを十分にキャッシュしているでしょうか？そのサービスが故障した場合でも、他のサービスは継続して動作できるでしょうか？
ノイジーネイバー問題とテナントごとの体験管理
これらは単なる例に過ぎません。もちろん、SaaS Well-Architected Lensを詳しく見れば、もっと多くのテストシナリオを探ることができます。ですので、ぜひそちらをチェックするか、私たちのチームに連絡して、さらに多くのテストシナリオについて相談してください。これで、テナント分離のもう一方の側面に話が移ります。私たちは非常にサイロ化されたモデルから始めましたが、これは一般的です。多くの場合、お客様は完全にサイロ化されたアーキテクチャから始めるのを目にします。しかし、もし逆の方向に進んで、すべてのテナントが同じインフラを使用するプールされたソリューションから始めたらどうなるでしょうか？
それには独自の落とし穴があり、多くの場合、すべてのテナントが同じであり、同じように振る舞い、同じ要件とニーズを持っていると仮定することから始まります。ここに、昨年私が一緒に仕事をしたお客様の例があります。彼らは大規模なイベントを運営していて、共有システムを使用していました。通常、彼らは負荷を予測し、事前にスケールアップすることができていました。しかし、何が起こったでしょうか？あるお客様が素晴らしいイベントを開催したのです。予想外に何千人ものユーザーが同時にシステムに殺到しました。同時に、別のお客様が予定していたイベントを開催していましたが、そのスケールアップは計画されていませんでした。
そこで、これら2つのイベントが同時に進行することになりました。これは、私たちが「ノイジーネイバー」状況と呼ぶものです。このノイジーネイバーの問題は、すべてのお客様に影響を与えました。お客様はそのエクスペリエンスに不満を感じ、このイベントによって一部のお客様を失ってしまいました。これは、SaaSソリューションで避けようとしているまさにそのような状況です。つまり、このタイプのノイジーネイバーの問題がシステム上の他のお客様に悪影響を与えることです。これはどのように見えるのでしょうか？そして、ここで見られる症状にはどのようなものがあるでしょうか？ノイジーネイバーの症状は、ソリューションのあらゆる層で発生する可能性があります。
ここで、皆さんの思考プロセスから始めたいと思います。ノイジーネイバーの問題を探したり、トラブルシューティングしたりする際には、ソリューションのフロントエッジだけを見るだけでは必ずしも十分ではないことを覚えておいてください。API gatewayから始めて、予期しないトラフィックから自分たちを守る方法があるかどうかを評価しようとするかもしれません。しかし、それだけが見るべき層ではありません。コンピューティングはスケールできなければなりません。この単純な例でAWS Lambdaを使用している場合、おそらくプロビジョニングされた同時実行数を使い切ってしまうかもしれません。そして、次に来るお客様がコールドスタートに遭遇し始めるのです。
EC2を使用している場合、これらはスケーリングイベントかもしれません。どのような形であれ、フロントエンドとコンピューティング層、そしてもちろんデータベースにも影響を与えます。これは予期せぬ方法で起こる可能性があります。現在のソリューションにかかっている負荷とは異なり、実際に保存されているデータとその分散方法についても考える必要があるかもしれません。この例では、テナントごとにPostgreSQLスキーマを使用しています。つまり、データベースのインスタンスを共有しているということです。複数のテナントのデータが同じデータベースで共有されています。ここには3つのテナントがあります。そのうちの1つが大量のデータを持っている場合、他の2つのテナントのクエリに影響を与えるでしょうか？インデックス作成プロセスに影響を与えるでしょうか？そのインデックス作成プロセス自体がデータベース全体の問題になる可能性はあるでしょうか？
このような問題を事前に考え、それらを回避する方法や、場合によっては回避策を考え出すことが、このピットフォールに対処する一部です。しかし、問題の解決方法を考える前に、問題があることをどのように知るのでしょうか？共有構造の中にいると、テナントの体験を簡単に理解する方法がありません。私たちのシンプルなサーバーレススタックでは、
テナントIDをスタック全体で使用しているログやメトリクスソリューションに出力しています。ここではCloudWatchを例として多く使用しているのを見ることになりますが、CloudWatchの部分には注目しないでください。Datadogを使っていても、Honeycombを使っていても、何を使っていても、このようなクエリを実行する機能があります。すべてのログとメトリクスでテナントIDを出力していることを確認してください。そうすることで、すべてのデータを迅速に集約できますが、同時に分解することもできます。問題が発生したとき、テナントレベルまで掘り下げて、そのテナントがその瞬間にどのような体験をしているかを理解する必要があります。
これは、CloudWatchを使用してそれらのログをクエリし、3つの異なるテナントの明らかに偽のモックを生成できるという単純な例です。ここでテナント2が問題を引き起こしているのは、他の2つのテナントよりもはるかに多くのリクエストがあるからです。テナントの1つのプロファイルが変化したことを理解できるこの段階に到達することが、このピットフォールを回避する方法の1つです。もちろん、これにはアラームの側面もあります。本当に予期せぬことが起こったときに知らせてくれるアラームを設定したいですが、必ずしもアラームだけに頼りたくはありません。確かに、SREはそうしたくないでしょう。
全体的なダッシュボード体験を作成し、管理者にソリューション全体の状況を一目で見られるようにした後でのみ、アラームを使用するようにしましょう。では、この問題の解決をどのように考え始めればよいでしょうか？いくつかの異なる戦略があります。その1つは、テナントのインフラストラクチャをソリューションで経験している使用状況に合わせることです。それはどのようなものでしょうか？共有スタックがあります。私たちが構築したものは必ずしも間違っているわけではありません。このスタック全体に対して何かをする必要はありません。API Gateway、Lambda、テナントごとのスキーマという正確に同じ戦略を維持するかもしれません。
テナントのインフラストラクチャ分離とセキュリティテスト
しかし、これらの各レイヤーに注目し、それぞれが何を意味するのかを考える必要があります。ノイズの多い1つのテナントを、そのインフラから切り離して独自の環境に移す必要があるかどうかを検討しなければなりません。ここでも価格帯が登場しますね。例えば、テナント2はadvanced tierの顧客だから、独立した環境に置く必要があると単純に言えるでしょう。「独立した」と言いましたが、実際には同じ共有環境です。1つのテナントしかいない共有環境を何と呼ぶでしょうか？ そう、独立環境です。インフラを変更する必要はありません。単に別のバージョンをデプロイし、テナントをその上でシャーディングするだけです。
この決定は、ここで示したほど単純ではないかもしれません。異なる地域にいる特定のテナントがいて、その使用プロファイルがあまり重複していない場合、同じインフラに置くことができるかもしれません。テナントのグループがあるかもしれません。ここでも価格帯を使いますが、standard tierにより多くの顧客を詰め込み、「あなたのSLAはそれほど高くありません。システムのパフォーマンスが出ない時期があるかもしれません。より高性能なシステムが必要な場合は、advanced tierにアップグレードできます」と単純に伝えるのです。しかし、これらすべての後、つまりシャーディングの変更を行い、API gateway、コンピューティング層、データ層でのポリシーを見直し、テナントを保護するためのポリシーを実装した後、それらが機能していることをどのように証明すればよいのでしょうか？
テストを行い、人工的なテナントプロファイルを作成する必要があります。これにより、テナント固有のインフラにヒットし、予期せぬ動作や、これらのテナントがノイジーネイバーとしてだけでなく、セキュリティの面でも与える可能性のある影響を明らかにすることができます。そのため、ソリューションのフロントエッジをテストできる必要があります。それがRoute 53であれ、他のDNSであれ、DNSを経由しない場合でも。偽のテナントで大量の負荷をかけたらどうなるでしょうか？その背後に回り込んでAPI gatewayやロードバランサーに直接アクセスし、大量のトラフィックを送り込んだらどうなるでしょうか？それは他のテナントに影響を与えるでしょうか？
API gatewayによって公開されているテナント固有のARNや基盤となるURLの1つが漏洩したらどうなるでしょうか？例えば、誰かが役職を変更し、「前の雇用主に嫌がらせをしてやろう」と決めて、大量のトラフィックを送り込んで彼らのエクスペリエンスを台無しにしようとした場合、何らかの方法で保護されているでしょうか？基盤となるコンピューティングにアクセスできるでしょうか？これは難しい問題です。正当なペイロードがある場合、そのペイロードを自分に割り当てられていないインフラに戻す方法はあるでしょうか？あるいは、セキュリティにJWTトークンを使用している場合、別のテナントのIDを持つJWTトークンを作成できるでしょうか？そして、これが正当なワークロードではないことをどのように処理し、理解すればよいのでしょうか？
最後に、データベースの裏側です。これこそが私たちが守ろうとしているものです。すべての中心にあるのは、テナントデータの保護です。トラフィックがどのルートを通ってくるかに関わらず、テナントデータが保護されるようにソリューションを十分に構築できているでしょうか？何らかの理由でデータベースの認証情報が漏洩した場合はどうでしょうか？それらの認証情報を、コンピューティングスタックを経由せずに使用する方法はあるでしょうか？また、偽のJWTトークンが実際に通過した場合はどうなるでしょうか？そのトラフィックを遮断し、他のテナントのデータにアクセスできないようにしているでしょうか？
これらはすべて、この落とし穴の正当な側面です。ノイジーネイバーに対する対策を構築・修正する際には、その解決策によって他の問題を引き起こしていないかを確認するため、継続的にテストを行う必要があります。
SaaSにおけるコスト効率とユニットエコノミクスの重要性
今週初めのキーノートで、Werner Vogelsは「すべてのエンジニアリングの決定は購買の決定である」と引用しました。この引用は実際、CloudZeroの創業者によるものです。彼らはコスト理解の支援において素晴らしい仕事をしています。キーノートでは言及されなかったようですが、彼らの功績を認めたいと思います。というのも、私たちは今や常にこの話題を耳にするからです。SaaSアプリケーションの利害関係者が「あなたが提示したこの請求書が理解できません。どんどん高くなっていて、収益の数字と合っていないように見えます」と言ってくるのです。
コストとSaaSについて利害関係者と話し合うための共通言語がなければ、有意義な会話を持つことはできません。新規顧客をスタックに追加しながら総コストを削減しようとするのは、単に実行不可能です。では、SaaSにおけるコストへの焦点はどのようなものでしょうか？
私たちが目指しているものは何でしょうか？それは、このような状況から始まります。なぜなら、これはCFOやステークホルダーが目にしている図であり、総コストが上昇し続けているからです。彼らの視点からは、これが見えているのです。一方で、SaaS製品の初期段階、つまり製品市場フィットを目指して立ち上げている段階では、通常、収益の落ち込みが見られます。そのため、彼らの視点からは、すべてが災害で、世界中が火の海のように見えます。これを修正し、何とか収益性のポイントに到達する必要があります。
彼らには見えていないものの、エンジニアリング側の私たちが取り組んでいるのは、ユニットコストに焦点を当てることです。これがSaaSで話すべき共通言語、ユニットエコノミクスです。「確かに総コストは上がっていますが、取引あたり、テナントあたり、ティアあたり、さらには機能あたりのコストは、このプラットフォームの構築がより効率的になるにつれて下がっています」と言えることが重要です。これがSaaSのコスト効率であり、AWSの請求書の総額ではありません。
これは強調しすぎることはありません。今年、投資家からのプレッシャーを受けて、プラットフォームの効率性に焦点を当てるのではなく、単に総コストを削減しようとしている人々が陥っている最大の落とし穴の1つです。成長を続け、顧客を増やし続けようとしながら、ユニットコストを下げる方法を見つけ、構築しているものをより効率的にすることが重要です。これが私たちが目指すべきことです。では、どうやってそこにたどり着くのでしょうか？この落とし穴からどうやって抜け出すのでしょうか？
SaaSのコスト把握と分析：粗粒度アプローチから細粒度アプローチへ
それは、これらのコストを把握することから始まります。では、把握したいコストとは何でしょうか？いくつかのシンプルなスタックを見てみましょう。同じような言葉が出てくるのがわかると思います。ここにサイロがあります。テナントごとのインフラストラクチャがあります。そして、これらに単純にタグを付けることができます。コスト配分タグをご存じない方のために説明すると、これはAWSでサーバーやその他すべてにタグを付けるのと同じように、別のオプションです。サイロリソースに単純にタグを付け、そのLambdaにタグを付け、その背後にあるAmazon RDSインスタンスにタグを付けることで、各テナントのサイロコストを配分することができます。
そしてそれは続いていきます。テナント2、テナント3と。共有インフラストラクチャもあります。これらは時にコントロールプレーンと呼ばれ、オンボーディングサービスや課金サービスなどです。これらは分割が難しいものです。いわば、ビジネスを行う上でのコストですね。ですので、これらをどのように分割するかについても戦略が必要です。しかし、プールされたコストが問題になります。 このプールされたコストは、SaaSのインフラストラクチャにおける主要な課題の一つです。どうすればいいのでしょうか？どうすればこれらのプールされたコストを理解できるようになるのでしょうか？
結論を先に言ってしまうと、申し訳ありませんが、手作業が必要になります。このプロセスにはある程度の労力を費やす必要があります。AWSが新しいサービスをリリースして、共有コストをすべて教えてくれるようになったと言えたらいいのですが、残念ながら今年はそのようなサービスはリリースしていません。そこで、代わりにいくつかの異なる手法をご紹介します。
まず、私が「粗粒度アプローチ」と呼ぶものから始めます。これは単純に、アーキテクチャの中でトラフィックの大部分が流れる場所を見つけることです。ボトルネックと呼んでもいいかもしれません。 それは Amazon API Gateway かもしれませんし、Application Load Balancer かもしれません。そういったインフラストラクチャはすべてログを生成します。 適切に設定すれば、それらのログの多くにテナントIDが組み込まれています。
AWS Lambda オーソライザーを使って、流れてくる JWT トークンのテナント ID をログに注入することができます。 そうすれば、先ほど話したのとほぼ同じプロセスを実行できます。Amazon CloudWatch ログを使用して、「各テナントがこの特定のサービスを何回呼び出しているか」を調べる簡単なクエリを書くことができます。これで、利用状況をかなり良く把握できるようになります。まだコストについては触れていませんが、利用状況を理解することは、コストを分割するための重要なステップです。
以前は、コストをテナントごとに均等に分割し、30のテナントがあれば、各テナントにこのプールの等しい部分を割り当てていたとしましょう。今では、各テナントがサービスをどれだけ消費しているかが分かるようになりました。その情報を使ってコストを分割すれば、すでにかなり正確になります。一部のプロバイダーにとっては、これで十分です。これ以上のことをする必要がない場合もあります。
SaaSコスト分析のためのデータ収集と可視化
Application Load Balancer ログを使用した別のバージョンをお見せしましょう。サブドメインベースのルーティングを行っている場合、テナント ID は実際にパスに含まれています。このサンプルのように、サービスもパスに反映されている場合（例えば注文サービス）、ログにテナントと使用している機能の両方が含まれることになります。これらは S3 バケットに格納されるので、Amazon Athena を使って簡単にクエリを実行し、 Amazon API Gateway で尋ねたのと同じ質問をすることができます。つまり、「各テナントがこれらのサービスをどれだけ使用しているか」です。これで、かなり良い消費指標が得られます。繰り返しますが、これで十分な場合もあります。
でも、十分でない場合はどうでしょうか？以前お話しした Amazon OpenSearch Service を使用しているお客様のケースを考えてみましょう。彼らは共有の OpenSearch インスタンスを持っていて、テナントごとにインデックスがありますが、それでも全体のコストの大きな部分を占めています。彼らは各テナントがこの特定のサービスをどれだけ使用しているかを理解したいと考えています。そこで、コストの細かい理解が必要になります。そのためには通常、コードに計測を組み込む必要があります。 つまり、実際にコードに入って、特定のメトリクスを設定する必要があります。
これは簡単な例で、大画面では読みにくいかもしれませんが、AWS Lambda Powertools を使用し、そこに含まれるメトリクスライブラリを利用しています。そして、テナント ID やおそらく彼らが消費しているサービス、サービスの応答時間などのディメンションを注入しています。さらに、裏で Amazon DynamoDB を呼び出している場合、DynamoDB の応答時間や使用した WCU 数なども入れることができます。かなり具体的になれるわけです。つまり、OpenSearch の例では、各 OpenSearch の呼び出しにかかった時間を測定できるところまで詳細化できます。OpenSearch にクエリを投げて、裏でどれだけのデータを使用しているかを尋ねることもできます。
細かいレベルでたくさんのオプションがありますが、それには労力が必要で、本当に努力が必要です。これらのメトリクスを出力できるようにする必要があります。結果として、このように単純なものになるかもしれません。 もっと複雑になる可能性もあります。Amazon CloudWatchの埋め込みメトリクス形式を使用して、それらをCloudWatchに送信できます。そして再び、CloudWatchに単純に問い合わせることができます。「テナントごとの消費量の内訳を教えて」と。しかし今や、より細かい視点を得ることができます。聴衆の中には、システムが複雑すぎてこのレベルまで掘り下げる必要がある人もいるでしょう。
大まかなところから始めて、徐々に細かいところに進み、そしてこれをコストと関連付けます。これで方程式のこちら側は完了しました。消費量がどのようなものかを示すCloudWatchログを手に入れました。もう一方の側、もう一つの要素は、AWS Cost and Usage Reportsや、AWSの公開価格を単純に提供するAWS Price List APIを使用することです。これらのコストをどのように分析したいかによって選択できます。
Cost and Usage Reportsは、各AWS Lambda呼び出しや各DynamoDBに対してAWSが請求した正確な記録です。これを使用できます。これらは基本的にAmazon S3に書き込まれます。ここでもAmazon Athenaを使用してクエリを実行できます。この例は示しませんでしたが、これらについて説明する別のワークショップがあります。Cost and Usage Reportsのクエリについてもっと詳しく知りたい場合は、それらを共有できます。AWS Well-Architected Labs も参照できます。そこにはAthena用に書かれた多数のCost and Usage Reportsクエリがあります。これらも、このようなシステムを作成するための基礎として使用できます。
しかし本質的に、私たちはこれを目指しています。テナントの消費量を測定するポイントに到達しようとしているのです。テナント1がこの特定のサービスの50%を使用したとします。それは10ドルに相当します。つまり、それに対して5ドルということですね。このように、消費量を説明し、コストと関連付けるレコードを作成できるようになります。これが最終的に目指すところだからです。聴衆の中にビジネスユーザーがいて、「これは技術的な詳細が多すぎる」と思っていたかもしれませんが、これこそが求めているものです。テナントごとのコストを示すダッシュボードを作成できるポイントに到達しようとしているのです。そして、それがどのようなものかを具体的に示します。
そして、このデータを様々な角度から分析できるようにしたいのです。ティアやフィーチャー、その他のメタデータについて話した理由は、これらのクエリがかなり複雑になる可能性があるからです。例えば、異なる顧客ティアによる特定のフィーチャーの使用状況を理解したい場合はどうでしょうか。なぜこれが必要なのでしょうか？それは、ソフトウェアの再パッケージ化を考え、ここで見ている特定のフィーチャーが現在はアドバンスドティアにあるが、実際にはそれほど高価ではないのでスタンダードティアに移動させ、より安価に提供したいと考えるかもしれないからです。そして、この非常に高価なフィーチャーをアドバンスドティアに移動させたいと思うかもしれません。SaaSソリューションの再パッケージ化や消費者の再考は、SaaSへの移行の一部であり、このコスト問題の一部です。そして、このプロセスを繰り返し改善していく必要があります。
SaaSにおけるコスト管理の継続的改善プロセス
では、少し技術的な側面から離れて、私たちが構築しているプロセスについて考えてみましょう。アプリケーションに何かを追加するリクエストのほとんどは、機能リクエストとして届きます。これらは顧客や製品チームから来るものですが、私たちはシンプルなソフトウェア開発ライフサイクルに従っています。設計、開発、デプロイ、運用という流れです。そしてこれを繰り返し、アーキテクチャ、パフォーマンス、信頼性の観点から、構築したものを継続的に改善しようとしています。
しかし、それと並行してコストが発生しています。そして、私たちはそれについて十分に考える時間を取っていません。最初の段階から、設計の決定において、エンジニアリングの決定はすべて購入の決定でもあるということを思い出してください。つまり、財務チームや製品チームを巻き込み、単に構築するだけでなく、作成している機能を運用するコストについて話し合うべきなのです。製品チームはこれをどのように販売するかをどのように理解すればよいでしょうか？営業チームはこの機能の対象顧客を理解できているでしょうか？彼らはこの機能を求めている人が誰なのかについてフィードバックを提供できるでしょうか？運用コストがわからなければ、どうやってそれを知ることができるでしょうか？
見積もりは決して正確ではありません。開発者やアーキテクトとしての私の人生で、正確な見積もりを作成したことは一度もありません。しかし、それは重要ではありません。大切なのは、これらの見積もりを行い、コストについて考え、コミュニケーションを取る努力をすることです。なぜなら、時には答えが驚くべきものであり、その答えが特定の機能の開発方法やアーキテクチャに影響を与えることがあるからです。そして、もちろん、これまで話してきたことはすべて運用段階に関することです。アーキテクチャの観点から繰り返し改善するのと同様に、このサイクル全体を通じてコストについても継続的に改善を行います。コストをアプリケーションの非機能要件として考え、信頼性やセキュリティだけでなく、コストについてもチームと共に継続的に見直し、コスト効率の良い機能を効果的に構築することを責任とする中心的なチームを置くのです。
SaaSのDevOpsとオンボーディングプロセスの自動化
DevOpsの旅は、多くのSaaS顧客が陥りがちな別の課題です。私たちはよく、オンボーディングプロセスが数週間や数ヶ月単位で測られる初期段階の顧客と話をします。これは、彼らが定期的にソフトウェアを提供する従来のソフトウェアの背景から来ているためです。おそらく、彼らの顧客はそれに慣れており、業界でもそれが期待されているのかもしれません。しかし、なぜハードルを低く設定するのでしょうか？アプリケーションのハードルを上げ、それをどのように実現するかを考えましょう。ただし、そのためにはより良いDevOpsの実践が必要です。
そして、SaaSソリューションの場合、それは次のようなものかもしれません。まず、オンボーディングという言葉を紹介します。オンボーディングは、DevOpsチームに新たな課題をもたらします。私たちはソフトウェアのリリースサイクルに慣れています。今日も、ソフトウェアのリリースサイクルがあります。しかし、SaaSでは、これが最初のDevOpsの課題となります。私たちはソフトウェアをより頻繁にリリースし続けます。おそらく毎日、あるいは毎時間単位で、これらの迅速なリリースを導入するかもしれません。しかし、それと並行して、テナントは私たちのソリューションにソフトウェアのリリースサイクルとは非同期にオンボーディングし続けます。1回のリリースの間に、おそらく5つの新しい顧客が私たちのソフトウェアにサインアップするかもしれません。これは、DevOpsの観点から、ソフトウェアのリリースサイクルと並行して対処する必要がある、予期せぬ、あるいは予測不可能な負荷を生み出すのです。
SaaSではこれをどのように考えるべきでしょうか？顧客体験に影響を与えたり、単に時間がかかりすぎたりするオンボーディングの潜在的な落とし穴について、どのように考え始めればよいでしょうか？まず最初に紹介したい概念はコントロールプレーンです。以前にもコントロールプレーンについて触れましたが、これは単にオンボーディングを含むサービスのグループのことです。また、請求、メトリクス、分析、個々のテナントの情報をどのように保存し、どのティアに属するかなども含まれます。今日は特にオンボーディングに焦点を当てて、繰り返し可能なオンボーディングプロセスとは何かを考えていきます。
これが、SaaS DevOpsで優れた結果を得るための方法です。オンボーディングで行うすべてのことを自動化できるようにする必要があります。ここで「それは私の業界では通用しません。顧客には長い販売サイクルが必要です。顧客のバックエンドシステムと統合する必要があります」と考える人もいるかもしれません。それは関連性があり、事実です。しかし、だからといって、その周りのすべてを自動化できないわけではありません。ブロッカーが自分たちの側にならないようにするのです。顧客のIDストアについての情報を待つ必要があるのであれば、それはそれで構いません。それは人間のプロセスの一部です。人間の要素は常に存在します。技術的なものはすべて自動化できるのです。
それは次のようなものかもしれません。今年、素晴らしいワークショップがありました。Michael BeardsleyとBabak Parviziが、コントロールプレーンの構築方法について興味深い例を作成しました。彼らは、そのコントロールプレーンにServerlessを使用できると提案しました。
そのコントロールプレーンでは、顧客をオンボーディングするのに役立つLambdaサービスとAPI Gatewayエンドポイントを作成するだけです。後でそのワークショップを自分で進めて、どのように構築したかを見ることができます。このサーバーレスコントロールプレーンを使用すると、アプリケーションプレーンで起こっているすべてを管理できます。それらのプロセスについては後ほど説明します。おそらくイベント駆動型でしょう。彼らは、顧客がオンボーディングする際にメッセージを送受信できるようにするために、Amazon EventBridgeを使用することを提案しました。ソフトウェアを更新したい場合、EventBridgeは層間で通信するための非常に興味深い方法を提供します。
繰り返し可能なプロセスを作成し、オンボーディングの自動化されたプロセスを持つことは、コントロールプレーンの側面を構築することから始まります。次に、自動化すべき適切なものを見つける必要があります。それはSaaSアプリケーションから始まります。そのSaaSアプリケーションは顧客体験の中核です。しかし、デプロイメントパイプラインについても考える必要があります。新しい顧客環境をブートストラップすることは何を意味するのでしょうか？セルフオンボーディングした場合、テナント管理者をどのようにオンボーディングするのでしょうか？新しい顧客を追加する方法は？ユーザー管理をどのようにセットアップするのでしょうか？外部システムに追加する必要がある場合、どのように追加するのでしょうか？おそらく、マーケットプレイスや請求プロバイダーに追加する必要があるかもしれません。
テナントユーザーをどのようにシステムに取り込むのでしょうか？外部のアイデンティティプロバイダーとの統合や連携でしょうか？それともシステム管理者が自らUIを使って行う必要があるのでしょうか？私たちは、管理者が自らその役割を担えるよう、これらすべてを自動化します。また、アップデートの自動配信についても考える必要があります。どうすれば自動的、シームレス、そして顧客に気づかれないように行えるでしょうか？
そして最後に、これ自体がピットフォールなのですが、オフボーディングについて考えましょう。私は多くのSaaS顧客が何千、何百もの顧客をオンボードしたものの、それらの顧客が離れた際にすべてのリソースをデプロビジョンするのを忘れているのをよく目にします。確かに、コストがかかるリソースの一部をデプロビジョンしたり、EC2インスタンスを削除したりはしているかもしれません。しかし、多くのアーティファクトが残されたままです。テナントがシステムからオフボードし、戻ってこないのであれば、すべてを削除してください。なぜなら、ここで陥る可能性のあるピットフォールの1つが、クォータとリミットの問題に直面することだからです。
すべてのクォータとリミットを把握しているわけではありません。私も確かにそうです。単一のペイヤーの下で持てるAWSアカウントの数、作成できるS3バケットの数、単一のAWSアカウント内で地域ごとに持てるIAMロールの数 - これらはすべて関連するクォータです。リソースをクリーンアップしないと、これらの制限に気づくことになるかもしれません。一部は厳格なクォータであり、私たちがお客様に代わって増やすことはできません。SaaSプロバイダーとして、これらの制限に抵触したり、近づいたりしないようにする責任があります。次の顧客をオンボードする際に支障が出ないようにするためです。堅実なオンボーディングプロセスを持ち、クォータとリミットをモニタリングして、それらに違反したり近づいたりしていないことを確認し、テナントを環境間で移動するためのシャーディング戦略を立てることも、このDevOpsの旅の一部であり、このピットフォールから抜け出すために対処する必要があります。
SaaSにおけるカスタマイズと設定の落とし穴
最後のピットフォールです。約束します。カスタマイズについて少し考えてみましょう。このピットフォールは、特に初期段階の顧客によく見られます。新しいロゴ（顧客）をオンボードし始めると、これらの顧客を満足させるためなら何でもしようとします。それも無理はありません。最初の10人の顧客は、おそらく私たちが獲得する中で最も重要な顧客です。彼らは製品市場フィットを見つけるのを助けてくれます。彼らが変更を求めれば、私たちは喜んでその変更を行います。しかし、それが私たちのシステム全体に影響を与え始め、チームがこれらの異なるバージョンすべてを管理しなければならなくなったらどうでしょうか？
それは、このようになるかもしれません。テナント固有の構造を持ち始め、システム全体に影響を与える技術的負債を抱えることになるかもしれません。リポジトリ、ビルドツール、Infrastructure as Code、そしてアプリケーションを含む単純なスタックが、分岐していくにつれてどんどん複雑になっていくかもしれません。単純なEFS設定のために新しい変数をコードビルドに注入するような比較的単純な変更に対応しようとして、コードの異なるブランチを持つことになるかもしれません。テナント固有のアプリケーションコードを入れ始め、コード内にテナント名が現れ始めて、このテナントはEFS Infrequent Accessを使用していて、こちらは使用していないといった区別が生まれるかもしれません。
特定のテナントが他のテナントが使用していない新しいサービスを要求した場合はどうなるでしょうか？ここで、Amazon FSx for Lustreを導入します。すると、これらの異なるブランチが生まれます。テナント4が行っていることをテナント1とどのように調和させればよいのでしょうか？このようなことを重ねれば重ねるほど、難しくなっていきます。これをどのように避けられるでしょうか？これは非常にシンプルで、過度に単純化された図ですが、理想的な状態を示しています。カスタマイズよりも設定を重視するのです。特定のテナントに対して何かを行う場合、可能な限り外部の設定システムを使用するところまで到達したいのです。ここでは、テナント3だけがこの機能を取得し、他のテナントは取得しません。テナント4にも追加する必要がある場合は、スイッチを切り替えるだけでテナント4も利用できるようになります。これにより、システムの多くの部分を改善することができます。設定の面白いところは、多くのプロセスに影響を与えることです。
ティアについて考えてみましょう。顧客には異なるティアがあり、それぞれに適用される機能セットが異なります。ここで、開発プロセスを変更できるようになります。以前は、開発者ごとに開発環境があったかもしれません。これは必ずしもアンチパターンではありませんが、トランクベースの開発ができるようになるかもしれません。個々の開発者が作業中の機能をオンにするだけで、それらが継続的に本番環境にフローアウトし、継続的なデプロイメントが可能になります。
これらの変数をビルドパイプラインに注入し、どのテナントが何を取得するかの決定を自動化し、設定に依存するようにすることができます。各顧客に対して異なるコードパイプラインを持つ必要はありません。そして、もちろんコードはよりクリーンになります。ここで提案していることの1つは、一部の方々がフィーチャーフラグについて考えているのとは少し異なるかもしれませんが、これらは長期的なフィーチャーフラグだということです。SaaSでは、今年この概念を導入し、LaunchDarklyやAppConfigを使用してSaaSの価格設定とパッケージングをセットアップするためのカスタム設定を行う方法について、いくつかのブログを書きました。
これらは長期的なフラグで、このグループのテナント、このティアのテナントが機能を受け取り、これらは受け取らないということを示します。つまり、システムからすぐに削除されるリリースフラグとは異なり、これらは異なる価格ティアの設定を外部化できるコード内の運用フラグです。これらのブログも参照できます。本当に興味深いソリューションがあります。開発側の方であれば、AppConfigは素晴らしいソリューションです。LaunchDarklyは素晴らしいAWSパートナーです。両方とも、これを行うための非常に興味深い方法を提供しています。
これらの差別化要因の1つは、ビジネスユーザーが設定の変更を行えるようにしたいかどうかかもしれません。LaunchDarklyには、それを容易にする非常に優れたUIドリブンのソリューションがあります。何をすべきか検討している場合は、これらの選択肢について話し合うことができます。お問い合わせいただければ、喜んでお話しさせていただきます。さて、どうすればよいでしょうか？この設定ができたら、どのようにしてこの設定を検証し、実際により良いテナントエクスペリエンスを提供できることを証明すればよいでしょうか？先ほど話した運用効率の向上、より良いリリース管理など、これらすべてをどのように証明すればよいのでしょうか？
このような設定があることで、システムに大規模な混沌をもたらすことができます。すべてをオフにしたり、すべてをオンにしたり、あらゆる設定を変更したりして、そのような状況下でもテナントの体験が期待通りであることを証明できます。カオスエンジニアリングは難しいものです。ここでは、インフラレベルでEC2をシャットダウンするような話ではありません。すべての機能をオフにした状態でもアプリケーションが正常に動作することをテストできるということは、私たちの設定が顧客に価値を提供していることを証明する一つの方法なのです。
Blue/greenリリース、カナリアリリース、A/Bテスト。これらのオプションはすべて、フィーチャーフラグや設定によって可能になります。新機能を10%の顧客にリリースし、残りの90%には影響を与えないようにすることができます。何か問題が発生した場合、その10%に対してロールバックするだけで済み、全体的な顧客ベースへの影響範囲を抑えることができます。また、A/Bテストも可能になります。新機能を導入する際、顧客がどのように好むかわからない場合、例えばUIがどのように見えるか、期待される動作は何か、ユーザー体験はどうかなど、これらも設定によって可能になります。
そして、前述したように、価格設定とパッケージングの反復が可能になります。これは新しい層を追加することと考えてください。ビジネスユーザーが市場を評価し、製品の新しいエンタープライズ層を望んでいるとします。これをどのようにテストするのでしょうか？新しいエンタープライズ層の顧客をすべてオンにしたときに、すべてが正常に動作するように設定をセットアップするにはどうすればよいでしょうか？価格層の設定を外部化し、ビジネスユーザーが管理できるようにすることは、このような設定を外部化することで可能になる興味深いオプションの一つです。
SaaS構築における落とし穴の総括
カスタマイズよりも設定を重視することの利点をいくつか見てきましたが、この落とし穴を避けるのは実に簡単です。個別のカスタマイズを行わず、落とし穴に陥らないことです。代わりに、設定をどのように行うか、どのように外部化するかを事前に考えることが重要です。 これで、いくつかの潜在的な落とし穴について説明しました。SaaSを構築する際には、優れたSaaSを構築することを目指します。デプロイメントについて話し、デプロイメントが一方通行であってはならないことを説明しました。代わりに、デプロイメントを全体的に考え、顧客のために開発しているものや、製品をどのように差別化できるかについて継続的に改善していく必要があります。
この落とし穴については説明しました。次に、ノイジーネイバーの問題について話し、共有ソリューションを慎重に計画する必要があることを説明しました。ノイジーネイバーの問題をテストし、確実にカバーする必要があります。そして、もしそのような問題が持続し、特定のテナントに対して修正できない場合は、顧客を異なる環境に分散させる能力を持つ必要があります。
コストに焦点を当てることが重要だと議論してきましたが、全体的なコストを考えるだけでは十分ではありません。個々のテナントをサポートするコスト、特定の機能を構築するコスト、あるいはテナントのティアごとのコストなど、ユニットエコノミクスに深く踏み込んで考える必要があります。また、DevOps プラクティスがどのように顧客のオンボーディングの課題を克服し、セルフオンボーディングを可能にし、プロセスを自動化して開発者が顧客に価値を提供することに集中できるようにするかについて探ってきました。
SaaS におけるカスタマイズの落とし穴についても取り上げ、カスタマイズよりも設定を優先する必要性について説明しました。このアプローチにより、ソリューションにおけるイノベーション、効果的なテスト、そしてビジネスユーザーがソリューションのパッケージングを管理できるようにする可能性が生まれます。いくつかの落とし穴について取り上げましたが、リストにはさらに多くの項目があることにお気づきでしょう。時間の都合上、いくつかしか取り上げられませんでしたが、他の課題に直面している場合は、ぜひ私たちのチームにご連絡ください。AWS 上で優れた SaaS を構築するお手伝いをさせていただきます。
AWSのSaaSリソースとパートナーネットワークの紹介
また、新しいリソースもローンチしました。これらの QR コードの写真を必ず撮ってください。今週、SaaS on AWS を新しいホームページとして導入し、パートナーリソースや彼らが構築しているものを含む、すべてのリソースを集約しました。また、SaaS におけるさまざまなセルフサービスオプションも提供しています。私たちのチームだけでなく、SaaS の専門家であり、SaaS ソリューションを構築する能力が検証された SaaS コンピテンシーパートナーにも連絡することができます。
AWS Partner Network への参加をお勧めします。SaaS Factory は AWS パートナー向けの無料プログラムであり、go-to-market サポートや特定のタイプのソリューション（コンプライアンスソリューションを含む）の構築支援など、多くの利点を提供する他のプログラムも多数あります。Partner Network への参加について質問がある場合は、お問い合わせください。多くの利点があり、SaaS を構築している方々には AWS パートナーになることをお勧めします。
私の名前は Bill Tarr で、連絡先情報を提供しました。遠慮なくご連絡ください。私たちはあなたの質問に答える準備ができており、パートナーの皆さんと一緒に仕事をし、話をすることが大好きです。素晴らしい re:Invent でした。皆様のご帰宅が安全であることを願っており、来年また皆様にお会いできることを楽しみにしています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion