保守を考慮したバッチ処理設計(その1）

保守を考慮したバッチ処理設計(その1）

 

こんにちは、商品開発部の北崎です。

毎日快適な在宅ワークで、日々開発を行っています。

ほとんど本社に出社してないので、毎朝ウォーキングしていますが、鹿児島市内の川沿いの桜も、あっという間に新緑に変わってしまいました。

 

私も入社して半年ですが、これまでメーカーで30年ほど社内システムの企画から、設計、開発、保守まで一貫して行ってきました。今回は、これまでの経験から保守効率の良いバッチ処理設計のノウハウについてご紹介したいと思います。

バッチ処理って何？

バッチ処理は、Webでのリアルタイム処理ではなく、データをためて一括で処理する方法です。多くの場合、日次や月次で締め処理として定期実行されます。

よくリアルタイム処理と対比されますが、コンピュータの性能が向上したので、ユーザーのリクエストに応じて逐次処理を実行することもあります。

システムの寿命と保守工数

システムは、導入後、どれぐらいの期間、運用されると思いますか？

規模と比例して刷新の費用や期間も大きくなるのはもちろんですが、ユーザーも業務手順を変えることへの抵抗感もあり、一旦導入すると大きな問題がない限り使い続けられます。これまでの経験上、基幹系になると環境の変化に対応しながら10年以上利用されることが多いのです。

 

新規開発時は、作ることが優先で、どれぐらいの期間運用されるのか意識されることは少ないと思いますが、作り方によっては、新規開発工数よりもはるかに工数がかかり手間のかかるシステムになってしまうことがあります。

多くのシステムを導入すれば、その運用維持にほとんどの工数が消化され、新しいシステム開発やユーザーニーズに対応できない状況に陥ってしまいがちです。

10年以上経過し、以下のような状況で保守が難しくなっていないでしょうか？

・メンバーの入れ替わりで、開発したメンバーが残っていない。

・言語に不慣れで、ソースの解読ができない

・データ量が膨大になって、処理時間が数倍になっている

・ドキュメントの内容が古くて、実際とは異なる

・多くの改修で、処理が複雑になり、どこに影響があるかわからない

導入後の維持運用体制も重要ですが、いったん本番稼働してしまうと保守工数の削減を検討しても大きな変更は難しいので、やっぱり設計時から保守の考慮が必要だったね、と後から悔やむことになります。

 

効率のよい保守の考慮点

システム導入後の保守は、大きく以下の項目に分類され、システム保守を効率よく行うための考慮点をまとめてみました。まとめてみると「当たり前だろう」と思われる内容ですが、設計フェーズから考慮しておかないと導入後の保守工数は、減りません。

No 分類 考慮点
1 監視、日常点検 Logの自動集計、重要度に応じたエラー通知
2 問い合わせ ユーザー側での運用マニュアルの整備と共有
3 データ抽出、修正 ユーザー側で対応可能にする
4 障害対応 素早い原因特定と復旧処置
5 機能追加 全体像、データ流れ、影響範囲の把握がしやすい

それでは、効率のよい保守のためにバッチ処理は、どのように設計すればよいでしょうか？

 

１・監視、日常点検

サーバーやアプリの日常点検や監視作業は、極力自動化したいですよね。AWSを利用していれば、OSのシステムLogやCPU、メモリの監視は、Amazon CloudWatchで閾値のアラート設定とかできるのでいいですが、アプリケーション側のバッチ処理の監視と日常点検は、どうすればいいでしょうか？

私は、通常、Logテーブルを作成し、定期バッチや、リクエスト処理の結果をWeb画面でユーザーが直接検索できるように設計します。

これにより以下のようなメリットがあります。

・データ起因のエラーは、ユーザーが自己解決できるようになる。

・システム担当者と同じWeb画面を共有することで、コミュニケーションしやすい。

・アプリケーションの日常点検もLogテーブルの監視のみに集約できる。

・データ集計しやすいので、処理時間やデータ件数のトレンド等のグラフ化を自動化できる。

・システム担当者が、本番サーバーに毎回ログインしなくてよい。

Logテーブルは、日時、バッチ処理名、メソッド名、処理結果区分、メッセージ内容等の項目を設定し、共通機能として実装します。

処理結果区分には、以下の区分を設け、絞り込み検索できるようにしておきます。

No 処理結果区分 内容
1 Target 処理対象データのKey項目、件数
2 Info 処理中の情報を表示
3 Result 処理結果。処理結果のKey項目、件数を表示する
4 Warning エラーではないが、確認が必要な場合
5 Error データ起因のエラーの場合。処理は中断しない
6 Abend 処理を中断する場合。ロジックの想定外エラー等

データ起因のエラーは、ユーザー側で対処できるようエラー内容とKey項目を表示します。エラー内容は、システム的な表現ではなく、ユーザーがわかる文章表現にします。

原因となったデータのKey項目からWeb画面で検索・メンテできるようにすることで、システム担当者への問い合わせを削減できます。

また、ユーザーとシステム担当者と同じ情報を共有することで、コミュニケーションもスムーズになります。

 

2・問い合わせ

　社内システムの場合、運用マニュアルは、ユーザー側で作成してもらいます。

システム導入前の運用テストフェーズで、ユーザーに機能を理解して頂き、業務フローに合わせた運用マニュアルを作成して、画面にリンクを設定し、常に閲覧できるようにします。導入後もユーザー側でメンテナンスすることで、運用担当者が変わった時でもスムーズな引継ぎができます。

　業務マニュアルは、システム概要と全体像も追加し、データがどのように処理されていくのかわかるようにすることが大事です。よくあるケースで、作業手順だけドキュメント化し、何の為の作業か、このデータがどこに結びつくのかが理解されないまま使われ、担当者が変わるたびに、ノウハウも欠落していき、数年後には誰も中身がわからないシステムになっていきます。こんな状態で機能追加の必要が出てくるとシステム担当者は、最悪ですね。

現状の運用とシステム動作を正しく理解したキーユーザーがいるかいないかで、保守も大きな違いが出てきます。ユーザーが自らシステムの動作を理解し、業務フローを見ながら日々の改善ができるように、マニュアルを整備するキーユーザーをフォローしておくことも保守工数削減の大きな要因だと思います。

 

3・データ抽出、修正

データ起因のエラーは、ユーザー側で元データを修正し、単純リランできるように設計します。

バッチ処理の利点は、システム全体の整合性を維持できることです。一部のデータのみ修正し、データの不整合が発生しないようにする為には、

１：源流のデータを修正する

２：処理を経由する途中のデータは、直接メンテせずバッチ処理で整合性を保持する

３：定期実行に加え、Web画面からユーザーがバッチ処理を実行できるようにする

締め時刻が決まっている業務では、ユーザーが自由にバッチ処理を何度も実行できるようにしておきます。これがないと締めに間に合わせるため、何度もシステム担当者に処理の実行依頼が来ます。また、その間は待機しておくとか、ローカルルールに縛られてしまいます。

ユーザー側での分析作業や調査目的で、全件データをWeb画面からダウンロードできるようにします。負荷の大きい処理は、定期のバッチ処理でCSVデータを生成し、Web画面からダウンロードするケースもあります。

 

今回はここまでですが、いかがだったでしょうか？

続きは、近日中にアップしますね。