<img src="/wp-content/uploads/img/polestar_logo_03_mono.png" alt="POLESTAR Automation">

一覧へ

運用自動化ツールとは？ 2022年版（6年の時を経て再考）

公開日:2022/09/27 更新日:2025/04/01

ワイドテックプロダクト企画の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インフラ運用における「属人化排除ツール」だと考えています。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

情シスの課題「繰り返し」「手間がかかる」を運用自動化で実現

公開日:2022/09/22 更新日:2025/04/01

一覧へ

新サービス「Widefone」と運用自動化・構成管理

公開日:2022/08/16 更新日:2025/04/01

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

本コラムで予告（「「XaaS」はどこまで自動化できるか」2022年2月15日公開・「弊社草創期からの事業「電話」について」2022年3月15日公開）してきた、弊社の電話関連新プロジェクト「Project C」が、この8月1日から「Widefone（ワイドフォン）」の名で、先行サービスを開始しました。

実はこのプロジェクトについては、3月15日公開の社内報のような（！）コラムの脱稿直後に大きな方針転換があり、スケジュールやサービス内容も大幅に変更されました。以来、社内唯ひとりの企画職としてのいくつもの定例・臨時会議参席と本コラムの執筆を除き、ほとんどWidefoneのサービス立ち上げに稼働を割いている状況で、これから来年の春ぐらいまでの行動予定が、ほぼ埋まってしまっています。

映画も6月初めにトム・クルーズ主演の大ヒット作「トップガンマーヴェリック」（もう2か月以上やっていますが、今もかなりのお客さんが入っていますね。やっているうちに特殊上映でもう一度見たい）を見に行って以来、一度も行けていません。別に、劇場に行く時間が作れなかったわけじゃないんですけどね…

■IP通信技術を用いた音声サービス「Widefone」

WidefoneはVoIP(Voice over Internet Protocol)、つまりIP通信技術を用いた音声サービスです。
PBX（構内電話交換機）をIP化・クラウド化した「クラウドPBX」を基盤とし、「050」で始まる電話番号で提供される外線通話可能なIP電話と、社内の範囲（テレワーク中でも可）でのみ通話できる内線通話の提供を基本に、さまざまなコミュニケーションサービスを展開して行こうというプラットフォームで、1つではなく、内容の異なる複数のサービスをリリースする計画です。

8月1日からWidefone初のサービスとして先行提供を開始したのは、最もベーシックな音声専用サービス商品「Widefone CV（CVはCloud Voiceの略）」で、「1ユーザーにつき1つの外線（050電話番号）、1つの内線」「初期費用も月額基本料も900円（税別）」という、シンプルさとわかりやすさにこだわっています。

会社で加入し、私用のスマホに入れていただくと、私用番号とWidefoneの社用番号の使い分けができ、社用番号の請求は会社に回せ、Widefoneどうしの通話も無料になります。

■Project CからWidefoneへ

…と、Widefoneのご紹介はここまでにしておきますが、Widefoneとネーミングされる前の当初のProject Cは、サービス基盤からクライアントアプリまで完全自社開発とし、電話をはじめ、ビデオ会議（Web会議）やチャットを含む多彩なコミュニケーション機能を、単一の基盤で提供する「UCaaS(Unified Communication as a Service)」を最初にローンチする予定にしていました。
3月前半までの時点では、まずは夏から秋にかけ、このUCaaSだけの単体でサービスを立ち上げ、応用・派生サービスは来年以降に考えよう、ということになっていたのです。

しかし、新サービスはもちろん、弊社の既存電話系SaaSでも利用中の「050」IP電話番号について、番号の仕入れ方法を変更することになり、番号仕入れ用のシステム開発が割り込んできたのです。その結果、Widefoneに先立つ形で「IP電話サービス[050]」という名のIP電話番号バルク販売事業も6月から始めたのですが、UCaaSのままサービスを早期提供するのは難しくなってしまいました。

そこで、本来は来年以降、UCaaSが取りこぼしそうな普通の音声通話・スマートフォン内線化のニーズを補完する派生商品として構想していた音声専用の多機能IP電話サービスを、UCaaSに先行して提供しようという話になりました。

それが、Widefone第1弾のWidefone CVというわけです。アプリは京都にあるIP電話アプリの老舗・ageet（アギート）さんから提供していただくことにし、まずはサービス基盤（つまりインフラ側だけ）の先行・集中開発に励みました。

Widefoneリーフレットより
左の電話アプリ画像がWidefone CVで採用したageet社の「AGEphone Cloud」

■Zabbix＋POLESTAR＝監視～運用自動化のワンストップソリューション

Widefoneのサービス基盤であるクラウドPBXは、機能面だけでなくコスト面でもいろいろな工夫を凝らすことで、質の良いサービスを手頃な価格で提供することを目指したのですが、中でも省力化運用、つまり最低限の人数での運用を主要テーマのひとつに掲げ、特に注力しました。
その一環が、Zabbix+POLESTAR Automationという、弊社の誇る監視～運用自動化のワンストップソリューションの採用です。

Widefoneのサーバー構成については2月の本コラムでも触れましたが、データベースを含むすべてのサーバーがクラウド上のインスタンスにあり、大半はAWSなのですが、一部は国内ベンダーのクラウドにあります。このマルチベンダー構成での運用管理には、特定クラウドに紐づくビルトイン型の監視・自動化サービスではなく、ニュートラルでインディペンデントな立場の運用ソリューションが求められます。

ZabbixとPOLESTAR Automationを用いることで、現状のWidefoneインフラの運用はもちろん、ユーザー増加に伴う追加の構築・拡張、点検や障害対応なども滞りなく、極力簡単に実施でき、しかも、作業が属人化してしまわないよう、標準化した運用設計が可能になりました。

■自社サービスの運用は、自社ソリューションで

…と、いかにも最初から、理路整然と運用の標準化に取り組んできたかのように書いていますが、実際には試行錯誤の連続でした。
Widefoneの開発はアジャイル方式なので、それ自体が試行錯誤です。しかも、少数精鋭のメンバーでやっていて、運用管理にまで手が回らないのが現状です。開発と運用の一体化、つまりDevOpsにも挑戦したかったのですが、開発メンバーには開発だけに専念してもらわないと、スケジュールが破綻してしまいます。

そこで、クラウドインスタンスの構築をはじめとするインフラの整備は、実は開発メンバーではなく自分がやっているのですが、サーバーの構成も何度も変わり、ある程度地歩が固まったのは、Widefone CVリリース直前のことです。

そこまでは運用設計に手を付けることはできず、ようやくサービスが始まろうというところでZabbixやPOLESTAR Automationの準備に掛かったのが、実際の話です。

■「手動構成管理」からの脱却をPOLESTARで。実際に体感

ともあれ、POLESTAR AutomationとZabbixが自社取扱製品にあって、本当によかったと思っています。プロジェクトの立ち上げの頃から構築を手掛けつつ、Excelファイルでインスタンス構成表などを作って管理していたのですが、本番・テスト環境を合わせてまだ10数個しかないインスタンスの管理も、他の仕事をやりながらですと、特に立ち上げた後の更新作業が疎かになりがちでした。これは正に、このコラムや他のPOLESTARチームメンバーが執筆している事例・ホワイトペーパーなどで再三触れている、POLESTAR Automationで改善・代替すべき「手動構成管理」そのものといえます。正直、字義通りの「トイル（toil=労苦）」すらも感じました。

「ひとり情シス」の皆様のお気持ちが、身を持って理解できた気がします。
POLESTAR Automationを入れてしまえば、構成管理はツールに任せてしまえるようになります。そこも、実務として体験できました。

なお、ZabbixやPOLESTAR Automationのインストール、ダッシュボードを含む必要な設定作業は、自分も片足を突っ込む形でPOLESTARチームが担当しました。本番運用は、社内の別の部署が担うことになっています。
つまり、Widefoneは社内のさまざまな部署やチームが、組織横断型で総力を挙げて取り組むサービスというわけです。

弊社エントランスのWidefone大型ポスター
これを思いついて貼ろうと言ったのは、もちろん社長です

■Widefone、ご期待ください

Widefone立ち上げとZabbix+POLESTAR Automationを用いた運用事例については、もう少し実運用を経験したところで、ここPOLESTARサイトに手前味噌な自社事例として書かせていただくつもりです。

ところで、実はWidefone CVの製品化やサービス基盤開発・構築を準備する間、自分の社会人経験でも前例がないほど、多くの皆様からのヒアリングの機会をいただいていました。貿易商社の営業職だった、新卒の数年間を上回る密度です。今も時間の許す限り、外出を含めてできるだけ直接、お客様に会うように心掛けています。

その結果、新サービスのアイディアの数が（オプション的なものを除いた、単体で成立するサービスだけでも）とんでもないことになっています。個人的に非常に面白く、世の中がちょっと変わるかも、と思っているものもあります。全部出せるかはわかりませんし、再来年以降になってしまうものもあるかもしれませんが、できるだけ世に送り出したいと考えています。

なお、本稿執筆時点では暫定コンテンツとなっているWidefoneのサイトは、正式公開に向けて準備中ですが、そこでも自分のコラム（社内通称「Yコラム」）を連載することになっていますので、機会がありましたら、どうかそちらもご覧いただければ幸いです。

そして、できればワイドテック渾身の新サービス、Widefoneの方にも興味を持っていただければ、とも思っています。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

ITインフラの足元を固める「構成管理」

公開日:2022/07/13 更新日:2025/04/01

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

先日、6/15～17の3日間「Interop Tokyo 2022（幕張メッセ）」Zabbixブースに、Zabbix JapanさんのパートナーとしてPOLESTAR Automationを出展させていただきました。
Interopといえば、国内のBtoB向けIT展示会ではトップクラスの来場者数を誇ってきた、初夏の一大イベントですが、一昨年はコロナ禍のため開催されず、昨年は開催されたものの、出展企業数も来場者数も例年の1/3程度でした。

しかし、今年はコロナ前の水準に回復したとまではまだ言えないものの、3日間で9万人強という来場者を集め、久々に賑わいを取り戻した感がありました。
Zabbixブースも、会場の出入口付近という場所の良さもあってか、大盛況でした。

盛況だったZabbixブース内POLESTARセミナー
右後ろに弊社ミニブース

■次の課題として注目される「構成管理」

さて、Zabbixといえば、サーバーやネットワーク機器といったITインフラの監視（モニタリング）ツールとして、おそらく日本では最も使われているのではないかと思います。規模や使われ方はさまざまでしょうが、気軽に導入できるオープンソースであり、しかもUIがほぼ完全に日本語化されていて、ユーザーによる日本語のナレッジも非常に豊富、ということで、特定のパブリッククラウドに密接な用途とかでない限り、他に選択肢がないほどの定番だと思います。

ZabbixパートナーとしてのInteropへのPOLESTAR Automation出展は、来場者数の寂しかった昨年も実施したのですが、昨年はストレートに、Zabbixの監視とPOLESTARによる運用自動化との連携について興味を持たれた方が多かったように記憶しています。

それが今年は打って変わり、POLESTAR Automationの主要な用途であり、POLESTAR単独でも成立する「構成管理」についての質問が大変多かったのが、非常に印象的でした。 Zabbixブースということで、Zabbixに上がってくるアラートをAPI経由でPOLESTARが受け取り、その内容に応じて、適切な回復処理を自動的に行う、といういつものデモ環境を持って行ったのですが、蓋を開けてみるとPOLESTAR独自の構成管理関連機能である「点検」や「監査」、「ライブオブジェクト照会」などをデモする機会がかなり多くなっていたのです。

特に、複数環境での設定ファイルやログ、パッチ適用状況などの差分を、マスター（基準）デバイスと比較対象のデバイスとで比較してわかりやすく表示する監査機能は、非常に好評でした。

差分がわかりやすくなった、最新の監査機能

構成管理そのものについては、このコラムと同時に公開されるはずのホワイトペーパーでもご紹介しているので、詳しくはぜひともそちらをご覧いただきたいのですが（ホワイトペーパー「ITインフラの構成管理でサイバーセキュリティや障害対応に備える」）、社内にあるITインフラ全体について、ハードウェアやファームウェア、OS、ミドルウェアなどの構成がどうなっているかを把握し、適切に管理するのが、構成管理です。

POLESTAR Automationなら、例えばOSのバージョンを把握するのにとどまらず、セキュリティパッチやWindows Updateの適用といった更新作業も自動化、ないしはスケジュール機能によりアクティブでない時間帯に実行できて、便利です。

■構成管理の効用の一つ「シャドウIT」の発見・把握

構成管理ツールを導入する目的は、何でしょうか？
インフラ機器のどこかでトラブルが発生した場合や、大規模なマルウェア感染事案発生に対応するセキュリティホールの把握と対策パッチの適用、外部からのサイバー攻撃を実際に受けた場合などセキュリティインシデント対策として、予防や原因の把握、回復作業を迅速に行う上で、やっておくと大いに役立つのが構成管理です。

ITインフラの肥大化や多様化により、手作業に頼った構成管理は限界になりつつあるでしょう。インフラ監視やセキュリティ対策の充実がある程度一巡し、次の課題として構成管理が挙がってきているケースが多いように思います。

構成管理の効用は、構成管理を導入する過程でも現れます。例えば「シャドウIT」の発見・把握がそうです。

シャドウIT、すなわち、社内のどこかに存在しているものの、運用担当者の交代や最新インフラへの更新によって使われなくなり、そのまま放置されているような管理漏れのサーバー・ネットワーク機器というのは、どの企業でも割とありふれたものです。特に、ITインフラの規模が大きければ大きいほど、見られがちです。

放置された古いデバイスは、OSやファームウェアがEOLを迎え、脆弱性パッチなどが供給されなくなってしまった状態であることも少なくありません。マルウェアの侵入や各種攻撃の対象になってしまいかねませんし、SDGsや節電の徹底が叫ばれる今、省エネルギーという点でも無駄な話です。

■POLESTAR Automationで構成管理を始めると、何がよいのか

POLESTAR Automationそのものは、シャドウITを発見するためのツールではありませんが、構成管理目的でPOLESTARを導入したところ、導入作業を行う過程で、用途不明だった謎サーバーがいくつも見つかった、などというお話も耳にしました。構成管理ツールの導入は、そうしたITインフラの棚卸しにもつながります。
もちろん、導入後はインフラの構成情報を常時更新することができるようになるので、シャドウITは発生しにくくなるでしょう。

そして、同じ構成管理を入れるなら、ビジュアルでわかりやすく、知りたい情報が素早く得られる、GUIベースのPOLESTAR Automationがおすすめです。

コロナ禍が落ち着き、あるいはCOVID-19との共存はある程度まで仕方ないという、半ば諦めのようなムードにもなってきている中で、ビジネス界でも全世界的に「Back to Office」「Return to Normal」の流れになってきているようです。リモートワークなどのためのニューノーマル投資、喫緊のセキュリティ対策などが一巡し、足元のインフラ運用改善にようやくお鉢が回ってきたようにも思います。
展示会も賑わいを取り戻す中、構成管理が次の課題のひとつとして注目されていることを、Zabbixブースに立っていても大いに感じました。

…と、ここまで書いていて、また新型変異株が広まったせいで、東京都の新規感染者数が急増し、再び1万人を超えてしまったようです。今回は行動制限などは行われなさそうですが、その分、この夏休みシーズンに感染リスクが街中に溢れたままということにもなります。できれば、COVID-19はもらいたくないですよね。

感染対策も、ITインフラの運用も、日頃からの備えが重要です。
日常では引き続き、マスクや手洗いなどの基本的な対策を。構成管理には、POLESTAR Automationを。
ぜひともご検討ください。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

今日もどこかでセキュリティ

公開日:2022/06/10 更新日:2025/04/01

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

冒頭に毎回書いている通り、自分の担当業務は「プロダクト企画」です。
弊社で「プロダクト」と呼んでいるのは、現在は社内で「TEL（電話）系」と総称されている「AUTOWARP」（オンプレミス）、「転送録」と「急コール」（クラウド）の3製品・サービス、「POLESTARチーム」のPOLESTAR Automationと今春事業化した「ITインフラ運用DXまるっと構築支援サービス」、そして最近新たに立ち上げたばかりのVNO（仮想通信事業者=IP電話回線などの再販）と派生事業（Coming Soon!）です。

これらに加え、新しい事業のネタを探し、商用化一歩手前の状態まで準備を行い、営業部署に渡すまでが自分のミッションです。今はVNO・派生事業の立ち上げに追われる日々ですが、実はかつて同じように、セキュリティ関連プロダクトの企画に明け暮れた時期がありました。

POLESTAR Automationのビジネスが一応の形になった2017年頃から、コロナ禍初期の2020年初頭にかけて、電話系・運用系に続く次の柱として、高成長の続くセキュリティ事業に参入しようという方針が立てられたからでした。

■セキュリティにまつわる「3文字・4文字英略語」の氾濫

当時企画を進めていたセキュリティ関連プロダクトには、オンプレミスのソフトウェア、クラウドサービスもあれば、アプライアンスまであり、3～4種類のプロジェクトが同時進行で動いていたものです。

その中で商用化直前まで至り、担当者のアサインやカタログ、Webサイトの制作まで進行していたのに立ち消えになってしまったのが「SIEM（シーム、Security Information and Event Management）」で、海外のベンダーのものをローカライズ・日本語化して提供する前提でした。

SIEMは、アクセスログやイベントログなど、ログを起点にセキュリティインシデントを検出し、必要な対策を実行するためのツールです。

その頃、既に「次世代SIEM」と呼ばれていた「SOAR（ソアー、Security Orchestration, Automation, and Response）」とか「UEBA（User and Entity Behavior Analytics。ウエバと読みそうですが、なぜかこれだけユーイービーエー）」を自称する製品も出始めていました。

前者は、エンタープライズにおいてセキュリティを統括する組織・場所である「SOC（Security Operation Center）」の運営を念頭に、さまざまなセキュリティツールを連携・統合運用するためのソリューション、後者はユーザーやエンティティ（日本語では「実体」と訳され、ユーザー以外のデバイスやソフトウェアなどを指す）の「振る舞い」を検知してセキュリティインシデントを検出するためのツールです。

弊社が発売を準備していたSIEMは、機械学習による振る舞い検知機能を備え、UEBAと呼んでも構わないほどの内容でした。クラウド基盤だったので、クラウドへのアクセスの分析や可視化・暗号化を行う「CASB（キャスビー、Cloud Access Security Broker）」の機能も備えていました。

しかし、商用化にあたって残されていた、いくつかの課題がなかなか解決されなかったことで、リリースは見送りとなってしまいました。

幻になった「SIEM」サービスのカタログ。
ここまで準備してあったのですが…

この頃はセキュリティに関する3～4文字の略語が、雨後の筍のごとく登場したり、セキュリティ界隈でバズったりしたものです。

エンドポイント（主にクライアントPC）絡みでは、いわゆるアンチウイルスに取って代わる存在として「EDR（Endpoint Detection and Response）」が提唱され始めていました。マルウェアだけでなく情報漏洩対策もカバーするソリューションで、このEDRも、ログの分析が柱となっていますが、監視するのはエンドポイントの名の通り、デバイス操作ログです。

用語としては、ここまで挙げたものよりやや古いですが「WAF（ワフ、Web Application Firewall）」の紹介も受けて、取り扱いを検討したこともありました。

■「SASE」から「SSE」へ。なぜ「A」が落ちたのか？

弊社が前述のSIEM商用化から撤退する頃、話題になり始めていたのが「SASE（Secure Access Service Edge）」で、コロナ禍でリモートワーク（テレワーク）が盛んになった頃から俄に注目され、つい最近までサイバーセキュリティにおける最新のキーワードという扱いを受けていたように思います。

従来はグローバルIP網であるインターネットと、プライベートIPのLAN（イントラネット)を区別し、ファイアウォールなどで外からの接続を遮断ないしは絞り込んだり、ミッションクリティカルな業務では閉域網での運用が行われていたりと、「境界」が明確でした。旧来のエンドポイントセキュリティ（アンチウイルス）のような「パターンマッチ型」やファイアウォールに代表される「境界型」の対策がなされていれば、ある程度のセキュリティが実現できていたものです。

しかし、近年は従来オンプレミスにあったITインフラが、クラウドというグローバルIPアドレスの世界に展開される事例が増えてきていたところに、コロナ禍でリモートワークが当たり前になり、「境界」も曖昧になっています。

この曖昧な境界の上に成り立つネットワーク環境において、アクセス面でのセキュリティを担保する目的で提唱されたのがSASEです。COVID-19感染初報告前の2019年には既に存在していた略語であり、前述の通り、SASE出現の背景には、ITインフラのオンプレからクラウドへの大きな流れがありました。

しかし、図らずもコロナでリモートワークが盛んになったことで、オンプレ・クラウドに関係なくボーダーレスなセキュリティが求められた結果、「ゼロトラスト」というもうひとつのキーワードとセットで広く認知された、という経緯があります。

SASE、自分は初見（脳内）で「セイス」と読んでしまったのですが、「サシー」ないしは「サッシー」と呼ばれることが多いようです。自分の周辺では、多数派はサッシー。やはり日本では、あの人に引きずられてしまうのでしょうか…

ちなみに「ゼロトラスト」の方は、具体的な製品やジャンルではなく、「誰も（何も）信頼しない」という「概念」であり、ざっくりしすぎて「バズワード」と呼ぶのが相応しいものでした。そのせいか、最近は境界外からのネットワークアクセスにおけるセキュリティ担保が対象であることを明確にした「ZTNA(Zero Trust Network Access)」という略語が使われる機会も増えています。

セキュリティ分野で今一番新しいキーワードといえば、「SSE（Secure Service Edge）」でしょう。
この手のIT新語は、米国の世界的なコンサルティングファームであるGartner社が初出であることが多いのですが、このSSEもご多分に漏れずで、昨年定義され、IT業界では自社名が載る（Gartnerに認知される）だけで名誉とされる著名な調査レポート、「マジック・クアドラント（MQ）」で取り上げられたのは2022年の2月という、まだ生まれたてホヤホヤの状態です。

しかし、よく見てみるとSSEというのは、SASEという既存の略語から「A」を削除しただけにすぎません。
A=Accessを消すことで、対象をネットワークアクセスのセキュリティ以外にまで拡大したものとも取れそうですが、Gartnerやベンダーの説明によれば、SASEのうちWAN側の機能（SD-WANなど）を含まず、SWG（Secure Web Gateway）やZTNA、CASB、通信の暗号化などで構成されるのが、SSEであるとされています。つまり、Aの1字削除は、内容の限定・特化を意味するわけです。

実際にSSEのMQで紹介されている製品は、新しいものもありますが、概ねSASEのそれと重なっていて、既存のSASE製品をSSEと称しているケースも多いようです。

GartnerによるMQの説明（左）と、「SSE」のMQ（ベンダー名記載なし（右））

ところでSSEというと、PCのCPUで、主に動画の再生支援処理などに係わる命令セット「SSE（Streaming SIMD Extensions）」があって、先に思い浮かぶのは今でもそっちです。半年後、1年後はどうなっているかわかりませんが、今のところ検索エンジンで単に「SSE」と検索しただけでは、結果の最初のページはこのCPU命令関係といくつかの企業名だけで、セキュリティの話はまだ出てきません。

■セキュリティ対策にも活用したい、POLESTAR Automationの構成管理

この年末年始にIT業界を震撼させた「Log4j」の脆弱性のように、サイバーセキュリティには続々と新しい脅威が立ちはだかるだけでなく、「Emotet」のように数年前から亜種を伴いながら、根絶されることなく繰り返し猛威を振るうマルウェアは、まるでCOVID-19の変異株を見るかのようです。

そこにリモートワークなど、非境界型対策へのニーズも加わった結果、新たなセキュリティの概念や対策製品が続々と出現することとなり、さらなる3文字・4文字の新しい略語が誕生する流れとなっているわけです。
日進月歩、であってほしくないのがセキュリティの脅威なのですが、対策も日夜編み出され、莫大な費用がセキュリティ対策に投じられることになり、ビッグビジネスとなっています。

中国の兵法書「孫子」に、「知彼知己者百戦不殆（彼を知り己を知れば百戦殆うからず）」とあります。
「彼（敵）を知」ること、すなわち、脅威に応じたさまざまなセキュリティ対策も重要ですが、構成管理によってデバイスごとのハードウェアやOS、ミドルウェア、アプリケーション、そしてネットワークなどの状態を常日頃から把握・アップデートし、現在のシステムの全貌を掴んでおくことは、セキュリティの維持はもちろん、万が一のセキュリティインシデントからの迅速な回復にも役立つでしょう。

構成管理ならPOLESTAR Automation。200を超える点検ポリシーや、最新の構成情報がその場で得られる「ライブオブジェクト照会」などを活用し、「己を知」りましょう。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

広くて深い「仮想化」の世界

公開日:2022/05/16 更新日:2025/04/01

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

5月13日の金曜日に封切られたばかりの映画「シン・ウルトラマン」を見てきました。
庵野秀明脚本 x 樋口真嗣監督という「シン・ゴジラ」コンビにより、1966年の特撮テレビドラマ「ウルトラマン」の設定を現代に置き換えた作品ですが、怪獣が「禍威獣（かいじゅう）」、科特隊（科学特捜隊）が「禍特対（かとくたい、”禍威獣特設対策室専従班”の略だそうで）」と変えられていたり、通称「エヴァ明朝」フォントによる字幕やら冒頭の禍威獣との対決歴の駆け足な説明やら、あともちろん台詞や演出も含め、随所に庵野風味が感じられる作品でした。ウルトラマンに変身する主演の斎藤工をはじめ、禍特対でその「バディ（相棒）」となるヒロインの長澤まさみ、先日の米アカデミー国際長編映画賞受賞作「ドライブ・マイ・カー」にも主演していた、禍特対班長役・西島秀俊と、有名俳優が多数起用される中、上手いキャスティングだったと感じたのは、外星人（宇宙人）「メフィラス」を演じた山本耕史ですね。本当にハマっていました。あの名刺、もらえるならほしいです。
テレビの初代ウルトラマンは小学生の頃、数回の再放送で見て以来ご無沙汰だったのですが、そのはるか昔に見た旧作を思い出しながら、童心に帰った気分で楽しめました。

■M1 Macがやってきた

さて、弊社の業務用PCは、これまですべてWindowsマシンでした。しかし、今回新プロジェクトにおいてiOS/iPadOS向けのアプリ開発を行うことになり、iOSアプリの標準的な開発環境「Xcode」を動かす目的で、初めて開発業務用としてAppleのMacを本格的に導入することになりました。それに便乗する形で、検証用兼自分の業務用サブマシンとして、この連休明け直後、まず届いたのが「MacBook Air(2020)」です。

MacBook Air(2020)のSafariブラウザでPOLESTAR Automationを開いたところ。
毎度毎度、写真が下手ですみません。ちなみにUSキーボード仕様。

既に皆様ご存知の通り、最新のMacには「Apple Silicon M1」という、ArmアーキテクチャーをベースにAppleが独自開発したCPUが採用されており、従来の環境との互換性は、macOS側でソフトウェア的に吸収する形となっています。その初号機となったのが、2020年11月発売のAir(2020)です。
この「M1 Mac」は、発表直後からぜひとも触ってみたかったものです。速いと評判のM1そのものもそうですが、M1以上に興味があったのが、仮想ハイパーバイザー（以下、仮想環境）における、Arm版Windowsのエミュレーションです。結局、いつものWindowsの話題じゃないか…と言われてしまいそうですが。

Macが長年にわたっていかに愛されようとも、PC用OSとしてのシェアでWindowsがmacOSを圧倒する状況だけはどうしようもなく、Windows用しかリリースされない有用なアプリケーションが多数あります。
近年（2006年～）の通称「Intel Mac」では、同じIntel CPUということでWindowsの併用が容易で、手段としては「Boot Camp」によるデュアルブートか、「Parallels Desktop for Mac（以下、単にParallels）」や「VMware Fusion」のような仮想環境、または両方の併用が行われてきました。
しかし、Apple Silicon用の仮想環境では、Intel版Windowsのエミュレーションはまだ実現されていません。一方でWindows側も、Armに本格対応してからまだ日が浅い上、M1 Macで直接起動可能なArm版Windowsが（おそらく今後も未提供なので、Boot Campも使えません。
M1 MacでWindowsを使うには、「仮想環境にArm版Windows 11をインストールする」というのが、目下（たぶん、これからも）唯一の方法です。

■Mac仮想環境の定番「Parallels」でWindows 11 Arm版を動かす

と、いうわけで、Air(2020)が届いた初日、Macとしての一連のセットアップを終えてから最初にやったのが、Intel Macの頃から仮想環境のデファクトスタンダードになっているParallelsの最新バージョン17と、Arm版Windows 11の導入です。
Windows 11ではPC（マザーボード）への「TPM(Trusted Platform Module) 2.0」というセキュリティ機能搭載が必須となりますが、Parallels 17にはこのTPM 2.0のエミュレーションが搭載され、Windows 11のインストール条件をクリアできています。
Parallelsでまず驚いたのが、Parallelsそのものだけでなく、Windows OSのインストールまで一気にできてしまうことです。
より具体的には、Parallelsのインストール過程でWindowsのイメージファイルをダウンロードし、Windowsの必要な設定が終わると同時に、Mac上の仮想マシンとしてWindowsが利用可能になる、というものです。

Parallelsのインストール。
左を選ぶとWindows 11 Armの製品版が自動的にダウンロードされ、そのままインストールされます。

ごく最近まで、M1 Mac上のParallelsインストール時に自動ダウンロードされるWindowsはInsider Preview版で、つまりM1上でWindowsを使うにはMicrosoftの「Windows Insider Program」にあらかじめ登録しておく必要があったのですが、現在ダウンロードされるのは製品版なので、Insider Programへの登録は不要となりました。（もちろん、最新機能が先行提供されるInsider Previewの方を積極的に選びたいのであれば、Parallelsによるダウンロード機能を使わず、別途ダウンロードしておいたVHDX形式のInsider Previewを入れることも可能です） Mac-Windows間のリソース共有やショートカットキーに関するオプションもいろいろ選べますが、初めてで詳しくないので、とりあえずは全部デフォルトのまま入れてみました。

ParallelsのWindows用ショートカットキー設定。
カスタマイズも可能なのですが、Mac & Parallels初心者なので全部デフォルトのまま。

かくして、憧れ？のM1 Mac上のWindows 11 Arm版に、ようやく触れることができました。
Parallelsについては、Intel Mac上でWindowsを動かす手段としてデファクト、という以上の知識はなかったのですが、実際に触ってみて、支持される理由がわかりました。
リソースの共有機能がよくできていて、Windows上でダウンロードしたファイルはMac側からも見られますし、逆もまた同様です。Microsoft Officeのファイルなど、もしWindows側にWindows版のOfficeしかインストールされていなければ、ファイルがMac側にあってもWindows版のOfficeを起動してそちらで開けますし、Mac側にOfficeがあれば、逆のことも可能です。
その名の通り、MacとWindowsの両環境がパラレル（並列）に、シームレスに動いているイメージです。VMwareでも、ゲスト側（仮想マシン）にVMware Toolsを入れることで、解像度の自由な変更、ホスト側（仮想環境を起動したマシン）とゲスト側とのリソース共有が可能となりますが、ここまでの一体感はありません。

ウインドウ（Apple用語では「ウイ」は拗音ではありません）モードで仮想Windows 11を実行中。
ちなみにスタートボタンは左が好きなので、左寄せにしてあります。

こちらはフルスクリーンモード。
スクリーンショットではMacとわからないので画面撮りですが、蛍光灯が写り込んでしまってすみません。

Mac側の画面。右端に並んでいるのはWindows側のショートカットアイコン。

あと、M1 Macでは無理ですが、Intel MacとBoot CampでIntel版Windowsを動かしているなら、OS切り替えのために再起動しなくても、Boot Camp用にインストールしたWindowsを、Mac環境上のParallelsから仮想マシンとして起動できる機能もあるそうですね。もちろん、完全なWindowsマシンとして使いたいなら、Boot Campでリブートすればいいわけです。
そんな話を聞くと、今から中古でIntel Macを手に入れるのも悪くなさそうに思えますが、いずれOSやアプリのサポート対象から切り捨てられるのは確実なので、もうApple Siliconだけでいいです。

Windows 11 Arm版の方は、従来からのIntel x86（32ビット）アプリだけでなく、x64アプリのエミュレーションにも対応した、との話でしたが、愛用するメディアプレイヤー「MPC-BE」のx64版は、インストールからできませんでした。Google Chromeブラウザも、ダウンロードされてくるのは32ビット版。x64サポートはまだ完全ではないようですし、動くものもパフォーマンスが悪い（遅い）という話もありますので、追究するのはやめました。
ただし、x86アプリはちゃんと動いて、特に違和感もありません。使い慣れたターミナルアプリ「Tera Term」なども、ごくごく普通に使えます。
最近は、x86/x64とは別途に、Armバイナリを用意するアプリも増えつつあります。ファイル圧縮・展開の「7-zip」はArm版があったので、入れてみました。
ちなみに今回のAir(2020)はメモリ8GB版なので、Windows側には4GBしか割り当てていないのですが、アプリを大量に起動したり、ブラウザで何十とタブを開いたりしなければ大丈夫です。

M1 MacでもParallelsにより、実用レベルのWindows環境が利用可能になっている、と断言してよいでしょう。少なくとも32ビットWindows相当では使えますし、使用感もリアルのWindowsマシンと変わりません。ただし、トラックパッドやマウスホイールによるスクロールは、MacとWindowsで向きが逆になりますので、両方を合わせるには工夫が必要です。手段はいくつかあるようですが、自分は「Scroll Reverser」というツールで解決しました。

■「仮想環境」に明け暮れた1か月

実は、4月に新プロジェクトが本格スタートしてから連休明けにM1 Macが届くまでの間も、仮想環境の構築や設定に、公私ともに結構な時間を取られていました。
新プロジェクトの方では、VMware ESXiを用いた検証用マシンを、自作で1台組みました。第12世代の最新Intel Core CPUとNVMeのSSDだけを用いた、単体のデスクトップ機として使うなら最新・最速の割と贅沢な環境にESXi 7.0を入れ、最大数十個のLinux仮想マシンを動かそう、というものです。
デスクトップ用のハードウェアとしたのは、あくまで社内でのテスト用途なので、Xeonベースとかのサーバー用で組むより、単純にコア数・スレッド数が多くて大量のメモリを積んでも安いから、という理由なのですが、ESXiには標準ではあまり新しいデバイスドライバーが含まれないので、自分で探してきてインストールする必要があり、これに結構な時間を要しました。
2年前（コロナ禍で最初に発令された緊急事態宣言が解除された頃）にもPOLESTARチームの検証環境として、当時最新の第10世代Coreで同様なマシンを組んだことがあったのですが、やはり今回同様、ドライバー周りで苦労させられたものです。「ESXiは枯れたハードウェアがいい」…格言です。

自宅でも、連休前後にPCを新調したのですが、連休中に今までメイン機として使っていた完全ファンレス構成のPCを仮想環境のホストとして再構成し、それまで別のシングルボードコンピューターで動かしていた24/365稼働のサーバーを、WindowsのHyper-Vで立てた仮想のLinuxに移して使うことにしました。ディストロは元がUbuntu 18.04だったので、出たばかりの最新Ubuntu LTSである22.04にしました。同じUbuntuでも、そもそもCPUアーキテクチャーが違うので、データと一部のコンフィグ（設定）以外は全部入れ直しになる上、22.04ではPython 2.xが完全に廃止されていたりもするので、その辺の対応も割と面倒でしたが、なんとか都合数日で完了しました。

そんなわけで、この1か月だけで、仮想環境に関する見聞と経験をかなり拡げられたと思っています。特に、Parallelsには感動させられました。

■面白くてSDGsな仮想環境

ところで、仮想環境を使う目的、意義はなんでしょうか？ひとつは「古い環境の保存・維持」が挙げられると思います。
趣味の世界では、MS-DOSやWindows 9xのような20世紀のOSで、1980年代から世紀末にかけての時代を風靡した、いわゆる「レトロゲーム」を楽しむために仮想環境が使われる例もありますよね。ゲームをあまりしなかった自分でも、たまに「DOOM（初代）」などを動かしてみることがあります。
その時代のハードウェアを今から手に入れるのはもちろん、使い続けるにも辛いものがあるので、仮想環境こそ最適解といえますが、例えばWindows 98とか2000あたりを、現代のPCの仮想環境で動かしてみると、当時の実機をはるかに上回る速度で快適に使えるので、感心させられたりもします。
そのような極端な古い事例に限らず、Windows XPや7、Server 2003や2008といった、比較的近年にEOL/EOSとなったOSについては、POLESTAR Automationで運用管理を自動化できるかどうかのお問い合わせをいただくことも稀にあるので、弊社POLESTARチームでも、それらの古いOSを仮想環境に保存してあります。

何より、アプリケーションやミドルウェアなどの中には、最新コンピューティング環境の提供するフルスペックを必要とせず、1つのハードウェア+ハイパーバイザー上で資源を共有し、仮想マシンとして動かせば済むようなものが、意外にあります。
SDGs（持続可能な開発目標）の実践が叫ばれて久しいですが、ITの世界でいろいろな意味でSDGsに相応しく、もっと広く活用されるべきなのが、仮想環境だと思います。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

ITインフラ運用の現場が直面する「脆弱性対策」

公開日:2022/04/19 更新日:2025/04/01

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

去る4月6日から8日まで、久々に東京ビッグサイトで最大規模の会場「東展示棟」において、2022年の「Japan IT Week 春」が開催され、弊社も「システム運用自動化展」エリアに出展しました。ご来場いただいた皆様に、この場をお借りして感謝を申し上げます。

2022年「Japan IT Week 春　システム運用自動化展」ワイドテックブース

■久々の「東京ビッグサイト・東展示棟」

弊社POLESTARチームでは、2018年以来、新型コロナウイルスの影響で開催中止となった2020年を除いて、毎年Japan IT Week 春への出展を続けているのですが、最初に出展した2018年は東展示棟全体を使って開催され、3日間の来場者が10万人を超える規模の大規模展示会でした。弊社ブースは限られた人数で回していたにもかかわらず、多数のご来場をいただき、スタッフは休憩を取る間もないほどで、ハードだった印象が強烈に残っています。

しかし、東展示棟は2020年開催予定だった東京オリ・パラのプレスセンターに供されることになり、翌2019年はテーマ別に「前期」「後期」の分散開催となり、さらに会場も、東京ビッグサイト本棟の小さい方の会場「西展示棟」と、東展示棟が使えない期間中の展示スペース不足対策として、本棟最寄りのりんかい線「国際展示場」から1駅離れた「東京テレポート」駅前に仮設で建てられた「青海展示棟」での分散開催でした。

弊社は後期、青海展示棟での出展となりましたが、会期だけでなく会場までも分散し、1駅分離れた西展示棟と青海展示棟をバスで行き来するという状況では、来場者の足も遠のいてしまったようで、集客は前年をかなり下回ってしまいました。

翌2020年にも出展を予定していましたが、コロナ禍により中止に。昨年2021年も、オリ・パラの1年延期により東展示棟は召し上げられたままだった上、さらに緊急事態宣言の影響で日程が一度延期されたこともあり、当初西展示棟と聞いていた会場が変更され、またも青海展示棟となりました。しかし、強行的な開催かつ出展者の激減もあって、来場者も少なく、寂しい限りでした。

ちなみに仮設の青海展示棟は役目を終えた昨年末に解体されましたが、その眼の前にあって、2019年展示会の打ち上げや、何度か昼食を摂りにも出掛けた商業施設「ヴィーナスフォート」も、3月27日で閉鎖となってしまいました。建物の中にあった噴水や、ユニークな「空の照明」が印象的な施設でしたが、個人的にはそれらは青海展示棟とセットで、オリ・パラとコロナ禍対応というビッグサイト過渡期の風景として刻まれています。

■DXよりも何よりも、喫緊のテーマは「脆弱性対策」

さて、久々に東展示棟への帰還を果たしたJapan IT Week 春のPOLESTAR Automationブースですが、まだ出展を見合わせる企業が多く、3日間合計の全体来場者数も4万人弱と、過去最低だった昨年に比べれば3倍近くまで増えたものの、かつて10万を超えていたところからすると、まだ回復したとはいえない状況でした。

それでも、POLESTARブースには予想外に多くの皆様にご来場いただき、時間帯によっては応対が間に合わず、せっかくお越しいただいたのに、説明の機会を逸してしまうような場面もありましたことを、改めてお詫び申し上げます。

今回は弊社の新事業として、POLESTAR AutomationやZabbixを利用したマネージドサービス「ITインフラ運用DXまるっと構築支援サービス」を開始したこともあり、内部的に「ITインフラ運用のDX（デジタル・トランスフォーメーション）」を主なテーマに掲げていて、毎回の展示会で好評をいただいてきた、Zabbixとの連携による障害検知から回復までの自動化や、サーバー・ネットワーク機器構成の「いま」を瞬時に把握できる、構成管理ツールとしてのPOLESTAR Automationをご紹介するためのデモをメインで用意していました。

いざ蓋を開けてみると、目立ったのは「脆弱性対策」という課題を抱えておられるお客様の多かったことです。特に、サーバーを多数抱えるお客様にあっては、昨年12月に明らかになったJavaベースのオープンソースログ収集ライブラリ「Apache Log4j 2（以下Log4j）」の脆弱性「Log4Shell」対策が、喫緊の課題となっているようです。

過去にも暗号化データ通信を担うOpenSSLの「Heartbleed」や、UNIX/Linux系OSで最も有力なコマンドシェルであるBashで発覚した「シェルショック」など、サーバーなら何にでも入っているほど影響範囲が幅広く、危険度も高くて悪用されやすい大型の脆弱性事案が、数年ごとに発覚してきました。Log4jもオープンソース、商用を問わず多数のサーバー用ソフトウェアにおいて、ログ収集を司るモジュールとして組み込まれ、活用されてきたものです。

Log4Shell脆弱性のあるLog4jでは、任意のコードをリモートで実行可能となっていたため、この脆弱性を悪用すると、さまざまなマルウェアを企業のネットワーク上に侵入させることが可能です。ランサムウェアやボットネット、仮想通貨のマイニングプログラムなどを侵入・実行させた事例が確認されているようです。

2024年2月追記

脆弱性情報/自動検索パッケージのページを公開しました。

脆弱性を狙ったランサムウェアやゼロデイ攻撃などのサイバー攻撃は増加傾向にあります。POLESTAR Automationは、使用しているソフトウェアの脆弱性情報を自動検索できるツールとしても活用していただけます。
脆弱性対策情報の自動検索ツールとしてのみのご利用でしたら、コストを抑えた導入が可能です。お気軽にご相談ください。

■POLESTAR Automationで、脆弱性に立ち向かう

バイナリモジュールのバージョン特定によってセキュリティホールを見つけていた過去のHeartbleedやBashの脆弱性事案とは異なり、圧縮されたJavaの.jarファイルが対象となるLog4jの脆弱性確認は、やや面倒です。

POLESTAR Automationでは、シェルコマンドなどを利用して調査可能な範囲であれば、管理対象サーバーのインストール済みパッケージの構成を調べて、容易にリスト化できます。このリスト化や報告書の作成機能は、POLESTAR Automationならではのものといえます。

ソフトウェアパッケージに脆弱性確認済みのLog4jを含むことがベンダーから発表されている場合は、公開情報を用い、パッケージ名を確認することで特定できるでしょう。

パッケージ名で特定できない場合、Log4jのモジュール自体は、多くの場合「.jar」ファイルの形で存在していますので、WindowsならWHERE、UNIX/Linux系ならfindなどのコマンドにより、サーバー内のファイルを検索することで発見できます。

ファイル名にバージョン番号が含まれている場合は簡単ですが、ファイルがリネームされてバージョン番号が抹消されているなどの場合は、.jarファイルをZIPアーカイブ用の展開ツールで展開し（.jarファイルはZIP形式で圧縮されています）、中に必ずある「MANIFEST.MF」ファイルに記載のバージョン番号を調べることで特定が可能です。

こうした一連の作業は、POLESTAR Automationではジョブを書いて実行することで、ある程度自動化できるでしょう。ただし、findやWHEREなどのコマンドはサーバーのファイルシステムなどに負荷を掛けるものですので、実行にあたってはスケジュールの検討が必要でしょう。

POLESTAR Automationなら、ジョブ実行のスケジュールも設定できますので、夜間などシステムが稼働していないか、稼働率の低い時間帯に、そうした作業を自動的に行うことができるでしょう。

■さまざまな運用の課題を、まとめて解決！

インストールやデプロイ、アップデートから、死活監視やパフォーマンス管理、そして脆弱性対応まで。多岐にわたるITインフラ運用の多くの場面において、課題解決に役立つのが、POLESTAR Automationです。

脆弱性・セキュリティ対策については、ゼロデイ（未知の）脆弱性のようにPOLESTAR Automationでは対応が難しいものもありますが、いざ脆弱性事案が発生すれば、POLESTAR Automationの得意とする構成管理が役立ちます。

また、ネットワーク機器における不要なポートの開放確認、サーバーやミドルウェア、アプリケーションへのタイムリーなパッチ適用など、セキュリティの基本とされつつも手作業では煩雑な日常のセキュリティ対策にも、POLESTAR Automationは有用です。まずは、評価版でお試しください。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

弊社草創期からの事業「電話」について

公開日:2022/03/15 更新日:2025/04/01

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

弊社では、入社日から1周年、2周年…と年次を重ねるたびに、「○月○日で、勤続○年です。」というお祝い？のメールが該当の社員に送られてくるのですが、自分はこの3月1日で、9年目となりました。
これまで最も長く勤めた会社は、6年に届かないところでの退職でしたので、9年もいるというのは、もちろん最長記録です。
その会社は、秋葉原からギリギリ徒歩圏にあった、主にコンシューマー向けのパソコン周辺機器を扱う中小企業で、自分はその会社で製品企画を手掛けていました。ワイドテックが設立された2000年12月25日は、台湾の協力会社に出張中でした。

■はじまりは「TOGOS」と「AUTOWARP」から

20世紀もあと6日を残す中で設立された弊社の、立ち上げのきっかけとなったのは、某大手通信会社向けに開発したNMS（ネットワーク管理/監視システム）スーパーバイザーシステム「TOGOS」でした。創業者でもある現社長が、以前から同社に提案していたTOGOSのアイディアを具現化するために興したのが、ワイドテックなのです。
TOGOSはその通信会社で、今もバージョンアップを繰り返しながら稼働を続けていて、TOGOS運用のために20年以上にわたり、常駐者も送り出しています。POLESTAR AutomationやZabbixを含む一連の運用関連製品や、SES/人材サービス事業などの起源は、すべてこのTOGOSにあるといえます。

一方、現在のワイドテックにおいて、対外的、客観的に最も存在感のある事業というと「電話」、主に固定電話を応用した製品やサービスでしょう。
最初の製品である電話転送切替システム「AUTOWARP」は、弊社の現社長が、ある会社で事務の女性社員が1人で、固定電話から携帯電話への転送となる電話番号の切り替え作業を、1日中手作業で行っていたのを見たのがきっかけとなって開発されたものです。
NTT東西の「ボイスワープ」をはじめ、各電話会社の電話転送サービス（以下「ボイスワープ等」と総称）では、転送先の電話番号の入力や切り替えを、電話機のプッシュボタンを操作して行う必要があります。
しかし、毎回の手作業では、切り替え忘れや電話番号の設定ミスが多発していたことから、番号切り替え作業を自動化し、ミスなく転送先を切り替えられるシステムの開発を思い付いたのです。
現在も金融業や全国展開の外食チェーンなど、数百～数千回線の定期的かつ大量切り替えを伴う大型案件で活用されるAUTOWARPが世に出たのは、2007年のことです。

■オンプレミスからクラウドへ～「転送録」の誕生

AUTOWARPは、プッシュ式電話のトーンダイヤルで行うボイスワープ等での切り替え操作を、ソフトウェア制御によりトーンを発生させる機器（回線制御装置）によりシミュレートすることで実現し、併せてスケジュール機能の提供により自動化を図っています。
しかし、このシステムは必要な各機器をオンプレミスで提供しているため、数百回線以上の規模がないと、収支が合いません。1回線から数十回線程度までの切り替え需要に応えるには、コストが高すぎるのです。
そこで、当時隆盛を迎えつつあったクラウド、当時はまだ「ASP(Application Service Provider)」から「SaaS(Software as a Service)」へと呼称が変わりつつあった頃ですが、回線制御装置を共用化し、回線1本単位から安く利用できるAUTOWARPのクラウド版を開発しようということで構想されたのが「転送録」で、正式サービスは2010年から提供されています。　
転送録を提供するにあたっては、AUTOWARPをクラウド化した「電話転送切替」だけではサービスラインナップが弱いこともあり、AUTOWARPとは異なる技術を用いた、さまざまなサービスも新規に開発しました。代表番号に着信した電話を、社員の携帯電話などに次々と転送する「順次転送」、登録された全員を呼び出して最初に取った相手と通話が成立する「一斉呼出転送」などがそれです。
現在では名実ともにワイドテックの顔となり、今なお毎年成長を続けています。

■予想を超えて、広範に活用される「急コール」

転送録からは、新しいサービスも派生しました。メールの受信をトリガーに、順次転送の仕組みを応用して電話を発信し、メールを受信したことを関係者に順々に電話を掛けて知らせるのが、過去に何度も本コラムで言及しているメール連携電話発信サービス「急コール」となります。
当初は単体のサービスではなく、サーバー監視を行っている取引先企業からの依頼で開発したものです。単にメール受信に反応するだけだと、重要度（深刻度）の低いメールやいわゆるスパムメールなどを受信しても電話を掛けてしまうので、送信者や件名、本文などで絞り込めるフィルター機能を開発して追加し、汎用性のあるSaaSとして展開できるようになりました。
システム運用の現場で、メール通知機能を持つ死活監視/パフォーマンス監視製品（例えばZabbix）との連携を想定して開発・汎用化したサービスですが、「重要なメール受信に確実に気付くようにしたい」というあらゆるニーズに応えられるサービスとして、昨年は一昨年比で約250%もの成長を遂げました。
例えば機械のメンテナンス、物流の温度アラート、IoTと連動した畜牛の健康管理、物流倉庫での温度管理、はては不動産や中古車買い取り店の営業メール対応など、開発当時は思いも寄らなかった用途へと、次々に展開されています。

■そして「電話」の未来へ

前回のコラムで、現在弊社で開発中の新しいXaaS「Project C」についてご紹介しました。
実は、これも電話に関係するプロジェクトです。
自分は入社以来9年間、ワイドテックの花形部門である電話応用サービスの企画には、ほとんど関わってきませんでした（唯一の例外が「急コール」という命名）。入社当時、AUTOWARPはいくつもの大型案件を獲得し、転送録もサービス開始3年を経て、成長軌道に乗った頃でした。
電話以外で新しいジャンルのプロダクトやサービスを開拓するのが自分に課せられたミッションであり、POLESTAR Automationはそのひとつでした。
しかし、創業から20年を迎えた一昨年の末あたりから、弊社の原点のひとつである電話事業で、新しいサービスを作ってみよう、ということになりました。
電話やその応用技術の基礎的な勉強から始め、企画に約1年を掛け、ようやく概要が固まり、今年から開発フェーズへと移行しています。
AUTOWARP、転送録、急コールの基礎やノウハウがあってこそのProject Cではあるのですが、入社から8年間にわたって電話系サービスには一切関わってこなかったところからのまっさらなサービスとして、過去の因習に縛られないものをと考えています。

POLESTAR Automationを発表したのは、創業以来江東区亀戸にあった弊社の本社事務所が、千代田区岩本町の現在地への移転を控えていた直前の、2016年10月でした。
岩本町への移転は当月の末に実施されましたが、移転作業のために古い書類やハードウェアを整理していたところ、ちょうどワイドテック創業直後の時期に、自分が冒頭の6年近く勤めたかつての勤務先で手掛けていた製品が倉庫の奥から出てきて、不思議な縁を感じてしまいました。

それから約5年半。これまで岩本町の現在地で、ビル4階の半分を使用してきた弊社でしたが、5月の連休明けからは全フロアを使用することになり、今週末から段階的に、新たに拡張された区域への座席の移動が開始となります。
と、いうわけで、今回はオフィス拡張という節目に弊社の歴史を振り返る、まるで社内報のような記事になってしまいました。
ITインフラ運用管理の話は何も出ない回で大変恐縮ですが、この機会に少しでも、ワイドテックという会社そのものにも、興味を持っていただければ幸いです。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

GoogleのSREを日本流にアレンジする

公開日:2022/03/15 更新日:2025/04/01

「GoogleのSREを日本流にアレンジする」（2022年3月15日公開）は、お役立ち資料（ホワイトペーパー&パンフレット）に移動しました。以下よりご覧ください。

お役立ち資料（ホワイトペーパー&パンフレット）：Vol10「GoogleのSREを日本流にアレンジする」

一覧へ

「XaaS」はどこまで自動化できるか

公開日:2022/02/15 更新日:2025/04/01

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

またも「まん防」こと、新型コロナウイルス感染拡大対策の「まん延防止等重点措置」が発動され、好きな映画も見に行く気がいまいち起きない中、先頃興行収入100億円を突破したばかりの「劇場版呪術廻戦0」だけは、と見てきました。
テレビアニメ化されて動画配信等でも人気を集めている少年誌連載漫画「呪術廻戦」の、本編ではなく前日譚として本編連載の前に発表された作品の映画化ですが、本編キャラの1年先輩にあたる本作の主人公・乙骨憂太（おっこつ・ゆうた）の声優が、昨年有終の美を飾った「エヴァンゲリオン」シリーズの主役・碇シンジと同じ、緒方恵美さんということでも話題になっています。
そもそも作者がエヴァのファンで、乙骨というキャラ自体、シンジ君をイメージして構想されたとのこと。発表直後や予告編が出始めた頃には賛否両論があったものですが、実際に見てみると、起用に納得してしまう出来の良さでした。

■フルクラウドで作る新XaaS。どうせなら最初から自動化で

さて、実は昨年2021年、自分ことYは、POLESTAR Automationにはこのコラム執筆とコンテンツの監修、あと若干の技術的支援以外で携わることは、ほとんどありませんでした。
では、1年を通して何をやっていたのかというと、社内で「Project C」というコードネームで呼ばれている、新しいサービスアイテムの企画と開発の準備です。
これが何であるかは、いわゆるXaaS（SaaSやIaaS、PaaSなど”as a Service”としてクラウドで提供されるものの総称）と呼ばれるクラウド型のサービスである、という以外、まだ明かせない状態なのですが、もちろん自分1人で何でもやっているわけではなく、コアとなるロジックやテスト用のプログラムは、社外の協力者を交えて開発しています。
あと、開発費用などについては、公的な補助金ももらうことになっているのですが、そのあたりの手続きはすべて、経験の豊富な総務にお願いしています。
年が明けてからは、専任の組織（自分もタスクフォースメンバー的な立場で参加しています）も立ち上がり、本格的な開発フェーズに入ったところです。
Project CはXaaSであり、オンプレミス主体のPOLESTAR AutomationだとかITインフラ運用とは全く違うジャンルであり、かつ自分にとっても未経験、未踏の分野でしたので、昨年はその方面の知識習得、テスト環境の構築やテスト実践などを通じた経験の蓄積に明け暮れてしまいました。
しかし、1から作る新しいXaaSということで、どうせなら「自動化」をテーマのひとつとして掲げようということになりました。
とりあえず、ユーザーとなる加入者が自分でサインアップし、設定もユーザー自身が行った上で日常的に利用し、請求処理なども自動的に行われる、という、できるだけ人の手が介在しない、セルフサービスによるXaaS提供を思い描いています。

■サインアップから設定、請求まで「セルフサービス」を目指して

セルフサービスというと、一昨年あたりから、携帯電話の新規契約（個人向け）で「オンライン専用」を謳うものが相次いで登場しています。
従来、携帯電話の契約というと、携帯電話ショップの店頭で、顔写真入り（または2種類以上）の書類による本人確認が厳重に行われていました。いわゆる特殊詐欺など、携帯電話が犯罪に利用されることを防ぐための「犯罪による収益の移転防止に関する法律（通称: 犯罪収益移転防止法、犯収法）」で規定されているからです。
かつて、プリペイド式携帯電話がコンビニなどの店頭で、最低限の本人確認だけで買えた時代がありましたが、「オレオレ詐欺」のような電話を用いた特殊詐欺の横行を機に、契約時の本人確認徹底が困難なプリペイド式は、サービス自体が事実上の廃止となり、携帯電話の契約は店頭かつ対面でないとできない時代が続いていました。
近年のオンライン契約では「eKYC（電子本人確認）」という仕組みが導入され、運転免許証やマイナンバーカードなどの本人確認書類を表裏だけでなく、書類を傾けて厚みまで撮影させます。書類が偽造やコピーされたものでないかどうかを確認するためです。
さらに、本人の「自撮り」による確認もあります。こちらも顔の正面だけでなく、横や左右、上下を向かせ、立体的に顔画像を取得します。
こうした数多くの手数の必要なeKYCの手順は、「面倒だ」という声も少なくないようですが、ここまで行うのは、本人確認を書類の内容ではなく、本人および書類の信憑性を証明するためにやや複雑な「過程」を踏ませることによって、確認の精度と速度を上げるためです。
実際、eKYCを導入している携帯電話サービスでは、対応する端末で物理SIMカードが不要の「eSIM」を選択することで、手続きが終わりさえすれば、早いものなら申し込み完了後数分で使えるようになるものもあります（物理SIMが必要な場合も、翌日や翌々日に届くことが多いです）。コロナ禍等で店に足を運びづらい状況もある中で、手続きがオンラインだけで完了し、しかも申し込みからすぐに使えるようになるというのは、メリットが大きいでしょう。
今回開発する新XaaSはBtoBであり、eKYCを入れるかどうかは未定ですが（ちなみに法人eKYCというものもあります）、eKYCの考え方は、セルフ契約型のクラウドサービスにおける、契約者確認のポリシー決定の参考になると思っています。
申し込み手順をクリアできたら、後は各種の設定、決済手段（運営側視点では請求方法）などが課題として残りますが、設定の自動化・簡素化については、ちょっとしたアイディアを思いついています。決済はクレジットカードを連携させれば簡単なのですが、法人の大半では「請求書払い」が求められると思います。顧客、運営双方にとって、できるだけ楽な手段を導入したいと考えています。

■「監視」と「障害復旧自動化」をどうするか

この新XaaS、クラウドでの提供ということで、サービスインフラもパブリッククラウドの上に構築することにしています。
必要なインスタンス（サーバー）だけでも、用途で大別して4種類か5種類、それにサービス規模の拡大につれて負荷分散や冗長化などが入ってくるので、かなりのインスタンス数になる可能性もあります。
さまざまな目的を持ったフロントエンド、ミドルウェア、バックエンド環境の稼働するインスタンスが絡み合い、連携し合いますので、安定して稼働できるようシステム構築を行うことはもちろんですが、各インスタンスの稼働状況の監視、いわゆる死活監視からプロセッサやメモリ、ネットワークなどの負荷の監視まで、リアルタイムでできるようになっていなければなりません。
あと、障害が発生してしまったら、ある程度は自動的に復旧できるような機能も必要でしょう。その実現には、構成管理が欠かせません。
この辺の構築や運用については、POLESTAR Automationに5年にわたり携わった経験が生きてくると考えています。
ただし、例えばAWSのように、1つのパブリッククラウドだけを利用するのであれば、Zabbixによる監視、POLESTAR Automationを用いた構成管理など、外部のツールに頼る必要は本来ありません。
AWSには、サービスにビルトインされた監視機能として「AWS CloudWatch」というものがあります。死活監視やパフォーマンスの監視はもちろん、メトリクス（CPU使用率やメモリ占有率、データトラフィックなどの数値）のしきい値を設定しておき、そのしきい値に応じてインスタンスを再起動するなど、自動復旧（オートリカバリー）の設定まで可能です。監視だけでなく、自動化の領域までをカバーする、非常に便利な機能です。
もちろん、CloudWatchもAWSのサービスのひとつですので、稼働時間や規模に応じた課金が発生するわけですが、もしAWSだけで完結する構成であれば、自分でもCloudWatchを利用する判断をしたことと思います。

■「マルチクラウド」に適応するには

が、しかし。
この新サービスを構築するにあたり、とある「絶対に譲れない条件」が出てきてしまいました。
その「条件」を満たすには、AWSではない、別のパブリッククラウドを利用しなければならないのです。
しかも、AzureだのGoogle Cloudだのという、運用ノウハウの蓄積されたメジャーなものではない、国内のクラウドです。そのクラウドを利用することで、新サービスは他にないアドバンテージを獲得することができるので、どうしても外せないのです。
期せずして、複数のパブリッククラウドが混在する「マルチクラウド構成」を選ぶことになってしまったわけですが、AWS CloudWatchでオンプレミスや、AWS以外のクラウドの面倒を見ることも、実は可能です。しかし、AWS外のインスタンスに対しては設定や管理が結構面倒な上、あくまでAWSに最適化されているので、やはりマルチクラウドなら第三者的立場のツールを使う方が都合がよいと判断しました。
あと、構成管理を行うには「AWS Config」というものがありますが、こちらは基本的に、AWS上のインフラだけが対象となるようです。
と、いうわけで、ここは弊社の取扱製品に頼ることにしました。監視はZabbixで、構成管理や障害復旧はPOLESTAR Automationで行います。どちらもクラウドに構築し、各サーバーにエージェントを導入して管理する方向です。

■後発ならではの強み発揮に向けて

Project Cは、弊社にとってゼロから手掛ける久々の大型新規事業であり、技術的、ビジネス的な未踏領域への、数多くのチャレンジをも含んでいます。
弊社では10年以上前から、電話転送サービス「転送録」や、電話による自動連絡サービス「急コール」などを通じ、SaaSの提供に関するノウハウを積み重ねてきてはいるのですが、これらは各々の分野における先駆者であり、参入当初は競合がいない状態でした。一方、いわゆるニッチ領域のサービスなので、市場規模は限られています。
Project Cで開発する新しいXaaSは、もう少し規模の大きな市場がターゲットながら、既に複数の先行コンペティターが存在するカテゴリになりますが、後発の強みを存分に発揮できるよう、さまざまな新機軸を打ち出して行きたいと考えています。サービス全体にわたる「自動化」も、新XaaSのキーファクターのひとつとなります。

リリースはまだしばらく先になると思いますが、発表された暁には、ああ、あれがそうだったのか、と思い出していただければ幸いです。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

自動化の手順書はどう作るか？ 2022

公開日:2022/01/18 更新日:2025/04/01

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

もう年明けから2週間余りが経ってしまいましたが、本年もどうか、ITインフラ運用自動化ソリューション・POLESTAR Automationをよろしくお願いします。
今年で足掛け7年目を迎えたPOLESTAR Automationですが、年明け最初のPOLESTARチーム打ち合わせの席上、昨年1年間の当サイトのページ別アクセス統計を見ていたところ、最も読まれているページのひとつに、2016年9月30日付けの当コラム最初の記事のひとつ「自動化の手順書はどう作るか？」があり、参加者一同から驚きの声が上がりました。
と、いうわけで、新年最初の当コラムは、過去の記事を振り返りつつ、2022年の自動化手順書作成はどうあるべきかを論じてみたいと思います。

■はじめに「手順書」ありき

華やかで甘く耳あたりのよい宣伝文句が並ぶのは、運用自動化ツールに限らず、あらゆるジャンルのサイトや広告に言えることですが、運用自動化ツールを導入したからと言って、その日からいきなり既存の運用業務を自動化できるわけでは、もちろんありません。
まずは手順書を作り始めること、それが運用自動化のスタートラインです。
POLESTAR Automationを世に送り出した2016年当時、運用自動化ツールを指して「Runbook Automation（ランブック・オートメーション、手順書による自動化、ランブック自動化などの日本語訳あり）」、略して「RBA」という呼称がよく使われていました。ランブックというのは、「手順書」の意味です。
リリース当初、POLESTAR Automationを指すキャッチコピーのひとつとして「エンタープライズRBA」というものがありました。しかし、発売開始からしばらくすると、「RPA」なる略語が、IT関連のネットメディアなどに突如あふれるようになりました。こちらはRobotic Process Automation（ロボット的な業務プロセス自動化）の略です。とりわけ2017年には、IT業界を代表するバズワードになっていたと思います。
弊社自身も、展示会などにブースを出すたびに「これはRPAですか？」「Excelの入力が自動化できるやつですか？」などという質問を受けるのが常になっていたものです。
後から出たRPAの方が俄然有名になってしまったので、弊社でも混乱を避けてRBAという用語は自然と使わなくなり、代わりに「運用自動化ツール」とか「構成管理ツール」を使用するようになったのですが、製品の中身やコンセプトが変わってしまったわけではありません。
運用自動化は、昔も今も手順書（に相当するもの）を作り、整理するところからスタートします。手順書がない状態では、何もできません。そこはこれからもずっと変わらない、運用自動化の本質です。

■手順書の作り方は、2016年と変わったのか？

そもそも手順書とは、辞書的な意味では、何らかの業務・作業を、第三者が見てもその通りに実施できることを目的に、業務・作業を実施するための手順をまとめたものです。一般的には作業者（人）が読めるように、文書として作成されます。
運用自動化ツールにおける手順書（ランブック）は、コンピューター上で稼働するソフトウェアツールが読み取って作業を行うためのものですので、文章のように書いて行くわけではなく、広義の「プログラミング言語」で書くことになります。
以前書いたコラムでは、運用自動化ツールの手順書は、プログラミング言語に近い独自のスクリプト（書式）、ないしはプログラミング言語そのものをスクリプトとして利用し、手順書を書いて行く、とご紹介しました。ここも、2016年と基本は変わっていません。
当時と異なるのは、そのツール専用の独自スクリプトを必要とするものは退潮し、YAMLのような、ある程度標準化されたフォーマットを利用するものが普及していることでしょうか。
このYAML等による手順書記述は「Infrastructure as Code（IaC)」として知られるようになり、DevOps（デブオプス=開発と運用の融合・共同作業）や前回のコラムでもご紹介したSREなど、新しい運用スタイルを実現する上でもキーファクターとなっています。
オープンソースのツールとして著名なものとしては「Ansible（アンシブル）」があります。Ansibleでは、YAMLを用いて記述された手順書を「Playbook（プレイブック）」と呼びます。YAMLは、XMLやJSONなど、他のデータ形式と比べて読みやすく書きやすいとされていますが、プログラミング言語のソースと比べても直感的な印象があります。
実際にPlaybookは、箇条書きのようなスタイルで書いて行けます。階層構造や、ブロック記述的な書き方も可能です。
数ある運用自動化ツールの手順書書式で、「手順書」というイメージに一番近いのが、もしかしたらAnsibleのPlaybookかもしれません。

■スクリプト・コード型手順書の限界

しかし、DevOpsや前回の当コラムでご紹介したSREは、ムダな稼働を省いて開発・運用の効率を飛躍的に向上させる画期的な手法である一方、従来は分担が明確で、互いに融合し合うことのなかった開発と運用の従事者それぞれに、新しいスタイルへの適応を求めるもので、展開方法を誤ると目的を達成できないケースもあろうかと思います。
そして、さまざまな理由から、DevOpsやSREの導入に踏み切れない現場もあることでしょう。特に日本のITインフラ運用においては、業務をいわゆる「下請け」を含む外部に委託しているケースが多いです。
運用自動化、IaCを導入する目的のひとつに「属人化の排除」があるでしょう。DevOpsやSREなど先進的な運用手法を導入するまでもなく、属人化はインフラ運用において最大の課題であり続けています。
当コラムでもテーマとして何度も取り上げてきましたが、特定の業務が特定の人物に紐付いてしまうのが属人化です。その人物が急な退職、長期の病気休養などで運用業務に従事できなくなってしまったら、最悪、その業務は停止してしまったり、障害が発生しても対処できなくなってしまいます。
スクリプト・コード型の手順書を用いるCLI（コマンドライン）型の運用自動化ツールでは、ある程度習熟すれば作業者が自ら手順書を作成し、運用作業の手順をセルフで自動化することができます。しかし、ツールを導入する過程でそのツールの利用が特定の人物任せになり、他の作業者に使用方法が周知されないまま、新たな属人化を招いてしまっている事例も少なくないようです。
そうした上級作業者は、非自動化、非IaCの運用環境においても「スクリプト職人」と呼ばれるような、ハイスキルの人であることが多いです。

■対話型GUIツールで、属人化しない手順書を作ろう

一方で、商用製品を中心に、GUIを採用した運用自動化ツールが存在します。作業手順を流れ図として手順書化するフローチャート型、ウィザード形式のような対話型などのインターフェースがあり、POLESTAR Automationは後者です。
フローチャート型の手順書は、全体を画面上で俯瞰でき、誰の目にも作業の流れがわかりやすいものです。しかし、アイコンの並ぶフローチャート上の中身は、作りやすそうに見えて、結局各作業アイコン内にCLIのスクリプトを埋め込む必要があるという例が多いです。フローチャートは、全体の流れを示しているだけです。高度な作業を志向しようとすればするほど、それぞれのスクリプトの連携に気を使わなければなりません。
期待通りに動くものを作ろうとすると、結構な手間が掛かってしまいます。
対して、ウィザードによる対話型、ステップ型のインターフェースは、フローチャート型ほどビジュアルではありませんし、ウィザードの各ステップでスクリプトやコマンドの埋め込みが必要になるのは、フローチャート型と変わりません。しかし、作成手順そのものは非常にシンプルですし、それぞれのステップの目的も明確です。
GUIが威力を発揮するのは、作成された手順書（POLESTAR Automationでは「ジョブ」と呼んでいます）を用いた、実際の運用、特に運用を外注しているようなケースにおいてでしょう。
作成済みのジョブを実行するだけなので、本当に誰でもできてしまいます。
しかも、POLESTAR Automationでは、ジョブの実行結果、つまりそのジョブが成功したか、失敗してしまったのかがすべて記録され、失敗の場合はその原因を容易に把握することもできます。

■手間を掛けずに手順書を作るには？

しかし、そもそもツールを用いても手順書を作れそうなスキルのある人材がいない、でも運用の自動化は叶えたい…そのようなケースでは、どうすべきでしょうか？
それには、POLESTAR Automationが提供しているサンプルジョブを利用するのが近道です。
昨年、弊社POLESTARチームが特に注力したのは、導入してすぐに使える「ジョブテンプレート」の拡充でした。
1年間、各ジャンルにわたるジョブ開発作業を通じ、テンプレートの個数は年末を待たずに1,000個を突破し、本稿執筆時点では1,111個という、非常に切りの良い数字に達しています（狙ったわけではありません。偶然です）。
実は、2016年の記事においても、締めくくりでテンプレートが豊富であることを謳っていたのですが、当時は200もなかったと思います。そこから特に昨年は急激に数が増え、この数字となりました。

と、いうわけで、記事の結論は今回も同じ。
「POLESTAR Automationのテンプレートは、量よりも質と実用性を重視して作成・提供しているものですので、簡単な手直しだけで業務に適用し、本格的な運用自動化を手軽に行うことが可能です。」

まずは2016年当時にはなかった、評価版でお試しください。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

「SRE」の実践へ。「トイル」の元を断つなら、POLESTAR Automation！

公開日:2021/12/14 更新日:2025/04/01

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

今年も残すところ、半月余りとなりました。
昨年の今頃は、来年の今頃（今のことです）になればきっとコロナ禍も落ち着いて、地方や海外出張・旅行なんかも復活しているのかな、などと期待していたものですが、地方はともかく、まだ海外には実質的に行けない状況が続いています。
新型コロナウイルス全体の国内感染者数は秋以降落ち着いたものの、世界規模で見ると、まだまだ感染が沈静化したとは言い難く、11月に突如現れた新たな変異ウイルス「オミクロン」の拡大も、予断を許せません。
来年の今頃（2022年の今頃のことです）こそは、本来の意味で日常を取り戻せているとよいのですが。

さて、今回のテーマは、最近、ITインフラ運用界隈で目や耳にする機会の増えているキーワード「SRE（Site Reliability Engineering）」です。
SRE、そのままカタカナで「サイトリライアビリティエンジニアリング」、ないしは「サイト信頼性エンジニアリング」と紹介されることもあります。「サイト？うちは自社内だけで、外に出しているサイトなんてやっていないのに」という方もいらっしゃるかと思いますが、まずはお読みいただければ幸いです。

■DevOpsとは？

SREを語る前に、まず押さえておきたいのが「DevOps（デブオプス）」です。
特にソフトウェア製品やサービスの開発を行う企業において、ITインフラ運用の自動化に携わられる方なら、実践するか否かにかかわらず、一度はお聞きになったことがあるのではと思います。
DevOpsの細かい定義はいろいろありますが、基本的にはDev（開発）とOps（運用）が一体となって協働し、さまざまなITの課題に取り組もうというものです。
とりわけ、Webの仕組みを通じてユーザーへのサービスが提供される、いわゆるXaaS（サービスとして提供される「何か」。最も有名なのは「サービスとして提供されるソフトウェア」を意味する「SaaS」でしょう）のようなクラウドサービスの開発においては、サービスの設計・開発を行う部門(Dev)と、情報システム部門と呼ばれることも多い、構築・運用部門(Ops)が、縦割りの組織で別々に運営され、連携を取ることもなく動くというのは、考えてみれば非効率的です。
しかし、大きな組織であればあるほど、必要なアプリケーションやミドルウェアをオンプレミスにインストールして開発を行い、そこから生み出される成果物もオンプレミスだった頃のレガシーな縦割り組織体系を引き摺っていることが、まだまだ多いようです。
横の連携が弱く、新たな開発成果が適用されるまでや、何か問題が発生した時の対応などに時間を要し、スピーディに解決しないケースも多かったかと思います。
このような課題の解決に向けて提唱されたのが、DevOpsです。このキーワードがある程度認知されたのは、2015～6年、ちょうどPOLESTAR Automationを世に出そうとしていた頃だったと思います。

図1：開発・運用環境（DevOps）

■運用現場も「開発」からは逃れられない

DevOpsとセットで語られていたのが「継続的デプロイ（ないしは継続的デリバリー）」というワードで、「アジャイル開発」と結び付いています。綿密な事前計画（設計書・仕様書）、明確な日程や目標が設定された従来型の開発スタイル（ウォーターフォール開発と呼ばれます）を捨て、開発成果を直ちにサービス展開し、スピード感を持って、継続して改善を重ねていくのが、DevOpsです。
DevOpsの対象となるインフラは例外なくクラウドであり、DockerやKubernetesといったツールによってインフラをコンテナ化、オブジェクト化し、手順を自動化するのはAnsibleのような、主にCLIに依拠した自動化ツールです。
…と、ここまでの説明をお読みになって「うちはソフトウェア開発企業じゃないから」という方も多いかと思います。
DevOpsはあくまで開発側中心の視点からの運用協働であるといえ、対象となる課題も、XaaSを開発している企業にとってのものが大半だと思いますが、DX（デジタルトランスフォーメーション）に取り組み、推進するにあたっては、出来合いのパッケージやXaaSなどを利用するにしても、それを実際の業務に反映させ、より効果的なDXを推進して行くには「開発」が入ってくることになるはずです。
外部に丸投げでもしない限り、DevOpsからは逃れられない時代になると思いますし、外部に投げることは、スピード感の喪失という結果をもたらすことでしょう。

■DevOps実現への近道「SRE」

では、「開発」に縁の薄い企業がDevOpsに取り組む近道は、ないのでしょうか？
最近、DevOpsとの絡みで注目されているのが、冒頭で触れた「SRE」です。
SREの発祥地は、Google社です。同社の創業事業で、今も主力事業でもある、検索エンジンWebサイトの継続的開発・改善にあたって提唱された、開発と運用に対する方法論です。
SREのSが「サイト」なのは、検索エンジンサイトの開発・運営手法としてGoogle社内で創始されたことに由来しているわけですが、現在ではGmailやGoogleマップ、広告関連などのWebサービス、はてはGoogle Cloudを含むGoogleのあらゆるサービスに、SREの考え方が適用されているようです。
実はSREの歴史はDevOpsとさほど差はないか、あるいはSREの方がやや早いかもしれないぐらいの時期からなのですが、当初はあくまでGoogleの先進的事例として紹介されていました。
広く企業における運用の改善、DXを加速するアクセラレーターとして、SREが有効な手段であることが注目されるようになったのは、ITの世界的トレンドに影響力を持つ調査・コンサルティング企業であるGartner社が取り上げてからでしょう。
GartnerによるSREの定義は「回復力の高い分散システムを構築・運用するために使用される、システムおよびソフトウェア・エンジニアリングの複数の原則から成る方法論」だそうです。
GoogleにおけるSREチームは、運用管理を担当しているものの、開発系のエンジニアで構成されているそうです。約50%は本来の開発業務もやりながら、残りの約50%を運用に充てるという業務配分です。これはすなわち、DevOpsに他なりません。
つまり、SREとはDevOpsと対立するものではなく、DevOpsを実践するための行動方針、方法論こそ、SREといえます。

図2：DevOps実現への近道「SRE」

■「トイル」とは何か

近年のGoogleによるSREに関する説明では、「トイル」という概念が頻出するようになりました。
トイル(toil)という英単語には、単に「労働」の意味もありますが、「労苦」「辛苦」のようなニュアンスで使われることが多いようです。
Google Cloudのブログでは、トイルを「手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業」と定義し、実例として、以下のようなものを挙げています。

– 割り当てリクエストの処理
– データベーススキーマ変更の適用
– 重要性の低いモニタリングアラートの確認
– プレイブックからのコマンドのコピーと貼り付け

つまり、単純ながら分量が多く、規模が拡大すればするほど増える雑多な作業を、トイルと定義しています。
前述のブログ記事では、高度なスキルを要する困難な作業は、トイルではないとしています。むしろ、そういった開発・運用上重要かつ有意義、付加価値の高い作業への取り組みを妨げる要因となっているのが、日常の運用作業におけるトイルの多さというわけです。

ちなみに、POLESTARではSREと運用自動化については「最新動向」のページなどでも情報公開を行っていますので、合わせてご覧くだされば幸いです。

■POLESTAR Automationこそ、SREに最適なツール

トイルとされる手作業、繰り返しの多い作業。確かに、それらに人を配置し、長期にわたってやり続けるとしても、何の価値もありませんし、何かを生み出しもしません。
トイルという用語は、今回初めて使用しましたが、自動化によってトイルを極限まで減少させたり、なくしたりすることは、まさにITインフラ運用自動化ソリューション・POLESTAR Automationが、発売以来訴求し続けてきたテーマでもあります。

運用自動化こそが、トイルの低減・撲滅、DevOps推進とDX加速の第一歩です。
POLESTAR Automationで、SREを始めてみませんか？

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

AIでITインフラ運用は可能か？/Webhookについて

公開日:2021/11/16 更新日:2025/04/01

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

「アイの歌声を聴かせて」。10月29日から上映中のアニメ映画で、自分も先日見てきたのですが、見た人の評価は非常に高いにもかかわらず（各レビューサイトでも5点中4点前後）、観客動員は今ひとつ、どころか…という、残念な状況になっている作品です。
いわゆる「スマートシティ」の実証実験が行われている「景部市」（新潟県の佐渡ヶ島がモデルらしい）。何でも自動でやってくれるスマートホームで暮らす女子高生・サトミ（声・福原遥）が自動運転バスで通う高校に、転校生としてやってきた性格の明るく、頭脳明晰で歌が得意、スポーツも万能な美少女・シオン（声・土屋太鳳）は、実は最終テスト中のAI（人工知能）搭載アンドロイドで…という設定です。
シンギュラリティ（AIが自律性や創造性を持つこと）一歩手前のAIが主人公ですが、話自体は高校が舞台のドタバタもある青春もので、タイトルの通り、歌がキーになっています。土屋太鳳が猛練習を経て自ら歌ったという楽曲も良いですし、ストーリーも映画全体としてもよくできていて、後味も良い作品なのですが、なぜ客足が伸びないのか…
マーケティング戦略や広告宣伝などの側面も含め、いろいろと示唆されるところの多い映画です。

■「運用自動化って、AIですか？」

先日、毎年恒例の「Japan IT Week秋」が開催され、弊社も2017年の初出展から5年連続、5回目となるブースを出展しました。
新型コロナウイルスの感染者数は大幅に減少したものの、例年大型のブースを出展している大手企業さんの多くがまだ戻ってきていないこともあってか、規模は小さめ、来場者数も昨年よりはマシという程度でしたが、弊社ブースには予想を上回る多くの方々にご来場いただき、この場をお借りして感謝を申し上げます。
ところで、ブースを出すたびにご来場の方から、毎回1～2回は「運用自動化ってAIで実現しているのですか？」とか「インフラ運用をAIで完全自動化することは可能なのですか？」といった、AI絡みのご質問をいただきます。
POLESTAR Automationは発売以来、「ITインフラ運用自動化ソリューション」としてご案内していますし、AI全般も近年、実用化に勢いが付いてきていることもあって、「自動化=AI」と結びついてしまうのもやむなしでしょう。

結論からいえば、POLESTAR AutomationにはAIは搭載されていません。
他社も含め、同じジャンルにカテゴライズされる運用自動化・構成管理ツールで、AIを搭載しているものはないでしょう。
運用ツールの中でも、監視（モニタリング）系ですと、機械学習による障害予測機能を搭載しているものがあります。CPU負荷やネットワークのトラフィック、ストレージ残量などのモニタリングデータを長期的に収集して機械学習し、その学習データを基盤とする推論エンジンにより、日頃の監視の中で障害発生の予兆を見つけ出そう、というコンセプトです。
POLESTAR Automationの開発元・Nkia社でも、そうした機械学習搭載の監視ツールを開発していて、以前数回、展示会に参考出品させていただきました。
セキュリティの分野でも、ログの解析などにAIを導入し、ログの内容からの振る舞い検知により、セキュリティ上の脅威を発見しようとするものがあります。「SIEM」とか「SOAR」「UEBA」と呼ばれるものがそれです。
システム運用全般において、運用自動化・構成管理以外のジャンルでは、AIの活用が着々と広がってきているようです。

■運用自動化にAIが介在しない理由

では、なぜ運用自動化には、AIが使われないのでしょうか？
まず、運用自動化の基盤は、構成情報の収集、コマンドやスクリプトの定期的な投入といった、人（運用現場の担当者）の行う、単純ながらも手間のかかる作業（ジョブ）の実行プロセスを自動化することで成立しているからです。頻繁に繰り返される単純作業を自動的に行うのに、AIなどによる学習や推論はオーバースペックです。
次に、対象が常に新しく、予測不能なものもあるからです。システム運用上で起こる障害の原因は、過去の監視データの分析により、ある程度の類型化が可能ですが、運用自動化ツールの活躍の場でもある障害からの復旧作業は、そうではありません。
OSやミドルウェア、アプリケーション、それらに対するパッチなどは、常に新しいものが出てきますし、障害の対処方法も毎回異なります。AI搭載監視ツールが発見できるのは過去の事例に基づく障害であり、新しい環境で起こりうる障害の根本原因を事前に発見したり、事後に自動的に対処するのはシステムの自己修復と同じであり、それこそシンギュラリティの話になると思います。
最後に、判断能力です。システム障害からの復旧に対して、誰かが判断しなければなりません。ひと口に復旧といっても、障害発生直後に100%の復旧は困難な場合も多く、まずは最低限動くレベルで妥協し、取り急ぎの復旧を図り、後で原因をしっかり追及した上で100%を目指す、という段階的な対応が行われるケースが多いかと思います。
運用自動化ツールは復旧支援のフェーズで使われるでしょうが、作業内容や手順を誤ると、期待通りの結果にはならないかもしれません。
どう対処するかは、対策期間や結果など、多角的・多面的な視点からの判断が求められます。AIにはまだ難しいでしょう。

以上、現状のインフラ運用は人の手や経験値に頼るところが大きいです。
運用自動化・構成管理ツールとは、人力運用を補助する支援ツール（道具）であり、ソリューション（解決策）であるといえます。このツールを動かすのは、あくまで人間なのです。

■「Webhook」ってご存知ですか？ – 外部ツールからのPOLESTAR活用

さて、AIについてはここまでにして、話題を変えます。
皆様は「Webhook（ウェブフック）」という用語を耳や目にされたことはあるでしょうか？
POLESTAR Automation V3以降にはAPI(REST API)が搭載されるようになり、ZabbixやRedmineをはじめとして、多数の連携事例が出てきています。
このAPIというのは、連携元から連携相手にリクエスト（要求）を送り、返ってくる結果に応じてアクションを起こすというのが基本です。
POLESTAR Automationにおけるジョブの実行を例に取ると、何かアクションを起こそうとすると、POLESTAR AutomationのAPIから連携相手のツールなどにリクエストを送り、その結果を受けて目的のジョブを実行することになります。
対してWebhookというのは、連携相手側で条件を設定しておき、その条件に合致（フック）するイベントが発生すると、連携元に通知が行われるというものです。
連携元ツール、ここではPOLESTAR Automationから見た場合、能動的なのがAPI、受動的なのがWebhookといえます。連携先のツール側から見れば、関係は逆になります。

実は、最近お客様より、とある他社製監視ツールからの障害通知をPOLESTAR Automationで受け取って、ジョブを実行させるようにできないか、とのご要望をいただきました。
このツールにもAPIがあるのですが、同ツールからのリクエスト発行によって外部のデバイスを登録したり、イベントやユーザーを追加したり、といった目的で使用されるもので、監視のアラートをリクエストとして送信する機能はありませんでした。
POLESTAR Automationに何か送信する機能はないか、もう少し調べてみると、Webhookによる通知機能があることに気付いたので、POLESTARチームの若く有能なエンジニアに伝えたところ、すぐに同ツールの評価版をダウンロードして環境構築し、その日のうちに連携を実現させてしまいました。

連携の流れは、以下の通りとなります。

1.【POLESTAR側】クレデンシャル管理でREST APIを作成

2.【POLESTAR側】連携相手のツールが通知してくる作業に応じたジョブ（障害回復など）を作成

3.【連携相手側】連携相手のツールで、Webhookによるアラート通知の条件を新規作成し 1. で作成したPOLESTARのAPI情報を記述、対象サービスなどを設定（詳細は多少端折っています）

4.【連携相手側】実際に障害が発生するとPOLESTAR側にWebhookで通知

5.【POLESTAR側】 2. で作成ジョブが自動的に起動

6.【連携相手側】アラートの解決を確認

と、いうわけで、REST APIの仕様が合わないツールでも、そのツールがWebhookの機能（Webhookではなく「API」など他の名称で提供されている場合もあるようです）を持っているならば、POLESTAR Automationと連携可能です。
自社でお使いの既存ツールをPOLESTARと組み合わせ、そのツールの発生させるイベントをトリガーとして、ジョブによる自動化を実現させたい方。ぜひとも弊社POLESTARチームにご相談ください。

ちなみに冒頭でご紹介した「アイの歌声を聴かせて」、全国の主要なシネマコンプレックスでも、もう1日1回程度の上映になっているところが大半のようです。以前ご紹介したメタバースがテーマの「竜とそばかすの姫」（こちらは興行収入65億円突破）同様、ITのお仕事に従事されている方にとっては身近な内容も多く、楽しめると思います。本稿を読んで興味を持たれた方、ぜひとも上映が続いているうちに、映画館に足を運んでみませんか。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

ものづくりのDX。POLESTARが製造業のレガシーシステム可視化に向いている理由とは。

公開日:2021/11/15 更新日:2025/04/01

経済産業省「2025年の崖」*では、「既存システムの複雑化・ブラックボックス化への対策」と「デジタル技術を活用したビジネスモデルへの新たな取り組み」を行わないと、2025年以降最大12兆円/年の経済損失が生じるという可能性について警鐘を鳴らしている。
*「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（経済産業省2018年）

そして、全体の約８割の企業がレガシーシステムを抱えていることから、「レガシーシステムが存在することによるリスクや課題が多いこと」、そして「レガシーシステムの保守・運用に多大なリソースがとられていること」が、貴重な「IT人材資源」の“浪費”につながっているとしている。

製造業のDXの目的、ゴールとは？

製造業ではレガシーシステムが残っている企業の割合が多く、また、その維持に偏重する傾向が顕著である。多くの企業では、まず身の回りからDXへの取り組みに着手する、中期計画に盛り込むなどして、対応に躍起になっているが、その方法論はマチマチのようである。

さて、DXの目的、ゴールとは何か。前述の「2025年の崖」では、「レガシーシステムの保守・運用に充てられている人材・資金を、新たなデジタル技術の活用にシフト」し、「さまざまなデータを活用」し、「迅速なビジネスモデル変革に対処できるようにする」、というあるべき姿が示されている。
現実的には、自社のあるべき姿とは何なのか、どこから手を付けるべきなのか、と困っている企業も多いのではないだろうか。

長年使用してきた業務システムの老朽化や複雑化という現状から、一足飛びにDXへと移行することは困難である。そこで、まずは現状の可視化から取り組み、その上であるべき姿とのギャップを確認し、課題の克服や実現ロードマップを作成する必要があるだろう。
したがって、自社のシステムが現在どうなっているのかを、的確に把握しておくことが大前提である。

構成管理の自動化ツールは現状把握に必須

そうした現状の把握・可視化で必要となるのが、構成管理を自動化するツールである。構成管理では、管理対象となるサーバーやネットワーク機器の様々な情報を収集し、データベース化し、レポーティングする。どこにどんなOSやアプリケーションがあり、バージョンは何なのか。どのようなハードウェアがあり、インターフェースはどうなっているのか、などといった最新の情報を収集することが可能である。

構成管理については、手作業でアナログ的な集計を行っているケースが散見されるが、いつの時点で収集した情報なのか、果たしてそれが正確なのかの確認が大変で、信憑性の問題もある。

そこで、製造業などものづくりのDXを支援する構成管理ツールとしておすすめなのが、インフラ運用自動化ツールPOLESTAR Automation（以下POLESTAR）を利用する方法である。
では、なぜPOLESTARが製造業のレガシーシステム可視化に向いているのだろうか？

構成情報の自動取得による現状の見える化（構成管理）

レガシーシステムの刷新、クラウドへの移行などにあたり、現状はどうなっているのか。インフラを移行するとしたら、どれくらいのリソースが必要で、いくらくらいのコストがかかりそうなのかの算出根拠になる。また、EOS/EOLの可能性があれば、どこから着手すべきなのかの優先順位、それぞれのOS、ミドルウェア、アプリケーションにおける依存関係なども、重要な情報となる。これらのすべてを、人海戦術により調べ上げるのは大変な手間と時間がかかる。

よって、POLESTARのような構成管理ツールで自動収集し、最新情報にいつでもアクセスできるようにしておくことが望ましい。

＜構成情報の収集＞
https://polestar.widetec.com/whitepaper_vol8_cm

800種類を超えるサンプルジョブ

構成管理ツールのデフォルト機能で直接取得できる情報もあるが、個別にスクリプトを実行しないと収集できない情報もある。
POLESTARには既に800種類を超える自動化サンプルジョブ（無償）が用意されており、これらを利用することで、機器シリアル番号の収集やセキュリティソフト情報、OpenSSLのバージョン、ネットワーク機器のConfigなど、収集にひと手間要する情報も、簡単に収集できる。

＜サンプルジョブ＞
https://polestar.widetec.com/polestar-automation_info/about_job#sample_job

また、ユーザーが簡単にジョブを作成できる「ウィザード」と呼ばれる機能があり、マウス操作による対話型でジョブを作成できる。

＜Windows Updateジョブ＞
https://polestar.widetec.com/polestar-automation_info/about_job/windowsupdatejob

閉域網でも利用可能

製造拠点では、機密保護のため、インターネットに露出しないプライベートLAN、つまり閉域網上にインフラを構築している場合が多い。インターネットから遮断されているため、最新パッチ情報の収集やパッチのダウンロードを直接行うことができない。

POLESTARでは、一旦ダウンロードしておいたファイルやパッチをライブラリに置いておくことで、ジョブを用いて自動的に配布、導入まで実現可能である。POLESTARをオンプレミスに置いておき、異なった閉域網ネットワークセグメント間はVPN等で接続することで、一元的な管理も可能となる。

＜ファイル配布ジョブ＞
https://polestar.widetec.com/polestar-automation_info/about_job/filedistribution

古いOSにも対応

閉域網で利用している場合、セキュリティ上の懸念は少ないため、サポート期限の満了した古いOSで動作しているWindowsやLinux、商用UNIXサーバーが残っている場合も多々ある。

POLESTARであれば、Windows Server 2000以降、LinuxならKernel 2.4以降から管理対象とすることができる。またUNIXはAIX、SunOS(Solaris)、HP-UXのすべてに対応している。また、ネットワーク機器についてはSNMPおよび標準MIBにより構成情報が取得可能であれば、対応可能である。

＜管理対象サーバー＞
https://polestar.widetec.com/polestar-automation_info/system-configuration

追加情報の管理

POLESTARでは、各サーバーやネットワーク機器に、障害履歴や保守契約情報、ロケーションなどの付加的な情報を紐付けし、一括して管理できる。

ユーザーが自由にテキスト入力できるデフォルト・スペースに加え、必要に応じて入力可能なプロパティを自由に追加できるため、情報の管理も容易になっている。入力した情報は報告書作成機能によりExcel、PDF、Wordファイルとして出力できるほか、ライブオブジェクト照会機能で結果をその場でExcelに出力でき、デジタル情報としての管理・保管も容易である。

＜ライブオブジェクト照会＞
https://polestar.widetec.com/case-study/use-case/liveobject

以上に加え、POLESTARは操作がほとんどマウスだけで可能で、属人化に陥りにくいことや、大量のデバイスがあってもリーズナブルに導入いただける価格が利点である。
構成管理だけでなくジョブスケジューラ機能も使いやすいため、DXへのステップアップ時や、DX完了後にも、継続的にご利用いただける仕様となっている。

このように、ものづくりのDXを進めるための最初のステップとして、レガシーシステムの可視化にPOLESTARは最適な選択肢である。
以上

一覧へ

Windows 11正式版リリース！インストール&ちょっとしたTips

公開日:2021/10/19 更新日:2025/04/01

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

10月5日、Windows 11正式版がリリースされましたね。
ちょうどその日はテレワークで、自宅にいましたので、仕事の合間にデスクトップとノートPC、それぞれ1台ずつをWindows 11に更新してみました。オンラインでのアップグレードはあまりに呆気なく終わり、拍子抜けするほどでした。
Insider Previewの頃は、Windows 10が動く環境では大体普通にインストールできていたのですが、その時点から予告されていた通り、正式版では「TPM 2.0」が本当に存在している必要があり、あとインストール可能なCPUの世代についても、予告通りの制限が掛かっていました。
POLESTARチームで使用しているテスト用のマシンは2017年前後に購入したものがメインで、CPUの制限に微妙に引っ掛かっているものばかりなのですが。唯一、条件を満たすPCがあったので、自宅のPCにインストールした翌日、会社でもインストールしてみました。

POLESTARチーム唯一のWindows 11対応PCにインストールしたWindows 11

【POLESTARチーム唯一の対応PCにインストールしたWindows 11】

■Windows 11のTips（というほどでもないですが）

Windows 11のWindows 10に対する変更点というと、最も注目されていたのは、Androidスマホやタブレット用のアプリがそのまま動く機能だったと思われますが、既にあちこちで報じられている通りで、リリースと同時での提供は見送られました。
変更箇所としては、Skypeがなくなって個人用Microsoft Teamsが入ったとか、いろいろあるのですが、目立つのはウィンドウやアイコンなど、UIデザインの変更でしょう。

1) スタートボタンの位置を「左端」に

Windows 10からWindows 11にして、まず最初に戸惑うのは、スタートボタンとその右側にあるアイコンの配置が、タスクバーの「中央」に変わったことでしょう。
Windows 9xの時代から、多くの方はスタートボタンは左端にあるのが当たり前とお考えかと思います。
スタートボタンを左端に持っていくには、タスクバーを右クリックすると現れる「タスクバーの設定」（または「設定」のサブ項目「個人用設定」）から変更できます。
「タスクバーの動作」を選択し、「タスクバーの配置」を「中央揃え」から「左揃え」に変更するだけで、スタートボタンが瞬時に左端に移動します。

【中央から左端に移動したスタートボタン】

しかし、Windows 10のように、スタートボタンのあるタスクバーを画面の「上」「左」「右」に配置させることは、結構難しいです。実は上には持っていけるようですが、レジストリの変更を伴うので、ここでは取り上げません。

2) エクスプローラーでアイコン/ファイルの間隔を詰める

Windows 11ではエクスプローラー（ファイルエクスプローラー）のUIも大きく変更され、ました。テキストメニューがなくなり、アイコンの下にアイコンテキストが添えられていた太いツールバーは、アイコンだけになって、細くなりました。
反面、アイコンやファイル名の項目表示を「一覧」以下に設定すると、フォルダー内の項目の表示間隔が広くなっています。こちらの方が見やすい、という方も多いかもしれませんが、フォルダーウィンドウ内の情報量、つまり1つのウィンドウに表示されるファイルの数は確実に少なくなりますので、ファイルが多いフォルダーでは、スクロールの手間が増えることになります。
この間隔を詰め、Windows 10以前と同等にするには、ツールバー右端から2つ目の「表示」にある「コンパクトビュー」を選択し、チェックの付いた状態にします。

【フォルダーに表示されるファイル名とアイコンの間隔、広くて見やすい方と情報量の多い方。お好みでどうぞ】

3) Windows 10ライクなスタートメニューに戻したいが…

Insider Previewの頃のWindows 11では、レジストリ操作によってWindows 10時代のスタートメニューに戻すことが可能でしたが、バージョンが更新される過程で削除されてしまいました。
正式版Windows 11では、Windows 10と同じデザインのスタートメニューは提供されていません。なんと、プログラムごと削除されてしまったようです。
Windows 10ではなく、Windows 7以前のスタートメニューでよければ、まず「Windows Tweaker」でタスクバーを「Classic Taskbar」（Windows 10スタイル）に設定します。
しかし、前述の通りWindows 10スタイルのスタートメニューはなくなっていますので、スタートボタンを押しても反応しません。旧スタートメニューの代替として、「Open Shell」をインストールすれば、Windows 7風やXP風などのスタートメニューが使えるようになります。
これらはサードパーティ製のツールですので、積極的におすすめはしませんが、参考としてご紹介しておきます。

【Windows 10ライクなタスクバー+Open Shell。Windows XPや7的なデザインのスタートメニューが利用可能】

■どうしても非対応のPCにWindows 11を入れたい時は

Windows 10は、かなり古いPCでも動いていました。10年前、それまでのCPUとは一線を画する性能で一世を風靡したIntelの第2世代Coreプロセッサ（コードネームSandy Bridgeの方が通用しているでしょう）はもちろん、それ以前の第1世代Coreや、さらに古いCore2Duo、はては「ネットブック」と呼ばれた、Atomプロセッサ搭載のロースペックノートPCなどで常用しているという話も耳にしたものです。これらの中には、いわゆる「大型アップデート」の過程で切り捨てられたものもありました。
しかし、Windows 11のCPU対応条件は、予想以上に厳しいものでした。AMD会心のヒット作となった初代Ryzenや、まだ比較的新しいと思われていた第7世代（Skylake / Kaby Lake）も一部を除き対象外となりました。
これではあんまりだ、という声がMicrosoftに届いたのか、Windows 11正式版のリリース開始直後に、動作条件から外れた非対応PCでWindows 11をインストールする方法が紹介されました。Microsoftが紹介するオフィシャルな手順ですが、アップデートなどの保証の一切ない、自己責任での方法となります。
こちらも積極的にはおすすめしませんが、自宅に1台、Haswell（Intel 第4世代Core）のPCがあるので、試してみました。今のところ、普通に動いています。

【どうしても非対応のPCにWindows 11を入れたい時は】

■今年も「Japan IT Week 秋」に出展します！

と、いうわけで、今回はほぼWindows 11オンリーの記事になってしまいましたが、アリバイ的に、左端スタートメニュー環境でMicrosoft EdgeからアクセスしたPOLESTAR AutomationのWeb UIスクリーンショットを掲載しておきます。

【左端スタートメニュー環境でMicrosoft EdgeからアクセスしたPOLESTAR AutomationのWeb UIスクリーンショット】

なお、今年も10月27日（水）から3日間、千葉・幕張メッセで「第12回 Japan IT Week 秋」が開催されます。
昨年、コロナ禍の影響で全体の来場者数はかなり減っていたにも拘わらず、POLESTAR Automationブースに来場された方は予想を上回っていたということがありました。
本稿執筆時点では、弊社のある東京都内での新型コロナウイルス感染者数は2桁にまで減少しています。これから寒い時期を迎え、まだ油断はできないと思いますが、どうかお時間のある方は、POLESTARブース（小間番号28-56）にご来場いただければ幸いです。

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

「点検」の自動化ができるのは、POLESTAR Automation

公開日:2021/09/28 更新日:2025/04/01

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

半導体不足が昨今の話題ですが、半導体チップ、特にCPUやGPU、SoCといった「心臓部」とされるものの多くは、台湾からやってきています。その安定した供給を長期にわたって支えてきた陰の立役者？とも言われるのが、「乖乖(Kuai Kuai)」という台湾のコーンスナック菓子です。
おそらく10数年前頃から、まずITインフラの管理者を中心に、緑色の袋に入った「乖乖（ココナツ味）」を置いておくと、トラブルに見舞われずに済む、という一種の都市伝説が広まりました。お守りのような扱いですが、今では世界有数の半導体組立メーカーであるTSMC（台湾積体電路製造）をはじめ、多種多様な工場の生産ラインなどにも、緑の「乖乖」の袋が置かれるようになっているそうです。
この「乖乖」伝説、去る4月には、ついに英BBCを通じて世界に発信され、台湾のSNSでは「台湾の最高機密が海外にバレた！」と大いに話題になった模様です。
先日、その「乖乖」が手に入ったので、さっそく「願い事」を油性マジックで書いて、POLESTARチームのテスト用サーバー・ネットワーク機器群の上に置いてみました。

POLESTARチームのテスト用機器群（一部）です。

■システム障害対策の基本「モニタリング（監視）」

さて、システム障害への対策というと、弊社でもパートナーとなっている「Zabbix」をはじめとする、モニタリング（監視）ツールの導入がまず思い出されると思います。
商用や社内の基幹システムにおいては、何らかの監視手段がほぼ例外なく導入されていることでしょう。
監視の基本といえるのは、システムが停止していないかどうかを把握するための「死活監視」でしょう。監視ツールを用意するまでもなく、pingコマンドを発行するスクリプトを一定の間隔で起動させるだけで、死活監視はできます。
実際、規模の小さいシステムで、こうしたpingスクリプトだけでシンプルに死活監視を済ませているというケースも結構耳にしますが、Zabbixなどを用いると、定期的な死活監視を自動でやってくれる上に、ログも見やすい形で残りますので、個人的にはツールによる監視をおすすめしたいと思います。
Zabbix（他の商用監視ツールなども同様かと思いますが）には死活監視だけでなく、サーバーのCPUやメモリの占有率、ネットワークのトラフィックなど、システムのパフォーマンスに関わる部分の監視機能（性能監視、パフォーマンス監視などと呼ばれます）もあります。ログ取得はもちろん、リアルタイムのグラフ表示機能もありますので、何か異常があればそこから読み取ることもできます。
しかし、監視という作業の主目的は、発生した障害を発見することにあります。死活監視は、システムダウン発生に気づくのが目的です。復旧作業はその後です。
性能監視については、長期にわたるパフォーマンスのモニタリングから、システムに内在する異常を予見する手段にはなりえますが、こちらもパフォーマンス異常の発見のほうが本質といえます。

■障害を未然に防ぎ、障害発生前に対策を立てられる…「点検」の意義

自動車の定期点検、工場の生産ライン点検のように、機械・設備の分野では「点検」が一定の間隔で行われます。消耗部品なども多く、いつかは壊れる、突然予兆もなく壊れてしまうこともある、という前提のもと、壊れそうな箇所を事前に発見したり、部品を事前に交換したり、という目的で実施されるものです。
サーバーやネットワーク機器など、ITインフラを構成する機器群についても、「点検」は壊れる前にやっておいた方が良いに越したことはありません。もちろん、ソフトウェアの脆弱性点検、OSやパッチのバージョン情報収集、デバイスごとの構成情報の定期的な収集といった、ITインフラに特有のものもあります。
POLESTAR Automationが、発売以来他の運用自動化ツールとの違い、差別化ポイントとしてアピールし続けてきたのが、「点検」に特化した機能の存在です。
手作業で実施していた運用タスクを自動化するために、スクリプトやコードを書き、それを対象のサーバーやネットワーク機器に送って回す、というのが運用自動化ツールの基本的な仕組みであり、POLESTAR Automationも同様です。
POLESTAR Automationにあって、他のツールにはあまり見られないのは、点検に特化したダッシュボードと、点検のための豊富なジョブテンプレート群、そして結果収集やExcel形式ファイルへの出力、レポーティング機能などです。
毎日、毎週など、一定間隔で点検ジョブを回し、その結果を収集・分析すれば、個別のデバイスの障害予測も立てやすく、システム全体の安定運用にもつながるでしょう。
障害を未然に防ぎ、実際に障害が起きる前に対策を実施できる。それがITインフラ運用管理における「点検」であり、POLESTAR Automationは「点検」を最も容易に実施できる運用管理ツールのひとつです。

図：日頃の点検に役立つ、POLESTAR Automationならではのダッシュボード

■絶対に壊れないシステムなど、ありえない！

ハードディスクドライブなどを除き、可動部品の少ないITインフラ機器は壊れにくく、停電など外部的な要因がない限り、数年間一度も電源を落とすことなく、半永久的に稼働し続けるものも少なくないでしょう。
しかし、壊れにくいとされる突発的な負荷、それに伴う発熱などによって積み重なるダメージが、思わぬ故障を呼ぶこともあります。
システム障害に備えるには、監視ツールの活用とともに、日頃からの点検が有用です。
システムの安定運用に、POLESTAR Automationをお役立てください。

＜おすすめコンテンツ＞
・活用事例：点検ポリシーを設定してみる！

ITインフラ運用ご担当者様にお勧めのコンテンツ

一覧へ

どうする？ CentOS Linux後継問題

公開日:2021/08/24 更新日:2025/04/01

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

まずは久々の映画ネタですが、皆様は夏の大作アニメーション「竜とそばかすの姫」（細田守監督）はご覧になられたでしょうか？
高知県の限界集落に住む地味な女子高生「すず」が、インターネット上に作られた、全世界で50億人以上が集う仮想世界「U」のスター「ベル」となって世界的な人気者になるのですが、そこに「竜」の姿をした、皆から恐れられる謎の存在が現れ…という話です。
細田監督といえば、やはりインターネット上の仮想世界をテーマとした「サマーウォーズ」もヒットさせ、今でも名作アニメとして、何度もテレビで放映されています。あれに負けず劣らず、面白い作品だと思います。Uの中でベル＝すずが歌うシーンが、とにかく圧巻ですね。あれは劇場の大きなスクリーンで見てこそのものでしょう。
本稿執筆中に、興行収入50億円を突破したというニュースも流れました。IT業界の方なら、ネット上の仮想世界という設定にも、違和感なく馴染めることでしょう。まだの方はぜひ。

■Linuxといえば「CentOS」、でしたが…

さて、いつものノリならスクリーンの向こうの「仮想世界」からOSの「仮想化」の話題に持って行くところですが、仮想化については前回も触れましたし、前回と前々回はWindowsの話題がメインでしたので、今回はLinux OSのお話です。

Linuxにはさまざまなディストリビューション（略してディストロとかディストリとも）がありますが、中でも国内の企業において社内ユースで人気が高いのは「CentOS（セントオーエス）」だと思います。海外ではLinuxのメジャーディストロでもう一方の雄「Ubuntu（ウブントゥ、ウブンツ）」も広く使われているようですが、日本ではどこに行ってもCentOSばかりのような印象で、弊社でもそうです。
周知の通り、CentOSは商用Linuxディストロの代表格、「RHEL（レルと呼ばれることが多いようです）」ことRed Hat Enterprise Linuxの「クローン」です。RHELのソースコードからRed Hat社の名称や著作権表記など、プロプライエタリ（権利の及ぶ部分）要素を削除してビルド（コンパイル）したものですので、ほぼ商用RHELと同一のOSということができます。セキュリティパッチなどの提供期間も長く、現在主流と思われるCentOS 7も、2024年4月30日まではサポートが継続されます。
もちろん、完全無料のOSなので、コミュニティを除くテクニカルサポートはありませんが、特に国内にはCentOSを常用しているユーザーが多いので、何かトラブルに遭遇しても、大抵のことは日本語によるネット検索で解決できます。

■え？ CentOSってなくなるの？

そんな有り難い存在のCentOSですが、昨年の暮れも差し迫る2020年12月8日、衝撃的なニュースが世界を駆け巡りました。CentOSの開発を手掛けるコミュニティCentOS Projectが、RHEL現行バージョンクローンとしてのCentOS開発・サポートを2021年12月31日をもって停止し、開発を2019年9月に発表されたRHELのアップストリーム（先行開発）ブランチである「CentOS Stream」に絞ると発表したのです。
従来（現行バージョンの8まで）のCentOSは、RHELのリビルドでしたので、リリースやパッチの配布は、本家RHELより若干タイミングが遅れて行われていました。それがCentOS Streamでは関係が逆転し、RHELに常に先行する形となります。
しかも、バージョン更新方式も従来とは異なる「ローリングリリースモデル」で、8.1, 8.2, 8.3…のような小数点以下のマイナーバージョンはなくなり、同じメジャーバージョン（現行は8ですが既に9の開発も始まっている模様）の中で、そのメジャーバージョンのサポートが終了するまで、新しいコードが随時リリースされて行くことになります。
RHELやCentOSのさらに先行リリース的な位置づけとして、「Fedora（フェドラ）」というディストロがありますが、新しいCentOS Streamは、FedoraとRHELの中間に位置づけられるリリースというわけです。

図：Fedora, CentOS Stream, RHEL リリースの流れ
Diagram licensed CC-SA: https://creativecommons.org/licenses/by-sa/4.0/

CentOSが人気を集めたのは、バージョンアップの間隔やコードの品質・安定性が、商用版のRHELと基本的にほぼ同一であることと、サポート期間の長さからでした。しかし、CentOS StreamはRHELの先行かつローリングリリースになることから、長期でバージョンを固定しての運用は、もはや困難です。

■CentOS 7からの移行先、何がいい？

そこで、従来版CentOSの開発中止発表から間を置かずして、従来からのCentOSと同様なRHELクローンとしてのOSSを求めるユーザーを対象に、CentOSに代わる新しいディストロを立ち上げるコミュニティがいくつか出てきています。
今のところ、有力と思われるのは、CentOS Projectの創始者が立ち上げた「Rocky Linux」と、主にホスティングサービスに特化したディストロを提供してきたCloudLinux社の支援による「AlmaLinux」の2つでしょう。

図：AlmaLinuxとRocky Linuxの公式サイト。
いずれも2021年8月23日時点で日本語対応（前者は機械翻訳調ですが…）

いずれのディストロも、RHELのクローンとしてローリング型ではない通常のマイナーバージョン型でリリースされることを謳い、最初のリリースとなるRHEL 8相当バージョンのサポート提供も、本家と同様の2029年までと宣言しています。
どちらが普及・定着するかは、現時点では何とも言えませんが、2024年に迎えるCentOS 7のサポート終了までには白黒が付いているかもしれませんし、案外、両方が併存しているのかもしれません。
CentOS 7までと同様の、バージョンを長期間固定しての運用を望むなら、これらの後継ディストロから選ぶことになりそうです。
一方、テスト用途が主で、現在CentOS 8を利用中の方なら、いっそCentOS Streamに移行してしまうのもありかもしれません。アップデートで常に最新のソースが降ってきますし、いずれはRHELの本番に適用されるソースということで、先を睨んだ開発テスト環境などには、むしろ適しているかもしれません。

■OS移行後の環境構築も、POLESTAR Automationで

さて、新しいOSの環境構築では、やること、入れるものは大体決まっているかと思いますが、定型的な環境のセットアップにも、POLESTAR Automationが便利です。
POLESTAR Automationのスクリプトジョブを用いると、各種の環境設定や必要なミドルウェア、アプリケーション等のインストール、yum/dnfでインストールされないパッケージやConfigファイル等の配布、そしてインストール後の動作確認まで、自動化することができます。

図：POLESTAR Automationのスクリプトジョブ。
POLESTARチームのエンジニアが作ったものが、もう511件にもなったとは（各OS対応用の合計です）

と、いうわけで、まずは評価版でお試しを！

＜おすすめコンテンツ＞
・活用事例：LinuxをGUIで操作する

ITインフラ運用ご担当者様にお勧めのコンテンツ