進入許容数の設定
「進入許容数の設定」は、同時にサービスにアクセスできるユーザー数を決定する核心的なトラフィック制御メカニズムで、サーバー処理能力およびユーザーフローを管理する主要な方法です。このガイドでは、区間制御セグメントの固定型進入許容数について説明します。
概要
進入許容数は、NetFUNNELのサービスユーザーアクセスを制御する基本概念です。同時にアクティブ化できる最大同時ユーザー数を設定するものと考えてください。これは、サイトを訪問できる総ユーザー数を制限するのではなく、重要な作業中にサーバーリソースを同時に占有できるユーザー数を制御するものです。
核心概念
サーバーを制限された数のテーブルがあるレストランとして想像してください。進入許容数は最大収容人数制限を設定するようなものです - キッチンが圧倒され、サービス品質が低下する前に、同時に特定の数の顧客のみがサービスを受けることができます。NetFUNNELはこの同時ユーザー数を管理するホストの役割を果たし、「レストラン」がすべての人の体験に影響を与えるほど混雑しないようにします。
このアプローチの利点は、サーバー過負荷が発生する前にそれを防止することです。システムが高い負荷でクラッシュするのを待つ代わりに、NetFUNNELはサービスに進入するユーザーフローを事前に制御します。これは、トラフィック急増中でも一貫したパフォーマンスを維持できることを意味し、インフラとユーザー体験の両方を保護します。
主要動作: 制限を超過したときにのみ待機が発生
ユーザーは、進入許容数にすでに到達したときにのみ待機を経験します。進入許容数が100名に設定されており、現在50名のアクティブユーザーがいる場合、次の50名のユーザーは待機体験なしで直接サービスに進行します。
101番目のユーザーがサービスにアクセスしようとするときにのみ、NetFUNNELが介入して「少々お待ちください、今進入許容数に到達しました。前のユーザーを処理している間、しばらくお待ちください」と言います。これは、進入許容数が保護閾値として機能することを意味します - 制限内のユーザーは即座にアクセスを楽しみ、そうでなければシステムを圧倒するユーザーはクラッシュやタイムアウトの代わりに専門的な待機体験を受けます。
統合アプローチの観点
進入許容数を解釈し、適用する方法は統合方法によって異なります：
区間制御はコードベース統合のみを使用します（URLトリガー統合はサポートされない）。
コードベース統合（CBI）
CBIでは、進入許容数はnfStartSection()およびnfStopSection()呼び出し間の同時セッション数を制御します。
意味: 同時に特定の区間（例：チェックアウトプロセス、多段階フォーム）にいることができるユーザー数を制限します。例えば、進入許容数を50に設定すると、同時に50名のユーザーのみがチェックアウト区間にアクティブ化されていることができます。
実用的解釈: これは多段階プロセスでの同時占有を制御するものです。キーは区間全体の間保持され、区間が完了したときにのみ返却されます。
区間制御では、進入キーはユーザーが区間を完了するまで（例：チェックアウト完了、登録完了）多段階プロセス全体の間保持されます。各作業が完了した後にキーが迅速に返却される基本制御とは異なります。
進入許容数のタイプ
区間制御は、進入許容数設定のために固定型のみをサポートします。
固定型
固定進入許容数設定は、サービス運用全体にわたって一定の進入許容数を維持します。午前2時でも午後2時でも、システムは同じ最大同時ユーザー数を許可します。
このアプローチは、予測可能で安定したトラフィックパターンがあるときに最もよく動作します。例えば、勤務時間中に一貫した使用量を経験するビジネスアプリケーションを運用する場合、固定制限は動的調整の複雑さなしで安定したパフォーマンスを保証します。
固定制限の単純性により、モニタリングおよびトラブルシューティングがより簡単になります。複雑なスケジューリングルールを管理する代わりに、既知の進入許容数制約内でアプリケーションのパフォーマンスを最適化することに集中できます。
区間制御は変動型をサポートしません。進入許容数設定管理のために固定型のみ使用可能です。
区間制御で変動型を使用できない理由：
変動型は処理時間に依存して進入許容数を自動的に調整します。しかし、区間制御では：
- 処理時間 = ユーザー滞在時間（ユーザーが区間に留まる時間）
- この時間はサーバー負荷ではなくユーザー行動パターンに応じて大きく異なる
- ユーザーがチェックアウトフローで数分を過ごすことができ、これは実際のサーバーパフォーマンスを反映しない
基本制御では処理時間はトランザクション完了時間を表し、これはサーバー負荷を直接反映します。しかし、区間制御ではこれは多段階プロセス完了時間を表し、サーバー負荷指標として信頼できません。
したがって、変動型の自動調整メカニズムは区間制御セグメントに適していません。
構成プロセス
進入許容数の設定
-
進入許容数の設定コンソールにアクセス
- 区間制御セグメントに移動
- 「進入許容数の設定」セクションに移動
-
固定型制限設定
- 進入許容数として単一の数字（正の整数）を入力
- 例: 「100」を入力して区間で100名の同時ユーザーを許可
-
固定制限を構成
- 以下の計算ヒントを使用して開始値を決定
- 計算された進入許容数値を入力
- 構成を保存
-
設定をテスト
- リアルタイムのユーザー数に対するコンソールモニタリング
- 制限を超過したときにのみ待機が発生することを確認
- 制限内のユーザーが正常に進行することを確認
テスト目的で進入許容数を0に設定して、すべてのユーザーを待合室または待機画面に強制できます。これは以下に便利です：
- 待合室/画面が正しく表示されることを確認
- 実際のアクセスを許可せずにエージェント統合をテスト
- ライブ前に待機メカニズムが期待通りに動作することを確認
進入許容数計算のヒント
区間制御の場合、進入許容数は区間全体内で最も重いトランザクションに基づいて計算する必要があります。これは、ボトルネック作業が同時ユーザー負荷を処理できるように保証します。
1段階: 最も重いトランザクションを識別
区間ワークフロー内のすべてのトランザクションを分析し、最も多くのリソースを消費し、最も低い処理TPSを持つトランザクションを識別します。
一般的な候補:
- 決済処理リクエスト
- データベース書き込みトランザクション
- 外部統合（決済ゲートウェイ、認証サービス）
- 複雑なビジネスロジック作業
最も重いトランザクションが制限要素になります。このトランザクションが処理できるものよりも進入許容数を高く設定すると、ユーザーは区間の重要な段階で遅くなったりエラーを経験したりします。
2段階: 安定した最大TPSを測定
APMツール、WASモニタリング、または負荷テストを使用して、最も重いトランザクションの安定した最大TPSを決定します。
目標メトリック:
- CPU使用量: 70%以下
- P95応答時間: 1.5秒以下
- データベース接続プール: 十分な余裕
- エラー率の増加なし
例:
最も重いトランザクション: 決済処理
安定したTPS_min: 50
→ 進入許容数 = 50名の同時ユーザー
代替: 保守的推定方法
正確なTPS測定がない場合：
- 保守的に開始: 区間に対して10-20名の同時ユーザーで開始
- 区間パフォーマンスをモニタリング: 多段階プロセス全体にわたって応答時間を観察
- 段階的に増加: すべてが安定しているように見える場合、数日ごとに10-20%増加
- 最初のボトルネックで停止: 区間のどの段階でもパフォーマンス低下が見られる場合、制限を減少
迅速に開始する必要がある場合、次の保守的なデフォルト値を使用してください：
| サービスタイプ | 推奨開始制限 |
|---|---|
| チェックアウトプロセス | 15-25名 |
| 多段階登録 | 10-20名 |
| 決済処理 | 10-20名 |
| リソース集約的区間 | 20-40名 |
1-2週間: 保守的な制限でモニタリング
- サーバーメトリックを観察（CPU、メモリ、応答時間）
- ユーザー待機時間を追跡
- エラー率をモニタリング
3週間以上: 段階的な最適化
- サーバーリソースが未使用で待機時間が長い場合制限を増加
- 応答時間が増加したりエラーが発生した場合制限を減少
- 急激な変更ではなく10-20%ずつ調整
- サーバー応答時間 > 正常の2倍: 即座に制限を減少
- エラー率 > 1%: 制限を50%減少
- CPU使用量 > 80%: 制限を30%減少
- データベース接続プール枯渇: 制限を大幅に減少
ベストプラクティス
保守的アプローチ
- 小さく開始: 低い制限で開始し、段階的に増加
- 継続的にモニタリング: サーバーメトリックおよびユーザー体験を観察
- 急増を計画: トラフィック急増および季節的変動を考慮
安全ガイドライン
- サーバー処理能力を超過しない: 常に安全マージンを維持
- 徹底的にテスト: 現実的な負荷条件で制限を検証
- ロールバック計画を準備: 事故中の迅速な制限調整のための準備
パフォーマンス最適化
- 重要なパスを最適化: 処理時間を減らして有効進入許容数を増加
- 頻繁にキャッシング: リソース集約的な作業を最小化
- 水平スケーリング: 継続的な成長のためのインフラ改善を検討
高度な構成オプションおよび統合の詳細については、区間制御セグメント概要および基本設定ドキュメントを参照してください。