← 戻る

Service Mesh は本当に必要か？集中型ゲートウェイで十分なケース

Yichun Zhang 投稿日 May 18, 2026 更新日 Aug 13, 2026

用時約24分

閲覧数

Service Mesh は本当に必要でしょうか？East-West トラフィックがレート制限のバラつき、認証基準の分裂、可観測性の死角に悩まされているなら、Istio を導入したくなるのは自然な発想です。しかし多くのチームにとって、その判断は時期尚早です——主要なネットワークノードに集中型ゲートウェイを配置すれば、Pod ごとのサイドカーも、コントロールプレーンを専任で運用するプラットフォームチームも不要で、同等のトラフィックポリシーを実現できます。ある大手 OTA プラットフォームは、この切り替えによりゲートウェイ運用を 7 名から 1 名に集約しました。

以下では、East-West トラフィック・ガバナンスの四大課題を分析し、Service Mesh と集中型ゲートウェイのアーキテクチャ選定を比較したうえで、内部 API 変更の全ライフサイクル——権限境界からワンクリック・ロールバックまで——に沿って、OpenResty Edge の各ステップでの具体的な手法を紹介します。

East-West トラフィックは North-South と何が違うのか

具体的な選定に入る前に、アーキテクチャの文脈におけるノース・サウス（外部）とイースト・ウェスト（内部）のトラフィック管理の違いを整理しましょう。内部トラフィック・ゲートウェイは、外部 WAF や従来のロードバランサーを単に内部に配置したものではありません。

外部ゲートウェイは「ゼロトラスト」を前提に、主に境界防御（DDoS、WAF）と高速化を担います。対して内部トラフィックの課題は、複雑なトポロジー関係とサービス間契約の管理にあります。

評価軸	外部トラフィック・ガバナンス（ノース・サウス）	内部トラフィック・ガバナンス（イースト・ウェスト）
トポロジー構造	比較的フラット（クライアント → ゲートウェイ → ビジネス層）	深くメッシュ状に絡み合う（マイクロサービス間の多段呼び出し）
信頼モデル	デフォルト拒否（Default Deny）	歴史的経緯によるデフォルト信頼（リスクの根源）
ガバナンスの重心	境界セキュリティ、高可用性、接続オフロード	ルーティング、きめ細かな認可、サービス劣化とサーキットブレーキング
トラフィック特性	突発的な大量アクセス、主に HTTP/S プロトコル	プロトコル多様（RPC/HTTP）、高頻度短時間通信と長寿命接続の共存
変更頻度	比較的低頻度、SRE/ネットワークチーム主導	極めて高頻度、各アジャイルチームの事業イテレーションに伴い継続的に変更

従来の nginx.conf 静的ファイルや手作業で維持する内部ネットワーク・ルーティングのモデルは、「集中型・低頻度変更」という設計思想を前提としています。これは、内部サービスが「管理主体が分散し、高頻度でリリースされる」という客観的な法則と、根本的に相容れません。

統一ガバナンスを欠く East-West トラフィックで何が起きるか

多くの企業のインフラ進化パスを観察すると、内部トラフィック・ガバナンスの欠如は、通常、次の四つの領域にわたる構造的リスクへと発展します。

暗黙の信頼とラテラルムーブメントのリスク

モノリスや初期のサービス化段階では、「内部ネットワークこそセキュリティ境界である」というのは妥協的な前提でした。しかしクラウドネイティブ環境下では、この前提は極めて脆弱です。

リスク露出：エッジアプリケーションがサードパーティコンポーネントの脆弱性（Log4j2、Fastjson など）により侵害されると、攻撃者はそのノードを踏み台に、内部ネットワークでラテラルムーブメント（Lateral Movement）を開始できます。内部ネットワークのサービス間には、アイデンティティベースのきめ細かなアクセス制御（RBAC/ABAC）が普遍的に欠けているため、コアデータサービスはしばしばあらゆる内部 IP に対して無防御の状態にさらされます。これは重大なデータセキュリティ上のリスクであるだけでなく、金融・医療などの業界が求める、ますます厳格化するコンプライアンス監査要件を満たすことも困難です。

レート制限・認証・リトライロジックの断片化

マイクロサービスの自律性を、非機能要件の領域まで拡大すべきではありません。統一されたデータプレーン・プロキシがなければ、各チームは業務コード内でゲートウェイ層の能力を重複実装せざるを得ません。

レート制限アルゴリズムの不統一：リーキーバケット、トークンバケット、単純なカウンタが混在します。
リトライストーム：グローバルな調整を欠くローカル・リトライ戦略は、下流サービスの性能劣化時にリトライストーム（Retry Storm）を極めて起こしやすく、システム全体を圧倒します。
認証標準の分裂：JWT、カスタム Header、認証なしが併存します。

この「サイロ型」の構築は全体の開発コストを押し上げるだけでなく、実装標準のばらつきにより、システム基盤に大量の安定性リスクを埋め込みます。

カナリアもロールバックもないリリース

内部コア API のイテレーション頻度は極めて高い水準にあります。動的ルーティングとトラフィック分割能力を欠くインフラでは、リリースのたびに事実上「全量トライアンドエラー」に近い状態になります。

動的ルーティングとトラフィック分割能力がなければ、リリースのたびに事実上「全量トライアンドエラー」となります。ロールバックコストは高くなり、エンジニアはリリースを恐れるようになり、最終的に全体のデリバリー速度が低下します。

可観測性のサイロ化が MTTR を押し上げる

障害発生時、調査効率はテレメトリデータ（Telemetry Data）の完全性に直接依存します。断片化したアーキテクチャでは、統一されたログ Schema がなく、エンドツーエンドの Trace ID 注入が欠け、メトリクス（Metrics）収集の粒度もバラバラです。三つのサービスを跨ぐ呼び出しタイムアウトを調査するには、運用担当者が複数の Kibana/Grafana ダッシュボード上でタイムスタンプを手作業で突き合わせる必要があります。平均復旧時間（MTTR）が高止まりする本質的原因は、エンジニアの経験不足ではなく、ツールチェーンの欠如にあります。

Service Mesh vs. 集中型ゲートウェイ：エンジニアリング上のトレードオフ

内部トラフィック問題の解決に向け、業界では通常、Sidecar ベースの Service Mesh（Istio など）と、集中型/マイクロセグメンテーション・ゲートウェイという二つの進化方向があります。

Service Mesh はプロキシを各 Pod レベルまで下げ、徹底した分散化を実現します。その代償として、コントロールプレーン運用の極めて高い複雑さ（Istiod の性能ボトルネックなど）と、無視できないネットワーク遅延（クラシックな sidecar モードでは、1 ホップの呼び出しが二度の Envoy プロキシホップを経由する）を払うことになります。

トップクラスのインフラチームをまだ持たない大多数の企業にとって、OpenResty Edge が代表する集中型かつ高度にプログラマブルな分散ゲートウェイは、より投資対効果（ROI）の高い道筋を提供します。明確なサービスドメイン境界（Domain Boundary）が存在するシナリオに適しており、重要なネットワークノードにクラスタを配置することで、統一統制を実現しつつ、Sidecar モードがもたらす認知負荷と計算リソースの浪費を回避できます。

この路線には、見過ごされがちな利点がもう一つあります。内部トラフィックと外部向けサービスの入口が同一のコントロールプレーンを共有できることです。同じ OpenResty Edge プラットフォームが、ノース・サウスのアクセスレイヤー——プライベート CDN、WAF 防御、外部向け API ゲートウェイ——を担うと同時に、内部ネットワークでイースト・ウェストのガバナンスも担えます。両方向のルーティング・認証・レート制限ポリシーを同一の Edge Admin コンソールで管理でき、変更フロー・権限境界・監査基準が自然に揃うため、内部ネットワーク用に別のガバナンス体系を構築する必要がありません。人的リソースの限られた中小規模のインフラチームでは、この効果はとりわけ顕著です。

内部 API 変更の全ライフサイクル——OpenResty Edge での実践

機能一覧を並べるだけでは意味がありません。以下では、実際の内部 API 変更を OpenResty Edge 上で一連の完全なフロー——権限の設定、設定変更、ステージングへのリリース、段階的なトラフィック移行、観測、ロールバック——に沿って辿り、内部トラフィック・ガバナンスの各ステップが実際の製品でどのように機能するかを見ていきます。

ステップ 1：権限境界の設定——誰がこの設定を変更できるのか

数十の事業ラインが一つの内部ゲートウェイを共有する場合、最初の関門はルーティングの設定方法ではなく権限です。A チームが B チームのアプリケーションを変更できてはなりません。「誰でも変更でき、変更しても誰も気づかない」共有環境は、それ自体が障害の温床です。イースト・ウェスト・トラフィックの「管理主体が分散し、高頻度でリリースされる」という特性から、権限境界はあらゆる設定に先立って存在しなければなりません。

OpenResty Edge では、権限はユーザーグループで決まります。システムには super admin、normal admin、normal user の三つのグループが組み込まれており、ユーザーは複数のグループに同時に所属できます。機能モジュールごとに読み取り/書き込み権限を個別に設定でき、「他のユーザーのデータを閲覧/変更できるか」（Read All / Write All）も区別できます。さらに最大レコード数やレコード種別の制限も可能です。アプリケーションの作成者は、そのアプリケーションの全モジュールの権限を自動的に保持します。他チームのメンバーが参加する場合は、アプリケーションレベルの User Access Control により単一アプリケーション単位で明示的に権限を付与します。既存の社内アカウント体系は LDAP 連携（ldaps と自動同期をサポート）でそのまま再利用できます。

これにより、設定変更の境界は組織の境界と一致し、権限逸脱や誤変更を源流で防げます。具体的な設定手順は、Web コンソールのユーザー管理とアクセス制御（OpenResty Edge）を参照してください。

ステップ 2：変更即リリース——すべての変更をレビュー可能・追跡可能に

多くのチームは今なお、Nginx 設定を手作業で変更して reload することで内部トラフィックを切り替えています。誰が・いつ・なぜこの行を変更したのか、後から調べる術がありません。また、同時接続数の多い長寿命接続の環境では、reload は worker プロセスの再起動（チャーン）と接続リセットも引き起こします。

OpenResty Edge は「設定の変更」と「設定の反映」を二つの操作に分離しています。変更は即座には反映されず、コンソールに未リリースの変更（pending changes）として表示され、リリース（Release）を経て初めてゲートウェイノードに配信されます。リリース時には変更の理由メモを記入でき、後日の検索と監査に役立ちます。リリース後、ルート、レート制限閾値、証明書など大多数のポリシーはデータプレーンのメモリ上でホットアップデートされ、reload による接続瞬断を回避できます。高頻度の変更は、もはや高リスクの操作ではありません。

具体的なバージョン管理とリリースのフローは、OpenResty Edge における Gateway Config のバージョン管理とリリース管理を参照してください。

ステップ 3：まず小規模な実トラフィックで検証——ステージング・ゲートウェイノード

新しいルートやレート制限ルールがリリースと同時に全ネットワークで有効になるのは、本番環境を実験場にするのと同じです。

OpenResty Edge では、特定のゲートウェイノードをステージング（Staging）ノードとしてマークできます。アプリケーションのリリース時にステージングノードのみへのリリースを選択でき、新しい設定をまず小規模な実トラフィックで動作させて観察し、問題がないことを確認してから残りのクラスタへリリースします。マークされたノードは一覧に Staging ラベル付きで表示され、一目で識別できます。

具体的な操作は OpenResty Edge におけるステージングゲートウェイサーバーの使用方法を参照してください。

ステップ 4：制御された段階的移行——カナリア、A/B テスト、トラフィックミラーリング

ステージング検証を通過しても、コア内部 API を一気に新バージョンへ切り替えるべきではありません。呼び出し量の大きい API では、1% から 100% までのすべての段階を制御する価値があります。

Page Rules で upstream の重みを調整するか、特定の HTTP Header などのリクエスト特性に基づいてテスト・トラフィックを新バージョンへ誘導することで、移行のペースを完全に制御できます。A/B テストの設定も同じバージョン管理下にあり、レビューとロールバックが可能です。より強い分離が必要な場合は、専用のゲートウェイノード群を確保して A/B トラフィックを受けることもできます（後述のゲートウェイ・パーティションを参照）。

新バージョンを正式に投入する前に実データで検証したい場合は、トラフィックミラーリングを利用できます。本番メイン経路の応答に影響を与えることなく、ゲートウェイがバックグラウンドで実トラフィックを非同期に複製し、プレ本番環境へ送ります。詳細は OpenResty Edge のミラーリクエスト機能が、セキュリティとパフォーマンスの両立を実現を参照してください。

ステップ 5：全過程の可視化——実クライアント IP、動的メトリクス、統一ログ

段階的移行における判断の根拠はデータです。しかし K8s と多層プロキシ（LB、Ingress、ゲートウェイ）の背後では、ログに記録されるのはプロキシや Pod の IP ばかりで、障害調査時に実際の呼び出し元と突き合わせられず、レート制限や認証も正確な送信元情報を失います。さらに、三つのサービスを跨ぐ呼び出しタイムアウトの調査には、複数のダッシュボードでタイムスタンプを手作業で突き合わせる必要があります。

OpenResty Edge はこの段階で三つの機能を提供します。

実クライアント IP の復元：信頼ホストリストを設定すると、TCP 接続の対向ノードが信頼リストに含まれる場合にのみ、リクエストヘッダによる送信元 IP の書き換えを行います。クライアント IP は X-Forwarded-For ヘッダから抽出できます。信頼できるプロキシチェーンの背後で実際の送信元を正確に復元でき、ログ・レート制限・認証のすべてが実アイデンティティに基づくものになります。詳細は OpenResty Edge で真のクライアント IP アドレスを正確に復元するを参照してください。
動的メトリクス：SQL ライクな構文（Metric SQL）でビジネスメトリクスをリアルタイムに定義・集約できます。特定の上流 API の P99 レイテンシのクエリなども、コード変更や再デプロイなしで可能です。詳細は OpenResty Edge における標準動的メトリクスの使用方法を、応用はカスタム動的メトリクスを参照してください。
統一構造化ログ：すべてのサービス間トラフィックが必ず通過するゲートウェイが、フォーマット統一された構造化アクセスログを自動生成し、チームごとのログ Schema の分裂を解消します。OpenTelemetry 標準の Trace ID 注入・透過もサポートし、既存の APM システムと連携できます。ログ設定は OpenResty Edge でゲートウェイのアクセスログファイルを設定するを参照してください。

ステップ 6：問題発生時——ワンクリック・ロールバック

移行中にメトリクスの異常を検知したとき、最も重要なのはただ一つ、既知の正常な状態へ最短時間で戻すことです。ロールバックのコストが低いほど、エンジニアは安心してリリースできます。

OpenResty Edge は任意の過去のリリースへ復元できます。revision 履歴は読み取り専用で改ざん不可であり、コンソールは人間が読めるバージョン間差分を提供します。ロールバック前に、どの変更が取り消されるのかを正確に把握できます。前述のステージング検証・カナリアと組み合わせることで、「小さくリリースし、問題があれば即座に戻す」という完全なループが成立します。ロールバック操作とバージョン比較は同じくバージョン管理とリリース管理を参照してください。

長期運用：ヘルスチェック、サーキットブレーキング、レート制限

変更対応の枠外でも、内部の呼び出し経路の日常的なレジリエンスには統一的なバックストップが必要であり、各業務チームが品質のばらつくフォールトトレランス・コードを自前で実装すべきではありません。この耐障害性は二層に分かれます。ゲートウェイによる上流業務ノードの障害対応と、コントロールプレーンによるゲートウェイノード自身の監視です。まず前者から見ていきます。

上流のアクティブ/パッシブ・ヘルスチェック：ゲートウェイがアクティブプローブとパッシブなトラフィック・フィードバックを組み合わせ、異常な上流業務ノードを自動的に除外し、高可用性の SLA を確保します。
サーキットブレーキングとフェイルファスト：上流のエラー率やレイテンシが閾値に達すると自動的にサーキットを開き（Fail-Fast）、下流のスレッドプール枯渇やリトライストームによるシステム崩壊を防ぎます。
統一レート制限：ゲートウェイレイヤーで統一されたアルゴリズムとカスタムキーによるレート制限を実施し、各業務に散在するリーキーバケット/トークンバケットの混在実装を置き換えます。詳細は OpenResty Edge におけるカスタムキーを使用したリクエストレート制限を参照してください。

もう一つの層は、ゲートウェイノード自身の健全性です。Edge Admin コントロールプレーンが各ゲートウェイノードを継続的にプローブし、プローブに失敗したノードはコンソール上で赤色の警告表示となり、DNS 解決から自動的に除外されます。人手の介入は不要です。詳細は OpenResty Edge でゲートウェイサーバーの自動ヘルスチェックを有効にするを参照してください。

gRPC 中心の内部呼び出しチェーンに対しては、ゲートウェイが gRPC プロキシをネイティブサポートし、上記のサーキットブレーキング・ヘルスチェック・レート制限も同様に適用できます。これは前述の「プロトコル多様」というイースト・ウェスト・トラフィックの特性に対応する基盤です。

複数チームでのゲートウェイ共有——パーティションと権限の二重分離

複数のアジャイルチームが同一のゲートウェイ・インフラを共有する場合、リソースの奪い合いと設定の誤上書きが中核的な課題です。ステップ 1 のユーザーグループとアプリケーションレベルのアクセス制御が担うのは論理分離です。OpenResty Edge のゲートウェイ・パーティション（Gateway Partition）はさらに物理分離を提供します。各ゲートウェイノードは管理登録時に一つのパーティションにのみ所属し、パーティションごとに独立した設定空間を持ち、変更は当該パーティション内のクラスタとノードにのみ配信されます。特定のアプリケーションを指定パーティションのみにリリースでき、パーティション単位でポートを設定し、ポートごとに Proxy Protocol を有効化することも可能です。

各事業ラインは自パーティション内で独立したアプリケーション、Page Rules、クォータを維持でき、統一コントロールプレーンを再利用しつつ、チーム間の設定誤上書きを回避し、障害の爆発半径を縮小します。専用パーティションで前述の A/B テスト・トラフィックを受けることもできます。パーティションとクラスタの階層関係および設定実践は、OpenResty Edge でゲートウェイパーティションを使用する方法を参照してください。

認証オフロードと East-West ゼロトラスト

上記のライフサイクルとは別に、セキュリティベースラインには特筆すべき価値があります。事業ラインに散在する認証ロジックを上位層へ引き上げ、ゲートウェイレイヤーへオフロードすることは、内部ゼロトラスト・アーキテクチャ（ZTA）を円滑に導入する第一歩です。サービス間呼び出しには JWT のステートレス署名検証（OAuth2/OIDC 発行のトークンなど）を、従業員アクセスには OIDC 連携を適用できます。セキュリティ要件の極めて高いコア経路では、ゲートウェイが双方向 TLS（mTLS）を有効化し、x509 クライアント証明書によるマシン・アイデンティティ認証をサポートします。さらに OpenResty Edge は TLS ハンドシェイク特性に基づく JA4 フィンガープリント識別をサポートしており、双方が正規の証明書を提示している場合でも正当な内部サービスと不正なクライアントを識別でき、IP ホワイトリストを補完します。セキュリティ防御は「静的 IP ホワイトリスト」から「動的アイデンティティと行動検証」へと進化します。

いつ始めるべきか：三段階の導入パス

複雑な技術的負債の解消において、既存システムの全面刷新は得策ではありません。内部トラフィック管理基盤の構築は、「スモールスタート・段階的な改善」を基本方針とすべきです。

このアプローチの有効性は、実際のエンジニアリングデータによって裏付けられています。数千名規模の HR SaaS プラットフォームでは、OpenResty Edge への移行後、API ガバナンス基盤の TCO が 80% 削減され、設定反映時間が時間単位から分単位へと短縮されました。また、大手 OTA プラットフォームでは、ゲートウェイ運用を 7 名の日次ローテーションから 1 名体制へ集約し、残りのメンバーをプロダクト開発へ振り向けることに成功しました。さらに Qunar.com（去哪儿网）は、1 日あたり百億件規模の呼び出しを処理する環境において、設定変更時のコネクションへの影響をゼロに抑え、運用コストを 90% 削減しています。これらの成果は、一度の大規模リファクタリングによって得られたものではなく、フェーズを区切り、計画的に段階移行を積み重ねた結果です。

「段階的な改善」は、実践上、以下の 3 つのフェーズに分解できます。

フェーズ 1：可観測性とセキュリティベースラインの確立を優先します。ゲートウェイレイヤーで JWT 認証、実クライアント IP の復元、標準的なアクセスログ収集を一元的に導入することで、アプリケーション側のコード変更を一切行わずに、認証なしの無防備な状態や障害調査のブラックボックス化を迅速に解消します。
フェーズ 2：トラフィック分割とフォールトトレランス（障害耐性）の導入を推進します。CI/CD パイプラインと連携し、「ステージング検証—カナリアによる段階的移行—ワンクリック・ロールバック」をチームの標準リリースフローとして定着させ、障害の爆発半径を制御します。
フェーズ 3：ゼロトラストアーキテクチャとマルチテナント分離を実装します。機密性の高いサービスノードに mTLS を適用し、ゲートウェイ・パーティションによって各事業ラインの物理ノードと設定空間を分離します。ルーティング・認証・レート制限といったポリシーの統合管理を組織標準として確立し、Edge Admin の承認フローおよび API を通じて既存の運用プロセスとシームレスに統合します。

ネットワークとトラフィックスケジューリングの複雑性を、統一されたインフラストラクチャレイヤーへと集約することは、クラウドネイティブ化における必然的な進化の方向性です。システムの安定性とセキュリティを、個々の開発者の意識や自助努力に依存しない体制が整って初めて、マイクロサービスアーキテクチャはビジネスアジリティを真に発揮できるようになります。

社内トラフィック管理ソリューションの導入をご検討中の方は、ぜひ OpenResty Edge チームまでお問い合わせください。お客様の具体的なユースケースに即した技術的なご提案をいたします。

よくある質問（FAQ）

Q: 内部（イースト・ウェスト）ゲートウェイと外部（ノース・サウス）ゲートウェイは一つのシステムで共用できますか？ A: できます。OpenResty Edge は単一のコントロールプレーンでノース・サウスとイースト・ウェストの両トラフィックを管理し、変更フロー・権限境界・監査基準を完全に統一できます。分離が必要な場合は、ゲートウェイ・パーティションにより内部向け・外部向けアプリケーションを別々の物理ノードグループへ配置できます。

Q: 集中型内部ゲートウェイの導入は Service Mesh と競合しますか？ A: 競合しません。両者は排他的な関係ではありません。Service Mesh は Pod レベルの徹底した分散化を追求しますが、その代償としてコントロールプレーンの運用複雑性と sidecar による追加レイテンシが生じます。明確なサービスドメイン境界を持つ多くの企業にとっては、重要なネットワークノードへの集中型ゲートウェイ配置の方が投資対効果に優れ、将来のよりきめ細かなガバナンスへ進むための現実的な出発点にもなります。

Q: 内部トラフィック・ガバナンスはどこから着手すべきですか？ A: 可観測性とセキュリティベースラインから始めることを推奨します。ゲートウェイレイヤーでログ収集・実クライアント IP 復元・JWT 認証を一元導入すれば、業務コードを一切変更せずに効果を得られます。その先の三段階の導入パスの全体像は、上記の結論セクションをご覧ください。

Q: Service Mesh を使うべきでないのはどんな場合ですか？ A: サービスのドメイン境界が明確で、Mesh コントロールプレーンを専任で運用するプラットフォームチームがいない場合です。主要なネットワークノードに集中型ゲートウェイを配置すれば、Pod ごとのサイドカーも Istiod の運用負荷もなく、レート制限・認証・カナリアリリース・可観測性といったトラフィックポリシーを実現できます。まずここから始め、Pod レベルの分散化が本当に必要になった段階で Mesh を検討してください。

Q: マイクロサービスに Service Mesh は必須ですか？ A: 必ずしもそうではありません。マイクロサービスの多くの課題——レート制限のバラつき、認証基準の不統一、カナリアやロールバックの欠如、可観測性のサイロ化——はインフラガバナンスの欠如であり、Pod ごとのサイドカーが必須というわけではありません。集中型ゲートウェイならより低い運用コストでこれらを解決できます。

Q: Service Mesh なしで East-West トラフィックをどう管理しますか？ A: 主要な内部ネットワークノードに集中型プログラマブル・ゲートウェイを配置し、サービス間通信の必須データプレーンとします。ルーティング、JWT/mTLS 認証、レート制限、サーキットブレーキング、構造化ログを統一的に実行し、すべて North-South トラフィックも同時にカバーする単一のコントロールプレーンで管理します。設定変更はデータプレーンのメモリ上でホットアップデートされ、コネクションの断絶はゼロ——手動の Nginx 運用で reload が引き起こすフラッピングを根本的に排除します。

OpenResty Edge について

OpenResty Edge は、マイクロサービスおよび分散トラフィック・アーキテクチャ向けに設計されたオールインワン型ゲートウェイ・ソフトウェアで、自社開発の製品です。トラフィック管理、プライベート CDN 構築、API ゲートウェイ、セキュリティ防御などの機能を一体化し、モダンなアプリケーションの構築・管理・保護を容易にします。OpenResty Edge は業界トップクラスの性能と拡張性を備え、高負荷シナリオの厳しい要求に応えます。K8s などのコンテナアプリケーション・トラフィックのスケジューリングをサポートし、大量のドメイン管理も可能で、大規模 Web サイトや複雑なアプリケーションの要求を容易に満たします。

OpenResty Edge の試用を申請する

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty^® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省の出身で、現在は米国ベイエリアに在住しています。中国における初期のオープンソース技術と文化の提唱者・リーダーの一人であり、Cloudflare、Yahoo!、Alibaba などの国際的なハイテクノロジー企業に勤務した経験があります。「エッジコンピューティング」「動的トレーシング」「マシンプログラミング」の先駆者でもあり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を有します。世界で 4,000 万以上のドメインに採用されているオープンソースプロジェクトのリーダーとして、OpenResty^® を基盤に、米国シリコンバレーの中心部に OpenResty Inc. を創設しました。同社の主力製品である OpenResty XRay（動的トレーシング技術を活用した非侵入型のプロファイリングおよびトラブルシューティング製品）と OpenResty Edge（マイクロサービスおよび分散トラフィック向けの統合ゲートウェイソフトウェア）は、世界各地の上場企業および大企業に広く採用されています。OpenResty 以外にも、Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、多数のオープンソースプロジェクトに累計 100 万行超のコードを寄与し、60 件を超えるオープンソースソフトウェアライブラリを手がけています。