運用自動化ツールとは? 2022年版(6年の時を経て再考)

2022年9月27日

ワイドテック プロダクト企画のYです。

のん(本名・能年玲奈)主演の映画「さかなのこ」を見てきました。魚類に詳しいタレントとしてお茶の間に登場し、絶滅したとされていた幻の魚「クニマス」を再発見、今は東京海洋大学の客員教授、魚類学者でもある「さかなクン」の自伝が原作です。「じぇじぇじぇ」ののんが「ギョギョギョ」のさかなクンを演じているこの作品は「男か女かはどっちでもいい」で始まり、多様性がテーマでもあります。

そういえば、自分ことYが弊社に転職入社したのはその「じぇじぇじぇ」が生まれた、2013年度上期のNHK朝ドラ「あまちゃん」が始まろうとしていた直前の頃でした。「さかなのこ」にも、「あまちゃん」へのオマージュと思われるシーンがあります。

映画を見て、いろいろ懐かしい想いにも浸っていたところで、マーケティング部から「古いコラムのリメイク」を依頼されました。1月にも「自動化の手順書はどう作るか?2022」というのを書きましたが、今回は「運用自動化ツールって何?」の2022年最新バージョンとなります。

6年の時を経て、運用自動化のマーケットやツールがどのように変化を遂げているのか、その遷移を辿りながら、「結局のところ運用自動化とは何?」について考えてみたいと思います。


■運用自動化ツールをめぐる状況 – 2016年と2022年

POLESTAR Automationの公式サイトが対外公開されたのは、2016年10月1日のことです。この10月1日で6周年になります
当時、掲載したコラムの中でも、今もアクセスが特に多いのが、冒頭で述べた「運用自動化ツールって何?」です。運用自動化ツールのジャンル分けや、運用自動化における永遠の命題といえる「エージェントvs.エージェントレス」について、当時の市場状況を前提にご紹介した記事でした。

エージェントvs.エージェントレスについては、当時のPOLESTAR Automationにはエージェントのインストールが必須だったので、一方的にエージェントを勧めるものとなっており、弊社として現在とはやや異なる見解も含まれています。

そもそも「運用自動化ツール」というカテゴライズには、当時も今も曖昧なところがあります。「運用の自動化」と軽々しく語りつつ、果たしてサーバーやネットワークの運用をどのように自動化するのか、実はPOLESTAR Automationの国内導入を担当した自分も、おぼろげにしかイメージできていなかったところがありました。


■RBAとRPA

世間の認識についても、弊社が「エンタープライズRBA(Run Book Automation)」を掲げてPOLESTAR Automation事業をスタートしてからわずか数ヶ月で、「RPA(Robotic Process Automation)」が突如バズりはじめたこともあり、大いに混乱を来すことになりました。

RPAは主にオフィス業務において、GUIツールを用いて行う煩雑な作業、例えば検索を伴う大量の入力のような業務の自動化を目的とするもので、「手順書(Run BookないしはRunbook)」に従ってスクリプトを用い運用業務の自動化を図るRBA(ここで扱う「運用自動化ツール」)は、実現方法・技術的には似通った部分がなくもないのですが、対象を全く異にするソリューションです。
しかし、用語が似すぎていて(しかも後から出てきたのはRPAの方です)、今なお展示会等で「自動化」の看板を目にした来場者の方から、「これはRPAですか?」という質問を受けることが少なくないです。

こういうことがあるので、現在はPOLESTAR Automationのマーケティングに「RBA」という用語は使用していません。他社も含む業界全体で、RBAという用語がほとんど使われなくなったのは、RPAの登場による混同回避の目的が大きいかもしれません。

あと、RPAとの混同は、運用自動化ツールに過度な期待や幻想が生じる原因にもなっていると思います。Robotics(ロボット工学)の略字を含み、「ソフトウェアロボット」とも喧伝されたRPAの中には、実際に作業内容の学習などにAIを導入したものがありますし、RBAの側にも、まるでAIのような高度なインテリジェンスをもって、運用業務を自動化できるかのように謳っていたものがありました。
もちろん、実態はそんな甘い世界ではありません。
どの運用自動化ツールでも、既存の業務に定型化された手順、ないしは手順書に落とせることが、自動化の前提となります。


■「運用自動化」と「構成管理」

2016年当時、ITインフラ業界でもあまり使われていなかったタームとして「構成管理」があります。弊社でも、POLESTAR Automationのマーケティング活動において「構成管理」という用語を盛んに使用しはじめたのは、2019年になってからでした。今ではPOLESTAR Automationを称して「構成管理ツール」と紹介することも、少なくありません。

ITインフラ運用における構成管理とは、多数のハードウェア、ソフトウェアからなるITインフラの「構成」を「管理」することです。対象となるハードウェアにはサーバーやネットワーク機器、ソフトウェアにはOS、ミドルウェア、アプリケーションなどの構成要素が含まれます。

それぞれの構成要素にはベンダー、型番、OSやファームウェアのバージョン、コンフィグ(ファイルなどの形で存在する設定情報)、あとユーザーといった付帯情報が存在し、型番やバージョン情報などは、サポート期限(EOL/EOS)とも紐づけて管理されるべき情報です。 ソフトウェアはもちろん、ハードウェアのファームウェアなども含めた最新化、つまりバージョンアップ作業も構成管理業務に含まれるでしょう。
EOL/EOS管理などは構成管理ではなく「資産管理」の範疇に含まれるとも考えられますが、資産管理ツールには情報収集機能がないものもあり、最新情報の取得は構成管理ツールで行うことも多いでしょう。

これらITインフラの「構成」を「管理」すること、つまり最新の構成情報を日々更新し、常に最新の構成を把握可能にしておくことこそ、「構成管理」というわけです。

しかし、「構成管理ツール」=「運用自動化ツール」ではありません。
例えば定型的な作業手順(POLESTAR Automationでいう「ジョブ」)の作成と実行、障害復旧などは運用自動化ツールでカバーしている領域ですが、構成管理業務そのものではありません。ただし、障害の復旧には、構成情報の最新化が役立つことでしょう。 POLESTAR Automationは「構成管理ツール」でもあり、広く「運用自動化ツール」でもある、ということです。


■「外部ツールとの連携」も運用自動化ツールの重要な要素に

あと、2016年の記事を書いた時点で考慮していなかったのは、外部ツール、特に運用管理製品で最も大きなウェイトを占める監視(モニタリング)ツールとの連携です。
当時から、同一ベンダー、同一ブランドでシリーズ化された運用管理製品群の中に、監視、ジョブ管理、資産管理、自動化などが存在している例はありました。特に国内の先行ベンダーの製品は、そのような百貨店的な品揃えを、今でも売り物にしているといえます。

弊社は規模の小さな会社であり、運用管理製品のすべて、全ジャンルをシリーズ化できるほどの体力はありません。しかし、ソリューションとしてある程度の提案力は備えておきたいと考えました。
そこで、POLESTAR Automationの開発元であるNkia社に外部連携のためのAPI開発を提案し、並行しておそらく国内で最もユーザー数が多く、社内でも従来より利用経験の多かったオープンソースの監視ツール「Zabbix」との連携を図り、監視ツールであるZabbixの担う障害の発見から、POLESTAR Automationによるその後の回復処理までを一気通貫で行うソリューションを完成させました。
これにより、POLESTAR Automationに新たな価値を提供し、弊社自身にとっての「運用自動化ツール」の定義を書き加えることにもつながりました。


■オープンソースの運用自動化ツール

弊社が営業やマーケティング活動においてベンチマーキングの対象とする競合製品にも、2016年当時と2022年現在では、変化が見られます。

前述の「まるでAIのような高度なインテリジェンスをもって、運用業務を自動化できるかのように謳っていた」製品は、国内市場からはほぼ撤退してしまいましたし、他にも外資を中心に、いくつかの競合ベンダーが撤退、ないしは営業を縮小しています。
代わりに勢力を伸ばしてきたのが、オープンソースの運用自動化ツールです。監視分野でZabbixが国内トップシェアであるのと同様に、運用自動化もサポートがいらない範囲ならオープンソースで済ませてしまおう、という流れが明確になってきている気がします。

オープンソースの運用自動化ツールを使うメリットは、ソフトウェア本体が無料であるのに加え、ユーザーによって作成されたテンプレート(POLESTAR Automationでいうところのジョブ)の充実度が挙げられます。これがやりたい、と思い立ったら、大抵のものはネットを検索すれば見つけられます。
しかし、オープンソースの運用自動化ツールは、CLI(またはCUI、要はコマンドラインのコンソール)で操作するものが大半です。要はCLIでの運用作業に支障のない、ある程度のスキルを保有している人が対象といえます。近年はGUIも徐々に整ってきていますが、CLIのランチャーのような機能が中心です。

プロプライエタリな商用ソフトウェアであるPOLESTAR Automationは、最初からGUIでの利用を主体として開発しており、ジョブ作成から実行まで、大半の作業をGUI上で完結させることが可能です。そこがオープンソースとの重要な差別化ポイントと、弊社では考えています。


■パブリッククラウドとハイブリッドクラウド

他に、当時と異なるのはクラウド、特にパブリッククラウドの利用が増えてきたことでしょう。既に2010年代の前半から、多くのWeb系サービスはパブリッククラウド上で動いていましたが、社内システムのような外部に出さないものまでパブリッククラウドに置くようになったのは、日本では比較的最近の話といえるでしょう。

大抵のパブリッククラウドには、運用自動化や構成管理の機能が標準で用意されていて、管理対象がパブリッククラウドだけなら、そういうビルトインツールでカバーできると思います。
しかし、日本企業の社内システムにおけるクラウド活用については、海外のように何でもかんでもクラウドに置く、という文化は浸透することなく、主にセキュリティを理由に一部はオンプレミスに残したまま、クラウドに移せるものだけを移す「ハイブリッドクラウド」が、最初から主流として始まったといえます。

海外でも近年、クラウドからオンプレへの撚り戻し現象が起きていて、やはりハイブリッドクラウドがトレンドなのですが、過程を異にしながら、同じ状況になっているのは興味深いです。
POLESTAR Automationでも時流に乗り、この1年ほどで主要パブリッククラウドのクレデンシャル管理、AWSインスタンス管理などクラウド関連機能を強化してきているところです。
ハイブリッドや複数クラウドを併用するマルチクラウド環境の運用には、特定のパブリッククラウドに紐づかない運用自動化・構成管理ツール、つまりPOLESTAR Automationのようなツールこそが最適といえます。


■結局のところ「運用自動化」ってなんだろう?

さて、肝心な「運用自動化ツールとは何なのか」、運用自動化ツールで一体何をするのか、という話が最後になってしまいました。

運用自動化ツールの対象領域として、今は構成管理が重要になってきていますが、サーバーの構築(OS、ミドルウェアからアプリケーションの導入までの、いわゆる「デプロイ」)に始まり、ソフトウェアアップデートやパッチの適用、障害対応と幅広いです。
これらは、言ってしまえば運用のエキスパートが、スクリプトなどを駆使して手作業で実現可能なものばかりです。しかし、その実現や日常的な運用には、高度な練度が求められることになります。作業内容も対象のハードウェア・ソフトウェアやそのバージョンによって異なるので、スクリプトも毎回同じというわけには行かず、手直しが必要になります。

そこに、特定の業務が特定の人物に紐付いてしまう「属人化」が発生します。属人化の弊害については、このコラムや本サイトのさまざまなコンテンツを通じて繰り返してきた通りです。
属人化の排除、つまり熟練者の作業をツールに落とし込み、練度の高くない作業者でも日常的な運用作業を可能とすることこそ、6年前も今も、運用自動化ツールの最も基本的かつ重要なミッションでしょう。
しかし、属人化排除を謳いつつ、その活用にはそれなりのスキルが求められるものも少なくありません。CLIに大きく依存するツールなどは、新たな属人化を生んでいるようにも思います。


運用自動化ツールとは何か?
それは、ITインフラ運用における「属人化排除ツール」だと考えています。