メインコンテンツへスキップ
FlexiCapture は、1 日あたり数百ページから数百万ページまで処理でき、数千人規模のオペレーターにも対応できます。このドキュメントのガイドラインを参考にすれば、事前にシステム負荷を見積もり、サーバーに適したアーキテクチャとハードウェアを容易に選定できます。 システムは、次の方法でスケールアップできます。
  • スキャンクライアント、検証クライアント、Processing Station の数を増やす。
  • Application、Processing、Licensing、Database の各サーバーと FileStorage のマシン性能を高める、またはこれらの役割に複数のマシンを使用する。
以下の数値は、FlexiCapture サーバーコンポーネントの初期構成を評価または選定する際の目安になります。

 

20,000

5,000

1,000

8

3

3

 

デモ

100 万

500,000

300,000

80

100

300

 

Medium

300 万

200 万

100 万

120

500

1,000

 

Large (Medium 10 Gb/s)

さらに大規模な場合

 

xLarge (ABBYY FlexiCapture インストールの組み合わせ)

ボトルネック監視 を利用すると、使用中のハードウェアでは必要なパフォーマンスを満たせないことや、スケールアップすべきタイミングに来ていることを確認できます。 デモ は、デモやパイロットプロジェクト向けの一般的な構成であり、本番規模のプロジェクトには推奨されません。システムのすべてのコンポーネントは、仮想マシンにインストールするか、PC にデプロイします。

ABBYY FlexiCapture

コンピューター 1 台:

4 コア CPU、2.4 GHz

8 GB RAM

HDD:

  • OS および一時ファイル用に 100 GB
  • Database および FileStorage 用に 100 GB

OS: Windows 2012 以降

データベースサーバーとして MS SQL Express を使用し、FlexiCapture サーバーと同じマシンにインストールできます。専用の FileStorage を使用しない場合は、ファイルをデータベースに直接保存することもできます。オペレーターと Processing Station は、同じマシンにインストールできます。
商用プロジェクトでは、Processing Station を FlexiCapture サーバーまたは Database サーバーをホストしているコンピューターにインストールしてはいけません。すべてのリソースを使い切ってしまい、サーバーのパフォーマンスが 低下するためです。
Medium はスケーラブルで、各サーバーコンポーネントを専用マシンにインストールするため、商用プロジェクトで一般的に採用される構成です。 Application Server は、Database サーバー、Processing Server、Licensing Server とは異なるスケールアップ方式を採用しているため、専用マシンにインストールする必要があります。
技術的には、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 Server と組み合わせる場合は、隣接するサーバーのパフォーマンスに影響しないように、CPU と RAM の使用を制限し、データベースファイルは物理的に別の HDD に配置してください。 負荷が小さく、より高いパフォーマンスが必要な場合は、Application Server マシンで FileStorage として高速な HDD を使用できます。たとえば、15,000 RPM 以上の SATA2 ディスクを使用し、冗長化のために最低でも RAID1、より高いパフォーマンスを得るには RAID10 で構成します。 ただし、プロジェクトの後期段階で処理するページ数が増えると、この構成は、特にグレースケール画像やカラー画像を処理する場合に、ボトルネックになる可能性が高くなります。しかも、この構成はその場でスケールアップできず、System を停止して別の HDD をアタッチする必要があります。 NAS や SAN などの外部ストレージを使用し、Application Server が LAN、SCSI、Fibre Channel などを介して 1 Gb/s で読み書きアクセスできるようにしてください。これにより、FileStorage をスムーズにスケールアップできます。 以下では、FileStorage ハードウェアに必要なパフォーマンスの計算方法について説明します。 エンタープライズ環境における一般的な FlexiCapture ネットワーク構成: 高速で信頼性の高い通信を実現するため、Application Server を FileStorage および Database サーバーに直接接続することを推奨します。

Application Server

CPU: 物理8コア、2.4 GHz以上

16 GB RAM

HDD: 100 GB

NIC 2基、各1 Gb/s:

  • 1基はLAN接続用
  • 1基はデータベースサーバー接続用

FileStorage: SANを使用する場合は、SCSI、Fibre Channel、またはInfiniBandで接続してください。

OS: Windows 2012以降

Web サービスであり、FlexiCapture のすべての通信の中核を担う Application Server は、次の 2 つの役割を果たします。

  • 大容量のバイナリ データの転送
  • 小規模な SOAP/JSON サービス リクエストへの高速応答

重要なリソースは次のとおりです。

  1. クライアント接続用の高速なネットワーク インターフェイス
  2. FileStorage および Database Server への高速で安定した接続
  3. 高クロックのマルチコア CPU
    • クロック速度が高いほど、各リクエストはより速く処理されます。
    • 物理コア数が多いほど、同時に処理できるリクエスト数も増えます。

CPU を最大限に活用するには、FlexiCapture Web Services のアプリケーション プールで、物理コア数の 2 倍の IIS Worker Processes を使用してください。たとえば、8 コアのプロセッサ であれば 16 個の IIS Worker Processes です。

  1. 十分な RAM (物理コア 1 つあたり少なくとも 2 GB)

これらのリソースのいずれかがボトルネックになっている場合は、Application Server をスケールアップしてください。

  • Microsoft Network Load Balancing テクノロジを使用する方法。これにより、Application Server の役割を持つ複数のコンピューターをクラスター化できます。詳細な手順は FlexiCapture システム管理者ガイドを参照してください。
  • ハードウェア レベルで、異なるクライアント群を、Application Server の役割を持つ別々のマシンに接続する方法。たとえば、1 台のマシンで自動処理をすべて担当させ、別の 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 を使用してください。詳細な手順については FlexiCapture システム管理者ガイドを参照してください。

Licensing Server は、同時接続するすべてのクライアント用のライセンスのコピーをメモリ内に保持します。スキャンオペレーターや検証オペレーターを多数同時に使用する場合は、この点にご注意ください。 また、同時接続クライアント数の多いプロジェクトでは、64 ビット版の使用を推奨します。弊社のテストでは、1000 クライアント分までのライセンスを処理するには 2GB の RAM で十分であることが確認されています。 さらに多くの同時接続クライアントに対応するには、複数の Licensing Server を使用することを検討してください。

データベースサーバー

MS SQL Server の場合：

データベース：MS SQL Server 2014 以降、Standard Edition または Enterprise Edition

ハードウェア：

CPU：物理 8 コア、3.4 GHz 以上

16 GB RAM 以上

HDD：400 GB

OS：Windows Server 2012 以降

Oracle の場合：

データベース：Oracle 12c Enterprise Edition

ハードウェア：Oracle Exadata Database Machine X2-2、Quarter Rack

ABBYY FlexiCapture は、任意のプラットフォームにインストールされた MS SQL Server および Oracle をサポートしています。これらのデータベースサーバーには、それぞれ最適な設定、スケーリング、耐障害性に関する推奨事項があります。

MS SQL Server に関する推奨事項:

  • 可能であれば、データベースサーバーマシンの RAM を増やし、データベースファイルの大部分を RAM 上に保持してアクセスを高速化すること。
  • ディスク上に配置されたデータベース部分にすばやくアクセスできるよう、高速な HDD を使用すること (この用途には SSD の使用を推奨します) 。
  • トランザクション遅延が発生するデータベースモード (Mirroring など) は避けること。
  • データベースの復旧モデルとして Simple を選択すること。
  • データベース本体とそのログは別々のディスクに保存すること。
  • 頻繁に変更されるテーブル (Document、Page、Batch、Task、EventLog) については、定期的にインデックスを更新すること。これを怠ると、インデックスのサイズが テーブル内のデータサイズより大きくなる可能性があります。

FileStorage

NAS または SAN

LAN、SCSI、Fibre Channel、または InfiniBand 経由で接続

読み書き速度: 100 MB/s*

容量: 5 TB*

*読み書き速度および容量要件は、主に次の 2 つの要因に大きく左右されます。

1. 1 日 (つまり 24 時間) あたりおよび 1 時間あたりに処理されるページ数の平均値とピーク値、ならびにその色モード。Performance Metrics セクションで説明したとおり、カラー、グレースケール、白黒でスキャンされたページの代表的なファイルサイズを用いることで、1 秒あたりのバイト数として入力フローを見積もることができます。

画像は、システム内で転送されるデータの大半を占めます。処理ワークフローを分析すると、次の 2 つの値を定義できます。

  • ページ画像が Application Server からダウンロードされるステージ数 R。
  • ページ画像が Application Server にアップロードされるステージ数 W。

読み書き速度の要件は、次のように計算できます。

  • 必要な書き込み速度 = W x 1 秒あたりの入力フロー (バイト数) 。
  • 必要な読み取り速度 = R x 1 秒あたりの入力フロー (バイト数) 。

例。ある顧客は、1 時間あたり 10,000 ページのグレースケールページを処理する必要があります。処理ワークフローは 3 つのステージで構成されています。

  1. 1 つ目の Processing Station は、ホットフォルダーから画像をダウンロードし、事前認識を実行したうえで Application Server にアップロードします (W=1、R=0) 。
  2. 別の Processing Station がこれらの画像を Application Server から取得して認識を実行し、その OCR 結果が Application Server に送られます (W=1、R=1) 。
  3. 検証オペレーターが確認のために画像と認識済みデータをダウンロードし、検証済みデータを Server に送り返します (W=1、R=2) 。
  4. 最後に、Processing Station が画像と検証済みデータをダウンロードし、それらを顧客のバックエンドシステムに送信します (W=1、R=3) 。
    A4 グレースケールスキャンの平均ファイルサイズを 3 MB とすると、計算は次のようになります。

入力フロー = 1 時間あたり 10,000 枚のグレースケールページ画像 = 1 秒あたり 2.8 枚のグレースケール画像 = 8.4 MB/s。

必要な書き込み速度 = 1 x 8.4 MB/s = 8.4 MB/s。

必要な読み取り速度 = 3 x 8.4 MB/s = 25.2 MB/s。

ハードディスクの性能をベンチマークするには、MIT ライセンスで配布されている CrystalDiskMark ツールを使用できます。

  1. 文書がシステムに保存される期間。

例。ある顧客は、24 時間で 100,000 枚のグレースケール画像を処理する必要があります。Service-Level Agreement に基づき、文書 1 件あたりの処理時間は 2 日です。処理済み文書は、顧客の ERP システムで追加チェックが行われるため 2 週間保存されます。不一致が発生した場合は、文書が FlexiCapture で編集され、再度 ERP システムにアップロードされます。

したがって、画像は 2+14 = 16 日間保存する必要があり、システムには 16 x 100,000 枚のグレースケール画像 x 3 MB (A4 グレースケール画像の平均ファイルサイズ) = 4.8 TB のデータが蓄積されます。

注: フォールトトレラントなストレージ技術 (例: RAID 10) の使用を強く推奨します。FileStorage の内容に対する検索インデックス作成やアンチウイルススキャンは、パフォーマンスの低下を招いたり、システム自体で処理されているファイルへのアクセスを妨げたりする可能性があります。

大量のカラーページ (30万ページ超) を扱う場合は、Large 構成が必要です。この構成の処理能力は、24時間あたり白黒ページで最大300万ページ、カラーページで最大100万ページです。 Medium 構成について前述した内容は、Large 構成にもすべて当てはまります。違いは、あらゆる最適化の推奨事項に従い、システムの各部分に特に注意を払う必要がある点です。つまり、負荷を見積もり、十分な性能を備えつつ過度に高価ではないハードウェアを選定しなければなりません。また、インターネット接続とバックエンド コネクタについても、必要な性能レベルで動作できることを確認するためにテストしてください。 当初から、10 Gb/s ネットワークと高性能な FileStorage の利用を検討してください。Large 構成で想定されるネットワーク アーキテクチャを以下に示します。 Large 構成向けの一般的なシステム要件を示す代わりに、このドキュメントに記載されている、テスト済みの構成とそのパフォーマンスを参照することをお勧めします。 さらに高いパフォーマンスを実現するには、複数の独立した FlexiCapture インストールを 1 つの Administration and Monitoring ポイントの配下で組み合わせます。これを xLarge 構成と呼びますが、これはこのドキュメントの対象外です。