大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント：徹底解説！ ITアーキテクトとは何か？（3）（2/2 ページ）
ITアーキテクトの役割を、具体的かつ分かりやすく解説する本連載。今回は締め処理やデータ変換などで利用される、バッチ処理におけるアーキテクチャ設計のポイントを紹介する。
ポイント2：排他制御
ポイント1の中でも、データの更新処理を設計する際に、他からの更新の可能性を検討する必要があることに触れてきました。ここでは、それに関連したテーマである排他制御に関して話を進めていきます。
バッチ処理に排他制御は必要でしょうか？ こう言ってしまうと「何を言っているんだ？ 当たり前じゃないか？」と言われる気がしますが、排他制御の目的は、データ（レコード）に対する同時更新によりデータが不整合な状態になることを防ぐことにあります。
もしバッチ処理対象のデータがオンライン処理や他のバッチ処理から更新される可能性がない場合、排他制御は必要でしょうか？ アーキテクチャを考えるときには、このような観点でデータへのアクセス種類とライフサイクルの中での変化を分析し、排他制御について検討します。
【1】のデータは、insertおよびselectは行われますがupdateおよびdeleteは行われないことを示しています。同様に、【2】はinsert、select、updateは行われますがdeleteは行われない、【3】は全てが行われるデータを表しています。【1】のケースだと「バッチ処理で排他制御を行う必要はないか？」と思う人もいるかもしれません。update不可のデータ【1】は、同時更新についての排他制御の必要はありません。しかし気を付けなければならないのは、この「規則」をシステムが保守フェーズへ移行した後も維持していく必要がある、ということです。もし保守のある段階でデータがupdate可能となった場合、排他制御も必要になります。そのような場合を考慮して、最初から読み取りロックとデータ更新回数のカウントアップは実装しておいた方がよいでしょう。
いろいろなシステムを見ていると、バッチが稼働すると、バッチ実行中フラグをあるテーブルの管理レコードに立てることで、オンライン側がそれをチェックし、サービスの実行可否を判定しているケースがありました。これは、オンラインの開閉制御を簡易的に実装している例です。通常は、このような機能をオンライン開閉局機能として実装し、オンラインの利用をコントロールします。そして、その上で、バッチ実行時には、この機能を利用してオンライン機能を閉局して処理を行うのです。
- 参考リンク：トランザクションの一貫性を保証するロック（＠IT）
今回は、ライフサイクルの中でアクセス種類が変化する例には言及しませんでしたが、アクセス種類もデータの状態によって変化する場合があることに留意してください。こうした問題への対策を、もっと簡単に行いたいのであれば、オンラインの利用可能時間を制限し、オンライン処理とバッチ処理が同時に動く時間帯を作らないという方法もあります。多くのレガシーシステムではこの方法を採用しています。
ポイント3：トランザクション
バッチ処理におけるトランザクション制御の検討ポイントは、「トランザクションの単位をどのようにするか」です。一番簡単なのは、バッチ処理の単位で1トランザクションとする方法です。トランザクションデータのコミット処理が実行されると、データベースシステムは更新データの書き込み処理を行います。よって、全体の件数に対して、コミット回数が少なければ少ないほど、高速に動作するのが通例です。
ただし、1トランザクションで処理するデータ件数が多くロールバックに必要なデータ容量が膨れ上がると、頻繁にスワップ処理が発生し、その結果、性能劣化が生じることもあります。トランザクションをいくつかに分割することが、このような処理速度の低下を防ぐケースもあります。バッチのフレームワークには「何件単位でコミット処理を行うか？」を指定できるものもあります。
また別の観点でも、バッチ処理の中でトランザクションを分割する方が有利な場合があります。それはバッチ処理が途中で失敗した場合です。バッチ処理が途中で失敗した場合に再実行することを「リラン」といいますが、リランには2つの方法があります。
【1】データを全てロールバックし、バッチ処理を最初から再実行する
【2】処理できなかったデータのみを対象にバッチ処理を途中から再開する
※【1】を「リスタート」と呼び、【2】のみを「リラン」と呼ぶ場合もあります
例えば処理データ件数が多く、【1】の方式でリランすると時間内に処理を終わらせることができない場合、【2】の方式でリランする必要があります。この時、適切にトランザクションを分割しておくことでリランの範囲を最小限に抑えることができます。
トランザクション単位の考え方としては、他に「データファイル上で更新処理を行い、エラーなく処理できたものだけをデータベースへ反映する」というものもあります。このときの処理の流れは以下のようになります。ポイント1の「実行場所」で紹介した【2】-2の方式に当たります。
【1】データ抽出処理（DB⇒ファイル）
【2】データ加工処理（ファイル⇒ファイル）
【3】データ更新処理（ファイル⇒DB）
【1】抽出処理において、「抽出したレコードに対して更新処理を行うかどうか？（例としては、処理済みフラグを立てるような処理です）」も検討ポイントの1つです。なぜなら、何らかの更新処理を行わなければ、「そのレコードがすでにバッチ処理に連携済みであるか？」の判断を行うのが難しいからです。この辺りは性能とのトレードオフでもあるので、注意して検討する必要があります。
ただし、データの抽出処理が登録されている日付によって決定されるのであれば、処理済みフラグのようなデータは必要ないかもしれません。もし複数件のレコードの更新処理が1SQLで完結するのであれば、高速に処理することが可能です。
ポイント4：ログ
バッチ処理において、ログはとても重要です。バッチ処理が失敗した場合、「処理のどこで失敗したのか」「失敗の理由は何か」といったことを迅速に解析して対処しなければならず、そのために必要な情報を提供するのがログの役割です。先に述べたトランザクション単位やリランの方式と合わせて、ログの内容もそれらを補える内容にしなければなりません。バッチ処理が成功した場合には処理件数や処理時間などを出力し、処理性能などを分析できるようにしておきましょう。以下はログ出力項目の例です。
| ログ出力項目 | ログ出力項目（英語） |
|---|---|
| 開始/正常終了/異常終了 | START/NORMAL END/ABNORMAL END |
| [入力 / 出力]データ件数 | [INPUT / OUTPUT] DATA COUNT |
| 処理対象件数 | PROCESS RECORD(DATA) COUNT |
| 処理件数 | PROCESSED RECORD(DATA) COUNT |
| レコード[登録 / 更新 / 削除]件数 | [INSERT / UPDATE / DELETE] RECORD COUNT |
| 図9 ログ出力項目の例 | |
ログファイルのローテーションや退避方法についても考慮する必要があります。ログファイルは何世代でローテーションを回すのか、古いログファイルはどこへ退避するのかなど、ログの増加量を考慮して決めます。
ポイント5：オンライン処理との関係
最近はシステムの方式として、できる限りデータの即時反映が求められています。そういった意味では、レガシーシステムをオープン化する際にも、この辺りが設計のポイントになります。
例えば、従来は日次バッチが稼働しないと反映されなかった内容についても、現在は即時にデータが反映され、その状況を参照機能で確認することができます。つまり、日次バッチで行われていた処理を、できる限りオンライン処理の中に内包させるようにする流れになってきています。
ただし、ここで注意すべきことは、ロジックをオンライン側に移動させると、オンラインアプリケーションのレスポンスを悪化させる可能性があるということです。その際には、要求されるレスポンスとマシン環境を総合的に判断して、アーキテクチャを決定していきます。
もし、オンライン機能への影響を最小限に抑えたいのであれば、オンライン処理を起点とした即時連携処理の方式（ディレード処理方式）を検討する必要があります。
オンラインでは必要最低限の処理を行ってレスポンスを返し、後続のディレードや、随時バッチに処理を移譲する方式を検討することです。ただし、オンライン以外で登録処理に失敗する可能性が残ります。その場合には、処理を再実行する仕組みも検討を行います。再実行しても失敗した場合は、依頼元へデータ処理の失敗を伝える何らかの方法を忘れずに設計しましょう。大量なトランザクションを受け付けるサービスでは、結果の伝達手段としてメールを使うことがあります。
今回はバッチ処理におけるアーキテクチャ設計時の5つの検討ポイントを解説しましたが、いかがだったでしょうか。データの特性、そのデータが支えている業務の特性に応じてバッチ処理の設計も変わることをあらためて理解できたのではないでしょうか。ぜひ実務の参考としてください。次回はシステム間連携について解説します。
著者プロフィール
熊谷 宏樹（くまがい ひろき）
コーポレート本部 戦略技術センターフェロー
大規模な証券およびカード系システムのチーフアーキテクトを経験し、生産性と品質を向上させるための開発基盤の構築・展開に従事。現在は、社内のアーキテクト育成研修のリーダーを務めるとともに、現場のプロジェクトを支援している。「システムの挙動には必ず理由がある」をモットーに、トラブルの解決にも当たっている。
Copyright © ITmedia, Inc. All Rights Reserved.