セグメント
📄️ インターフェースガイド
NetFUNNELコンソールインターフェースでセグメントを表示、作成、編集、および削除する方法を学習します。
🗃️ 基本制御セグメント
13項目
🗃️ 区間制御セグメント
10項目
概要
セグメントは、NetFUNNELトラフィック制御の核心的な構成要素で、トラフィック制御の範囲とポリシーを管理する作業単位の役割を果たします。各セグメントは一意のセグメントキーを持ち、トラフィック管理要件に応じて異なる制御方法で構成できます。
セグメントとは何ですか?
セグメントは、トラフィック制御が適用される範囲を管理する作業単位です。指定された範囲内のアクセスリクエストに対してトラフィック制御ポリシーが実行されます。セグメントを通じて以下を実行できます:
- 制御範囲定義: どのURLまたは区間を制御すべきかを指定
- トラフィックポリシー設定: 進入状態、進入許容数、および待合室動作を構成
- パフォーマンスモニタリング: トラフィックパターンおよびシステムパフォーマンスを追跡
- リソース管理: 同時ユーザー制限およびシステム容量制御
セグメントタイプの比較
NetFUNNELは、異なるトラフィック制御シナリオに最適化された2つのセグメントタイプを提供します:
| 側面 | 基本制御 | 区間制御 |
|---|---|---|
| 主要目的 | 特定の作業/URLに対する進入速度制御 | 多段階プロセスで固定同時ユーザー数を維持 |
| キー管理 | 作業完了後キーを迅速に返却 | 区間/プロセス全体が完了するまでキー保持 |
| 最適な用途 | ボタンクリック、API呼び出し、ページロード、特定のURL | 多段階プロセス、チェックアウトフロー、登録 |
| 統合方法 | URLトリガー統合(UTI)+ コードベース統合(CBI) | コードベース統合(CBI)のみ |
| 進入許容数のタイプ | 固定型 + 変動型 | 固定型のみ |
| トリガールール | サポート(UTI用) | サポートされない |
| 進入パス | サポート | サポートされない |
| 高度なタイミング | 再リクエスト周期、タイムアウト | 再リクエスト周期、Alive Notice 再リクエスト周期、Alive Notice 満了、タイムアウト |
| 事前/事後待合室 | サポート | サポートされない |
基本制御セグメント
基本制御は、特定の作業またはURLに対するトラフィックを制御します。この方法は、以下があるときに理想的です:
- 特定の急増URL: 既知のトラフィックが多いページまたはエンドポイント
- ターゲット制御: 特定のユーザー作業を制御する必要がある
- URLベース保護: URLパターンに基づいて自動保護を望む(UTI)
- 迅速な応答: 作業完了後、即座にキー返却が必要
- 変動型: 測定された処理時間に基づいて自動的に進入許容数を調整したい
主要特徴:
- 作業完了後キーを迅速に返却
- 進入速度制御(ユーザーが進入できる速度)
- UTIおよびCBI統合方法の両方をサポート
- 測定された処理時間に基づいて進入許容数を自動調整する変動型をサポート
- 最適な用途: 単一作業、APIスロットリング、ページ保護、ターゲット急増ポイント
ユーザージャーニー:
作業 → 待機列で待機(アクティブユーザー数超過時) → 即座に進入 → キーを迅速に返却 → 次のユーザーが進入可能
使用例:
/checkoutページロード保護/paymentエンドポイントスロットリング/signupボタンクリック制御- トラフィックが多いイベントページ保護
区間制御セグメント
区間制御は、多段階プロセス全体またはアプリケーション区間を制御する必要があるときに使用されます。この方法は、以下に適しています:
- 多段階プロセス: チェックアウトフロー、登録プロセス、複数ページフォーム
- 固定同時ユーザー数管理: 区間で固定された数の同時ユーザーを維持する必要がある
- プロセス全体制御: 個別ページではなくプロセス全体のフローを制御したい
- 長期実行区間: ユーザーが複数のページ/段階をナビゲートするプロセス
主要特徴:
- 区間/プロセス全体が完了するまでキーを保持
- 固定同時ユーザー数維持(区間内の固定ユーザー数)
- CBI統合方法のみサポート
- 固定型のみサポート(一定の進入許容数)
- 最適な用途: 多段階プロセス、チェックアウトフロー、固定同時ユーザー数の維持
ユーザージャーニー:
開始 → 待機列で待機(アクティブユーザー数超過時) → 区間進入 → 複数の段階 → プロセス全体完了 → キー返却 → 次のユーザーが進入可能
使用例:
- Eコマースチェックアウトプロセス(カート → 配送 → 決済 → 確認)
- ユーザー登録フロー(フォーム → 確認 → 確認)
- 予約/予約プロセス
- 多段階決済処理
共通概念
基本制御と区間制御の両方が、複数の基本概念を共有します:
セグメント作成および識別
セグメント名: 簡単に管理できる人間が読める識別子
- セグメントリストで識別に使用
- ベストプラクティス: 説明的な名前を使用(例:「Eコマースチェックアウト」、「ユーザー登録」)
- 環境表示子を含めることができる(例:「本番」、「ステージング」)
セグメントキー: NetFUNNELエージェントが使用する一意の識別子
- 自動生成(形式:
segKey_XXXX) - 作成中にカスタマイズ可能
- 作成後は変更不可(不変)
- API呼び出しで使用:
nfStart(segmentKey)またはnfStartSection(segmentKey)
進入状態
進入状態は、制御されたリソースにアクセスしようとするときにユーザーが処理される方法を決定します:
-
待機: ユーザーが待機列で待機し、進入許容数が使用可能になると進入
- 待合室UIを表示
- 進入許容数が使用可能になると、ユーザーが順次進入
-
ブロック: ユーザーの進入がブロックされる
- ブロックルームUIを表示
- すべてのアクセスリクエストがブロックされる(メンテナンスまたは緊急事態に有用)
注意: 進入許容数を0に設定すると、すべてのユーザーが待合室に移動します(テストに有用)。
進入許容数
進入許容数は、同時にサービスにアクセスできるユーザー数を決定する核心的なトラフィック制御メカニズムです。
核心概念:
- 同時ユーザーに対する最大進入許容数を設定
- ユーザーはアクティブユーザー数が進入許容数を超過したときにのみ待機
- 進入許容数が100で現在のアクティブユーザー数が50の場合、次の50名のユーザーが即座に進行
- ユーザー#101以上は進入許容数が使用可能になるまで待機
固定型(両方で使用可能):
- 一定の進入許容数(例:常に100名のユーザー)
- シンプルで予測可能
- 推奨開始ポイント
変動型(基本制御のみ):
- 測定された処理時間に基づいて自動的に進入許容数を調整
- 処理時間範囲および進入許容数範囲の構成が必要
- 区間制御では使用不可(処理時間 = ユーザー滞在時間であり、サーバー負荷ではないため)
待合室適用
両方のセグメントタイプが、ユーザーが見るUIを構成するために待合室適用を使用します:
待合室: 待機中の待機列ユーザーに表示されるテンプレート
- カスタマイズ可能なテンプレート
- ライブメッセージを含めることができる(リアルタイムテキスト更新、最大20文字)
- 基本制御: 「予想待機時間」を表示
- 区間制御: 「予想待機時間」を表示しない(ユーザー滞在時間が可変的であるため)
ブロックルーム: ブロックされたユーザーに表示されるテンプレート
- 進入状態がブロックに設定された場合に表示
- カスタマイズ可能なテンプレート
高度な機能
待機順維持(両方):
- 接続切断後、待機順番を復元(1秒 ~ 2時間)
- ブラウザが閉じられたりネットワークが切断されても、ユーザーが順番を維持するのに役立つ
進入キー無効化(両方):
- 特定の条件に対する強制再待機
- 基本制御: URLベースまたはタイマーベース無効化
- 区間制御: タイマーベース無効化のみ
高度なタイミング(両方):
- 基本制御: 再リクエスト周期、タイムアウト
- 区間制御: 再リクエスト周期、Alive Notice 再リクエスト周期、Alive Notice 満了、タイムアウト
担当者指定(両方):
- セグメント管理に対する責任運営者を指定
- 指定された運営者のみセグメント編集を制限
主要な違いの説明
1. キー管理の哲学
基本制御と区間制御の根本的な違いは、進入キーが返却される方法と時点です:
基本制御 - 迅速な返却:
- 作業が完了すると即座にキーが返却される(例:ページロード、API呼び出し完了)
- 焦点: 進入速度制御 - ユーザーが進入できる速度
- 前のユーザーが作業を完了した後、次のユーザーが迅速に進入可能
- 例:
/checkoutページがロードされた後キーが返却される → ユーザーが進行可能 → 次のユーザーが即座にアクセス可能
区間制御 - 完了まで保持:
- 多段階プロセス全体の間キーが保持される
- 焦点: 固定同時ユーザー数維持 - 同時に区間にいる固定された数のユーザー
- 区間全体が完了したときにのみキーが返却される(例:チェックアウト完了、登録完了)
- 例: ユーザーがチェックアウト進入 → カート → 配送 → 決済 → 確認の間キー保持 → すべての段階が完了するとキー返却
2. 統合方法
基本制御 - 2つの方法:
-
URLトリガー統合(UTI): URLパターンに基づいて自動保護
- コード変更不要
- トリガールールを構成してURLと一致
- 一致するリクエストに対して自動的に待合室を表示
-
コードベース統合(CBI):
nfStart()およびnfStop()を使用した手動制御- 待合室が表示される時点を精密に制御
- ボタンクリック、API呼び出し、特定のコードパスに使用
区間制御 - 1つの方法:
- コードベース統合(CBI)のみ:
nfStartSection()およびnfStopSection()を使用した手動制御- 区間境界を手動で定義する必要がある
- 区間が開始されるときに
nfStartSection()を呼び出す - 区間が完了されるときに
nfStopSection()を呼び出す - URLトリガー統合はサポートされない(区間は多段階であるため、単一URLでトリガーできない)
3. 進入許容数タイプの可用性
基本制御 - 2つのタイプ:
- 固定型: 一定の進入許容数
- 変動型: 測定された処理時間に基づいて自動的に進入許容数を調整
- 処理時間(サーバー応答時間)をモニタリング
- 測定された処理時間に基づいて進入許容数を調整
- 処理時間範囲および進入許容数範囲の構成が必要
区間制御 - 1つのタイプ:
- 固定型のみ: 一定の進入許容数
- 変動型使用不可: 区間制御の処理時間はユーザー滞在時間(多段階プロセスでユーザーが留まる時間)を表し、サーバー負荷ではない
- ユーザー行動が大きく異なる(一部のユーザーは2分、他のユーザーはチェックアウトで10分かかる)
- これをサーバー負荷指標として信頼できない
- したがって、自動調整メカニズムが適していない
4. 高度な機能の可用性
基本制御専用:
- トリガールール: 自動保護のためのURLベース条件(UTI)
- 進入パス: 再待機なしで即座に再進入を許可(1分 ~ 24時間)
- 事前/事後待合室予約: 主要イベント前後の待合室予約
- 変動型進入許容数: 処理時間ベースの進入許容数自動調整
- 予想待機時間: 待合室に表示される
区間制御専用:
- Alive Notice 再リクエスト周期: エージェントが「まだアクティブ状態」信号を送信する頻度
- Alive Notice 満了: ユーザーが区間でアクティブ状態を維持できる最大期間
両方でサポート:
- 待機順維持
- 進入キー無効化(方法が異なる)
- 高度なタイミング(オプションが異なる)
- 担当者指定
どのセグメントタイプを使用すべきですか?
基本制御を選択すべき場合:
- ✅ 特定のURLまたはページを保護する必要がある
- ✅ **URLトリガー統合(UTI)**を使用して自動保護したい
- ✅ 単一作業完了後迅速なキー返却が必要
- ✅ 処理時間ベースの進入許容数自動調整のための変動型が必要
- ✅ ターゲット急増ポイントがある(特定のページ/エンドポイント)
- ✅ 即座の再進入のための進入パスが必要
- ✅ URLベース条件付き制御のためのトリガールールが必要
最適な用途: 単一ページ作業、APIスロットリング、ページ保護、URLベーストラフィック制御
区間制御を選択すべき場合:
- ✅ 多段階プロセスがある(チェックアウト、登録、複数ページフロー)
- ✅ 区間で固定同時ユーザー数を維持する必要がある
- ✅ 個別ページではなくプロセス全体のフローを制御したい
- ✅ ユーザーが複数のページ/段階をナビゲートするプロセスがある
- ✅ コードベース統合(CBI)のみを使用中
- ✅ 固定進入許容数管理が必要(変動型不要)
最適な用途: 多段階チェックアウトフロー、登録プロセス、予約フロー、固定同時ユーザー制限が必要なプロセス
決定フロー
多段階プロセスを保護する必要がありますか?
├─ はい → 区間制御
│ (チェックアウトフロー、登録、予約)
│
└─ いいえ → URLベース自動保護が必要ですか?
├─ はい → 基本制御(UTI)
│ (特定のページ、トリガールール)
│
└─ いいえ → 基本制御(CBI)
(ボタンクリック、API呼び出し、コードレベル制御)
セグメント構成概要
基本設定プロセス
- セグメント作成: セグメントリストで '+' ボタンをクリック
- タイプを選択: 基本制御または区間制御を選択
- 設定を構成:
- 基本設定(名前、キー)
- 進入状態(待機/ブロック)
- 進入許容数
- 待合室適用(テンプレート)
- 統合設定:
- 基本制御: UTI(トリガールール)またはCBI(コード実装)を選択
- 区間制御: CBI実装(nfStartSection/nfStopSection)
- 構成テスト: 設定確認およびリアルタイムメトリックモニタリング
必須構成要素
すべてのセグメントには、以下の核心設定が必要です:
- セグメント名: 簡単に区別できる識別子
- セグメントキー: API呼び出しのための一意のキー(自動生成、作成時まで変更可能)
- 進入状態: 待機(順次進入)またはブロック(進入制限)
- 進入許容数: 同時にアクセスできるユーザー数
- 待合室: テンプレート選択およびカスタマイズ
基本制御追加:
- トリガールール: URLベース条件(UTI専用)
ベストプラクティス
セグメント計画
- 制御範囲を識別: どのURLまたは区間を制御すべきかを決定
- タイプを選択:
- 特定のURL/ページ/作業の場合は基本制御
- 多段階プロセスの場合は区間制御
- 容量計画: 進入許容数を最大サーバー容量の約50%に設定
- 待機体験を設計: 意味のある待合室体験を作成
- 統合方法を考慮: 自動保護のためのUTI、精密制御のためのCBI
パフォーマンス最適化
- 使用量をモニタリング: セグメントパフォーマンスおよびユーザー体験を追跡
- 制限を調整: 実際の使用量に基づいて進入許容数を修正
- 固定型で開始: まず固定型を使用し、モニタリング後に変動型を考慮(基本制御)
- 徹底的にテスト: トリガールールテスト(基本制御UTI)またはコードテスト(CBI)で設定を確認
構成ヒント
- セグメント名指定: 目的と環境を示す説明的な名前を使用
- キーをカスタマイズ: コード可読性のために作成中にセグメントキーをカスタマイズ
- 進入状態: 正常動作のために待機を使用、メンテナンス/緊急事態のためにブロックを使用
- テスト: テストのために進入許容数を0に設定(すべてのユーザーが待合室に移動)