「自分たちで作ればいい
文字通り、ゼロからテナントごとのインフラをプロビジョニングしようとするすべてのチームに贈る最後の言葉だ。
顧客ごとにコンテナをスピンアップし、トラフィックをルーティングする。
次に、永続的なストレージが必要で、次に環境の分離が必要で、次にワイルドカードDNSが必要で、次にサブドメインごとのSSLが必要で、次にプロビジョニングAPIが必要で、次にテナントごとのモニタリングが必要で、次に独立したスケーリングが必要です。
3ヵ月後、あなたのインフラ・エンジニアは、顧客が実際に求めた機能を出荷する代わりに、カスタム・オーケストレーション・システムをメンテナンスしている。
DIYプロビジョニングの氷山
ただコンテナを回転させるだけ」のように見えるが、実は相互に関連し合い、増殖し続ける問題の巨大な積み重ねなのだ。
コンテナ・オーケストレーション
コンテナの作成、起動、停止、再起動、破棄をオンデマンドで行う必要がある。ヘルスチェックが必要で、障害が発生すると自動的に再起動する。
もしkubernetesを使っているなら、テナントごとにDeployments、Services、Ingresses、PersistentVolumeClaims、ConfigMaps、Secretsを書くことになる。
ネットワーキングとルーティング
各テナントには固有のURLが必要です。ワイルドカードDNS、サブドメインに基づいてルーティングするリバースプロキシ、テナントごとのSSL証明書（または、それ自体が頭痛の種である適切な管理を伴うワイルドカード証明書）。
企業顧客は、slug.yourdomain.comの代わりにai.theircompany.comを絶対に欲しがるだろう。これは、カスタムドメインごとのDNS検証、証明書のプロビジョニング、プロキシの再設定を意味する。
永続記憶装置
コンテナはエフェメラルだが、顧客のデータはそうではない。再起動や再展開に耐える永続的なボリュームが必要で、バックアップ戦略では、あるテナントのボリュームが別のテナントから決してアクセスできないようにしなければならない。
環境遮断
APIキー、モデル設定、機能フラグ、レート制限。各テナントは、実行時に注入される独自のenvバーのセットを必要とする。全体を再デプロイすることなく、これらを保存、更新、ローテーションする安全な方法が必要だ。
プロビジョニングの自動化
コンテナ、ボリューム、ネットワーク設定、DNSレコード、SSL証明書、envバーを1回の操作で作成するプロビジョニングAPIが必要だ。
モニタリングと観測可能性
10テナントなら手動で管理できるかもしれません。CPU、メモリ、ディスク、ネットワーク、ヘルスステータス、アップタイムのトラッキング、アラート機能などです。
ここでの真のコストは機会である
エンジニアの時間は確かに高価だが、それは最大のコストではない。
あなたのチームがインフラ構築に費やす1週間は、その1週間が彼らの仕事に費やされない1週間なのだ：
- 製品を差別化する機能
- トライアルユーザーを有料顧客に変えるオンボーディングフロー
- 新たな市場を切り開く統合
- 顧客が貴社に支払う実際のAI機能
インフラは必要だが、差別化にはならない。それに費やす時間を減らせば減らすほど、実際に重要なことに費やす時間が増える。
維持税（恒久的なもの）
正直なところ、それは簡単なことだ。
インフラは永遠にメンテナンスが必要だ：
- コンテナランタイムの更新とセキュリティパッチ
- SSL証明書の更新(期限が切れる。いつも最悪のタイミングで期限が切れる)
- ストレージ容量計画
- ネットワーク設定の変更
- 監視システムの維持管理
- インシデント対応手順
- チームのための文書（誰も読まないが、それでも書かなければならない）
これは、エンジニアリング能力に対する恒久的な税金である。製品が成熟するにつれて縮小するのではなく、テナント数が増えるにつれて大きくなる。
DIYが実際に意味を持つとき
公平を期すため、特定の状況においては自作することは理にかなっている：
- 専門的なインフラチームがあり、他の業務がない。
- お客様の分離要件が、どのプラットフォームもサポートしていないほど特殊である。
- インフラそのものが競争優位
- プラットフォーム・コストが製造コストを純粋に上回るような規模で事業を行っている。
AI製品を出荷しているほとんどのチームにとって、これらのどれにも当てはまらない。
ShipClawに代わるもの
ShipClawは、上記のスタック全体をビジュアルビルダーとデプロイボタンに置き換える。
| DIY component | ShipClaw equivalent |
|---|---|
| Container orchestration | drag a Runtime node onto canvas |
| Networking and routing | Gateway node handles wildcard routing + SSL |
| Persistent storage | Volume node mounts at /data automatically |
| Environment isolation | Env Config node per tenant |
| Provisioning automation | click deploy. platform does everything. |
| Monitoring | built-in dashboard with per-tenant metrics |
| Custom domains | Custom Domain node with automatic SSL |
Dockerfileも、kubernetesマニフェストも、terraformも、構築・保守するプロビジョニングAPIもない。
トポロジーをビジュアルに設計し、デプロイする。
算数
DIYテナントプロビジョニングを構築する2人のエンジニアチームの概算見積もり：
- 初期ビルド： 8～12週間の集中エンジニアリング（何も問題が起こらなかったと仮定して(笑)
- 継続的なメンテナンス: 10-20時間/週、毎週、ずっと
- **事故対応：**予測不可能だが、最悪のタイミングで起こることが保証されている
- 機会費用: ~3ヶ月の製品開発期間がちょうどなくなった
ShipClawは午後には同じ結果を得ることができます。
ボトムライン
DIYのテナント・プロビジョニングは罠である。週末のプロジェクトのように見えるが、永久的なエンジニアリングのコミットメントとなり、徐々にチームを蝕んでいく。
問題は "作れるか "ではなく、"作るべきか "だ。
プラットフォームを使い、製品を出荷し、すでに解決された問題に最高のエンジニアの時間を費やすのはやめよう。
東建