なぜメズスフェアを作ったのか

私がこれまで見てきたクラウドアーキテクチャ図は、すべて同じに見えます。

ロードバランサー、リバースプロキシ、APIゲートウェイ、CDN、WAF、認証プロバイダー、DDoS対策、すべてYAMLと祈りでつなぎ合わされています。10個のサービス、6つのベンダー、3つの課金モデル。そして誰もがビジネスロジックの最初の1行を書く前に、他のすべての会社がまったく同じように設定する同じボイラープレートの設定に何週間も費やします。

このパターンは、私が働いたすべての会社で、すべてのクラウドで、すべての国で繰り返されていました。

80%の問題

一般的なクラウドアーキテクチャの約80%は、非差別化インフラです。プロダクトを良くするわけでもなく、競争優位性を与えるわけでもありません。リクエストを１つ処理する前に設定しなければならない前提条件に過ぎません。

スタートアップにとって、これは致命的です。DevOpsエンジニアはいません。セキュリティスペシャリストもいません。プロダクトを作る代わりに最初の1ヶ月をインフラの設定に費やす余裕はありません。でも代替案、セキュリティを省略し、ベーシック認証を使い、DDoSされないことを祈ること、はさらに悪い選択です。

成長中の企業にとっては、別の種類の痛みです。インフラは動いていますが、今度はそれを維持しなければなりません。新しいサービスごとに同じセットアップが必要です。認証のインテグレーションは毎回数週間のプロジェクトです。ベンダーの請求書は毎回サプライズです。エンジニアは機能よりもインフラに多くの時間を費やしています。

アイデンティティの問題

Authlete（3年間エンジニアリングをリードしていました）で、認証の問題を間近で見ました。OAuth、OpenID Connect、トークン管理、これらは本当に難しい問題です。しかし、それらをうまく解決しても、ソリューションをトラフィックレイヤーに組み込む必要があります。トークンの検証はエッジではなく、アプリケーションコードで行われます。認証エラーはルーティングエラーに連鎖します。アイデンティティシステムとトラフィックシステムは別物で、その間のギャップにセキュリティ脆弱性が存在します。

そこでアイデアが結晶化しました。認証がインテグレーションする別のシステムではなく、トラフィックレイヤー自体のプロパティだったら？すべてのリクエスト、人間、デバイス、サービス、AIエージェント、がワークロードに到達する前にエッジで認証されたら？

反転イングレスモデル

生まれたアーキテクチャは直感に反するものでした。プロキシやゲートウェイのレイヤーを通じてインバウンドトラフィックを設定する代わりに、ワークロードがエッジに対して外側に接続します。軽量なサイドカー、Warpgate(ワープゲート)と呼んでいます、がセキュアなアウトバウンドトンネルを確立します。エンドユーザーのトラフィックはエッジから入り、TLS、認証、DDoS対策、ルーティングが自動的に処理された上で、Warpgate(ワープゲート)に転送されます。

インバウンドポートなし。ファイアウォールルールなし。リバースプロキシなし。APIゲートウェイなし。インバウンドネットワーキングレイヤー全体が存在しません。

これは単にセットアップが簡単なだけでなく、構造的により安全です。ワークロードにはパブリックな攻撃面がありません。スキャンするポートも、発見するオリジンも、ミス設定するロードバランサーもありません。攻撃面はMezusphere(メズスフェア)のグローバルエッジであり、それに対処するために設計されています。

日本発、世界で勝つ

日本発で真のグローバルな成功を収めたクラウドプラットフォームはまだありません。私たちはそれを変えるつもりです。

Mezusphere(メズスフェア)という名前は、日本語の「珍しい」（mezurashii）、レア、独特、と「sphere」（領域）を組み合わせたものです。ありふれたものではなく、珍しく、意図的なもの。

私たちがMezusphere(メズスフェア)を作ったのは、コードとユーザーの間のインフラレイヤーは10個ではなく１つであるべきだと信じているからです。セキュリティとパフォーマンスはアドオンではなくプリミティブだからです。そして複雑さは成長への隠れた税金だからです。