FlexiCapture は、1 日あたり数百ページから数百万ページまで処理でき、数千人規模のオペレーターにも対応できます。事前にシステム負荷を見積もり、それに合わせてアーキテクチャとサーバーハードウェアを選定します。
システムは、次の方法でスケールアップできます。
- スキャンクライアント、検証クライアント、Processing Station を追加する
- Application、Processing、Licensing、Database の各サーバーと FileStorage をホストするマシンの性能を高める
- これらのサーバーの役割を複数のマシンに分散する
以下の数値を使用して、FlexiCapture サーバーコンポーネントの初期構成を選定します。
システム監視とボトルネック検出 では、現在のハードウェアが目標とするパフォーマンスを満たしているかどうか、およびスケールアップすべきタイミングを確認できます。
デモは、デモやパイロットプロジェクト向けの一般的な構成であり、本番規模のプロジェクトには推奨されません。システムのすべてのコンポーネントは、仮想マシンにインストールするか、PC にデプロイします。
データベースサーバーとして MS SQL Express を使用し、FlexiCapture サーバーと同じマシンにインストールできます。専用の FileStorage を使用しない場合は、ファイルをデータベースに直接保存することもできます。オペレーターと Processing Stations も同じマシンを共有できます。
商用プロジェクトでは、Processing Station を FlexiCapture サーバーまたは Database サーバーをホストしているコンピューターにインストールしてはいけません。Station が利用可能なすべてのリソースを消費し、サーバーのパフォーマンスが低下します。
Application Server、Processing Server、Licensing Server は 1 台のコンピューターにインストールできます。これによりサーバーの冗長化は実現できますが、Application Server のスケーラビリティは確保できません。
- Application Server は IIS 上で動作する Web サービスです。そのスケーリングと信頼性は、Microsoft Network Load Balancing テクノロジを使用したクラスタリングによって実現されます。クラスタ内のすべてのノードは、active-active モードで動作する対等なノードであり、いつでも停止できます。
- Processing Server と Licensing Server は Windows サービスです。これらの信頼性は、Microsoft Failover Cluster テクノロジに基づく active-passive クラスタを構成することで実現されます。
Microsoft は、これら 2 つのテクノロジを同一のコンピューター上で併用することを禁止しています。
信頼性は必要だがスケーリングは不要な場合は、Microsoft Failover Cluster もサポートする IIS 内で Application Server をクラスタ化してください。
Licensing Server と Processing Server は 1 台のマシンを共有できます。
Database サーバーはホストのリソースを大幅に消費するため、専用マシンにインストールしてください。他の FlexiCapture サーバーと併用する場合は、CPU と RAM の使用量を制限してください。また、同一ホスト上の他のサーバーのパフォーマンスに影響しないよう、データベースファイルも物理的に別の HDD に配置してください。
負荷が小さい場合は、Application Server マシン上の高速 HDD を FileStorage として使用できます。15,000 RPM 以上の SATA2 ディスクを使用し、冗長化のために少なくとも RAID1 を、より高いパフォーマンスのために RAID10 を構成してください。
ローカル HDD は、ページ数が増えるにつれて、特にグレースケール画像やカラー画像ではボトルネックになります。また、ディスクを追加するにはシステムを停止する必要があるため、必要に応じて拡張することもできません。
より大規模な用途では、NAS や SAN などの外部ストレージを使用してください。Application Server には、LAN、SCSI、Fibre Channel、または同様のインターフェイス経由で、1 Gb/s の読み書きアクセスが必要です。外部ストレージは容易に拡張できます。
次の図は、エンタープライズ環境における一般的な FlexiCapture ネットワーク構成を示しています。
高速で信頼性の高い通信を実現するため、Application Server を FileStorage および Database サーバーに直接接続してください。
- CPU: 物理コア 8 個、2.4 GHz 以上
- RAM: 16 GB
- HDD: 100 GB
- 1 Gb/s の NIC 2 基：LAN 接続用と Database Server 接続用に各 1 基
- FileStorage: SAN を使用する場合は、SCSI、Fibre Channel、または InfiniBand で接続
- OS: Windows 2012 以降
Application Server は、FlexiCapture のすべての通信のハブです。次の 2 種類のトラフィックを処理します。
- 大容量のバイナリデータ転送
- 高速なレスポンスを必要とする小規模な SOAP/JSON サービスリクエスト
Application Server は、次の 4 つの重要なリソースに依存します。
- クライアントへの接続用の高速なネットワークインターフェイス
- FileStorage および Database Server への高速で安定した接続
- 高速なマルチコア CPU:
- 速度が高いほど、各リクエストの処理が速くなります
- 物理コア数が多いほど、同時に処理できるリクエスト数が増えます
- 十分な RAM (物理コアごとに少なくとも 2 GB)
CPU を最大限に活用するには、FlexiCapture Web Services のアプリケーション プールに、物理コア数の 2 倍の IIS Worker Processes を設定します。たとえば、8 コアのプロセッサには 16 個の IIS Worker Processes を設定します。
これらのリソースのいずれかがボトルネックになる場合は、Application Server をスケールアップします。
- Application Server の役割を持つ複数のコンピューターをクラスター化する Microsoft Network Load Balancing を使用します。詳細については、フェールオーバー構成を参照してください。
- ハードウェアレベルでは、異なるクライアント範囲を、Application Server の役割を持つ異なるマシンに接続します。たとえば、1 台のマシンですべての自動処理を実行し、別のマシンを外部クライアント向けのウェブサービスとして公開できます。
いずれの場合も、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 は、同時接続する各クライアントのライセンスのコピーをメモリ内に保持します。そのため、必要な RAM 容量は同時に作業するスキャンオペレーターおよび検証オペレーターの数に応じて増加します。テストでは、1000 クライアント分までのライセンスを処理するには 2 GB の RAM で十分であることが確認されています。
同時接続クライアント数の多いプロジェクトでは、64 ビット版の Licensing Server を使用してください。1 台のサーバーで対応できる数を超えるクライアントに対応するには、2 台目の Licensing Server を追加してください。
サポートされるバージョン:
- MS SQL Server 2014 以降、Standard Edition または Enterprise Edition
- Oracle 12c Enterprise Edition
ABBYY FlexiCapture は、任意のプラットフォームにインストールされた MS SQL Server および Oracle をサポートしています。両ベンダーは、最適な設定、スケーリング、耐障害性に関する独自のガイダンスを公開しています。
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 を使用します。
- ほとんどのデータベース ファイルが RAM 上に保持され、高速に読み取れるよう、Database サーバー マシンには可能な限り多くの RAM を搭載します
- ディスク上に残るデータベース部分には、できれば SSD などの高速な HDD を使用します
- ミラーリングなど、トランザクション遅延が発生するデータベース モードは避けます
- データベースの復旧モデルを Simple に設定します
- データベースとそのログは別々のディスクに格納します
- 頻繁に変更されるテーブル (Document、Page、Batch、Task、EventLog) のインデックスを定期的に更新します。更新しない場合、インデックスがテーブル内のデータより大きくなる可能性があります
- LAN、SCSI、Fibre Channel、または InfiniBand 経由で接続された NAS または SAN
- 読み書き速度: ワークロードに応じて 100 MB/s 以上
- 容量: ワークロードに応じて 5 TB 以上
両方の値をプロジェクトに合わせて見積もってください。詳細については、FileStorage のサイジング を参照してください。
FileStorage の内容に対する検索インデックス作成やウイルス対策スキャンにより、パフォーマンスが低下したり、システムで処理中のファイルへのアクセスがブロックされたりする可能性があります。
RAID 10 などのフォールトトレラントなストレージ技術を使用してください。
- R: ページ画像を Application Server からダウンロードするステージの数
- W: ページ画像を Application Server にアップロードするステージの数
次に、この 2 つの速度を計算します。
たとえば、ある顧客が4段階のワークフローで、1時間あたり10,000枚のグレースケールページを処理するとします。ページ画像をApplication Serverとの間で転送するステージのみが、RとWの計算対象となります。
A4グレースケールファイルの平均サイズが3 MBの場合:
- 入力フロー = グレースケールページ画像10,000枚/時 = グレースケール画像2.8枚/秒 = 8.4 MB/秒
- 必要な書き込み速度 = 1 × 8.4 MB/秒 = 8.4 MB/秒
- 必要な読み取り速度 = 3 × 8.4 MB/秒 = 25.2 MB/秒
ハードディスクのパフォーマンスをベンチマークするには、MITライセンスの下で配布されているCrystalDiskMarkツールを使用できます。
容量は、画像が削除されるまでシステムに保存される期間によって決まります。
たとえば、ある顧客は 24 時間で 100,000 枚のグレースケール画像を処理します。Service-Level Agreement に基づき、1 ドキュメントあたりの処理時間は 2 日です。その後、顧客の ERP システムで追加チェックが行われるため、処理済みドキュメントは 2 週間保存されます。不一致が見つかった場合は、ドキュメントを FlexiCapture で編集し、再度 ERP システムにアップロードします。
したがって、画像は 2 + 14 = 16 日間保存されます。A4 グレースケール画像の平均ファイルサイズを 3 MB とすると、システムには 16 × 100,000 × 3 MB = 4.8 TB のデータが蓄積されます。
24時間あたり30万ページを超えるカラーページを処理するには、Large 構成を使用します。24時間あたり、白黒ページで最大300万ページ、カラーページで最大100万ページを処理できます。
Medium のすべての推奨事項が Large にも適用されますが、この規模ではそのすべてに従う必要があります。システムの各部分の負荷を見積もり、過剰なコストをかけずに処理できる十分な性能のハードウェアを選定してください。インターネット接続とバックエンド コネクタをテストし、目標とする性能を維持できることを確認してください。
当初から、10 Gb/s ネットワークと高スループットの FileStorage を計画してください。
以下のダイアグラムは、Large 構成で想定されるネットワーク アーキテクチャの例を示しています。
この規模における一般的なシステム要件はありません。代わりに、テスト済みの構成と測定されたパフォーマンスを確認してください。詳細については、Huawei FusionCube 6000 でのテスト結果を参照してください。
Large 構成を超える処理量の場合は、複数の独立した FlexiCapture インストールを 1 つの Administration and Monitoring ポイントの配下にまとめます。これが xLarge 構成です。 
