反転イングレスモデルとは何か
Mezusphereの中核となる技術革新は反転イングレスモデルです。ワークロードがインバウンドトラフィックを受け入れる代わりに、エッジに対して外側に接続するアーキテクチャです。この記事では、それが何であるか、どのように機能するか、そしてなぜインターネット向けサービスのセキュリティと運用プロファイルを変えるのかを説明します。
従来のイングレス：インバウンドモデル
主要なクラウドプロバイダーやCDNはすべて、インターネット向けサービスに同じ基本パターンを使用しています。トラフィックは内側に流れます：
エンドユーザー → CDN → ロードバランサー → APIゲートウェイ → リバースプロキシ → ワークロードこれを機能させるには、以下が必要です：
- インフラのインバウンドポートを開放（通常80と443）
- ロードバランサーやCDNを指すDNS設定
- TLS証明書のプロビジョニングと終端の設定
- トラフィックをルーティングするリバースプロキシの設定（NGINX、HAProxy、Traefik）
- API管理のためのAPIゲートウェイのデプロイ（Kong、AWS API Gateway）
- 認証のための認証プロバイダーの統合（Auth0、Cognito、Keycloak）
- 上流でのDDoS対策の有効化（Cloudflare、AWS Shield）
各レイヤーは別々のサービスで、多くの場合別々のベンダーから提供され、それぞれ独自の設定、モニタリング、課金があります。レイヤー間の統合はあなたの責任です。CloudflareとAPIゲートウェイの境界で何かが壊れた場合、どちらのサポートチームもその問題をオウンしません。
このモデルは25年間機能してきました。しかし、偶然ではなく構造的な問題を生み出しています。
インバウンドイングレスの構造的問題
1. パブリックな攻撃面
ワークロードはパブリックに到達可能なIPアドレスを持ちます。ポートは開いています。DNSはオリジンを直接（または間接的に）指しています。攻撃者はインフラを探索、スキャン、フィンガープリントできます。CDNの背後でも、オリジンIPの漏洩は持続的なセキュリティリスクです。
2. 設定の複雑さ
各レイヤーにはそれぞれの設定が必要です。TLS設定、ルーティングルール、CORSポリシー、認証ミドルウェア、すべて異なる場所に、異なる形式で、異なる更新メカニズムで定義されています。どのレイヤーでも１つの設定ミスでサービスが露出する可能性があります。
3. 統合の脆弱性
認証トークンはトラフィックレイヤーではなくアプリケーションコードで検証されます。レート制限はAPIゲートウェイで、DDoS対策はCDNで、WAFルールはまた別の場所で。ポリシーは単一の真実源なしにシステム間に散在しています。
4. 運用オーバーヘッド
6つのサービスは、6つの監視対象、6つの更新対象、6つの独立して障害が発生しうるものを意味します。インシデント対応には、一緒に動作するよう設計されていないレイヤー間の相互作用の理解が必要です。
反転イングレス：アウトワードモデル
Mezusphereはトラフィックフローを反転させます。プロキシのレイヤーを通じてインバウンドトラフィックを設定する代わりに、ワークロードはMezusphereのグローバルエッジに対して外側に接続します。
ワークロード + ワープゲート → (アウトバウンドTLS 1.3) → メズスフェアグローバルエッジ ← エンドユーザー仕組みは以下の通りです：
ステップ1：Warpgateが外側に接続
Warpgateという軽量サイドカーがワークロードと一緒に動作します。起動時に、WarpgateはサービスアカウントAPIキーで認証された、MezusphereのグローバルエッジへのアウトバウンドTLS 1.3接続を開始します。
これが唯一必要なネットワーク操作です。インバウンドポートなし。ファイアウォールルールなし。DNS設定なし。TLS証明書管理なし。
ステップ2：エッジがすべてを処理
Mezusphereのグローバルエッジがすべてのエンドユーザートラフィックを処理します：
- TLS終端：証明書は自動的にプロビジョニング・更新
- DNS：ホスト名は自動的に割り当て・管理
- DDoS対策：Warpgateに到達する前にエッジでトラフィックをフィルタリング
- 認証：有効な場合、転送前にすべてのリクエストを認証
- 認可：アクセス制御をエッジで適用
- ルーティング：パスルールに基づいてリクエストを正しいWarpgateに振り分け
ステップ3：トラフィックがWarpgateに流れる
認証済み、認可済み、フィルタリング済みのトラフィックが、確立されたトンネルを通じてWarpgateに転送され、Warpgateはlocalhostのワークロードにそれを渡します。アプリケーションはクリーンな、事前認証済みのリクエストを受信します。
なぜこれが重要か
ゼロパブリック攻撃面
ワークロードにはオープンポート、パブリックIPアドレス、それを指すDNSレコードがありません。直接スキャン、探索、攻撃できるものがありません。唯一のパブリックに到達可能な面はMezusphereのグローバルエッジであり、それは敵対的なトラフィックを処理するために設計されています。
単一の設定面
ルート、認証ルール、レート制限、CORSポリシー、DDoS設定はすべて１つの場所で設定されます：Mezusphere Console。6つの異なるサービスに散在する設定ファイルはありません。YAMLもありません。
コードではなくエッジでの認証
認証はトラフィックがWarpgateに到達する前に行われます。アプリケーションはトークンの検証、セッションの管理、ログインフローの処理をしません。すでに認証済みのリクエストを、ヘッダーにアイデンティティ情報を含めた状態で受信します。
アーキテクチャによるクラウド非依存
Warpgateが外側に接続するため、ワークロードがどこで動作しているかは問題ではありません。AWS、GCP、Azure、オンプレミス、クローゼットのRaspberry Pi、パターンは同一です。トラフィックの到達方法を変更することなく、ワークロードをクラウド間で移動できます。
シンプルなデプロイ
Mezusphereに新しいサービスを追加するには3ステップです：
- ワークロードをデプロイ
- Warpgateを一緒に実行
- Consoleでルートを設定
ロードバランサーのプロビジョニング不要。DNS更新不要。TLS証明書管理不要。APIゲートウェイ設定不要。認証インテグレーションの構築不要。
従来のアプローチとの比較
| 観点 | 従来（インバウンド） | Mezusphere（アウトワード） |
|---|---|---|
| ネットワーク方向 | ワークロードへのインバウンド | ワークロードからのアウトバウンド |
| オープンポート | 必要（80、443+） | なし |
| TLS証明書 | 手動または半自動 | 完全自動 |
| DNS設定 | 必要 | 自動 |
| 認証統合 | 別システム、アプリレベル | エッジレベル、設定トグル |
| DDoS対策 | 別サービス | 組み込み |
| 設定 | 6+サービスに散在 | 単一 Console |
| クラウド依存性 | ベンダー固有 | クラウド非依存 |
ngrokとの違い
ngrokは最も近いアーキテクチャ上の類似であり、こちらもアウトワード接続トンネルを使用します。ngrokは確立された開発者コミュニティ、優れたドキュメント、素早いオンボーディング体験を構築しており、Mezusphereはそれを尊重し学んでいます。主な違い：
- 認証の深さ：ngrokはOAuth/SAMLパススルーを提供しますが、ユーザーディレクトリ、サインアップ/ログインフロー、認可システムはありません。Mezusphereはユーザー管理を含むフルスタック認証を提供します。
- 本番環境向け：ngrokは開発者向けトンネリングツールとして生まれました。Mezusphereは本番インフラプラットフォームとして設計されています。
- 含まれるサービス：MezusphereにはDDoS対策、WAF（アドオン）、キャッシング、管理コンソールがngrokの提供範囲を超えて含まれています。
試してみる
反転イングレスモデルは理論ではありません。Mezusphereはすでにパイロットで稼働中で、一般公開は2026年10月です。ワークロードをデプロイし、Warpgateを追加して、インフラの定型作業がただ消える体験をしてください。
パイロットアクセスを申請 →