ゲートウェイを極める：プロトコル、プロキシ、そしてモダンメッシュ

SchemaBridge Team · 2026-01-14 · Protocols, REST, API

断片化したクラウドのための設定可能な HTTP ゲートウェイ。上限付きリトライ、宛先ごとのレート制限、送信時に注入されるシークレット。

プロトコルのスープ：果てしない断片化の時代を生きる

ハイプを信じるなら、世界はすべて JSON を使った HTTPS 上の RESTful です。本当のハイプを信じるなら、世界は GraphQL や gRPC へと移行しつつあります。しかし現代の企業 IT の実情に目を向ければ、世界は 40 年にわたるアーキテクチャの流行が入り混じった、雑然として統制のないプロトコルのスープです。

1 つの組織の中に、おそらく次のようなものがあるでしょう。

統合とは、このプロトコルのスープの上に橋を架ける技術です。従来それは「アダプターサービス」、つまり HTTP 呼び出しを行うだけの小さく壊れやすい Node や Go のプログラムを書くことを意味していました。私たちはそれを「グルーコード」と呼んできました（グルーコード危機を参照）。これはエンジニアリングの速度に対する大きな負担です。

SchemaBridge では、これに Managed Gateway で取り組みます。REST スタイルの API 向けの設定可能な HTTP ゲートウェイで、ビジネスロジックを個々のエンドポイント実装から切り離します。これは意図的に 1 つのプロトコルをしっかりこなすものです（GET、POST、PUT、DELETE による HTTP）。GraphQL、gRPC、SOAP のクライアントは組み込まれていないため、それらのエンドポイントには HTTP の面を通じて到達するか、到達できないかのどちらかです。

Managed Gateway のアーキテクチャ

SchemaBridge のゲートウェイは単なるプロキシではありません。インフラの「接続メンテナンス」、つまりリトライ、レート制限、認証情報を引き受ける仲介者です。

レスポンスの正規化：JSONata ファーストのアプローチ

レスポンスをパースするコードを書く代わりに、ゲートウェイと TRANSFORMATION ステップを組み合わせます。

1. 呼び出し：GATEWAY vertex が外部サービスを呼び出し、結果を response.statusCode と response.body として返します。JSON のボディはパース済みで届き、それ以外は生の文字列として届きます。

2. マッピング：下流の JSONata 変換が、ワークフローに必要な特定のフィールドを抽出・再構成します。

これを一貫して行えば、ビジュアルロジックの残りの部分は、基盤となるソースの構造にかかわらず、あなたが定義したクリーンな形だけを扱うことになります。

適応型リトライポリシー：「3 回リトライ」の先へ

多くの開発者は「固定リトライ」ポリシー、つまり 1 秒間隔で 3 回リトライという方式を使っています。これはしばしば益よりも害をもたらします。負荷が原因でサービスがダウンしている場合、毎秒リトライするワーカー群は協調した DDoS 攻撃のように振る舞い、サービスの回復を妨げます。

SchemaBridge のゲートウェイは、バックオフを伴い、上限の範囲内でリトライします。

HTTP リトライの後もプロバイダーが過負荷のままなら、ステップはアドミッション制御を通じてさらに数回再ディスパッチされます（maxAutoRetries、デフォルトは 3）。それでもプロバイダーが失敗し続ける場合、ステップは無限にループするのではなく目に見える形で失敗し、プロバイダーの復旧後に再試行できます。

レート制限との戦いを制する：グローバルな同時実行制御

どの SaaS プロバイダーにもレート制限があります。単純なものもあります（毎秒 10 リクエスト）。100 のワーカーが統合を実行しているとき、制限を超えないようにどう協調すればよいでしょうか？

各ワーカーが自分のレートを個別に追跡しようとすれば、必ず制限を超えてブロックされます。SchemaBridge は、ディスパッチ時に適用されるワークスペース全体での宛先ごとの制限を提供します。

比較：従来の API ゲートウェイ vs. SchemaBridge ゲートウェイ

| 機能 | API ゲートウェイ（Apigee/Kong） | SchemaBridge Managed Gateway |

| :--- | :--- | :--- |

| 対象 | 受信トラフィック（ノース・サウス） | 送信（エグレス）のビジネス呼び出し |

| 状態 | 主にリクエスト単位（カウンター、キャッシュ） | 永続化された実行の上での上限付きリトライ |

| ロジック | スクリプト（Lua/JS） | ビジュアル（JSONata） |

| アイデンティティ | 認証の検証 | 送信時に注入されるシークレット（{{ secrets.NAME }}） |

ペイロードの正規化：アダプターサービスの終焉

このシリーズの前半で述べたように、データ変換のために専用サービスを書くのはシニアエンジニアの才能の無駄遣いです。ゲートウェイと共有の変換を組み合わせることで、正規化はリンクの特性になります。

この再利用を現実のものにするプリミティブが 2 つあります。custom app は、プロバイダーの接続設定（ベース URL、ヘッダー、認証）をワークスペースに一度だけ登録し、それを使うすべてのゲートウェイに事前入力します。永続化された変換ルールは、マッピングを ruleId の下に一度だけ登録し、同じレガシー ERP と通信するすべてのワークフローがそれを共有します。「技術的なオーバーヘッド」をプラットフォームに移し、「ビジネスロジック」をクリーンかつビジュアルに保てるのです。

例示シナリオ：レガシー API をモダンな Web へ移植する

注文管理システムを刷新しようとしている多国籍小売グループを考えてみましょう。

課題

中核となる在庫データが、何千もの店舗にまたがる不安定なレガシーシステムにあり、一方で新しい EC フロントエンドは React/Next.js アプリだと想像してください。手書きの「アダプターマイクロサービス」群で 2 つの世界をつなぐのは、複数四半期にわたる大規模な取り組みになるでしょう。

SchemaBridge のやり方

代わりに、チームが SchemaBridge のゲートウェイプリミティブを使う様子を思い描いてください。

1. ゲートウェイの設定：コードを書く代わりに、レガシーシステムを SchemaBridge の custom app として設定し、認証情報は暗号化されたシークレットストアに保管します。

2. ビジュアルロジック：プロダクトチームが「Check Inventory」のビジュアルグラフを直接構築します。

3. 組み込みのレジリエンス：ゲートウェイのバックオフ付きリトライがレガシーシステムの短い一時的な障害を吸収し、宛先ごとの制限がフロントエンドからのトラフィックでレガシーシステムが圧倒されるのを防ぎます。

想定される結果

未来：プロトコルに依存しない企業

API の具体的なプロトコルは実装の詳細であるべきで、ロードマップの障害であってはなりません。ゲートウェイを極めるモデルへと移行することで、私たちは「レガシーの亡霊」から解放されます。ビジネスロジックはクリーンで階層的な真実の土台の上に構築し、断片化したクラウドの雑然とした現実はインフラが引き受けるのです。

ゲートウェイ設計のためのエキスパートチェックリスト

統合レイヤーを設計する際は、外向きの接続について次のヒューリスティクスに従ってください。

1. プロトコルを隔離する：ビジネスロジックにプロトコル固有の実装の詳細を含めてはいけません。それらはゲートウェイとその変換ステップに抽象化しましょう。

2. 認証情報を金庫に入れる：認証ヘッダーを設定に直接貼り付けてはいけません。{{ secrets.NAME }} として参照し、リクエストがプラットフォームを出るときにだけトークンが注入されるようにしましょう。

3. バックオフし、上限を設ける：単に「1 秒後にもう一度リトライ」するのではなく、指数バックオフを使い、Retry-After を尊重し、宛先ごとに同時実行数を制限しましょう。クライアントを自分で制御できるなら、同期したリトライを分散させるためにジッターも加えましょう。

結論：橋とはゲートウェイである

インフラとは、ロジックを純粋に保つために雑然とした詳細を処理する技術です。ゲートウェイを極めることは、エンジニアリングの速度を過去の技術的負債から切り離すための最後のステップです。アダプターを書くのをやめ、橋を架け始めましょう。

「Building the Bridge」シリーズの関連記事：エラーからの復旧。障害を第一級のビジネスライフサイクルとして扱う方法について。

詳しく見る