ICAP パフォーマンス概要
This document provides guidance on how Glasswall Halo ICAP server performs across different deployment sizes, as detailed in the Performance summary.
これらの事前定義された導入規模は、組織が自社の運用規模に対して Halo がどのように機能する可能性があるかを理解するのに役立ちます。
3つの構成例は有用なベンチマークとして機能しますが、Halo は非常に高い拡張性を備えています。十分なコンピュートリソースと予算があれば、幅広いパフォーマンス要件および容量要件に対応するよう導入できます。
これらのガイドラインは、パフォーマンスに対する期待値を設定し、初期導入の意思決定に役立てるための枠組みを提供します。
導入ユースケース
ユースケース 1: ファイルダウンロードのみ
このモデルは、Halo ICAP server を意図的なファイルダウンロード専用で使用する組織に適用されます。たとえば、ドキュメント、インストーラー、メディアファイルなどです。このシナリオでは、ユーザーが意図的に開始したダウンロードのみが ICAP server に転送されます。その他のすべての Web アセット(画像、スクリプト、スタイルシートなど)は除外されます。
1秒あたりの推定リクエスト数 (RPS)
各ユーザーは、1日あたり約40件のファイルダウンロードを開始すると想定されています。この推定値は Glasswall の社内観測に基づいています。
1日あたりのダウンロード数を1秒あたりのリクエスト数に変換するには:
RPS = 40 downloads per day ÷ 86400 seconds per day ≈ 0.00046
簡略化のため、これはユーザーあたり 0.00046 RPSに丸められています。
| 従業員数 | 1秒あたりの推定リクエスト数 (RPS) |
|---|---|
| 100 | 0.046 RPS |
| 500 | 0.23 RPS |
| 1,000 | 0.46 RPS |
| 5,000 | 2.3 RPS |
注: 「request」は、ICAP server によってスキャンされる、ユーザーが開始したファイルダウンロードを指します。例として、PDF レポート、zip アーカイブ、または実行可能ファイルのダウンロードが含まれます。
これらの数値は保守的な見積もりです。実際の使用状況は、自動化スクリプト、スケジュールされたダウンロード、またはユーザーの行動によって異なる場合があります。お使いの環境に自動化システムや頻繁なバッチダウンロードが含まれる場合は、それに応じて計算を調整してください。
パフォーマンス結果の例
小規模導入
- シングルノード Kubernetes cluster
- 5 Engines
- 8 Virtual cores
- 28 GB memory
スループット: 1 秒あたり 30 リクエスト (RPS)
組織規模の目安: 約 65,000 users(ファイルダウンロードのユースケース)
ユースケース 2: すべての Web トラフィックスキャン
このモデルでは、Halo ICAP server は、意図的なダウンロードだけでなく、すべての Web トラフィックをスキャンします。これは、ユーザーのブラウザーまたはマシン上のプロキシが、すべての Web リクエストを ICAP server に転送することを前提としています。
推定リクエスト/秒 (rps)
Web利用の推定値は、以下に基づいています:
- 平均的なWebページの読み込みには71個のアセットが必要です (http archive 2024)
- ユーザーは1日あたり約130ページのWebページを閲覧します (digital silk web statistics)
その結果:
9230 asset requests per user per day
RPSに換算すると:
RPS = 9230 ÷ 86400 ≈ 0.1068
簡略化のため、これはユーザー1人あたり0.1 RPSに丸めています。 0.1
| 従業員数 | 1秒あたりの推定リクエスト数 (RPS) |
|---|---|
| 10 | 1 RPS |
| 50 | 5 RPS |
| 100 | 10 RPS |
| 250 | 25 RPS |
注: この計算ではブラウザキャッシュを考慮していないため、実際にはICAP serverへの負荷が大幅に低減される可能性があります。信頼できるキャッシュヒット率のデータがないため、これらの推定値はキャッシュなしを前提としています。実際のシステム負荷は、運用環境ではこれより低くなる場合があります。
パフォーマンス結果の例
小規模デプロイメント
- シングルノード Kubernetes cluster
- 5 Engines
- 8 Virtual cores
- 28 GB memory
スループット: 1 秒あたり 30 リクエスト (RPS)
同等の組織規模: 約300ユーザー(全Webトラフィックのユースケース)
中規模デプロイメント
- 3ノードのKubernetesクラスター
- 合計15 Engines
- ノードあたり8仮想コア(合計24)
- ノードあたり28 GBメモリ(合計84 GB)
スループット: 毎秒70リクエスト(RPS)
同等の組織規模: 約700ユーザー
大規模デプロイメント
- 5ノードのKubernetesクラスター
- 合計25 Engines
- ノードあたり8仮想コア(合計40)
- ノードあたり28 GBメモリ(合計140 GB)
スループット: 毎秒100リクエスト(RPS)
同等の組織規模: 約1000ユーザー
概要
これらのデプロイメント例は、特定のファイルダウンロードをスキャンする場合でも、すべてのWebトラフィックをスキャンする場合でも、Glasswall Halo ICAPサーバーデプロイメントのサイジングを開始するための出発点となります。パフォーマンスは、必要に応じて水平方向または垂直方向にスケーリングすることで、特定の要件に合わせて調整できます。
詳細なガイダンスやお客様向けのサイジングに関するアドバイスについては、Glasswall チームまでお問い合わせください。