複数のソフトウェア製品からなるMicrosoft System Centerですが、その中に「System Center Orchestrator(オーケストレーター)」というソフトウェア製品があり、一般的にはそのままOrchestratorとかSCOと略して呼ばれます。
この「Orchestrator」という言葉自体は、Microsoft社以外のソフトウェアベンダーでも製品名称として使われており、狭義には所謂インフラの作業の「自動化」を目的とした製品に対して使われていることが多いです。
本記事ではSystem Center Orchestratorを指してOrchestratorという言葉を使います。
そもそもこの製品をご存じではない方は、ITProさんの記事がよくまとめられておりますので、「OrchestratorによるITプロセスの自動化」をご参照下さい。
さて、Orchestratorに関してよくいただく質問のひとつに「これでジョブスケジューラを置き換えできる？」があります。この質問が良く出る理由は、多くのOrchestratorの紹介画面がジョブスケジューラと似ていること、「自動化」というキーワードが共通していることがあります。
この記事ではこのわかりにくい「ジョブスケジューラとOrchestratorの違い」に関してREALTECH独自の現場視点で今回書いてみたいと思います。
ジョブスケジューラとOrchestratorの役割分け
まず、ジョブスケジューラと同じことをOrchestratorで行うことも、その逆も、「技術的には」可能です。ただジョブスケジューラとOrchestratorは特性が大きく違います。その特性を理解していれば、ジョブスケジューラをOrchestratorで置き換えることができる場面は少ないと言えます。
ジョブスケジューラの役割
JP1など何らかのジョブスケジューラを既に導入済みという現場は多いかと思います。まずは馴染みの深いであろうジョブスケジューラから見ていきます。ジョブスケジューラの主な役割は、MRPや伝票の集計といった業務の処理をスケジュール通りに前後関係を持って実行するような「業務の自動化」です。この「業務の自動化」で最も重要な部分は処理が意図通りのスケジュールで動いてくれることにあると考えます。例えば、現場では以下のような要件が出てくることがあります。
「本社稼働日カレンダーの稼働日で、かつ、拠点Aカレンダーの月の最終営業日から3営業日前で、かつ月次の○○処理が走らない時にこの処理を流してください」
上記のような要件に容易に無理なく対応できるような柔軟性の高いスケジュール機能を持っているのが良いジョブスケジューラの一つの条件です。
一方、System Center Orchestratorで上記の要件に対応できるかと言うと、技術的にはできないことは無いのですが、かなり複雑な設定が必要になってしまいます。上記の1つの要件のでも複雑なので、これが１０個、１００個とジョブが増えると運用不可能なほどの複雑設定になってきます。System Center Orchestratorはスケジュールの柔軟性という点ではジョブスケジューラと比較すると苦手です。
Orchestratorの役割
次にOrchestratorについて考えてみます。上記で「業務の自動化」という言葉を使いましたが、Orchestratorの主な役割は「運用の自動化」です。先程と同じように例として、運用現場で自動化を行うとしてありそうな要件を一つ挙げながら「運用の自動化」を通してOrchestratorの役割に関して考えてみます。
「バックアップ処理を起動して、もしバックアップが失敗したら、エラーを検知して、ログファイルを確認して、ファイルから該当のエラーメッセージを抽出し、メールに記載して送信してください」
「運用の自動化」でありそうな要件だと思います。バックアップからログファイル、メール送信まで様々なコンポーネントが出てきました。このように運用の現場では、一つシステムが増えると、その基盤となるデータベースやOS、H/Wまで全てが運用担当者の管理対象として追加されてきます。結果として、運用担当者が管理しなければいけない対象は芋づる式に増える一方です。
更に、IT運用予算は削減が強く求められることが多いので、運用担当者は少ない人数で、昔から動き続けているシステムから、新技術を使って導入された新しいシステムまで様々なシステムを管理しなければなりません。このような中、新しく人を入れても教育が追いつかず属人化が進み、１人または少数の担当者に業務が偏っていくことがあります。
少ない人数で多くの対象を管理していくには、手動で管理作業をしていたのでは、いくら時間があっても足りません。そこで自動化が必要になってくるのですが、多種多様な管理対象がある運用の現場で業務を自動化する際に便利なのがスクリプトです。どこのシステムでも何らかのスクリプトが動いているはずです。
このスクリプトですが、実際はジョブスケジューラでスクリプトを起動する形で運用業務を自動化している事例を多く見ます。「運用の自動化」におけるジョブスケジューラの役割は、あくまで主役であるスクリプトを起動するための補佐的役割にあると言えます。
このように「運用の自動化」で使われるスクリプトですが、作成してしまえば、確かに運用業務は楽になります。しかし、元々は属人化で集中してしまった業務を楽にするために作成したスクリプトは、実は別の形で属人化を招くことになる危険性も持っています。
スクリプトを使った「運用の自動化」が動き始めると、いつか担当者（作成者）がいなくなったとしてもスクリプトは動き続けます。そして自動化している処理に異常が発生した際に、スクリプトを書いた人が既に現場におらず、だれも対応できない状態になっていたりすることがあります。それでも問題に気付けば良いのですが、自動化した処理が異常になっていても誰も気付かないでいることすらあります。
Orchestratorの役割の一つは、このような「運用の自動化」に利用されているスクリプトを置き換え、スクリプトでは足りなかった部分、実装が難しかった部分から起こる課題を解決するための機能が備わっています。その機能とはパッケージによる機能拡張、処理の集中管理・可視化、再利用可能なコンポーネント化などになります。このあたりは今後のBlog記事で記載していきたいと思います。
