脱バッチ教

新興宗教の勧誘のお知らせです！（違

バッチ処理

メインフレーム等の大型コンピュータって、バッチ処理がたくさんありますよね。なんでバッチ処理なのか、みなさんはご存知でしょうか。

大型汎用コンピュータが出てきた当初、計算を行うためには予めプログラムを組んで使いたい時間を申請して、実行時間に応じた料金が掛かるものでした。今でいうクラウドで時間単位で課金されるのと同じ。私も小学生の頃、父親の会社にあった3270端末を叩いてみたことがあります。ええ、キーを叩くのは親父で、私は画面をぶっ叩いていましたが。（笑）

つまり、CPUの利用率に関わらず"利用時間"で料金が掛かるので、ダラダラと雑多な処理を長時間行うのではなく、データをまとめてドガッと行ってパッと終える必要があったわけです。更に言うと、昼間と夜間では料金が違ったと記憶しています。そうすると昼間は金融機関などの「リッチ」な会社が利用し、父親が居たような中小企業などの「節約」しなければならない会社は夜の時間に利用することになります。（父親の会社では港湾施設の基礎設計などをやっていて、潮力等の流体力学等のシミュレーションを行っていました。簡単なプログラムだと実行時間が0.5秒とか出てて、当時小学生だった私はその速さに興奮した覚えがあります！）

バッチ処理はそういう技術計算だけではなく、月次の料金計算、営業の売上集計、代理店手数料計算等にもよく使われています。大型汎用コンピュータでのこの「習慣」が、Intel Architecture(IA)の環境になっても同じように使われています。

バッチ処理の何が問題か

上で書いたとおり、バッチ処理は「いかに利用料金(コスト)を減らして処理させるか」に焦点が当たったものになっていました。自前でハードウェアを持たず、専用線の接続先で処理をしていた時代はそれで良かったのですが、ハードウェアのコストが安くなったことで、自前でサーバを立てた方が安くなりました。アセンブラやCOBOL/FortranからCやJavaに書き換えはしたものの、バッチプログラムを構造的にはそのまま持ってきて実行しても、IAサーバでは単体ではまかないきれません。そこでバッチ処理のピーク時に合わせた処理性能を確保するために、多くの高速なCPUを載せて、大型サーバを用意して実行しています。分散処理型ではないため、処理能力を増大させるにはスケールアップ（CPUを積み増すとか高速なCPUに載せ替える）方法になります。

ここに問題が２つあります。一つは夜間バッチ処理に合わせたリソースで、昼間がどうしても使用率が上がらない問題。もう一つはビジネスが好調で処理件数が増大してしまい、サーバの能力を超える処理が必要になり、夜間バッチが朝の始業時間までに終わらず、翌日の業務開始が遅れるという問題です。

バッチ処理の中身

ここでバッチ処理の中身をよく見てみましょう。私の経験を例にお伝えすると、営業成績を月次で夜間に集計をしするアプリケーションがありました（メインフレームで動いていました）。契約数の急な増加により夜間バッチ処理が終わらなくなっており、翌日の営業活動に支障が出かねないというご相談いただきました。中身の処理は、１ヶ月分の受注した伝票データを元に、商品毎・お客様毎・営業マン毎・営業部毎・事業部毎・地域毎・代理店毎等の単位で集計するという業務です。しかもかなり細かい条件（AさんはG店に居たのでG店の売上として扱うが、商品Y,ZはG店ではなくU事業部付、商品Xでかつ契約期間が1年以上のものは1年に丸めた上でK事業部に半分付ける等）があり、１ヶ月の伝票データは2,000万件程度にまで膨れ上がっていました。

皆さんならどうしますか？

解決策その１

バッチ処理と言っても全てを一気にメモリ上に読み込むことはまず不可能です。ではどうするかと言うと、1件読み込み、それを各集計単位に落として、終わったら次の1件を...　という繰り返しを行います。

でもこれを逐次的（シーケンシャル）に行っていても、処理は全く進みません。処理している内容をよく見ると、異なる複数の伝票間に関係性を持った処理（例えば3つの伝票があって、A伝票のKという項目の値が100でB伝票のJという項目の値が80の場合、C伝票のGという項目を0にする　というようなものを関係性と言っています）は無いのです。つまり1伝票毎に異なるサーバで処理を行ったとしても、なんら問題がないのです。

いろいろなお客様で聞くのが、「バッチ処理は複雑で触りたくない」というものですが、それは「バッチ処理の中身」に書いたとおり面倒くさい処理が山ほどあるだけで、データ間の関係性は無かったりします。としたら、処理の系の途中にQueueを置いて、その中にデータを入れて、Publish/Subscribeという機能を使い必要とするデータをアプリケーションが選択取得し、処理が終わったら処理済みのQueueに入れて次の処理をする　というような流れにして、「処理」を多重化・多段化することで全体の処理時間を短縮することが可能です。サーバも「スケールアップ」ではなく、「スケールアウト」として、同じようなサーバを追加するだけで性能向上が見込める形になります。

最終的にはルールエンジンを使って伝票の仕分けと集計を行い、伝票1件ずつ、10台のサーバを使って多重化しました。1伝票の内容を集計する単位別に複製し、集計単位が同じキー（営業店コードとか）を持つものが2つ以上あればすぐに集計オブジェクトに合算し、計算が終了した複製した伝票を消去する、というような流れです。

解決策その２

更に良く見ると、1ヶ月分の集計を行うのに1ヶ月待ってから月次処理する必要性が無いことに気づきます。「月次処理」として本当に必要なのは各集計単位を「足し込む」事のみで、途中の集計結果は毎日、いえ、リアルタイムに処理していても良いんじゃないのか？ということです。つまり、バッチ処理を極小化してなるべくリアルタイムに処理してしまえということです。そうすると、「夜間バッチ」に合わせたリソースは、実は必要なく、負荷を平準化させることでもっと少ないリソースでその処理が可能になるのです。これはハードウェア費用の節約だけではなく、夜間バッチの運用立ち会い人員の削減（Abendした時の回復要員とかね）も可能、さらにデータがリアルタイムにわかることによる経営的なトレンドの把握によるダイナミックな作業指示、それによる商機逸失の回避ができることを意味します。

つまり、システムの系としてQueueやインメモリデータベース、処理のマイクロサービス化などを行い、バッチ処理をリアルタイム処理に極力変えることで、コストの削減とリスクの低減と売上の増大を一気に達成することが可能なのです。

別のお客様では、工場の生産計画を、メインフレームでは夜間の10分の稼働で3ヶ月分を作成できたものを、IAの分散環境にしたことで3分の稼働で8ヶ月分が作成できるようになりました。処理の効率化により、今までできなかった処理もできるようになったのと、作成する計画がより長期で見れることによる経営的な判断のしやすさもベネフィットとしてありました。

さらにもう一歩。この「処理」や「Queue (Stream処理できるKafkaとかだとさらに良い）」に相当するところをmicroservicesと定義し、コンテナで動かすことによって「サービスとして止めない」仕組みが出来上がり、業務の変更に対して柔軟に変更が可能な「最強システム」が出来上がります！

この活動を、私は「脱バッチ教」と社内で宣告し、勝手に教祖を名乗っております。（誰にも承認を得ていないので、「野良教祖」ですが...笑）皆さんも入信してみませんか？

技術のお話

今日のお話の中で、レッドハットでご用意している技術・製品は下記のとおりです。

ルールエンジン：Red Hat Decision Manager

データ連携：Red Hat Integration (AMQ, Kafka, Data Virtualization)

In Memory DataBase：Red Hat Runtimes (DataGrid)

クラウド環境：Red Hat OpenShift Container Platform

IT環境の自動化：Red Hat Ansible