SOA/BPMの現場から - 日本のお客様事例 -

第3回 SOAの4つの事例から見るデータマネジメントの本当

目次

• はじめに
• SOAのアーキテクチャとデータにまつわるケーススタディ
  
  • SOAの中心的なアーキテクチャの一つであるESBの特徴
  • ケース1　ESBにおけるデータの結合の課題
  • ケース2　ESBによる大量データ連携
  • BPMS（Business Process Management System）の特徴
  • ケース3　BPMSと業務の進捗管理
  • ケース4　BPMSと業務データ
• まとめ

はじめに

SOAやクラウドなどの新しい技術では、従来からのRDBMSに代表されるデータ管理－ACID特性やバッチ的な考え方とは異なるアプローチが必要になっていると言われています。 参考文献(1)(2)(3)

本稿はSOAにおけるデータマネジメントをテーマとし、従来からのデータマネジメントとは何が違うのか、及びそれぞれの使い分けに焦点を当て、実際のケーススタディに基づいて解説します。

▲ ページTOPに戻る

SOAのアーキテクチャとデータにまつわるケーススタディ

本稿の読者の中には、これまでに書籍やWeb上の技術資料などでSOAアーキテクチャについての解説をご覧になった方が多いと思います。その中には、なんとすばらしい方式だろうかと感じられたものもあったのではないでしょうか。ここからはSOAの有力なアーキテクチャであるEnterprise Service Bus（以下ESB）とBPMSについて4つの事例をあげ、そこに潜む課題と解決へのアプローチを検討します。

SOAの中心的なアーキテクチャの一つであるESBの特徴

まず、実際の事例の前にESBの特徴についておさらいをしましょう。

図1 ESBの特徴

ESBは サービス間を仲介する役割を果たし、次のような特徴を持ちます。

• 各システムをまたがる連携はESBを介して行う
• ルーティング
• データ変換/フォーマット変換/プロトコル変換
• エンドポイントの抽象化

“エンドポイントの抽象化”についてはわかりにくいかもしれませんが、ここでは、サービスを実際に稼働している場所、サーバ名、ポート番号など、物理的な情報をサービスの利用者には意識させないという意味です。

ESBを介することで、 システム間を疎結合に保つことが可能となり、次のようなメリットを受けることができます。

• 個々のシステムから見ると、ESBが提供するI/Fのみを意識すればよい
• 変更時の影響範囲を限定
  下レイヤの実装が変わったとしてもUIアプリ側に影響はない
• 既存システムを流用しやすい
  既存システムの持つ独自なインタフェースを標準インタフェースに変換する

ESBは上記のようなバスを中心としたアーキテクチャです。オラクル製品では Oracle Service Busが該当します。

ケース1　ESBにおけるデータの結合の課題

この事例では、ESBが2つのシステムから情報を集約して公開するサービス（このようなサービスはデータサービスと呼ばれることが多い）を提供しています。

シナリオ

1. 各システムが共通で利用するデータを別データベース上に共通マスタとして作成し、共通マスタへの操作は全てESB経由で行うルールにした
2. サービスの利用者であるUIアプリケーションが、ユーザから情報取得のリクエストを受け取る
3. UIアプリケーションは取得する情報を指定して、ESBに対してサービスを呼び出す
4. 共通マスタが実体であるサービスから、ESBが該当する1,000件の情報を取得
5. 業務アプリケーションBが実体であるサービスから、ESBが該当する100件の情報を取得
6. ESB上で共通マスタと業務アプリケーションBから得られた情報をマッチングしてクライアントであるUIアプリケーションに返す

このとき、3.で大量のデータをESB上に取り込んでいること、及び5.でマッチング処理をESB上で行っていることから、全体のレスポンスタイムが落ちる結果となりました。

図2 サービスとデータ配置の不一致

それでは、このような課題に関してどのようなアプローチがあるでしょうか。原則はやはり、検索画面から指定される情報を同じデータベースに持つデータ配置設計になっていることが望ましいといえます。

• 解決策1
  RAC等によるデータベース統合を行うことで、共通マスタと業務データを同じデータベースに配置する。
  データベースを共有することで、データベースを介したシステム間の密結合が懸念されるが、スキーマを使って各システムが使用できるオブジェクトを論理的に分離する。
• 解決策2
  下記に図示している方式です。
  共通マスタから検索に 必要なデータを個別のシステムに配信する。
  
  図3 大量件数の場合、より下位レイヤでのマッチング処理が性能改善につながる
  
  本解決策はSOA Design Patterns 参考文献(4)の「Service Data Replication」パターンを実装して、業務アプリBの共通マスタへの依存度を下げたといえます。例えば、共通マスタが停止していたとしても、データの配信ができないためにデータの鮮度は落ちますが、業務アプリBはサービスを提供することができます。
  ただし、なんでもコピーしてしまうとシステム間の疎結合という目的を達成することはできませんので、どこがデータの主となるのか、双方向の更新はしない、などの標準化を決めるべきです。

疎結合とは何が疎結合なのでしょうか？
インタフェースが疎結合であることの他に、運用が疎結合であることがあります。例えば、システム間の運用時間がずれていてもサービスが提供できる、一部のシステムが停止しても最終的には処理が完了する状態は、お互いの運用が疎結合であるといえます。

解決策1、2のいずれの解決策もデータベース層で結合処理を解決しているため、パフォーマンスの問題は解決されました。ユニークキーで情報を取得できる場合、このような課題は発生しませんが、件数が絞り込めない条件でのデータサービスの提供は注意が必要です。

ケース2　ESBによる大量データ連携

2つめは、ESBに大きなサイズのデータを連携させたため、性能が悪化した事例です。

シナリオ

1. 関連するシステムの数が多く、現状のシステム間連携は複雑であるため、全てESBを介して連携を行う方式を採用した
2. 要件を詰めると、連携には次のパターンがあった
   
   • 大量のデータを夜間バッチで連携する
   • 少量のデータを発生都度にほぼリアルタイムに連携する

ESBは内部的にXML解析処理とデータのメモリ上への展開を行います。そのため、大量のデータが流れた場合に、レスポンスが著しく悪化する、またはメモリの不足によりOutOfMemoryが発生して処理が異常となるケースがあります。

図4 大量データによりレスポンスが悪化した

原則は「 ESBは大量データ連携のツールではなく、公開されたサービス、または既存システムをサービスとして利用する際のメッセージの仲介が役割である」と認識することです。大量データのバッチ連携については、ESBではなく別途ETLの仕組みを用意し、そちらを経由させることを検討してください。ESBではリアルタイム性が要求される連携や、1回あたりのデータ量が小さいメッセージの連携を行いましょう。

この方式のメリットとしては次の点があげられます。

• 大量データの連携について、ETLツールで直接DBやFileを読み書きさせることでスループットが向上する
• 大量データ連携の負荷により、少量データの連携処理が巻き添えになって性能劣化、動作不安定になってしまうことがない

図5 バッチ的な大量データについてはESBを介さないパスを検討

ETLとはソースからのデータ抽出（Extract）、データ変換（Transform）、ターゲットへのデータロード（Load）を行うソフトウェアです。オラクル製品としてはOracle Data Integratorが該当します。

BPMS（Business Process Management System）の特徴

次に、BPMSについて特徴をまとめます。

定義されたプロセス

• 業務フロー等を元に定義したプロセスに従って、途中でメッセージの受け取りや、システム連携を行いながら プロセスの進捗管理を行う
• 個別システムに実装された業務ロジックと、BPMS上に実装された業務プロセスを 分離している（関心の分離、疎結合）
• 定義された業務プロセスには人や外部システムからの待ち受け処理などを含むことがあるため、実行される インスタンスの存在期間は長く、インスタンスの状態が永続化される

プロセスのビジュアル的な定義

• BPMN、XPDLのようなプロセスモデリング用の記法と、BPELのようなプロセス記述用の言語が標準として広まりつつあります

図6 プロセスを個別のシステムから分離し、BPMS上で実行／管理するアーキテクチャ

オラクルのBPMS製品は、 Oracle BPEL Process Managerが該当します。実装を学ぶことはコンセプトを理解するのに有効ですので、インスタンスの存在期間が長くなることに対するOracle BPEL Process Managerの戦略を解説します。
Oracle BPEL Process Managerでは、メッセージの待ち受け処理、タイマーの待ちなど長時間スリープするようなタイミングで自動的に永続化ストア（実体はデータベース）に状態が保存され、一旦、JVMのメモリ上からは待避されます。これにより、次の3点のメリットを実現しています。

• 長期の待ち状態のインスタンスが増えた際にもメモリリソースの消費が最適化される
• 耐障害性が向上する。データベースに永続化されているため、障害から復旧後、永続化されている情報を利用してサービスが継続できる
• データベースに状態を持ち、BPMS部分はステートレスなアーキテクチャのため、BPMSが水平方向にスケールする

ケース3　BPMSと業務の進捗管理

BPMSでプロセスを管理するほとんどのプロジェクトで、プロセスの進捗状況、滞留状況の可視化が要件としてあがります。この事例は、プロセスの状態をどのように取得するのかがテーマです。

シナリオ

1. プロセスの管理者が、プロセスがどこまで進んでいるか見たい、またプロセスのどの部分で滞留が発生しているのか分析を行いたいという要件がある
2. プロセス管理者が使用するアプリケーションは、インスタンスの状態が永続化されているBPMSの永続化ストアから状態を取得する構成とした
3. BPMSパッケージに付属するAPIを利用して取得した状態名は、「与信処理」の様な業務ユーザから分かりやすい名前だけではなく、「注文データセット」といったシステム的なものも存在する

この時の課題として、大きくは次の2点が上げられます。

• インスタンスの状態を保存している永続化ストアに格納される情報は、必ずしもユーザが認識可能な業務的に意味ある単位とは限らない
• プロセスと画面アプリケーションが密結合してしまう
  プロセスにシステム的な処理を追加・変更した場合、取得される状態が修正前と異なる可能性がある

図7 永続化ストアを参照している例

解決策

• 業務ステータスを管理するための、テーブルを作成する
• プロセスが業務的に意味のある単位で完了したタイミングでステータスを更新する
  ここでは、このテーブルを案件管理表と呼びます
• 業務ステータス表には、個別のシステムからではなく、プロセスからのみ操作を行う

この方式のメリットとしては次の点があげられます

• プロセスに変更を加えたとしても、論理的に定義している業務のステータスの意味が変わらなければ、参照側のUIアプリに影響がない
• 表の状態を使用して再実行、キャンセルなどの頻度の非常に低い操作を実装することで、プロセスがシンプルになる

図8 進捗状況、滞留状況を行うためのテーブルを用意する

ケース4　BPMSと業務データ

最後の事例は、BPMS上のプロセスに個別業務のデータを全て受け渡しする必要があるかがテーマです。

シナリオ

1. プロセスのインタフェースとして各システムのデータ明細も含めて定義している
2. BPMSは注文受付（明細データ含む）のリクエストを受け取りプロセスが起動する
3. プロセスは受け取った情報を元に明細の件数分ループを行いながら受注テーブルに登録を行うため、処理時間がかかる
4. 後日、注文受注リクエストに新たに単価項目が増えたため、プロセスの改修と再デプロイを行う必要があった

ここでの課題は、明細データを処理するためのループ構造によってプロセスが複雑になっていること、明細データの項目変更によってプロセスの変更が必要になるといった、プロセスと業務ロジックが分離されていないことの2点です。

図9 BPMS全てのデータ連携を行う例

ここでもBPMSの本来の役割を考えてみましょう。BPMSはデータを運ぶことではなく、 プロセスの進捗を管理することが主な責務です。下記の解決策では、プロセスは受注テーブルに注文情報を書き込むことではなく、注文が来たというイベントと受注のプロセスを管理しています。

解決策

一般的に「Claim Check」と呼ばれている連携パターンを使用します。

• プロセスに進捗管理に必要なキー項目を個別のシステムと連携する
• キーになる項目以外はESB等の別の手段で連携を行う

※必ずしもキー項目だけしか連携してはならない訳ではない。例えばプロセスの分岐条件に使用される可能性のあるものはメッセージに含むべきである

この方式の注意が必要な点は、連携のパスがプロセス経由の連携と、プロセスを介さない連携と分かれることで、 一時的にデータの一貫性が取れない状態になることです。ただし、BPMSが対象とする長期間にわたって非同期で実行する処理では、一時的に一貫性が取れていない状態が問題とならないケースが多くあります。下図の例では、注文リクエストを受け取ってから注文テーブルを受付済にすることで、営業支援システムから受注テーブルを参照する際には整合性がとれた状態になっています。

図10 データの連携は別で行い、BPMSはプロセス管理に集中した

▲ ページTOPに戻る

まとめ

SOAやBPMの考え方では、サービスの疎結合により、再利用性の向上、改修コスト・期間を押さえるといったメリットが得られます。
一方で、SOAやBPMのような新しい考え方、手法は銀の弾丸、魔法の杖のように思えますが、それだけでは解決できない問題や、本来の目的とは異なる使い方によって期待していた効果が得られないケースもあり得ます。SOAの考え方や、それを実装した製品のアーキテクチャを見極めて、既存のシステム連携の手法も組み合わせた方式設計が必要です。

最後に、これまで解説した連携方式の検討要素となる項目をあげます。

• データサイズ
• リアルタイム性
• プロトコル
• インタフェースの公開レベル（サブシステム内、社内、社外）
• トランザクション量
• 性能要件

図11 連携の特性に応じた使い分け

▲ ページTOPに戻る

"SOA/BPMの現場から - 日本のお客様事例 -" インデックスに戻る

十川　亮平(そごう りょうへい)
日本オラクルにて、SOA関連のコンサルタントとして
日々、お客様のプロジェクトに参画。