今回の記事では、企業のシステム管理者や経験の浅いSEを対象にして、システムの運用におけるバッチ処理の特徴や、有効な活用方法を紹介していきます。
「バッチ処理」とは
今回の記事の主題である「バッチ処理」について大まかに定義していきます。
まずは、Wikipediaで「バッチ処理」についての解説を抜粋してみます。
データ処理におけるバッチ処理（バッチしょり）は、ひとまとまりのデータを一括して処理する方式である。逐次生み出されるデータを一定期間・一定量集めたものをバッチといい、このバッチ単位で処理をおこなう方式がバッチ処理である。
バッチ処理 – Wikipedia
狭義の意味としてはWikipediaに記載されている解釈で問題無いかと思いますが、当記事ではもう少し広く解釈して以下のように定義します。
- 複数の関連する処理を一つにまとめて実行できるプログラムである。
- 夜間など決められた時間に実行される非同期処理である。
- 対話的なコンソールを持たず起動から終了まで自動化されている。
複数の処理を一つにまとめたプログラムと記載しましたが、処理が一つだけでも対話的なコンソールを持たず、非同期処理(オンライン処理ではない、又はリアルタイム処理ではない)で実行されるプログラムであればバッチ処理として定義しようと思います。
また、一般的な業務アプリケーションのように操作画面を持たず、実行時に画面を表示しない、又はコマンドプロンプトなどの簡易的なコンソールを表示し、処理が完了後に自動的に終了するプログラムも広義なバッチ処理、又はバッチプログラムとして扱うこととします。
「バッチ処理」の基礎知識
当項では、「バッチ処理」や「バッチプログラム」の実装種類ごとの特徴やバッチ処理の一般的な用途などの基礎的な知識を紹介しておきます。
これらの知識は、システム管理者が状況に応じて適切なバッチ処理の実装方法を選定したり、実行する環境の制約を理解しながらバッチプログラムを運用するためには不可欠な知識です。
バッチ処理の実装方式の種類と特徴
一言で「バッチ処理」といっても、その実装方式(作り方)は様々なです。
その実装方式によって、作成の手軽さや実行時の制約などの特徴があります。
実際にはプログラム言語の数や、動作環境を数分の実装方式がありますが、そのなかでも主要な実装方式と特徴を以下で列挙していきます。
| 実装方式 | 動作環境 | 実装 難易度 |
特徴 |
|---|---|---|---|
| bat | Windows | 低 | Windows標準のDOSコマンドと制御構文を組み合わせて簡単なプログラムの作成が可能。 すべてのWindows環境で実行できるが、複雑な処理の実装はできない。 |
| シェルスクリプト | Linux | 低 | Linuxのコマンドと制御構文を組み合わせて簡単なプログラムの作成が可能。 Windowsにおける「bat」と同じような役割。 |
| VBScript | Windows | 低 | Windowsに標準で搭載されているWSH(Windows Script Host)を使用するスクリプト言語。 VB系の構文で記述ができて、比較的複雑な処理も実装が可能。 |
| PowerShell | Windows /Linux |
中 | Windows7以降のWindowsOSに標準搭載され、オブジェクト指向に基いて設計されているスクリプト言語。 .NET Frameworkを使用し、.NET Coreを利用することでWindows以外の環境でも動作可能。 |
| Java/C#などの 高級コンパイル型言語 |
Windows /Linux |
高 | コンパイルをしてEXE形式などの実行ファイルの生成が必要な言語。 OS標準搭載されたスクリプト言語に比べ高度な処理が実装できて動作も高速。 |
| PHP/Python/Rubyなどの バックエンド系言語 |
Windows /Linux |
中 | Webアプリのバックエンド側の開発などで使われることも多い言語。 バッチ処理としても利用可能。 |
| ストアドプロシージャ | RDBMS | 中 | IFなどの制御構文とSQLを組み合わせたサブルーチンをRDBMS内に作成、実行できる機能。 RDBMSごとに独自拡張された構文が用意され互換性はない。 |
上記の表では実装難易度も定義してみましたが、実際にはその実装方式を用いてどんな処理を作るかによって難易度は大きく変わります。
バッチ処理の実装方式や使用言語の違いによる特徴の詳細
前項では、バッチ処理の実装方式による特徴の違いを大まかに解説しました。
当項では、実装方式ごとの具体的な特徴を紹介していきます。
「bat」の特徴の詳細
バッチ処理において、Windows環境では昔から広く活用されている実装方式です。
大昔から存在し、PowerShellなどの高機能なスクリプトがOS標準で利用できるようになった現在においても、ちょっとした処理の自動化では十分便利に使えます。
作成方法も手軽であり、空のテキストファイルを作成し、処理させたいDOSコマンドをメモ帳などで記述します。
必要によってIFなどの制御構文も組み合わせた一連の処理を作り、そのテキストファイルの拡張子を .bat に変更して保存するだけです。
このファイルをダブルクリックなどで実行すると、コマンドプロンプトが起動し、batファイル内で記述した一連の処理がまとめて実行されます。
当ブログでも、batファイルを作成して処理の自動化する方法を紹介した記事を幾つか掲載しています。
但し、一般的なプログラミング言語で用意されているような高度な処理はできません。
また、繰り返し処理の仕様にクセがあり、慣れないと非常に扱い難い側面もあります。
あと、注意するべきポイントとしては、batを実行する際に「管理者として実行」するか、通常実行するかによって、DOSコマンドで行える操作が変わります。
管理者としてコマンド実行をしないと、その操作を受け付けてくれないものもありますが、UAC(ユーザーアカウント制御)の設定によっては、管理者権限での実行に制約が発生する場合もあります。
大昔のWindowsではコマンドプロンプトがOSを操作するためのシェルでした。
WindowsのシェルがExplorerなどのGUIに置き換わった以降もWindowsがアプリケーションを起動する仕組みに変わりはなく、DOSコマンドを使用することで殆どのアプリケーションを起動することができます。
コマンドで指定したアプリケーションの実行ファイルに必要な引数を渡して起動する操作を自動化する場合、今でもbatの仕組みは有効な手段の一つです。
「bat」でバッチを作るメリットデメリット
- ファイルのコピーなどOSの基本操作であれば容易に自動化ができる。
- OS標準機能のなかで実行ができてソフトのインストールが不要。
- コマンド操作に対応した外部アプリケーションとの連携で使用可能。
- Windowsのバージョンの違いによる機能差が殆どない。
- 複雑な制御や分岐が求められる処理は実装できない。
- DOSコマンドで用意されている機能がすくない。
- UACの設定によっては管理者権限の実行に制約がある。
- WindowsOS上でしか利用できない。
メリットのなかでも大きいのは、OS標準で使用できて、Windowsのバージョンの違いによる影響がほぼ無い部分です。
Windows Server 2003で使用していたbatファイルを、Windows Server 2022 にコピーして実行しても、通常は同じように動作します。
また、WindowsのサーバーOS間に対する互換性だけではなく、Windows11などのクライアント用OSに対しても互換性があります。
これは大きなメリットです。
デメリットとしては、複雑な処理をbatで実装しようとすると、DOSコマンド自体の機能の貧弱さによって、実装に手間がかかったり、そもそも機能が足らず実装ができない場合もあります。
「bat」に向いているバッチ処理の用途
「bat」で向いているバッチ処理の用途としては以下です。
- サーバーデータのファイルベースの日次バックアップ処理。
- 端末の設定変更コマンドを記述してADのGPOで管理下の端末に配信。
- PCのキッティング作業時の設定作業自動化。
- 外部アプリケーションに引数を渡して実行させる定時処理。
このような用途であれば、DOSコマンドレベルでの自動化(bat)で十分だと言えます。
「シェルスクリプト」の特徴の詳細
Linuxでは「Bash」と呼ばれるシェルが広く使われており、シェルスクリプトではその「Bash」に対する操作をスクリプトとして自動化できます。
WindowsOSにおけるbatと同じような役割です。
LinuxでOS上の操作を自動化するようなケースでは、まず「シェルスクリプト」を書くのが一般的です。
また、Linux上で動作するApacheなどのアプリケーションの起動時の処理などで、シェルスクリプトが用意されており、そのシェルスクリプトを読み込んで自動的に実行しているケースも多々あります。
尚、シェルスクリプトでバッチ処理を作る場合のメリットデメリットや、シェルスクリプトに向いている用途は、コマンドプロンプトとほぼ同じです。
よく使用される用途としては、Linuxサーバーのデータバックアップ処理を自動化したり、ログをローテートしたり、Linuxで稼働させているサービスの運用をを自動化するといった使い道があります。
もしLinuxでサーバー運用するのではれば、簡単なシェルスクリプト程度は作れるようにしておくことで、サーバーの運用作業の多くを自動化、無人化できることになり、大変重宝します。
「VBScript」の特徴の詳細
VBScriptは、VB系のプログラミング言語の構文を真似て作られているスクリプト言語であり、前述したbatファイルで用意されている機能と比較すると、実装できる処理が各段に増えています。
正確に言えば、VBScript自体にはそれほど多くの機能を持っていないのですが、Windows独自のアプリケーション間の連携技術を利用して、必要な処理を呼び出して利用できるような設計思想になっています。
尚、当ブログでは、過去にプログラミング言語におけるVBScriptの特徴を記事にしています。
興味があれば以下のリンクからご一読ください。
このリンク先の記事でも解説していますが、VBScriptはバッチ処理を実装するプログラミング言語としても大変優秀です。
言語の持つ機能としては、後述するPowerShellの方が格段に優れていますが、コードの記述のし易さや、実行環境の汎用さ、セキュリティ上の制約の緩さなどの点で、PowerShellに勝っています。
コードの記述のし易さの観点では、言語仕様をVB系に似せて設計されており、Microsoft Office の VBA を習得している人であれば、同じ構文でコードを書くことができます。
また、実行環境の汎用さの観点では、VBScriptの実行環境であるWSH(Windows Script Host)がWindowsOSに標準搭載されたのは Windows 95 の頃であり、以降は最新のWindowsOS上でも変わりなくサポートされています。
長い歴史のなかで、VBScriptの実行環境であるWSHのバージョンアップは発生していますが、Windows Vista の頃を最後に、それ以降は良くも悪くも更新はされていません。
よって、過去に書いたコードが新しいOS環境上でも同じように動くことは大きなメリットです。
また、IDEも不要であり、コンパイルも必要ないため、メモ帳などのテキストエディタがあればその場で作成することができます。
更に、例えばbatファイルを実行する場合は、前述したように管理者権限の有無による影響を受けます。
PowerShellの場合も、管理者権限のないOSユーザーが実行してもブロックするセキュリティポリシーが既定では有効になっていたり、厳しいセキュリティ上の制約があります。
しかし、VBScriptに関しては、このような制約がありません。
それはセキュリティ上のリスクでもあるため、WindowsのローカルポリシーなどでVBScript自体の実行をできなくするような設定も可能ですが、既定の状態では自由に実行が可能です。
このようにセキュリティ上の制約が緩いのも、使い勝手の面で非常に有効です。
また、例えばWindowsのレジストリにアクセスしてキーの値を取得したり書き換えるといったWindows自体の設定を変更することもVBScriptは得意です。
これもセキュリティ上のリスクと表裏一体ではありますが、PCのキッティングを自動化させるバッチ処理を作る場合は非常に重宝します。
ただし、複雑なコードを書こうとした場合は、言語仕様における機能の少なさから冗長なコードにならざるを得ないのと、Web APIのデータの受け渡しなどでよく使われるJSON形式のデータをパースするといった比較的新しい技術には対応できていないため、処理によってはVBScript単体では実装しきれないケースも発生します。
「VBScript」でバッチを作るメリットデメリット
- 「OLE」で外部アプリケーションと連携し高度な処理も実装可能。
- OS標準機能のなかで実行ができてソフトのインストールが不要。
- Windowsのバージョンの違いによる機能差が殆どない。
- セキュリティ上の制約が少なく自由に実行できる。
- タスクスケジューラーから直接実行できる。
- JSONデータのパースなど比較的新しい技術には対応できていない。
- IDEが存在しないため、ステップインでデバッグすることができない。
- マルウェアなどの不正なソフトの攻撃に悪用される恐れがある。
- WindowsOS上でしか利用できない。
メリット部分で言えば、前述した「bat」の上位互換と言えます。
DOSコマンドでやれることは概ねVBScriptでもやれますし、更にVBScript内でシェルのオブジェクトを生成し、DOSコマンド自体を実行させることもできます。
また、OLE技術で外部アプリケーションと連携できることで、ADO(ActiveX Data Objects)を利用してデータベースに対してSQLを発行してデータを取得したり、データを更新するような業務アプリケーション用のバッチ処理も開発が可能です。
デメリットは、言語仕様が古いことにより、現在のデータ交換フォーマットの主流であるJSONなどのデータ形式に対応できない部分が大きいです。
JSONのパースが必要になった場合は、バッチ処理自体を他の言語に変えるか、パース処理だけを他の言語で作り、それを呼び出すようにする必要があります。
「VBScript」に向いているバッチ処理の用途
「VBScript」で向いているバッチ処理の用途としては以下です。
- 業務システムのDBに接続したデータ更新処理。
- 端末の設定変更コマンドを記述してADのGPOで管理下の端末に配信。
- PCのキッティング作業時の設定作業自動化。
- SaaSのWeb API連携処理(JSONは不可)。
実行環境自体はWindowsOSに限定されますが、様々な用途のバッチを作成することができます。
当ブログでは、VBScriptを利用して、データベースのデータを更新するバッチ処理の実装方法や、Web APIを利用したシステム連携の実装方法なども広く記事で紹介しています。
ご興味があれば、以下の記事もご一読ください。
また、プログラミング初心者向けに、VBScriptの入門記事もあります。
これからプログラミングを覚えようとされる方は以下のリンクをおススメします。
「PowerShell」の特徴の詳細
PowerShellはMicrosoftが開発しているスクリプト言語であり、そのスクリプトの実行環境です。
比較的新しいプログラミング言語であり、Windows 7 以降のWindowsOSに標準搭載されています。
尚、WindowsOS自体の管理や操作をコマンドラインから行うためのシェルでもあります。
登場した初期の頃はWindows専用のスクリプトでしたが、マルチプラットフォームで動作する.NET Coreの登場により、Linuxなどの異なるプラットフォームでも利用できるようになりました。
PowerShellに関する詳しい説明は、以下のリンク先のWikipediaの記事を読んでいただいたほうが早いかと思います。
上記のリンク先でもPowerShellの特徴がまとめられていますが、個人的には以下の点が大きな特徴だと考えています。
- .NET Frameworkを基盤としたオブジェクト指向言語
- Windows環境であればインストールや設定不要で利用できる。
- .NETのクラスを利用することで様々な処理を実装できる。
- エイリアスがありDOSコマンドと互換性がある。
- 実行ポリシーにより実行権限の制約が存在する。
まずは、ベースが.NET Framework(マルチプラットフォーム用では.NET Core)である部分が最大の特徴です。
そのため、PowerShellでは、.NET に含まれる様々なクラスを利用して処理を実装することができます。
Windows標準のスクリプト又はシェルとして、「bat(DOSコマンド)」や「VBScript」を紹介してきましたが、PowerShellではそれらと比べ物にならないほど高機能です。
VBScriptの紹介では、JSON形式のデータのパースといった処理が対応できないと書きましたが、PowerShellでは当然対応可能です。
また、PowerShellはスクリプト言語であると同時にWindowsのシェルの役割もあり、コマンド操作にも対応しています。
そのコマンドは、旧DOSコマンドと同名のエイリアス(別名)が用意されており互換性があります。
尚、PowerShellでは各コマンドを入力して、その結果が.NETのオブジェクトとして返されます。
オブジェクトとして返されるため、そのオブジェクトからプロパティとして値を取得するといったことも可能になっています。
また、マルウェアからの悪用を防ぐ目的や、意図しない実行を防止するために、PowerShellでは「実行ポリシー」と呼ばれる仕組みがあり、PowerShellのスクリプトが実行できる権限に制約を掛けています。
「PowerShell」でバッチを作るメリットデメリット
- .NETの機能を利用することで高度な処理も実装可能。
- OS標準機能のなかで実行ができてソフトのインストールが不要。
- 現在も開発が継続されており、機能が更新されている。
- C#など.NETベースの言語経験があれば習得も容易。
- パイプに対応しておりコマンドを柔軟に組み合わせることができる。
- コマンドレットや.NETのクラスの文字列が長いため入力支援のあるエディタが必要。
- PowerShellの実行ファイルであるps1ファイルを単独で実行できない。
- タスクスケジューラーから直接ps1ファイルを指定して実行することができない。
- スクリプト言語でありシェルとしてコマンドも受け付けることで構文がわかり難い。
メリットは何度も書きますが、.NETの膨大なクラス群にアクセスして処理を実装できる部分が一番の魅力です。
そのため、バッチ処理として求められる機能の大半はPowerShellのなかで完結します。
例えばC#などの.NETベースのプログラミング言語と類似しているため、若干文法は異なりますが、.NET系の言語で開発経験があれば、比較的容易に習得が可能です。
また、C#の場合はクラスを作って処理することが前提の言語ですが、PowerShellではスクリプト言語やシェルとして側面から、C#よりも柔軟にコードを記述できます。
そのため、習得における難易度もC#やJavaといった純粋なオブジェクト指向的なプログラミング言語と比較した場合は若干低くなっています。
個人的な一番のデメリットは、ps1ファイルで単独実行ができないところです。
PowerShellのコードをテキストファイルにメモ帳などで記述したうえで、そのファイルの拡張子を .ps1 とリネームして保存すると、PowerShellの実行ファイルとして扱われます。
ただし、ps1ファイルはダブルクリックしてもテキストエディタが開いて、なかのコードが表示されるだけで、コードの実行はできません。
GUIベース(マウス)の操作であれば、ps1ファイルを選択→右クリックして「Power Shellで実行」から実行します。
CUIベース(コマンド)の操作であれば、コマンドプロンプトやPowerShell本体を起動して、ps1ファイルのパスを入力して実行します。
また、バッチプログラムを自動実行させる際に、タスクスケジューラーからプログラムの起動する方法は定番ですが、そのタスクスケジューラーからps1ファイルを直接指定しても実行できません。
ps1ファイル実行用のbatファイルなどを作り、タスクスケジューラーからはそのbatファイルを実行対象として登録するようなやり方で設定する必要があり、こちらも結構不便です。
また、実行ポリシーを使用した実行権限の制約があり、PowerShellのコードを実行する場合は、都度実行ポリシーを緩めるなどの処理も併せて実施する必要があります。
この実行ポリシーが適切に指定できていないと、意図せずps1ファイルの実行がブロックされてしまうなどの自体が発生します。
また、コマンドプロンプトのようなシェルであり、オブジェクト指向型プログラミング言語としてのコードも書けることで、コマンドとコードが混在して初学者は混乱するかもしれません。
PowerShellはスクリプト言語であり、コンパイルをしなくても処理を実行できますが、.NETのコマンドレットやクラス名が長いと、Windows標準のメモ帳だけでコードを書いたりコマンドを書き足すのは少し大変です。
よって、batやVBScriptのように、気軽にメモ帳でコードを書くような使い方は難しいと言えます。
因みに、Windows系OSでは、「Windows PowerShell ISE」というPowerShell専用の簡易的なIDE的なツールがPowerShell本体と一緒にインストールされています。
エディタ機能と併せて、シンタックスハイライト機能や入力補完機能や、ステップインデバッグなどができるため、PowerShellでコードを書く場合は、この「Windows PowerShell ISE」を使うか、Microsoftが無償で提供している高機能テキストエディタの「Visual Studio Code(VS Code)」を使うかのどちらかが一般的です。
「PowerShell」に向いているバッチ処理の用途
「PowerShell」で向いているバッチ処理の用途としては以下です。
- 業務システムのDBに接続したデータ更新処理。
- 端末の設定変更コマンドを記述してADのGPOで管理下の端末に配信。
- PCのキッティング作業時の設定作業自動化。
- SaaSのWeb API連携処理。
- JSONやXMLの生成や加工が伴う定例処理。
PowerShellは多機能であり、バッチ処理として求めらる用途の大半は実装できます。
その為、どのような処理でも向いているとも言えますが、Windows標準のスクリプトであるbatやVBScriptと比べると、コードの記述が長くなりがちであり、コードの記述も若干難易度が上がるため、手軽さの観点ではbatやVBScriptの方に分が有ります。
但し、信頼性の高いバッチ処理を実装しようとする場合や、複雑な処理を含むバッチ処理を作る場合は、PowerShellのようにエラー処理が充実していたり、.NETのクラス群を利用できたほうが開発もし易いです。
また、最近ではクラウド型のウェブサービスの利用も広がっており、多くのウェブサービスでは、システム連携用に Web API を公開しています。
その Web API を上手く活用することで、基幹システムとクラウドのウェブシステムとのデータ連携を自動化したり、ウェブシステム側のデータ登録や更新作業を自動化、無人化するなどの効率化が図れます。
このようなWeb APIで受け渡しをするデータ形式ではJSONが使われることも多く、JSONデータの生成や読み込みは前述したVBScript単体ではほぼ不可能なため、Web API とのシステム連携バッチではPowerShellが向いています。
また、JSONだけではなく、XML形式もJSONと同様にデータのやり取りに使われるケースは多く、XMLを扱う場合でもPowerShellの方が実装は楽です。
尚、当ブログでは、PowerShellを利用してJSON形式のデータをパースするやり方を記事も公開しています。
もし興味があればご一読ください。
「Java/C#などの高級コンパイル型言語」の特徴の詳細
業務システムを開発しているシステム開発会社がバッチ処理を開発する場合は、前述したbatやVBScript、PowerShellなど言語ではなく、JavaやC#などのコンパイル型プログラミング言語で作るケースが多いです。
その理由としては以下があります。
- プログラムのソースを顧客が直接閲覧及び編集できなくするため
- スクリプト型言語より処理が高速なため
- システム会社固有のフレームワークを活用し効率よく開発するため
- 複雑な処理を実装しやすいため
- その言語に精通している技術者が多いため
一般的に、システム開発会社が顧客に納品したシステムに対して瑕疵(不具合)が見つかった場合、一定期間の間であれば、それを修正するなどの対応をする義務があります。
ただし、あくまでその義務は、納品されたプログラムを勝手に改変せずに使用していることが前提です。
システム開発会社では、顧客に納品した時点のプログラムソースを保管しているため、PowerShellなどのスクリプト系言語で作られたバッチ処理であっても、顧客が無断でコードを改変すれば、あとからそれは必ずわかります。
ですが、そもそもコードを改変できないexeファイル形式などで顧客に納品しておけば、無用なトラブルを回避できます。
また、コンパイル型のプログラム言語では、プログラマーが書いたコードを、コンピュータが効率よく実行できるように最適化します。
そのため、一般的にはスクリプト型言語で作成した処理よりも高速で動作します。
システム開発会社では、過去の開発プロジェクトで作成した汎用的なプログラム群を再利用して効率よくプログラミングを進めるために、会社独自のフレームワークを利用しているケースも多く、フレームワークを活用するためにコンパイル型の言語を選定することも多いです。
コンパイル型のプログラミング言語は機能も充実しているものも多く、複雑な処理の実装にも充分応えられます。
また、VBScriptではできなかったJSON形式のデータを扱うことも容易です。
また、システム開発会社では、コンパイル型のプログラミング言語を使用して開発することが多く、扱える技術者が多いこともあり、慣れた言語でバッチ処理も作るほうが効率的です。
このように、プログラミングが本業のシステム開発会社の場合は、コンパイル型のプログラミング言語でバッチ処理を作ることのメリットは多いのですが、企業の情シスなど、プログラミングが本業ではない職種の場合は、上にあげたメリットがデメリットにもなり、扱いづらい場合もあります。
「Java/C#などの高級コンパイル型言語」でバッチを作るメリットデメリット
- ソースの改変ができない。
- 処理が高速。
- 言語自体の開発が継続されており、機能が更新されている。
- オブジェクト指向的なプログラム設計が可能。
- 新しいソフトをインストールしなくても実行ファイルが動く。
- その言語を扱える技術者も多い。
- 技術的な習得難易度が高い。
- IDEがなくても作れるが現実的には必須。
- ソース管理が面倒。
- コンパイル前のソースがないと内部処理を確認できない。
メリットについては、前項で記載したシステム開発会社がコンパイル型言語を選択する理由として紹介している内容と類似しています。
尚、C#やJavaなどの主要な高級コンパイル型言語の場合、現在でも積極的に言語自体の機能追加や改善、不具合修正などのサポートが継続されています。
手が加えられ変化していることは、必ずしもメリットばかりとは言い切れませんが、改善活動が継続しているデメリットよりもメリットのほうが大きいです。
また、C#やJavaなどの主要な言語では、オブジェクト指向言語であり、オブジェクト指向に準じた実装が可能です。
コンパイル型言語では、exeファイルなどの実行ファイルを生成します。
C#であれば、.NET Framework(.NET Core)がインストールされていれば動作し、通常のWindows系OSであれば初めからOSに組み込まれています。
よって、新しくソフトをインストールすることなく実行できるのも大きなメリットです。
また、C#やJavaなどは、IT業界のなかでも広く使われていることもあり、扱える技術者が比較的多いプログラミング言語です。
扱える技術者がすぐに見つかることも大事な要素です。
デメリットとして大きい部分は、技術的な習得難易度の高さです。
冒頭で紹介したbatやVBScriptなどと比べると、言語仕様として機能が多く、様々な処理を実装することができますが、その反面、習得するにあって理解しておかないといけない機能も多く、また、オブジェクト指向を意識したプログラミングが求められることから、プログラミング初心者には敷居が高いと言えます。
また、コンパイルしたexe形式などの実行ファイルの場合、テキストエディタで開いても、スクリプト型言語のように実装している処理内容を確認することはできません。
設計書などのドキュメントが適切に残されていなければ、その実行ファイルに実装されている処理は完全にブラックボックスになります。
システムの運用担当者の場合に、状況によっては非常に困るケースもあります。
「Java/C#などの高級コンパイル型言語」に向いているバッチ処理の用途
「Java/C#などの高級コンパイル型言語」で向いているバッチ処理の用途としては以下です。
- 業務システムのDBに接続したデータ更新処理。
- 外部のライブラリを組み込んで実装する処理。
- SaaSのWeb API連携処理。
- JSONやXMLの生成や加工が伴う定例処理。
- 処理速度が重要視される処理。
- 同じ言語で自社フレームワークが流用できる処理。
「PHP/Python/Rubyなどのバックエンド系言語」の特徴の詳細
人によっては意外と感じるかもしれませんが、Webアプリケーションの開発で使われるバックエンド系の言語もバッチ処理として利用できます。
Webアプリケーションの開発では、一般的に「フロントエンド系言語」と「バックエンド系言語」が使われます。
「フロントエンド系言語」では、HTML、CSS、JavaScriptなどを使用し、ウェブページの描写やページ内での制御などブラウザ上での処理を担当します。
「バックエンド系言語」では、PHP、Ruby、Python、Perlなどのスクリプト系言語を使用する場合と、JavaやC#などのコンパイル系言語を使用する場合があります。
主な役割は、ブラウザなどから送られてきたWebリクエストを受け取り、データベースなどにアクセスしながら動的なHTMLを生成してブラウザに返したり、データをレスポンスとして返します。
バックエンド系言語のなかでも、コンパイル系言語であれば、前項で紹介したようにバッチ処理としても使えることはわかりますが、スクリプト系言語については、あまりバッチ処理として使うイメージがないかもしれません。
実は、非コンパイル型のバックエンド系言語で書いた処理をApacheなどのウェブサーバーからではなく、サーバー内の実行環境から直接実行してあげることで、一般的なバッチ処理としても利用することが可能です。
「PHP/Python/Rubyなどのバックエンド系言語」でバッチを作るメリットデメリット
- Webサーバー上で新しく実行環境をインストールしなくても使用できる。
- Webアプリケーション開発と同じ言語で開発できる。
- 言語自体の開発が継続されており、機能が更新されている。
- スクリプト系言語であれば、ソースをテキストエディタで開いて参照や編集が容易。
- その言語を扱える技術者も多い。
- Webアプリケーションの開発言語に依存する。
- コンパイル型言語と比較すると処理は遅い。
- 容易にソースの参照や編集ができてしまう。
- 使える環境が限定的。
メリットとして一番大きいのは、Webアプリケーションを稼働させるWebサーバー上で、バッチ用の実行環境を用意しなくてもバッチ処理を実行できるところです。
例えば、Windows Serverの場合は元々batやVBScript(WHS)、PowerShellが最初から有効化されて使用できる状態になっていますが、Linux系OSの既定で使用できるスクリプトは「シェルスクリプト」です。
これはWindowsにおけるbatのようなもので、複雑な処理を自動化するには不向きです。
また、LinuxのディストリビューションやOSインストール時の設定によっては、初めからPythonなどの環境がインストールされていたりもしますが、一般的にはWebアプリケーションで使用する予定の言語の実行環境だけをインストールしたり有効化しておきます。
例えば、PHPを使ってWebアプリケーションを開発する場合、バッチ処理目的に他の言語の実行環境をインストールすることはあまりありません。
PHPが動く環境があるなら、それを活かしてバッチ処理も作る方が無駄がありません。
また、サーバー上に不必要に異なる言語の実行環境をインストールして意図しない不具合を起こしたりするリスクも防げます。
よってこのメリットは、LinuxOS上でWebアプリケーションを動かしているサーバー上にバッチ処理を実装する場合に特に有効です。
また、デメリットとしては、Webアプリケーションの開発で使用している言語に合わせるという制約から、好きな言語を選択できなくなるという部分があります。
あと、スクリプト型の言語では、コンパイル型の言語で生成した実行ファイルと異なり、コードの最適化がされないことで、一般的には処理が遅くなると言われます。
あとは、WindowsServerなどのOSでは、既定でこれらの言語の実行環境は入っていません。
また、Windows 11 などのクライアント向けOSでも同様であり、これらの言語でバッチ処理を作っても、その実行環境も併せて作らないと動作はしません。
その意味で汎用的ではなく、手軽でもありません。
「PHP/Python/Rubyなどのバックエンド系言語」に向いているバッチ処理の用途
「PHP/Python/Rubyなどのバックエンド系言語」で向いているバッチ処理の用途としては以下です。
- Webアプリケーションが動作するLinuxサーバー上で実行する処理全般。
Webアプリケーションを動かしているLinux製のWebサーバーであれば、必要となったバッチ処理の全てはWebアプリケーションのバックエンドで使っている言語で作ってしまって問題ないかと思います。
そうすることで、Webアプリケーションのバックエンド処理とバッチ処理の両方でコードを共有することも可能です。
「ストアドプロシージャ」の特徴の詳細
「ストアドプロシージャ」とは、RDBMSの製品ごとに標準的なSQLの仕様を拡張し、IFなどの条件分岐や繰り返し処理を組み込むことができ、複雑な分岐を伴うデータ更新などの処理を作ることができる機能です。
当ブログでは、データベースに関する基礎知識を紹介する記事のなかで、ストアドプロシージャに付いても特徴を簡単にまとめています。
また、具体的なストアドプロシージャの作り方についても記事にしているため、良ければご一読ください。
ストアドプロシージャはデータベースのなかでしか動かせないため、データベースに対する処理しか作れませんが、業務システムで必要になるバッチ処理の多くは、データベースと接続してデータの追加や更新を行います。
よって、業務システムで必要になるバッチ処理であれば、ストアドプロシージャの機能のなかで十分に要件を満たせるケースが多いと言えます。
また、上記のリンク先にあるストアドプロシージャの特徴でも解説していますが、ストアドプロシージャはデータベース上で動作し、ネットワークを介さないため、ネットワークの通信速度がボトルネックになって遅延することがありません。
また、RDBMSに割り当てたメモリー上で動作をすることで非常に高速に処理を実行できます。
ストアドプロシージャはRDBMSで用意されているスケジューラー機能から処理を呼び出して定時実行させることもできますし、異なる他のプログラミング言語で作成した処理から呼び出して実行させることも可能です。
「ストアドプロシージャ」でバッチを作るメリットデメリット
- データベースに対する処理の高速化。
- RDBMSの機能のなかで実装可能。
- 異なる言語の処理と容易に呼び出しが可能。
- データベースに対する処理しかできない。
- 数が増えると管理が煩雑になる。
- デバッグの機能がなかったり十分ではない。
ストアドプロシージャでバッチ処理を作る最も大きなメリットは、データベースへの複雑な更新処理を高速に実行できる部分です。
前述した通り、ストアドプロシージャでは自データベース内に登録し、自データベースに対しての分岐などを伴う複雑な処理を一つのプログラムとして実行できます。
ネットワークを介さないことで通信経路による遅延が発生せず、また、オンメモリーで実行されて実行速度も速いのが大きな特徴です。
例えば、バッチ処理を前述したPowerShellやVBScript、C#などの言語で作成して実行させていたが、データベースに対する処理に時間が掛かり、それをもっと改善したい場合などは、ストアドプロシージャで作り替えるような対応が最適です。
元のバッチ処理の作りによっては、実行速度が劇的に改善されます。
また、ストアドプロシージャはRDBMSの機能の一つであり、作成したストアドプロシージャを動かすために追加で実行環境をインストールする必要はありません。
業務システムでは、必ず何らかのRDBMSを使用しているため、業務システムで使用するバッチ処理の実装にストアドプロシージャは最適です。
ストアドプロシージャはRDBMSに登録し、RDBMSから実行することももちろん可能ですが、他のプログラミング言語で作成した処理からも呼び出して実行することが可能です。
尚、当ブログではVBAからADOを使用してストアドプロシージャを呼び出す方法を記事で紹介しています。
良ければこちらもご一読ください。
この記事で紹介したVBA以外の言語であっても、呼び出し方は概ね同じです。
デメリットについては、当然ですがストアドプロシージャはデータベースに対する処理しかできないところです。
例えば、ストアドプロシージャを使用してWebSocketを生成し、Webの通信の仕組みを利用してWebメソッドを実行してPOSTするといった処理を作ることはできません。
このように、実装できる処理は限定されています。
また、ストアドプロシージャはRDBMS内に登録して使用します。
ストアドプロシージャを多用している環境では、RDBMS内に大量のストアドプロシージャが登録されていくことになりますが、システム開発会社などで使用しているソースコード変更管理システム内に組み込んで変更履歴を管理することが難しく、何らかの効率的ではない変更管理が必要になります。
また、各RDBMSごとにストアドプロシージャを作成する機能が用意されていますが、他の言語であれば一般的なIDEで用意されているステップインデバッグ機能が提供されていないケースが多く、複雑な処理を実装しようとした場合は、デバッグが面倒になります。
「ストアドプロシージャ」に向いているバッチ処理の用途
「ストアドプロシージャ」で向いているバッチ処理の用途としては以下です。
- 業務系システムがデータベースに対して行う処理全般。
- データベースに対して行っている処理の速度改善対応。
- 業務システムで実行している処理の共通化。
業務系システムで非同期処理を実装する場合の多くでストアドプロシージャは効果的に利用できます。
また、同じく業務系システムで実行しているバッチ処理に対して、処理時間の短縮が求められるような場合は、既存のバッチ処理をストアドプロシージャに作り替えることで劇的に処理時間が軽減できる場合も多く有効です。
また、業務システムのクライアントアプリケーションがオンラインで実行している処理をバッチ処理でも実行させたい場合では、RDBMS内にオンライン処理とバッチ処理の両方で利用するストアドプロシージャを作ることで、処理を共有化することができます。
そうすることで、処理内容に修正が必要になった場合も、オンライン処理とバッチ処理の両方で共有しているストアドプロシージャを修正すれば対応が済むようになります。
最後に
今回の記事では、「バッチ処理」について幅広く解説してみました。
プログラミングやアプリケーション開発と言えば、何らかの画面やフォームを持つプログラムを作るイメージが強いのですが、今回紹介したバッチ処理もとても大事な要素です。
今回の記事を参考にして、貴方が業務システムの設計で適切なバッチ処理の方式設計をする際の検討時の手助けになったり、社内SEとして自社の業務を効率化したり自動化するための方法を選定する手助けになれば幸いです。
今回も長々とした記事を読んでいただきありがとうございました。
それでは皆さまご機嫌よう！
