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

このコラムはある時期以降、「月1回」書くのが「ノルマ」になっています。
以前は好きな時に、好きな内容で書いていたのですが、POLESTARチームから月1回のメルマガを出し始めた頃から、なし崩し的にそうなってしまいました。

今はWidefoneの立ち上げ中で、そちらが業務の大半を占めているので、運用管理業界から少し離れてしまっている状態ですが、ともあれ、継続は力なりということで、これまで続けてきています。しかし、今回はネタがなかなか思い浮かばず、山積する業務が止まってしまうほどでした。もう6年やっていますが、これほどテーマ探しで悩んでしまったのは初めてです。

■日本政府認定のパブリッククラウドは、すべて米国系に

コラムのネタ出しで悩んでいる間に読んだネット記事に、こういうものがありました。

政府共通のクラウド基盤、国産サービスの応札は「なかった」　河野大臣がコメント
https://www.itmedia.co.jp/news/articles/2210/05/news084.html 出典：ITmedia（2022年10月05日 10時51分 公開）

2回目となる政府認定パブリッククラウドサービス「ガバメントクラウド」の応札者に、またも日本のクラウドベンダーが含まれていなかった、という内容で、河野太郎デジタル相の記者会見を記事にしたものですが、大変残念に思いました。

選ばれたのはAWS、Google Cloud(GCP)、Microsoft Azureといういわゆる「3大クラウド」と、永年無料でサーバー2インスタンスを使わせてもらえる（実は自分も大いにお世話になっています）ことでも知られるOracle Cloudの4つでした。

ガバメントクラウドに応札するには、日本政府の定めたセキュリティ基準「ISMAP（ずっとアイスマップだと思っていたのですが、イスマップと読むそうです。SMAPはスマップでいいのですね）」を満たす必要があります。 ISMAPで認定されたクラウドサービスのリスト（https://www.ismap.go.jp/csm?id=cloud_service_list）を見ると、日本企業のパブリッククラウドも結構入っています。しかし、それでもガバメントクラウドに応札した企業はゼロでした。

ガバメントクラウドについては、ISMAPに加え、業務の継続性など約350項目の条件を満たす必要があるそうで、前回は3社が応札してAWSとGCPが選ばれ、1社が脱落しました。

今回は1社も脱落なく選ばれています。

前回の選定時にも国内クラウドベンダーの不在を嘆く声があり、今回も同様な論調の記事があちこちに出ましたが、もう日本企業は官公庁・自治体に自社のクラウドを採用してもらうことすら諦めてしまったのか、と思うとやはり残念ではあります。

国内の業界からは、「規模の経済」、つまり量・質ともに莫大な規模で世界展開する3大クラウドなどを最初から前提としていると考えられる、デジタル庁の選定基準の厳しさへの指摘が目立つようです。そもそも小規模な国内ベンダーには勝ち目はなく、最初から勝負を諦め、不戦敗となるのは必至だったというわけです。

もちろん、ガバメントクラウドの公募は今回で終わり、というわけではないのでしょうが、今の状況で日本のベンダーが入ってくる可能性は、次の公募でも高くなさそうです。

■海外クラウド依存には為替リスクも。しかし…

海外クラウドへの極度な依存は、政府・公共セクターだけではなく、民間でも起きてしまっているようですが、さっそく副作用が出てきています。
何十年ぶり、という記録的な超円安による、請求金額の上昇です。

基本的に3大クラウドの料金はすべて米ドル建てであり、それを実際には日本円で払うわけですが、海外クラウドに大きく依存しているWidefoneを提供する立場から、毎月の料金を眺めるたびに、ため息をついてしまいます。

MM総研の「国内クラウドサービス需要動向調査」※によれば、円安を受けて「新規開発に限り利用する」・「収益化できる開発に限り利用する」とするユーザーが32.7%でした。しかし、全体的には、3大クラウド利用企業の46.5%が、このまま円安が継続しても「現在のまま使い続ける」と回答したそうです。

もっとも、調査時点の6月では、ドル円レートは平均で134.15円でしたから、145円を超える今ほどの超円安ではありませんでしたが、結局、選択肢が他にないので、この超円安でも使い続けるしかないという状況は、たぶん変わっていないと思います。

円安が続いた場合におけるAWS/Azure/GCP利用動向（n=383）（MM総研）

※株式会社MM総研プレスリリースより（2022年8月24日）：https://www.m2ri.jp/release/detail.html?id=549

■日本のクラウドは「ハイブリッド」「マルチ」へ

前回のコラム（運用自動化ツールとは？ 2022年版（6年の時を経て再考））にも、「日本のクラウドの主流はハイブリッドクラウド（パブリッククラウドとプライベートクラウド/オンプレミスの併用）」と書きました。

日本の場合、クラウド導入のトレンドが北米等に比べると遅くやってきた上、しかも石橋を叩いて渡る慎重さを誇る日本のIT業界ですので、極東の大市場として3大パブリッククラウドが早くから日本リージョンを展開していたにもかかわらず、体感としても歩みはかなり遅いように思います。

海外ではパブリッククラウド万能論からの「撚り戻し現象」と捉えられているハイブリッドクラウドが、日本ではオンプレミス信仰から抜け出す過程の一環として浸透してきているように思います。結果的には同じ方向に向かっているわけですが。

あとは、複数ベンダーのクラウドを使い分ける「マルチクラウド」も、この円安を機に拡がる可能性があると思っています。

マルチクラウドというと、これまでは3大クラウドにおいて、基本はシェアが最も高く、ナレッジも蓄積されているAWSを使いつつ、Active Directory(AD)連携が必要な部分はAD本家のAzure、AI関連やKubernetesなど先進的な取り組みにはGCP、のような使い分けがみられました。もちろん、特定クラウドへの依存を避け、リスクを分散する目的もあります。そこに今後は、為替対策・コストセーブのために、国内クラウドを組み合わせるようなケースも出てくるかもしれません。

先のMM総研の調査でも、為替に左右されない「国内ベンダーのPaaS/IaaSを利用する」との回答が28.3%でした。円安がさらに進んだ現在は、この選択肢がもっと増えている可能性があるでしょう。

実は、Widefoneなど弊社の自社サービスでも一部国内クラウドを利用していることは、以前のコラム「新サービス「Widefone」と運用自動化・構成管理」で触れました。ただし、これは為替リスク回避が目的ではないのですが…

■ハイブリッド/マルチクラウド運用の煩雑化はPOLESTARで解決！「Japan IT Week 秋」へ！

ハイブリッドクラウドやマルチクラウドにはメリットも大きいのですが、課題は管理の煩雑化です。

パブリッククラウドのコントロールパネルは各サービスで異なりますし、各サービスごとに用意されている管理サービス（監視や自動化コマンド）などの学習コストも必要になります。特に構成管理については、それぞれのクラウドの機能を用いて個別に行うのは、非効率的です。

そこでPOLESTAR Automationです。
1つのUIで横断的な構成管理や自動化コマンドの投入が可能になりますし、各クラウドで提供されているCLI（コマンドライン）と組み合わせることで、高度な統合管理も実現できます。

さて、弊社からPOLESTAR Automationをリリースして以来、唯一、これまでコロナ禍等を受けても中止されることがなく、POLESTAR Automationも欠かさず出展を続けてきた展示会が、幕張メッセで毎年開催されている「Japan IT Week 秋」です。今年度は10月26日（水）～28日（金）で、弊社ブースは第7ホールの39-51です。

今回はZabbix連携など定番デモに加え、年末にリリースする予定の2つの新機能「ネットワーク自動化」と「クラウドディスカバリー」も初めてご紹介します。
特に「クラウドディスカバリー」は、大規模なクラウド運用において課題となっている、企業の現場で立てておきながら、使われなくなっている「野良クラウド」を見つけ出すための機能です。（実はこのコラムの執筆時点では、まだ現物を見られていません）

と、いうわけで、幕張に来られる方は、ぜひともPOLESTARブースにお立ち寄りになり、直接ご確認いただければ、と思います。
POLESTAR関係者一同、皆様のご来場をお待ちしております。



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



ワイドテック プロダクト企画の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の方にも興味を持っていただければ、とも思っています。



ワイドテック プロダクト企画の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を。
ぜひともご検討ください。



ワイドテック プロダクト企画の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を超える点検ポリシーや、最新の構成情報がその場で得られる「ライブオブジェクト照会」などを活用し、「己を知」りましょう。



ワイドテック プロダクト企画の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に相応しく、もっと広く活用されるべきなのが、仮想環境だと思います。



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

去る4月6日から8日まで、久々に東京ビッグサイトで最大規模の会場「東展示棟」において、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では、任意のコードをリモートで実行可能となっていたため、この脆弱性を悪用すると、さまざまなマルウェアを企業のネットワーク上に侵入させることが可能です。ランサムウェアやボットネット、仮想通貨のマイニングプログラムなどを侵入・実行させた事例が確認されているようです。

■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は有用です。 まずは、評価版でお試しください。



ワイドテック プロダクト企画の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インフラ運用管理の話は何も出ない回で大変恐縮ですが、この機会に少しでも、ワイドテックという会社そのものにも、興味を持っていただければ幸いです。



ワイドテック プロダクト企画の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のキーファクターのひとつとなります。

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



ワイドテック プロダクト企画の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年当時にはなかった、評価版でお試しください。



ワイドテック プロダクト企画の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を世に出そうとしていた頃だったと思います。

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

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といえます。

■「トイル」とは何か

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

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

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

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

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

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

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



ワイドテック プロダクト企画の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チームの若く有能なエンジニアに伝えたところ、すぐに同ツールの評価版をダウンロードして環境構築し、その日のうちに連携を実現させてしまいました。

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

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

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



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

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

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

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

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

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

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

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

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

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

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）にご来場いただければ幸いです。



ワイドテック プロダクト企画の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をお役立てください。

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



ワイドテック プロダクト企画の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の中間に位置づけられるリリースというわけです。

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

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

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

いずれのディストロも、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ファイル等の配布、そしてインストール後の動作確認まで、自動化することができます。

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

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



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

前回のコラム脱稿（6月15日）時点では、まだ「噂」レベルだったWindows 11。
それから10日も経たずに、次期Windowsこと21H2が、本当に「Windows 11」というネーミングで発表されてしまいました。
新しいWindowsが試せる状態になったら、試したくてはいられない体質なので、今回も早速試してみました。

■Windows 11 Insider Previewを試すには/試してみた

まず、Windows 11 Insider Preview（以下Preview版）を試すには、Windows InsiderプログラムにMicrosoftアカウントで登録し、開発者対象の「Devチャンネル」に参加する必要があります。
製品版により近い「Betaチャンネル」では、まだ配信されていません。
このあたりの話は、ズバリ「Windows 11 Insider Previewを試すには」と検索すると、手順の書かれた記事がいくつもヒットしますので、お試しになりたい方は参照してみてください。本稿での紹介は、ここまでとします。

さて、Windows 11発表時に波紋を呼んだのが、動作条件、特にハードウェアに関するハードルの高さです。セキュリティ面の理由からだとされていますが、「TPM(Trusted Platform Module) 2.0」とかは、従来その存在を気にしたことすらなかった、という方が多いのではないのでしょうか。
CPUの条件も厳しく、最初の発表時点では2018年第1四半期以前リリースのものは切り捨てられていました。Windows 7の時代に一斉を風靡したSandy Bridge（第2世代Intel Core）はおろか、比較的最近のCPUと思っていたSkylake（第6世代）やKaby Lake（第7世代）、初代AMD Ryzen（1000番台）なども対象外です。もっとも、このあたりは緩和される可能性もあるとのことです。
しかしながら、現時点のPreview版は、TPMのないマシンや、やや古めのCPUでも動作しているようです。自分が試したいくつかのPCの中には、CPUが対応リストにないHaswell（第4世代）、かつTPMもないものがあります。
実機に入れるのはまだ気が引けるので、VMware WorkstationやWindows 10 Pro上のHyper-Vなどの仮想化環境で試していますが、UIはタスクバーの中央部に移動したスタートボタンをはじめとして大幅に変わったものの、中身はWindows 10の正常進化ですので、大体の既存アプリは動きました。

■仮想化よもやま話

さて、今回のメインテーマは「仮想化」です。
最近、POLESTAR Automationの営業やサポート宛に、仮想化環境に関連する問い合わせが多いからです。
仮想化環境（仮想マシン）を構築するソフトウェアは、一般に「仮想化ハイパーバイザー」と呼ばれ、よく知られているものとしてはVMware、Oracle VirtualBox、Hyper-V、Xen、そしてKVMなどがあります。ハイパーバイザーという用語は、「スーパーバイザー」と呼ばれることもあるOSの、さらに上位でOSを管理するところから来ているようです。
最近はPOLESTAR Automationでも管理サーバー構築案件の大半が「1台の物理サーバーに複数の仮想マシン」という構成で、OSがLinuxならVMware、Windows ServerであればHyper-Vという2大ハイパーバイザーが、ほぼスタンダードになっています。
弊社内でも、VMware ESXiやWindows Server版Hyper-Vを用いて大量のLinuxやWindows、Solarisなどの仮想マシンを構築し、POLESTAR Automationのサポート用環境の再現や、新バージョンのテストなどに使用しています。
しかし、お客様、特にPoCを希望される方からは、まれに2大以外のハイパーバイザーで仮想アプライアンス（以下仮想AP）を提供してほしいとのご要望もいただきます。春先にはVirtualBoxで、という依頼がありましたし、最近KVMもありました。
KVMについては、実はPOLESTARチームの誰も最近まで触ったことがありませんでした。POLESTAR Automationの評価を希望されたお客様から、KVMで仮想APを作ってほしい旨の依頼をいただき、初めて触ったのですが、ESXi環境に「ハードウェアアシストによる仮想化をゲストOSに公開」オプションを有効にした状態のCentOS 7仮想マシンを作り、その中でKVMをインストールし、さらにPOLESTAR Automation評価環境を動かすためのCentOS 7の仮想マシンを作りました。

このESXiの仮想化支援オプションを最初見落としていて、KVMがインストールできずに数時間苦労したものですが、どうにか解決してESXi上で「入れ子」状態で動くKVMベースの仮想マシンを作り、エクスポートして無事評価用の仮想APとして納品できました。
その他、POLESTARチームの日常では仮想環境にまつわる話が多く、実はここには書けないような苦労話もあるのですが、明確に言えることは、POLESTAR Automationの取り扱いを始めてから、仮想化環境を触る機会と、半端な知識が増えたことですかね。

■仮想化環境とPOLESTAR Automation

以前にもあったのですが、最近久々に、POLESTAR Automationで「ESXiのハイパーバイザーが管理できるか」というお問い合わせをいただきました。
ESXiは仮想OSを束ねるハイパーバイザーであって、OSそのものではないので、直接エージェントを入れて動かすことはできませんが、SSH（要有効化、標準では無効）があるので、CLI経由でエージェントレス管理の対象とすることは可能です。ESXiの状態取得、仮想マシンの新規作成、コピー、削除など、ESXiのコマンドラインで可能なことは当然可能です。ジョブもいくつか作成し、動かしてみています。
余談ですが、かつてPOLESTAR Automation V2の時代には、GUIベースのハイパーバイザーのモニタリング機能がありました。ビジュアルにも凝っていて、個人的には気に入っていたのですが、ハイパーバイザーの稼働状態が見られるというだけで、設定を変更する機能はなかったので、現行バージョンであるV3には引き継がれませんでした。
その代わり、V3にはエージェントレスがあり、ESXiのようなエージェントを入れられない環境も管理対象とすることができます。仮想環境の管理ができるのは、V3の方です。

と、いうわけで、最後にWindows 10のHyper-V上にインストールしたWindows 11で、Chrome（あえて）で動かしてみたPOLESTAR Automationと、エージェントを入れたWindows 11をPOLESTARから見てみたところのスクリーンショットで、本稿を締めくくります。

＜おすすめコンテンツ＞
・POLESTAR Automationで必要となる5年間のコスト（TCO）を試算



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

Windows 10初版のリリースは2015年7月末でしたので、今年で6周年を迎えますが、先月、半年ごとの大型アップデートとなるバージョン「21H1」が配信されました。

21H1は前の20H2と比べて見た目の変化をあまり伴わない小幅なものでしたが、6月24日に概要が発表されるという次（たぶん年末頃配信）の大型アップデート21H2では、かなり大規模な変更が予定されていて、「Windows 11」になるという噂まであります。

さて、自宅には24/365で電源入れっぱなしのWindows 10マシンがあり、21H1は先月手動で適用していたのですが、今朝起きたら第2火曜日（米国時間）配信の月例Windows Updateが掛かっていて、タスクバーの右側に見慣れないお天気アイコンのようなものが出現していました。「ニュースと関心事項」という新機能で、まだ20H2が最新だった4月頃から、大型アップデートに関係なく順次ロールアウトされているとのことです。

PeopleだのCortanaだのは全部オフ、スタートメニューにデフォルトで登録されているライブタイルもほとんど削除し、必要なものしか置かない派なので、これもさっそく切ったのですが、どうせなら21H1の時に一斉リリースにしてほしかったところです。セキュリティホールとかのクリティカルなアップデートというわけでもないですし。

新たにロールアウトされた「ニュースと関心事項」。無効にしたい場合は、黄色の枠の手順で「無効にする」を選択

■有無を言わさずやってくるWindows Update

皆様もご存知かと思いますが、デスクトップ版Windows 10におけるWindows Updateでは、基本的に強制配信となっています。

当初は有無を言わさずアップデートさせられる仕様で、適用時間をアクティブ時間外（使用していない時間以外）に変更できる程度でしたが、クレームも多かったのか、いつしか「更新を7日間一時停止」というオプションが追加されました。

Windows 8.1までは、Windows Update自体を停止させることができていましたので、Windows 7を使っていた頃（おそらく多くの方がそうだったと思いますが、8や8.1は会社でも自宅でも使っていませんでした）は、週末等の暇な時にまとめてアップデートを掛けていたものです。

しかし、現在はWindows Updateそのものを停止することは、機能上はできません。24/365でWindows 10マシンをつけっぱなしにしておくと、毎月第2水曜日（日本時間）を過ぎて数日の間に必ずアップデートが来てしまうわけですが、アップデートが降ってくる日に限って、閲覧中の面白いWebページや作成途中のファイルを開きっぱなしで寝てしまって、Windows Updateのせいで吹っ飛ばしてしまったことも、1度や2度ではないです。

最近はブラウザの履歴保存やオフィス系アプリの自動データ保存の作りが良くなってきていますが、それでも絶対確実に再現されるとは限りませんので。

と、いうわけで、自動アップデートが大嫌いなのですが、デスクトップ用のWindows 10ではなく、Windows Serverであれば、最新版でもWindows Updateの停止は可能です。しかし、脆弱性の放置による影響、何かあった時の被害は一般にエンタープライズユースのServerの方が大きいでしょうから、むしろ積極的にWindows Updateを適用すべきなのは、Serverの方でしょう。

もちろん、デスクトップWindowsにおいても、脆弱性の放置が事業所における情報漏洩やその他のセキュリティ事案につながるケースもありますが、最近はメール等に添付でくっついてくるマルウェアやフィッシングサイト等が原因で、Windows自体のせいではないことの方が多いですね。気を付けるしかないでしょう。

■Windows Updateを制御する「WSUS」

さて、上から下までフルにWindowsで固めている事業所では、Windows Serverをドメインコントローラーとして用い、Active Directory(AD)によって他のWindows Serverや、デスクトップ版WindowsのPCを管理していることと思います。

そして、AD配下のWindows Updateの適用管理には、「WSUS」を使用していることが多いでしょう。

WSUS、Windows Server Update Servicesの略ですが、一般に「ダブルサス」と呼ぶことが多いようです。WSUSを使うと、サーバーやクライアントPCの1台1台が直接インターネット経由でMicrosoftのWindows Updateサーバーを参照しに行くのではなく、WSUSの存在するWindows Serverを経由してWindows Updateを適用させることが可能となります。

WSUSがあれば、新しいWindows Updateがリリースされても、それを配下のサーバーやクライアントに適用するかどうかをWSUSで制御することができます。新しいWindows Updateが既存のアプリケーションやミドルウェアなどに影響を及ぼさないかどうか検証した後に、Windows Updateを展開することが可能となるわけです。

また、機密情報を扱うなどセキュリティの重視される事業所では、サーバーやクライアントの大半をインターネットから遮断された閉域網に置いていることも多いかと思いますが、WSUSの入っているサーバーだけをインターネットに接続してWindows Updateを取得後、閉域網内に展開する、といったユースケースも存在します。

しかし、WSUSも万能ではありません。そもそもWindows 10以降ではアップデート無条件強制が原則であり、WSUSもそれに従った仕様となっています。WSUS配下のサーバーやクライアントに対して、いったんWindows Updateをリリースしたら、それがいつ、どんなタイミングで適用されるかまでは制御できないのです。

■Windows Updateの悩みも、POLESTAR Automationで解決

POLESTAR Automationを含めて弊社のWeb関連は、すべてマーケティング部というチームで制作とアクセス分析を行っているのですが、最近同部のWeb担当者から、「Windows Update」や「Windows Update 自動化」など、Windows Update関連のキーワードで検索してPOLESTAR Automationのサイトに来訪される方が増える傾向にあるという話を聞きました。

POLESTAR Automationが発売当初から搭載している機能のひとつに「Windows Updateジョブ」があります。その名の通り、POLESTAR Automationで管理しているサーバーのWindows Update適用を司るもので、WSUSと重複する機能といえます。

WSUSがあるなら、WSUSを使えばいいじゃない、というのはたしかに正論ですが、ではなぜ、POLESTAR Automationにこの機能があるのかといいますと…

まずは、マルチベンダーな環境への対応のためです。目的と用途に応じて、WindowsとUNIX/Linux系のサーバーを使い分けていて、両方それなりの数があったり、どちらかといえば*nixがメイン、という事業所から、AD+WSUSではなく、Linuxを含むサーバー向けのあらゆるジョブをPOLESTAR Automationひとつで管理できないか、という要望があり、この機能を開発した経緯があります。

もうひとつは、Windows Update適用を任意のタイミングで、つまり、決まった時間帯に行いたい、というニーズへの対応です。

スケジュール設定の可能なPOLESTAR AutomationのWindows Updateジョブを使うと、Windows Updateを当てたい日時に適用できます。

テスト環境で新しいWindows Updateが既存の環境に影響を及ぼさないことを確認したので、WSUSでアップデートをリリースしたら、平日昼間の稼働時間帯にアップデートが当たり、サーバーが再起動してしまった…というお話も伺いました。

土日や深夜など、都合のいいタイミングでアップデートを当てたい、という要望は、本当にたくさんの方からいただいております。

そうしたニーズにお応えできるソリューション、それがPOLESTAR AutomationのWindows Updateジョブ機能なのです。

その詳細については、当POLESTAR Automationサイトの「お役立ち資料（ホワイトペーパー&パンフレット）」コーナーで公開しているコンテンツ「ホワイトペーパー Vol.5 – Windows Updateにともなう作業はどこまで自動化できるか」でご紹介しています。

POLESTAR AutomationでのWindows Updateについて興味を抱かれた方は、ぜひそちらをご一読ください。

実は今回のコラムは、マーケティング部からの依頼で、急遽書いたものです。

本当は別のテーマで書く予定で、導入部分まで書き終わっていたのですが、テキストを保存せずに削除してしまいました（故意です。Windows Updateで飛ばしてしまったわけではありません）。そっちは時事的要素も含んでいたので、完全にボツ企画です。

ところで最近、個人的にはOSを触るといえば、WindowsではなくLinuxの方が多いです。何をもって「OSを触る」と定義するかにもよりますが、普段Windowsでやることといえば、Webブラウジングとメールを含むドキュメント作業ぐらいで、環境を新規構築したり、何か新しいことをやったりするのは、全部Linuxの上、ということです。

そんなわけで、個人的にはWindowsの知識がどんどん希薄化して行く一方だったのですが、この機会に、久々にWindowsを触ってみようかなと思っています。

＜おすすめコンテンツ＞
・ホワイトペーパー Vol.5 – Windows Updateにともなう作業はどこまで自動化できるか



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

自分ことYは、自他ともに認めるデジタルガジェットマニアです。中でも海外のものが好きで、中国のAliExpressとか京東商城（JD.com。中国語のサイトですが、日本にも発送してくれるそうです）とかは、眺めているだけでも楽しいですね。
スマホとスマートバンドは割と頻繁に買い換えている方なのですが、このところ視力の衰えを痛感するようになり、スマホでは見づらい電子書籍や、ネ○フリなどを少しでも大きな画面で見る目的で、数年ぶりにAndroidタブレットを買ってしまいました。
11インチを超える大きめのもので、デジタルペンも使えるので、メモ書きやアイディアスケッチ用にも使おうと思っています。
下の写真は、クラウド(AWS)上にあるPOLESTAR Automationの管理画面を開いてみたところです。V3からはHTML5ベースなので、スマホやタブレットでも開けるようになったのですが、さすがにこのサイズのタブレットだと、結構実用的です。

さて、POLESTAR Automationも多くのお客様に導入、あるいはPoC（概念実証）をしていただけるようになり、弊社や開発元では気づかなかった、お客様からの貴重かつ有用なフィードバックや、新機能へのご要望を多数いただいております。
このたび、5月中旬を目処に新しいマイナーバージョンアップのリリースが決定し、先日より開発元と弊社の検証チームが共同で、検証作業を行っているところです。

■ハイブリッド運用のための、クラウド管理の充実

今回、最大の変更点として、「構成」メニューで「デバイス管理」の下に、「クラウド管理」という項目が追加されます。

従来のバージョンでも、AWSやAzure、GCP、その他VPS系も含めたクラウド上にあるサーバーインスタンスを登録して、オンプレミスサーバーとともに管理することができていました。
今回は、プライベートとパブリックの2つのIPアドレス、ロケーション（リージョン/アベイラビリティーゾーン）、リソースIDといったパブリッククラウドに固有の管理情報をプロパティとして追加し、クラウド上のインスタンス管理の便宜を図ることにしました。

ズラリと並んだクラウドインスタンス。
プライベート/パブリックの両IPやリージョン（ロケールと表記されているもの）なども見られます

これは「AWS」でグループ化した一覧。いろいろな条件で一覧抽出が可能

クラウドのアカウントを利用してインスタンス情報をインポートし、エージェントレス方式で一括登録することも可能となりました。公開鍵認証情報も一括管理できます。
もちろん、登録されたインスタンスは、オンプレミスもクラウドも分け隔てなく、点検や監査、スクリプトジョブなどの対象とすることができます。 このクラウド管理は、とある大規模のお客様がオンプレミス構成のサーバーの大部分を、クラウドに移行を図ろうとしているところから新たに追加した機能です。
既にオンプレミスはほとんど残さず、パブリッククラウドに完全移行してしまった…というお客様もいらっしゃるでしょうが、近年はセキュリティや安定運用の面から、パブリッククラウドとオンプレミス/プライベートクラウドとを併用し、目的に応じて使い分ける「ハイブリッドクラウド」、複数のパブリッククラウドで冗長化を図る「マルチクラウド」など、運用体系の多様化が進んできています。
新しいPOLESTAR Automationは、こうしたハイブリッドクラウド、マルチクラウドの一括運用自動化・管理に最適なソリューションです。

■繰り返し作業の完全撲滅を目指す、ネットワーク機器管理

次に、最近増えてきた、POLESTAR Automationをスイッチやルーターといったネットワーク機器の管理にお使いのお客様のための新機能です。ネットワーク機器のお客様はサーバーと比べても管理台数の桁が違うことも多く、たくさんの宿題をいただいていました。
新バージョンでは、ネットワーク機器のリモートアクセス情報を、CSV形式のファイルで一括登録できる機能を追加します。
従来のバージョンでも、ネットワーク機器情報をCSVで一括登録することはできたのですが、パスワードなどアクセス情報の更新は、個別に行う必要がありました。この問題の解決を図ったものです。しかも、この更新をスケジュール化する機能も搭載しましたので、パスワードなどをの更新頻度の高い用途では特に有用です。
他に、ネットワーク関連でいただいていた宿題への対応としては、ネットワークスクリプトジョブにおいて報告されていた、ジョブ結果のExcel出力で発生していた長い列（32768バイト超）が入り切らない問題への対応（32767バイトごとに列を分割します）、監査ジョブでのデータ比較ジョブなどの新機能追加を図っています。

■Interop 2021/Japan IT Week 春でお試しを！

以上の2点以外にも、新バージョンではいろいろ細かい使い勝手の改善を図っています。
前述の通り、正式リリースは5月中旬以降を予定していますが、もうすぐ開催される2つの展示会、「Interop 2021（4月14～16日、幕張メッセ。Zabbix社ブースへの共同出展ですので、おなじみの赤いZABBIXロゴを目印にお越しください）」と「Japan IT Week 春（4月26～28日、東京ビッグサイト。月曜日が初日ですので、お間違えのないように）」では、この新バージョンを先行でチラ見せしたいと考えています。
ぜひともご来場をお待ちしております。



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

最近評判の映画「花束みたいな恋をした」を観てきました。テレビドラマ「東京ラブストーリー」などで知られる坂元裕二氏の書き下ろし脚本、菅田将暉と有村架純のダブル主演による、恋愛映画です。
2015年に付き合い始めたサブカルチャー好きの大学生男女が、社会人生活を経て2019年に別れてしまうまでの話ですが、上流階級と庶民の恋だとか、主人公を襲うアクシデントだとか、不治の病で余命あと何か月だとか、そういうハラハラ・ドキドキ要素は一切なく、物語は淡々と進んで行きます。
しかし、そんなある意味とても地味な日常系恋愛映画が、同世代に限らず幅広い層の共感を呼び、ネットを中心に口コミで評判が広がっていったようです。意外とそんな映画が、最近なかったからでしょうか。
原作がなく、配給会社も大手ではなく宣伝も少なめ、しかも件の緊急事態宣言で映画館の営業時間が短縮中というハンディキャップにもかかわらず、上映開始後6週連続で観客動員1位、興行収入30億円を窺う異例のヒット作となっています。
ちなみに、物語が始まる2015年といえば、弊社では運用自動化製品のプロジェクトが本格化した年。映画を観ながら、POLESTAR Automationの歩みと重ね合わせずにはいられませんでした。

■「エージェント」とともに歩んできたPOLESTAR Automationの歴史

さて、POLESTAR Automationが世に出て以来、一貫して取り組んできたのが「エージェント」に関する周知活動です。
営業や展示会への出展を重ねる中で、文字通りのFAQ、frequent（頻繁な）と呼ぶのに相応しいほどの高確率で尋ねられてきたのが

「これってエージェント入れるんですか？」 という質問です。
運用自動化ツールや監視ツールでは、エージェントと呼ばれる常駐型プログラムをインストールするものが多いです。弊社もパートナーとなっているITインフラ向けモニタリング（監視）ツールの代表格・Zabbixでもエージェントレス監視をサポートしていますが、サーバーを監視対象とする場合は、サーバーにZabbixのエージェントをインストールするのが一般的なようです。
エージェント方式の方が取得可能な情報が豊富で、リアルタイム性にも優れているなどのメリットもありますが、何よりもインストールしてZabbixの管理サーバーに登録するだけでほぼ設定が完了する手軽さこそ、エージェント方式が選ばれる最大の理由でしょう。
これは、POLESTAR Automationのエージェントでも同様です。POLESTAR Automationを含む自動化ツールのエージェントは、構成情報の収集、コマンドやスクリプトの実行に加え、ファイルの受け渡しなどもこなす万能プログラムですが、一定間隔でサーバーのリソースやデータトラフィックなどをモニタリングする監視ツールのエージェントとは異なり、必要な時にしか仕事をしませんので、稼働していない時間の方が通常は圧倒的に長く、システム負荷もその分低いといえます。

■Windowsでのエージェントレス実現について

営業活動を通じてエージェントに関する啓蒙のノウハウを蓄積し、エージェントありでも導入していただけるというお客様も増えてきたのですが、それでも「エージェントは絶対NG」というお客様が結構いらっしゃるので、POLESTAR Automationでもエージェントレスの開発には早くから取り組んできました。
サーバー用のエージェントレス開発以前に、エージェントのインストールできないルーターやスイッチのようなネットワーク機器を対象に、TelnetやSSHを使って管理対象にログインし、構成情報の取得やスクリプトの実行を行う技術が開発済みでした。
ともあれ、ベースはあったわけで、Linuxや商用UNIXでは、SSH経由で送ったシェルスクリプトを実行し、構成情報を取得するのは比較的容易なので、問題なく実装できました。ファイル転送もSSH経由のSCPにより実現しました。
問題はWindowsでした。Windowsにはコマンドを遠隔実行するためのインターフェースとして、「WMI(Windows Management Instrumentation)」と「WinRM(Windows Remote Management)」の2種類があります。
WMIはWindows NT 4.0時代の末期にリリースされた管理インターフェースで、Windows 95からWindows 10まで幅広く対応しているのが特徴です。
WinRMの方は、Windows Vista/Windows Server 2008以降で実装された遠隔管理インターフェースですが、Windows Management Framework(WMF)のインストールにより、Windows XPやWindows Server 2003でも利用可能です。しかし歴史が長く、近年のWindowsではバージョンに関わらず期待通りの動作をしてくれるWMIとは異なり、WinRMが仕様的に安定してきたのは、Windows 8/Windows Server 2012以降です。
POLESTAR Automationについては、既存のお客様で閉域網内でWindows XP/Windows Server 2003を使われているケースがあり、開発元と弊社での議論を重ねた結果、WMIを採用することになった経緯があります。
しかし、WMIを採用した結果、POLESTAR Automationの管理サーバー側にもWMIが必要となり、Windowsで動作している管理対象サーバーをエージェントレスで利用するには、管理サーバーのOSもWindows Serverに限定されることになりました。
あと、WMIにはファイル転送機能がありませんので、ファイル転送はSSHを用いることになるのですが、これについてもWindowsのバージョンごとにお願いする内容が異なります。
Windows 10（1709以降）やWindows Server 2019にはSSHが標準搭載されていますが、それ以前のWindows、特に現在Windows Serverとして最も稼働数が多いと思われるWindows Server 2016や、たぶん次点のWindows Server 2012R2では、別途OpenSSHというものの事前導入が必要となります。方法は、POLESTAR Automation V3.1のマニュアルでご紹介しています。

■エージェントとエージェントレスのリアル

そんなわけで、エージェントとエージェントレス、どちらを選ぶべきか。
とりあえず下の2枚のスクリーンショットを見てください。同じLinux(Ubuntu)の管理対象サーバーを、エージェントとエージェントレス、それぞれでPOLESTAR Automationの管理サーバーに登録してみたものです。

画面1：エージェント方式で登録したUbuntuサーバー

画面2：エージェントレス方式で登録したUbuntuサーバー

いかがでしょうか？ エージェントの方が圧倒的に設定項目が少ないですよね。
エージェントレスでは、管理対象側にログインするためのさまざまな登録項目があります。特権コマンドの利用のために、su情報の登録も必要になります。
もちろん、お客様の管理ポリシーとしてエージェントは入れない、監視ツールもエージェントレス監視を使っている、などなど、どうしてもエージェントレスが求められる、エージェントレスじゃなきゃ困る！ というケースもあることでしょう。
そうしたお客様のために、エージェントレスも用意させていただいた、というのが、弊社のスタンスです。

POLESTAR Automationに限らず、監視も含む運用管理系ツールにとって永遠のテーマかもしれない、エージェント（レス）問題。久々にこのテーマでコラムを書くことにしたのは、最近「エージェントレスの設定が殊の外面倒だった」という理由で、PoCを断念されたお客様がいらっしゃったからです。
「いやいや、エージェントレスも実は簡単なんですよ」とフォローを試みるのではなく、ここはあえて開き直り、エージェント（レス）のリアルをお伝えした方がよいのかな、と考えました。
と、いうわけで、管理対象サーバーにはエージェントを入れるだけの簡単設定、エージェントレスもできる運用自動化ソリューション・POLESTAR Automation。まずは評価版でお試しください。



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

昨春、国内でも華々しくデビューしたはずだった高速無線通信技術「5G」。
理論値では一般的な光回線より速く、実使用レベルでも、現在支配的な方式である4G（LTE）と比べ、下りの通信速度が4～5倍は出ます。
昨年はコロナ禍等の影響も受けてか、5G基地局（NR=New Radioといいます）の展開がなかなか進まず、結局、非常に限定されたスポット的な範囲にしか設置されないまま年末を迎え、流行語大賞やヒット商品番付等に入ることすらありませんでした。

■「DX」、忘れていませんか？

「5G」と同様に昨年、トレンドの最前線からはやや後方に押し出されてしまった感のあるキーワードが「DX（デジタル・トランスフォーメーション）」かと思います。
経済産業省から「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」という報告書が発表されたのは2018年9月で、当時「DX…デラックス？」などというオヤジギャグとか、「transformationがなんでエックスなの？」という素朴な疑問の声もあちこちで飛び交っていたものですが、実は自分もこのコラムを書くためにDXの流れを追うまで「2025年の壁」と覚えていたのは、内緒です。
要旨を改めて整理しておくと、

• 日本企業の多くで老朽化・肥大化したレガシーシステムを放置しており、サポート期限を迎えても更新されることなく使われ続けている
• IT人材が不足しており、しかも属人化や下請け企業への業務委託（丸投げ）も多い
• IT関連費用の約80％が現行ビジネスの維持・運営に充てられている
• 日本企業でこのままDXを推進しなかった場合の経済的な損失は、最大で年間12兆円。放置すればするだけ毎年経済損失が積み上がる

と、危機感を煽りつつも、納得できる内容でした。
エンタープライズからSMBまで、多くのIT関係者がこのレポートによってDXを意識したと思われ、これ以降、IT投資がにわかに盛り上がったことを弊社でも実感していました。POLESTAR Automationへの問い合わせや、セミナーへの参加申し込み、展示会ブースへの訪問なども、加速度的に増えて行きました。
しかし、その後実際に導入に至ったケースは、こちらの期待ほど多くありませんでした。「DX」という概念は、社内外向けの業務システム（クライアント側やミドルウェア）から、POLESTAR Automationが対象とするサーバー・ネットワークなどのインフラ周りまで、企業におけるIT活用のすべてを網羅するものであり、一気に更新できるものではなく、まずは多くの従業員が日常的に直接操作する、クライアントマシンやフロントシステムから着手した例が多いようでした。
そして、ようやくバックエンドのインフラへと順序が回りつつあった昨年、新型コロナウイルス禍の発生により、各事業所では出勤者の抑制が求められることになり、多くの企業でVPNやVDIの導入、通信回線増強、従業員に支給するノートPCなどの可搬クライアント端末購入といった、緊急性の高いテレワーク環境への投資に振り向けざるを得なかったようです。
コロナ禍以前から「働き方改革」が叫ばれてはいたものの、コロナ禍がなければ、DXよりもテレワーク投資の優先順位は低かったのではないかと思われます。

■コロナ禍で遅れたDX推進。巻き返すには？

コロナ禍に伴うテレワークへの緊急投資需要は、実は弊社全体で見れば、それなりに恩恵を受けた方かもしれません。オフィスの番号への着信を業務携帯などに転送できる電話サービスや、ファイアウォール/NATを跨いでのテレワークが実現可能なリモートアクセス製品などが伸びたからです。
で、次はいよいよ、というか今度こそ！ ITインフラの番かなと思っています。昨年はコロナ禍のために後回しにせざるを得なかったITインフラのDX対応投資は、今年以降復活することが見込まれています。昨年4月の第1次緊急事態宣言の頃は減っていた新規のお問い合わせも、コロナ禍が一時的に落ち着いていた秋頃から再び増えはじめ、保留になっていた案件の多くも復活しました。コロナ禍などの感染症による出勤制限にも強い運用を、という趣旨で、新たにPoCを開始されたお客様もおられます。

「2025年の崖」というのは、かつてOSや基幹システムの大量リプレースを発生させた「2000年(Y2K)問題」などとは異なり、はっきりと2025年の何月何日に一斉に何かが起こる、という性格の話ではありません。レポートがまとめられた2018年時点での人口や年齢層の推移、企業のIT投資額などをもとに導き出された、あくまでシミュレーションです。
IT運用の実情は、個別の企業によってまちまちでしょう。「崖」がもう目の前に迫っていることを実感しつつも、諸事情により対策に踏み出せないでいる経営者やIT管理者の方も、中にはおられるかもしれません。もちろん、運用業務の属人化排除やタイムリーなシステム更新などの対策を早くから講じていれば、「崖」を見ることもなく未来永劫、安定したIT運用を維持・継続できることでしょう。
しかし、属人的かつサイロ化したITインフラ運用、レガシーシステムやシャドウITの放置、外部への運用業務丸投げなどは、規模や内容によっても異なるものの、さまざまな内的・外的要因による破綻の危険性を孕んでいると思いますし、古いシステムを旧態然とした運用手順で使い続けることで発生するコストの無駄も、馬鹿にならないでしょう。
そこでおすすめするのが、POLESTAR Automationです。短い期間で導入でき、しかも1つのソリューションで、運用業務全体をカバーすることができます。「崖」を回避するには、運用を含むITシステム全体の管理・運用体制の見直し、投資の最適化など経営側のトランスフォーメーション（変身）も必要ですが、何より鍵になるのは運用現場のトランスフォーメーション、属人化しない運用だと思います。

さて、冒頭に触れた5Gですが、空振りだった昨年とは異なり、今年は新年度を迎える4月前後、既存携帯キャリア3社の「5G対応・データ20GBで2000円台（税別）・オンライン契約専用」料金プランが展開される頃までには、全国主要都市でかなり広いエリアに展開されると聞いています。
1月に出されて3月まで延長された10都府県の緊急事態宣言、再度延長されそうな情勢ですが、解除時期が見えてくる頃には、5Gで自宅からテレワークができるようになっている人も出てきているのかもしれませんね。
今年こそ真の「5G元年」になることを期待しています。
そして、5GといっしょにDX、特にITインフラ運用のDXにぴったりなPOLESTAR Automationのことも、この機会に思い出していただければ幸いです。



あけましておめでとうございます。
ワイドテック プロダクト企画のYです。

昨年12月（先月）に発表された「新語・流行語大賞」や「今年の漢字」などは、やはり新型コロナウイルスに関するものが多かったですね。漢字の方は、意外なところで「鬼」が来たりして…なんて思っていたのですが、大方の予想通り「密」でした。
「鬼」はもちろん、吾峠呼世晴さんの漫画「鬼滅の刃」からです。TV版アニメから映画化に至った「劇場版 鬼滅の刃 無限列車編」の大ヒットと、年末ぎりぎりに発表された歴代映画興行記録の更新は、暗い話題の多かった2020年の、数少ない明るいニュースだったかもしれません。春の緊急事態宣言の頃は、全国の映画館も本当に苦しんでいたそうですが、いったん廃業を発表した近畿地方のある映画館が「鬼滅」のおかげで起死回生を遂げ、廃業を撤回したという話も聞きました。映画業界を襲ったコロナ禍という「鬼」を「滅」ぼし、文字通りの救世主となったのです。

■POLESTAR Automationってどこがよいの？ 実はわかっていませんでした（苦笑）

2016年10月にPOLESTAR Automationを発表し、翌年から順次営業体制を構築して拡販に取り組んできましたが、当初は売っている側も、POLESTAR Automationがお客様サイドでどのようにITインフラ運用の自動化を実現するのか、漠然とはわかっていても実感の湧かない、手探り状態からのスタートでした。
それから営業活動や展示会への出展を重ねつつ、お客様へのヒアリング等を通じて、運用自動化へのさまざまなニーズの存在が、少しずつ理解できるようになりました。
ある時にはお客様からのリクエストで、またある時には脆弱性やJavaの有料化といった突発的なニーズに応える形で、POLESTAR Automationで対策や課題解決を図るためのジョブ開発と提供を進めてきました。
いつしかその合計数は500を超えていましたが、その大半はW君という若いエンジニアが自ら、時にはPOLESTAR Automationの生みの親であるNkia社の協力や支援も得ながら開発し、積み重ねてきたものです。日本におけるPOLESTAR Automationの歴史は、W君の成長物語でもあります。
市場投入した時点から最大の弱点にしてアキレス腱と認識していたFlash(Flex)によるUIも、2019年9月にHTML5でGUIを完全に刷新したV3のリリースにより、解決をみました。
しかし、営業やマーケティング活動を進める上で悩ましかったのが、POLESTAR Automationの市場でのポジショニング、ターゲティングでした。
というか、先にも書いた通りで最初は運用自動化という前提、リサーチ会社による推定市場規模などの情報だけをあてにして、あるはずのニーズに向けて闇雲に「新しい運用自動化製品」として売ってきたのですが、そんな状態で売り始めても説得力がなく、売れる先は限られていました。
競合製品にもどのようなものがあり、それぞれどんな特徴があって、強みや弱みがどこなのかも頭では理解していたのですが、それらと比べてPOLESTAR Automationはどこが良くて、どんな自動化ニーズに最適なのかも、実は最近までよくわかっていなかったことを、今ここに告白します。

■数ある運用自動化製品。その中から、POLESTAR Automationを選ぶべき理由

巷にいくつもあるIT運用自動化製品の中で、POLESTAR Automationを選ぶとしたら、どんな動機や理由が考えられるでしょうか。
初版リリースから4年を経た10月の「Japan IT Week 2020 秋」の頃になって、やっと気付きました。 それはPOLESTAR Automationが、「ITインフラ運用業務をまるごと自動化」できる数少ない、否、ひょっとしたら唯一の製品かもしれないことです。
POLESTAR AutomationのようなGUIではない、CLI（コマンドライン）環境だけでスクリプトやYAMLコードを利用して自動化を図る製品のユーザーに特に顕著な傾向として、IT的な言い回しでなく本来の意味に近い「ツール」、すなわち「道具」「工具」として、管理対象機器全体の設定変更やアップデートといった繰り返しの多いものや、ステップ数の多い環境のデプロイといった、特定の作業だけを自動化する目的で用いられるケースが多いようです。
このあたりは、展示会やコロナ禍以降のWeb商談を含む営業活動の場で、お客様へのヒアリングを通じてわかってきたことでもあるのですが、実は発売間もない2017年頃に作った「古典」ともいえる営業資料の中に、POLESTAR Automationの汎用性の高さを物語る表があったのを思い出しました。
青地の部分が、POLESTAR Automationによって自動化可能な作業です。

		比率	運用業務の詳細
導入	新規インストール	9%	ソフトウェアインストールと更新
維持管理	資産管理	2%	ハードウェア/ソフトウェア資産登録、調査、廃棄、EOL管理
	構成管理	5%	OS、DB、ミドルウェア、アプリケーション
	日常点検	8%	システム状態の点検、分析作業
	パッチ	10%	OS、ソフトウェアへのパッチ適用（Windows Updateを含む）
	セキュリティ管理	4%	脆弱性点検、アクセス管理・権限管理
変更	変更管理	19%	ハードウェア、パラメータ、アカウント管理、アプリケーション、DBリソースの管理
障害	障害対応	10%	障害の影響、原因の調査と回復処置
	モニタリング	20%	性能管理とシステム監視
レポート	調査とレポート	9%	現状インフラ情報の確認、技術的な検討
その他	テクニカルサポート	4%	サポート対応、会議、電話対応
計		100%

【表】POLESTAR Automationで自動化できる運用管理業務のカテゴリー

これらの作業ひとつひとつは、CLIツールや他の運用管理ツールでも可能なものがほとんどです。 資産管理やモニタリング（監視）には、餅は餅屋でそれぞれ専用のツールがあり、テクニカルサポート（ヘルプデスク）は唯一人手でしか実施できない作業です。
しかし、こうした一連の作業を、全体を俯瞰するように単一のUI上で実現できるのは、グラフィカルなユーザーインターフェース（GUI）がベースで、カスタマイズ自在のダッシュボードを搭載するPOLESTAR Automationならではのアドバンテージです。
例えば、POLESTAR Automationならではの特徴に、サーバーやネットワーク機器の構成情報や設定、動作状況を一定の間隔（毎日、毎週、毎月）で確認し、結果をExcelファイルやPDF等の報告書フォーマットで出力できる「点検」機能や、差分を取得し変化を追跡できる「監査」機能があります。こうした点検や監査をCLIツールで行うことも不可能ではありませんが、「ログ」として吐き出される、作業結果の収集と整理には手間が掛かっているのではないでしょうか。
POLESTAR Automationでは、点検結果をGUI上で表示するだけでなく、あとから活用しやすいExcel形式での出力や、レポーティングエンジンを用いて整理・整形された報告書としての自動出力にも対応していますので、CLIツールで可能な自動化作業に加えて、その後の結果整理まで自動化、ないしは簡素化が可能です。
ジョブがちゃんと走っていたか、問題なく完走したかどうかの結果確認も、POLESTAR Automationなら点検・監査・スクリプトジョブといった各カテゴリーのジョブ結果をまとめて、あるいはカテゴリーごとに一目瞭然で確認可能ですし、エラーがあればエラーの内容も結果をクリックするだけで把握できます。
もちろん、CLI型の自動化ツールの役割として期待されている「ツール」的な作業や、特定の目的を達成するために、複数のジョブを組み合わせて行う比較的複雑なプロジェクト的自動化も、POLESTAR Automationなら500種類ものジョブテンプレートの応用や、新たなジョブ作成（ウィザード形式でも作れますし、弊社で作成をお手伝いすることも可能）を通じて、難なくこなせます。スケジュール外でとっさに必要となった構成情報収集に便利な「ライブオブジェクト照会」機能や、複数のジョブをまとめて実行できる「バッチジョブ」という機能もありますし、APIを使って他のツールと連携させることも可能です。

■2021年はPOLESTAR Automationで「運用業務まるごと自動化」を！

運用自動化のニーズを感じてから実現に至るまで、要件定義や方法論の追求からツールの選定、導入、そして実際に自動化を行うのに必要なジョブの設計・開発と、時間と手間がかかって途中で投げ出した、などというお話もお聞きしたことがあります。もちろんコストも考えなければなりませんが、たとえツールそのもののコストがフリーであっても、学習の手間やジョブ開発に要する時間などの稼働まで考えると、本当に「タダ」でできるわけではないでしょう。
結局はそうしたツールの操作に詳しい人に業務が偏り、属人化回避のための運用自動化が、新たな属人化を生んでしまった、という笑うに笑えない話も、複数のお客様からお聞きしました。
「自動化しよう！」と思い立ったら、まずはPOLESTAR Automationをご検討ください。難しいことは考えず、今行っている運用業務をまるごと、1つの運用プラットフォームに乗せて自動化できます。しかも、一度POLESTAR Automationによる自動化運用に切り替えてしまえば、あとは属人化することもなく運用を続けることができるはずです。
ITインフラの運用自動化をご検討中の皆様。新しい年はぜひとも、POLESTAR Automationに運用業務をまるごと任せてみませんか？ 評価版、PoCプログラムなど、いろいろご用意しております。

…実は本コラム、「鬼滅」の興行新記録達成発表日となった昨年12月28日の正午ちょうどにサイトで公開すべく準備してあったのですが、年内最終営業日ということで他にやることもあって、年明けの本日掲載となってしまったものです。
「鬼滅」関連というと、公式ツイッターアカウントをはじめとする広報活動の「謙虚さ」も、とても印象的でした。他の作品ファンとの対立を煽ったり、「あと〇〇億！」とカウントダウンして過剰に盛り上げたりすることは一切なく、節目ごとに淡々と、来場特典や特殊上映追加などの情報、そして来場者へのお礼を、ひたすら丁寧な文体で謙虚に発信し続ける姿勢に感心していたものです。広報に携わる端くれとして、学ぶところも多かったです。
と、いうわけで、本年もPOLESTAR Automationをよろしくお願いします。



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

皆様の職場では「ビジネスチャットツール」はお使いでしょうか？「コラボレーションツール」などと呼ばれることもありますが、より多くの方がパッとイメージできそうなのは前者だと思いますので、ここではビジネスチャットと呼ぶことにします。
文字によるチーム内コミュニケーション手段であるビジネスチャットツールは、以前からチームで開発などを行うIT系企業を中心に、メンバー間の連絡事項共有などに使われてきましたが、今年はコロナ禍でテレワークがニューノーマルになる中、日常業務の維持に有効な手段として、急速に広まった気がしています。

ビジネスチャットのほとんどはWebサービス、ないしはWeb技術基盤のアプリケーションとして提供されており、ほぼ例外なく、何らかの外部連携用APIを持っています。
つまりREST APIを持つPOLESTAR Automationとの連携も可能というわけで、個別ユーザーやグループ宛にPOLESTAR Automationのジョブからのメッセージを飛ばすという、ビジネスチャットらしい連携を図ってみるべく、早速いろいろ試してみました。
連携の作例は、弊社POLESTARチームで数百個ものジョブ開発やインテグレーションを担当してきた「ジョブの鬼才」ことW君に担当してもらいました。

■基本的な連携手順

REST APIを用いたビジネスチャットへのジョブ結果通知の連携設定の手順です。
同時に通常のメールへの通知を行うことも可能ですので、併せてご紹介します。

1. POLESTAR Automationの「クレデンシャル登録」画面で「NOTIFY_REST」を選択して必要な情報を登録します。

2. ジョブの「通知設定」タブを開き、RESTやメールの通知設定を行います。

「REST」のタブを開き、1.で登録したRESTのクレデンシャルを選択します。RESTには、1つのクレデンシャルのみ設定可能です。

メール通知先には、複数のメールアドレスが設定できます。

3. ジョブを実行してみて、連携対象のビジネスチャットやメールアドレスに通知が届いたことを確認します。

■TypeTalkと連携

実は、このコラムを書くきっかけになったのは「TypeTalk」というビジネスチャットです。
あるお客様からの「TypeTalkでPOLESTAR Automationのジョブ結果を見たい」という要望をいただくまで、不勉強ながら自分は寡聞にして知りませんでした。
調べてみると、クラウド型プロジェクト管理ツール「Backlog」で有名な福岡の企業、ヌーラボさんのサービスなのですね。Backlogは国内のIT企業、特に開発に携わられている方の間ではかなりの知名度と利用率のあるツールという認識ですが、TypeTalkはBacklogと共通のアカウントで使えて連携もできるので、併用すると便利そうです。

TypeTalkにAPI経由で飛ばしてみた、POLESTAR Automationからのジョブメッセージです。

同時に、先に設定したメールアドレスにもこんな感じで通知が届きます。

■Slackと連携

「Slack」はこの分野の代名詞的存在でしょう。ビジネスチャットだのコラボレーションだのというジャンル名ではなく、Slackというサービス名自体がカテゴリ扱いに近いです。
つい先日、Salesforce.comが開発元のSlack Technologiesを買収するという報道もあったばかりですね。日本円で3兆円近い277億ドルというディールだそうです。元はオンラインゲームの会社だったそうですが、現在はSlackだけですので、この買収金額はSlack自体の価値に対する評価というわけです。
数年前から、イケてるIT企業はみんなSlackで社内外とのコミュニケーションを取っているというイメージですが、コロナ禍を受けてのテレワーク実施を機会に、Web会議ツール「Zoom」とセットで導入したという話も、よく耳にします。

Slackにジョブメッセージを飛ばしてみると、こういう感じになります。

■Microsoft Teamsと連携

「Microsoft Teams」は「Microsoft 365(Office 365)」の企業向けサブスクリプションに含まれている（追加で買う必要がない場合が多い）のと、SlackとZoomが1つに統合されたようなツールということもあってか、MSのサブスクを契約している企業を中心に、コロナ禍で急激に利用が伸びたビジネスチャットです。実は弊社でも、全社のテレワーク用コミュニケーション手段として採用したのは、こちらになります。

Teamsには、こんな風に飛んできます。

■工夫次第で広がるAPIの世界

POLESTAR Automationとお使いのビジネスチャットを連携させれば、点検、ファイル配布、監査、Windowsアップデートなど、自動実行されるようにスケジュールを仕込んでおいたジョブの結果が、POLESTAR AutomationのWebUIにログインするまでもなく、いつも開きっぱなしのビジネスチャットの画面上で確認できるようになり、とても便利です。

昨秋、POLESTAR Automation V3に初めてREST APIを搭載した当初は、Zabbix連携に特化したような内容だったのですが、V3.1に至るまでにさまざまな機能を搭載し、何とでも連携できる汎用性を備えた、本格的なAPIに成長しています。先日のJapan IT Week 秋でも、ZabbixだけでなくRedmineとも連携するデモを披露させていただきました。
引き続き、弊社でもいろいろなAPIとの連携を試してみたいと考えています。例えば、TypeTalkと連携できたということは、同じ基盤で運用されているBacklogとも連携できそうですしね。



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

新型コロナウイルス禍の中、久々の大型IT展示会として、10月28日から30日まで幕張メッセで「Japan IT Week 2020 秋」が開催され、弊社もPOLESTAR Automationを出展させていただきました。弊社ブースにご来場いただいた皆様に、この場をお借りして改めてお礼を申し上げます。

■1年ぶりの大型IT展示会、果たしてその成果は…

今年の展示会は春以降、ITに限らずあらゆる分野で展示会の大半が開催中止、ないしは動画配信等を用いてオンラインでの開催となるなど、コロナ禍の影響を大いに受ける形となりました。8月から徐々にリアルの展示会も復活していますが、来場者数は前年の3割から5割未満程度のものが多く、しかもまだ出展企業の多くが出展を見合わせる状況の中で開催された今回のJapan IT Weekということで、弊社ブースへの来場者も、最大で昨年の半数程度だろうと見込んでいました。

それが、蓋を開けてみたら弊社ブースは前年の1割減にとどまり、予想外の結果となりました。展示会全体ではやはり昨年の半数未満の来場でしたので、手前味噌ながら健闘したといえるでしょう。

理由はいろいろ分析できますが、コロナ禍にあっても、否、コロナ禍だからこそ、運用自動化への根強いニーズがあるのだろうと考えています。

POLESTAR AutomationのV3.1へのバージョンアップとともに迎えた今回の展示会は、昨秋のJapan IT Weekでもご好評をいただいた監視ツール・ZabbixとのAPI連携に加え、新たにインシデント管理ツール・Redmineとの連携にも対応し、ZabbixがRedmineで起票したインシデントチケットを、POLESTAR Automationで自動対応してクローズするところまでのデモを披露させていただきました。

さらに、新機能のメール通知連携と、弊社独自開発のクラウド型緊急連絡サービス「急コール」との連携もご紹介しました。 急コールについては以前もご紹介していますが、「メールを送って電話をかける」というのが基本のサービスです。しかも、メールの内容を解析し、架電（電話の発信）の対象とするかどうかを判定するという機能があり、深刻度の高い、本当に必要なメールだけを抽出して電話をかけさせることが可能です。

監視をはじめとするITインフラ系での緊急連絡という本来想定していた用途以外にも、建設業、畜産業、不動産業といった、思いも付かなかったような業種でも導入事例が出てきているところなのですが、今回は本来の用途に近いところで、POLESTAR Automationの点検ジョブで特定のWindows Updateの適用有無を確認し、適用されていなければ新機能のメール通知でメールを急コールの受信アドレス宛に送信し、急コールがメールを受け取ると電話を発信する、というデモを実施していました。

■コロナ禍で改めてクローズアップされる「ひとり情シス」

さて、中島みゆき女史の名曲の1フレーズがタイトルの今回のコラムですが、展示会に来場されていた「ひとり情シス」の方とお話していて、この曲を思い出したからです。好きで率先してひとり情シスになられたという方は、少ないでしょうからね…
ここ数年、ITインフラ管理分野において深刻な課題となっている、ひとり情シス・ゼロ情シスについては、POLESTAR Automationを初めて展示会に出して以来、多くの来場者の皆様から悩みの声が寄せられています。時には悲鳴に近いお話もお聞きしていたものです。
特に、今年はコロナ禍発生とそれに伴う4月の「緊急事態宣言」という、過去に経験したことのない状況で、より厳しい条件での情報システム運用を迫られてきたことと思います。

従来のサーバーやネットワークの運用に加え、VPNやリモートコンピューティング、クライアント仮想化といった、テレワーク実施に不可欠な業務のリモート化対応という喫緊の課題が発生し、多くの社員が在宅勤務・テレワークとなる中で、情シス担当だけは事業所への通常出勤・長時間勤務を迫られるようなケースも多く、COVID-19以外の要因で体調を崩されていた方もいらしたそうです。
業務量、業務負荷の軽減には、運用自動化が役立ちます。

POLESTAR Automationの良いところは、具体的な課題に1つ1つ対応する単品のソリューションではなく、日常的な作業を含む情シス運用業務のフローをまるごと載せることが可能な、プラットフォーム型の運用自動化ツールであることだと思っています。
軽快でわかりやすいWeb UIを搭載し、運用業務を俯瞰的に把握しながら必要な作業をスピーディに実施できるPOLESTAR Automationは、ひとり情シス・ゼロ情シスの課題解決にも適していると自負しています。
VPNなどを通じて自宅等からPOLESTAR Automationの管理UIにアクセス可能にしておけば、テレワークでの運用業務実施にも役立つことでしょう。

■ひとり情シスの皆様、ぜひともご相談ください

POLESTAR Automationにひとり情シス運用に適したジョブを組み合わせて最適化したソリューションパッケージ「ひとり情シスパック」も、今回の展示会に合わせて提供を開始しています。価格面でも、年間予算の策定段階でガッツリと組み込んでの稟議プロセスを待つことなく、期中や期末の残予算でも導入可能なレベルを目指しています。
しかし、考えてみれば、日夜情シス業務に追われていて、POLESTAR Automationを必要とされている方は、展示会に来場される時間が取りづらかったのではないかと思います。

この春以降、弊社でも各プロダクト・サービスの商談は原則オンラインとし、ZoomやMicrosoft TeamsなどのWeb会議ツールを使用して行わせていただいておりますが、POLESTAR Automationが自治体やひとり情シスの皆様の課題解決にどのように役立つのか、営業担当者からオンラインでご説明させていただきます。所要時間は1時間程度で十分ですので、ぜひともご調整の上、説明の機会をいただければと思います。お気軽にお申し付けください。

さて、展示会終了から約2週間、これから寒い季節を迎えようとしている中、再びCOVID-19感染者の増加傾向が報告されるようになり、本稿の執筆中に、1日あたりの感染者数が過去最大になったというニュースも入ってきました。例年猛威を振るうインフルエンザの状況も、気になるところです。
衛生面をはじめとして、対策の徹底は欠かせませんが、無理をせず体力に負担を掛けることのないよう、業務負荷を調整することも大切だと思います。
コロナ禍に打ち勝つための運用のニューノーマル・POLESTAR Automationで、この冬を乗り切りましょう。



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

今回は前書きなし、いきなり始めます。テーマはこれです。

■今どきのNASは…

このQNAP、最近、お客様から「POLESTAR AutomationでQNAPのNASが管理できるか？」というお問い合わせをいただいたので、検証のために購入したものです。

取り急ぎ、社内のサーバー室から古いハードディスク(HDD)2台を提供してもらって組み込んでみたのですが、装着はネジ不要、非常に簡単です。RAID動作中に片方のHDDが故障してもその場で交換できる「ホットスワップ」にも対応しています。
NASの基本構造はHDDケースにCPU、メモリ、ネットワーク(LAN)インターフェースが付いたもので、近年はUSBインターフェースなども標準的です。OSはLinuxかWindows(Windows Storage Server)ですし、ディスプレイ出力がない（最近はHDMIが付いているものもありますが）だけで、ほぼPCですね。

NASの目的はLAN上でのストレージの共有ですが、その昔、PC周辺機器メーカー数社からLinuxを搭載した低価格のNASケースが発売され、本来の用途だけでなく、Webサーバーとブログ用CMS（WordPressなど）を立ち上げたり、VPNを組み込んで遠隔ファイル共有をしたりと、さまざまな用途が開拓されていったものでした。
今では、NASベンダー自体が元からそうした多用途のアプリケーションサーバー、ホームサーバーを志向しているように思います。
国内のNAS市場というと、B社やI社といった日本の有名周辺機器ブランドのものもありますが、主役はQNAPやSynology（シノロジー）のような台湾メーカー製だと思います。
とにかくコストパフォーマンス（価格が安いというより、文字通りの価格対性能比、費用対効果の意味で）が優秀ということで、SMB（中小企業）からSOHO、個人まで幅広く愛用されている印象があります。スペックも良いのですが、前述のようなアプリケーションの豊富さも人気の理由でしょう。

■QNAPをLinuxサーバーとして使うには

QNAPのNASには、CPUにx86/x64系とArm系のRISCを採用したものがあります。今回購入したTS-231Kは後者で、Annapurna Labs（Amazonの関連会社らしいです）のAlpine AL214という、クアッドコアのArmを搭載しています。
OSは「QTS」という、独自のWeb GUIを搭載したLinuxベースのもので、CPUに関係なく共通で用意されているようです。このスマホやタブレット端末を彷彿とさせるGUIが非常に出来がよく、初期化やRAID関連を含む基本設定は、何でもGUIだけでできてしまいます。「App Center」というGUIベースのアプリインストーラもあり、バックアップツールやWordPress、MediaWikiのようなCMS、メディアサーバー、ホームオートメーションなど、NASで可能な一通りのアプリケーションがカバーされています。

一方、普段からCLI（コマンドライン）に慣れ親しんでいるユーザー向けには、CLIによるアクセス手段もちゃんと提供されています。SSHやTelnetを有効化すれば、常用のターミナルクライアントからCLIでログインできます。
しかし、このCLIが結構独特なもので、adminというアカウント名ながらroot権限になってはいるものの、標準のシェルがbashなどではなく、素のUNIXシェルであるshである上、yum/dnfやaptのようなパッケージインストーラも提供されていません。
とりあえず、QNAPをCLIモードで汎用Linuxサーバーっぽく使えて、かつPOLESTAR Automationの管理対象としてスクリプトジョブなども走るようにするには、

– シェルをshからbashに変更する

– パッケージインストーラを使えるようにする

の2点が必須かな、ということで、早速実践してみました。

■QNAPにパッケージインストーラを追加+シェルをbashに

ここでは、QNAPのNASをSSH経由でCLIの使えるLinuxサーバーとして設定する手順をご紹介します。

1. SSHの有効化

まず、QTSのWeb GUIにログインしてでコントロールパネルの「ネットワークサービスとファイルサービス」-「Telnet/SSH」からSSHを有効にしておきます。

2. Web GUIからEntwareのインストール

QNAPやSynologyなどのNAS用独自OSに、CLI用のパッケージ管理機能を追加できる「Entware」というソフトウェアをインストールしますが、「App Center」のQNAP標準アプリストアからはインストールできないので、手動でインストールします。
最新のEntwareは、以下の場所にあります
https://github.com/Entware/Entware/wiki/Install-on-QNAP-NAS
「Download this package for standard installation…」の「this」以降の文字列が、インストーラファイルのリンク先になっています。クリックすると、インストーラ（本稿執筆時点ではEntware_1.00std.qpkg）がダウンロードされます。
App Centerを起動してツールバーから「手動でインストール」アイコンをクリックし、先にダウンロードしたインストーラを開いてEntwareをインストールします。
（いろいろ警告が出ますが、とりあえずスルーしてください）

次に、お使いのターミナルクライアントで、QNAPのアドレスへのSSHを設定します。
GUIにログインするのと同じadminアカウントとパスワードで、SSHにもログインできます。
Entwareが入ると、パッケージインストーラの「opkg」コマンドが使えるようになります。例えばテキストエディタのnano（個人的にはこれが一番使いやすいと思っています…）をopkgでインストールするには、以下のように実行します。

# opkg install nano
root権限ですので、頭にsudoは不要です。

3. CLIシェルの変更

ところで、この時点でのシェルは前述の通り「sh」です。現在のシェルを確認するには

# echo $SHELL
と実行しますが、返ってくるのは

/bin/sh
のはずです。
ほとんどのLinux使いの皆さんはbashに慣れていると思いますので、bashを標準シェルに設定（固定）しましょう。
テキストエディタ（標準で入っているvi/vimでも、opkgでインストールできるnanoでも）で /etc/passwd を書き換えます。

admin:x:0:0:administrator:/share/homes/admin:/bin/sh
を

admin:x:0:0:administrator:/share/homes/admin:/bin/bash
に変更して保存後再ログインすれば、以降はbashが標準のシェルになります。 /etc/passwd には他のユーザーの情報も入っていると思いますので、/bin/sh は全部 /bin/bash に書き換えてしまいましょう。
bashが適用されるとプロンプトが[~]から[admin@サーバー名 ~]に変わるので、シェルが変わったことがわかるかと思います。先のecho $SHELLでも

/bin/bash
と返ってくるはずです。

4. パスを通しておく

Entwareのopkgでインストールしたプログラムは /opt/bin または /opt/sbin ディレクトリに保存されます。
Entwareのインストール直後は、これらのディレクトリにパスは通っていません。
以下のコマンドを実行するとパスが通ります。

export PATH=/opt/bin:/opt/sbin:$PATH

次回のログイン以降も有効にするには、テキストエディタで ~/.bash_profile ファイルを開き、最終行に上記のコマンドを追加して保存します。

■QNAPはエージェントでどうぞ

POLESTAR Automationにサーバーを登録する方式には、エージェントとエージェントレスの2種類がありますが、QNAP QTSは現状、エージェントレスでの登録ができません。
QNAPではエージェントをお使いください。CPUがx64系であればx64版が、Arm系ならRaspberry Pi（ラズパイ）用として提供しているエージェントが利用できます。
TS-231KはArmですので、ラズパイ用エージェントをTera TermのSCPで送ってインストールし、POLESTAR Automationに登録することができました。

ところで、QNAP（最新ファームウェア、バージョン4.4.3.1381）でのEntwareに関しては、今回どうしても解決できなかった問題が残っています。
QNAPを再起動すると、Entwareそのものやopkgでインストールした /opt 配下のプログラム、パス設定、あとPOLESTAR Automationのエージェントなどが消失してしまうのです（bash関連の設定変更だけは戻されませんでした）。
どこかにバックアップがあるのか、前述のインストール手順でEntwareを再インストールすると、再起動前に存在していた /opt 以下の内容が復旧します。ただし、POLESTAR Automationのエージェントだけは、再インストールが必要でした。
セキュリティ機能が働いているのでしょうが、今後さらなる追究が必要かなと考えています。
なお、ネットワーク機器として登録する方法もあり、こちらですと明示的に削除しない限り登録が消えませんが、利用可能なジョブには限りがあります。

以上、QNAPのNASをPOLESTAR Automationに登録する方法と、その前提となる環境構築手順をご紹介しました。なかなか面白い実験でしたが、再起動の件はなんとかならないかなと思っています。
そこの解決方法も含め、引き続き検証を続けて行くつもりです。上位機種なら管理対象としてだけでなく、POLESTAR Automationの管理サーバーも動かせるかなと思いますので、機会があればトライしてみるつもりです。あと、NASのもう一方の雄、Synologyもぜひ試してみたいところですね。



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

「ラズパイ」ことRaspberry Piの小型版「Raspberry Pi Zero WH」を買ってみました。
ラズパイは自宅や実家で数台が全部違う目的で稼働中、社内でもテストやデモ用途で活躍中なのですが、これまで自分が触ったものはすべてクレジットカードサイズと呼ばれるModel B系統でしたので、Zero系統は自分にとっては初めてです。
Zero WHを購入した目的は、センサーのデータを現在製品化準備中のIoTプラットフォームに送り込むテストを、より小型で低価格なZero WHでやろうとしているからなのですが、肝心のプラットフォーム本体も外からの接続に必要なハードウェアもまだ揃っていないので、取り急ぎ1,000円以下で買える温湿度センサーを用意し、まずは社内のPOLESTARテスト用ネットワーク(LAN)に接続、POLESTAR Automationのジョブを使ってデータを取ってみることにしました。

■V3が「公開鍵認証」に対応しました

今回はまず、POLESTAR Automation V3がv3.0.8から待望の「公開鍵認証」に対応したお話からです。対象はSSHを用いるエージェントレスやネットワーク機器で、ジョブ実行に必要なログイン認証を公開鍵方式で実行できるようになりました。

従来、サーバー等へのログイン認証というと、IDとパスワードを組み合わせる方法でセキュリティを担保する、伝統的な方法が採られてきました。
しかし、数字や文字の羅列で構成されるパスワードは、それ自体が盗まれるなどの物理的な奪取に遭わなくても、文字列を自動生成し、手当たり次第に侵入を試みる「ブルートフォース攻撃（総当たり攻撃）」でたまたまヒットしたパスワードにより攻撃・侵入される可能性がないとは言えません。
対策として、文字列を長くしたり、大文字/小文字の区別や数字・記号などの組み合わせで複雑化することが行われていますが、複雑なパスワードはブルートフォースには強くても人間には覚えづらく、いざ必要な時に忘れてしまってログインできなかった、という本末転倒なケースも少なくないようです。
また、実際の侵入には至らなかったとしても、例えばSSHで標準(Well-Known Port)となっているTCP 22番ポートが空いていると攻撃の対象になりやすく、連続した執拗なアタックが繰り返されることでサーバーに負荷が掛かったり、大量の不要アクセスログが発生して管理の手間を煩わせたりする原因となります。

こうしたパスワードの問題点を克服すべく、パスワードに代わる認証手段がいくつか考案されていますが、公開鍵認証はその中でも代表的なものでしょう。
公開鍵認証は「公開鍵(Public Key)」と「秘密鍵(Private Key)」という、2種類の「鍵」と呼ばれる情報を照合することで、認証を行う方式です。公開鍵はログイン先（ログインされる側）のサーバーなどに保存されている鍵で、秘密鍵はログイン元（ログインする側）がファイルなどの形で保持する鍵です。公開鍵はログイン先で、秘密鍵を持ったログイン元からのログイン要求が行われるたびに、毎回暗号化されてログイン元に渡されます。ログイン先から受け取った公開鍵情報がログイン元の秘密鍵情報と一致すれば、認証が成立します。

パスワードログインを禁止し、パスワードプロンプトを出さないようにすれば、ブルートフォース攻撃の影響も抑制できます。
また、長いパスワードを覚える必要もなくなるので、一旦設定してしまえばパスワードログインより容易にログインできます。
今では、いわゆる3大パブリッククラウドや有名VPSサービスなど、クラウドでサーバーを貸すサービスの多くで公開鍵認証が基本となり、パスワードログインへの切り替えを禁止しているところもあります。

と、いうわけで、弊社の業務や自分個人の私的なものも含め、利用中のクラウドやVPSの全てに公開鍵認証を設定していることもあり、POLESTAR AutomationがV3でエージェントレスに対応することが決定した時点で、開発元に公開鍵認証への対応を要望していたのですが、今回ようやく実現したものです。 下のスクリーンショットは、前述のラズパイZero WHをエージェントレスサーバーとして登録した際のログイン設定です。

最下部に「SSHクレデンシャル」という項目が追加になりました。POLESTAR Automation V3におけるSSHクレデンシャルとは、公開鍵認証に必要なプライベートキー（秘密鍵）とログインIDなどの情報を含む設定を指し、それ自体は「管理者」-「システム管理」の下に新設された「クレデンシャル管理」メニューから登録します。
一方で「パスワード」欄が空白になっています。公開鍵認証ですので、パスワードは不要です。

なお、エージェント方式の場合は、エージェントを管理対象サーバーに管理者権限でインストールすることで、POLESTAR Automation管理サーバーとの通信やコマンドの発行・ジョブ実行が可能な状態になりますので、もとから認証やパスワードの存在を意識する必要はありません。

■ラズパイ+POLESTAR Automationで温度・湿度測定のプチIoT

POLESTAR Automationとラズパイといえば、Raspbian OSで動くエージェントもあるのですが、せっかくエージェントレスでの公開鍵認証に対応したので、SSHクレデンシャルを作成してPOLESTAR Automationの管理サーバーに登録した上で、今回購入した温湿度センサーで10分ごとに温度と湿度を測定するジョブを作り、走らせてみました。
作成手順は今回は省きますが、POLESTAR Automation自慢の「ジョブ作成ウィザード」を使ってエージェントレス用のスクリプトジョブを作り、温湿度センサーのサンプルプログラムを動かすためのコマンドを1行入れただけの、超シンプルなものです。

今回はLAN上で動かしていますので、このコラムを書いている自席のPCから数mしか離れていない場所での測定ですが、機材が揃ったらもう少しIoTらしく、離れた場所に置き、SORACOM Air SIMを使って3GかLTEで接続してみたいと考えています。

■最後にちょっとだけ、Coming Soon!

と、このコラムを書いている間に、POLESTAR Automation V3のビッグマイナーチェンジとでも呼ぶべき、多数の新機能追加の情報が入ってきました。
V3をリリースしてこの9月で1年になりますが、その頃には大幅に機能強化された新バージョンのお知らせができそうです。
もちろん、今すぐ導入を決めていただいても、アップデートは無償で提供させていただきます。評価版も公開鍵認証対応を含めて新しくなっていますので、どうかお試しの上、お気に召したら本番導入やPoCをご検討いただければ幸いです。



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

COVID-19（新型コロナウイルス）感染拡大対策として4月上旬から続いてきた「緊急事態宣言」の段階的な解除が進む中、弊社でも連休を挟んで2か月近く続いたテレワークが終了し、通常の勤務体制に戻っています。
宣言解除を機に「3密」を避けつつも出掛けてみる気になったのと、しばらく前にスマホの契約を「5G（第5世代移動通信）」に変えたのとで、まだ都内でも数少ない、5Gの電波が飛んでいる場所に電車で行って5Gを試してきたのですが、速度を測ってみたら、かつて見たことのない数値が叩き出されました。

しかし、残念ながら5Gは弊社のオフィスや周辺ではまだ使えず、公表済みのエリア拡大予定にも入っていません。駅などへの展開も夏頃と聞いています。技術的な事情もいろいろとあるようですが…
と、いきなり脱線から始まった今回のコラムですが、久々にストレートなPOLESTAR Automationの話題として、このたびリリースした最新版「3.0.7」をご紹介します。

■帰ってきたファイル＆レジストリビュー

POLESTAR Automationの前バージョン(V2)にはあって、V3でなくなっていた機能に「ファイルエクスプローラー」と「レジストリ」がありました。
主にWindowsで動作しているサーバーにおいて、Windowsに標準で搭載されているファイルエクスプローラーやレジストリエディターと同等のユーザーインターフェース、同等の機能を提供するもので、1台の管理用UIからいちいち個別の管理対象マシンのコンソールやリモートデスクトップを開くことなく、ファイルやレジストリの確認ができて便利だと好評をいただいていたものです。
しかし、昨年9月にリリースしたPOLESTAR Automation V3では、FlashからHTML5ベースへの変更という、POLESTAR Automation史上最大の刷新が実施されたことで、ファイルやレジストリビューの開発は先送りになっていました。
今回「復活」したファイルエクスプローラーとレジストリ機能は、V2時代のそれでは、右ペインにWindowsのようにフォルダー（ディレクトリ）やレジストリのツリーと内容が表示されるだけでなく、ワークスペース（左ペインのツリー）内にも階層構造が表示されていたので、フォルダーやレジストリの項目が多いと、両方が全部表示され終わるまで時間を要していました。
V3では右ペイン内にだけ表示されるようになりましたので、表示の所要時間が短縮できたと思います。
なお、本機能は管理対象サーバーにエージェントが導入されている環境でのみお使いいただけます。あと、レジストリはWindows固有の機能となりますが、ファイルの方はLinuxでもお使いいただけます。

■快適さを実感！ さらに最適化の進んだHTML5 UI

3.0.7で追加された新機能としては、内蔵レポーティングエンジンによる報告書作成機能が、エージェントレスサーバーやネットワーク機器にも対応したことが挙げられます。多数のテンプレートを追加しています。
ところで、POLESTAR Automation V3では、ブラウザ本体とは別のUI描画プラグインであるFlashを廃止し、ブラウザ内部の描画エンジンを利用するようになったことで、V2からお使いいただいているお客様からも、従来よりも動作が軽快になったとのお声をいただいています。
昨年リリースしたばかりのUIということで、実はその後も機能追加だけでなく、目に見えない部分の改良も進めています。特にGUIあってのPOLESTAR Automationということで、管理UI画面の操作性やレスポンスの向上に注力しています。
実際、バージョンが上がるたびに少しずつ速くなっているのですが、今回、前バージョンのV2や最初のV3などを触り比べてみて、最新の3.0.7はチューニングが進み、さらに軽くなっていることが実感できました。
もちろん、管理UIを動かすPCやブラウザの描画速度などにも左右されるとは思いますが、確実に言えるのは「史上最速のPOLESTAR Automation」であるということです。5Gのように、というのは言い過ぎですが…

■評価版が新しくなりました

このコラムを掲載するタイミングで、POLESTAR Automation評価版も3.0.7に更新しました。
POLESTAR Automation評価版の特徴のひとつに、商用ソフトウェアとしては「破格」と自負する、180日もの長い評価期間が挙げられるでしょう。
ぜひともファイル＆レジストリビューや快適なGUI、API連携など、POLESTAR Automationならではの機能をじっくりとご評価いただければ幸いです。
新しい評価版のダウンロードは、こちらからどうぞ。

■ロゴも新しくなりました

2016年秋から使ってきたロゴ書体を、約4年ぶりに刷新しました。今後カタログなどの印刷物も、順次更新して行く予定です。

ポスト・コロナ時代に向け、新しいバージョン、新しいロゴで再始動するPOLESTAR Automation。これからも理想のITインフラ運用を目指して進化を続けます。ご期待ください。



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

運用自動化の事例

運用自動化の効果

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

前回のコラムは2月20日公開でしたので、2か月ちょっと空いてしまいましたが、COVID-19こと新型コロナウイルスが各方面に及ぼした影響は、その時点での予想をはるかに上回るものになってしまいました。

東京五輪を含め、多くのイベントが中止ないしは延期となり、非常事態宣言により「接触8割減」、「3密回避」が叫ばれる中、テレワーク（リモートワーク）も当たり前のものになりました。

わずか数か月ほどの間に、コロナ禍は仕事のやり方、あり方すら、物凄いスピードで変えてしまった気がしますね。2月の時点で時差出勤やテレワークなどを実施していた企業は既に相当数ありましたが、今ではIT企業や事務職の大半がそうなっていることでしょう。弊社も例外ではありません。

■電話転送系サービスの需要が急増

弊社が自社開発・提供している商品には、「ボイスワープ」など各電話会社の転送電話サービスの設定を自動的に切り替えたり、着信した電話を順次または複数回線一斉に鳴らして転送したりするサービスをラインナップしているクラウド型多機能電話転送サービス「転送録」や、前回このコラムでもご紹介した、監視システムなどと組み合わせてメールでは気付きにくい緊急連絡を電話を鳴らすことで通知する「急コール」など、いかにもこのご時世に求められそうな、電話関連のサービスが揃っています。

これらは別にテレワークの普及・拡散を意識して開発していたわけではないのですが、たまたま在宅勤務や緊急連絡に適したサービスがいくつもあったことで、各製品のWebサイト閲覧数、導入決定数ともに、想像を絶するレベルになっています。何より、担当チームのメンバーが非常に忙しい毎日を送ることになってしまいました。

電話に関することなので、問い合わせもメールよりは電話の方が多いですし、お客様の中には営業の直接訪問をご希望されておられる方も少なくないです。

しかし、「接触8割減」や「ソーシャル・ディスタンシング」などが叫ばれる中、お客様を直接訪問するのは難しくなってきてしまいました。そこで弊社で導入済みのMicrosoft 365（旧Office 365）に標準で含まれていながら、これまで活用されてこなかったMicrosoft Teamsを利用して遠隔セールスをやってみてはどうか、という話になったのです。

当初はおそらくどこでもそうであったように、懐疑的な意見も多かったのですが、今では各担当も、直接訪問の代わりにTeamsを用いた製品説明にすっかり慣れてしまったようです。

■商談のリモート化から、NetSupportによる全社テレワークへ

そんなわけで、弊社のテレワークはなし崩し的に始まってしまった部分もあったのですが、先の緊急事態宣言を機に、弊社でも出社人数の削減を図ることになり、全社で弊社20年の歴史上初めての在宅勤務制が導入となりました。

テレワークに利用するツールはTeamsと、2つの弊社取り扱い製品です。ひとつは先の転送録で、本社の電話を各営業担当者の社用携帯電話に転送します。

もうひとつは「NetSupport Manager」。これは自社開発ではなく英国産で、現在日本では弊社だけが取り扱っているソフトウェアです。弊社では販売代理店になる前から案件への組み込み等で20数年の利用歴があるのですが、自社で全社員が利用することになったのは初めてです。

平たく言えばWindowsの標準機能である「リモートデスクトップ接続」に似た、会社のWindows PCを自宅など社外のPCから操作できる、リモートコントロール・ソフトウェアです。

このNetSupportをテレワークに使う最大のメリットは、「ゲートウェイ」の存在です。会社のPCはプライベートIPで接続されたLAN上にあるのが普通で、自宅のPCもまた、ルーターなどの配下にあってLANでつながっていることでしょう。ざっくり言うと、ゲートウェイとは異なるLAN上にあるPCに、簡単に接続できる機能です。

異なるLAN上にある会社のPCに自宅から接続するには、会社のルーターの設定でポートフォワーディングを行ったり、そのポートをファイアウォールで開放したりと、手間が掛かります。VPNを使う方法もありますが、セキュリティに配慮しながらVPNの設定を全社展開するのは、かなりの労力を必要とします。VPNでテレワークを実施している会社は、以前からVPNが導入済みのところが大半だと思います。

弊社では、NetSupportの全社導入の方針を決めてから、実際にゲートウェイの社内構築と必要なソフトウェアの展開を終えるまでの所要期間は、3営業日程度でした。

実はこのコラムもNetSupportで、自宅から会社のPCに接続して書いているものです。会社のPCですので会社のファイルサーバーにもつながります。しかし、セキュリティ上の理由からファイルの転送はもちろん、クリップボードの利用も制限されています。そういうセキュリティ対策が簡単にできるのも、NetSupportならではですね。

電話転送やWeb会議と比べ、リモートデスクトップ系の導入は一筋縄には行かないところもあるでしょうが、NetSupportなら本当に数日で済みます。あと、ゲートウェイは弊社では社内に立てましたが、例えばAWS、Azureのようなクラウドや、ConoHaやさくらのようなVPSにも立てられます（但し、OSはWindowsであることが条件です）。

リモートデスクトップ導入がまだのお客様、ぜひともNetSupportもご検討いただければ幸いです。30日間無料で試用できます。詳しくはこちらをどうぞ。

■POLESTAR AutomationでIoT。やってみませんか？

さて、このコラムはPOLESTAR Automationのプロダクト専用サイト上にあるので、最後にPOLESTAR Automationにも触れておかなければなりません。

弊社ではコロナ禍の中、4月8日にIoT専用サイトを立ち上げました。とはいうものの、現時点では実質的にいわゆるティーザー（事前告知）サイトで、夏に発売する予定のAI搭載IoTプラットフォームのご紹介が主な目的ですが、リリースまで少し時間があります。

そこで今回、同プラットフォームのリリースに先駆け、既に多くのお客様にご愛用いただいているPOLESTAR Automationを、IoT向けに「POLESTAR Automation for IoT」として展開して行こうという話になりました。

POLESTAR AutomationのIoTでの活用については、以前からこのコラムで何度かご紹介してきた通りでして、特にV3になってからはエージェントレスもサポートしましたので、メモリやストレージに余裕のないIoTデバイスにコマンドを送ったり、データのやりとりをする上で便利になっています。

まずは、PoC（概念実証、評価）をご一緒させていただけるお客様を募集します。ご興味のある方は、まずはこちらのページをご覧いただければ幸いです。

もちろんTeamsを用いたWeb会議によるご説明にも、対応させていただきます。

以上、POLESTARの話はわずかになってしまいましたが、この連休中、連休明けまでとされていた緊急事態が、5月末まで延長と発表されました。オフィスに全員の顔が揃う日は、もう少し先になりそうですね。

とにかく今は、一日も早く感染の沈静化を願うばかりです。



国内外の大型データセンターから、数百台規模の企業内サーバールーム、10ノードほどの「ひとり情シス」まで…さまざまな規模・業種・業態のITインフラ運用を、自動化・効率化・省力化してきた「POLESTAR Automation」。
その先進的で柔軟な運用自動化・構成管理のソリューションを、IoT機器の運用管理向けにご提案いたします。

■IoTデバイス/ゲートウェイの管理を自動化・省力化

コンソールから手作業で行っていた一連の運用業務を「ジョブ」として定義・実行するのが、POLESTAR Automationでの自動化の基本です。
大量のセンサーデバイス・複数箇所に分散配置されたエッジサーバーなどを対象に行う繰り返し作業や、夜間や休日等の勤務時間外に行わざるをえなかったアップデートなどを自動的に実行し、あとで結果も確認できます。管理対象台数が多ければ多いほど、作業に必要な時間を短縮できます。
簡単にジョブを作成できるウィザードや、定型的な作業を対象機器と実施タイミングだけを設定すれば自動化するジョブ・テンプレートを用意しており、活用までのリードタイムも短時間で済みます。

• センサーの収集したデータを定期的に取得し、BIツールなどに送信
• プログラムや制御用データのアップデート
• セキュリティ対策のためのプログラムや制御用データ差分チェック
• センサーやゲートウェイデバイスなどへのコマンド送信
• デバイス障害発生時の自動再起動
• 作業結果の確認

■エージェントレス/エージェント両方式による幅広いデバイス対応

管理対象デバイスのPOLESTAR Automation管理サーバーへの登録には「エージェントレス方式」と「エージェント方式」の2種類が利用できます。

• 管理対象デバイス（サーバー）側にエージェントレスのインストールが不要なエージェントレス方式は、SSH（パスワード認証・公開鍵認証）の利用可能なほとんどのデバイスに対応可能。ストレージやメモリ容量に余裕のないIoT機器に最適です。
• エージェント方式は、エージェントのインストールと管理サーバーへの登録だけで運用自動化を始められ、独自プロトコルを用いた高速でセキュアなデータ転送、きめ細やかな運用管理が可能です。x86/x64(Linux/Windows)とRaspbian OS専用エージェントを用意していますので、エッジサーバーやRaspberry Piなどの管理に特に適しています。
• IoTゲートウェイ（※）を含むネットワーク機器に最適化された、専用の構成管理機能を搭載しています。

※CLIの利用が可能なものに限ります

■REST APIによる外部連携

各種の監視ツール・チケッティングツールなど、REST APIの利用可能な外部ツールとの連携が可能。アラートやデバイスメッセージをトリガーとするジョブの実行、チケットの発行と処理などを、作業フローに沿った形で自動化します。

• API外部連携につきましてはこちらのページをご参照ください。

■運用実務者の立場で考え、磨き抜かれたUI

軽く、操作しやすいHTML5ベースのGUI。構成要素をウィジェット化し、個人毎に必要な情報を見やすくレイアウトできる、カスタマイズ性にすぐれたダッシュボードを搭載しています。

■10ノードから導入可能、サブスク・買い取りどちらにも対応

提供形態はサブスクリプション（10ノード～）とライセンス買い取り（50ノード～）の2種類。プロジェクトの規模や必要期間に応じて最適な導入形態をお選びいただけます。

• 導入形態につきましてはこちらのページをご参照ください。

---

【POLESTAR Automation for IoT 早期検証支援プログラム（PoC）】

ワイドテックでは、POLESTAR AutomationのIoT向けPoC（概念実証）にご協力いただけるお客様を募集しています。
POLESTAR AutomationのIoTへの展開は、まだ始まったばかりです。自動化ジョブの開発をご要望に応じて支援しながら、お客様とともにIoTでの活用事例を作り上げて行きたいと考えています。
検証支援プログラム（PoC）には、一切費用はかかりません。商用（本番）導入につきましても、優遇条件にて提供させていただきます。

• PoCプログラムにつきましてはこちらのページをご参照ください。

---

※「POLESTAR Automation for IoT」はマーケティング上の呼称です。
提供するソフトウェアは、ITインフラ向けのPOLESTAR Automation V3と同一となります。



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

昨年末に発見されたCOVID-19（新型コロナウイルス）が、多方面に影響を及ぼしています。 国内でもBCP対策の一環として、人混みを避けるための時差出勤や、テレワーク（在宅勤務）に踏み切る企業も出ていると聞いています。この原稿を書いている最中、東京マラソン（3月1日）の一般参加者出場が中止、というニュースも飛び込んできました。

■「非常時」に強い運用とは

感染症が「パンデミック」と呼ばれる「非常事態」レベルにまで至ると、現在は企業ごとに自主的な判断で行われている時差出勤やテレワークが、国や自治体レベルで推奨されることになるかもしれません。
既にこの原稿を書いている2月17日現在、日本政府はCOVID-19の感染拡大を防ぐため「不要不急の外出」は控えるよう呼びかけ始めており、一部の企業にもこの呼びかけに呼応する動きが出始めているようです。

もちろん、経済活動を全面的に止めることはできないでしょう。COVID-19が最初に発見された中国でも同様でした。延長された春節（旧正月）休暇が終わった現在でも、不要な外出は控え、可能な限り自宅で過ごすことが奨励されていますが、自分もよく利用している「微信（WeChat=LINEに相当）」や「愛奇芸（NetFlixに相当）」といった中国の大規模なITサービスは、春節期間中も大きな不具合を起こすことなく動いていました。今回特にこうしたSNSやコンテンツ配信では、奨励された在宅中の情報や娯楽へのニーズから、トラフィックが急増していたにもかかわらず、です。

さて、国内の話に戻すと、今後仮に感染拡大が進んだ場合、感染拡大の防止や従業員の安全確保といった観点から、限られた人数でいかにシステムを運用し、安定性を担保するかが課題として浮上してくるのは、確実かと思います。

POLESTAR Automationが2016年10月の発売開始以来訴求してきたのは、そうした少人数でのシステム運用に加え、「属人化対策」への有用性です。 多くの運用自動化製品は、シェルスクリプトやバッチファイルといったOSごとに異なるスクリプト書式の代わりに、その製品固有の書式によるコードによって自動化を図ることをコンセプトとしています。「Infrastracture as Code(IaC)」とも呼ばれます。OSごとの違いを自動化製品が抽象化し、吸収しようという思想です。
抽象化によるIaCは実現されれば理想的な運用になりえますが、IaC用のコードは全面的な新規作成が必要になるうえ、実際はOS固有部分を完全に抽象化するところに至っていません。
POLESTAR Automationは、IaCの思想を取り入れつつも、既存のスクリプト書式をそのまま用いて自動化を図ることに重点を置いています。従来のスクリプト資産を活用・継承しながら自動化が達成できます。
また、最初からGUIを前提に設計されていますので、過程や結果の確認も容易です。とりわけ、点検や監査（差分確認）においてGUIのわかりやすさは有用です。

「属人化しない運用」、それは万一の不可抗力による運用体制縮小にも対処できる運用であると考えます。もちろん運用手順をはじめ作業内容の標準化あってこその属人化排除なのですが、運用の標準化を図るには、運用自動化製品の導入による手順の標準化が有用です。 そして、POLESTAR Automationは、最も属人化しにくい運用自動化ソリューションであると自負しています。

■Zabbix認定パートナーになりました！

話はガラッと変わりますが、このたび、株式会社ワイドテックはZabbix LLC（Zabbix社、東欧・ラトビア）の「認定パートナー」となりました。

実は弊社では、Zabbixが日本に紹介されて間もない頃から、Zabbixの絡む構築や運用案件を、さまざまな形で手掛けてきており、Zabbixの経験が豊富なエンジニアもたくさん抱えていたりします。
しかしながら、これまでは自社開発製品や、POLESTAR Automationのように自社で販売権を持っている製品を主力にしたいという方針から、Zabbixそのものを積極的に販売していくことはありませんでした。

それが昨年、POLESTAR AutomationのAPIによる外部連携を発表して以来、お客様からZabbixそのものについてのご要望も多数いただくようになり、Zabbixを公式な形で取扱製品に加えるべく、認定パートナーに加わることとなりました。 今後は運用ソリューション提案の一環として、POLESTAR Automationと連携する形でのZabbixによる監視ソリューションを提案していくことになります。

もちろん、Zabbix単体での導入案件にも対応させていただきます。お気軽にPOLESTAR担当営業までお問い合わせください。 なお、弊社では4月13日（月）～15日（水）に開催されるInterop Tokyo 20（幕張メッセ）のZabbix Japanブースに共同出展することになりました。Zabbixとの連携ソリューションをお見せする予定です。
直前の4月8日（水）～10日（金）には、Japan IT Week 春（東京ビッグサイト西展示棟、こちらは単独出展）にも出展しますので、土日を挟みはするものの、6営業日連続で展示会に出ることになります。こちらでもZabbix連携デモを行う予定です。

■そのアラート、ちゃんと伝わっていますか？

Zabbixといえば監視、監視といえばアラート。システム異常をメールなどを通じたアラートで管理者に伝える監視ソリューションの機能は、システム運用には必須といえます。サーバーやネットワークの運用現場には、POLESTAR Automationのような運用自動化製品は未導入でも、監視だけは何らかの製品が最低限入っているのが普通かと思います。
しかし、管理者が張り付いている平日の日中はともかく、夜間や休日にアラートメールが送られてきても、気付かないことも多いのではないでしょうか。 夜中の就寝中でも伝わる確度の高いアラート手段、それが「電話」です。

弊社では「急コール(CueCall)」というクラウド型緊急連絡サービスを提供しています。夜間や休日など、メールだと埋もれてしまいかねない緊急連絡を、メールを合図(cue)に、つまり弊社のクラウドにメールが届くと自動的に指定の番号に電話をかけ(call)、対象者に確実に伝えられるという、最も確実な緊急連絡手段です。

単に「メールで電話をかける」だけでなく、大量に発生するアラートメールから重大性の高いものだけを自動的に選別し、本当に必要なケースでだけ電話を発信するという、メール解析による発信絞り込みの機能も備えています。
もともと大手通信キャリアさんの運用部門からの要望を受け、電話転送サービス「転送録」のノウハウを応用して単発で開発・納品したものをベースに商品化した急コールですが、最初の1年ほどはあまり売れませんでした。 しかし、なぜか昨年の後半あたりから、それまでの苦戦が嘘だったかのように突然売れ始めています。災害時の緊急連絡用として導入されたケースもありますが、やはりシステム運用関係のお客様が多いです。
Zabbixをはじめ、外部にメールの送信さえ可能なものなら、あらゆる監視・インシデント管理システムと組み合わせ、緊急対応担当者の電話を鳴らすことが可能です。システムのそばに電話機を置く必要はありません。緊急連絡が伝わらなくてお困りの方には、急コール(CueCall)をおすすめします。

実は春先に中国に行く予定があったのですが、予約していた飛行機が欠航になってしまいました。便数は縮小になったものの全面欠航ではないので、行こうと思えば行けないこともないのですが、日本の周囲だけでなく先方の中国側からも止められてしまったので、しばらく見送りになりそうです。
個人的にはこれまでも普段から手洗い、うがいを欠かさないようにしていたつもりですが、これまで以上に意識して徹底するのが、感染予防につながると思います。
いずれにせよ、一日も早く収束することを願っています。



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

映画「スター・ウォーズ」シリーズの新作が公開されましたね。今回はエピソード(EP)7～9 3部作の最終作ですが、個人的にはスター・ウォーズといえば旧作のEP4～6、中でもEP5こと「帝国の逆襲」がお気に入りだったりします。

2019年最後のPOLESTARコラムは、POLESTAR Automationを語るのに欠かせない「エージェント」をテーマに選んでみました。エージェントレスについては何回か取り上げましたが、エージェント側をメインにコラムを書くのは、実は初めてです。既に書いたような覚えがあるのですが、2016年10月オープンの当Webサイトで最古のコンテンツのひとつ、こちらを書いた記憶からかもしれません。

■「エージェントレス」対応後になぜか「エージェント可」の依頼が増えている件

代理人、代理店などの意味を持つ「エージェント」は、SF映画やテレビ番組にもよく登場しますね。どちらかといえば悪役・敵役として出てくることが多いです。映画「マトリックス」シリーズのエージェント・スミスが有名でしょうが、1970年代のテレビ特撮作品「超人バロム・1」には「悪のエージェント・ドルゲ」なんていうのがいたそうですね。
ネット動画で少し見ただけですが、タイトルにもなっているバロム・1も「正義のエージェント」と呼ばれているのに、「悪のエージェント」という肩書があまりにも語呂が良すぎて、なるほど日本で「エージェント」という言葉がネガティブイメージなのは、この辺が由来なのか！ と妙に納得してしまったほどです。

さて、POLESTAR Automation V3で実現された、サーバー管理のエージェントレス対応は、本当に多くのお客様から要望をいただいていたものです。管理対象サーバーにエージェントが必須だった前バージョンの時代、「エージェントレスができたら、また来てくださいね」 という案件があまりにも多かったので、V3完成以降、営業がそうしたお客様のところを順に回っているところなのですが、どういうわけか最近「エージェントありでも構いませんから」「むしろエージェントでお願いします」という案件が増えてきています。
まさに「帝国の逆襲」ならぬ「エージェントの逆襲」とでも呼びたくなるような現象です。

実は、今年後半に重要テーマとして取り組み、前回のコラムでもご紹介したクラウド運用案件も「エージェント可」案件でした。
パブリッククラウドのインスタンス上では、さまざまなエージェントが動いています。例えばAWSのEC2（サーバーインスタンス）でいうAMI（Amazonマシンイメージ）では、標準で入っているものやカスタムインストールできるものなど、いくつかのAWS謹製・公式エージェントが動いているのが普通です。
Amazon LinuxのSSM Agent、Windows用のEC2Launch/EC2Configといったエージェントは、AMIの種類に応じて基本で入っているものです。インスタンス監視サービスであるCloudWatchのエージェントは標準では入っていませんが、CloudWatchを使うには、インスタンスごとにエージェントのインストールが必須です。
AWSのユーザーさんの大半は、普段そんな公式エージェントの存在を意識することは少ないのかもしれませんが、AMIの仕様を調べていくと、実に多彩なサービス固有の公式エージェントが存在していることに気付きます。
何が言いたいのかというと、クラウドのインスタンス（サーバー）にエージェントが入っているのは普通なことで、オンプレミスよりクラウドを中心にやっているユーザーさんほど、エージェント導入に対する抵抗も薄い傾向があると感じています。
もちろん、クラウドサービス側が公式に提供し、半ば強制的に入ってくるエージェントと、POLESTAR Automationのように任意の判断で導入されるエージェントとでは、性格が異なるといえなくもないですが、OSに標準装備ではないという点では、本質的には同じといって構わないでしょう。

■いま、改めて問う「エージェント」のメリット

POLESTAR Automationをリリースした2016年時点で、すでにエージェントレス対応の運用自動化製品は複数存在していましたので、営業先で他社のエージェントレスと比べられてしまった場合には、なるべくエージェント方式の良い点を理解していただく努力を重ねてきました。
それがクラウド利用の拡大とともに、エージェントの存在と役割への理解が広がってきていると実感するようになり、少々意外にすら思っているのですが、一方で今なお、エージェントの導入に抵抗感を抱かれるお客様も少なくないようです。とりわけ、社内システムの運用管理ではなく、他のお客様の運用業務を受託しているようなケースでは顕著なようです。

日本国内の運用管理ソリューション分野において「エージェントレス」という表現が使われるようになったのは、監視（モニタリング）系ツールが最初だと思います。監視系におけるエージェントレスとは、SNMPやIPMI、WMIなど、監視対象OSにあらかじめ用意されている既存のシステム情報収集用インターフェースを用いてシステム監視を行うものをいいます。
実は、こうした監視用の標準インターフェースを提供するプログラムも「エージェント」と呼ばれ、例えば「SNMPエージェント」などは各OSに用意されているのですが、一般にはOSに標準で入っているプログラムは、「エージェント」の概念からは除外する、という定義になっているようです。
POLESTAR Automationのような運用自動化・構成管理ソリューションにおけるエージェントレスは、監視系のそれと比べると歴史が浅いですが、自動化は内部的には各OSごとのシェルコマンドの発行によって実現していますので、SSH、WMI、WinRMといったコマンド文字列の通せるインターフェースを利用します。
例えば、管理対象サーバーの構成情報の取得を行う場合、管理サーバーから管理対象サーバーに対してリモートでスクリプトを投入し、その結果を別のコマンドで取得しているのですが、この方法はリアルタイム性にはやや欠ける上、権限に阻まれてリモート実行が困難な作業（例: Windowsのレジストリ操作）などもあります。
何より、SSHは既知のプロトコルであり、標準のポート番号のままだと総当たり攻撃の対象になるので、特にグローバルIPでインターネットに露出するような環境では、セキュリティ上の懸念から使用を避ける傾向もあります。独自プロトコルを用いるエージェント方式の方がベター、という判断になることも多いです。
一方、管理対象サーバーにエージェントプログラムを常駐させるエージェント方式では、エージェントが管理対象サーバー側のroot/admin権限で動作していますので、ローカルサーバーと同水準の権限で作業が可能となり、直接ハードウェアにアクセスしてリモートコマンドでは集められない構成情報を集めてきたり、Windowsのレジストリを操作したり、ファイルの送受信が容易に実現できたりと、さまざまなメリットがあります。

以上、前述のページと内容が重複しているところもありますが、個人的には今でもエージェント推しですので、POLESTAR Automationエージェントレス元年でもある令和元年の年末に、改めてエージェントの良さを説明させていただきました。
もちろん、POLESTAR Automation V3ならエージェント、エージェントレスを適材適所で使い分けていただけます。以前にも一度触れましたが、現状POLESTAR Automationでエージェントを提供していないOSや仮想化ハイパーバイザーなどでは、エージェントレスが唯一の自動化手段となります。

■Zabbixエージェントのインストールからホスト登録まで自動で。Linuxでも、Windowsでも！

あと、エージェントつながりでもう1つ。POLESTAR Automation V3でエージェントレスとともに追加された新機能「API連携」ですが、現在は要望の特に多かった、監視ツールのZabbixとの連携を中心に、ユースケースの開発に取り組んでいます。
このZabbixもまた、SNMPやWMIなどを用いたエージェントレス監視に対応していますが、エージェントを用いることで、本来の機能をフルに発揮できます。しかし、すべての監視対象サーバーにエージェントをインストールするのは面倒ですし、Zabbixホスト（管理サーバー）からエージェントを認識できるようにするには、エージェントがインストールされている監視対象サーバー側でのファイアウォールの設定なども、適切に実施する必要があります。
そこでPOLESTAR Automationのような自動化ツールが活躍するわけですが、そのZabbixエージェントのサーバーへのインストールからZabbixホストへの登録までを自動的に行うデモは、前回のコラムでもご紹介した通り、10月のJapan IT Week 秋でも披露させていただきました。しかし、当時はLinuxでだけ可能でした。
それが年末もギリギリになって、早めに長めの冬休みに突入した若いエンジニアが、年内の最終出勤日になって、Windows用のZabbixエージェントインストールからファイアウォール設定、Zabbix側のホスト登録までの流れを自動化するジョブを完成させました。これでLinux・Windowsともに対応可能となりましたので、お知らせしておきます。
Zabbixエージェントの一斉展開・追加展開・削除の手間がなくなります。ご興味のある方は、ぜひともこちらのページからお問い合わせいただければと思います。

最後に、現在開発中の「関連性情報表示」をチラ見せしておきます。
サーバーやネットワークのトポロジーマップを瞬間的に自動作成し、表示する機能です。前バージョンにもあった機能ですが、V3でも年明けに復活することになりました。

以上、今年1年もPOLESTAR Automation Webサイトをご覧いただき、ありがとうございました。
どうか来年もよろしくお願いします。



ワイドテックのYです。

気が付いたら、前回のコラムから2か月も経っていました。その間にやっていたことは、POLESTAR Automation V3のリリースに向けてのさまざまな作業、10月に開催されたJapan IT Week秋（幕張メッセ）の準備、そして、とあるお客様のチャレンジングな案件対応でした。
いずれも一息付きましたので、久々に1本書かせていただきます。

■大好評！ Japan IT Week 秋の「Zabbix連携」

10月23日から3日間、幕張メッセで開催された「Japan IT Week 2019 秋」。この秋の幕張でのイベントへの出展は3年連続3回目、今年は3日目の午前中に開催地の千葉県が記録的な豪雨に見舞われるなど天候の影響があったにもかかわらず、弊社ブースにご来場いただいたお客様の数は、おかげさまで過去最高を更新しました。
今回は9月に正式リリースさせていただいたPOLESTAR Automation V3の初の製品版出展ということもあり、エージェントレス対応と並ぶV3の新機能「API連携」、それもお客様から最も多くの要望を頂戴していた「Zabbix」との連携デモを、大々的にフィーチャーしました。
ブース内で一番目立つ場所で臨んだZabbixデモコーナーで実施していたのは、以下のようなデモでした。

• 管理対象サーバー(Linux)で故意にCPU負荷を発生させ、Zabbixが検出した負荷アラートを受けてPOLESTAR Automationのジョブで管理対象サーバーを再起動
• 管理対象サーバー(Linux)で故意にCPU負荷を発生させ、Zabbixが検出した負荷アラートを受けてPOLESTAR Automationのジョブで上位10個の高負荷プロセスを検出
• 管理対象サーバー(Linux, Windows)でZabbixエージェントが停止した場合、POLESTAR AutomationのジョブによりZabbix Agentを再起動
• 管理対象サーバー(Linux, Windows)へのZabbixエージェントの自動インストールとZabbixへのホスト登録（これだけはAPI連携は使用していません）

POLESTAR AutomationにAPI連携の実装が決まった頃からの念願だった、ZabbixとPOLESTAR Automationとの連携デモを初めて披露することができ、関係者一同、感慨ひとしおでした。
おそらく国内のシステム運用現場で監視（モニタリング）ツールとして最も使われているもののひとつであろう、Zabbixとの連携デモということで、デモコーナーは予想を上回る盛況となりました。Zabbixコーナーだけでは間に合わず、他のデモ機もZabbixのデモに回していたほどです。
負荷関連のデモでは、今回もまたRaspberry Piが活躍しました。下の写真でデモ用のノートPCの右横に置いてあるのが、ラズパイ（実はYの私物。最近新型の発売待ちのせいか品薄で、会社での購入を諦めました）と7インチディスプレイ（こちらは会社で購入したもの）です。ディスプレイを用意したのは、再起動デモのためです。

■クラウド運用自動化への挑戦

会場のラズパイやデモ用ノートPCは、当然、現地で借りたインターネット回線に、ルーターを介して接続されていました。
デモ用ノートPCで開いていたのはPOLESTAR Automationの管理サーバーでしたが、管理サーバーそのものは会場内ではなく、別の場所にありました。デモのために用意した臨時のZabbixサーバーはAWSに置いてあり、ラズパイ以外の管理対象サーバー（Zabbix用語ではZabbixホスト）も多くはAWSに置いていたのですが、1台だけは管理サーバーと同じ場所にありました。
つまりAWS、管理サーバーと管理対象サーバー1台、会場内のラズパイはそれぞれ別々のネットワーク上に存在していたわけですが、これらをVPNを介し、論理的に同一のLAN上で疎通させていました。 こうしたネットワーク的な構築はすべて自分ことYがやったのですが（Zabbixのデモ構築は別のエンジニアが担当しました）、以前ご紹介したように、趣味と実益を兼ねていろいろな種類のVPNを触った経験が、今回ちょっとだけ役に立ったのかな、と思います。

そんなわけで、今回はクラウド(AWS)とVPNのおかげで実現できたデモでもあったのですが、実は展示会に前後して「POLESTAR AutomationをAWSの管理に使いたい」という、弊社にとっても開発元にとっても初めての、とてもチャレンジングな案件が持ち込まれています。
展示会終了後からはその検証を行っていて、実は現在進行形でもあるのですが、今回の検証のために、それまで存在しか知らなかった「AWS CLI（コマンドライン・インターフェース）」なるものを、初めて実際に触ることになってしまいました。
AWSのインスタンスを立てたり、インスタンスタイプを変更したり、スケーリングしたり…という、これまでAWSのWebUIである「マネージメントコンソール」からしかできないと思っていた作業がコマンドラインからほぼ全部可能という、その柔軟性の高さに驚いているところであります。
AWSのCLIに感動してしまうなんて、「マウスひとつで日常の運用をこなせるGUI」がセールスポイントのPOLESTAR Automationのコンセプトとは、いささか矛盾した話のように聞こえてしまいそうですが、POLESTAR AutomationのGUIによるお手軽運用は、内部的にはコマンドラインのスクリプトである「ジョブ」によって実現されています。つまり、POLESTAR AutomationからはCLIで操作できることが前提です。
AWS CLIとPOLESTAR Automationを組み合わせることで、インスタンスの作成・起動からアプリケーションなどのデプロイ、その後運用フェーズに移行してからの管理までを、単一の業務フローとして自動化を図ることが可能となります。
日常の運用業務からAWSのようなクラウドインフラの操作まで、POLESTAR Automationという1種類のWebUI上で一気通貫で実現すること、それが「マウスひとつで日常の運用をこなせる」コンセプトなのです。

■おまけ: MacでPOLESTAR

ところで今回、POLESTAR Automation V3の管理用WebUIは、従来版のFlex（Adobe Flashに依存）から、HTML5ベースへと全面刷新されています。
実はPOLESTARチームとは別の全く関係ない仕事で、最近ちょくちょくMacを触る機会があるので、興味本位でApple謹製・macOS標準Webブラウザの「Safari」で、恐る恐るPOLESTAR Automation V3の画面を開いてみました。

現行最新版のmacOSである10.15 Catalinaでは、32ビットアプリケーションのサポートが廃止されたので、そもそもSafariで32ビットアプリであるFlashのWebページは見られませんでした。V3はCatalinaのSafariでも見られたので、ちょっと安心しているところです。
そういえば、macOSは公式UNIXでもありますよね。これまでmacOS用のエージェントは用意していませんでしたし今後も予定はありませんが、エージェントレスなら管理対象にできるかもしれませんね。いずれ試してみたいと思います（ただし、正式サポートするかどうかは、また別の話です）。

■株式会社ワイドテックはZabbix認定パートナーです

認定パートナーとは、Zabbixが提供しているサービスや製品を提供ないし、技術サポートを行えることができるパートナーとして認定する、Zabbix社の公式パートナープログラムです。

Zabbixをはじめとしたツールとの連携で障害対応を効率化する方法については、こちらもぜひご覧ください。「Zabbixなどの監視ツールやインシデント管理ツールと連携し、障害対応を効率化」



ワイドテックのYです。

小学5年生の息子がいるのですが、ここ数年、夏休みになるたびに頭を悩ましていたのが「自由研究」。何をやったらよいのかなかなか思い当たらず、結局、お盆休みを過ぎた頃からあわててテーマを決め、取り掛かるのが通例でした。

■自由研究のネタに「らずぱい」

それが、今年はお盆の前に「Raspberry Pi（以下ラズパイ）を触ってみたい」と、息子の方から言い出してきたのです。
自宅では室温に応じてエアコンを自動的にオン・オフしたり、外からエアコンの電源を入れたりと、ちょっとしたホームオートメーションを実験しているのですが、その仕組みを知りたいという興味がきっかけのようでした。
このホームオートメーション実験、実はラズパイではなく、別の製品を組み合わせてやっているのですが、ラズパイを使うといろいろなものが作れる、というのは自分が常日頃息子に言い聞かせていたことなので、興味を持っていたようでした。
と、いうわけで、とりあえず数百m先の近所に住んでいる義母（息子にとってはおばあちゃん）宅で飼っていて、息子自身も普段から面倒を見ている猫（1歳、オス）の様子を、自宅にいる時でも両親のスマホやノートPCから観察できるようにと、しばらく使われず遊んでいたRaspberry Pi 3Bと某大手ネット通販で急遽注文した純正カメラモジュールを用意し、ライブカメラの作り方を教えることにしました。

■V3がエージェントレスになって、よかったこと

息子がラズパイで猫観察用ライブカメラを組み上げ、義母宅のWi-Fiにつなげようと試行錯誤していたその頃、父親は会社で、最終段階まで進んだPOLESTAR Automation V3の開発状況の確認やテストを進めていたところでした。
その過程でV3の新機能、「サーバーのエージェントレス管理」を従来のエージェント管理と比較しながら、いろいろなデバイスをエージェントレスでV3の管理サーバーに接続してみるテストも行っていました。
POLESTAR Automation V3のエージェントレスは、SSHやSNMP、WMIなどの汎用プロトコルを利用しています。SSHがあれば行けそうということで、実はWindowsでもLinuxでも3大商用UNIXでもない某フリーなOSだとか、社内でも検証用に大活躍しているあの仮想化ハイパーバイザーなんかでもテストしてみたのですが、Linuxで可能なシステム情報の収集などはできないものの、コマンドやスクリプトを走らせたり、VMイメージをロードしたりすることはできました。
いずれも大変恐縮ながらサポート外にはなってしまいますが、入り口(SSH)さえあれば、V3では大体のものはつなげられそうです。
エージェントなしでデバイスを登録可能になったことで、Intelアーキテクチャ以外のCPU(SoC)で動いている管理対象サーバー、特に64ビットArmアーキテクチャのSoCとOSを搭載しているシングルボードコンピューター(SBC)で使えるのは、SBC好きの自分にとっては嬉しくて仕方ない話です。

ラズパイのSoCもRaspberry Pi 3以降、実は64ビット化されているのですが、実質的な公式OSであるRaspbianは、過去のラズパイとの互換性上の理由もあってか、32ビットのままです。これまでPOLESTAR Automationでは、この32ビットのRaspbianに対応したエージェントを用意しており、V3でも引き続き使えますが、64ビットで動くものはありませんでした。
V3でエージェントレスが入ったことで、ラズパイはもちろん、Arm64対応OSを搭載する他のSBC、あとまだ確認していませんが、ArmやIntel以外のSoC(CPU)を搭載するデバイスであっても、Linuxであれば個別のエージェントを開発することなく、対応可能となったわけです。

■エージェントレスで拡がる可能性。そしてIoTへ

実は社内でもオーソライズされていない個人の思い付き話を、今ここで初めて書くのですが、エージェントレスになったV3は、普通のサーバーやルーター、ネットワークスイッチなどの運用だけでなく、IoTでも生きてくるのではないかな、などと考えています。
IoTデバイスからのセンサーやカメラといったデータの定期的な取得、逆に設定・制御情報などのIoTデバイスへのデプロイ、そして今回V3で新たに搭載したREST APIを使ったコマンドの受け渡しなど、IoTデバイスの管理に関連する作業全般がV3を使って自動化できそうです。
IoTに参入している企業、IoTで旗揚げするベンチャーやスタートアップは非常に多いのですが、トライアルやスモールスタートのところが少なくなく、専用にハードウェアを開発するところまで、なかなか至らないケースが多いようです。「IoTは永遠のPoC」などと言われたりもします。
カット＆トライの多い試作・PoC段階から本格運用まで、POLESTAR Automation V3のエージェントレスと軽快で扱いやすい新GUIは、IoTでもきっと幅広くお役に立てると思います。
もしこの駄文を読んでV3のIoTへの応用に興味をお持ちいただいた方は、弊社までご連絡ください。ぜひともPoCなどをご一緒させていただければと思います。

ところで、弊社のIoTプロダクトといえば、昨秋のJapan IT Week 秋の弊社ブースで、IoTデバイス管理ソリューション「AIOTION（アイオーシャン）」を参考出品として初披露させていただきました。
このAIOTION、かなり気合を入れて開発を進めている関係で、もともとの予定よりもリリースが遅れてしまっています。近いうちにご紹介できると思いますが、POLESTAR Automation V3は自動化ソリューション、AIOTIONはIoTデバイスのモニタリングを中心としたソリューションとなりますので、目的や機能は異なります。

そのJapan IT Week 秋、今年も10月23日（水）～25日（金）に幕張メッセで開催されます。
詳しくは後日改めてご案内しますが、V3発売から最初の展示会となる今回は、ブースのサイズをこれまでの2倍に拡大しての出展となります。乞うご期待！



ワイドテックのYです。

POLESTAR Automationの良さを知っていただくには、まずは実際に触っていただくことから、と考え、以前から展示会への出展（3年連続年3回）、弊社セミナールームでの定期ハンズオンセミナー、昨年末から今春にかけてはクラウド版PoC環境や評価版の提供など、あの手この手でPOLESTAR Automationに実際に触れていただくための手段を提供してきました。
今回は、そんな取り組みの一環として新たに加わった、仮想マシンファイルのダウンロードとインポートだけでインストールが完了する「仮想アプライアンス(VA)」によるPOLESTAR Automation評価版誕生までのお話です。

■評価版がダウンロードされない…なぜだ！

この3月にリリースしたPOLESTAR Automationの評価版、正直な話をすると、期待されたほどダウンロードされていません。これまで原因をいろいろ追求してきましたが、「インストール対象となるハードウェアの要求条件が厳しい」「インストールに手間が掛かる」というのが一番の理由ではないか？ という推測に至りました。
そこで、6月に入ってVPS（root権限の提供されるレンタルサーバー）へのインストール手順紹介や、動作条件の緩和などを矢継ぎ早に打ち出してきたのですが、それでもインストール件数は微増止まりです。
VPSを使えば、ハードウェアを別途用意することなく、月数百円で利用できるVPS上にPOLESTAR Automationをインストールしていただくことが可能です。しかし、インストール場所は容易に確保できても、点検テンプレートやサンプルジョブなど、プログラム本体のインストール後にインポートしなければならないファイルがあります。従来の評価版では、その作業に結構な手間を要していました。本体のインストールを上回る時間が必要だったかもしれません。
もっと簡単・気軽に、極限までインストール手順を簡素化できる手段はないか？ と検討を重ねた結果、たどり着いたのが「仮想アプライアンス(Virtual Appliance)」でした。

■仮想アプライアンスとは？

「アプライアンス(appliance)」とは、英語では通常「家電製品」（主に冷蔵庫・洗濯機などの白物家電）を意味するhome applianceの略語として使われますが、ITの世界ではロードバランサー（負荷分散装置）、セキュリティ用途のファイアウォール、エンドポイントセキュリティ、IPS（侵入防止システム）、UTM（統合脅威管理）といった特定用途向けの機器を指します。「家電製品のごとく」スイッチオンですぐに動き出し、インストールなどの事前作業が最小限で済むことが由来でしょう。
実はこれらのアプライアンスの中身は、CPUとメモリやストレージ、ネットワークインターフェースなどを搭載したサーバー、またはPCそのものといえます。そして、先に挙げたアプライアンスの数々は、WindowsやLinuxなどのOS上でアプリケーションとしても提供されているものばかりです。
つまり、特定用途のアプリケーションが最初から組み込まれているコンピュータ機器、それがアプライアンスなのです。中にはファームウェアのカスタマイズが最小限で、ストレージを初期化してOSを入れ替えれば、サーバーとして使えてしまうようなものも存在します（もったいない話ですが）。
実は昨年、とあるセキュリティ向けアプライアンス製品の商品化検討を行ったことがありましたが、正にそういうハードウェアの上に構築された製品でした。

この「スイッチオンですぐ動き出す」ITハードウェアとしてのアプライアンスの思想を、仮想化環境に展開する形でソフトウェアの世界に引き戻したのが「仮想アプライアンス」です。
仮想アプライアンスは10数年前から存在していましたが、盛んになったのはここ数年、仮想マシンやパブリッククラウドなどの普及につれてのことでしょう。

■仮想アプライアンスができるまで

POLESTAR Automation評価版の仮想アプライアンスは、VMwareやVirtualBoxなどで利用できるOVF形式と、Windows ServerやWindows 10の上位バージョンで提供されるHyper-V(VHDX)形式の2種類を提供します。
仮想マシンの作成は、VMwareのESXi上で行いました。細かい作業はいろいろありますが、ざっくり言えばESXiにLinux(CentOS 7)の仮想マシンを構築し、そこに通常のやり方でPOLESTAR Automation評価版一式（点検・ジョブテンプレート一切を含む）をインストールしただけです。
OVFやHyper-Vのインポート手順については、一般的な方法で可能ですので、ここでの説明は割愛させていただきますが、ともかく仮想マシンとしてインポートして起動するだけで動き出しますので、インストール作業は本当に数分で終わってしまいます。
むしろ、仮想マシン（2形式とも各4GB程度）をダウンロードしたり、インポートしたりする時間の方がかかるかもしれません。このファイルサイズの大きさが、強いて言えば仮想アプライアンス方式の唯一の欠点といえるでしょうか。

今後は評価版に限らず、PoC版や製品版のPOLESTAR Automationも、オンプレミス向けの通常のインストール形式に加え、仮想アプライアンス方式でも提供します。
実は、過去に行われたPOLESTAR Automationの納品でも、作業時間が限られていて、期限ギリギリでなんとか終えられたような、冷や冷やものの案件がいくつかあったのですが、そのいくつかは今回の仮想アプライアンス構築手順の応用により、時間短縮が可能だったものでした。

■評価版仮想アプライアンス、今日から使えます！

POLESTAR Automation 評価版の仮想アプライアンスは、このコラムが掲載されるタイミングで提供を開始します。 とりあえずVMware Workstation PlayerやOracle VM VirtualBoxなどのOVF対応仮想化環境か、Windows 10 Proなどに標準搭載（要有効化）のHyper-Vがあれば、ダウンロード・インポートしてお使いいただけます。

さて、ITの世界での最新トレンドは、DockerやKubernetes(K8s)を筆頭とする「コンテナ化」です。コンテナ化技術は、運用のあり方そのものを変える可能性があると思います。
弊社でも、仮想化やクラウド、そしてコンテナ化といった新しい運用環境へのPOLESTAR Automationの対応を進めるべく取り組んでいるところです。手前味噌ですが、今回の仮想アプライアンス提供も、そうした試みから生まれた成果物のひとつでもあります。
仮想化やクラウド関連への取り組みは、POLESTARチームや社内にさまざまなノウハウを蓄積するのにも、非常に役に立っています。一部は開発元のNkia社にもフィードバックしています。

いずれコンテナ化関連で新しいネタをと考えていますが、いつになるかはわかりません。また改めて。
まずは、仮想アプライアンス化でインストールが簡単になったPOLESTAR Automation評価版、ぜひともこの機会にお試しいただければ幸いです。



ワイドテックのYです。

「この」VPSシリーズも今回で第3弾、一応これが最終回のつもりです。
前回でVPSにPOLESTAR Automationをインストールし、使える状態になっていると思いますので、今回はPOLESTAR Automationを運用自動化ツールとして使うためのサンプルジョブや点検グループのインストール方法をご紹介します。

■サンプルジョブをダウンロードしよう

商用版のPOLESTAR Automationでは、フル構成で200種類を超えるジョブ・点検テンプレートを提供しているのですが、評価版での提供はごく一部となり、しかもお手数ながら、お客様ご自身で個別にダウンロード・導入（インポート）していただく必要があります。
サンプルジョブのダウンロード先URLは、評価版のダウンロード申し込みとともに自動送信されたメールに記載されており、こちらは何度でもアクセスしてダウンロードが可能となっております。

このページからは、Windows用、Linux用に各14種類、計28種類のジョブと点検テンプレート（これらを総称して弊社では「サンプルジョブ」と呼んでいます）を提供しています。

■Linux用ジョブ

1. 点検ジョブ
NO	ジョブ名	説明
1	NTP時刻ずれチェック	NTPサーバーと対象サーバーの時刻がずれている場合、実行中のサービスに影響を与える可能性があるため、時刻ずれの点検により障害予防を図る
2	Bashリモート任意コードの実行点検	BashShellの環境変数処理における脆弱性の有無を確認。脆弱性が放置されている場合、システムセキュリティを迂回してのShellコマンド実行による攻撃を受ける可能性がある
3	OpenSSL HeartBleed点検	暗号化通信に多く使われるOpenSSLライブラリにおいて、サーバーに保存された重要メモリデータが漏えいするHeartBleedという深刻なバグが発生したため、システム及びSWに対する迅速な脆弱性対策を実行することを推奨
2. 変更監査ジョブ
NO	ジョブ名	説明
1	ルーティング情報の変更確認	サーバーの再起動やOSパッチ作業を行う際、設定されたルーティング情報が変更された場合は実行中のサービスに影響を与える可能性があるため、作業前·後のデータの変化を監査し、障害予防を図る
2	DNS情報の変更確認	サーバーの再起動やOSパッチ作業を行う際、設定されたDNS情報が変更された場合は実行中のサービスに影響を与える可能性があるため、作業前·後のデータの変化を監査し、障害予防を図る
3	OSファイアウォールの設定変更確認	サーバーの再起動やOSパッチ作業を行う際、設定されたOSファイアウォール情報が変更された場合は実行中のサービスに影響を与える可能性があるため、作業前·後のデータの変化を監査し、障害予防を図る
3. スクリプトジョブ
NO	ジョブ名	説明
1	Javaのバージョン確認	サーバーにインストールされて実行されているJavaバージョン確認
2	Linuxアカウント生成、パスワード変更	新規に導入されるサーバー、または既存のサーバーに新規のアカウントを追加する作業 / 既存サーバーに登録された一般アカウントに対するパスワードの変更作業
3	SW情報収集：Package、Application	RPM形式のパッケージからインストールされたソフトウェアの情報確認
4	ens192の詳細表示	ens192のデバイス関連情報を確認
5	パッケージ情報表示	インストールしたパッケージ情報を表示
6	HDD使用率取得	HDDの使用率を取得
7	ネットワークインターフェースの一覧表示	ネットワークデバイスの種類、状態などを確認
8	USBデバイス情報の取得	接続されているUSBデバイスの情報を取得

■Windows用ジョブ

1. 点検ジョブ
NO	ジョブ名	説明
1	NTP時刻ずれチェック	NTPサーバーと対象サーバーの時刻がずれている場合、実行中のサービスに影響を与える可能性があるため、時刻ずれの点検により障害予防を図る
2. 変更監査ジョブ
NO	ジョブ名	説明
1	ルーティング情報の変更確認	サーバーの再起動やOSパッチ作業を行う際、設定されたルーティング情報が変更された場合に実行中のサービスに影響を与える可能性があるため、作業前·後のデータの変化を監査し、障害予防を図る
2	DNS情報の変更確認	サーバーの再起動やOSパッチ作業を行う際、設定されたDNS情報が変更された場合に実行中のサービスに影響を与える可能性があるため、作業前·後のデータの変化を監査し、障害予防を図る
3	OSファイアウォールの設定変更確認	サーバーの再起動やOSパッチ作業を行う際、設定されたOSファイアウォール情報が変更された場合にはサービスに影響を与える可能性があるため、作業前·後のデータの変化を監査し、障害予防を図る
3. スクリプトジョブ
NO	ジョブ名	説明
1	Windows HotFix情報収集	Windowsサーバーを対象にHotFix情報を収集し、Microsoftの推奨するアップデートが実施されたかどうかを確認
2	Javaのバージョン確認	対象サーバーで現在実行中のJavaバージョンの確認
3	SW情報収集：Package、Application	EXE形式のインストーラでインストールされたソフトウェアの情報確認
4	最新10件のアプリケーションログの取得	起動したアプリケーションの最新10件のログ情報を取得
5	「受信の規則」取得 (ファイアウォール)	Windowsファイアウォールの「受信の規則」を取得
6	「送信の規則」取得 (ファイアウォール)	Windowsファイアウォールの「送信の規則」を取得
7	HDD情報、使用率取得	HDDの情報、使用率を取得
8	ドメイン情報取得	ドメインの情報を取得
9	電源オプション状態確認	電源オプション(バランス/高パフォーマンス/省電力)状態を確認
10	SNMP状態確認	SNMPがある場合、状態の確認が可能

■ジョブのインポート手順

各ジョブはXMLファイルになっていて、クライアント側に展開したXMLをブラウザからインポートすることになります。
実は、ジョブごとにインポートの方法がそれぞれ異なるので、個別にインポート手順を記したマニュアルを添付させていただいています。ちょっと煩雑で、お手数をおかけすることになります。
一例として、XMLが3個入っていてそれぞれインポート先が異なるという「OpenSSL HeartBleed点検」のインポート手順をご紹介しておきます。

1. ダウンロードした「OpenSSL HeartBleed点検（Linux用）」のアーカイブファイルを、クライアントPC上の任意のフォルダーに展開します。
（実はインポート方法は、展開先に作成されるPDF版マニュアルの中に全部書いてあります）

2. まず「〔構成リスト〕 OpenSSL HeartBleed点検.xml」からインポートします。
POLESTAR Automationの管理サーバーにログインし、「構成」-「構成リスト」を選択します。

3. 次に「マイ コンピュータ」をクリックします。クライアントPC側（ここではWindows）のファイル選択ダイアログが開きますので、「〔構成リスト〕OpenSSL HeartBleed 点検.xml」を選択し、「開く(O)」をクリックします。

4. 「ファイル」欄に目的のファイル名があることを確認し「インポート分析」をクリックします。

5. チェックボックスにチェックを付けて「インポート」をクリックします。

6. 「成功」を確認した後、「閉じる」をクリックします。

7. 「更新」をクリックします。

8. ジョブが追加されたことを確認後、ダブルクリックします。

9. 「スクリプト種類」が「Shell」、「OS」が「Unix/Linux」であることを確認し、「保存」をクリックします。

10. 次に「〔点検グループ〕脆弱性点検_HeartBleed 点検.xml」をインポートします。「ダッシュボード」-「構成の状況」を選択します。

11. 「構成の状況」タブが開いたら、中にある「点検グループ」タブの「インポート」をクリックします。

11. 「構成の状況」タブが開いたら、中にある「点検グループ」タブの「インポート」をクリックします。

12. 「マイコンピュータ」をクリックしてクライアントPC側のファイル選択ダイアログが開いたら「〔点検グループ〕脆弱性点検_HeartBleed 点検.xml」を選択して「開く(O)」をクリックします。

13. ファイル名を確認して「インポート」をクリックします。

14. 確認のダイアログが開いたら「確認」をクリックします。

15. ジョブが追加されたことを確認します。

16. ワークスペース（管理UI左側）の「点検グループ」をクリックして「点検グループ」のツリーが開いたら「All」をクリックし、「脆弱性点検_HeartBleed 点検」がインポートされたことを確認します。

17. 最後に「〔点検ジョブ〕脆弱性点検_HeartBleed 点検.xml」のインポートを行います。

「ダッシュボード」-「構成の状況」を選択します。

18. 「マイコンピュータ」をクリックしてクライアントPC側のファイル選択ダイアログが開いたら「〔点検ジョブ〕脆弱性点検_HeartBleed 点検.xml」を選択して「開く(O)」をクリックします。

19. ファイル名を確認して「インポート」をクリックします。

20. 確認のダイアログが開いたら「確認」をクリックします。

21. ジョブが追加されたことを確認します。

22. ワークスペースの「ジョブ」をクリックして「ジョブ」のツリーが開いたら「All」をクリックし、「脆弱性点検_HeartBleed 点検」がインポートされたことを確認します。

以上でLinux用「OpenSSL HeartBleed 点検」のインポートは終了です。ふぅ。

■ジョブの確認

では、インポートした「OpenSSL HeartBleed 点検」ジョブが動作するかどうか、確認してみましょう。
1. ワークスペースが「ジョブ」担っている状態から「All」をクリックし、インポートした「脆弱性点検_HeartBleed 点検」ジョブをダブルクリックします。

2. 中にある「基本情報」タブの下にある「基本情報」をクリックし、「OS」欄が「Unix/Linux」になっていることを確認します。

3. 「基本情報」-「点検グループ選択」をクリックして点検グループを指定します。

4. 「基本情報」-「対象選択」をクリックし、ジョブを実行する対象のサーバーを選択します。ここでは「Unix/Linux」をツリーから「グループ/デバイス」にドラッグ＆ドロップしてみましょう。
「Unix/Linux」がスマートグループ（解説はいずれ。または評価版ダウンロードページからダウンロードできるユーザーマニュアルをご覧ください）が追加され、現在POLESTAR Automation管理サーバーに登録されているすべてのLinux（およびUNIX）サーバーが対象となります。

5. もし個別に対象サーバーを登録する場合は、以下のようにツリーから個別のサーバーを選択してドラッグ＆ドロップします。

6. スケジュールを登録するには、「基本情報」タブの下の「スケジュール」タブから「追加」をクリックします。

7. スケジュールが「1回」「毎日」「毎週」「毎月」「繰り返し（指定した間隔で繰り返します）」から選べます。触ってみれば直感的にわかっていただけるかと思います。設定したら「保存」をクリックします。
ここでは毎日6時00分というスケジュールを入れてみます。

8. 登録したスケジュールを確認します。

9. 設定が終わったら「保存」をクリックします。

以上で、スケジュール機能を使った「OpenSSL HeartBleed点検」ジョブ（Linux用）の実行予約ができました。

■ジョブの実行

実は、先の画面の「保存」の隣にも「実行」ボタンがあり、スケジュールを登録しなくても、そこから直ちにジョブを実行することができます。
POLESTAR Automationのジョブには2種類の実行方法があります。どちらから実行しても結果は変わりませんので、便利な方をお使いください。

1. ワークスペースからの実行。各ジョブのコンテキストメニューから「実行」を選ぶと、ジョブの実行が開始されます。

2. 個別のジョブタブからも実行できます。ワークスペースからジョブをダブルクリックしてタブを開き、その右上端にある「実行」をクリックします。

■ジョブの結果確認

ジョブの実行結果を確認する手順です。

1. 管理サーバーUI下部の「実行ジョブ」で、実行したジョブをダブルクリックします。

2. 開いたタブで「ジョブ履歴」をクリックすると、結果が確認できます。

「OpenSSL HeartBleed点検」の場合、結果欄の「遵守」とか「違反」は、
遵守 : 脆弱性のあるOpenSSLバージョンが使用されていない
違反 : 脆弱性のあるOpenSSLバージョンが使用されている
という意味になります。

3. 「名称」欄にあるホスト名をダブルクリックすると、詳細が確認できます。

■ちょっと便利な使い方

POLESTAR Automationには構成情報の取得やジョブの実行以外にも、たくさんの機能があります。
例えば、手持ちのスクリプトを「スクリプトジョブ」として登録し、複数の管理対象サーバー上で同時に走らせることも可能です。
詳しくはユーザーマニュアルをご覧いただければ、と思いますが、せっかくなのでひとつだけ、POLESTAR Automationならではの機能を紹介しておきたいと思います。
「入力コマンド実行」というもので、例えば管理中のサーバーのメモリ利用状況、ストレージの空きといた情報を今すぐ知りたい時や、シェルのコマンドや短いスクリプトを走らせたい時など、わざわざ個別にコンソールを開かなくても、POLESTAR Automationから1回の実行で済みます。
まずはPOLESTAR Automation管理サーバーのUIから「運用」-「入力コマンド実行」を選択します。

「入力コマンド実行」のタブが開きます。今回はメモリの使用状況を調べるためのfreeコマンドを、6個のLinuxサーバー（すべてVPSです）に対して実行してみました。

1. ワークスペースから「Linux」をドラッグ
2. 「対象サーバ」領域にドロップ
3. 「コマンド実行」欄に「free」と入力して右端の「実行」をクリック
4. 下に「free」というタブが作成され、各サーバーで実行された結果が表示される

4. 下に「free」というタブが作成され、各サーバーで実行された結果が表示される
以上のような手順で、各サーバーの現在のメモリとSwap領域の状態が、1回の操作で調べられます。
こんな風に、日常的なサーバー管理のツールとしても便利にお使いいただけるかと思います。

今回はここまでです。
VPSへの導入をテーマとした連載企画はこれで最後になりますが、評価版の活用方法については、今後も随時情報発信して行ければと考えています。
最後に、執筆にあたってさまざまなインスピレーションとモチベーションを与えてくれた「美雲このは」さんに感謝しつつ、この連載を締めくくります。



ワイドテックのYです。

前回に引き続き「この」VPSシリーズの第2弾。実際にVPSにPOLESTAR Automationをインストールする手順をご紹介します。

■まずは管理サーバーの準備から

POLESTAR Automationの本体と呼べるのが管理サーバー(Manager Server)です。VPSを確保し、管理サーバーをインストールしてみましょう。

1. VPSの用意ができていることを前提とします。プラン選択から初期設定、SSHでコンソールを開けるようになるまでの一連の手順は省きますが、「この」VPSはコントロールパネルが非常にわかりやすいですね。ちなみにOSはいろいろなLinux/BSDディストリビューションから選べますが、迷ったらこれ、ということでCentOSにしました。

2. まずはダウンロードの申し込みからです。 最低限必要なのは、お名前とメールアドレス（確認のために２度入力）、そして評価版使用許諾と個人情報保護条件への同意だけですが、企業の方は企業名なども書いていただけると嬉しいです。

3. 数秒後、ダウンロード用URL（3回までアクセス可能）の記載されたメールが、先の申し込み画面で入力したメールアドレス宛に自動送信されます。クライアントPCでブラウザから開き、Linux用POLESTAR Automation評価版一式をダウンロードしましょう。

• POLESTAR Server software for Linux
• POLESTAR インストールガイド(Linux)
• POLESTAR Agent software for Linux
• POLESTAR Agentインストールガイド(Linux)

Windows系のサーバーも管理対象とする場合は、Windows版のエージェントもダウンロードしておきます。

• POLESTAR Agent software for Windows
• POLESTAR Agent インストールガイド(Windows)

4. ダウンロードしたLinux用評価版のtar.gzファイルを展開します。展開するとPolestarEvaliation_Linuxというディレクトリ（フォルダー）が作成され、その中にプログラム本体のアーカイブであるpolestar_evaluation.tar.gzとマニュアル、そしてライセンスキーのテキストファイルが格納されています。
※今回の作業はWindowsクライアント上から行っていますが、もちろんデスクトップLinuxや他の環境から実施しても構いません。

5. VPSにSSHクライアントでroot権限でログインし、polestar_evaluation.tar.gzをrootディレクトリに転送します。WindowsでTera Termをお使いの方は、ドラッグ＆ドロップでSCPを使うと便利でしょう。

6. 転送したpolestar_evaluation.tar.gzをそのままrootディレクトリ上で展開します。
# tar -xzvf polestar_evaluation.tar.gz
展開すると、ディレクトリpolestarが作成されます。
※展開後、polestar_evaluation.tar.gzは削除していただいても構いません

7. このtar.gzには、POLESTAR Automationのプログラム以外に、実はMariaDB（とOpenJDK）も同梱されています。 まずMariaDB関連の作業を行います。

# useradd mysql
# cd polestar
# chown -R mysql mariadb-10.3.12-linux-x86_64
# chgrp -R mysql mariadb-10.3.12-linux-x86_64
# su mysql
# cd mariadb-10.3.12-linux-x86_64/bin
# ./mysqld_safe --defaults-file=/polestar/mariadb-10.3.12-linux-x86_64/my.cnf
# su root

8. 次にファイアウォールの設定です。必要なポートの開放を行います。
開放するのはいずれもTCPポートで、80（Web UI用）、3306（MariaDB用）、22002、22003、22005（以上POLESTAR Automation独自機能で使用）の5つです。
ここではCentOS 7の標準であるfirewalldでの手順をご紹介していますが、iptablesの方に慣れ親しんでいるという方、UbuntuでUFWを使われる方などは適宜読み替えてください（手抜きですみません）。

# firewall-cmd --add-port=80/tcp --zone=public --permanent
# firewall-cmd --add-port=3306/tcp --zone=public --permanent
# firewall-cmd --add-port=22002/tcp --zone=public --permanent
# firewall-cmd --add-port=22003/tcp --zone=public --permanent
# firewall-cmd --add-port=22005/tcp --zone=public --permanent
# firewall-cmd --reload

9. ここまでで、POLESTAR Automationが起動できる状態となりました。

# cd /polestar/polestar_automation/bin
# ./manager.sh -start

最初の起動時にはDBの構築など一通りの初期設定を行うので、結構時間がかかります。

# ./manager.sh -status

を実行してみて、

Manager is running.

と出れば、POLESTAR Automationの起動が完了し、実行中の状態です。

10. ブラウザでVPSのIPアドレスを開いてみましょう。 デフォルトでは80番ポートにアサインされていますので、そのままIPアドレスを叩けばログイン画面が開くはずです。 最近のブラウザなら、まずFlashの実行許可が求められると思います。許可してください。

Flashを許可すると、下のようなログイン画面が開きます。とりあえずログインしてみましょう。初期ログインIDとパスワードは、先にクライアントPCで展開した先にある「Polestar_v2.4.12_9 (Linux版).pdf」の7ページをご覧ください。

11. ログインすると下のようなPOLESTAR Automationの管理画面が現れますが、初期状態のダッシュボードは、文字通り真っ白です。

画面の右上に歯車のアイコンがあります。とりあえず、以下のように操作してみましょう。

こんな感じで、POLESTAR Automationらしくなります。

12. この状態では、まだ管理対象サーバーやネットワーク機器を登録することはできません。評価版ライセンスを適用しましょう。
クライアントPCで先に展開したフォルダにある、「[Evaluation] Polestar Automation License.txt」ファイルを普段お使いのテキストエディタで開き、全体をコピーします。
次に、ブラウザに開いているPOLESTAR Automationの「システム管理」-「ライセンス管理」を開いて、コピーしたライセンスを貼り付けます。
ライセンス適用が完了すると、サーバー・ネットワーク機器各10台までを登録して180日間お使いいただける、POLESTAR Automation評価版の管理サーバーとしての準備が完了します。
このあたりの手順は、同じフォルダにある「POLESTAR_ライセンスキーの適用.pdf」もご参照ください。

■エージェントのインストール

管理サーバーの準備が整ったら、管理対象サーバーにエージェントをインストールし、管理サーバーに登録してみましょう。
まずは、管理サーバーをインストールしたVPS自分自身を管理対象として登録してみるのが、手っ取り早いです。

1. 先にクライアントPCでダウンロードしておいたAgent_Linux.tar.gzを展開します。
作成されたagent_linuxフォルダーの中身は、下のようになっているはずです。

2. VPSにSSHクライアントでログインし、PolestarDCA_Linux64_3.4_2.3.1.9.tar.gz （64ビットLinux用エージェント）を転送します。転送先はホームディレクトリでも構いませんが、サブディレクトリを作成してそこに展開することをおすすめします。

3. 転送したエージェントのファイルを展開します。
# tar –xzvf PolestarDCA_Linux64_3.4_2.3.1.9.tar.gz
カレントディレクトリにシェルスクリプトAgentInstall.shと、PolestarDCA_Agent というサブディレクトリが作成されます。

4. AgentInstall.shを実行すると、エージェントがインストールされます。
# ./AgentInstall.sh

5. もし管理サーバーと別のVPSや、実機を含む他のLinuxサーバーにエージェントをインストールした場合は、TCPポート22003の開放を行ってください。
# firewall-cmd --add-port=22003/tcp --zone=public --permanent
# firewall-cmd --reload

6. 以上でエージェントがインストールされ、管理サーバーからの登録が可能になりました。

■管理対象サーバーの登録

1. クライアントPCのブラウザでVPSのIPアドレスを開いて管理サーバーにログインし、メニューの「構成」-「デバイス登録」-「サーバ」の順に選択します。

2. 「サーバ登録」画面が開きます。
「検索開始IPアドレス」「検索終了IPアドレス」ともに、エージェントをインストールした管理対象サーバー（ここでは管理サーバー自身）の同じIPアドレスを入力し、右上の「追加」をクリックします。
「ポート」は22003のままにしておきます。

3. 検索開始IPアドレスの下あたりに、入力されたサーバーのIPアドレスが表示されているはずです。 下端中央の「次へ」をクリックします。

4. 「ロール」を指定するステップとなります。指定したロール（権限グループ）に属するユーザーだけにサーバーを見せるようにするための設定ですが、今回はそのまま「次へ」をクリックします。クリックすると、サーバーの検索が開始されます。

5. サーバーの検索が完了し、登録が可能になったところです。「登録」をクリックすると、サーバーの登録が行われます。

6. 登録が完了すると、状態が「管理」に変わります。「閉じる」をクリックしてください。

7. ワークスペース（左端のツリー部分）に、登録したサーバーが表示されることを確認してみましょう。
「All」（登録済みサーバーすべて）と「Linux」（Linuxサーバーのみ絞り込み）の両方に、先に登録したサーバーのホスト名があるはずです。
どちらでも構いませんので、ダブルクリックしてみましょう。

8. エージェントによって取得された管理対象サーバーの情報が表示されます。これはエージェントの情報を表示しているところですが、CPUやディスク（ストレージ）、ファイルシステム（ファイルとディレクトリ/フォルダー）、メモリ、ネットワークインターフェース、OSといった情報も見られます。

以上、今回は管理サーバーとエージェントのインストール、そして、エージェントの入った管理対象サーバーを管理サーバーに登録する手順をご紹介しました。
この記事、VPS向け、と銘打っていますが、別に物理実機であろうがオンプレ環境上にある仮想マシンであろうが、対象がLinuxである限り、基本的な手順は同じです。違いはローカルでダウンロードしたインストール関連ファイルをどうやってリモート側に送り込むか、それだけの話です。VPS以外の方も、ぜひ参考にしていただければ、と思います。

ここまででPOLESTAR Automationは動くようになりますが、管理対象サーバーに対してスクリプトを自動的に実行したり、点検をかけたり、といったPOLESTAR Automationならではの自動化機能を利用するには、「点検グループ」や「ジョブ」のインポートまたは作成が必要です。
次回は、そのあたりのご紹介です。



ワイドテックのYです。

前回のコラムで、自分でPOLESTAR Automation評価版を入れてみた話を書きましたが、そのインストール先がVPS（Virtual Private Server=仮想プライベートサーバー、root権限付きでレンタルされている仮想サーバー）であることはサラッと流しただけで、どのVPSを使ったのかとか、スペックとかには触れませんでした。ネタとしてキープしておいたために他ならないのですが、今回は、その部分を詳細にご紹介する段となります。

■評価版をどこに置くのか？ それが問題だ

評価版を試したくても、あいにく実機が空いていないとか、仮想OSであっても自宅や勤務先のPCに入れるのはローカルのリソースを消費するので面倒だ、とおっしゃる方も、少なくないことでしょう。
それならば、と思いつくのが、パブリッククラウドやVPSなどに立てる方法です。中でも個人ユースなら、何もかもが従量制課金のクラウドではなく、固定料金主体のVPSに立てる方がベターだと思います。
しかし、公式に弊社からアナウンスしている評価版の動作環境での要求スペックは、贔屓目に見ても結構ハードル高めなものです。

これ、開発元が決めたものとはいえ、これだけ見ると月1,000円以下のVPSはキツいと言わざるを得ないですね。気楽に試すにはちょっと辛いし、お勧めする立場としても少し気が引けてしまいます。
評価版とはいえ、実はプログラム自体は製品版など展開しているものと同じなのですが、管理対象のサーバー・ネットワーク機器が各10台、合計最大20台までに限定された評価版を試すのに、そこまでのスペックが必要なのか？ という疑問が以前からありました。

■あえて、動作条件を下回るVPSで試してみる

そこで、実用最低レベルは一体どの辺までなのかを見極める上でも、VPSへの、それもギリギリ動きそうなローエンドに近い構成でのインストールにチャレンジしてみることにした次第です。
今回試したのは、月額ベースで借りられるだけでなく、時間単位の課金（不要な時は止めれば課金されない）にも対応していて、二次元＋有名声優さんを使ったキャラクター展開でも知られる、国内の有名どころです。「この」VPS、個人的には以前から一度試してみたいと思っていたので、この機会に自腹でサインアップしてみました。

今回試したのは下から2番めのプランで、2コアの仮想CPU、メモリ1GB、SSDストレージ50GB、最新Linuxが使えて月額900円。1000円以下クラスのVPSとしてはスペックの良い方だと思います。今回は「令和」記念割引だとかで、10%引きの810円でした。

下の画面は、「この」VPSにインストールしたPOLESTAR Automation評価版の管理サーバーをブラウザで開き、「ダッシュボード」-「構成の状況」から登録済みの管理対象サーバーの一覧を開いてみたところです。

Linuxが6つ（うち4つがCentOS、2つがUbuntu）、Windowsが1つあります。

POLESTAR Automationのエージェントをインストールして管理サーバーに登録すると、ハードウェアやOSの構成状態を、一目瞭然で確認できるようになります。
以下は「この」VPS自体にインストールしたエージェントによって収集された、「この」VPSのリソース情報のスクリーンショットです。まずはCPUから。コアは2つ、2.4GHzのXeonなのですね。

これはメモリ容量、単位はKB（キロバイト）です。本当に約1GBです。

こちらはOSの情報です。仮想化基盤OpenStack Nova上で動いているCentOS 7.6であることがわかります。ちなみにカーネル5.1.6はBBR（前回のコラム参照）を使うために、自分で入れたものです。

と、いうわけで、今回の結論。

実際に試してみた印象では、社内の実機などで動かすのに比べると、やや重いかな、という気はしたものの、使えないレベルではないと感じました。
ログインして最初の画面全体のロードにはやや時間が掛かる印象です。freeコマンドで見てみるとSwap領域を多少消費しているようなので、スワップのためだと思いますが、ストレージがSSDということもあってか、そこまで待たされる感じもありません。一旦開き終わるとワークスペース（管理画面左側のツリー部分）でサーバー一覧を出す時間とかは、オンプレミスのPOLESTAR Automationとさほど遜色ない体感速度です。
ジョブも数台が対象ですから、実行速度はオンプレと大差ないです。
そんなわけで、自分なりの（非公式）結論です。
POLESTAR Automation評価版を動かしてみるなら、評価版の対象台数（サーバー/ネットワーク機器各10ノード、計最大20ノード）の範囲内であれば、今回の評価に用いた「この」VPSや同等のスペックで、リーズナブルな価格帯のVPSで十分です！

ちなみに管理対象として登録したのは、別のVPSやクラウド上にあるサーバー群と自宅のサーバーで、すべてグローバルIPでの登録です。対象のサーバーやVPSには予めエージェントを導入しておく必要があり、エージェントがVPS上のPOLESTAR Automation管理サーバーと疎通するためのポートの開放を、各VPSごとに行う必要もあります。
なお、VPS上のPOLESTAR AutomationにLAN上のサーバーを登録して管理したい場合、VPS側にVPNクライアントをインストールして、LAN側のVPNサーバーに疎通させるか、またはエージェントがグローバルにあるVPSから見えるように、インターネットに接続されたルーターでポートを開放する方法があります。接続点が1箇所で済み、プライベートIPアドレスで登録できる前者の方が、一旦VPNさえ疎通してしまえば楽な上にセキュリティ的にも良いのでしょうが、今回は自宅サーバー1台なので、後者の方法で試しています。
VPNを使う方法は、法人のお客様でパブリッククラウドやVPSに立てたPOLESTAR AutomationからPoCを行う場合にも有用かなと思います。

このコラムは、3回に分けての連載を予定しています。
次回は、VPSへの実際のインストール手順をご紹介します。



ワイドテックのYです。

10連休、新元号「令和」とともに明けた5月も、そろそろ終わりですね。
弊社の連休明けは、展示会「Japan IT Week 春・後期」とともにスタートしました。
連休明け直後、前後期・後期2会場での分散開催、慣れない仮設会場（東京ビッグサイト青海展示棟）のほぼ一番奥のブース、といういくつもの厳しい条件のもとで開幕した展示会でしたが、3日間の来場者数が例年と比べて激減したにもかかわらず、総来場者数に対する弊社ブース訪問者数の比率は、おかげさまで前年を上回っておりました。

ご来場いただいた皆様には、この場をお借りして感謝いたします。

■GWとGFW

数年前から毎年4月に仕事で中国に行くのが恒例で、今年も行ってきたのですが、中国出張のたびに毎回悩まされるのが、インターネット規制です。

ご存知の方も多いでしょうが、中国には「金盾工程」と呼ばれるインターネット統制の仕組みがあり、中国の外では「万里の長城(Great Wall)」に準えて「GFW（Great FireWall）」として知られています。しかし、規制があると必ず回避を試みようとする動きも出てくるわけで、次から次へと新しい回避手段が発見、ないしは生み出されています。
以前はGFW回避手段というとVPNが主流でしたが、VPNは通信プロトコル上見分けが簡単なので、近年は発見され次第、当局から即規制されると聞きます。

最近は「Shadowsocks」という、SOCKS5をベースに中国内で開発されたプロキシサーバーがよく利用されているようで、現在はさらに改良を加えた「ShadowsocksR(SSR)」が主流です。普通の非VPN通信と見分けが付きにくく、発見されにくい（＝規制されにくい）上に、最新の暗号化技術（Chacha20など）が使えてセキュアで、しかもベースがSOCKS5なので速度も一般的なVPNより優秀、とされています。
これにさらにGoogleが開発し、Linuxカーネル4.9以降で有効化可能なTCP輻輳制御アルゴリズム「BBR(Bottleneck Bandwidth and Round-trip propagation time)」を組み合わせると、パケットロスが激減し、例えば動画などの視聴も安定します。 自分も最近SSR+BBRの存在を知り、今回の中国出張の直前に自宅のサーバーに立てて行きました。
導入には、こちらのQiitaの記事を参考にさせていただきました。

[中国金盾][VPN][ShadowsocksR][BBR] VPNを自分構築してみる

しかし、GFW以前にホテルのWi-Fiが絶不調で、あまり効果を実感する場面がなかったのがちょっと残念でした（ちなみに持参したスマートフォンには、GFWの影響を受けないタイ国のキャリアの海外ローミング対応プリペイドSIMカードを入れていました。短期の出張なら、これでも十分ですね）。

■趣味でPOLESTAR Automation 評価版を使ってみた

日本に帰ってきて、SSR+BBRのGFW超え技術や通信高速化効果にさらに興味が湧いてきたので、GW（ゲートウェイでも万里の長城でもなく、連休です）を機に、国内を含めたいくつかの国にVPS（レンタル仮想サーバー）を借り、立ててみました。

気付いたら、その数は9つにもなっていました。一体いくら掛かるの？ と心配される方もおられるでしょうが、海外のVPSには、安いものでは共有IPで年額（月額の間違いではありません）300円台から、専有のグローバルIPがもらえるものでも、3か月で600円ぐらいからあったりします。ストレージは2～5GBとかですが、コンテンツを大量に置くわけでもないので、十分です。
その管理に、3月から弊サイトで提供しているPOLESTAR Automation 180日評価版を使いはじめました。

この評価版（管理サーバー）は普通のインストーラ形式ではなく、Java（OpenJDK系統で構いません）が使えるようになっているWindowsまたはLinux環境上で、フォルダー（ディレクトリ）に直接展開して実行するだけ、という非常に簡単な手順でお試しできるようになっているものです。
今回、管理サーバー自体も、自宅ではなく国内の某VPSに置いてみました。

管理対象の各VPS（すべてLinux、CentOS6だったり7だったりUbuntu 18.04だったり）にPOLESTAR Automationのエージェントを入れ、ポート（標準は22003ですが変更できます）のファイアウォールを開けてやった状態で、管理サーバーのGUIから対象サーバーを登録すれば、いろいろな操作や構成情報の取得が自動化できるようになります。
BBRや他の通信高速化手段の有効化設定、SSR等のインストーラやスクリプトファイルの配布からインストール、通信量（特に海外のVPSは転送量制限があるのが普通なので）や速度の測定などができるようにしました。既存のスクリプトを微改造して回し、結果を取ってきているだけなので、全然活用しているとは言えないのですが、VPSごとのコンソールやコントロールパネルなどにログインするより、楽でいいです。

こんな風に、POLESTAR Automation 評価版はお仕事でなくても、個人でダウンロードしていただいて、完全に趣味の範囲でお使いいただいても構いません。
お気に召していただいたら、ぜひともQiitaなどに投稿していただけるとありがたいです。
もちろん、趣味でお試しいただいて、ぜひ業務にも…となると、最高です。

■Qiitaといえば…

ところで、このコラムにはそのQiitaの広告バナーから飛んで来られた方も多いかと思います。なぜなら、バナーのリンク先が、このコラムになっているからです。（笑）
この4月から、弊社ではPOLESTAR Automationの知名度・認知度を上げるための、さまざまな取り組みを行っています。@ITさん（1回目、2回目）やZDNet JapanさんにはPR記事が掲載されましたし、Qiitaさんほかにはバナー広告を出稿しました。

この中で普段から趣味でも実務でも参照することの多いQiitaへの出稿については、自分ことYがぜひやってみたいと考えて、半ばゴリ押しの形で決まったものです。なので、コピーとかも自分の作です。なお、バナー制作とおじさん画像のチョイスは、隣席のWebデザイナーさんにお願いしました。
実はそろそろ掲載が終わる頃なので、記念に全3種類のバナーを掲載しておきます。

さて、冒頭のJapan IT Week 春に続き、来月6月12～14日には「Interop Tokyo2019」が控えています。今回は新バージョン「POLESTAR Automation V3（仮称）」を、初めて本格公開します。ご要望の多かったエージェントレス対応やAPI連携（Zabbixも行けます）、全面HTML5化した新UIなど、ぜひとも会場にてお試しいただければ幸いです。
皆様のご来場をお待ちしております。



ワイドテックのYです。

今年初のコラム脱稿が1月末ギリギリというタイミングになってしまいましたが、大型のお客様案件やその他POLESTAR Automation関連のいくつもの企画が、年明け早々から一斉に走り出してしまい、コラム執筆に手が回らなかったためです。
そんな中、多少時間が取れたので、POLESTAR Automationのインストールについて、ちょっと変わった「実験」をしてみました。今回はそのお話です。

■Windows上でLinuxが動く「WSL」とは

今回の実験を思い付いたのは、Windows 10上でLinuxのコマンドライン用ソフトウェアが動かせるという「Windows Subsystem for Linux(WSL)」を試してみたのがきっかけです。 WSLは2016年にβ版が、2017年のFall Creators Update(v1709)で正式版がそれぞれリリースされています。発表当初はBash on WindowsとかBash on Ubuntu on Windowsなどと呼ばれていたこともあります。発表された頃からその存在は認識していたのですが、Linuxは一昨年の秋にRaspberry Pi（ラズパイ）を触るまで本格的に弄ったことがなく、今も自分にとってはラズパイを含めたシングルボードコンピュータでの利用が中心なので、実際にWSLを試したのは今年に入ってからです。

さて、WSLについて軽く解説しておきますと、その実体は、Windows 10のカーネルでユザーモードのLinux用ソフトウェアを動作させるためのカーネルインターフェースであり、Linuxカーネルそのものは含まれません。
独自のカーネルを持った仮想マシン(VM)ではないので、互換性も完全ではないとされていますが、VMでない分、リソース消費が少なく、低スペックのPCでも使えると思います。
あと、Windows上でLinuxを動かす手段として以前からあるのはHyper-Vですが、Hyper-Vが使えるのは64ビット版のWindows 10 ProやEnterprise等であり、Windows 10 Homeでは使えません。WSLなら、64ビット版であればWindows 10 HomeでもOKというのも、敷居が低くて好ましいです。
WSLではDebianやSuSEなども動かせるようですが、Bash on Ubuntu on Windowsという当初の呼称からもわかるようにUbuntuのCanonical社が開発に協力したようで、基本はUbuntuです。日本で多数派？ のCentOSには未対応なので、Fedora系統が使いたい場合はFedora Remix for WSL（有償です）というのを選ぶことになるようです。
UbuntuといってもGUIは使えませんが、実際に試してみると、Linux用に開発されたコマンドラインのプログラムは違和感なく動きます。WebサーバーのNginxとかPHP 7.2、MariaDB、そしてWordPressも試してみましたが、あっさり普通に起動して拍子抜けするほどでした。
ただし、VMではなくカーネルはWindows側と共用なので、アップデートパッチ（apt update→apt upgrade）を適用して再起動を求められた場合は、Windowsのシステム(OS)ごと再起動するまで適用されません。あと、ネットワークインターフェースもWindowsに被る形になるので、Windows側で例えばWebサーバーなどが動いている場合は、ポート番号が被らないように設定しないと、競合します。

■POLESTAR AutomationをノートPC+WSLで動かしてみる

そんなわけで、WSLを触っているうちに試してみたくなったのが、果たしてWSLにPOLESTAR Automationの管理サーバーを構築できるのか？ です。
まず、前もってお断りしておくと、POLESTAR Automationの推奨スペックは論理4コア以上、メモリ16GB以上のサーバーマシン、サーバーOSです。WSLは最新のWindows Server 2019でも動いているようですが、今のところはクライアント用のWindows 10が中心だと思います。サーバーOSでないことには目を瞑るとしても、このスペックを満たすPCとなると、それなりのものになりますね。
とりあえず前提条件は果敢に無視し、まずはデスクトップPC上のWindows 10 ProにWSL環境を作って動かしてみました。Intel G3260というデュアルコアCPU、メモリは8GBで、Hyper-Vも動かしたことがありますが、常用には結構しんどい環境です。
今回は、WSLを有効化してWindowsストアから最新LTS（長期サポート）版のUbuntu 18.04をインストール後、POLESTAR Automationの動作に必要なJava VMとMariaDBをインストールします。前回ご紹介したAdoptOpenJDKとMariaDB 10.3をインストール後、POLESTAR Automationを入れてみたら…いとも簡単に動いてしまいました。
Windows側のブラウザからlocalhostで開いてみましたが、普通に見慣れたPOLESTAR Automationの管理画面が開きます。

次にノートPC。普段個人で愛用している、メモリ4GB（増設不可）、CPUはIntel Core m3、Windows 10 Home 64ビット版のプリインストールされた、12インチ液晶で1kg強の、いわゆるモバイルノートPCです。
こちらでも同様にWSLでUbuntuが動くようにした後、デスクトップと同じようにAdoptOpenJDKとMariaDB 10.3を入れてからPOLESTAR Automationをセットアップします。

ギリギリのメモリ容量ですが、このノートPCはストレージが100% SSDなおかげか、意外にも軽く動きます。
こんな感じで、Hyper-Vがサポートされずメモリも厳しいWindows 10 HomeのノートPCでも、WSLを使ってPOLESTAR Automationを動かせるようになりました。
ちなみに、自分自身（WSL側でもWindows側でも。ただしどちらか一方）にエージェントをインストールする、つまり1台のPCにPOLESTAR Automation一式をインストールすることができますので、簡単な動作確認なら1台のPC上で完結させることも可能です。ノートPCなら、どこでもテストが可能となるわけです。エージェント経由でPCの再起動を伴うようなテストは、もちろんできませんが…

ところで、実はWSLなどという回りくどい手段を使わなくても、POLESTAR AutomationにはWindows版のインストーラもありますので、そのままノートPCを含むあらゆるWindows PCにインストールすることが可能です。
それなのに、なぜこんなややこしいテストをしたのかといいますと、現在社内でとあるプロジェクトが動いていて、その至上課題のひとつがWindows用、Linux用の両インストーラに関する「インストール手順の簡素化」だったりするのですが、その一環として自分の普段使っているWindows PC上に手っ取り早くLinux環境を作り、LinuxでのPOLESTAR Automationの新しいインストール手順と動作を確認してみたかったからです。
「とあるプロジェクト」の詳細は、間もなく発表できると思います。乞うご期待！

そして、本年も引き続きPOLESTAR Automationと本コラムをご愛顧賜りますよう、よろしくお願いします！



ワイドテックのYです。

元号「平成」で迎える最後の年末まであと1週間。先日は3連休の方も多かったでしょうが、12月23日も来年からは平日です。いろいろと感慨深そうな年末がもうすぐです。
そして、年明け早々、IT業界を揺るがしかねないイベントが1月末に控えています。今回はそのお話から。

■Javaの有償化と、その対策は？

例年この時期になると、各分野の今年の重大ニュースランキングが盛んに発表されますが、IT分野のニュースで結構な上位に入っていそうなのが「Javaライセンスの有償化」ではなかったでしょうか。
実はPOLESTAR Automationも、管理サーバーのプログラムはJavaで構築されていて、動作にはJDKが欠かせないので、我々POLESTARチームにとっても他人事ではありません。

Sun Microsystems社により開発されたプログラミング言語Javaは、Oracle社によるSunの買収とともにOracleに権利が移って以降も、これまではずっと無償でライセンスされ、バグ修正や脆弱性対策等のアップデートも、基本的に無償で提供されてきました。Javaが普及したのは、OSプラットフォームに依存せずコードを共通化できることと、ライセンスフリーなことが理由であったのは言うまでもありません。

ところが、この3月にJava 10のリリースとともに、6か月後に提供されるJava 11からのJavaライセンスの有償化が発表され、実際に9月には初のサポート有償化版としてJava 11が提供されました。「Javaショック」とも呼ぶべき一大事件、騒動となったのは、まだ記憶に新しいことでしょう。

今後Javaが利用されている多方面に影響を与えそうなJavaの有償化ですが、その影響が直近で顕在化することになるのは2019年1月31日、つまり来月の末日です。LTS（長期サポート）版として提供され、稼働数も最も多いと思われるJava 8の商用ユーザーに対するサポートが終了する日（個人向けは2020年末まで）です。2019年2月以降、商用Javaの脆弱性対応は無償ではできなくなるのです。

なお、Oracle自身とコミュニティによるJavaのオープンソース実装としてOpenJDKがあり、近年は概ね商用Javaと同じペースでバージョンアップが行われています。ただし、Javaアプレットは商用Javaのものは使えない上、今後OpenJDKのLTSが提供されるかどうかも、本稿執筆時点でもまだ明確になっていません。LTSがなければ、サポート期間はバージョン更新から6か月間が原則となります。
他に、Java 8では2023年まで、11では4年間のLTSを提供するとしているAdoptOpenJDKというプロジェクトもあります。今後もLTSが期待できるとしてJava有償化発表以降にわかに注目を集めていますが、OpenJDKのソースを基にしているとはいえOracleによるものではないので、検証が必要かもしれません。

■POLESTAR Automationで、サーバー数千台のJavaバージョンを一斉チェック！

で、Javaの話を年内最後に持ち出したのは、POLESTAR Automationから管理対象サーバーにインストールされている「Javaバージョンの一斉チェック」ができる自動化ジョブスクリプトの用意ができたからです。

実はPOLESTARの最大手のお客様から要望があり、POLESTARの開発元で作成して提供したものなのですが、そのお客様のサイトでは、このスクリプトを使ってあっという間に、管理対象サーバーにインストールされているJavaバージョンの何千台分ものリストが作成できたそうです。

POLESTAR Automationを使えば、Javaのバージョンチェックはもちろん、ファイル配布/インストール機能を用い、その後のバージョン更新まで自動化できます。
なお、今POLESTAR AutomationのローカルPoCをお申し込みいただいた方には、このJavaバージョンチェックスクリプトも提供させていただきます。

■クラウド上のPOLESTAR AutomationをLANと繋いでみました

AWSとローカルのネットワーク環境を接続する手段はいくつかあるのですが、最も敷居の低そうなのはVPNを利用する方法かと思います。クラウドとLANのVPNによる接続手順についてはここでは省きますが、とりあえず本当に動くかどうかを検証しないとお勧めできないので、実際にPOLESTAR Automationが動いているAWSのインスタンスで試してみた次第です。 管理対象サーバーとしてテストに使用したのは、今回もRaspberry Piです。小回りが利く上に普通にLinuxサーバーとして使えますので、最近POLESTAR関連の社内テストに大活躍しています。

と、いうわけで、クラウドにお客様のPoCや実運用のためのPOLESTAR Automationを構築しても、普通にオンプレ側のサーバー運用管理に使えることが確認できました。

さて、2018年の本コラムは、これが最後になります。
今年1年もPOLESTAR Automation Webサイトをご覧いただき、ありがとうございました。
2019年には、先般ご案内したエージェントレスなど新機能の提供も控えていますし、運用管理業界にちょっとしたインパクトを与えそうな新展開も準備中です。どうか引き続きご愛顧いただきますよう、よろしくお願いします。



ワイドテックのYです。

10月に千葉・幕張メッセで開催された今年最後の大型IT展示会「Japan IT Week 2018 秋」のPOLESTAR Automationブースは、おかげさまで大盛況となりました。1か月も間が空いてご挨拶が遅くなってしまいましたが、ご来場いただいた皆様に、この場をお借りしてお礼を申し上げます。
今回は、多くのお客様からご要望をいただいておりました、エージェントレスによるサーバー運用自動化機能が実現しそう、という朗報のご紹介です。

■根強かった「エージェントレス」への要望

現在のPOLESTAR Automationはサーバー、ネットワーク機器を対象に点検や監査などの構成管理、運用業務を自動化できるソリューションですが、サーバーの管理については各管理対象サーバーにエージェントを組み込むこと（エージェント方式）が前提となっています。
エージェント方式は、最初に管理対象サーバーにエージェントをインストールしてしまえば、あとは管理対象側の設定はほぼ不要（ファイアウォールが介在する場合はポート開放も必要となります）で運用自動化が始められ、かつファイル転送やOS/アプリケーションパッチの適用なども容易に実現可能で、管理サーバー側に管理対象サーバーのログイン情報も保持しないのでセキュリティ的にも安心と、メリットの多い方式です。
しかし、特に自社のサーバーではなく、顧客のシステムを扱うデータセンターやマネージドサービス提供などのお客様を中心に、「顧客のシステムに特別なプログラムを入れたくない」という理由から、エージェントを使わない方式へのご要望を多数いただいておりました。

■ネットワーク機器管理機能は既にエージェントレス

もともと発売当初、POLESTAR Automationは、サーバーだけを管理対象とする運用自動化製品でしたが、2017年秋にはネットワークスイッチやルーターなどを対象とした「ネットワーク機器管理機能」をリリースし、自動化の幅を拡げています。
ところで、エージェント方式のPOLESTAR Automationがネットワーク機器に対応したということで、「ネットワーク機器にどうやってエージェントを？」と疑問を持たれた方もおられるかもしれません。
結論から言えば、既存のPOLESTAR Automationでもネットワーク機器に対しては、エージェントを使わない方式で自動化を行っています。ネットワーク機器の構成情報はSNMPで取得し、コマンドやスクリプトの投入は、SSHを用いて管理対象のネットワーク機器にログインすることにより実行されます。
つまり、ネットワーク機器に対応した時点で、POLESTAR Automationは構造上、既にエージェントレスになっていたとも言えるわけです。

■エージェントレス対応プロトタイプ到着！

そしてこのたび、サーバーを含む全面的なエージェントレス運用の実現に向け、開発元よりエージェントレス方式によるサーバーの運用に対応した、プロトタイプバージョンが上がってきました。
先日より、社内でテストを開始しているところです。現在動作しているのは「点検ジョブ」「監査ジョブ」「スナップショットジョブ」「Expectジョブ」の4種類のみで、まだ課題も多いのですが、これまでのテストでは既存のエージェント方式用の点検グループを使ったジョブの多くが、エージェントレス環境でも動作しています。

今後、弊社を含むテスターからのフィードバックと機能のブラッシュアップを経て、β版、そして製品版のリリースへと続いて行く予定です。
本コラムでは、引き続きPOLESTAR Automationのエージェントレス対応開発の進捗状況について、随時お伝えしてまいります。どうぞお楽しみに！
あと、ご希望されるお客様には、エージェントレス版のデモも承ります。どうか弊社営業まで、お気軽にお問い合わせください。



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

このところ、コラムでは展示会の話ばかり書いている気がしますが、今年もあと1回、来月の「Japan IT Week 2018 秋」にPOLESTAR Automationを出展いたします。詳細は9月中旬以降にご案内しますが、従来よりやや広いブースになり、今回初公開となる新製品も参考出品します。その新製品とは…

■IT運用管理からIoTへの展開

弊社の社内では、たくさんの新プロダクトや新ビジネスのプロジェクトが同時進行で動いています。具体的な製品のリリースを念頭に置いたプロジェクトもあれば、テーマごとに動いているものもあります。 ただ、テーマ別のプロジェクトは長い時間を掛けて取り組む自由研究や勉強会のようなところもあって、具体的にいつまでに、という段階になると、製品別プロジェクトに移行することになります。 もう数年にわたってテーマ別に取り組んでいるもののひとつに、近年注目を集めるIoT（Internet of Things、モノのインターネット）も含まれており、社内で志のあるメンバーからさまざまな情報が集められ、共有されています。個人的には非常に興味を持っていて、IoT関連の展示会やセミナーなどにも、たびたび顔を出させていただいています。

そうした弊社の事情を知ってか知らずか、POLESTAR Automationを開発しているNKIA社でも、IoT向けプロダクトの開発に取り組んでいます。 IoTという概念は非常に広範にわたっていて、いわゆるFA（工場自動化）から発展した製造業向けのIoTにはじまり、農林水産業、流通・物流分野などのサービス業、はてはコンシューマー向けのHA（ホームオートメーション）まで、既存の機器をコンピューター・ネットワークに接続すれば、それはIoTだ、ということができます。 IoTで利用されるデバイスは、遠隔操作可能なスイッチ類（ネットワーク用語のスイッチではなく、電源を入れたり切ったりする電気的なスイッチです）などもありますが、キーデバイスになるのは、やはりセンサー類でしょう。センサーをネットワークに接続し、環境データなどを取得して監視、分析することで、製造業なら製造機器類の自動制御や部品の耐用年数の予測、農業分野であれば水や肥料の適切な補給、流通業なら来客数・来客属性の予測とそれに応じた商品在庫のコントロールなど、さまざまな応用が可能です。

■新開発の「IoTソリューション」を初披露します

NKIAが開発しているのは、センサー類の監視・分析を中心としたIoTソリューションです。国内外で既に多くの企業が同様な製品に取り組んでいますが、NKIAは20年近い蓄積のあるIT運用監視や自動化に関する豊富なノウハウ、次世代のIT運用への適用に向けて取り組んできたAIやビッグデータ解析など、IT運用管理製品で培った経験と実績を集大成したIoT向け監視・分析ソリューションとして、差別化を図ろうとしているそうです。
このIoTソリューション、今回のJapan IT Week 秋が初披露となりますが、まだ販売開始日程が決まっているわけではないので、あくまで参考出品という形です。
弊社ブースのメインは今回もPOLESTAR Automationですし、POLESTAR Automationとは全く異なる市場に向けた製品が1つのブースに同居してしまうことになりますが、IoT導入・運用も兼任されている情シスの方のご来場や、製造管理部門などへのご紹介など、ぜひともご検討いただければと思います。

ところで「参考出品」といえば、2017年のInterop以来、弊社が出展する展示会では、これまでIT運用監視ソリューション「POLESTAR Monitoring」を、毎回参考出品してきました。
単なるサーバー・ネットワーク機器等の監視やアラート通知にとどまらず、機械学習AIによる障害予測機能を搭載した先進的な監視ソリューションとして、製品化にご期待いただいているお客様も多かったのですが、実は先日、POLESTAR Monitoringという名称の単体製品としては、リリースを見送ることに決定しました。
発売予定が固まっていなかったので、このサイトで詳細をご紹介することはありませんでしたが、展示会ご来場の方には製品化前提の展示であるとご案内してきたので、これまで楽しみにして来られた皆様方には、この場をお借りしてお詫びさせてください。
しかし、IT運用管理の最前線において、運用自動化とともに欠かせない存在である監視（モニタリング）については、何らかの形で提供させていただくつもりで、準備を進めています。時期が来たらご案内させていただきます。ご了承ください。

では、Japan IT Week 秋の正式なご案内をお楽しみに！



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

報告が遅くなってしまいましたが、弊社では5月、6月と2か月連続で、大型のIT展示会にPOLESTAR Automationを出展させていただきました。

5月の「Japan IT Week 春 2018」（東京ビッグサイト）、そして6月の「InteropTokyo 2018」（幕張メッセ）、いずれも過去最大の入場者数を更新し、弊社ブースも予想を上回る大変な盛況となりました。

弊社ブースのスタッフ、特に説明に携わる要員は昼食を摂ることすらままならないほど多くのお客様が訪問され、嬉しい悲鳴を上げることになりましたが、その分、今後につながるお話も多くいただけたと考えています。

■展示会に出展し続ける理由

2016年秋から始まったPOLESTAR Automationの展示会への出展は、直近のInteropで6回目となりました。

規模の小さな弊社では、営業や技術の担当者の数も限られており、プッシュ型の営業を行うのもままならない状態です。そこで展示会を貴重なコミュニケーションの場と考え、毎年複数回の展示会への出展を基本にしています。
営業に行かないと聞かせていただけないような、さまざまなご意見、ご要望を集中的に伺うことができるのが、弊社が展示会を重視する最大の理由です。

あと、弊社が出展している展示会は、いずれも首都圏で行われるものですが、本来ならこちらから出向いて行かなければならない地方のお客様も、北は北海道から南は九州・沖縄まで、多数来場されます。多数のサーバーを運用されているお客様、システム運用に悩みを抱いておられるお客様は、首都圏だけにいらっしゃるわけではありませんので、そうした地方の皆様のニーズを直接汲み取る機会でもあります。
お客様から得られるご意見、ご要望は、POLESTAR Automationの製品機能やマーケティング活動をより充実させる上で、非常に参考になります。

■「ひとり情シス」にもPOLESTAR Automation!

ところで、今回の2か月連続の展示会で多かったのが、いわゆる「ひとり情シス」、またはそれに近い少人数でシステム運用に携わられているというお客様です。昨年も結構ありましたが、以前にもまして、少人数での運用に苦労されている方が増えている気がします。

サーバーの台数は20～30台程度と少なくても、対外的なサービスを運用していたり、社内サーバーであっても業務基盤として依存度が高かったりして、絶対に止めてはならないサーバーがあることでしょう。それに、脆弱性対策やOSのバグ修正などのためにパッチを適用する作業は煩雑で、しかも作業可能な時間が非アクティブな時間帯に限られるため、全部パッチを当て終わるまでに1日や2日では済まないというお話も伺いました。

サーバーの台数が少ない事業所では、管理に携わる人数が1人で、さらにクライアント側PCの面倒を見る社内SEと兼務せざるを得ないケースもあって、激務になることも少なくないそうです。それが原因で辞めていくシステム管理者も、少なくないと聞きます。
管理・運用の担当者が辞めてしまった結果、管理ノウハウが引き継がれることもなく、たとえ手順書などの形で引き継がれたとしても、新しい担当者が消化しきれないまま日常の管理やトラブル対応に苦労することになった結果、また退職へと追い込まれるようなケースもあるそうです。
これが「ひとり情シス」問題です。もちろん担当者を増やして業務量を分散できればよいのでしょうが、雇用側の事情や昨今の雇用情勢から、簡単に人を増やせないこともあるでしょう。

こうした問題の解決にも、POLESTAR Automationはお役に立てると思います。複数のサーバーに対して自動的に、かつ同時並行で一斉にパッチを当てる作業などは、POLESTAR Automationが最も得意とするものです。

さらに、日常の点検や構成情報の収集・変更、ソフトウェアのインストール・更新など、POLESTAR Automationはシステム運用のあらゆる場面で活躍します。
実は、POLESTAR Automationを発表した時点では、買い取り型のライセンスしかなく、価格体系も最小管理台数100台を想定していました。しかし、展示会等を通じてご来場のお客様よりお話を伺う中で、サーバー20台程度の事業所でも自動化の需要はあると判断し、年単位契約のサブスクリプション型料金を導入するに至った経緯があります。

「ひとり情シス」にもPOLESTAR Automation。自動化によって運用担当者の業務負担を軽減し、少ない人数でもより多くのシステムを管理可能にすることで、担当者の業務満足度向上をも実現します。

お困りの皆様、ぜひとも弊社営業までご相談ください。

なお、弊社ではPOLESTAR Automationの展示会出展活動として、今年度はあともう1回、10月に幕張メッセで開催される「Japan IT Week 秋 2018」への出展を予定しています。

この秋には、新しい趣向での展示をご披露できればと考えています。
詳しくは期日が近付きましたら、また案内させていただきます。ご期待ください！



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

POLESTAR Automationがじわじわと売れ始め、現在、担当のエンジニアは納品するサーバーの構築に追われています。

POLESTAR Automationはソフトウェア製品ですが、弊社ではソフトウェアライセンスとしての提供だけでなく、サーバーにインストールした状態での販売にも応じております。今回、お客様よりリクエストがあったので、POLESTAR Automationの担当以外に、普段別の業務を担当しているエンジニアまで応援で参加し、鋭意作業中です。

その作業は自分の席のすぐ隣で行われているので、作業の状況は否が応でも伝わってくるわけですが、非常に勉強になることも多いです。

■インターネット未接続のシステムで、アップデートはどうやる？

最近、いわゆる「閉域網」、つまりインターネットに常時接続されていないシステムを組まれているお客様からの問い合わせが、相次いで弊社の営業宛にありました。

閉域網でサーバーやネットワーク機器を運用する場合、課題になるのが各機器とそのOSの修正アップデートパッチ、アプリケーションソフトウェアなどの導入や更新です。

Windowsでは例の「Windows Update」が米国時間の毎月第2火曜日（日本は時差の関係で第2水曜日）に定期配信されるほか、緊急の脆弱性対応などで臨時のWindows Updateが配布されることもあります。インターネットに接続されていれば、通常は勝手にアップデートパッチがダウンロードされ、たいていは再起動を伴って適用されます。

Adobe Flash PlayerやJavaランタイム、WebブラウザのGoogle ChromeやFireFox、IMEのGoogle日本語入力などは、割と不規則に自動更新されます。

しかし、インターネットにつながっていない閉域網では、自動でアップデートを適用することはできませんので、インターネットに接続された別のPCでダウンロードしたパッチファイルを、USBメモリなどを用いて閉域網の各サーバーに転送し、手動でインストールする、ということが行われます。

もちろん、最初から自動更新の機能などなく、手動で更新しなければならないアプリケーションソフトウェアも多く存在しますし、自動更新があっても新規インストールはたいてい個別に手動で行う必要があります。これらのケースでは、作業は閉域網か否かに関係なく、個別に行うことになりますね。

数百台規模ならもちろん、数十台でも結構面倒な作業です。

■POLESTAR Automationのソフトウェア配布機能が解決します

と、いうわけで、前述の閉域網のお客様には以前展示会でPOLESTAR Automationを紹介していたこともあって、白羽の矢を立てていただいた次第です。

POLESTAR Automationには、ファイルリポジトリとソフトウェア/ファイル配布の機能があり、POLESTAR Automationのファイルサーバー（リポジトリへの想定保存容量が少ない場合は、管理サーバーまたはDBサーバーと兼用可能）に保存されたアップデートファイルを対象のサーバーに配布し、複数のサーバーに対して同時並行的にインストールすることが可能です。

もちろん、すべての対象サーバーではなく、一部だけにソフトウェアのインストールや更新を実施したいこともあるでしょう。そのようなケースでは、サーバーを自動的に振り分け、分類するスマートグループ機能を用いて、対象サーバーと非対象サーバーを分けておけば便利です。

また、管理対象サーバーのWindows UpdateをWSUS(Windows Server Update Services)環境で管理していない場合は、POLESTAR Automationの「Windows Update管理モジュール」をお使いいただくことで、管理対象サーバーに対するWindows Updateの管理を、POLESTAR Automationの管理画面上で一括して実施することもできます。

アプリケーション導入や各種修正アップデートパッチ適用作業の自動化にも、ぜひともPOLESTAR Automationをご用命いただければ幸いです。



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

POLESTAR Automationの発売から1年半ほど、Webサイト等での露出を地道に、時には展示会などを通じて派手に重ねてきたこともあってか、それなりに認知が広がってきている気がしています。最近、問い合わせの数が以前にもまして増えてきており、営業・技術の担当者が製品の説明やデモに出向く時間も多くなっています。

中小企業ゆえ、限られた人数で回していますので、担当が外出中などの場合は、お問い合わせをいただいても即答できないケースも出てくるほどです。専門の担当者が適確にお答えすることを優先していますので、多少のお時間をいただく場合があるかもしれません。あらかじめご了承ください。

■始まりはいつも、市場調査から。

実は自分ことYは、現在POLESTAR Automation関連の直接業務からは外れ、新しいプロダクト企画に携わっています。新企画はまだ市場調査の段階なのですが、何か調査業務を始める度に思い出されるのが、POLESTAR Automationプロジェクトの初期のことです。
弊社内で「自動化」製品のプロジェクトが立ち上がったのは、2014年の話です。昨年（2017年）「RPA」というキーワードが、ITに「新語・流行語大賞」があるなら大賞をもらいかねない勢いで話題を集めましたが、当初は今でいうRPAのような汎用自動化製品を志向していました。

以来、2016年10月にPOLESTAR Automationとしてリリースアウトするまで、結構な期間が流れたのですが、RPA的な製品ではなくIT運用の自動化にフォーカスしたのは、当時の市場調査を受けての結果でもあります。

リリースまでの2年ほどで、最も多くの時間と手間を費やしたのが、市場調査です。あの手この手で、運用自動化市場の規模や競合製品の情報などを収集し、新規参入に向けての手応えを掴もうとしてきました。中でも、このコラムの第1回でも触れた通り、弊社の売上のかなりの部分を占めているのが、NMSスーパーバイザーシステム「TOGOS」を祖とする技術人材派遣事業なのですが、システム運用の業務に携わっている社員も少なくないので、現場からの経験談（もちろん、派遣先との守秘義務に触れない範囲で）も聞くことができました。
営業開始に先立ち、まずは市場調査と現場の情報をもとに、営業やマーケティングのプランを立てました。当初、競合製品として想定していたのは、国内の大手ベンダーさんや海外のグローバルベンダーの製品で、それぞれ国内・海外の自動化市場で高いシェアを占めていて、価格も高いといわれるものばかりでした。
当然、価格を含めた営業政策も、最初はそれらの製品との競合を念頭に置いたものとなりました。

■世に出して初めてわかったニーズも

しかし、実際に販売活動を開始してみると、事前情報・予備知識とは異なる製品との競合や、予想だにしなかったニーズなどが、次々と発掘されたものです。
中でも、Ansible（アンシブル）をはじめとするOSS（オープンソース・ソフトウェア）の浸透度には、当初の想定を上回るものがありましたが、OSSを含む既存の運用自動化ツールを導入してみたものの、うまく活用できていなかったりとか、そもそも運用自動化の導入自体がまだ、というお客様も多かったのも意外でした。

POLESTAR Automation発売前の段階で「大手企業のユーザーさんはあらかた運用自動化を導入済み」「運用自動化は大手中小入り乱れてレッドオーシャン」といった悲観的な情報も耳に入ってきていたので、実はまだまだビジネスチャンスのある市場だという手応えが掴めたことには、製品化の実務を担当した身としては、ほっとしているところです。

もちろん、弊社としても、実際の市場状況に素早く対応することを心掛けています。昨秋から導入したサブスクリプション方式の料金体系は、OSSからの乗り換えのお客様を想定して用意させていただいたものですし、発売当初なかったネットワーク機器の制御機能も、お客様からのご要望を受けて追加したもののひとつです。
あとはお客様がどの運用自動化製品を選ばれるか、に尽きるわけですが、展示会や訪問デモなどを通じて、お客様から高い評価をいただいているのが、POLESTAR AutomationならではのユーザーフレンドリーなGUIです。

展示会はしばらくありませんので、定期的に開催しているセミナーや営業へのデモ依頼を通じて、運用自動化の導入や乗り換えを検討されている皆様方に、ぜひともPOLESTAR Automationの扱いやすさを実感していただければと思います。

以上、2018年初めてのPOLESTARコラムは1月中を死守すべし！ と考えていたのですが、別件で動いていたこともあって、今日の脱稿となりました。新年のご挨拶のタイミングは完全に逸してしまいましたが、引き続きお客様のニーズを最優先に進化を続けるPOLESTAR Automationでありたいと、関係者一同願っております。



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

ここに個人的な話を書くのは気がはばかられるのですが、実は10年ちょっと前から、いわゆる「自宅サーバー」を立てています。自宅で使用している可変IPのインターネット回線を経由し、外から自宅のLANに接続できるようにするためです。

自宅サーバーを立てる動機や利用方法はさまざまでしょう。おそらくはファイルサーバーが最も多いと思いますし、WordPressなどを使ってブログ用のサーバーを自宅に立てているというケースもあるようですが、自分の場合は、自宅にある動画ファイルを外で携帯電話などを使って見られるようにするのが最初の目的でした。この時の個人的な経験は、後の「GLORIAS-HD」という動画配信システムを開発する上で役に立ったと思っています。

■「LAMP」あるいは「LEMP」について

弊社もIT企業ですので、社内に一通りのネットワーク環境やサーバーがありますが、自分自身は情シス部門の社員ではなく、そういったシステムについてはアンタッチャブルな立場ですので、サーバーとかネットワークとかの勉強や実践は、会社のシステムではなく、もっぱら自宅サーバーと宅内LAN上で行うことになります。
最初の自宅サーバーからずっとWindows一筋でしたが、今年はひょんなことからシングルボードコンピュータ（”ラズパイ”の愛称で知られる「Raspberry Pi」が有名ですが、自分のは別のSBCです）を使い始め、初めてLinuxでサーバーを構築しました。
ところで、オープンソース主体でWebサーバーとその応用サービスの構築に用いられる、Linux（オペレーティングシステム）・Apache（Webサーバー）・MySQL（データベース）・PHP（プログラミング言語）の4点セットを「LAMP」と呼ぶそうです。
MはMySQLからフォーク（分岐）されたMariaDBを指していたり、PはPerlやPython、あるいはPHPを含めて全部入りの場合もあるようですし、最近ではWebサーバーにApacheではなくNGINX（エンジンエックス）を用いる「LEMP（EはNGINXの実際の読み方から”Engine”のE）」も増えてきているようです。
いずれにせよ、LAMPないしはLEMPはWebを使って何かを実現する上で、ほぼファーストチョイスになっている定番の手段といえます。POLESTAR Automationのお客様が管理されている対象サーバーにも、LAMPやLEMPが結構多いことと思います。

■MySQL対応とサブスクリプション方式で「導入しやすさ」を追求

と、ここまで長い前置きになってしまいましたが、先日発表した通り、POLESTAR Automationがようやく、LAMPないしはLEMPの「M」である「MySQL」への対応が完了し、弊社内で動いているテスト・評価用のPOLESTAR Automationも、MySQLを用いての再構築が完了したところです。
テンプレートやジョブの格納と実行を筆頭に、POLESTAR Automationにおいてデータベース(DB)は大変重要な役割を担っていますが、これまでは有料のDBMSを組み合わせていただく必要があり、コスト面などからオープンソースDBを使いたい、というご要望を導入検討中のたくさんのお客様よりいただいていました。
LAMP/LEMPはもちろん、Windowsベースのサーバー上でも、おそらくMySQL（派生のMariaDBを含む）は最も広く使われているオープンソースDBであることは確実でしょう。
さらに、ライセンス体系についても従来のライセンス買い取り型に加え、新たに1年単位更新（初回のみ2年間のご利用前提）のサブスクリプション（定期利用権）方式を用意しました。MySQL対応と合わせて、POLESTAR Automation導入へのハードルはグッと低くなったのではないかと思います。
新しい年の始まりには、ぜひともPOLESTAR Automationによる運用業務の自動化をご検討いただければ幸いです。

さて、前回のコラムで年末のあいさつっぽいことを書いてしまっていますが、今回が本当に2017年最後のPOLESTAR Automationコラムとなります。
この1年、POLESTAR Automationプロダクトサイトをご覧いただき、ありがとうございました。
そして、来年2018年も引き続き、POLESTAR Automationはさらなる進化を続けてまいります。ご期待ください。



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

2017年の11月も今日で終わり、今年もあと1か月を残すのみとなりました。
今月は先月の「CEATEC JAPAN」に続き、同じ幕張メッセで行われた展示会「Japan IT Week 秋」に出展。2か月連続の展示会出展となりました。
そもそも今年は6月の「Interop Tokyo」を含めてPOLESTAR Automationを3回も展示会に出展したのですが、回を重ねるごとに弊社のブースに訪れるお客様が増えていったのには、スタッフ一同驚くばかりです。Japan IT Week 秋は弊社が今年出展した3展示会中、全体の来場者数は最も少ないのですが、弊社ブースへの訪問者数では最多という結果となりました。それだけ、運用自動化へのお客様の関心が今年1年で高まってきたという証左でもあるのでしょう。それにつれてPOLESTAR Automationの認知度も上昇していったのだと嬉しいのですが…

■運用業務を「標準化」するということ

実はCEATECとJapan IT Weekの間の時期に、弊社のPOLESTAR Automation担当エンジニアたちが開発元のエンジニアから1週間の研修を受ける機会がありました。 その一環として、実際にPOLESTAR Automationを使ってサーバー8,000台を運用しているデータセンターの現場を見せていただく機会もあったそうです。 このデータセンターでは、POLESTAR Automationの導入に先立ち、組織全体での取り組みとして、業務内容別に豊富な経験と高い専門性を持ったリーダーを任命しました。 その上で、従来の運用業務内容を検証したところ、従来の運用手順をそのまま踏襲するのではなく、POLESTAR Automation導入を機により効率の高い業務手順を確立した方が効果が高い、という結論に至ったとのことです。 つまり運用業務を全面的に見直した上で、業務のひとつひとつをPOLESTAR Automationのテンプレートに落とし込んで「標準化」するところからスタートしたわけです。そこには経験豊富で専門性の高い、部門別リーダーたちの経験が生かされたのはもちろんであり、ひとつひとつのテンプレートには、運用のベストプラクティスが凝縮されているといえます。

■今一度「属人化の排除」について

こうして、このデータセンターではPOLESTAR Automationを用いて運用業務の標準化を達成し、その後のサーバー増設や新しい業務の追加なども、効率よく実施することが可能となったそうです。
ところで、実際の運用現場では、知識と経験の豊富な担当者に重要な業務が集中してしまった結果、他の担当者に引き継ぐことができないレベルでその業務が専門化してしまっている、という話をよく耳にします。今年の3回の展示会でも、複数の来場者の方々からお聞きしました。
いわゆる「属人化」と呼ばれる現象です。
そうした担当者が体調を崩して業務に携われなくなったり、転職してしまったりすることは、運用業務における最大級のリスクとなります。たとえ高度なスクリプトや複雑な手順書を残して行ったとしても、それらを解釈して使いこなせる人がいなければ、無用の長物です。
効率化や省力化、ヒューマンエラーの撲滅など、運用自動化ツールの導入によって運用業務を標準化するメリットは計り知れませんが、中でも最も重要なもののひとつが、業務を特定の担当者に対する隷属から解放すること、つまり「属人化の排除」にあるといえます。

■既存の運用資産と人を無駄にせず、運用を標準化する

ところで、かつて運用自動化ツールは「属人化」対策の切り札、最終兵器のように持て囃されたこともありました。しかし、今年の3展示会で運用自動化ツール（特にオープンソースのもの）を導入されているという複数のお客様からお聞きしたのは、そうしたツールの導入によって、そのツールへの新たな「属人化」が生まれてしまった、という皮肉めいた体験談です。
運用自動化ツールには、RubyやPythonといったプログラミング言語や、YAMLのようなスクリプト書式の知識が不可欠なものもあります。これらは開発向けの言語として実績があったり、書式がシンプルで覚えやすかったり、という特徴もありますが、使うのに運用とは別のスキルが求められる、ということでもあります。
いずれにせよ、運用の人が新たにこうした言語や書式をマスターするか、開発と運用との連携を模索しなければなりません。言語や新しいスクリプトの読み書きに堪能な特定の担当者への業務集中、すなわち前述の『新たな「属人化」』が発生する可能性も高まります。
開発と運用の連携は「DevOps」として肯定的に捉える向きもありますが、運用現場の内部や周辺に、必ずしも開発経験者がいるとは限りません。
他の多くの運用自動化ツールと異なる、POLESTAR Automationならではの特徴のひとつに、特殊なスクリプト書式を用いていないことが挙げられます。POLESTAR Automationに標準装備されている200余のテンプレートは、各対象OSの標準的なスクリプト書式を用いて記述されたものです。UNIX/Linux系ならシェルスクリプト、WindowsではVBScriptなどです。
これは即ち、POLESTAR Automationなら、運用を担当しておられる皆様が日頃お使いのスクリプトがそのまま使える、ということでもあります。
POLESTAR Automationなら、既存の運用資産を無駄にしたり、人的資源を浪費することなく、属人化しにくい運用の自動化・標準化が達成できると、弊社では考えています。

以上、まだ年末のあいさつには時期が早いですが、今年3回にわたって出展した弊社の展示会ブースにご来場いただいた皆様に、このコラムの場をお借りして今一度お礼を申し上げます。
あと、来年の展示会出展スケジュールも、実は既に決まっています。こちらは会期が近づいてきたところで、またこのWebサイトを通じてご案内させていただきます。ご期待ください。



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

昨今、メディアにおける頻出ワードのひとつが「働き方改革」。セミナーやイベントも多数開催されていますね。

長時間・時間外労働の削減と労働生産性向上を目指し、多様かつ柔軟な働き方を模索する一連の動きは「ワークスタイル変革」と呼ばれてきましたが、昨年9月末に首相の私的諮問機関「働き方改革実現会議」が立ち上がった時点から、国の政策課題「働き方改革」となりました。

このタイミングで「働き方改革」が政策にまで浮上したのは、とりわけ2020年の7月に東京で開催されるオリンピック・パラリンピック（「オリ・パラ」と略すそうです）に向けた準備のひとつといえます。

会期中の混雑回避、ボランティアなど「オリ・パラ」運営に欠かせない人材確保の必要性に加え、かつて「エコノミック・アニマル」だとか「ワーカホリック（仕事中毒）」などと呼ばれて主に欧米世界からの非難の対象となった、日本の労働環境（特に長時間労働）に対するイメージの改善を図って行こう、という目的もあるのでしょう。

■IT運用業務における「働き方改革」とは？

主にホワイトカラーの業務において、「働き方改革」の中核として位置付けられるのが、場所に関係なく業務を可能にする「テレワーク」です。テレワークといえば「在宅勤務」を真っ先に連想される方が最も多いかと思いますが、自宅以外の場所（コワーキングスペースなど）で行うリモートワーク、モバイルワークなども、テレワークのバリエーションといえるでしょう。

通勤・移動時間の節減を通じ、時間あたりの労働生産性向上を図ろうというのがテレワーク推進の主な目的ですが、前回の本欄でも取り上げた「BCP対策」としても有用です。テレワークの可能な環境、つまりどこにいても仕事のできる基盤が整備されてさえいれば、事業所や交通機関が災害に遭ったり、「オリ・パラ」などでオフピーク通勤や移動の自粛などが求められることがあったとしても、業務を滞りなく行うことが可能となるでしょう。

しかし、ITシステム・サービスの運用業務においては、テレワークの全面展開は困難と思われます。システムが膨大すぎて外部から管理するのが難しい上、ハードウェアにまつわる物理的な作業やセキュリティなどの都合もあり、現場、つまりサーバールームでの作業がどうしても主体にならざるを得ないからです。

IT運用業務における作業時間の大半は、目視点検やコマンドの入力に割かれ、マンパワーの多くもそこに投入されます。24時間・365日休みなく動き続けるシステム・サービスの運用を維持するため、深夜・早朝や休日の勤務も発生しがちです。

時には、ヒューマンエラーによるコマンド投入や操作ミスも発生するでしょう。ミスの内容にもよりますが、ヒューマンエラー要因を含む障害からのリカバリーには、通常の作業よりも多くの時間を要するのが普通でしょう。

そんなIT運用業務の改善に役立つのがPOLESTAR Automationで、導入により業務の標準化が促進され、作業効率・労働生産性の向上やヒューマンエラーの原理的な撲滅が可能となり、休日・時間外業務の劇的な削減につながる…というのは、私たちがこれまでずっと訴え続けてきたことですが、これこそIT運用業務における「働き方改革」の実現にほかならないでしょう。

運用業務の生産性向上を進める上で、何よりも重要かつ最も効果的なのは、「自動化システムに任せられる業務はすべて任せてしまう」ことなのですから。

■POLESTAR Automation「ネットワーク自動化機能」の概要

さて、去る11日、POLESTAR Automationへの「ネットワーク自動化」機能追加に関するプレスリリースを配信しました。 POLESTAR Automationでの、ルーターやL2/L3スイッチといったネットワーク機器の制御を通じた自動化の実現については、昨秋の製品発表以来、弊社の営業がお客様を回ったり、あるいは展示会などに来訪されたお客様の声を伺ったりする中で、特に多くのご要望をいただいていたもののひとつです。

まず、ワークスペース（画面左側）に「ネットワーク」という項目が追加され、ルーターやL2/L3スイッチを登録すると、機器ごとのステータスが見られるようになりました。

また、「ネットワーク」のワークスペース（または[構成]-[ジョブ作成]メニュー）には、ネットワーク機器向けの自動化ジョブを作成するための「ネットワークスクリプトジョブ」という項目が追加されました。

これまでのサーバー向けのジョブ作成と同様、わかりやすく扱いやすいと評判のウィザード形式でコマンド入力や対象機器の指定を行うだけで、簡単にネットワーク機器向けの自動化ジョブが作成できます。

■ネットワーク自動化はエージェントレスで実現

ところで、これまでPOLESTAR Automationでは、サーバーに対する各種の自動化を「エージェント方式」で実現してきました。管理対象サーバーに「エージェント」と呼ばれる小さなプログラムを組み込んでデータやコマンドをやりとりするこの方式にさまざまなメリットがあることは、以前から再三ご紹介してきましたが、ルーターやL2/L3スイッチなどのネットワーク機器に対しては、エージェントのような常駐プログラムを外部から組み込むのは無理です。

そこで、今回開発したネットワーク機器の制御用には、SSHなどを利用し、POLESTAR Automation（管理サーバー）からルーターやスイッチに対してコマンドを発行・送信する手法を開発し、適用しています。
で、鋭い方ならお気付きでしょう。この手法って、実はネットワーク機器以外にも応用できるんじゃないの？ と…

今回のネットワーク自動化対応により、「自動化システムに任せられる業務」の幅がさらに広がったPOLESTAR Automation。きっと御社IT運用業務の「働き方改革」にもお役に立てると思います。
ネットワーク自動化機能を搭載した最新のPOLESTAR Automationは、10月3日から6日までの「CEATEC JAPAN 2017」で初公開します。ぜひともCEATECワイドテックブースにご来場ください。



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

前回6月から久々となる今回のコラムも、前回に続いて展示会の話題です。
コーポレートサイトの方では4日付けで発表済みなのですが、おかげ様で大盛況に終わった6月の「Interop Tokyo 2017」出展に続き、POLESTAR Automationがまたも展示会に出展することになりました。
しかも10月の「CEATEC JAPAN 2017」、11月の「Japan IT Week 秋（クラウドコンピューティングEXPO）」と2か月立て続け、さらに2回続けて（Interopから数えると3回連続で）会場は幕張メッセです。今回は、まずCEATEC出展についてのご案内です。

CEATECという展示会は、かつては「エレクトロニクスショー（エレショー）」という名称で、最初の前身から数えると60年近くもの非常に長い歴史があり、来場者数も昨年で14万人以上と、国内のIT系展示会としては屈指の規模です。
長い間「エレショー」「CEATEC」といえば電子機器、それもBtoBよりもコンシューマー寄りの、いわゆる家電製品などがメインの「電子立国・日本」を象徴するイベントとして知られてきましたが、産業構造の変化などに伴い、昨年（2016年）からは「サイバーフィジカルシステム（CPS）とモノのインターネット（IoT）」の展示会として、スマート社会に欠かせない製品・ソリューションを展示するイベントへとコンセプトが変更され、今年は新生CEATECとして2年目を迎えます。

ワイドテックにとって、今回は初めてのCEATEC出展となり、しかもPOLESTARAutomationと、弊社のもうひとつの主力製品分野である電話関連ソリューションが揃い踏みする出展というのも初めてです。
POLESTAR Automationに関して今回の目玉はというと、実は4日のリリースにはしれっと記載済みなのですが、待望の「ネットワーク機器自動化機能」が搭載されることになり、CEATECがその最初のお披露目の場となります。この機能の詳細については後日またご紹介しますが、とりあえずネットワーク機器自動化の搭載は、決定事項です。

さて、ちょっと余談になりますが、先日、なぜか「BCP対策」という検索ワードでこのサイトに来訪してきた方がおられました。
BCPはBusiness Continuity Planの略、日本語では「事業継続計画」などと訳されますが、毎年9月1日の「防災の日」が意識される時期だったので、その影響もあったのでしょう。確かにPOLESTAR AutomationでIT運用を自動化、テンプレート化することは、災害を含む各種障害からの迅速な復旧を可能にする、広い意味でのBCP対策ソリューションといえなくもないですが、少なくとも当サイトには、今回のコラムが載るまで「BCP」という単語を登場させたことは、一度もありません。

ただし、弊社全体に目を向けると「BCP対策」は非常に重要なキーワードです。
電話転送自動切替システム「AUTOWARP」、クラウド型の電話転送サービス「転送録」など、BCPに直接役立つソリューションを提供しているからです。
このうちAUTOWARPは、発売から今年でちょうど10年を迎えた、オンプレミス型のロングセラー製品です。これまでに最大規模のお客様が5,000回線、2番目に大きなお客様は4,000回線分の切替設備を導入されているのですが、前者のお客様には、まさにBCP対策として採用していただきました（ちなみに後者のお客様は、ほぼ毎日切り替えておられます）。つまり、非常時に電話回線をバックアップ用の回線網に切り替えるのが目的で、年に数回のBCP訓練（切替テスト）を行う以外、普段は動いていないわけです。
このBCP用に導入された史上最大回線数のAUTOWARPが、過去に一度だけ、テスト以外で実際に稼働したことがありました。そう、東日本大震災の時です。
それまで幾度か繰り返されてきたBCP訓練の通り、AUTOWARPは震災当日、5,000回線を遅滞なく自動的にバックアップ回線に切り替え、期待された役割を果たすことができました。

今回のCEATECには、そんなAUTOWARPや、そのクラウド版としてスタートした「転送録」、それに両電話転送系製品のチームが新たに開発し、今月中に満を持して発表予定の画期的な新サービス（こちらもBCPに最適）も、会場でご覧いただけます。
これらの電話関連製品/サービス、そして我らがPOLESTAR Automationをひっくるめて、今回初出展となるワイドテックブースのテーマは、

「自動化(Automation)」

です。
CEATECのワイドテックブースは、幕張メッセ第1ホール入口の階段を降りて左手すぐ、という非常にわかりやすい場所にあります。
どうか、本コラムをご覧いただいた皆様も、ぜひともご来場いただければ幸いです。



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

6月7日から9日までの3日間、千葉市・幕張メッセで開催された国内最大のICTイベント「Interop Tokyo 2017」に、POLESTAR Automationを出展しました。
POLESTAR Automationの展示会出展は2回目だったのですが、ブース規模を前回の2倍として臨んだ今回は、ご来場いただいた方の数がなんと前回の 5倍 を超え、正直に言って予想を上回る大盛況となりました。

実は、自分はPOLESTAR Automationがまだ企画段階にあった昨年も、Interopには行かせていただいたのですが、昨年は運用自動化製品の出展がほとんどありませんでした。今年は弊社以外にも複数の製品が出ており、他社さんのブースをチラッと覗かせていただいた限りでは、どちらも結構盛況だったように思います。運用自動化が注目分野になりつつあることを、改めて実感させられました。

さて、今回はPOLESTAR Automationの強みをご紹介するシリーズの第2弾として「導入の早さ」、すなわちIT運用を自動化すると決めてから、実際に自動化運用を行うまでの作業手順の簡単さ・手軽さ、期間の短さについてまとめてみます。

1. 豊富なレディメードのテンプレート

まずは200種類超という「テンプレート」の豊富さです。
テンプレートについては、以前のコラム「自動化の手順書はどう作るか？」でも言及しましたが、POLESTAR Automationにおけるテンプレートとは、ある業務を行うためのスクリプトの集合体です。
そもそも、運用自動化の導入から運用開始までの過程で、もっとも長い時間と手間を要するのが「現状の運用業務の分析」と「自動化ソリューションへの落とし込み」つまりスクリプティングなどと呼ばれる準備作業です。
POLESTAR Automationでは、基本提供されるテンプレートをご利用いただき、IPアドレスのような環境要素をわずかに手直しするだけで、多くの業務はそのまま自動化できるようになっています。しかし、既存のテンプレートではカバーしきれないものもあるかと思いますので、その際は弊社でカスタムテンプレートの開発にも応じさせていただきますし、もちろん、お客様の方で直接テンプレートを作成していただくことも可能です。
ちなみに、POLESTAR Automationが開発された最初の時点では、テンプレートは1つもなかったのですが、開発の過程で最初のお客様の業務分析を通じて多数のテンプレートが作成され、その後の構築案件では、そうしたテンプレートを使い、短期間で構築を終わらせることが可能となりました。中には、導入決定から自動化運用開始まで1か月程度で完了した事例もあるそうです。

2. 導入の手軽さでも有利な「エージェント型」

Interopにご来場いただいた皆様から一番多かった質問は「エージェント」に関するものでした。なんと半分以上もの方が、エージェントについて何らかの言及をされていたように思います。
運用自動化製品には大別して「エージェント型」と「エージェントレス型」があり、POLESTAR Automationでは前者を採用しています。
エージェントレス型は、SSHやSNMPといった既存のプロトコルを通じて構成情報を取得したり、コマンドやスクリプトを投入・実行したりするものです。文字通りサーバーにプログラムを追加で導入する必要がないので、耳当たりがよいようです。比較的近年に商品化された自動化製品は、エージェントレス型が多いと思います。
ただ、Interopでは、実際にエージェントレス型の導入経験をお持ちの複数のSIer様から、SSHのアカウント設定など、最初に行う作業が意外に大変だった、という声もお聞きしました。
一方、エージェント型の運用自動化ソリューションであるPOLESTAR Automationでは、「エージェント」と呼ばれる小さなプログラムを管理対象サーバーにインストールし、そのエージェントが管理サーバーと通信することで、自動化タスクを実行します。
エージェント型は、エージェントレス型に比べて機能やセキュリティの面でもいろいろなメリットがあるのですが、その辺のご紹介は別の機会に譲るとして、今回のテーマである「構築期間の短縮」にも大いに役立っています。
管理対象サーバー側で行う設定は「エージェントのインストール」、本当にこれだけ。あと、ファイアウォールを導入している場合はエージェントとマネージャーサーバー間の通信に必要なポートの開放も必要ですが、使用するポートは1個だけです。
どこまでもシンプル。管理対象のサーバーが増えてもエージェントのインストールだけで済み、検索機能により管理サーバーへの登録も簡単です。

3. Webブラウザで管理できて、しかも扱いやすいGUI

あと、テンプレート開発を含む管理用のユーザーインターフェース(UI)がWebブラウザであることも、POLESTAR Automationのメリットでしょうか。
他社さんの自動化製品では、管理用端末に専用のGUI版管理ツール（たいていWindows版だけ）をインストールして使うのが一般的ですが、わざわざツールをローカルにインストールすることなく、Webブラウザを開いてそのままサクッと使えるのは便利だと思います。
このGUI、Interopにご来場いただいた皆様からも、直感的でわかりやすいとの声を多数いただきました。UIのわかりやすさは習熟期間の短縮や、自動化開始後の運用管理をスムーズに行うことにもつながるはずです。

今回のInteropは、多くのお客様とのダイレクトなコミュニケーションの機会として、今後のPOLESTAR Automationの営業やマーケティング活動についても、さまざまなヒントを得る場にもなりました。

ご来場いただいた皆様に、改めて感謝いたします。