検索
連載

鉄板焼きのお店から学ぶ、バッチ処理“超”入門Javaバッチ処理は本当に業務で“使える”の?(1)(1/2 ページ)

PC用表示 関連情報
Share
Tweet
LINE
Hatena

バッチ処理を知っている人も知らない人でも

 多くの業務システムでは、ユーザーと直接対話処理を行う「オンライン処理」とは別に、バッチ処理が裏方としてシステムを支えています。しかし、裏方としての活躍であるせいか、Webアプリケーションなどのオンライン処理と比較して、表立って取り上げられることが少なく、公開されているノウハウも少ないのが現状です。


 本連載では4回にわたって、バッチ処理についてその特徴をまとめ、最近話題になっているJava言語で開発するバッチアプリケーションについて解説します。連載の中では、Javaバッチアプリケーションを実際に体験するために、オープンソースのJavaバッチアプリケーションフレームワークの1つである「TERASOLUNA Batch Framework for Java」を取り上げます。

編集部注:「Batch Framework for Java」を含むTERASOLUNAフレームワーク全体について詳しく知りたい読者は、特集「Java、.NET、Ajax開発の“銀の弾丸”オープンソース?」をご覧ください。

 Webシステムに関してはある程度の知識・技術を持っているが、バッチ処理(バッチアプリケーション)についての知識をほとんど持ち得ていない方、また「そもそもバッチとは何か?」から知りたいと考えている方はぜひ試しに読んでみてください。Javaバッチアプリケーションを実際に作成することで、バッチアプリケーションを開発する際にどんなことに注意が必要なのかオンライン処理の開発と比較してどこが違うのかを確認しましょう。

どんなものが「バッチ処理」を意味するのか?

 突然ですが、「バッチ処理」の開発経験はありますか?「バッチ処理」という言葉は知っているけれど、開発経験はないという方が多いのではないでしょうか?

 バッチ処理の開発経験がない人にとっての最初の壁は、「バッチ処理とは何か」を理解することだと思います。まずは、バッチ処理の概念から理解していきましょう。

鉄板焼のお店から学ぶ、「バッチ処理」

 筆者の個人的なことで恐縮ですが、この前友人3人と鉄板焼きのお店に行ってきました。

 友人らと鉄板焼きに舌鼓を打っていたわけですが、ふと「あー、バッチ処理ってこういうところにも隠れているのか」と気付くシーンがありましたので、それを例にバッチ処理とは何かを説明します。

忙しそうなカウンター

 その鉄板焼きのお店では、カウンター注文・テーブル注文の2通りがありました。

 カウンターでは、シェフがお客さんの注文を聞きながら料理をします。時にはシェフが忙しくてお客さんを待たせたり、手を止めてお客さんの相手をしたりしていました。一方、テーブルでは店員さんが注文を聞いて、伝票にまとめてから別のシェフに渡していました。

 カウンターとテーブルには、それぞれ同じくらいの人数のグループが座っていました。カウンターとテーブルでは、注文していたのは同じくらいのタイミングだったのですが、料理が出そろったのはテーブルの方が速いことに気付きました。どうして差が出たのでしょうか?

図1 カウンター注文とテーブル注文
図1 カウンター注文とテーブル注文

 図1にあるとおり、カウンター注文ではお客さんの注文のたびに料理を作ります。10個の料理を出す場合、10回個別のタイミングで注文を受けて作ることになります。これでは、シェフは作りながらお客さんの注文も聞くので大変ですね。また、同じ料理でも別々に作らなくてはいけないので、手間が掛かってしまいます。

 それに引き換え、テーブル注文では店員さんがまとめて10個の注文を取り、その伝票を見ながらシェフが一気に料理を作ります。また、機械的に「注文を取る」→「まとめて料理を作る」を繰り返していきます。この方がシェフの負担も減りますし、カウンター注文の場合と違って同じ料理をまとめて作れるので効率的です。結果、カウンター注文よりもテーブル注文の方がより早く料理が出てきたわけです。

 この「テーブル注文」という処理方法こそが「バッチ処理」なのです。

大量注文でもお任せ!

 テーブル注文のように、「すべての料理が速く出そろう」のがバッチ処理です。単位時間当たりに処理できる量を多くすることを優先(“スループット”を優先)します。一方、カウンター注文のように、「1つの料理を速く出す」のがオンライン処理です。処理の依頼を受けたら、早く結果を返すこと(応答性)が求められます。

 もっとも、オンライン処理ではスループットが考慮されない、ということではありません。バッチ処理では、オンライン処理のような応答性が求められないので、よりスループットを優先できるということです。そして、大量のデータを処理しなくてはいけない場合に、応答性を犠牲にしてスループットを優先するバッチ処理が活躍するのです。

 バッチ処理的であるテーブル注文は、2つの特徴があります。

  1. まとめて処理する
    注文をまとめて取ったり、料理をまとめて作ったりする
  2. 処理に一定の順序がある
    「注文を取る」「料理を作る」「料理をテーブルに運ぶ」など、処理に一定の順序がある

 用語辞典などでバッチ処理について説明する際には、この2つの特徴がしばしば登場します(参考:@IT情報マネジメント用語事典バッチ処理」)。

実際のシステムのバッチ処理はどんなもの?

 では、概念を簡単に説明したところで、もう少し踏み込んで「実際のシステムにおけるバッチ処理」を見ていきましょう。銀行の口座振り込み処理を簡略化した例で考えてみます。

図2 バッチ処理を利用したシステム構成例
図2 バッチ処理を利用したシステム構成例

 図2の例では振り込み処理をオンライン+バッチで処理していますが、オンラインですべて処理するとしたらどうでしょうか?

 オンラインですべて処理する場合には、全国の大量の振り込みデータを処理するというのに応答性まで考慮しなくてはいけないので、かなり性能の高いハードウェアを用意しておく必要がありそうです。振り込み込依頼を受け付けたらすぐに振り込み先口座に反映されますが、大量に振り込み依頼が来てしまうと処理し切れなくなる恐れがあります。

 そこで、オンライン処理では振り込みデータの登録だけをしておき、一定時間分(例えば15時まで受け付けた分)の振り込みデータをまとめてバッチで処理することで、大量の振り込み依頼をすべて処理できるようになります。ほかの銀行のシステムとのやりとりも、1件ごとではなくまとまった件数分のデータでやりとりできるので、通信のオーバヘッドも小さくなり効率的です。

 このような例のほかにも、規模を問わずさまざまなシステムで処理の効率化のためにバッチ処理が利用されています。

 さらに次ページでは、なぜ実際の業務でバッチ処理が必要なのか、Javaによるバッチ処理の現状はどうなっているのかについて解説します。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ
ページトップに戻る