ブログBlog
プログラムの処理方式
こんにちは、サカタです。
最近暑くなってきましたね。
この頃はリモートワークが増え出勤日が少ないので、なかなかそれを日々敏感に感じられにくくなってきました。大汗をかきつつ出勤し、受注先のお客様にクールビズ期間になった事を確認し、私もクールビズスタイルで出勤を始めました。
皆様はいかがですか？
さて、今回の私の常駐先仕事ではバッチ方式のプログラムが多くなってきました。
以前の仕事でエクセルマクロやCシェルでのバッチプログラムを作った事はありましたがメインではなく前者は通常の業務の補助のため、後者は撤退協力会社の方が残したソースの改修でしたが、全くCシェルの経験がなかったのでやっかいだった記憶があります。
wikiで調べるとバッチ処理とは
「コンピュータでひとまとまりのデータを一括して処理する方式」
「反対語は逐次処理または連続処理。」「データをキューイングせず即時処理するリアルタイム処理とも比較される。」とあります。
他には反対の処理をオンライン処理としているような情報もありますね。（厳密にはオフライン処理の反対がオンライン処理だと思いますが）
一般の方にはあまりなじみのないものだと思います。現在ではバッチと反対/対象的となる上記の逐次処理または連続処理、リアルタイム処理で、ネット通販やスマホからのネット/Web経由の処理の対話的利用がこのバッチではない方式だからです。
しかし、ワクチン予約システムがトラブルで停止した等の最近の報道にもあるようにこのバッチではない方式（以下リアルタイム処理と表記）での問題が多くなったように感じます。またインターネット上のトラブルでこれらのシステムが利用できなかった問題も増えています。またこれらにはユーザが多くて、処理が集中してしまったためサーバやサーバまでのネットワークインフラに問題が生じている事象も見受けられます。
初期のコンピュータでは端末からの対話的利用はほとんど行われず、バッチ処理方式が主流でした。
wikiではバッチ処理には以下のような利点があると書かれてあります。
・多くのユーザーがコンピュータのリソースを共有できる。
・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。
・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。
・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。
だとするとやはり大量ユーザの処理等現在の問題にはバッチ処理の方が一日の長があるように思えます。そのせいか昔からあるインフラ系等の基幹システムの処理にはバッチ処理が多く用いられています。
と言ってもバッチ処理で一部の銀行などで問題は起きていますし、バッチでのデメリットやできない事もあります。
しかし、現在はまだまだネット経由のリアルタイム処理には、大量ユーザ集中時に耐えられるだけのネットワークやサーバ側のキャパシティが追いついていないのではと思われます。また最近はワクチン予約システムをはじめ時間や予算の理由で民間のクラウドシステムのインフラやフレームワークを利用してシステム構築される場合が多く、そちら側で問題が起きたらシステムが利用できなくなるし、復旧もクラウド側頼みになってしまうという問題もあると思います。
なので特に国民全員単位等大量ユーザの利用が予想されたり、インフラ・基幹・金融系の重要なシステム等は、十分にリスクを考え、バッチ処理のよいところも取り入れながら構築した方がよいではと、最近この手のトラブルの報道を目にする際によく思うようになりました。（例えば予約システムでは予約結果のリアルタイムの回答をあきらめ、コンサートチケットの抽選予約みたいに処理後にメールで知らせるとか。）
皆さんはどう思いますか？
それでは、また。
最近暑くなってきましたね。
この頃はリモートワークが増え出勤日が少ないので、なかなかそれを日々敏感に感じられにくくなってきました。大汗をかきつつ出勤し、受注先のお客様にクールビズ期間になった事を確認し、私もクールビズスタイルで出勤を始めました。
皆様はいかがですか？
さて、今回の私の常駐先仕事ではバッチ方式のプログラムが多くなってきました。
以前の仕事でエクセルマクロやCシェルでのバッチプログラムを作った事はありましたがメインではなく前者は通常の業務の補助のため、後者は撤退協力会社の方が残したソースの改修でしたが、全くCシェルの経験がなかったのでやっかいだった記憶があります。
wikiで調べるとバッチ処理とは
「コンピュータでひとまとまりのデータを一括して処理する方式」
「反対語は逐次処理または連続処理。」「データをキューイングせず即時処理するリアルタイム処理とも比較される。」とあります。
他には反対の処理をオンライン処理としているような情報もありますね。（厳密にはオフライン処理の反対がオンライン処理だと思いますが）
一般の方にはあまりなじみのないものだと思います。現在ではバッチと反対/対象的となる上記の逐次処理または連続処理、リアルタイム処理で、ネット通販やスマホからのネット/Web経由の処理の対話的利用がこのバッチではない方式だからです。
しかし、ワクチン予約システムがトラブルで停止した等の最近の報道にもあるようにこのバッチではない方式（以下リアルタイム処理と表記）での問題が多くなったように感じます。またインターネット上のトラブルでこれらのシステムが利用できなかった問題も増えています。またこれらにはユーザが多くて、処理が集中してしまったためサーバやサーバまでのネットワークインフラに問題が生じている事象も見受けられます。
初期のコンピュータでは端末からの対話的利用はほとんど行われず、バッチ処理方式が主流でした。
wikiではバッチ処理には以下のような利点があると書かれてあります。
・多くのユーザーがコンピュータのリソースを共有できる。
・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。
・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。
・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。
だとするとやはり大量ユーザの処理等現在の問題にはバッチ処理の方が一日の長があるように思えます。そのせいか昔からあるインフラ系等の基幹システムの処理にはバッチ処理が多く用いられています。
と言ってもバッチ処理で一部の銀行などで問題は起きていますし、バッチでのデメリットやできない事もあります。
しかし、現在はまだまだネット経由のリアルタイム処理には、大量ユーザ集中時に耐えられるだけのネットワークやサーバ側のキャパシティが追いついていないのではと思われます。また最近はワクチン予約システムをはじめ時間や予算の理由で民間のクラウドシステムのインフラやフレームワークを利用してシステム構築される場合が多く、そちら側で問題が起きたらシステムが利用できなくなるし、復旧もクラウド側頼みになってしまうという問題もあると思います。
なので特に国民全員単位等大量ユーザの利用が予想されたり、インフラ・基幹・金融系の重要なシステム等は、十分にリスクを考え、バッチ処理のよいところも取り入れながら構築した方がよいではと、最近この手のトラブルの報道を目にする際によく思うようになりました。（例えば予約システムでは予約結果のリアルタイムの回答をあきらめ、コンサートチケットの抽選予約みたいに処理後にメールで知らせるとか。）
皆さんはどう思いますか？
それでは、また。