← 戻る

WAF 性能比較：OpenResty Edge は ModSecurity の 3.7〜10 倍（208 ルール）

章亦春投稿日 Dec 15, 2025 更新日 Aug 4, 2026

用時約13分

閲覧数

同一の 208 のセキュリティルールをすべて有効にし、1 つの CPU コアのみを使用する条件下で、OpenResty Edge は約 5300 RPS のスループットを維持します。これは ModSecurity Nginx 版（約 1400 RPS）の 3.7 倍であり、リクエストが複雑になるほど差は 10 倍以上に拡大します。その理由は、ルールが 1 つずつ解釈実行されるのではなく、リクエストデータを一度だけスキャンする形にコンパイルされるからです。

本記事では、この WAF 性能ベンチマークの全データ、その背後にあるコンパイラ技術（正規表現ルールの単一 DFA への統合、EdgeLang によるグローバルルール最適化）、そしてエッジに WAF を導入する 4 つのステップを解説します。

OpenResty Edge の試用を申請する

ベンチマーク：1 CPU コアに 208 の WAF ルール

テスト環境：

1 つの Worker プロセス、1 つの CPU コアを使用
すべてのシステムに同一の 208 の WAF ルールをロードし、完全に有効化
比較対象：OpenResty Edge WAF と ModSecurity Nginx 版。あわせて ModSecurity Apache 版と OpenResty 上の lua-resty-waf も測定
測定指標：リクエストあたりの URI パラメータ数（URI Args、x 軸）の増加に伴う、1 秒あたりのリクエスト数（RPS、y 軸）の変化——パラメータが多いほど、WAF が検査すべきリクエストデータが増えます

ModSecurity Nginx 版を主な比較対象としたのは、自前で構築する Nginx 用 WAF の事実上のベースラインであり続けているためです。

テスト結果：

URI パラメータ 1 個の場合： OpenResty Edge のスループット（約 5300 RPS）は、すでに ModSecurity Nginx 版（約 1400 RPS）の 3.7 倍です。
パラメータ 20 個の場合： ModSecurity の性能は急激に低下し、スループットは約 150 RPS まで落ち込み、サーバーリソースは枯渇しました。
パラメータ 100 個の場合： この極端な負荷の下でも、OpenResty Edge は約 1500 RPS を維持しました。これは ModSecurity が最も負荷の低い状態で示す性能をも上回る数値です。

これが実運用で意味すること：

ユーザー体験： 同等のハードウェアで 208 のルールをすべて有効にしても、セキュリティと速度の間で妥協する必要はありません。ユーザーは完全な WAF 保護を受けながら、サイトの表示速度を犠牲にしません。

コスト： OpenResty Edge は、競合製品が数個から十数個のコアを必要とするスループットを、わずか 1 つの CPU コアで達成します。より少ないコアでより多くのトラフィックを処理することで、クラスター規模と AWS/GCP/Azure の月額費用を直接削減できます。

ルール数が WAF 性能を損なわない理由

従来の WAF は静的な設定ファイルや低効率なスクリプトに制約され、ルールを 1 つずつ順番に評価します。ルールを追加するたびにリクエストデータへのスキャンが 1 回増え、レイテンシはルールセットの規模に応じて増加します。上のベンチマークが示すのは別のアプローチです——ルールセット全体を事前にコンパイルすることで、ロードされたルール数に関係なく、リクエストデータのスキャンは一度で済みます。

EdgeLang でルールをゲートウェイネイティブコードにコンパイルする

OpenResty Edge は、当社が独自開発した EdgeLang を導入しています。高性能ゲートウェイ向けに設計されたドメイン固有言語（DSL）であり、手書きの Lua コードよりも大幅に簡潔で、しかも高速です：

最適化されたコード生成： EdgeLang コンパイラは、ルールを高度に最適化された Lua コードへ変換し、ゲートウェイサーバー上で実行します。アルゴリズム最適化と精緻なコード生成戦略により、実行速度は通常、手書きの Lua コードよりも高速です。
グローバルルール最適化： コンパイラはルールを順番に実行するのではなく、すべてのルールを包括的に統合・最適化し、ルールセット全体にわたる複雑な相互作用を簡素化します。

ルールが何個あっても、リクエストのスキャンは一度だけ

2 つのマッチング技術により、ルール数とスキャンコストが切り離されています：

正規表現の統合（Regex Merging）： コンパイラはすべての正規表現ルールを 1 つの包括的な決定性有限オートマトン（DFA）に統合します。ルールの数に関係なく、システムはリクエストデータを一度スキャンするだけで、マッチするすべてのルールとその位置を特定できます。
文字列ツリー（String Trees）： すべての定数文字列のプレフィックス／サフィックスパターンは、統一された高効率なツリー構造にまとめられ、検索を高速化します。

これが、ルールセットの規模がもはや性能のボトルネックにならない理由です。

性能を犠牲にしない拡張性

EdgeLang は孤立した存在ではありません。カスタム Lua モジュールやコードを直接呼び出せるため、既存のビジネスロジックを再利用できます。また、一般的なセキュリティ保護、データ処理、ネットワーク操作をカバーする豊富なプリコンパイル済みライブラリを備えています。コンパイラによって得られた性能を犠牲にすることなく、ビジネスを考慮した複雑なセキュリティポリシーを編成できます。

ルールを無効化せずに WAF の誤検知を抑える

WAF の誤検知という業界共通の課題に対し、当社は多段階の感度調整機能を提供しています。運用チームはルールをオフにするのではなく、状況に合わせて対応できます：

セキュリティ演習／ペネトレーションテスト期間： 感度を厳格モードに引き上げ、ブロックが増えても安全性を最優先します。
ビジネスピーク時： 感度をバランスモードに下げ、正規ユーザーへの影響を最小限に抑えます。
通常運用時： 標準モードを使用し、安全性と可用性のバランスを取ります。

感度をリアルタイムに調整することで、誤検知がビジネスに与える影響を最小化できます。完璧な解決策ではありませんが、現時点で最も実用的な戦略です。

エッジに WAF を導入する 4 つのステップ

ステップ 1：全体的なセキュリティ基盤を確立する

具体的なアプリケーションに保護を設定する前に、まず統一されたグローバル WAF ルールを確立します。これにより、すべてのサービスに基本的なセキュリティレベルが提供され、一般的で広範囲な攻撃を効率的にブロックできます。

グローバル WAF ルールの設定方法

ステップ 2：コアアプリケーションに専用の保護を有効にする

グローバルルールを確立した後、最も重要なアプリケーションに対して WAF 機能を有効にします。有効にすることで、設定されたルール（グローバルルールかアプリケーション専用ルールかに関わらず）が実際に適用されます。アプリケーションの WAF を有効にする。

ステップ 3：正確な許可設定でビジネスへの影響を回避する

WAF 保護を有効にした後、正常なビジネスリクエストが誤ってブロックされる場合があります。ビジネスの継続性を確保するため、ホワイトリストを設定し、信頼できるリクエストをブロックルールから正確に除外してください。

アプリケーションの WAF ホワイトリストの設定方法

ステップ 4：カスタムルールで完全な柔軟性を手に入れる

複雑なビジネスシナリオや高度なセキュリティ要件に対しては、標準の WAF ルールでは柔軟性が不十分な場合があります。EdgeLang を使えば、リクエストの任意のパラメータ（Header、Cookie、URL など）に基づいて動的で詳細な WAF ルールを記述し、高度にカスタマイズされた保護ロジックを実現できます。

Edgelang を使用した WAF ルールの定義

これらのステップに従うことで、グローバルからローカルまで網羅的で、汎用からカスタマイズまで適応可能な防御体制を構築できます。

CDN・WAF・API ゲートウェイを一体化：統合アーキテクチャの利点

従来のアーキテクチャでは、WAF は各機器の間に挟まれた独立した境界アプライアンスとして扱われます。OpenResty Edge はそうではなく、プライベート CDN、WAF、API ゲートウェイを 1 つのソフトウェアスタックに統合したプラットフォームを構築し、各レイヤーが最も得意な役割を担います：

CDN——最外層： 静的リソースをユーザーの近くにキャッシュし、分散した帯域幅を活かして、大規模な L3/L4 DDoS 攻撃が後段のシステムに到達する前に吸収します。WAF の最初の防衛線です。
WAF——検査層： CDN ノードの直後（または内部）に位置し、リクエストがどのバックエンドに向かうかに関わらず、SQL インジェクション、XSS、悪意のある Cookie などの脅威をすべてのリクエストについて検査します。
API ゲートウェイ——ビジネス層： リクエストを認証（OAuth/JWT）し、適切なマイクロサービスへルーティングし、ユーザー単位・API 単位のクォータを適用します。

3 つのレイヤーがすべて単一の Worker プロセス内で動作するため、このアーキテクチャは 2 つの具体的なメリットをもたらします：

コンポーネント間のネットワークホップがゼロ： 分離型の構成では、トラフィックは CDN、WAF、ゲートウェイの各機器間を行き来し、ホップのたびにネットワーク I/O と遅延が加わります。統合モデルでは、キャッシュ、セキュリティ検査、ルーティングが 1 つの Worker プロセス内で完結します——データはレイヤー間でネットワーク境界を一切越えません。これは遅延に敏感なアプリケーションにとって特に重要です。
運用するプラットフォームは 1 つだけ： 複数の異種システムを管理するということは、それぞれに個別の設定、監視、アップグレード、トラブルシューティングが必要になるということです。統合スタックなら、1 つのプラットフォームでエッジトラフィックのライフサイクル全体をカバーできます。

このアーキテクチャの上に構築することで、セキュリティは配信パイプラインに後付けされた外部制約ではなくなります。ルールはネイティブコードにコンパイルされるため保護ロジックがボトルネックになることはなく、セキュリティポリシーは保護対象のビジネスコンテキストを踏まえて記述できます。

FAQ：WAF の性能

WAF はサーバーをどれくらい遅くしますか？

WAF がルールをどう評価するかによります。ルールを 1 つずつ解釈するエンジンは、ルール数とリクエストの複雑さが増すにつれて性能が低下します——当社のベンチマークでは、URI パラメータが 1 個から 20 個に増えると、ModSecurity Nginx 版は約 1400 RPS から約 150 RPS まで落ち込みました。一方、OpenResty Edge のように各リクエストを一度だけスキャンするコンパイル型 WAF は、208 ルール有効・パラメータ 100 個でも約 1500 RPS を維持しました。

WAF のルール数はリクエストを遅くしますか？

従来の逐次実行エンジンでは、遅くなります——ルール 1 つごとにリクエストデータへのスキャンが 1 回増えるためです。OpenResty Edge はこの結び付きを解消しています。EdgeLang コンパイラがすべての正規表現ルールを単一の DFA に、すべての定数文字列パターンを 1 つのツリー構造に統合するため、ロードされたルール数に関係なく、リクエストデータのスキャンは一度だけです。

OpenResty Edge は ModSecurity と比べてどれくらい速いですか？

同一ハードウェア（1 CPU コア、208 ルール有効）で、最もシンプルなケースにおいて OpenResty Edge は約 5300 RPS、ModSecurity Nginx 版は約 1400 RPS でした——3.7 倍です。リクエストが複雑になるにつれて差は 10 倍以上に拡大しました。URI パラメータ 20 個で ModSecurity は約 150 RPS まで低下した一方、OpenResty Edge はパラメータ 100 個でも約 1500 RPS を維持しました。

なぜオリジンではなくエッジで WAF を動かすのですか？

エッジ WAF はトラフィックがオリジンのインフラに入る前に検査するため、攻撃は発生源に近い場所でブロックされ、オリジンは悪意のあるリクエストにリソースを一切費やしません。OpenResty Edge の統合アーキテクチャでは、さらに CDN 層が大規模な L3/L4 DDoS 攻撃を先に吸収し、WAF の検査はキャッシュやルーティングと同じ Worker プロセス内で実行されます——セキュリティ層のための追加のネットワークホップは発生しません。

ルールを無効化せずに WAF の誤検知を減らすには？

OpenResty Edge では 2 つの仕組みが連携します。多段階の感度レベル（ペネトレーションテスト期間は厳格モード、ビジネスピーク時はバランスモード、通常運用は標準モード）によりブロックの強度をリアルタイムに調整でき、アプリケーション単位のホワイトリストにより、信頼できるリクエストだけを正確にブロックルールから除外しつつ、それ以外への保護は維持されます。

OpenResty Edge について

OpenResty Edge は、マイクロサービスと分散トラフィックアーキテクチャ向けに設計された多機能ゲートウェイソフトウェアで、当社が独自に開発しました。トラフィック管理、プライベート CDN 構築、API ゲートウェイ、セキュリティ保護などの機能を統合し、現代のアプリケーションの構築、管理、保護を容易にします。OpenResty Edge は業界をリードする性能と拡張性を持ち、高い同時接続数・高負荷のシナリオの厳しい要求を満たすことができます。K8s などのコンテナアプリケーショントラフィックのスケジューリングをサポートし、大量のドメイン名を管理できるため、大規模ウェブサイトや複雑なアプリケーションのニーズを容易に満たすことができます。

OpenResty Edge の試用を申請する

著者について

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

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty^® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay（動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール）と OpenResty Edge（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。