こんにちは。
これまで2回の連載にて、レガシーモダナイゼーションとデータ統合処理におけるバッチ処理の課題を洗い出してきました。
今回は、洗い出した課題をバッチ処理基盤の観点で統合し、解決するためのアプローチを考察していきたいと思います。

運用性における目標と達成基準

レガシーモダナイゼーションのバッチ処理とデータ統合処理の課題を統合すると、運用性、生産性、性能という優先順位になります。
まずは、運用性から、課題に対するアクションを考えていきます。

運用性における目標は、2つです。

• レガシーのバッチ処理をマイグレーション後も安定稼働させること。
• インフラがクラウドになっても問題なく運用できること。

達成するためのポイントは、3つです。

• 障害が起きても、他システムや処理に影響しないシステム構造にすること。
• データ量が増えても減っても、安定稼働する仕組みにすること。
• クラウド連携の機能性を担保できる基盤にすること。

生産性における目標と達成基準

次に、生産性の課題に対するアクションを考えていきます。

生産性における目標は、2つです。

• 属人化を排除して、チームとして要件の変更や追加に柔軟に対応できること。
• オンプレでもクラウドでもノーコードでスピード感を持って対応できること。

達成するためのポイントは、3つです。

• 誰でも簡単に開発できる仕組みにすること。
• 安定性と性能の作り込みの工数を基盤側で担保できる仕組みにすること。
• オンプレでもクラウドでも生産性が変わらないこと。

性能における目標と達成基準

最後に、性能の課題に対するアクションを考えていきます。

性能における目標は、2つです。

• データ量が多くても、更改前のサービスレベルを担保すること。
• 運用性と生産性に負荷をかけずに性能を担保すること。

達成するためのポイントは、3つです。

• データ量に応じて処理がスケールする仕組みであること。
• 性能のために、特殊なシステム構成やリカバリ処理等の複雑な運用をしないこと。
• スキルが高い人がゴリゴリ作り込んで性能が出る、という属人化の仕組みにしないこと。

バッチ処理基盤の構造

バッチ処理基盤の構造を考えると、ファイルとデータベースとバッチ処理がやり取りをするわけですが、お客様によっては、超大きいデータベース環境を構築して、データをすべてそこにツッコんで、SQLでぐりぐり処理するというようなアーキテクチャを採用されることもあります。

私は、システムを俯瞰して見て、ファイル処理の運用も考慮したうえで、データベース処理とのバランスを取る仕組みが有効だと考えます。
バッチ処理基盤に大きなパワーを持たせるというシステムのアーキテクチャ設計思想です。

そして、このバッチ処理基盤に、運用性、生産性、性能を担保するバッチ処理エンジンをアーキテクチャとして組み込むシステム設計がとても効果的だと考えてます。

これにて、バッチ処理基盤についての考察は、いったん完了です。

本ブログのスライドは、前回 の連載記事と同様、2022年11月16日開催「DX Insight Winter」講演内容を再構成した資料から抜粋しています。資料は、こちらからダウンロードください。