そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

SOAとデータベース(2)

はじめに謝っておきますが、わたくし、データベース統合をメインでやったことはありません。
ですので、システムが連携をしながらある一連の業務が実行されるというような場合にシステム連携側からの視点でデータの持ち方を考えています。エントリの最後の方にでてくるコストも主観ですので、ご容赦くださいね。


まず、前回のエントリで、複数のシステムを横断するような連携が必要な場合に、データをどの様に持つかという案を3つ+アルファあげてました。

1.データベース統合
2.各システムの共通データ項目を抜き出し、共通データベースに統合
3.各システムが個別にデータベースを持ったまま
 3−1.共通データ項目をマスタから各システムに配信
 3−2.ESBの様な層でデータを仮想的に統合



これらがどんなものかちょっと考えてみます。

1.データベース統合
そもそもシステムごとに持つデータを統合します。似たようなデータは再設計を行い、ひとつにまとめます。データベース統合というのは、それだけで一つの大きな関心事であり、プロジェクトになり得ます。
ただ、システムが統合されたデータベースを介して密結合になっていると見ることもできると思います。例えば、統合データベースへの変更はそれを利用する多くのシステムに影響を与えます。


2.各システムの共通項目を共通データベースに統合。
個別システムがもつ固有のデータはそれぞれのシステムのローカルに持つ
これは、システムが提供しているサービスが機能+データからなると考えると、そのサービスに関して凝集度が高いと言え、システムの固有のデータモデルへの変更は他のシステムには比較的影響が少ないはずです。
しかし、その様な状態になるには、データ、機能を重複してもっているようなシステムを少なくしていく活動が必要だと思います。


ここまでの2つのパターンは統合されたデータベースが停止すると全システムに影響がでますので、可用性が求められるでしょう。



3.各システムが個別にデータベースを持つ。
この方式は、共通データベースを作ったとしても、必ずしも業務中動いていなくても良いというメリットがあります。

3−1.共通のデータは、レプリカとして個別システムにもち、なんらかのタイミングでマスタより個別システムへ同期
オンライン中はシステムのローカルに持つデータベースにアクセスするので、最もパフォーマンスが良いと考えられます。共通データベースが停止していても、運用できます。
また、ローカルのデータベースを持つので、トランザクションの管理も行いやすいでしょう。ただし、レプリカなので、参照系だけにしておきたいところです。更新がある場合は各システムごとに行われた変更のマージが大変になります。

3−2.完全にデータはシステムごとに持つ。ESB的なレイヤでデータ配信。
こちらは、データ、機能を重複して持つようなシステムがある場合の対応として有効だと思います。重複した機能を提供するシステムAとBがあった場合、操作としては1つを外部には見せ、ESBのレイヤで、システムAとBに処理を依頼すれば良いのです。
ただし、新規作成、連携の変更はESBを介さずに連携していたころと比べると幾分ましですが、他のパターンと比較するとコストがかかりそうです。



最後に上記のパターンが前のエントリにあげた3つのコスト増をクリアしているかどうかも振り返ってみます。

パターン 初期開発コスト 運用コスト 改修コスト
データベース統合 大(政治力90くらいないと、きっと大変) 小(統合DBのデータモデルに影響が発生するような改修はコスト大大)
部分的共通データベース 中(共通データモデルの変更はコスト大)
レプリカデータベース 大(同期しないと)
データベース仮想統合 大(ESBの運用)

個人的な所感としては、機能に応じて凝集度の高いサービスを機能とデータのセットで用意するのが最もバランスが良いように思えますが、それまでの過渡期にESBによる仮想的なデータ統合は有効そうです。

また、参照のみのマスタのような情報であれば、共通分をレプリカでサービスごとに持つという構成もなかなか良さそうです。



補足ですが、ここでのデータベース統合とは論理的な統合であって、物理的な統合はまた別かもしれません。