FlexiCapture は、1 日あたり数百ページから数百万ページまで処理でき、数千人規模のオペレーターにも対応できます。このドキュメントのガイドラインを参考にすれば、事前にシステム負荷を見積もり、サーバーに適したアーキテクチャとハードウェアを容易に選定できます。
システムは、次の方法でスケールアップできます。
- スキャンクライアント、検証クライアント、Processing Station の数を増やす
- Application、Processing、Licensing、Database の各サーバーと FileStorage のマシン性能を高める、またはこれらの役割に複数のマシンを使用する
以下の数値は、FlexiCapture サーバーコンポーネントの初期構成を評価または選定する際の目安になります。
システム監視とボトルネック検出 を利用すると、使用中のハードウェアでは目標とするパフォーマンスを満たせないことや、スケールアップすべきタイミングに来ていることを確認できます。
デモは、デモやパイロットプロジェクト向けの一般的な構成であり、本番規模のプロジェクトには推奨されません。システムのすべてのコンポーネントは、仮想マシンにインストールするか、PC にデプロイします。
データベースサーバーとして MS SQL Express を使用し、FlexiCapture サーバーと同じマシンにインストールできます。専用の FileStorage を使用しない場合は、ファイルをデータベースに直接保存することもできます。オペレーターと Processing Station は、同じマシンにインストールできます。
商用プロジェクトでは、Processing Station を FlexiCapture サーバーまたは Database サーバーをホストしているコンピューターにインストールしてはいけません。すべてのリソースを使い切ってしまい、サーバーのパフォーマンスが低下するためです。
技術的には、Application Server、Processing Server、Licensing Server は同一のコンピューターにインストールできます。サーバーの冗長化は確保されますが、Application Server のスケーリングは確保されません。
- Application Server は IIS 上で動作する Web サービスです。そのスケーリングと信頼性は、Microsoft Network Load Balancing テクノロジを使用したクラスタリングによって実現されます。クラスタ内のすべてのノードは、active-active モードで動作する対等なノードであり、いつでも停止できます。
- Processing Server と Licensing Server は Windows サービスです。これらの信頼性は、Microsoft Failover Cluster テクノロジに基づく active-passive クラスタを構成することで実現されます。
Microsoft は、これらのテクノロジを同一のコンピューター上で併用することを明確に禁止しています。
信頼性のみが必要な場合は、Microsoft Failover Cluster によるクラスタリングもサポートする IIS 内で Application Server をクラスタ化してください。
Licensing Server と Processing Server は同じマシンにインストールできます。
Database サーバーは専用マシンにインストールすることをお勧めします。非常に多くのリソースを消費するため、他の特定の FlexiCapture サーバーと組み合わせる場合は、隣接するサーバーのパフォーマンスに影響しないように、CPU と RAM の使用を制限し、データベースファイルは物理的に別の HDD に配置してください。
負荷が小さく、より高いパフォーマンスが必要な場合は、Application Server マシンで FileStorage として高速な HDD を使用できます。たとえば、15,000 RPM 以上の SATA2 ディスクを使用し、冗長化のために最低でも RAID1、より高いパフォーマンスを得るには RAID10 で構成します。
ただし、プロジェクトの後期段階で処理するページ数が増えると、この構成は、特にグレースケール画像やカラー画像を処理する場合に、ボトルネックになる可能性が高くなります。しかも、この構成はその場でスケールアップできず、システム を停止して別の HDD をアタッチする必要があります。
NAS や SAN などの外部ストレージを使用し、Application Server が LAN、SCSI、Fibre Channel、または同様のインターフェイスを介して 1 Gb/s で読み書きアクセスできるようにしてください。これにより、FileStorage をスムーズにスケールアップできます。
エンタープライズ環境における一般的な FlexiCapture ネットワーク構成:
高速で信頼性の高い通信を実現するため、Application Server を FileStorage および Database サーバーに直接接続することを推奨します。
要件:
- CPU: 8 物理コア、2.4 GHz 以上
- RAM: 16 GB
- HDD: 100 GB
- 1 Gb/s の NIC x 2: 1 つは LAN 接続用、もう 1 つは Database サーバー接続用
- FileStorage: SAN を使用する場合は、SCSI、Fibre Channel、または InfiniBand で接続します
- OS: Windows 2012 以降
Application Server は、Web サービスであると同時に、FlexiCapture におけるすべての通信のハブでもあり、次の両方を担います。
- 大容量のバイナリ データの転送
- 小規模な SOAP/JSON サービス リクエストへの迅速な応答
重要なリソースは次のとおりです。
- クライアント接続用の高速なネットワーク インターフェイス。
- FileStorage および Database サーバーへの高速で安定した接続。
- 高速なマルチコア CPU:
- 速度が高いほど、各リクエストはより速く処理されます。
- 物理コア数が多いほど、同時に処理できるリクエスト数が増えます。
- 十分な RAM。物理コアごとに少なくとも 2 GB。
CPU を最大限に活用するには、FlexiCapture Web Services のアプリケーション プールを、物理コア数の 2 倍の IIS Worker Processes で構成します。たとえば、8 コアのプロセッサには 16 個の IIS Worker Processes を設定します。
これらのリソースのいずれかがボトルネックになっている場合は、Application Server をスケールアップします。
- Microsoft Network Load Balancing テクノロジを使用する方法。この方法では、Application Server ロールを持つ複数のコンピューターをクラスター化します。詳細な手順については、フェールオーバー構成を参照してください。
- ハードウェア レベルで対応する方法。異なる範囲のクライアントを、Application Server ロールを持つ別々のマシンに接続します。たとえば、あるマシンで自動処理全体に対応し、別のマシンで外部クライアント向けに公開できます。
いずれの場合も、Application Server ロールを持つすべてのマシンは、同じ Database と FileStorage に対して同等の接続性を備えている必要があります。
Processing Server と Licensing Server
- 4 コア CPU、2.4 GHz 以上
- 8 GB RAM
- HDD: 100 GB
- LAN 接続用 1 Gb/s NIC
- OS: Windows 2012 以降
サーバーには安定したネットワーク接続が不可欠です。そうでないと、文書処理が停止します。冗長化を確保するには、Microsoft Failover Cluster を使用してください。詳細な手順についてはフェールオーバー構成を参照してください。
Licensing Server は、同時接続するすべてのクライアント用のライセンスのコピーをメモリ内に保持します。スキャンオペレーターや検証オペレーターを多数同時に使用する場合は、この点にご注意ください。また、同時接続クライアント数の多いプロジェクトでは、64 ビット版の使用を推奨します。弊社のテストでは、1000 クライアント分までのライセンスを処理するには 2 GB の RAM で十分であることが確認されています。さらに多くの同時接続クライアントに対応するには、複数の Licensing Server を使用することを検討してください。
要件:
- MS SQL Server の場合: MS SQL Server 2014 以降、Standard Edition または Enterprise Edition。
- Oracle の場合: Oracle 12c Enterprise Edition。
MS SQL Server のハードウェア:
- CPU: 物理 8 コア、3.4 GHz 以上
- RAM: 16 GB 以上
- HDD: 400 GB
- OS: Windows 2012 以降
Oracle のハードウェア: Oracle Exadata Database Machine X2-2, Quarter Rack。
ABBYY FlexiCapture は、任意のプラットフォームにインストールされた MS SQL Server および Oracle をサポートしています。各データベース サーバーには、最適な設定、スケーリング、耐障害性に関する独自の推奨事項があります。
MS SQL Server については、次を推奨します:
- 可能であれば Database サーバー マシンの RAM を増やし、データベース ファイルの大部分を RAM 上に保持して、より高速にアクセスできるようにすること。
- ディスク上に配置されたデータベース部分にすばやくアクセスできる高速な HDD を使用すること (この用途には SSD の使用を推奨します) 。
- トランザクション遅延を伴うデータベース モード (ミラーリングなど) を避けること。
- データベースの復旧モデルとして Simple を選択すること。
- データベース本体とそのログを別々のディスクに保存すること。
- 頻繁に変更されるテーブル (Document、Page、Batch、Task、EventLog) のインデックスを定期的に更新すること。そうしないと、インデックスのサイズがテーブル内のデータ サイズより大きくなる可能性があります。
要件:
-
LAN、SCSI、Fibre Channel、または InfiniBand 経由で接続された NAS または SAN
-
読み書き速度: 100 MB/s*
-
容量: 5 TB*
-
読み書き速度と容量はワークロードによって異なります。FileStorage sizing を参照してください。
読み書き速度と容量の要件は、主に次の 2 つの要因に大きく左右されます。
1. 1 日 (24 時間) あたりおよび 1 時間あたりに処理されるページ数の平均値とピーク値、ならびにそのカラーモード。 Performance metrics セクションで説明したように、カラー、グレースケール、白黒でスキャンされたページの一般的なファイルサイズを使用して、1 秒あたりのバイト数で入力フローを見積もることができます。
画像は、システム内で転送されるデータの大部分を占めます。処理フローを分析し、次の 2 つの値を定義します。
- ページ画像が Application Server からダウンロードされるステージ数 R
- ページ画像が Application Server にアップロードされるステージ数 W
読み書き速度の要件は、次のように計算できます。
- 必要な書き込み速度 = W × 入力フロー (バイト/秒) 。
- 必要な読み取り速度 = R × 入力フロー (バイト/秒) 。
例。 ある顧客は、1 時間あたり 10,000 ページのグレースケール画像を処理する必要があります。処理フローには、次のステージが含まれます。
- Processing Station がホットフォルダーから画像をダウンロードし、事前認識を行ってから、Application Server にアップロードします (W=1、R=0) 。
- 別の Processing Station がこれらの画像を Application Server から取得して認識を実行し、OCR の結果が Application Server に送られます (W=1、R=1) 。
- 検証オペレーター が画像と認識データをダウンロードして確認し、検証済みデータを Server に送り返します (W=1、R=2) 。
- 最後に、Processing Station が画像と検証済みデータをダウンロードし、顧客のバックエンドシステムに送信します (W=1、R=3) 。
A4 サイズのグレースケールスキャン 1 ページあたりの平均ファイルサイズを 3 MB とすると:
- 入力フロー = 1 時間あたり 10,000 枚のグレースケールページ画像 = 1 秒あたり 2.8 枚のグレースケール画像 = 8.4 MB/s。
- 必要な書き込み速度 = 1 × 8.4 MB/s = 8.4 MB/s。
- 必要な読み取り速度 = 3 × 8.4 MB/s = 25.2 MB/s。
ハードディスクの性能をベンチマークするには、MIT ライセンスで配布されている CrystalDiskMark ツールを使用できます。
2. ドキュメントがシステムに保存される期間。
例。 ある顧客は、24 時間で 100,000 枚のグレースケール画像を処理する必要があります。Service-Level Agreement に基づき、1 ドキュメントあたりの処理時間は 2 日です。処理済みドキュメントは、顧客の ERP システムで追加チェックが行われるため、2 週間保存されます。不一致が発生した場合は、ドキュメントが FlexiCapture で編集され、再度 ERP システムにアップロードされます。
したがって、画像は 2 + 14 = 16 日間保存する必要があり、システムには 16 × 100,000 枚のグレースケール画像 × 3 MB (A4 グレースケール画像の平均ファイルサイズ) = 4.8 TB のデータが蓄積されます。
RAID 10 などのフォールトトレラントなストレージ技術の使用を強く推奨します。FileStorage の内容に対する検索インデックス作成やウイルス対策スキャンにより、パフォーマンスが低下したり、システムで処理中のファイルへのアクセスがブロックされたりする可能性があります。
