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

menuclear
ホーム > ブログ > 中山 嘉之の記事一覧 > オンバッチの薦め(リアルタイム性の誤解)


オンバッチの薦め(リアルタイム性の誤解)


今回のブログは再び疎結合アーキテクチャに着目してみたい。今後の企業システムにとって“疎結合化“が重要なキーワードである事は、本ブログシリーズで度々提言してきた(バックナンバー2015.3.20「疎結合アーキテクチャへの転換」を参照)。しかし、システム間を疎結合にする事は、開発保守の生産性向上をもたらす一方で、データの一貫性をどう保てば良いかという課題が新たに発生する。最近注目の”マイクロサービス”を企業システムに適用する際にもこの事が最大の障壁となる。本ブログではこの疎結合システム間のデータ一貫性の課題解決の1つをご紹介したい。

かつて企業の基幹系システムはその拡大期において、ビジネスのスピードアップとともに、執拗に”リアルタイム性”にこだわり続けてきた。DBMSと対になったTPモニターの登場によってACID特性*を堅持するべく、リモートデータベースアクセス、2フェーズコミットといった高度なテクノロジーの実用にまで至った。このような技術進化の下、度重なる無秩序な増改築、ベンダー丸投げによる個別最適化があいまって、図らずも大盛りスパゲッティの完成に至っている。

さて、目線をエンドユーザに移してみよう。この“リアルタイム性“に関して、ユーザは本当にシステムのリアル化を望んだのだろうか?答えは否である。ユーザは、ある局面において一刻も早く情報を得たいとは思っても、”使いもしない時にシステムがリアルタイムにデータ連携されていて欲しい“とまで言っていない。裏側のシステムがどうなっていようがユーザには興味がない。”リアルタイムデータ連携”とはシステム屋が作ったものである。では、「ある局面において一刻も早く情報を得たい」を実現するには、毎秒毎に自動的に情報を用意する以外に方法はないのだろうか。

1980年代初頭、メインフレーム時代のシステム屋は、OLTPモニターの出現とともに受発注・在庫管理をリアルタイム処理で実現することに奔走したが、リアル性を必要としないトランザクションの大量一括処理は効率よく“夜間バッチ“で実現した。やがて運用を進めて行くと、複数件一括処理ではあるが夜まで待てない(或いはある時は一刻も早く)処理がある事に気付かされた。そしてこのニーズを実現する為に登場したものが、日中にユーザ画面から起動されるオンラインバッチ(通称:オンバッチ、又はオンデマンドバッチ)である。

%e3%82%aa%e3%83%b3%e3%83%87%e3%83%90%e3%83%83%e3%83%81%e3%81%ae%e8%96%a6%e3%82%81

図1にバックナンバー2015.4.6「疎結合アーキテクチャの具体例(基幹系システム)」でも紹介した受発注・債権債務管理システムの疎結合化の例(右)を密結合モデル(左)とともに記載したのでご覧いただきたい。ここでのポイントは2か所で分散同期する受発注明細テーブルを基に、受発注システムと、債権債務管理システムを疎結合化している事である。そして、この2つ分散同期の仕方として、ユーザニーズを程よく満たすには上記のオンバッチが相応しいと言える。そもそも債権債務管理における“請求・支払処理”は、複数の受発注明細をあるタイミングで束ねたものが対象である。よって締日にバッチ処理するのだが、1度きりの締処理で漏れがあった場合に再度、追加の同期処理を走らせたいとか、そうならない為に仮締めをした後に本締めをしたいといった要請があったりする。このユーザ要請に柔軟に対応する為には、昔からあったオンバッチ処理が極めて有効である。そして、毎時、毎分、毎秒、何もユーザ要請がないのに同期処理を実行することのオーバーヘッドは少なくともITコスト増を生む。この事は例えて言うなら、戸建ての自宅のあらゆる扉を自動扉にしたようなものであり、開閉の手間も一切かけたくないという豪華な造りという事になる。

現代のオープン環境では、同期のバッチ処理(DBレプリケーション、差分ファイル転送&更新)は、OS上で稼働するJOB管理ツールで実行するのが一般的である。日立:JP-1、富士通:SYSTEM-WALKER、IBM:TIVOLIなどがこれに相当し、複数STEPからなるJOBのスケジューリングから稼働監視までを行なうことができる。そしてJOBの起動タイミングは時間指定、先行JOBからの自動起動のほかに、JAVA画面プログラムからのコマンド実行も可能である。

私の記憶では、このオンバッチJOBは今から34年前の1982年には自社のメインフレーム上で当たり前のように稼働していた。当時メインフレームのセンターコンソールに張り付いてテストJOBの行方を追っていた私の脳裏には、JOB監視画面に日中、アットランダムに出現しては消えてゆくオンバッチJOBの姿が今でも残っている。プラットフォームは変われどもユーザとシステムの基本的関係は変わらない。まさに、温故知新なのである。

※ACID特性・・・トランザクション処理において必要とされる4つの要素、Atomicity(原子性)、Consistency(一貫性)、Isolation(独立性)、Durability(永続性)を頭字語で表したもの。

 


| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

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

Recent Entries最近の記事