エンタープライズトラフィック管理はもはや単なるロードバランシングルールではありません。同じプラットフォーム内で、トラフィックルーティング、ヘルスチェック、ログエンリッチメント、GTM決定、セキュリティスコアリング、captchaポリシー、ACL、アクセスコンテキストがすべて一緒に動作します。問題は、ほとんどの製品がこれらのモジュールを別々の式言語、別々の変数名、別々のエラー動作で管理することです。
その断片化により、オペレーターは常にメンタルコンテキストを切り替えることを強いられます。同じ値が一つのモジュールと別のモジュールで異なって書かれます — クライアントの国、ソースIP、リクエストパス、JWTクレーム、WAAPスコアはすべて各場所で別々のロジックで処理されます。結果として、学習コストの上昇、ルール重複の倍増、デバッグサイクルの長期化が生じます。
さらに危険なのは、同じビジネスルールがモジュール間で異なって解釈される場合です。ヘルスチェック条件がルーティング条件と乖離すると、システムはサービスを正常とマークしながら、別のロジックパスが同じサービスへのトラフィックをドロップする可能性があります。ログ側が同じコンテキストを不完全に記録すると、インシデント後の調査も影響を受けます。
正しいアプローチは、単一の式言語を共有決定レイヤーにすることです。その言語は関数、変数、型チェック、使用スコープを集中的に定義し、すべてのモジュールが独自の運用コンテキスト内で同じ式ツリーを消費するようにすべきです。
TR7 FXエンジンはこのニーズを満たします：モジュール間に散在していた決定ロジックを単一の式言語、単一の変数カタログ、事前登録検証モデルの下に統合します。
決定ロジックをモジュールごとの別々の構文に分割する代わりに、TR7はすべてを共有FX式ツリーを通じてコンパイルおよび評価します。
FXエンジンは14のグループに整理された41の組み込み関数と173の変数を提供します。接続、HTTPヘッダー、ボディ、SSL、タイマー、統計、WAAP、AAMコンテキストはすべて同じカタログから選択されます。
ネイティブに処理できる関数は高性能なサンプルフェッチとコンバーターチェーンとして直接実行されます。例えば、リクエストボディからJSONフィールドを読み取り、テキストトランスフォーマーで正規化して単一の式結果に結びつけることができます。
XML XPath、複雑なJWTクエリ、カスタム処理を必要とする関数はLuaベースのアクションとして出力されます。FX言語は統一されたまま；ランタイムパスは関数のニーズに基づいて選択されます。
トラフィックルール、ヘルスチェック、ログフォーマット、GTMトリガー、captchaポリシー、ACLはすべて同じ関数と変数モデルを共有します。この共通性により、オペレーターが各モジュールに新しい決定言語を習得する必要が減ります。
FX式と変数エンジンはプラットフォーム全体の変数と関数をスキーマ駆動で検証可能かつコンパイル可能なモデルに変換します。
FX変数カタログは接続、HTTPヘッダー、ボディ、クライアント、リクエストライン、レスポンスライン、SSL、統計、タイマー、トラッキング、WAAP、AAM、VarBuilder、その他のグループに整理されています。オペレーターはソースIP、宛先ポート、リクエストパス、レスポンスステータス、SNI、証明書詳細、WAAPスコア、AAMユーザーロール、カスタム変数を同じモデルから選択します。これにより同じコンテキストが異なるモジュールで異なる名前で書かれることを防ぎ、ルール言語をより一貫性があり、読みやすく、エラーが少なくなります。
関数カタログはコンバーター、数学、XML、JSON、JWT、IP、文字列、ハッシュ、FIX、MQTT、マップ/リスト、パラメータ、条件選択グループをカバーします。JSONQUERY、XMLQUERY、JWTHEADER、JWTPAYLOAD、PARAM、DIGEST、LOWERCASE、STRREPLACEALL、MAP_STR、LIST_REG、TERNARYはすべて単一の式内に組み合わせられます。オペレーターはシンプルなテキスト変換と深いボディフィールドクエリの両方に同じFXモデルを使用し、ルール作成をアドホックなコーディングから管理可能なポリシー定義へと移行させます。
ネイティブサポートを持つ変数と関数はサンプルフェッチとコンバーターチェーンに直接コンパイルされます。このパスはヘッダー読み取り、パスマッチング、テキスト変換、マップルックアップ、特定のボディクエリなど頻繁に必要な決定に適しています。中間解釈レイヤーが介在しないため、パフォーマンスが予測可能なまま保たれます。トラフィックルールは可能な限りプラットフォームの最も効率的な実行パスに変換されます。
ネイティブチェーンを通じて表現できない制御はLuaアクションとして実行されます。XML XPathクエリ、カスタムJWTチェック、複雑な条件処理はすべてこの方法でサポートされます。オペレーターの視点からは式言語は同じです — システムがバックグラウンドで正しい実行パスを選択します。この分離により、単一のFXエクスペリエンス内で高性能なネイティブパスと柔軟なLuaパスが組み合わされます。
すべての関数引数は型とともに定義されます — 整数、文字列、jsonPath、xmlPath、ハッシュ、またはsmartInput。UIと管理レイヤーは保存時にこれらの型を検証します。誤った引数の型、欠落したパラメータ、互換性のないネストされた使用はランタイムに到達する前にキャッチされ、本番トラフィックでの予期しないルール失敗を削減します。
各変数はどのモジュール、条件タイプ、トラフィックフェーズで使用できるかを記述したメタデータを持ちます。一部の変数はレスポンスフェーズでのみ有効で、他のものはログテンプレートまたは特定の条件タイプにのみ表示されます。UIはこの情報を使用してオペレーターにコンテキストに適したオプションを提示し、無効な変数が誤った位置に配置されるのを防ぎます。
VarBuilderグループにより、オペレーターはランタイムで計算されるカスタム変数を作成できます。値はFX式を通じて計算され、トランザクションスコープ内に格納され、後続のルールで再利用されます。このモデルにより、同じ計算を複数の場所で書き直す必要が減ります。複雑なフローでは決定ロジックがよりモジュール化され追跡可能になります。
FXコンソールは中央スキーマから関数、変数、引数、スコープ情報を引き出します。オペレーターが関数名や変数を入力すると適切なオプションが提案され、空の値を受け入れる引数と括弧が必要な関数はUIによって正しくガイドされます。これにより新規ユーザーの学習コストが削減され、経験豊富なオペレーターはより速くルールを作成できます。式は保存ステップに到達する前により正確になります。
FXエンジンは式作成体験だけでなく、検証、スコープ適用、監査、パフォーマンス、エッジケースの動作を考慮して設計されています。
各関数の期待される引数リストと型は中央定義に保持されます。UIと管理レイヤーはこの情報を独立してチェックします。その結果、無効な式は画面上だけでなく保存ポイントでも拒否されます。
一部の変数はレスポンスフェーズでのみ意味があります。これらの変数はメタデータでフラグが付けられ、リクエストフェーズ条件での使用がブロックされます。この区別によりフェーズの不一致によるランタイムエラーが削減されます。
一部の変数は後方互換性または内部使用のためにシステムに保持されていますが、UIには表示されません。これによりプラットフォームは古い式の実行を継続しながら、オペレーターにはクリーンで正確な変数リストを提示できます。可視カタログと内部使用が分離されます。
XMLQUERY、XMLPATHTYPE、XMLPATHEXISTSなどの関数はLuaコンバーターコンポーネントに依存します。これらのコンポーネントはサービスの起動時に読み込まれ、関連するFX関数によって消費されます。コンバーターの欠落状態はデプロイメントとヘルスチェックプロセス中にキャッチされる必要があります。
すべての式ツリーは変更履歴とともに追跡可能である必要があります。誰がどの式をいつ変更したかは、運用とセキュリティレビューにとって重要な情報です。これらの記録はロールバック機能と説明責任の追跡を提供し、特にトラフィック動作に影響するルールに対して重要です。
STRREPLACEALLと一部の正規表現ベースのチェックは、不注意に書かれると高い処理コストが発生する可能性があります。バックトラッキングの重いパターンはセキュリティとパフォーマンスの両方にリスクをもたらします。UIはこのような場合にオペレーターに警告し、より安全なパターン作成を促すべきです。
SaaSチームはレスポンスボディの`$.status == "OK"`などの同じFX式をヘルスチェックとトラフィックルーティングルールの両方で使用できます。同じサービス状態が各モジュールで異なって書かれないため、運用の一貫性が向上します。
SOCチームはJWTPAYLOADを通じてログフォーマットにユーザーのメールアドレス、ロール、テナント情報を追加できます。インシデント調査は生のIPとURLデータを超え、すべてのログエントリでユーザーコンテキストが可視化されます。
グローバルサービスチームはDNSレスポンスを選択する際にFX式を通じて国、ASN、レイテンシデータを評価できます。同じロジックは必要に応じてトラフィックルーティングルールで再利用できます。
Eコマースチームはユーザー識別子から派生したハッシュに基づいて定義された割合のトラフィックを新しいバリアントに振り向けることができます。分配は決定論的 — 同じユーザーはすべてのリクエストで常に同じエクスペリエンスに誘導されます。
同じFXモデルでトラフィックルール、ヘルスチェック、ログ、GTM、セキュリティ決定を管理します。お客様自身の環境でのライブセットアップをご案内します。