Oswald Regular
OpenSans Regular
Continuous>Flows

リアルタイムな業務データ処理は非常に困難であり、実際の要件に対応できるソフトウェア製品はほとんどありません。しかし、Ab Initioなら実現できます。

Ab Initioの持つ、Co>Operating SystemのContinuous>Flows機能という一つのテクノロジーは、それだけで“ミニバッチ”、高容量の“非同期メッセージ処理”、サービス指向アーキテクチャ(SOA)、遅延時間の短い“要求/応答”アプリケーションなど、幅広くリアルタイムアプリケーションに対処します。

Co>Operating Systemは“データフローエンジン”です。このエンジンは、連続した“コンポーネント”でレコード、つまりトランザクションのストリームを処理します。各コンポーネントは、たとえば、出力レコードを生成するためのトランスフォームルールを適用するなど、入力レコードに関するさまざまな計算や処理を行います。複雑な処理ロジックは、簡単に理解できる手順に分解され、各手順はさまざまなコンポーネントによって実行されます。レコードは、処理に必要なコンポーネントを通ります。

このデータフローモデルは、バッチ処理とリアルタイム処理の両方に完全に適合しています。バッチアプリケーションとリアルタイムアプリケーションは、まったく同じとは言えませんが、ほとんどが似ています。アプリケーションがバッチであるか、またはリアルタイムであるかは、終点の出力コンポーネントによって決まります。バッチアプリケーションは、フラットファイルおよび静的データベースのテーブルコンポーネントに接続されます。一方、リアルタイムアプリケーションは、メッセージ処理キュー、Webサービス、RPC、CICSサーバー、またはTCP/ソケット経由通信を行うなどの特別な用途のコンポーネントに接続されます。

Ab Initioでは、バッチアプリケーションおよびリアルタイムアプリケーションが多くの点で共通で、両方ともCo>Operating Systemという同じテクノロジを使用しているため、結果として複雑さが大幅に軽減され、パフォーマンスが向上します。複雑さの軽減は生産性の向上につながり、パフォーマンスの向上はコストの低減につながります。

バッチアプリケーションおよびリアルタイムアプリケーション全体での業務ロジックの再利用可能性

バッチアプリケーションおよびリアルタイムアプリケーションは、ほとんどの場合、入力コンポーネントと出力コンポーネントの間で使われる業務ロジックコンポーネントは同じであり、同じ業務ロジックを“再利用”できます。これは生産性に大きな影響を与えます。Ab Initio以外のアプローチでは、バッチ処理およびリアルタイム処理のテクノロジと実装方法が大きく異なるので、バッチ処理からリアルタイム処理に変更する際には同じ業務ロジックを何度も実装し直す必要があります。Ab Initioを使用する場合は、一度だけ開発した業務ロジックを、バッチおよびリアルタイム処理に組み込むことができます。

さまざまなリアルタイム実行モデルのパフォーマンスの達成

アプリケーション設計者は、相反するように見えるパフォーマンス要件を満たすという課題によく遭遇します。

  • バッチアプリケーションでは可能な限り“効率的に”データを処理する必要があります。バッチジョブには処理対象のトランザクションが多数存在するためバッチジョブの実行には長時間かかる場合があり、ジョブが完了するまでその結果を使用できないことがあります。実行中は、バッチジョブでは1秒間にきわめて多くのレコードが”効率的に”処理されます。
  • “ミニバッチ”アプリケーションは、少量のデータを処理するバッチジョブの集合です。ただし、毎日実行するこのような小規模のジョブは何千、何万とある可能性があります。ジョブが処理するデータの量を制限することによって、各ジョブの応答時間は最小限に抑えられます。このアプローチを使用すれば、同じアプリケーションで非常に大量のデータを従来のバッチ設定で効率的に処理することもできます(1日に何万ものジョブを管理するには複雑性の問題が伴いますが、これは、Ab InitioのConduct>Itで対応できます)。
  • 非同期メッセージ処理アプリケーションは、メッセージキューに接続し、可能な限りトランザクションを効果的に処理する必要があります。ただし、下流システムは通常、数秒から数十秒以内にその応答メッセージを受信することを想定しています。実際に非同期アプリケーションで1、2秒以内の応答が可能であれば、対話での使用をサポートできます。
  • “要求/応答”または同期メッセージ処理アプリケーションは、トランザクションをすぐに処理し、通常、“遅延”は1秒未満と可能な限り速く応答します。このような複数のアプリケーションが連携してトランザクションを処理する場合、個々のアプリケーションは0.01~0.1秒ときわめて短い応答時間を実現する必要もあります。Ab Initioは、特に応答時間を短縮するために特殊な実装を用いたりせず通常の処理と同じ方法で業務ロジックを含む処理を数十ミリ秒内に実行します。

Ab Initio Co>Operating SystemのContinuous>Flows機能は、これらのリアルタイム実行モデルに共通して効率よく使用できるテクノロジです。これは、Co>Operating Systemが最初からこれらのさまざまなアプローチの要件をすべて満たすように設計されているためです。

Ab Initioには、バッチアプリケーション(ミニバッチを含む)とリアルタイムアプリケーションの間に、次に示す2つの主な相違点があります。

  • 終了: バッチアプリケーションは、すべての入力データの処理が完了するとすぐに終了します。終了後、バッチアプリケーションが利用していたシステムリソースは解放されます。

    一方、リアルタイムアプリケーションはいったん開始すると、トランザクションの受信と処理を継続します。新しいトランザクションの入力が一時的に途切れた場合、リアルタイムアプリケーションは新しいトランザクションを受信するまで待機します。

  • チェックポイントとリカバリ: バッチアプリケーションは、アプリケーション内の事前に定義された位置にチェックポイントを設定し、いずれかを通過したすべてのデータをディスクに保存します(そうでないと、チェックポイントは正常に機能していないことになります)。リカバリとは、すべてのデータが正常に通過した最後のチェックポイントからアプリケーションを再起動します。

    リアルタイムアプリケーションでは、他の条件(経過時間やトランザクション数など)に基づいてトランザクションごとか、あまり用いませんがいくつかのトランザクションの間にチェックポイントを設定できます。再起動されたアプリケーションは、正常にチェックポイントを通過した最後のトランザクションに戻って自動的に再開されます。

さまざまなリアルタイムシステムとのインターフェイス

Ab InitioのContinuous>Flowsには、次に示す広範なリアルタイムシステムとのインターフェイスがあります。

  • サードパーティのキューイングシステム: IBM MQ、JMS、TIBCO Rendezvous、およびMicrosoft MQ。Ab Initioには、これらのすべてのキューイングシステムに直接接続するためのコンポーネントが用意されています。
  • Webサービス: WebSphere、WebLogic、IIS、およびApache/Tomcat
  • Ab Initioアプリケーション間を短い遅延時間で効率良く2点間接続で接続するためのAb InitioキューイングおよびRPC
  • レガシーまたは社内のメッセージ処理ソフトウェア

WebサービスおよびSOAのネイティブサポート

Ab Initioアプリケーションを用いて、SOAでWebサービスを簡単に実装できます。これは、ユーザーが利用する標準的なのアプリケーションサーバー(WebSphere、WebLogic、IIS、またはApache/Tomcat)にAb Initio提供のサーブレットにインストールします。サーブレットには、Webサービス呼び出しと対応するAb Initioアプリケーションを関連付けるための登録メカニズムが用意されています。Webサービス呼び出しを受信すると、サーブレットはTCPを介してAb Initioアプリケーションと通信し(Ab Initioアプリケーションは、アプリケーションサーバーとは別に実行します)、Ab Initioアプリケーションから返された結果を要求元に返します。

Co>Operating Systemは、WSDLで定義されたメッセージの解析も全面的にサポートしています。

特殊用途および旧式のメッセージ処理システムとのインターフェイス

商用のキューイング製品およびWebサービスは比較的新しく、あまりパフォーマンスが高くありません。つまり大量のメッセージ処理が必要なユーザーは、独自の社内高容量メッセージ処理ソリューションを構築しています。

Continuous>Flowsでは、“UNIVERSAL SUBSCRIBE”および“UNIVERSAL PUBLISH”コンポーネントを使用して、それらの独自のソリューションと堅牢にインターフェイスできます。これらのコンポーネントは、独自のメッセージ処理システムとのインターフェイスを取るカスタムのC++サブルーチンを呼び出します。コンポーネントは、失敗した場合のロールバックおよびリカバリも処理します。

Ab Initioは、独自のメッセージ処理システムと連携して、基幹アプリケーションで1秒あたり50万件を超えるメッセージを継続的に処理する非常に高いパフォーマンスを実現しています。

さらに、UNIVERSAL SUBSCRIBEコンポーネントとUNIVERSAL PUBLISHコンポーネントは、他のContinuous>Flowsコンポーネントとまったく同じ方法で使用されているので、ユーザーはAb Initioアプリケーションにほとんど影響を与えずに、社内キューイングソリューションからサードパーティのキューイング製品に切り替えることができます。

失敗時の堅牢性

Co>Operating Systemのチェックポイント機能は、アプリケーションの失敗に対して復旧できるように働きます。チェックポイントを使用することで、アプリケーションは複数のデータベースおよび入出力システム(キュー)の変更をコミットできます。アプリケーションが失敗すると、Co>Operating Systemは正常に通過した最後のチェックポイントに環境を“ロールバック”します。データベースでのロードの拒否、ディスク領域の不足、ネットワーク障害など、潜在的な問題が解決すると、アプリケーションを再起動できます。そのとき、最後に正常に処理されたトランザクションの後のバックアップが自動的に収集されます。

ほとんどのチェックポイントの実現方法は計算や処理の負荷が高くなるため、それを最小限に抑えようとする開発者の努力によってアプリケーションは複雑で不安定になってしまうことがよくあります。Co>Operating Systemは、非常に高いパフォーマンスと堅牢性を“兼ね備える”ように設計されています。Co>Operating Systemには、リカバリ時間を優先させトランザクションが遅くなることとのバランスを取るように、チェックポイントの手段がいくつも用意されています。いずれの場合も、Co>Operating Systemではあらゆる出力先(データベース、ファイル、およびキュー)へすべてのトランザクションが1度だけ確実に書き込まれます。

Co>Operating Systemには、チェックポイントのための2つの基本メカニズムがあります。最も良く知られているのは、2フェーズコミット用のXA標準プロトコルです。Co>Operating Systemには、異なるデータベースおよびキューイング製品全体にわたってコミットを統合するトランザクションマネージャが含まれているので、バッチトランザクションを1つのコミットに統合してスループットを向上させることができます。

ただし、XAには、計算負荷が高い、管理が複雑である、必要なすべての入出力デバイスでサポートされているとは限らないといった制限があります。そのため、ほとんどのAb Initioユーザーは、2フェーズコミットによく似ているCo>Operating Systemのネイティブのチェックポイントメカニズムを利用しています。このメカニズムは、Ab Initioが接続するすべての入出力デバイス(データベース、ファイル、およびキュー)と連動し、異機種が混在する複数の分散サーバーにわたって機能し、そして非常に性能が高く堅牢です。たとえば、キューマネージャのクラッシュによりトランザクションが複数回出力される可能性がある製品など、Ab Initioは特定のサードパーティのキューイング製品の制約を補うためのコネクタコンポーネント方法にも組み込まれています。

Co>Operating Systemのネイティブチェックポイントシステムを使用すると、開発者はトランザクションの数や経過時間、またはメッセージストリームのある特定のトークンなどのイベントによって、チェックポイントの頻度を制御できます。さらに、複数の出力デバイスにわたるチェックポイント時間でのトランザクションの整合性の度合いも制御できます。デフォルト設定で高いパフォーマンスを実現し、トランザクションが失われることはなく、アプリケーションの正確性が犠牲になることもありません。

運用の堅牢性

Co>Operating Systemは、ミッションクリティカルなシステムのリアルタイムアプリケーションを実現しています。その中には、次のメカニズムも含まれています。

  • 負荷分散およびフェイルオーバーを実現するためにリアルタイムアプリケーションを同時に複数インスタンスとして実行する
  • 年中無休のシステムを停止させることなしに変更があるモジュールを更新するよう、アプリケーションシステムの一部を停止する
  • データベースへの接続をプールしてリソースの使用量を制限する
  • 複数のコンポーネントを1つのプロセスに“フォルディング”してCPUの負荷やメモリ消費量を減らす
  • 動的にグラフロジックをロードできる“マイクログラフ”を使用して、オペレーティングシステムのリソースの使用量を大幅に減らす

結論

Continuous>Flowsは、リアルタイムな処理に対して、グラフィカルデータフロー実装の生産性の向上、実行モデル、および確実なチェックポイント処理とトランザクションを連携させる堅牢なメカニズムをすべて実現します。

English
Français
Español
Deutsch
简体中文
言語:
日本語