バッチ処理は、パンチカードでプログラムを書いていた時代からの、電子計算機の最古の利用形態だ。汎用機では、昼間にオンライン処理で入力したデータを、夜間にオフラインバッチ処理する利用方法が長く取られて来た。リソースが空く時間にまとまった処理ができる合理性があるからだ。大企業では数千のバッチ処理が複雑に連携して動いている*1こともあるそうだ*2。
1. レガシー手法の代表
夜間バッチ処理は望ましくないソリューションと考えられるようになっている。処理結果が翌日まで見られないし、オンライン処理が停止する時間帯ができたりするので、エンドユーザーからすると使い勝手が悪い。また、夜間バッチが異常終了したり、大量のバッチの管理が煩雑になったりと、保守・運用の課題にもなっている。
前日の夜間バッチが終わっていることが前提に業務が構築されているので、何らかの事情で処理が間に合わないと惨事になる。2002年4月1日からの一ヶ月、みずほ銀行の職員の皆さんは生きた心地がしなかったはずだ。京都市の基幹システム更新が失敗したのは、バッチ処理のパフォーマンスが出なかったためだ。
2. 脱夜間バッチ処理
汎用機からオープン系に移行するにつれ、夜間バッチ処理への依存は徐々に減ってきている。夜間バッチ処理を減らす方法は、
- オンライン処理にする
- データ登録時やデータ参照時にデータ処理も行うのが簡単だ。リレーショナルデータベース（RDB）の基本的な使い方。何でもバッチにしたがる開発現場もあったそうだが、RDBによるオンライン処理で捌ける仕事は増えている。もちろん、応答までの時間制限が現実的にはあり、限度はある。
- オンラインバッチ処理
- エンドユーザーがオンライン処理を行っている最中に、バッチ処理を走らせる方法がある。1日1回のバッチ処理を4時間に1回にすれば、午前の入力データの処理結果を午後に見ることができる。ただし、夜間バッチと異なりトランザクション処理になり、パフォーマンスはかなり落ちる。また、空き時間帯のリソースの有効利用と言う利点も無くなる。
- メッセージキュー
- オンライン処理でデータ入力と同時にキューにメッセージを投げさせ、キューのメッセージを待っているプログラムが（既に動いていなければ）即座にバッチ処理を開始する（か、させる）方法*3。バッチ処理が忙しい場合は、キューにメッセージがたまる。オンライン処理は入力しか受け付けないので応答が早く、バッチ処理は順次実行されるので（ユーザー視点で）使い勝手もよい。ただし、空き時間帯のリソース有効利用と言う利点は無くなる。
と言うのがおそらく定番*4。ただし、夜間のオフラインバッチが無くなっても、バッチ処理自体が無くなると言う感じではない。
3. デジタル庁クラウドチームの推奨
前置きが長くなったが、デジタル庁クラウドチームの脱夜間バッチ処理の方法を考察してみたい。山本教仁CCOの「ガバメントクラウドでのクラウド最適なアーキテクチャのサンプル」に、
夜間バッチではなくイベントドリブン処理クラウドのマネージドサービスではRead Replica構成が簡単に組めるため、これを使えば申請を受けての後続処理を即時に行っても性能影響を与えない構成が組みやすくなりました。
後続処理はRead Replicaからデータを読み取るため、更新側のデータベースに性能影響は出ません。更新があるたびにその更新データに対して加工や集計などの処理を動かし次の処理を行うデータベースにデータを保管していくことで、性能影響を考慮して夜間にバッチアプリケーションとして処理をしなくてもよくなります。
夜間バッチアプリケーションが必要になるのは、締め処理や期間での統計等ある一時点の静止点データが必要な処理か、夜間に外部から渡ってくるデータを処理する外部要因のケースと考えられます。そうした処理も途中までの処理は都度処理で済ましておくことができます。それ以外のほとんどのケースは都度の後続処理で対応できると考えます。
夜間バッチアプリケーションについては、これがあると、システムの閉局が必要になったり、夜間の監視要員が必要になったり、バッチアプリケーションが失敗したときの朝の開局までのリカバリーが難しかったりして、システム運用の難度を上げる大きな要因でした。これを廃止、もしくは極小化し、更新イベントがあるたびに後続処理を行う、イベントドリブン処理とすることでシステム運用のシンプル化に大きく貢献します。
また、夜間バッチアプリケーションを廃止・極小化することで、複雑なジョブ連携をジョブフローとして管理するジョブ管理サーバも不要となります。
とあるのだが、どういう代替システムを念頭に置いた議論か、お分かりになるであろうか。
Read Replica構成は、オンライン処理に使われているデータベースのREDOログを使って、もう一つ（以上）のデータベースを同期させ、データベースにかかる負荷を二つ（以上）に分散すると言う話だ。
後続処理の話があるため、オンライン処理で全て片付ける話ではない。更新があるたびに即時に行う話のようだから、オンラインバッチ処理でもない。メッセージキューを使うとイベントドリブンになるので、メッセージキューが入っていることが分かる。実際に、クラウドでメッセージキューを使うソリューションの事例は多数ある*5。
ただし、メッセージキュー以外にも、イベントドリブンな後続処理になる大手クラウド事業者のサービスは他にもあり、メッセージキューに分類されるものに限らない。オブジェクトストレージにアップロードしたときに走るイベントなども含まれていると思われる。
4. 移行でもたらされうる複雑怪奇なイベント処理
イベントドリブンな後続処理を行うと、ジョブ管理システムで大量の夜間バッチを複雑に組み合わせて使う運用が不要になるとされている。それは恐らく真実ではあるが、「システム運用のシンプル化」になるかは怪しい。
最大手クラウドサービス（i.e. AWS）では、メッセージキュー（e.g. SQS, Step Functions）によって複数の後続処理（i.e. Lambda）を連結することができる。また、データベースのストアードプロシージャとして後続処理を呼べたりと、油断するとラムダ地獄に陥りそうな充実ぶりだ。そして、どうも皆さん、複雑に連結して使っている。
クラウドサービスのイベントドリブンな後続処理は、夜間バッチどころではない複雑さを持たすことが可能だし、デジタル庁は漸次的なアジャイル開発を推奨しているが、泥縄的に改修していくとそうなりがちだ。夜間バッチで複雑なパイプラインをくみ上げてしまったところが、シンプルに運用できる保証はないと言うか、やはり複雑に使う蓋然性が高い。
コンソール（i.e. Lambdaコンソール）が用意されていて一望できるようだが、夜間バッチだってジョブ管理システムで一望できる。
5. まとめ
デジタル庁クラウドチームの推奨アーキテクチャへの移行だけでは、複雑怪奇な夜間バッチは複雑怪奇なイベント処理にかわるのみだ。複雑さの問題を解決するのはレガシーコードのリファクタリングであって、イベントドリブンな後続処理の採用ではない。
夜間バッチの他の問題も、リファクタリングで解決することはある。夜間バッチの異常終了は、異常系の処理を足していけば減るはずだ*6。夜間バッチが終わらない問題も同様だ。オンラインバッチ処理になっていたのを、トランザクション無しのシーケンシャル処理にしたら改善した*7、複数の計算機による並列化を徹底したらスループットが向上した*8，両方やったら激速だった*9という事例紹介もある。
イベントドリブンな後続処理に置き換えれば、ユーザーの利便性が向上するなどの利益もあるし、クラウドサービスのサーバーレスなソリューションではスケールしてくれるので、スループットの不足も大きな問題にはならないと期待できる。しかし、システム運用が簡素になるかは怪しい。どこに何が仕掛けてあるか把握するのが困難な状態に陥りかねない。
*1ひとつひとつのプログラムの機能を抑えることでデバッグを容易にでき、OSのパイプ機能で接続することで複数プロセッサによる平行処理や、さらに遠隔手続き呼出し（RPC）と組み合わせて複数サーバーによる分散処理が可能になる。
*3プロプライエタリな製品はもちろん、オープンソースでもRabbitMQのようなミドルウェアがあり、そう困難なく実現できる。クラスタリングも可能（RabbitMQ徹底解説 #RabbitMQ - Qiita, 新人プログラマに知ってもらいたいRabbitMQ初心者の入門の入門 #Java - Qiita, RabbitMQ + php-amqplib でメッセージキューイング試してみた #PHP - Qiita）。
ミドルウェアを使って実現するのが一般的だが、最近のOSにはPOSIX message queuesと言うシステムコールが備わっている（POSIX メッセージキューについて調べてみた - simotin13's message）。また、MQを使わずとも、名前つきパイプを使えば、手っ取り早くシェルスクリプトを非同期で呼べる。sshなどのRPCと組み合わせれば、分散処理をベタに実現できる。保守困難な複雑怪奇なシロモノになるが。
*4脱オフラインバッチ手法をまとめた文献を見たことがない。
*5若手が知らない昔の技術MQ、クラウドではホットだ | 日経クロステック（xTECH）
*6そもそもイベントドリブンな後続処理にしたら解決する問題ではない。
*7損保料率機構がCOBOL集約推進 DBからCSVに移行しコスト削減 | 日経クロステック（xTECH）
処理にもよるが、例えばテーブルを単純に総なめするような場合は、SQLを使うのではなく（トランザクション処理にはならない）バルクロードして処理した方が速い。
0 コメント:
コメントを投稿