ユースケース
シナリオ：認証済みパートナーアクセスを持つフィンテックAPI
誰が：決済処理APIを運用する3人のフィンテックスタートアップ。 どこで：月額$40のVPS上の単一バックエンドサービス。 課題：TLS、DDoS対策、加盟店パートナー向けの認証済みAPIアクセスが必要だが、DevOpsエンジニアがおらず、Cloudflare、Auth0、APIゲートウェイを連携させるのに数週間をかけられない。
Mezusphere導入前
デプロイには複数のサービスの設定と管理が必要：
5つのベンダー、5つの設定、5つの障害点、すべてが１つに。
ステップバイステップのデプロイ
1. 既存のAPIから始める
チームはすでにポート3000でリッスンするNode.js APIを持っている：
# 既存のセットアップ — 変更なし
node server.js # localhost:3000でリッスン2. Warpgateをサイドカーとして追加
# docker-compose.yml
services:
api:
build: .
ports:
- "3000:3000"
warpgate:
image: mezusphere/warpgate
command: ["--token", "wg_prod_abc123...", "--upstream", "api:3000"]
depends_on:
- apiWarpgateは外向きにMezusphereに接続。インバウンドポート不要、ファイアウォールルール不要、VPSにパブリックIP不要。
3. Consoleでルートを設定
Mezusphere Consoleでチームは以下を設定：
| ルート | パス | 認証要否 | 説明 |
|---|---|---|---|
| ヘルスチェック（公開） | /health | 不要 | 稼働状況監視 |
| 加盟店API | /api/v1/* | 必要 | 認証トークンが必要なパートナーエンドポイント |
| Webhookレシーバー | /webhooks/* | 不要 | 決済プロバイダーからのインバウンドWebhook |
4. パートナー認証を有効化
/api/v1/*ルートに対して、Consoleで認証を有効化：
- 「加盟店パートナー」というユーザーディレクトリを作成
- メール＋パスワード認証でパートナーアカウントを追加
/api/v1/*ルートに認証を要求
パートナーはログイン認証情報を受け取り、Mezusphereの認証フローでアクセストークンを取得。決済APIは事前認証済みのリクエストを受信；アプリケーションに認証コードは一切不要。
5. 公開
APIがhttps://payments.example.comで利用可能に。トラフィックフロー：
TLS · 認証 · DDoS · ルーティング
得られるもの
- TLS 1.3：自動、証明書管理不要
- DDoS対策：エッジに組み込み、設定不要
- パートナー認証：Consoleで管理、アプリケーションコードはゼロ
- パスベースルーティング：公開ヘルスチェックと認証済みAPIを同じドメインで
- インバウンドポートなし：VPSにパブリック向けポートは一切なし
- 請求書は１つ：月額$99でCloudflare（$20+）、Auth0（$23+）、APIゲートウェイホスティング、証明書管理のオーバーヘッドを置き換え
デプロイ所要時間：30分以内
チームはインフラ管理ではなく、決済機能の構築に時間を使える。
シナリオ：ステージング環境を持つマルチリージョンSaaS
誰が：Reactフロントエンドと3つのバックエンドマイクロサービスを持つ15人のB2B SaaS企業。 どこで：レイテンシのためにAWS（us-east-1）とGCP（asia-northeast1）に分散。 課題：リージョンごと・環境ごと（dev、staging、prod）に異なるCloudflare設定、nginx ingressコントローラー、OAuth統合を管理することで、維持が困難な設定マトリックスが生まれている。
Mezusphere導入前
環境×リージョンの各組み合わせにそれぞれ必要：
- Ingressコントローラー設定
- TLS証明書管理
- OAuthクライアント認証情報
- ファイアウォール/セキュリティグループルール
- DNSレコード
2リージョン×3環境で6以上の設定を同期する必要があり、それぞれ異なる認証情報とわずかに異なるセットアップが存在。
Mezusphereの場合
1. サービスごと・環境ごとにWarpgateをデプロイ
各マイクロサービスに環境ごとのトークンを持つWarpgateサイドカーを追加：
# Kubernetesサイドカー（本番、us-east-1）
- name: warpgate
image: mezusphere/warpgate
args: ["--token", "wg_prod_useast_...", "--upstream", "localhost:8080"]# Kubernetesサイドカー（ステージング、asia-northeast1）
- name: warpgate
image: mezusphere/warpgate
args: ["--token", "wg_staging_apne1_...", "--upstream", "localhost:8080"]2. Consoleで統一ルーティング
すべての環境とリージョンを１つのConsoleから管理：
| 環境 | リージョン | エンドポイント | サービス |
|---|---|---|---|
| 本番 | us-east-1 | app.example.com | フロントエンド、API、課金 |
| 本番 | asia-northeast1 | app.example.com | フロントエンド、API |
| ステージング | us-east-1 | staging.example.com | フロントエンド、API、課金 |
ルート、認証ルール、権限は一度設定するだけで、リージョン間で一貫して適用。
3. 変わること
- Ingressコントローラー：不要に。Warpgateが置き換え。
- TLS証明書：自動。cert-managerもLet’s Encryptのcronジョブも不要。
- 環境ごとのOAuth：ConsoleでAuth設定を１つ管理。リージョンごとの個別OAuthクライアントは不要。
- ファイアウォールルール：インバウンドポート不要。セキュリティグループが極めてシンプルに。
- DNS管理：Mezusphereがエッジルーティングを処理。エンドポイントごとにCNAME１つ。
結果
インフラチームのKubernetesマニフェストは数百行削減。新しいリージョンの追加は、Warpgateサイドカー付きでサービスをデプロイし、Consoleで環境を作成するだけ、数日がかりのインフラプロジェクトが10分のタスクに。