「ノー」と言うべき時を見極める4Dウェブサーバー

10月 20, 2026 1 読了時間

4D Web Serverのワークロードの微調整が、今や朝飯前になりました。4D 21 R5以降、Webサーバーは、過剰なデータ要求量、多すぎるリクエスト、あるいはゲストセッションの急増など、意図しない過負荷にさらされることがなくなりました。

Webアプリサーバー向けに完全にカスタマイズされたレート制限システムを構築するために必要なすべてを、この記事で詳しくご紹介します。

以前の 4D 21 R4 に関するブログ記事では、REST セッションにおけるエンティティセットの数を制限する方法をご紹介しましたが、これははるかに大きな物語の序章に過ぎませんでした。本日、その物語は（最終的なものではありませんが）重要なマイルストーンに到達しました。

4D 21 R5では、クォータ機能により、4D Web Serverを微調整して、受信および送信トラフィックを適切に制御 できるようになりました。

この新機能によって、Webサーバーのデフォルトの動作が変わることはありません。初期設定では、クォータは適用されません。ニーズに応じて、包括的なクォータのラインナップから自由に選択できます。1つだけ使うもよし、すべて使うもよし、その細かさは完全にユーザー次第です。

HDI_WebServer_RateLimitingQuotas

従来のWeb保護にアプリケーションインテリジェンスを追加

この機能は、リバースプロキシ、WAF、ファイアウォール、その他のサービスを置き換えるものではなく、それらを補完するものです。これらの技術はネットワークの境界を保護し、悪意のあるトラフィックをフィルタリングしますが、4DはWebサーバー内部でアプリケーションレベルのワークロード制御を提供します。

その付加価値は、4Dセッションとアプリケーションコンテキストを認識している点にあります。開発者は、リクエスト、データ量、セッション、およびエンティティセットに対して、グローバルおよびセッションレベルのクォータを定義できます。これにより、不正な形式や過剰な使用、MCPトラフィック、およびビジネス固有のワークフローを、アプリケーション内で直接制御することが可能になります。

サーバーレベルおよびセッションレベルのクォータ

詳細に入る前に：よりきめ細かな制御を行うため、ほとんどの上限は次の2つのレベルで設定可能です：

サーバーレベル：サーバー全体のアクティビティを制限します
セッションレベル：新しく作成された各セッションに個別に適用されます

サーバーレベルのみのクォータ、セッションレベルのみのクォータ、あるいは両方を組み合わせて利用することができます。

利点：セッションレベルのクォータは、すべてのユーザーを平等な立場に置き、特定のユーザーがWebサーバーのリソースを独占することを防ぎます。

クォータで規制できるもの

クォータにより、以下を制限できます。

インバウンドトラフィック：受信バイト数、受理されたリクエスト数
送信トラフィック：送信されたバイト数
セッション：アクティブなセッションの最大数
ゲストセッション： setPrivileges() を通じてまだ認証されていないセッションの最大数
エンティティセット：新しく作成される各RESTセッションに対して、デフォルトで許可されるエンティティセットの最大数

基本原則：クォータを超過すると、サーバーはHTTP 429 – Too Many Requests を返します。

利点：Web サーバーに過負荷をかける可能性のあるあらゆる側面がカバーされています。送受信バイト数だけでなく、リクエスト数も対象となります。アイドル状態のゲストセッションや、同時ユーザーセッション数にも上限を設定できます。

クォータは、Web サーバーの使用量を適切に調整し、サーバーがダウンしたりクラッシュしたりしているのではなく、単にその役割を果たして、信頼性の高い可用性を維持するために負荷を調整しているだけであることをユーザーに伝えます。

仕組み：2種類のクォータ

クォータには2つの種類があります：

レート制限クォータ
同時接続クォータ

レート制限クォータ

これらは以下の項目をカバーします：

受信バイト数
受理されたリクエスト数
送信バイト数

これらは分単位および時間単位の タイムウィンドウ方式を採用しているため、Webサーバーおよび／またはそのセッションが、1分間または1時間のウィンドウ内で処理できる最大バイト数（またはリクエスト数）を定義できます。

ある時間ウィンドウ内でクォータが超過すると、次のウィンドウが開くまで、サーバーはHTTP 429 を返します。

これらのクォータは、サーバー全体およびセッションレベルの両方で設定できます。

メリット：1 分単位と 1 時間単位のウィンドウを組み合わせることで、非常にきめ細かな制御が可能になり、1 時間ごとの上限を厳守しつつ、分単位のピークを平準化することができます。

セッションレベルでも同じロジックを適用することで、各ユーザーのアクティビティを個別に規制し、1 人のユーザーが帯域幅をすべて使い果たしてしまうのを防ぐことができます。

同時接続クォータ

これには以下が含まれます：

セッションの最大数
ゲストセッションの最大数
新しく作成される各RESTセッションに対して、デフォルトで許可されるエンティティセットの最大数

これらは絶対的なカウンターです。クォータを超過すると、カウンターの数値が減少するまで、 サーバーはHTTP 429を 返します。例えば 、セッションが終了して新しいセッションのための空きが確保された場合などです。

利点：これにより、トラフィックだけでなくユーザー数も規制できるため、レート制限クォータを効果的に補完します。

クォータの設定

WEB Server オブジェクトは、quotas プロパティを公開しています。これは、より正確には、 4D.QuotaManager クラスのインスタンスです。

クォータの設定には3つの方法があります。アーキテクチャに最も適した方法を選択してください：

1- Webサーバーがすでに稼働している状態で、quotas オブジェクトを動的に更新する：

var $quotas : 4D.QuotaManager

$quotas:=WEB Server().quotas

$quotas.inBytesPerMin:=10000000

2-Webサーバーの起動時にクォータオブジェクトを渡す：

var $quotas:={}

$quotas.inBytesPerMin:=20000000

WEB Server().start({quotas: $quotas})

3- 起動時に自動的に読み込まれるHTTPQuotas.json 設定ファイルを使用する：

  {
    "inBytesPerMin": 10000
  }

利点：完全な柔軟性。どのようなデプロイ環境であっても、これらのオプションのいずれかが適合します。

具体的な例

以下は、20人が利用し、時折（数枚の画像やレポートなど）使用される社内アプリケーションの例です：

var $quotas:={}

// Maximum number of input bytes accepted in a one-minute time window on the web server
$quotas.inBytesPerMin:=20000000

// Maximum number of sent bytes in a one-minute time window in a session
$quotas.outBytesPerMinPerSession:=10000000

// Maximum number of allowed sessions on the web server
$quotas.nbSessions:=50

// Maximum number of not authenticated sessions on the web server
$quotas.nbGuestSessions:=10

// Maximum number of accepted requests in a one-minute time window on the web server
$quotas.nbRequestsPerMin:=500

// Maximum number of accepted requests in a one-hour time window on the web server
$quotas.nbRequestsPerHour:=20000

WEB Server().start({quotas: $quotas})

デバッガーには次のように表示されます：

注：

nbRequestPerHour は、単にnbRequestPerMin × 60（この場合 30,000）という値ではありません。意図的に20,000という低い値に設定されています。これにより、たとえ数分間だけ1分あたりのクォータを上限まで使い切るようなワークロードであっても、そのペースを1時間近く維持することはできず、単なる1分単位のクォータの言い換えではなく、真の意味での1時間あたりの上限が確保されます。

ユーザーがアプリケーションを使用している間、クォータが超過するたびに、サーバーは HTTP 429 – Too Many Requests を返します。

該当する場合、レスポンスヘッダーの「Retry-After」が、クライアントに再試行までの待機時間を秒単位で正確に通知します：

詳細なHDIを使って実際に試してみて、ドキュメントで詳細を確認し、フォーラムで体験談をぜひ共有してください。

サーバーの過負荷による速度低下とはおさらばしましょう。今すぐ、Webサーバーの最高のパフォーマンスを最大限に活用してください。