金融業・システム統合プロジェクト
銀行の統合に 絡んで、システムを統合するプロジェクトに参入しました。
本番まで余り時間がない状態で、 積み残しになっている案件を担当することになりました。案件の内容は、統合後にデータ量の 増大が見込まれるので、バッチ処理が所定の時間で処理しきれるかどうかを検証する、 というものでした。
業務内容を把握してから、個々のジョブについて検証していくという 時間がない為、現行の最長処理時間を要した特異日を基準にして、統合後にはそのデータ量が ｎ倍になるということを根拠に、統合後のバッチ処理時間を算定する方法をとりました。
事務処理のバッチ特性からみて、ＣＰＵ時間より入出力時間がその処理時間の大半を占める ことは明らかです。従ってデータ量やデータ保存の面から磁気テープを多く使用していた点を、 仮想ＭＴに媒体変更した場合にどれだけ時間短縮が図れるのかを検証していくことになりました。
仮想ＭＴとは、ＭＴとＤＡＳＤの性質を併せ持つもので、入出力時間はＤＡＳＤ並みで予め媒体を 設置しておくものであるので、オペレータの介在する余地がなく、ハンドリング時間や マウント待ち時間を無視できる利点があり、１本当りの容量もＭＴの１０倍と大きなものです。 反面、ＭＴと同様にその装置に対しての共用検索はできません。
データ量の多いものから 順にＭＴを仮想ＭＴに媒体変更してテストしてみることになりました。仮想ＭＴに変更した ファイルの中にＤＡＳＤを媒体としたファイルとデータセット結合で使用している ジョブステップがあり、エラーを起こしました。単純機械的に媒体変更した為の間違いが発覚した わけです。
また、バッチ処理は処理機能単位にジョブを構成し、ジョブ間では処理の 順序を意識して実行するものと、並行して実行できるものとがあります。ジョブ間の先行・ 後続関係をとってジョブを結びつけるとジョブネットができます。ジョブ毎に算定した処理時間を このジョブネットに積み上げていくと、何時にスタートすれば何時に終了することができる、 という目安が立ちます。
対象システムでは、ジョブの数で７００以上、ネット数で２００以上 あり、処理時間の目標は８時間でした。
次に着目した点は、このジョブネットの中で どのルートがクリティカルになっていて、それをより短縮する方法があるのかを検討する ことでした。
バックアップセンターへ搬送・保管するファイルはどうしても媒体を ＭＴのままで残さざるを得ない訳ですが、このような搬送ＭＴを作成しているジョブが ルートの中に含まれていることで、そのルートがクリティカルになってしまいます。データ量から 見て、一つのファイルに何本ものＭＴが必要であり、それだけでオペレータの介在がでてきて、 処理時間が数倍になってしまいます。
そこで、搬送対象になるファイルを直接ＭＴへ出力するのではなく、 ＤＡＳＤ上のファイルとして特定のボリュームへ一旦出力するところまでをルート内で処理し、 バッチ処理全体の終了時間までに特定ボリュームからボリュームバックアップの形式で 搬送用ＭＴを作成する方法に切り替えました。ボリュームバックアップは、１ボリューム当り データ・フルの状態で暗号化しても正副２本を３５分位でとることができます。これは１０ＧＢの 容量のファイルを直接ＭＴ出力する場合と同等の時間であり、正副２本作成することを考えると 半分の処理時間で済む訳です。
いよいよ本番を迎えて、検証してきたことが妥当で あったかどうかが実証されることになりました。
本番へ移行された時点では不要なデータが 削除されたクリーンな状態ですから、想定したデータ量には及びませんでしたが、２ヶ月たち、 ３ヶ月たちして、データも段々と蓄積の度合いを増してきました。しかし、想定したデータの 成長率からみれば、それを下回る状況で推移しており、処理時間も現在のところは５時間半 程度で収まっている状態である、というところで私の役割を終えることになりました。