エンタープライズアプリケーショントラフィックにおけるルーティング決定は、もはやホスト、パス、ポートだけに依存しません。ヘッダーの修正、レガシーアプリケーションの互換性、CORSポリシー、クッキーセキュリティ、帯域幅制限、captchaトリガー、quarantine、カスタムエラーページ、レスポンス変換はすべて同じトラフィックパス上に現れます。シンプルなロードバランシングルールではこの多様性に対応できません。
多くの従来のアプローチは二つの極端のいずれかに傾きます。オペレーターに少数のプリセットアクションしか与えられず、モダンなユースケースが解決不可能になるか、または完全な柔軟性のために生のスクリプトや低レベルの設定を記述することを要求されます。後者のモデルでは、すべてのルール変更がソフトウェア開発、テスト、コードレビュー、セキュリティ監査という重いプロセスに結びつきます。
リスクはさらに、アクションがどのサービスタイプまたはトラフィックフェーズに適用されるかを明確に制御できない場合に高まります。TCPサービスにHTTPヘッダーアクションを書いたり、レスポンス側にリクエスト動作を期待したり、プール制限のあるアクションを複数回追加したりすることはすべてランタイムの問題を引き起こす可能性があります。
正しいモデルはビジュアルルールエディターとコンパイル済みランタイム動作を組み合わせることです。GUIは有効な組み合わせのみを表示し、アクションのメタデータはサービスタイプとリクエスト/レスポンスフェーズを管理し、エッジケース用の制御されたマニュアルルールの抜け道が利用可能なままであるべきです。
TR7トラフィックルールエンジンはこのバランスを実現します：オペレーターに30以上のプリセットアクションを提供し、無効な組み合わせを非表示にし、正しいルールを検証済み設定として本番トラフィックに適用します。
TR7はアクションの分類、フェーズ認識、コンパイル済み設定、検証済みプロモーションモデルを通じてトラフィックルールを適用します。
各アクションはサービスタイプ、リクエスト/レスポンスフェーズ、条件サポート、コンテンツ要件、エラーコード動作、プールごとの使用制限のメタデータを持ちます。GUIはこのメタデータを読み取り、現在のコンテキストで有効なルールオプションのみを表示します。
ビジュアルエディターで作成されたアクションは、定義された優先順位シーケンスで動作中の設定に出力されます。変数代入、ルーティング、ヘッダー操作、エラー動作、バックエンド選択はすべて予測可能な順序で実行されます。
静的ディレクティブとして表現できない一部の高度なアクションは、ランタイムで呼び出し可能な関数に変換されます。オペレーターはコードを一切書かずにルールエンジンを通じて複雑なトラフィック動作を管理できます。
新しい設定が生成され、検証ステップを通過します。検証が失敗した場合、現在実行中の設定が保持され、不正なルールは本番トラフィックに到達しません。
トラフィックルールエンジンはプリセットアクションとFX条件を組み合わせて、リクエストとレスポンスパスにわたる制御されたポリシー適用を提供します。
TR7はadd_header、del_header、set_header、replace_header、redirect_scheme、req_redirect_location、set_path、normalize_uri、req_auth、cors、ipMask、cookieEncryption、bandwidthRule、advancedCaptcha、modifyResponse、silentLog、securityHeaders、cookieSecurity、deny、quarantine_table、manualRule、prometheusServiceを含む30以上のアクションを提供します。オペレーターはビジュアルエディターでアクションを選択し、パラメータを入力し、条件を添付します。これにより一般的なトラフィック操作タスクがスクリプトの領域から外れます。運用チームはより速くルールを作成し、開発チームへの依存を減らせます。
アクションはatRequest、atResponse、errorRules、cookieBased、tcpRulesなどのセマンティックグループの下に提示されます。この分離により、ルールがどのトラフィックフェーズで実行されるかがすぐにわかります。リクエスト側のヘッダーとパス操作は、レスポンス側のセキュリティヘッダーとエラーページ動作と混在しません。GUIは技術的な複雑さを削減し、意図別にルール作成を整理します。
各アクションはHTTP、TCPまたは両方のサービスタイプの互換性情報を持ちます。CORS、ヘッダー操作、クッキーセキュリティ、パス書き換えなどのHTTP固有のアクションはTCPサービスには表示されません。接続管理オプションなどのTCP固有のアクションはHTTPサービスの選択肢として表示されません。このアプローチにより、オペレーターが保存を試みる前に機能しないルールを選択することを防ぎます。
メタデータは各アクションが有効なフェーズを正確に定義します。リクエストフェーズで実行する必要のあるアクションはレスポンス側に誤って添付されることはなく、レスポンス重視のアクションはリクエストパスに誤ってバインドされることはありません。アクションが両フェーズで有効な場合、それは明示的に管理されます。無効な組み合わせは設定検証中に本番トラフィックに到達する前にキャッチされます。
アクションは無条件で実行されるか、FX式言語で記述された条件に結びつけられます。ソースIP、国、ASN、パス、ヘッダー、クッキー、ボディフィールド、ユーザーロール、WAAPスコア、タイマー値はすべて同じ条件モデルで使用できます。複数の条件がACLロジックで組み合わされ、アクションがいつ発動するかを決定します。これによりルールエンジンはコンテキスト認識かつコンテンツ認識の意思決定者になり、単なる静的ルーティングテーブルではなくなります。
一部のアクションは特定のプールに一度だけ表示されるべきです。クッキー暗号化、IP修正、ヘッダー名保持の2番目のインスタンスを追加すると予期しない結果が生じる可能性があります。TR7は各アクションのメタデータにプールごとの最大使用数を持ち、GUIが2番目のインスタンスを追加するのを防ぎます。このガードにより本番に到達する前に運用上の矛盾が削減されます。
プリセットアクションが特定のシナリオをカバーできない場合、manualRuleにより生のトラフィックルールを挿入できます。この機能は標準エンジンカタログ外の高度なシナリオの抜け道として機能します。マニュアルルールは設定検証ステップを通過し、サービス動作に直接影響するため慎重に使用する必要があります。これによりプラットフォームは同一モデル内でビジュアルルールの便利さと高度レベルの柔軟性の両方を提供します。
cookieSecurityアクションはSecure、HttpOnly、SameSiteクッキー属性を強制できます；cookieEncryptionは選択したクッキー値を転送中に暗号化できます。corsアクションはオリジン許可リスト、メソッド、ヘッダー、プリフライトキャッシュ設定を単一のポリシーにまとめます。securityHeadersはセキュリティヘッダーのベースラインセットを中央で適用します。quarantine_tableは特定のIPまたはクライアントシグネチャを一定期間quarantineに配置し、エッジで繰り返す悪い動作を封じ込めます。
トラフィックルールはアトミックプロモーション、バージョニング、クラスター同期、競合管理、監視、エッジケース処理と組み合わせて運用されます。
新しいルールセットは別途生成され、アクティブになる前に検証されます。検証が成功した場合、アクティブ設定が入れ替わります；失敗した場合、現在実行中の設定が保持されます。このモデルにより、不正なルールが本番トラフィックを中断するのを防ぎます。
すべてのルール変更はIDとタイムスタンプで記録される必要があります。運用チームは誰がどのルールを変更し、どのプールに影響し、必要に応じてどのバージョンにロールバックするかを確認できます。これらの記録はセキュリティとコンプライアンスのレビュー時に特に重要です。
高可用性デプロイメントでは同じルールセットをすべてのピアノードに配布する必要があります。これがなければ、同じVIP配下の異なるノードが異なるトラフィック動作を示す可能性があります。TR7はクラスター全体でルールセットの一貫性を保つことを運用モデルの一部として扱います。
複数のアクションが同じヘッダーまたはトラフィックフィールドをターゲットにする場合、優先順位が決定要因となります。システムはアクションを定義されたシーケンスで出力し、最終的な動作はそのシーケンスに依存します。オペレーターは監査記録と優先順位ロジックを使用してクリティカルなルールの潜在的な競合を評価する必要があります。
アクションが実行されているかどうかは、silentLogを通じて追跡し、専用フィールドとしてSIEMに転送できます。これにより、ルールが実際に何件のリクエストにマッチし、どの条件下で発動し、期待通りの効果をもたらしたかが明らかになります。可観測性によりルールエンジンがブラックボックスのように動作するのを防ぎます。
一部のレガシーバックエンドはヘッダー名の大文字/小文字に敏感です。keepHeaderNamesアクションはそのような互換性シナリオで元のヘッダー名の大文字/小文字を保持するのに役立ちます。この設定は真に必要とするサービスにのみ使用し、アプリケーションの動作と合わせてテストする必要があります。
モダナイゼーションチームはreplace_headerまたはset_headerを使用して、レガシーバックエンドが期待するヘッダー名をアプリケーションが必要とする形式に変換できます。アプリケーションコードに触れることなく、トラフィックエントリポイントで互換性レイヤーが作成されます。
SaaSチームはsecurityHeadersアクションを使用して、サービスの前面で一般的に必要なセキュリティヘッダーを中央から追加できます。各アプリケーションチームが同じ設定を個別に行う必要なく、セキュリティベースラインが強化されます。
金融アプリケーションはbandwidthRuleとadvancedCaptchaアクションを組み合わせて、繰り返しのログイン失敗後にcaptchaチャレンジをトリガーできます。疑わしい繰り返し動作はユーザーエクスペリエンスを完全に中断することなく、より厳格な検証フローに誘導されます。
Eコマースと金融サービスはcookieEncryptionを使用してセッションクッキーを暗号化された形式でクライアントに配信できます。バックエンドは期待する値を引き続き参照できる一方、クッキーコンテンツはクライアント側で意味のある形では読み取れなくなります。
30以上のプリセットアクション、FX条件、アトミック設定プロモーションによるリクエストとレスポンスパス全体の完全制御。お客様自身のサービスでのライブセットアップをご案内します。