バッチ処理のデータ量が増大！“突き抜け”が心配！より早くしたい！解決策、『並列分散処理』とは？

毎月、取引情報などのデータを夜間バッチにより処理していたA社。決められた日時までに終了していれば問題がないものであったが、近年、部門間に分散されていたIT機器などの集約、組織の改変などの影響で、バッチ処理量が増大。

「このままでは、1年以内にはバッチ処理量の限界が訪れる。もし、何かの理由で処理量が増え、夜間バッチが業務開始時間までに終わらなければ、オンライン業務が停止するなど大問題になる！」
危機感を抱いたA社のシステム担当者ムライ氏は、早速解決策を検討しはじめた。

「処理対策の投資は認められているものの、高額のサーバ導入は…。」はじめはそう考えていたムライ氏だが、処理能力を向上させるには、もう1つの方法があることを知った。

「なるほど、グリッドバッチ…つまり、『バッチ処理を分散・並列実行できる技術』があるのか。これなら、比較的安価なサーバ複数台でバッチ処理を並列実行させられるから、コストも抑えられる！
業務量が増加したら、それに合わせてサーバも増やせばいい。これでIT投資の効率化ができる…社内稟議も通りやすそうだ。」
コスト面での課題解決の糸口をつかんだムライ氏。

「だが、基幹システムのバッチ処理に失敗は許されない。機能や運用のしやすさはどうだろうか。社内稟議の前にしっかり調べておこう。」
ムライ氏が調査したグリッドバッチ適用のメリットは下表の通り。

グローバル展開をしているB社。更なる競争力向上を検討しているB社の経営層では、売上などの情報をできるだけ早く入手し、分析して次の手を打ちたいと考えていた。そこで、情報システム部門に下ったのが「これまで日次で出していたデータを1時間ごとに出すように」という指令。
B社の情報システム部門ワタナベ氏は、社長の指令が求める要求の高さに頭を抱えた。
「1時間ごとにデータを出せだって？高速化だけでもタイヘンなのに、万が一、障害が発生したらどうするんだ？」
対策を考え始めるワタナベ氏だった。

バッチ処理の高速化について情報収集していたワタナベ氏が目を付けたのが、「グリッドバッチ」。
「サーバの並列化でバッチを分散すれば、処理を高速化できる。これなら日次データ処理もできそうだ！それに、日立の実証実験では最大81倍の高速化に成功したという結果も心強い。（※詳細は次章）」

また、基幹システムではよりシビアに信頼性を要求されるが、複数のサーバで並列処理を行うため、障害時の影響を局所化し、再実行時間を短縮できる。

更に、日立では大量データ分散処理に関するコンサルティングやクラウドを用いた実証実験の支援により、適切なシステム形態の立案を支援してくれる“大量データ分散処理アセスメントサービス”もある。
「専門技術者の支援を受けながら、効率よく検証を実施できる点が心強い！」と感じたワタナベ氏だった。

「近い将来、我が社も社内システムをプライベートクラウドにしたい。その場合、グリッドバッチならば、更にITリソースを効率化できそうだ。昼間はオンライン用、夜はバッチ用ということもできる…。ワールドワイドにビジネスを広げる際に、柔軟なシステム構成ということは重要課題。その第一歩を踏み出せそうだ。」
効率的な解決策を見出したワタナベ氏。B社のバッチ処理の高速化も成功し、更なるビジネスの躍進に貢献したという…。

今回は、2社の課題を例にとり、「グリッドバッチ」によるバッチ処理の高速化についてご紹介しました。

B社の例を補足すると、日立では、このグリッドバッチの導入から運用までを幅広く支援。また、日立が行った「最大81倍に高速化」した実証実験について、下図を参照して下さい。

このように企業のバッチ処理の課題を解決する「グリッドバッチ」について、詳しく情報を知りたい方には、下記の関連リンクを是非、ご一読下さい。