OpenResty Edge には DDoS 防御機能が内蔵されています。独立したセキュリティ製品ではなく、プラットフォーム・インフラの一部であり、ゲートウェイ、ノード、Agent と同一のデリバリーおよび運用体系を共有します。中核目標は、カーネルの整合性を損なわない前提で、千万規模の PPS に耐えうる防御能力を本番環境へ直接組み込むことです。 本稿では、その設計思想、多段の防御モデル、コンソール機能を紹介します。その前提として、まず対象とする中核的なエンジニアリング課題を簡潔に整理します。

1. DDoS 防御の「不可能の三角」

DDoS 防御が外周のパッチからシステムのホットパスへ組み込まれると、技術チームは長年の「不可能の三角」—次の三つを同時に満たすことの難しさ—に直面します。

1. 極限のスループット性能
2. カーネルとエコシステムとの互換性
3. 長期的なエンジニアリング上の保守可能性

既存のアプローチは、そのうち一つか二つを満たし、三番目の次元で代償を払うことが少なくありません。

1.1 カーネルバイパス型：高性能だがシステム整合性を犠牲にする

高い PPS の攻撃下で極限性能を得るため、カーネルのネットワークスタックを迂回し、防御ロジックを NIC 近傍へ押し出す方式があります。性能課題は解消されますが、代償は次のとおりです。

• ネットワーク経路が二つの体系に分裂する
• 既存の監視・診断・運用ツールが機能しなくなる
• 防御システム自体が、手を出しにくい特殊コンポーネントになる

一度きりの性能最適化が、長期的なシステム複雑さと運用リスクをもたらします。

1.2 純カーネル型：互換性は高いが性能の天井が明確

別の系統は、防御ロジックを既存のカーネル枠組み内に厳密に留めます。ネットワーク構成を変えず、追加のランタイムを導入せず、成熟したカーネル機構を完全に再利用します。エンジニアリング上は受け入れやすい一方、処理経路は固定され、性能上限も固定されます。

真に高頻度の攻撃下では CPU がすぐにボトルネックとなり、攻撃が完全に識別される前に防御側が先に限界に達する恐れがあります。

1.3 ハイブリッド：理論上は可能だがエンジニアリング上の複雑さが抑えきれない

理論上の最適は、防御を十分に手前に置きつつシステム整合性を壊さない状態ですが、現実には次のような帰結を招きがちです。

• OS のバージョンと機能への強い依存
• 制約の多いプログラミングモデルと実行環境
• デプロイ・アップグレード・ロールバックの標準化の難しさ

技術的には実現可能でも、エンジニアリング上は再現が難しく、大規模本番で長期運用するのはなおさら困難です。 システムが安定稼働すると、チームはしばしばそれを敬遠します。高リスク・高メンテナンス負荷の中核コンポーネントを、誰も軽々とは触りたがらないのです。

2. OpenResty Edge の設計：三つの目標を同時に満たす

設計の立脚点は、物理限界への挑戦ではなく、エンジニアリング価値の高い次の位置づけです。カーネルの整合性を損なわない前提で、カーネルが提供する最先端のデータ処理能力を最大限に活用する。 上記の「不可能の三角」の各次元に対し、次の原則で応えます。

注力の中心は、「さらに速くできるか」から、千万規模の PPS を処理する能力を、安全かつ安定して本番へ展開し、管理・保守しやすくできるかへと移ります。

2.1 「四層連携防御」：グローバル基線から単一 NIC まで

OpenResty Edge は、防御設定を上から下へと四つの階層に分け、実ネットワークトポロジに整合させます。大企業環境における責務分担と運用領域の切り分けを容易にします。

• グローバル（Global）：Edge ネットワーク全体の既定となる SYN PPS、DNS RPS などの上限・下限の基線を設定し、下流のすべてのエンティティに対するセーフティネットとする。新規に接続したクラスタが個別にチューニングされていない場合も、この層の基礎防御を継承する。
• クラスタ（Cluster）：ワークロードまたは地域単位で分離する。例として、test-yuannn のようなテスト用クラスタに対し、実際の業務規模に応じて防御パラメータのみを微調整し、他のクラスタへ影響を与えないようにできる。
• ノード（Node）：クラスタ内の 1 台に対する重点的な強化。性能が相対的に限定的なサーバや、標的型の攻撃を受けているノード（例：jenkins-slave-2）では、この階層でだけポリシーを締めたり緩めたりできる。
• ネットワークインターフェース（Interface）：防御を単一の NIC まで下げられる。ハイブリッドクラウドやコンテナ環境では、Kubernetes で一般的な cni0 など特定のコンテナ用 NIC に個別の上限を設定し、あるマイクロサービス区間の分離と保護を実現できる。

2.2 設定の継承と必要に応じた上書き

複数階層が併存する場合、OpenResty Edge は 継承（Inherit） 機構により、設定の重複と誤設定のリスクを下げます。

• クラスタやノードなどの階層では Inherit を選択し、ひとつ上の階層の防御方針をそのまま引き継げます。項目を逐一やり直す必要はありません。
• あるノードやインターフェースで例外が必要な場合にのみ、Enabled や Disabled などのモードへ切り替えて上書きし、**「グローバルでは既定を統一し、局所のみ必要に応じてカスタマイズする」**という運用上のモデルを実現します。

2.3 SYN および DNS フラッドのきめ細かなパラメータ

インターフェース階層および対応する設定パネルでは、攻撃ベクターをきめ細かく制御できます。例は次のとおりです。

• SYN フラッド：グローバルなレート制限（最大／最小 PPS）に加え、IP あたりの SYN レート（SYN/IP/s）、IP あたりの ACK レート（ACK/IP/s） を設定できます。また、特定のポート（例：80）に対して個別に監視し、上限を設けられます。
• DNS フラッド：全体の 1 秒あたりのクエリ数（RPS）、IP あたりのクエリレート（DNS/IP/s） を制限できます。さらに、適用範囲を ドメイン（Domains） および IPv4 アドレス範囲 で限定し、偽装された送信元を利用した増幅攻撃や乱用を抑制します。
• 自動検出モード（Auto detect attack mode）：ワンクリックで有効化すると、リアルタイムのトラフィックモデルに基づき、防御をいつ介入させるかを自動判定します。後述する攻撃と防御の自動化されたクローズドループと整合します。

3. 性能はスローガンではなくエンジニアリング上の事実

性能は、定量評価でき、再現可能なエンジニアリング上の事実であるべきであり、マーケティング上のスローガンではありません。

3.1 ベンチマーク性能と費用対効果

低スペックのクラウドインスタンス（例：AWS t3.small）において、専用ハードウェアや特別なシステム設定に依存せず、小さなパケットの UDP / TCP SYN フラッドを処理する場合、17〜18 万 PPS を実測で安定して処理できます。

この数値は、データ経路の最適化とアーキテクチャ上の適切な配置により、汎用ハードウェア上でも極めて高い性能密度を実現でき、大量インスタンスによる水平スケールや高価な専用機の調達といった従来モデルを回避できることを示します。性能向上の源泉はハードウェアの積み上げではなく、アーキテクチャ設計にあります。

3.2 防御のヘッドルーム（Headroom）の価値

本番環境での実測に基づくと、典型的な攻撃トラフィックのピークはおおよそ 30〜40 Mbps です。一方、上記構成のシステムは、おおよそ 100 Mbps（小パケットで約 18 万 PPS に相当）の攻撃トラフィックを安定して処理できます。

この差分、すなわち性能面の余裕（ヘッドルーム）が重要です。実際の攻撃発生時にもシステムは処理限界から大きく離れており、監視・意思決定・ポリシー調整に十分なバッファが確保されます。システム挙動の予測可能性と、落ち着いた対応が担保されます。

3.3 アーキテクチャの拡張性

より高スペックのハードウェアでは、性能は CPU コア数にほぼ線形でスケールします。ラボ環境では、千万級規模の PPS のトラフィックを処理する能力も検証済みです。これは次を意味します。

• 防御能力はハードウェアの世代交代に伴い滑らかに向上でき、長期的な投資を保護する。
• 将来より大規模な攻撃に直面しても、根底からアーキテクチャを組み替える必要はない。

4. 自動化は「おまけ」ではなく DDoS 防御の前提

DDoS 防御の有効性は、ピーク性能だけでなく、対応の速さと正確さにも左右されます。

4.1 攻防の完全自動化

システムの設計目標は、自動化された防御のクローズドループの実現です。

• 攻撃トラフィックのパターンを自動検知し、防御方針を起動する。
• コンソール側では、具体的な階層に対して 自動検出攻撃モード（Auto detect attack mode） を有効化でき、リアルタイムのトラフィック特性に基づき自動的に判定・介入する。
• 攻撃終了後はポリシーを自動的に撤回し、通常の経路へ復帰する。

その結果、MTTR（平均応答時間）が大幅に短縮され、人的介入が招きうる遅延や誤判断も抑えられます。セキュリティ対応は、属人的な「ヒーロー業」ではなく、確定的なシステム挙動として実現します。

4.2 方針決定の体系化

システムに組み込まれたトラフィック分析エンジンは、異なる攻撃ベクター（例：不正なドメインに関するリクエスト、CC 攻撃など）を識別し、最適な防御方針と自動的にマッチさせます。その中核的価値は次の点にあります。「遮断するか、どう遮断するか」という判断を、セキュリティ専門家に依存した突発対応から、システムに組み込まれた再現可能な意思決定ロジックへ移す。

防御能力がプラットフォーム能力として固定化され、特定のセキュリティ専門家への依存が下がり、チーム全体の安定性が高まります。

5. 可観測性：透明性は信頼の基盤

コアデータパス上で動作するシステムが「ブラックボックス」であれば、それ自体が潜在リスクとなります。本システムの設計では、可観測性を最優先の設計要素の一つに位置づけています。

提供されるリアルタイムのテレメトリには、次が含まれます。

• 攻撃状態（あり／なし）
• 識別された攻撃の種別
• リアルタイムおよび累積のパケットドロップ数と通過数
• カーネル側実装の実行状態とリソース消費

OpenResty Edge の各階層の防御設定画面の下部には、Real-Time Metrics（リアルタイム指標） パネルが埋め込まれており、同一画面内でポリシーと効果を照らし合わせられます。当該階層の SYN や DNS 関連トラフィックの概要として、Reply pps（毎秒の応答パケット数）、Dropped pps（毎秒の破棄パケット数）、Not Under Attack（未攻撃）/ Under Attack（攻撃中） といった状態を確認でき、指標が防御の実効性をそのまま示すため、「ブラックボックス型」のセキュリティモジュールにならずに済みます。

これらのデータにより、次が確保されます。

• 監査可能なポリシー：すべての防御動作がデータに裏付けられる。
• 障害のトレーサビリティ：問題調査に共通の、信頼できるデータ基盤を提供する。
• 部門横断の連携：セキュリティ、ネットワーク、ビジネス側が共通の事実に基づいて議論できる。

6. 結論：内蔵かつ適応型の防御体系を構築する

ネットワーク攻撃の規模と複雑さは継続的に増大しています。真のアーキテクチャ上のリスクは、攻撃そのものではなく、対策のために導入した結果、既存の体制と両立しにくい「異種のシステム」になること、あるいは要所で人の手に過度に頼る脆弱なプロセスにあります。運用コストが過大なセキュリティ体制は、開発チームと運用チームから受け入れられない—その点は十分承知しています。多段のポリシー を OpenResty Edge の内蔵機能として提供するのは、単一プロダクトの範囲内で性能・互換性・運用しやすさを両立させるためであり、独立した「DDoS 専用装置」を重ねたり、別系統の運用面をもう一段積み増したりするためではありません。

• Console + Agent モード：中央の Console ですべてのポリシーを構成でき、各ノード上の Agent が API 経由で自動的に取得・同期します。サーバへ 1 台ずつログインして手作業で操作する必要はありません。
• 段階的な導入：ミッションクリティカルでない業務や単一ノードからパイロットを開始し、効果を検証したうえで、サーバおよび事業ラインへ段階的に展開できます。プロセス全体をスムーズかつ制御可能に保てます。
• 複雑なネットワークへの適合：ネットワーク名前空間をサポートしているため、コンテナ環境（Docker、Kubernetes など）やマルチテナント仮想化環境においても、異なるネットワークインターフェースごとに独立した防御ポリシーを適用できます。

理想的な DDoS 防御アーキテクチャは、シームレスに統合され、自律的に稼働し、そのものとして十分に堅牢なシステム能力であるべきです。導入後、技術責任者がその自律動作を信頼でき、当番表のなかで常に高い注意を要するアラート源にならないことです。これこそが、本アーキテクチャの設計が解決しようとする中核的エンジニアリング課題です。

著者について

章亦春（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 件を超えるオープンソースソフトウェアライブラリを手がけています。

翻訳

英文版の原文を掲載しています。他言語への全文翻訳（省略なし）も歓迎いたします。内容を精査し、採用を検討いたします。厚く御礼申し上げます。