DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回のブログでは、大規模複雑化した企業システムが、少なくとも今後5～6年先を見据えたところで、現実的にどのようなアーキテクチャを指向すればよいのかについてお話してみたい。“現実的に“としたのは、ベンダーや開発者が提唱する新たなITをベースにした究極のモデルではないという意味である。例えば大容量高速なインメモリDBマシンで全リソースを集中処理可能にするとか、その真逆で小さく切り刻んだマイクロサービスで極度の分散処理を可能にする等がこれに該当する。

本シリーズでも度々取り上げているように、大規模な密結合システムと化した企業システムは、もはやこれ以上のスパゲティを盛り付けるわけにはゆかない。従って、疎結合化に舵を切らねばならない事は皆さん薄々と感じているが、往々にしてマスメディアは上記の極端なケースを取り上げるので、どうしてよいか決断がつかないというのが本音ではなかろうか。集中と分散の狭間で右往左往させられるのはいつもユーザ企業である。

さて本ブログでは上記のような背景にあって、ユーザ企業が当面目指すアーキテクチャはどのようなものが良いかについて、あくまで私見であるが語ってみたい。前提として、「上記のようなDBマシンをもってすれば疎結合化は不要である」という見解は除外したい。なぜなら、処理が高速化してもメンテナンス問題は解決しない事、ビジネスが多様性重視に向かっている事などがその理由である（DBマシン自体を否定するものではないが）。よって、話の論点は、どの程度、疎結合化するかという事になる。「図１.企業システムの疎結合化の例」を参照していただきたい。

エンタープライズシステムにおける疎結合化の障壁は何といってもデータの一貫性である。マイクロサービスに至ってはなおさらである。ここで“障壁”と書いたが企業システムがデータ中心である事は今迄も今後もその重要性に変わりはない。迅速な意思決定には最新化された正しい情報提供が必要である。ではなぜ障壁なのか？それは、物理的に一元化されたDBに排他制御を施した従来型集中トランザクション処理が出来なくなるからである。すなわち関連するデータの“リアルタイム“での一貫性を保証することが難しくなるのだ。そこでもう一度、”リアルタイム”での一貫性が本当に必要なのかを考えてみよう。

モノリシック*なERPパッケージによるリアルタイムなデータ一貫性は、その作り手にとっては理路整然としていてシンプルである。受注、出荷、売上計上、在庫・棚卸資産減少、売掛金計上といった一連の処理がリアルタイムに行われ実に気持ちが良いが、ビジネスにとっては必ずしも、リアルタイム性を必要としていないものもある。たとえ売上計上が出荷基準であっても同時に売掛金残高が更新されなくとも通常は問題ない。棚卸資産残高の減算も同様にリアルでなくとも問題ない。しかし、リアルタイムではなくともビジネスが要求するタイミングにおいては一貫性を維持する必要がある。

このように企業システムの疎結合化には、分散DB設計が重要となる。この分散DB間でのデータ一貫性を保持する為には、限りなくリアルタイムに近い準リアルタイムから、30分間隔、1時間間隔、2回／日、１回／日といったようにビジネスが要求するインターバルで遅延型同期させることになる。同期の実装方式はメッセージキュー、ファイル転送（データHUB経由）、DBレプリケーションなど様々存在する。なお、他システムへの2フェーズコミットはそもそも疎結合化に反するので除外される。

ところで、分散トランザクション処理は禁じ手であるが、1システム内でのトランザクション処理は可能である。図１における受注処理での受注DBの更新と在庫DBの引当や、出荷処理での出荷DBの更新と在庫DBの減算などはそれに該当する。言い換えれば、これらのリアルタイム性はビジネスが要求するものだからであり、これを分断することはできないという事だ。

最後に補足であるが、データベース設計のセオリーに「One fact in one place」というものがある。データ無法地帯から中央集権的データ統治が必要となったホストコンピュータ全盛期には、物理的な1インスタンス化を意味したかも知れないが、密結合システムの限界を迎えつつある今日、このセオリーは論理的なものと捉えた方が自然である。データ管理の一元化と、物理実装の集中化とは異なると。

※モノリシック：[monolithic]　一体となっている、一枚岩的な