進入許容数の設定
「進入許容数の設定」は、同時にサービスにアクセスできるユーザー数を決定する核心的なトラフィック制御メカニズムで、サーバー容量およびユーザーフローを管理する主要な方法です。このガイドでは、基本制御セグメントの固定型および変動型進入許容数について説明します。

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