作成日 | 2020/01/07 |
---|---|
更新日 | - |
本記事の対象機能
運用管理製品というと広い範囲を指し示すので、ここでは「監視」と「ジョブ管理」の2つに絞って解説を進めます。
◆ターゲットとなる運用管理機能
監視
ジョブ管理
何故、製品移行が必要か
運用管理製品においては、製品の見直しの契機があります。その見直しの契機で、製品移行を判断せざるを得ない場合があります。そこで、よくある製品の見直しの契機と、その際の製品移行を判断する理由・必要性について順に見ていきましょう。
管理対象システムの統合・リプレースの契機
個々のシステム更改(リプレース)では、更改対象のHW機器やNW機器、OS、ミドルウェアに対応した運管理製品を選定する必要があります。利用している製品が対応していない場合は、製品移行が必須です。
複数のシステムの統合のタイミングでは、複数の運用管理製品で運用を行っていたものを1つの運用管理製品へ集約します。(個々の運用管理製品の視点では移行になります)
運用管理製品のサポート期間終了の契機
利用している運用管理製品のサポート期間の終了に伴い、現状利用している製品をバージョンアップするか、他製品に乗り換えるかを検討します。製品や、サポート品質、サポート期間に不満がある場合は、その要件を満たす製品への移行を検討します。
運用費用(ライセンス・保守サポート)の見直し・削減の契機
会社方針などで運用費用の見直しを行うケースがあります。システム構築時のイニシャルコストから、サービス開始後のランニングコストまでに渡り、高価な製品を使っている場合はより安価なものへ、日々工数が掛かっている場合は簡単に運用できる製品への移行が必要になります。
仮想化・クラウド環境の利用・システム移行の契機
既存のオンプレミス環境から仮想化・クラウドへのプラットフォーム移行の契機では、クラウドに対応した製品選定が必要になります。
何が、製品移行の課題か
運用管理製品を移行する際には、多くの課題を検討する必要があります。ここでは、製品移行に関する課題と注意事項を紹介します。
そして、Hinemosによりそれらの課題が簡単に解決できることを解説します。
◆移行で検討すべき課題一覧
ジョブ定義の移行
製品の選定順
運用性
コスト・コスト・コスト
クラウド対応
可用性
オペレータの抵抗
移行判断と移行設計
1.ジョブ定義の移行
製品移行において最初に検討すべき課題が「ジョブ定義」の移行です。このジョブ定義は、ジョブネット・ジョブフローを定義した「ジョブフロー定義」と、個々のジョブの中で実行される「シェルスクリプト」に分けて考えます。
シェルスクリプトの移行
移行前後で動作プラットフォームが同じ場合は、大きな割合で流用が可能です。しかし、プラットフォームが変更となる場合は、次のような状況(流用が難しい)が発生します。
- シェルスクリプトの作り直し
プラットフォームが違うと動作するシェルも異なる(kshからbash等)ので、シェルスクリプト自体の作り直しが発生する可能性があります。
- 業務フローからの見直し
シェルスクリプトだけではなく、1つ1つのジョブで実行する処理単位からジョブフロー定義の再検討が必要になる可能性があります。
このプラットフォームが変更となる場合の「シェルスクリプトの移行」は、機械的に実現が難しいため、新規システムの設計・検討として進めるのが一般的です。
ジョブフロー定義の移行
次に業務フローそのものであるジョブフロー定義の移行を考えます。数が少ないうちは手作業でも可能ですが、ジョブが数千~数万となると機械的に実施しないと、作業コストだけでなく品質にも影響があります。大前提で、移行先の製品に移行元と同等なジョブ管理機能を保持している必要があります。
この「ジョブフロー定義の移行」に対して、Hinemosでは「他運用管理製品からの移行サービス」を提供しています。他製品のジョブフロー定義をHinemosのジョブ定義に変換するサービスを提供しています。
課題・注意事項 | ・・プラットフォームが変更となる場合は、シェルスクリプトの全面的な作り直しや業務フローの見直しが発生する |
---|---|
Hinemosによる解決 | ・他運用管理製品からの移行サービスを提供 |
2.製品の選定順
製品の選定順は検討が漏れやすく、気づいた時にはもう遅いという課題です。
監視機能はコモディティ化しており参入の敷居が低い分野のため、多くの監視製品があります。これと比べて、ジョブ管理製品は製品数が少なく、動作要件の制約も多く、そして一般に監視製品より高価です。よって、全体最適を考えるために最初に選ぶべきは選択肢の少ないジョブ管理製品です。
この課題に対して、Hinemosは様々な環境で動作するジョブ管理機能を保有しているためジョブ管理製品として有用な選択肢の1つとなります。併せて監視機能も具備しているため、Hinemosを選択するだけで投資対効果の高い構成になる事が分かります。
課題・注意事項 | ・監視機能はコモディティ化、選択肢が多いので最後に選択 ・ジョブ管理製品は選択肢が少なく高価なため最初に選定すべき |
---|---|
Hinemosによる解決 | ・Hinemosを最初に選ぶと他の課題も併せて解決できる |
3.運用性
運用性にて、一番シンプルで全員に影響ある課題が、運用に必要となる「製品数」です。
一般的に、運用管理の製品は単機能ツールが多いです。要件に合わせて取捨選択が出来るメリットの反面、製品別の設計や製品間連携が必要になります。これに追加して、仮想化やクラウドといったプラットフォームへのシステム移行の場合には、プラットフォーム固有の管理ツールも必要になることで、運用に必要になる製品の数が増えてしまうという課題も生じます。
この課題に対して、Hinemosではワンパッケージで統合運用管理に必要な機能を持っており、プラットフォーム固有の運用を支援する機能があるため、製品数が増加どころか減らすことも可能です。
課題・注意事項 | ・運用性を上げるには製品数を増えないようにすべき ・単機能ツール、プラットフォーム固有のツールがある |
---|---|
Hinemosによる解決 | ・Hinemosはワンパッケージで統合運用管理に必要な機能を保持 |
4.コスト・コスト・コスト
コストといっても様々なコストの課題があるので1つ1つ見ていきます。
ライセンスコスト
一番わかりやすいものが、製品のライセンス及び保守サポートにかかるコストです。監視製品では主に監視対象の台数で、ジョブ管理製品ではCPUコア数といったスケールファクタで費用が増減します。
見積コスト
最近のシステムでは無視できないのが見積コストです。仮想化・クラウド環境では構成変更が柔軟にできるため、旧来のライセンス体系の製品では、環境変更の都度の見積もりが必要になったりします。また、設計前では判断が難しい性能問題に伴う環境変更など、見積もった営業と現場のSEとがせめぎ合う事もある非常に厄介なものです。
運用設計・運用作業コスト
サービスイン前では設計・試験の人的コスト、サービス開始後は日々の運用における人的コストです。設計による影響が大きい部分です。
移行コスト
移行にかかるコストです。詳細は「移行判断と移行設計」で触れています。
この課題に対して、 Hinemosではサブスクリプションモデルにより、シンプルで扱いやすいライセンス形態になっています。Hinemosのサブスクリプションのメニューでは、監視対象の台数とCPUコア数のスケールファクタがなく、Hinemosマネージャの台数のみで費用がスケールします。再見積もりが不要という営業としても現場のSEとしても扱いやすい製品です。またHinemosでは環境構築、業務、運用の3軸の自動化機能を持っているため、様々な自動化を推進できます。
課題・注意事項 | ・ライセンス、運用設計・運用作業、移行、見積もりコストが高い |
---|---|
Hinemosによる解決 | ・サブスクリプションメニューは安価かつ見積もりが楽 ・Hinemosによる運用の自動化の促進が可能 |
5.クラウド対応
更改するシステムがクラウド上に構築される場合、運用管理製品もクラウド対応が必須になりますが、これには次の課題があります。
クラウド上で動作する
運用管理の製品分野において、クラウド上の動作サポートはかなり遅れていました。実際に、未だにクラウド上での動作サポートが明確でない製品もあります。特に、運用管理マネージャの可用性構成の可否は大きな問題です。
クラウド管理の専用機能がある
クラウドにはクラウド特有の運用があるため、旧来の機能とは別の支援機能が必要です。これを作りこみで対応をするとアジリティも下がり、維持メンテナンスの人的コストが膨れ上がります。
この課題に対して、Hinemosでは多種多様なクラウド上で動作します。新しいVM・クラウド環境にも随時対応します
また、VM・クラウド管理機能による専用の運用機能を提供しているというメリットがあります。複数のVM・クラウド環境を俯瞰して運用管理ができます。
課題・注意事項 | ・クラウド上で動作するか ・クラウド管理の専用機能を持っているか |
---|---|
Hinemosによる解決 | ・様々なクラウドで動作する ・VM・クラウド管理機能による専用の運用機能を提供 |
6.可用性
ここでの可用性とは、運用管理製品自身が無停止で動作する事を指します。
将来的にでもハイブリッドクラウド環境におけるシステム構築を考えた場合、一般的なクラスタミドルウェア+共有ディスク方式では実現が難しいです。そのため、クラウドのサービス(ロードバランサ等)を使った、環境特有の可用性構成が提供されるケースがあります。しかし、クラウドのサービスを使った可用性を組む場合、次のような課題が上がります。
- 使用するサービスの深い知識が必要
- 障害発生時の切り分けに、クラウドのサービスの確認が含まれる
この課題に対して、Hinemosではミッションクリティカル機能により、どのプラットフォームでも同じアーキテクチャで可用性機能を提供します。
課題・注意事項 | ・当該サービスの深い知識が必要 ・障害など発生した際にサービスの正常性を点検するのはユーザ ・動く動かないの他に誰が何度どこまでサポートするかが重要 |
---|---|
Hinemosによる解決 | ・ミッションクリティカル機能によりどこでも同じ可用性構成 |
7.オペレータの抵抗感
製品の乗り換えで一番影響がある人は、日々の運用を実施するオペレータの方々です。毎日確認する画面が変わること、製品の仕様や機能、用語が変わることは、ダイレクトに業務に影響が出ます。新しい製品へ乗り換える際の学習コスト、手順書更新のコストが求められますが、机上で進めるには限界があります。
この課題に対して、まずは新しい製品を触ってみる機会を作ることになります。
まずは触ってみる(評価版やトレーニングコース受講)
Hinemosはオペレータ向けに作られたシンプルなGUIを提供しています。難しい作りこみはなく、GUI操作でサクサクと運用タスクを実施できます。評価版を使用してみたりトレーニングコース受講により、現在の運用がどのように変わるかのイメージが付きやすくなります。
また、一気に製品の乗り換えではなく、スモールスタートで実施することが重要です。
スモールスタートで個別システムから導入する
例えばオペレータが見る運用管理端末があり、そこから部署別の複数のシステムを見ているようなケースでは、末端の個別システムから移行を進めます。
そうすることで、オペレータが常時査証する画面は暫くの間は変更がなく、Hinemosの知識を得ながら全体コストの低減が図れます。もちろんHinemosから別運用管理製品への通知といった機能は簡単に実現できます。
課題・注意事項 | ・「画面が変わる」ことによる影響範囲の見積もりが難しい |
---|---|
Hinemosによる解決 | ・評価版やトレーニングコース受講できる ・親子連携も簡単に実現できるのでまずは末端から移行開始 |
8.移行判断と移行設計
製品移行可否や実現性の判断、必要となるコストの的確な見積りが難しいです。移行元の製品ベンダーには相談できないですし、移行先の製品に相談しようとしても「現状がこうなっている」を適切に伝えないといけない、という課題があります。
もし機能の有無にて採用を判断したとしても、実際の作業において製品仕様差分を考慮した運用の設計が難しいという現実があります。
この課題に対して、Hinemosでは次のサービスを提供しています。
アセスメントサービス
既存システムからのHinemosへのマイグレーション可否を明確にできるアセスメントサービスを行っています。既存ジョブ定義、設計情報を提供いただければアセスメントレポートを作成し、マイグレーションの実現可否を報告いたします。
他運用管理製品からの移行サービス
お客様のご要望をお伺いし、現在お使いの商用運用管理ツールからHinemosへ移行を支援いたします。
課題・注意事項 | ・製品移行可否や実現性の判断、必要となるコストの的確な見積りが難しい ・製品仕様差分を考慮した運用の設計が難しい |
---|---|
Hinemosによる解決 | ・移行におけるアセスメントサービスを提供 ・他社製品からHinemosへの移行サービスを提供 |
製品移行におけるHinemos導入効果
製品移行においてHinemosを導入した場合の導入効果を紹介します。
1.システム管理の統合
Hinemosは、アプリケーション/ミドルウェア・OS・仮想化/クラウドといった、 すべてのレイヤの一元管理を実現します。
2.データの収集と活用による運用自動化
収集した過去データを基に、将来発生する異常の予測が可能です。予測された結果に基づく対応も、Hinemosで自動化が可能です。
3.運用コストの削減
システム状態の最適化、運用の定型化・自動化を実現する事により、「インフラコスト」「作業コスト」を低減します。
実際のプロジェクトでの試算結果ですが、5年間のシステム全体のコストを、従来使用していた製品より数分の1となったことで、Hinemosを採用頂いた事例もありました。
Hinemos移行事例
関連サービス
お問い合わせ