2008年には楽天証券が、2011年にはみずほ銀行が、2013年にはアフラック(アメリカンファミリー生命保険)がバッチ処理の”突き抜け”により大規模なシステム障害を引き起こしています。
日々バッチ処理と向き合っているエンジニアの方々の中には「始業時間までバッチ処理が終わらないかもしれない…」と肝を冷やした経験があるのではないでしょうか。
そもそもバッチ処理の突き抜けは何が原因で起きるのか？今回は2つの原因、そして突き抜けないための対策について解説していきます。
バッチ処理とは
バッチ処理とはいわゆる、”一定量あるいは一定期間のデータが溜まった段階で一括処理するというデータ処理方法”です。
日中皆さんが業務にあたっている際は実に多くの、そして多様なデータがやり取りされています。
売上げ、購買、在庫、給与などなど、全てのデータ統合するとそれはもう大規模なデータ群となりますね。
こうしてやり取りされているデータは即時性があり今すぐ処理する必要のあるデータと、すぐにではなく一括で処理した方がいいデータの2種類があります。
銀行の勘定システムで例えると分かりやすいですが、前者は銀行ATMなどユーザーが利用し即レスポンスが求められるデータとなります。
皆さん銀行ATMを利用する際はすぐにお金を毛受け取ることができますが、これはその場でデータ処理が行われているからです。
後者は給与振り込みや月末決済など、ある程度まとまったデータをいっぺんに処理するデータとなります。
即時性のあるデータはオンライン処理によりその場で処理され、それ以外のデータはバッチ処理で一括処理されるのです。
なぜバッチ処理が必要かというと、全てのデータをオンラインで処理してしまうとシステムが過負荷となり、システムダウンを起こしてしまうからです。
もちろん、最近ではオンライン処理のみでデータ処理を行っているケースもありますが、ほとんどの企業でオンライン処理とバッチ処理でデータ処理を分担しています。
バッチ処理の突き抜けとは
突き抜けとはいわば、予定時間内にバッチ処理が終わらなかったことを指します。
バッチ処理中はシステムにかなりの負荷がかかっているため、基本的にオンライン処理と並行して行うのは不可能です。
ですのでバッチ処理は一般的に夜間に行われます。(これを夜間バッチや日次バッチを言います)
夜間バッチはシステムリソースの有効活用や日中の業務システムへ影響を出さないために行いますが、稀に予定時間内に終わらずに日中業務システムが稼働できないという状況が発生します。
これがバッチ処理の突き抜けであり、バッチ処理担当エンジニアの方は日々突き抜けがないか常に注意を払っていることでしょう。
しかし、注意を払いつつもバッチ処理が突き抜けシステム障害を起こしてしまっている企業が少なくありません。
冒頭で列挙した企業や突き抜けよる”大規模なシステム障害”を起こしたケースであり、「始業開始時間になっても業務システムが動いてない」といったトラブルに関しては多くの企業で日常的に起きています。
バッチ処理が突き抜ける2つの原因
1.データ量増加に伴う対策が取れていなった
バッチ処理の突き抜けで最も多のがこの原因であり、みずほ銀行やアフラックではデータ量の増加に対処できず突き抜けを起こしました。
業界業種を問わず、何かしらのシステムが稼働し続けている以上データ量は増加しいてく一方です。
このデータ量が増えればその分バッチ処理に遅延が発生するので突きぬけが起こります。
データ量増加に対する対策としては主に並列処理が用いられますが、これは影響範囲が重なっていない処理ポイントに対し並行して処理を行うことでバッチ処理時間を短縮するというものです。
しかし、どんなに並列処理を施したとしてもデータ量の増加は避けられないので、いずれCPUやメモリなどのリソース不足が起こります。
このためエンジニアは常にデータ量の推移を予測し、状況に合わせて並列度を増加させたりシステムリソースのスケールアウトやスケールアップを行わなければならないのです。
また、最近ではサーバのパフォーマンス低下を避けるために処理を複数サーバに分散するといった手法が取られています。
クラウドサービス環境が整備された現代では、ニーズに合わせて自由にサーバリソースの増減が可能なので、有効的な手段だと言えますね。
データ量増加に伴う突きぬけは寸前で対処するのは非常に難しいので、事前の対策が何よりも重要です。
オンライン処理との整合性が取れず過負荷となった
最近では東急ハンズの事例があるように、夜間バッチを廃止する動きが各社で見られています。
夜間バッチ廃止のメリットとして突きぬけが起きないということや、業務側としも翌日の発注データを前日に作れるので業務効率化に繋がります。
しかしやはりと言いますか、夜間バッチ廃止にはリスクがあるのです。
夜間バッチを廃止したからと言ってバッチ処理が不要なわけではなく、日中のオンライン処理と並行して処理が行われます。
このとき注意したいのがオンライン処理とバッチ処理との並行処理によりシステムリソースが不足し、システムダウンを起こすことです。
しかし、システムへの負荷を下げようとバッチ処理負荷の割合を下げると結局夜間まで持ち越すことになり、オンライン処理負荷の割合を下げると業務システムのパフォーマンス低下に繋がるので設計が非常に難しくなります。
また、上手に設計しなければバッチ処理とオンライン処理で同じデータにアクセスしてしまい競合が発生しやすくなるというリスクもあるので注意が必要です。
バッチ処理とオンライン処理を並行させるためには、基本的にオンライン処理を起点としつつ連携処理方式を検討することです。
つまりオンライン処理では必要最低限のデータ処理だけを行い、残りのデータに関してはディレード(※1)やバッチ処理で対応するといった設計となります。
※1：ディレードとは一般的にディレードオンライン処理を指し、ある程度トランザクションを蓄えてから処理する方法。
突き抜けを起こさないために取れる対策は？
突きぬけはそもそもデータ量の増加やオンライン処理との兼ねあいによるシステムリソース不足で起きるケースがほとんどなので、まずはスケールアウトやスケールアップを容易にできる環境を確保することです。
これは、クラウド環境をシステム構築を行うのが最も適しているでしょう。
そもそもクラウドとはインターネット経由でサーバリソースなどのインフラを提供するサービスであり、拡張性に優れているため自由にリソースを増減することができます。
ですので「データ量が増加して突き抜けが起きそう！」などといった時に、簡単にスケールアウトやスケールアップを行うことが可能です。
しかも、クラウドは従量課金制で使った分の費用しか発生しないのでコスト削減にも繋がるでしょう。
また、増え続けるデータ量を削減するためにデータのライフサイクルを定義するのも効果的です。
予めデータ保持期間を策定して設計しておけば、定期的にデータの整理がされ増加を防ぐことができます。
もう一つの対策としては、高速なバッチ処理で突きぬけを防止する大規模バッチ処理ソリューションの導入です。
インテリジェントモデルの「ODIP(オーディップ)」では、大規模なバッチ処理も高速で行うソリューションを提供しています。
また、GUIでのシステム構築を提供しているのでプログラムの属人化やブラックボックス化を防止し、バッチ処理のパフォーマンス維持にも貢献します。
バッチ処理で突きぬけを起こすことで生まれる機会損失は測り知れません。
このため経営者やエンジニアの方は突きぬけに対し十分に注意し、事前に対策を取っておくことが大切でしょう。
まとめ
最後に、今回の要点を以下にまとめておきます。
- 突きぬけとは、予定時間内にバッチ処理が完了せず日中の業務システムを稼働できなくなること
- 突きぬけの原因のうち最も多いのがデータ量の増加に共ないシステムリソースが不足し、バッチ処理が遅延するケース
- 夜間バッチレスによりオンライン処理とバッチ処理を並行させると突きぬけのリスクが高まる
- データ量増加による突き抜けを防止するためには、まずシステムリソースのスケールアウトとスケールアップを行う
- プラットフォームはリソースの増減が自由なクラウドがおすすめ
- オンライン処理を起点とした連携処理方式で、システムを上手に設計する
- 増加するデータ量を削減するためには、データのライフサイクルを定義しておくのが効果的
- 大規模バッチ処理ソリューションで処理を高速化し、プログラムの属人化防止でパフォーマンスを高める
いかがでしょうか？今回はバッチ処理の突きぬけが起きる原因について解説しました。
日々バッチ処理と向き合っているエンジニアの方にとってはすごく身近な突きぬけですが、非エンジニアの方からすれば「そんなトラブルもあるのか」と思いますよね。
実は、経営者の中にも突きぬけについてよく知らないなんて方が少なくありません。
「ITのことに関してはエンジニアに一任している」というスタンスの方が多いのでしょうが、経営に関わることである以上知っておく必要はあるでしょう。
また、バッチ処理や突き抜けなど社内のITについて深く理解することで、今後何に投資をしたらいいのか？が自然と見えてくると思います。
IT活用が企業成長に直結すると言われている現代では、非エンジニアでもITへの理解が必須だと言えますね。
本稿ではバッチ処理突きぬけの原因について紹介しましたが、他にも超高速開発ツールやIT用語解説などなどITへの理解を深められるコンテンツを用意しています。
ITへの理解を深め、是非今後の経営戦略に役立ててください。
