ページの本文へ

Hitachi

企業情報研究開発

  • 写真「飯塚 大介(いいづか だいすけ)」
    飯塚 大介
    (いいづか だいすけ)
    主任研究員
  • 写真「増田 峰義(ますだ みねよし)」
    増田 峰義
    (ますだ みねよし)
    研究員
  • 写真「和田 清美(わだ きよみ)」
    和田 清美
    (わだ きよみ)
    研究員

近年、システム運用は複雑化の一途をたどっています。このような状況下で、24時間365日、システムの安定稼働を支えるべく奮闘している運用管理者をサポートしたい。運用管理の現場の声に応えたい。そんな開発者の思いから生まれたJP1製品の二つの機能、JP1/IT Service Level Managementの「サービスレベル監視機能」とJP1/Automatic Operationの「運用自動化機能」についてお話を伺いました。

(2013年3月27日 公開)

運用管理の現場の声を製品に

運用管理とは、具体的にどのような業務なのでしょうか。

写真「飯塚 大介(いいづか だいすけ)」

飯塚身近な例で言うと、ネットショッピングのようなサイトを、24時間365日、安定して運用するための業務ですね。企業の中では、販売管理や資材発注などの重要な社内システムを、規定どおり問題なく動作させることが主な業務になります。

運用管理業務は、「定常業務」と「非定常業務」に大きく分けられます。「定常業務」は、新しいサービスの公開や、バックアップ、システムの稼働監視、ログファイルの監視などです。「非定常業務」は、ハードウェアが壊れてサービスができない、アプリケーションが異常を起こしている、または異常を起こしそうなどといった、予測できない状況に対応することです。

今回、JP1のV10でJP1/ITSLM(JP1/IT Service Level Management)とJP1/AO(JP1/Automatic Operation)という製品をリリースしたのですが、主に「定常業務」で使われるのがJP1/AOの運用自動化機能です。毎日行う作業を間違いなく、かつ迅速に行えるようにサポートします。

一方、主に「非定常業務」で使われるのはJP1/ITSLMのサービスレベル監視機能です。障害を未然に防ぎ、もし障害が発生したら迅速に解決できるようにサポートします。

サービスレベル監視機能と運用自動化機能が開発されたきっかけを教えてください。

飯塚運用管理の現場でヒアリングしたり、和田が実際にSEさんと運用管理業務を経験する中で、さまざまな現場の声を聞きました。そこで、運用管理の作業を、「楽に」「間違いなく」「障害を発生させない」ようにできる、万が一の場合も「迅速に解決」できるような運用管理機能が求められているとわかりました。そんな現場の声に応える機能を開発することが、我々の使命だということに気づいたんです。

実際にご自身で運用管理業務を経験されたのですか。

写真「和田 清美(わだ きよみ)」

和田はい。いままでは、良いと思った機能をリリースしても、実運用では需要がないということになってしまいがちでした。そこで、運用管理の現場ではどのようなことをやっていて、何が必要なのかということを知るために、2年間、SEさんと一緒に運用設計や実際の運用に携わって勉強させていただきました。

それまで、開発側の自分たちは、いままでになかったビックリするような機能を出せば喜んでもらえると思っていたんです。でも、現場では、めったに発生しないエラーのためのすごい機能より、日常的に簡単に、いま何が起こっているかを確認できる機能の方が必要とされていることがわかりました。

運用管理製品は一般的にたくさんの機能があるため、いろんなことを設定しなくてはいけなくて、導入時に手間が掛かる、またスキルのある人しか使えなくて困っているという声も伺いました。

そこでJP1/ITSLMでは、運用管理の状況を簡単に確認できるように、スキルのある人でなくても使えるようにしました。そうして開発したのが、「サービスレベル監視」という機能です。

サービスレベルの"いつもと違う"を監視

JP1/ITSLMで監視する「サービスレベル」とはどのようなものですか。

写真「増田 峰義(ますだ みねよし)」

増田サービスレベル」というのは、システムがどれだけ健全に動いているかを表したものです。そのシステムをユーザが快適に使えているか、バックアップなどの運用が問題なくできているか、ということを示すレベルですね。

JP1/ITSLMのサービスレベル監視機能では、性能を基にサービスレベルを計測しています。システムが安定して稼働し続けているか、サービスの応答時間がどれだけ掛かっているか、という性能をモニタリングして計測し、このシステムのサービスレベルは○なのか×なのか判断します。

例えば、99%のアクセスに対して3秒以内に応答しているという集計結果があれば、そのサービスとして応答時間が3秒というのは妥当なのか、ということを評価しているんです。

図1 サービスレベル監視機能
サービスレベル監視の概念図

妥当かどうかを、どのように評価しているのでしょうか。

写真「和田 清美(わだ きよみ)」

和田サービスレベルが"いつも"と違う状態に変わったかどうかを監視して、評価しています。例えば、アクセス数が増えていないのに応答時間が遅くなったとか、リソースの使用状況が"いつも"と違うとか。

この"いつも"を「ベースライン」と呼んでいますが、ベースラインを超えると検知して、「いつもと違うから問題があるのでは?」と知らせます。ベースラインでは、アクセス数に応じて、100人がアクセスしていたら応答時間は2秒くらい、500人だったら3秒くらい、というように、状況に応じて自動的にしきい値を連動させます。

このような、新しいしきい値というか、自動でしきい値を設定して監視するのが、JP1/ITSLMのベースライン監視です。

図2 ベースライン監視の仕組み
ベースライン監視の仕組みの概念図

増田ベースライン監視は、お医者さんのレントゲン写真の見方みたいな感じですね。お医者さんは健康な人のレントゲン写真が頭の中に入っていて、それと見比べることで、どこに患部があるか見分けています。

ベースラインというのは、健康な人のレントゲン写真みたいなものです。JP1/ITSLMでは、自動的にシステムの正しいふるまいを学習し、それとどこが違うかということを常に見比べて、どこに問題があるかを知らせます。

飯塚お医者さんのようなスペシャリストでなくても、"いつも"と違うところがわかるようにしているんですね。しきい値は、下げ過ぎると警告がたくさん出てしまうし、上げ過ぎると性能障害が起こっても気づけなくなる。ですから、設定するには知識と経験が必要でした。そこを、代わりにやってあげましょう、というのがベースライン監視です。

ドリルダウンとグラフで迅速に解決

ベースライン監視で検知した問題を、どのように解決するのでしょうか。

写真「増田 峰義(ますだ みねよし)」

増田JP1/ITSLMでは、「ドリルダウン」で問題を迅速に解決できるようにしています。ドリルダウンとは、異常が発生した原因や場所を特定するために、システムを構成している要素を1段ずつ掘り下げていって、OS・サーバ・ミドルウェアのどれが問題なのか切り分ける作業です。

従来は、ある程度スキルのある人が、時間を掛けて問題を追い詰めていました。ですが、問題が発生したときには、いかに簡単に手早く問題のところにたどりつけるかということが重要になってきます。これに対応するために、ツリー形式で表示するドリルダウン画面を用意しました。

図3 ドリルダウン画面
ドリルダウン画面図

画像を拡大する

和田JP1/ITSLMのドリルダウン画面では、マークを頼りに掘り下げていきます。マークは、ベースラインに違反しているいちばん下の結果を、どんどん上に伝播(でんぱ)させて表示しているものです。マークを頼りに、サービスを構成しているホスト、その中にある監視項目・・・と、掘り下げていくことができます。

一つのサービスに対してホストが10台以上あったり、一つのホストに対して監視項目が100個以上あったりと、大変数が多いのですが、マークを頼りにクリックしていけば、いちばん問題があるところに簡単にたどりつけます。

右側には、いくつかグラフが並んでいますね。

和田サービスやシステムなど、いろいろな項目のグラフをすべて同じ時間軸で並べられるようにしています。

この、"同じ時間軸で並べる"というのがポイントなんです。このようにグラフを見ることで、例えば、平均応答時間がおかしくなったときにいちばん影響しているのはCPU使用率であるといったことが、視覚的にわかるんですね。

いままで運用管理の現場では、性能監視製品からデータを吐き出し、表計算ソフトウェアなどに入力し、加工してグラフを並べたり重ねたりしていたんです。それを、ボタン一つでできるようにしました。

効率よく迅速に確認できるので、障害が発生したとき、または障害の予兆があったときでも、気持ちに余裕を持って対応できるようになります。

運用自動化で属人性を排除

運用管理の自動化については、どのような声があったんでしょうか。

写真「飯塚 大介(いいづか だいすけ)」

飯塚業務そのものを自動化する仕掛けは以前からありました。例えば、給与計算や資材発注のような、決まった業務手順の自動化には対応できていたんです。

ところが、バックアップや新しいシステムの公開といった運用管理業務については、いままではスキルのある人が手動かスクリプトなどを使ってやっていました。ですから、その人が異動などでいなくなると現場が回らなくなってしまう、という大きな課題がありました。

そんな属人性をできるだけ排除し、基本的な業務知識のある人なら誰でもできるようにしたい、という声に応えて、ここ3〜4年くらいでRBA(Run Book Automation)という運用管理技術が出てきたんです。このRBAという技術を取り入れたのが、JP1/AOの運用自動化機能です。

RBAとは、どのような技術ですか。

飯塚従来、操作を手動で行う場合は、文書に書かれている作業手順を見て、運用管理者が画面を操作したり、操作を書いてあるスクリプトを実行したりしていました。

これに対してRBAでは、アイコン(部品)を画面に置いていくことで作業の順番を設定します。作業や流れを示す部品を選んで絵を描いて、パラメータやアプリケーションを設定して実行すれば、自動化できるんです。

また、RBAでは実行時にどの経路を通ってきたかがわかります。「この経路を通って異常終了した場合は、この原因が考えられる」ということをマニュアルにしておけば、トラブルシュートが比較的スムーズになるという利点もあります。このようなRBA製品を使って、運用管理を楽にしたいというニーズが増えてきました。

図4 RBA製品(JP1/AO)での設定例
RBA製品(JP1/AO)での設定例の図

製品化するにあたって、特に工夫した点はありますか。

飯塚当初は、運用を全部自動化すれば便利だと思っていたんです。でも、現場の声を聞いてみたところ、すべてを自動化するのは「怖い」という声があったんですよ。これまで人間が確認していたところをすべてシステムに任せてしまって、万が一システムが壊れたまま暴走してしまうようなことがあったら怖い。だから、大事なところは人間が確認したい、と。

運用管理者が不安に思う気持ちもわかります。そこで、JP1/AOでは、いったん停止して「こんな結果が出ましたがどうでしょう?」と確認する手順の部品を用意しました。まずはこの部品を使って実際に運用してみて、ここは人間が確認しなくても問題ないということがわかったら、すべて自動化する。そうやって、段階的に安心して自動化できるようにしました。

運用管理技術の究極の目標に向かって

運用管理技術の今後の展望を教えてください。

写真「飯塚 大介(いいづか だいすけ)」

飯塚わたしと増田は、入社後2〜3年、ビジネスグリッドコンピューティングの国家プロジェクトに参画し、運用管理ソフトを利用してうまく運用できる仕掛けを作ろう、という技術を研究していました。

このプロジェクトで最初にやろうとしたことが、自律システム運用です。これは、システムに障害が発生した場合、例えばサーバが壊れた場合に別のサーバに切り替えるという処理を自動でやらせたり、アクセスが殺到した場合はサーバを増やして負荷を分散する処理を自動でやったり、といった技術です。今後は、そういうことが簡単にできる仕掛けを作りたいと考えています。

写真「増田 峰義(ますだ みねよし)」

増田運用管理技術の業界全体のトレンドとして、自律システム運用という究極の目標に向かって進んでいます。我々も運用管理研究部として、その目標に向かって技術をこれからどんどん作っていきたい。皆、それぞれの立場からいろいろな技術開発を進めていきたいと思います。

自律システム運用で、さらに運用管理の現場の声に応えることができそうですね。

写真「和田 清美(わだ きよみ)」

和田そうですね。わたしは、運用管理の現場にいたときに、運用管理に携わる人の精神的なプレッシャーというものを経験しました。

24時間365日、お客様のシステムを安全に稼働させ続けるために作業する。お客様先では相手に安心感を持っていただけるように、常日頃から冷静な判断ができるように準備をしておく。そんな経験から、運用に携わる人の気持ちを理解できました。この経験を踏まえて、新しい製品はどうあるべきかということを設計部署と話しながら、JP1/ITSLMを開発してきました。

今後も、実際に運用管理をしている現場の声を確認しながら方向性を間違えずに、ちゃんと喜ばれる、マーケットに受け入れられる製品にしていかなくてはいけない。機能だけではなく、本当に現場が欲しいものを提供できるように、これからも開発を続けていきたいと思います。

特記事項

  • 2013年3月27日 公開
  • 所属、役職は公開当時のものです。

関連リンク

  • ページの先頭へ

類似キーワードコンテンツ

  • ページの先頭へ