サービス拡張性
ABBYY Cloud OCR SDKサービスの概念では、多くのアプリケーションがこれを同時に利用し、新たなタスクのアップロードと処理結果の受け取りが同時に行われることを想定しています。そして各アプリケーションのタスクは、許容範囲とされる時間内で完了しなければなりません。
すべてのアプリケーションに対して適度な処理速度を確保するには、どのように処理能力を管理すればよいでしょうか？ この記事ではABBYY Cloud OCR SDKの拡張性についてご紹介します。
Cloud OCR SDKとMicrosoft Azure
ABBYY Cloud OCR SDKサービスはMicrosoft Azureを活用しています。これは、負荷に応じて処理能力を拡張する確実な方法です。 以下はその技術的な内容です：
- アップロードされた画像や文書はBLOBとして保存されます — データセンターは大量のデータを受け入れることができ、安全に分散されたデータを保管することができます。
- 送信されたタスクは、拡張可能な冗長化Azure SQLデータベースサービスで管理されます。
- タスクのOCR処理は、専用の「Azure workerロール」で実行され、その多くは同時に開始・使用することができます。
Cloud OCR SDKは1日に数百万ものページを処理することができます。
サービスの処理能力は、ほぼ無制限です。 ABBYY（および一部の当社クライアント）が実施した複数の高負荷実験では、処理スループットの技術的な限界に到達することはありませんでした。
処理キュー
サービスへ送られたすべてのタスクはキューに追加されて、アプリケーションの優先順位に沿って処理へ受け渡されます。 処理キューが長くなる場合、その高まる負荷に対応するために、新たなインスタンスが開始されます ― つまりサービスが拡張されます。
一般的に、サービスは実行されているインスタンスの平均負荷を一定の限度に抑えようとします。新しいインスタンスは、一定期間に平均負荷が高くなり過ぎるときにだけ開始されます。一方で、インスタンスごとの負荷があまり高くなくても、着信キューが増加している間は、サービスが縮小されることはありません。
ほとんどのアプリケーションが新しいタスクをランダムに送信するように、処理するページが徐々に増加／減少した場合、クライアントがサービス処理能力の変化に気づくことはありません。 ABBYYは負荷の傾向も監視しながら、可能な限り反応速度を改善しようとします。
大容量への対応
スケーラブルなCloudサービスは、会社の資料をデジタル形式に変換するような1度きりの大容量文書処理で力を発揮します。 これを社内で処理するには、ハードウェアに大きなコストをかける必要があるだけでなく、変換作業が終わってしまえば、購入したサーバーもあまり使われなくなってしまいます。 一方、Cloud OCR SDKサービスを使えば、処理するページの分だけのコストで済みます。
しかし、大きな文書のまとまり（バッチ）を十分な速さで処理することは可能でしょうか？また、他の小さなタスクを処理しているアプリケーションのレスポンス時間に影響を与えることはないのでしょうか？
バッチ処理 vs. ランダムなタイミングのアップロード
当社サービスの拡張性のロジックは以下の想定をベースにしています： 小さな容量のものがランダムなタイミングでアップロードされた場合は速いレスポンスが要求される。しかし、大量の文書が処理される場合は、バッチの全体的な時間の方が個々のページのレスポンスよりも重要になる。
1つのアプリケーションが大きなバッチを処理するためにアップロードすると、処理キューが増え、サービスは拡張し始めます。 短い期間、このバッチのページはかなり遅いスピードで処理されます。 しかし、一度拡張が完了すれば、処理速度は通常スピードに戻ります。 大型バッチにとって重要なトータルの処理時間は、少量のものを処理した場合と変わらなくなります。
一方で、この負荷の変化によって他のアプリケーションが影響を受けることはありません。なぜなら、拡張プロセスの間、大きなバッチを送ったアプリケーションの優先順位は下げられ、負荷の少ないアプリケーションから送られたページは、高い優先順位のまま処理されるからです。
実際の大容量文書バッチの処理スピードを知りたい場合、可能な限り短い時間で5,000ページほどをサービスに処理させる必要があります。 現実に想定されるお客様の負荷が非常に大きなものであり、テストで大容量の料金を払うのはちょっと...とお悩みの場合は、ぜひABBYYの営業までご連絡いただき、大容量テストを希望していることをお伝えください。 ― お客様に適したソリューションを提案させていただきます。
例
以下のチャートは、処理負荷とインスタンス数の関係をグラフに表したものです。
縦軸の単位は各ラインで異なります。
グラフ上の数字で示された期間は以下の処理を示しています：
- サービスが処理のために多くのページを含む大きなバッチを受信すると、（現在実行中のインスタンスの）平均インスタンスCPU使用率は、ほぼ100%に増加します。 サービスの拡張性アルゴリズムがこの比率を監視し、一定期間高いままの状態なら、サービスは拡張を始めます。 新しいインスタンスの開始には時間がかかる： 遅延は各インスタンスで5～10分。
- 負荷はまだ高いが、インスタンス平均CPU使用率は、サービスの拡張に合わせて減っていく。 着信する量やインスタンスの数は次第に均整化される。
- 負荷が減ると、インスタンスの平均CPU使用率も下がる。 一定期間、比率が低いままならサービスは縮小を始める。
このグラフは、サービスの拡張と縮小に関する一般的な原則をお見せするためのものです。 実際の生産データをもとにしていますが、お客様が特定の状況下で特定の文書を処理したとき、その処理スピードがこのグラフと同じになるかどうかについて、保証することはできません。
Cloudサービス vs. ローカルサーバー
OCRソリューションをインストールしたローカルサーバーとABBYY Cloud OCR SDKとで、効率を比較したいと考えることもあるでしょう。
小さい処理負荷なら、ローカルインスタンスの方が効率が良いかもしれません。大きなバッチの処理についても、序盤はスピードが速いかもしれません。それは、サービスが最初に拡張しなければならず、設定済みサーバーでOCR処理を始めるよりも時間がかかるからです。
一方、ローカルサーバーで無限に拡張することは不可能ですし、やがて物理的な処理速度の限界を迎えます。しかし、クラウドサービスは処理容量に関わらず、安定した結果を提供することができます。
ローカルサーバーとCloud OCR SDKサービスを比べる場合、インターネット接続のスピードも考慮する必要があります。1ページの処理で、実際には画像をアップロードする時間や結果をダウンロードする時間の方がタスクを処理する時間よりも長くなる場合があります。
まとめ
ABBYY Cloud OCR SDKサービスは、すべてのアプリケーションで、大量の文書を処理しつつ確実に早いレスポンスを提供する能力を持っています。
特別な条件がある場合、または処理スピードをテストしたい場合は、ぜひご登録の上開発を始めてから詳細をABBYYの営業までご相談ください。