ITコンサルタント美咲いずみが行く

第19回　進化する運用管理ツール(2)～運用管理ツール、運用自動化

2016年1月19日掲載

「全体像が分かる」ということ

 埼玉県にある従業員約280人のEMS（Electronics Manufacturing Service）企業、YMC電子工業（仮名、以下YMC）。同社の顧問ITコンサルタントである美咲いずみ（仮名）は、週はじめのシステム部門の定例ミーティングに参加した後、同社の山田昭（仮名）CIO兼システム部長の相談を受けるという形態のコンサルティングをしている。

今回は、定例ミーティングの途中で人為ミスによる重大インシデントが発生した。このところ人為ミスが多いので「これは仕組みやルールに問題があるかもしれない」と、運用担当の宮下（仮名）を入れた3人での、ミーティング後のコンサルティング・セッションとなったのである。

休憩が終わり、いずみが切り出した。

「休憩前の話を簡単におさらいします。クラウドもモバイルも、そして運用の自動化も高度化・複雑化するシステムに対応したもので、だからこそいきなり取りつこうとしても難しいのです。先ほどお話したように、1990年代には基本的な運用機能、2000年代にはITのサービス化支援機能が取り入れられ、2010年代になってこれらの機能が付け加えられたということが分かるだけでも、運用ツールを調べるときに楽になります」

「確かに全体像が見えました。90年代に実装された機能は必須、00年代のものはどちらかというと運用そのものを支援する機能、さらに10年代のものは最新なので『難しい』と分かるだけでも比較検討しやすくなったと思います」

「何だ？ その『難しい』というのは？」と山田が笑いながら聞く。

すると宮下は明るい顔で、こう言うのだ。「正直に言いますと、何から何まで全部が難しく感じていたのです。しかし、こうしてみると難しい部分は2010年代に取り入れられた最新機能のところだと分かりました。それってごく一部なので、すごく気が楽になったのです。勉強しないといけないのがどこかも、はっきり分かりましたしね」

「全体像を捉えるというのは、そういうことなんです。自分が全体の中のどこを分からないのかが明確になれば、次に何をしたらいいのかはっきりします」といずみが付け加えた。

「運用自動化」とは

「それでは『運用自動化』についてご説明いたします。運用管理ツールのベンダーによっては『ランブックオートメーション』や『オーケストレーター』と呼ぶこともあります」

「『ランブック』は聞いたことがあるな。『操作指示書』とでも言うのかな？」と山田が反応する。

「はい。そのとおりです。操作指示のような従来は人間の解釈が必要だったことを、できるだけコンピューター上で自動的に実行しようというのが『運用自動化』です。そのほうが人的ミスは激減しますからね」

「『オーケストレーション』というのは、オーケストラと関係あるんですか？」と宮下が質問する。

「はい。元々は音楽用語ですね。日本語にすれば『管弦楽法』です。ICT用語として使うときは、データセンターにあるサーバー、ストレージ、ネットワークなどをまるでオーケストラを管理するように取りまとめるというイメージです。楽器の奏者はそれぞれ自律的に演奏するのですが、指揮者はそれを上手に取りまとめるでしょう？ そういう比喩です」

「なるほど。なんとなくイメージはできるね。しかし手順をまとめるだけなら、ジョブスケジュールと変わらない気もする。どこが違うのだろう。より高度だというのは伝わってくるのだけど」と山田。

「そうですね。大きく2つあると思います」といずみは答えた。

ワークフローの取り込み

「1つは、ワークフローが取り込めるようになったということです」

「ワークフローというと稟議や出張申請などで使うあれですか？」と宮下が聞いた。

「まさにそれです。例えば、障害が発生したときにサーバーの再起動が必要になるケースがあります。しかし、担当者の判断で勝手に実行してはいけない場面もありますよね？」

「はい。よくあります」

「そのようなときに、上司に判断を仰ぐメールなどが送信されると便利ですよね？ 今の運用管理ツールでは、そのような手順を定義する機能を持っているものがあります」

「それは助かる！」と山田と宮下が同時に言い、顔を見合わせて笑った。

GUIとテンプレートで運用業務を可視化

「もう1つは、GUIとテンプレートで運用業務を可視化していることです。これらの機能はこの2、3年でかなり充実してきました」

「それは、ジョブスケジューラーも一緒では？」と宮下が疑問を口にする。

「はい。しかし、もっと高度なんです。例えば、プライベートクラウド内で仮想サーバーを作成する作業だとゲストOSを起動したあと、どんなアプリケーションを導入するかで作業の流れが分岐しますよね？ また、それらが完了した後、万が一確認で失敗したら、関係者に連絡しないといけませんよね。成功したとしても実際にリリースする前には上長の承認が必要かもしれません。このような流れをGUIですべて定義できます」

「ほう」山田が驚嘆の声を上げた。

「さらに良いのは、こういった複雑な作業のテンプレートが準備されているということです。ベンダーによって提供の仕方は若干違って、標準テンプレートとカスタマイズのためのマニュアルを用意しているベンダーもあれば、簡易テンプレートを実務に使えるようにするガイダンス（ウイザード）を用意しているベンダーもあります。また、運用管理ベンダーとして実際の業務に使用しているテンプレート集を提供しているベンダーもあります」

「なるほど。ある意味ノウハウごと販売しているという感じなんですね」

「そうとも言えますね」

PaaS標準仕様の採用でマルチベンダーも

「しかし、そのような高度な機能が提供されるとなると、ベンダーロックインに陥る怖れもあるのではないかな？」と山田が聞く。

ベンダーロックインとは、特定のベンダーに囲い込まれて離れられなくなることだ。何でもワンストップで解決してもらえるというメリットもあるが、競争原理が働かないため低価格化や納期の前倒し要求が難しいなどのデメリットもある。

「そうですね。マルチベンダーを視野に入れておくことは重要なことだと思います。そのためにPaaS標準仕様というものがあります。Webサービスなどの標準化団体OASISが策定したTOSCA（Topology and Orchestration Specification for Cloud Applications）が有名です」

例えばTOSCAを採用している運用管理ツールであれば、ベンダーに関係なく、それらを適切に連携させることが可能となるということである。

アプリケーションのレベル分けをしないとコスト高に

「うーん。そこまでできるとは進歩しているんだなあ。だけど、何でもかんでもそんなに高度な管理をしたら、かえってコスト高になるんじゃないだろうか？」と山田が言う。

「おっしゃるとおりです。例えば、ミッションクリティカル（24時間365日の稼働が求められるということ）で、万が一故障しても1時間以内に復旧しないといけないようなアプリケーションは変更承認レベルも高いし、監視項目も多数あります。それを完全に自動化しようとしたら、かなりの高機能な運用管理ツールが必要ですし、また自動化のための準備にかかるコストも膨大になります」

「それはそうですね」と宮下も分かったようだ。

「なので、アプリケーションを求められる信頼性のレベルで、例えば松竹梅のような3段階でもいいので分類して、それぞれにどこまでどのような自動化をするのかを定義する必要があるのです」

「あまり人手をかけなくてよいアプリケーションに対しては自動化を推し進め、重要度の高いアプリケーションについては今までのように人手をかけるという感じにすみわけするんですね」と宮下。

「そうです。そのほかにも、梅であればOSS（オープンソース）の無償ツールで対応し、竹であれば商用ツール、松は運用専門ベンダーにアウトソーシングするという考え方もあります」

「どちらにしろ、そのような切り分けを早い段階でやるべきなんだね」と山田。

「はい。それこそ、運用専門のコンサルタントの手を借りてでもです」

「分かった。それも検討しよう」

ここで一区切りついたので、もう一度休憩することになった。

［ITブレークスルー代表　森川　滋之　記］