ホーム > ブログ > 中山 嘉之の記事一覧 > 大規模&疎結合アーキのかなめ(その1)


大規模&疎結合アーキのかなめ(その1)

Pocket

今回からエンタープライズレベルでのデータ(統合)アーキテクチャをテーマに数回に渡って連載したい。理由は、近年EAにおけるデータアーキテクチャの悩みの1つに、いわゆるデータモデリング問題だけでなく、システムの規模拡大とともに物理DBの配置とデータ連携のデザインをどうしたものか?があるからだ。具体的には、これからの時代に備えて大規模かつ疎結合*を実現する”HUBアーキテクチヤ”を取り上げてみたい。連載の初回は、本アーキテクチヤの持つ本来的メリットと、その基本構造についてお話したい。

%e3%83%94%e3%82%a2to%e3%83%94%e3%82%a2まず図1を見ていただきたい。図の例はアプリA~アプリFまでの6つのシステム間で何らかのデータのやりとりが発生するものとする。インターフェース(以下I/Fと略)のルート数は、左側のHUBを介さない場合には組み合わせ合計15通り存在し得る。一方で右側のHUB経由の場合にはルート数はアプリの数分の6通りということになる。ピアtoピアはHUB経由の2.5倍のルート管理が理論上発生する。アプリの数が8個になれば28:8(3.5倍)、10個になれば45:10(4.5倍)とその比率も増えて行く。言わずもがなHUBを経由しないピアtoピアのままの連携はいわゆるスパゲッティ化の元凶となる。

そして、このHUB経由が成り立つためには、図2にあるようにHUB上のI/Fレコードはアプリ非依存で中立な標準形式であることが条件となる。そしてこの標準形式に歩み寄る為に、HUBの両側に変換機能が存在する。変換機能にはコード変換やフォーマット変換等があり、それらは他の類似したI/Fにおいても再利用可能である。システムのいたる所に同類の変換プロセスを作成し、いたずらにコード量を増やすことはエンタープライズ全体でのメンテナビリティの悪化をもたらす。

hub%e5%86%85%e3%83%87%e3%83%bc%e3%82%bf%e8%93%84%e7%a9%8d%e5%bd%a2%e6%85%8b

次にこのHUB内のI/Fレコードの種類であるが、レコードの汎化度合いがポイントとなる。通常はマスタレコードのケースはエンティティ(“取引先“と“品目”など)毎に個別となるが、トランザクションレコードは実績系においてはバックナンバー2014.3.25「トランザクションHUB」にあるようにかなりの汎化が可能である。SCMでの“受払“、会計での”仕訳“、人事での”異動“などがこれに該当する。また、トランザクションにおいても指図(メッセージ)系のレコードは汎化が難しく個別のものとなる。
さらにこのHUB内のI/Fの連携形態には大きく2種類存在する。1つは実DBを介した最も疎結合なI/Fであり、DBへの書き込みとDBからの読み出しを非同期にするデータベースHUBである。本ブログに度々登場するマスタHUBやトランザクションHUBがこれに該当する。もう1つはDBが実体を持たない”仮想DB”のケースであり実DBへの読み書きがない分だけ即時性が高い疎結合I/Fである。

以上がHUBアーキテクチャのメリットとその基本的メカニズムである。どうであろうか、物理的には目に見えないITアーキテクチャであるが、このように図表現してみるとHUBアーキテクチャのメリットがいかなるものか一目瞭然である。ITアーキテクチャはシンプルかつシンメトリーで美しいほうが良い。逆に図やモデルに現そうとしても条件分岐や例外が多い歪(いびつ)な形になってしまう場合はダメなアーキテクチャという事になる。次回は、このHUBアーキテクチャの進化形についてお話したい。

※疎結合とは・・・情報システムにおいて、二つのシステムが緩やかに結びついた状態。システムどうしが標準的なインターフェースに基づいて接続されているため,一方が他方を容易に取り替えられる状態をいう。⇔ (反)密結合

 

Pocket

| 目次

Profileプロフィール

中山 嘉之
中山 嘉之
1982年より協和発酵工業(現、協和発酵キリン)にて、社内システムの構築に携わる。メインフレーム~オープンへとITが変遷する中、DBモデラー兼PMを担い、2013年にエンタープライズ・データHubを中核とする疎結合アーキテクチャの完成に至る。2013年1月より(株)アイ・ティ・イノベーションにてコンサルタントを務める。

Recent Entries最近の記事

このページのトップへ