なぜAI SaaSは顧客50社で破たんするのか

誰もこのことを話題にしないが、ほとんどのAI SaaS製品は50テナントあたりで壁にぶつかる。ランタイムの共有、envバーのリーク、午前3時のポケベルアラート。実際に何が起きているのか、そして私の失敗を繰り返さないためにはどうすればいいのかを紹介しよう。

なぜAI SaaSは顧客50社で破たんするのか

正直に言おう。

私たちがAI製品を作り始めた当初、共有ランタイムは問題ないと考えていた。ひとつの大きなコンテナで、すべての顧客が同じエンドポイントを叩く。簡単だ。金曜日には出荷し、ビールで乾杯。

私たちは間違っていた。

最初の10人は?すべてが美しい

配備する。顧客はサインアップする。APIのレスポンスは速い。ログはきれい。あなたは天才になった気分だ。

あなたは共同創業者に「ほら、kubernetesは必要ないと言っただろう」と言う。ハイタッチ。人生は楽しい。

そして顧客11が加わる。彼らは予想外の使用例を得た。彼らは1分間に400リクエストを送信しています。他の10人の顧客は?全員タイムアウトになりました。あなたのスラックは爆発しています。

でも、大丈夫でしょう?レート制限を加えればいい。すぐに解決できる。

違う。あれは始まりに過ぎない。

50人の顧客で実際に壊れたもの

私たちに起こったことを説明しよう。

**我々はenvに全ての顧客のAPIキーを持つ1つの共有ランタイムを持っていた。ある悪いエラーハンドラがenvの全データを監視ツールに記録していた。我々は3週間気づかなかった。Datadogには顧客の秘密が3週間も放置されていたのだ。今でもこのことで眠れない。

ある顧客が全員をクラッシュさせた。 顧客34は、モデルが無限トークンを出力するようなプロンプトを送信できることを発見した。ランタイムがOOMした。50人全員がダウン。火曜日の午前2時47分に。どうやって知ったか聞いてくれ。

**顧客Aは200ミリ秒でレスポンスを得る。顧客Bからの同じリクエストには4秒かかります。なぜか?顧客Cがバッチジョブを実行していて、すべてのCPUを消費しているからです。共有ランタイムでは、すべてのトラフィックが混在しているため、これをデバッグすることさえできません。

**企業顧客はGPT-4を望んでいる。もう一人はクロードが欲しい。3人目はカスタムのシステム・プロンプトを必要としている。共有ランタイムで?幸運を祈る。基本的には、インフラストラクチャー用の機能フラグが必要だ。そんなものはない。

誰もやらない数学

始める前に計算しておきたかったことがある:

共有ランタイムの構築費用 **2週間

50人の顧客が故障した後、隔離されたランタイムに移行する費用: 3ヶ月

クロステナントのデータ漏洩により2社の企業顧客を失うコスト: プライスレス(良い意味ではない)

移行は残酷だった。プロビジョニング・システム、コンテナ・オーケストレーション、ボリューム管理、DNSルーティング、SSL証明書、環境分離を構築しなければならなかった。すべて、50社の顧客を稼働させながらです。まるで飛行中の飛行機のエンジンを交換するようなものでした。

一方、孤立から出発した人々は、本物の製品を作っている。

私たちがマイグレーション作業に溺れている間、他のチームは初日から独立したランタイムで実際の製品を出荷していた:

東建

ClawFieldは隔離されたランタイムでライブ取引ボットスキャナーを構築しました。すべてのエントリーは30秒以内、秒単位まで正確に実行。彼はクロステナントの問題をデバッグしていたのではない。彼は収益を上げる機能を構築していたのだ。

東建

Max Blade は、孤立した OpenClaw エージェントを起動する iOS アプリ全体を出荷しました。TelegramもAPIキーもセットアップも不要。サインインするだけで、エージェントは稼働する。彼は、共有インフラストラクチャのメンテナンスに行き詰まることがなかったので、それを構築した。

これらは本物のビルダーによる本物の製品だ。彼らは、配管の代わりに製品に時間を費やすことができるよう、分離から始めた。

手遅れになるまで誰も乗り換えない理由

私はAI製品を開発している多くの創業者と話をする。彼らは皆、同じことを言う:

「もっとお客さんが増えたら、後で隔離しよう

これが罠だ。分離を正当化できるだけの顧客ができた頃には、安全に移行するには顧客が多すぎる。移行しやすい時期?それは今です。問題が発生する前です。

バックアップのようなものだ。データを失うまでは、バックアップなんて誰も気にしない。それが突然、世界で最も重要なことになる。

テナントごとの分離の実際

移行に3ヶ月を費やした結果、こうなった:

  • 顧客ごとにDockerコンテナを用意
  • 各コンテナは、/dataに独自の永続ボリュームを持つ。
  • 環境変数はテナントごとに完全に分離されている
  • 各顧客はcustomer.agents.shipclaw.ioのような固有のURLを取得する。
  • 一人の顧客がクラッシュしても、他の顧客には影響しない
  • モデル、設定、顧客ごとの料金制限をカスタマイズできます。

その差は昼夜を問わないものだった。サポートチケットは80%減少した。午前3時のページはなくなりました。エンタープライズの顧客は、撤退すると脅すこともなくなりました。

「しかし、孤立したランタイムは高価だ

これは私が最もよく耳にする反論だ。コンテナが増える=お金が増える、でしょ?

まあね。しかし、実際に計算してみよう:

**共有ランタイムコスト

  • インフラ:月200ドル
  • 午前3時のインシデント対応:あなたの正気
  • 信頼性の問題による顧客離れ:月5,000ドル以上の収益損失
  • 企業との取引は「孤立を保証できない」という理由で失われた:???
  • クロステナントの問題をデバッグするエンジニアリング時間:20時間/週

分離されたランタイム:

  • インフラ:400ドル/月(はい、それ以上です)
  • 午前3時の事件:基本的にゼロ
  • 顧客離れ:大幅に減少
  • エンタープライズ案件:今なら実際に成約できる
  • インフラ問題のエンジニアリング時間:2時間/週

インフラは高くつく。それ以外はずっと安い。ネット?かなり得をする。

ShipClawで今どのようにしているか

そのような苦痛を経験した後、私たちはShipClawを作った。

ビジュアルビルダーを開きます。ランタイムノードをキャンバスにドラッグします。ルーティング用にゲートウェイを接続します。永続ストレージ用にボリュームを追加します。シークレット用にEnv Configを追加する。デプロイをクリックする。

それだけです。各顧客は、完全に分離された OpenClaw ランタイムを利用できます。独自のコンテナ、独自のボリューム、独自の環境変数、独自のURL。DockerファイルやKubernetesマニフェストは一つも書いていません。

手作業で3ヶ月かけて構築したものが?今はドラッグ・ドロップでデプロイできる。

私が無料でアドバイスする部分

複数の顧客のためにAI製品を作るのであれば、初日から分離してください。ShipClawを使おうが、自分で作ろうが、まったく別のものを使おうが構わない。ただ、共有ランタイムのようなことはしないでほしい。

技術的負債は急速に膨らむ。セキュリティ・リスクは本物だ。午前3時のページは必ずやってくる。そして、後で移行するのは、すぐに始めるより10倍難しい。

信じてくれ。私は高価な方法でこれを学んだ。

東建