Skip to Content Java Solaris コミュニティ パートナー 開発者 マイ・アカウント ご購入について (0120-33-9096) Japan Worldwide

Feed Feed RSS 1.0 Feed RSS 2.0 Feed ATOM 1.0
コンピュータよ、汝、自らを修復せよ!~管理者をトラブル地獄から救う真のセルフヒーリングとは~
  前号へ     次号へ  
今回は、research.sun.comから、Solaris 10の目玉機能のひとつである、『予測的セルフヒーリング(自己修復)機能』をサンの若きエンジニア、マイク・シャピロが、どんなアイデアから編み出したのかを紹介します。

突然、サーバのコンソール画面にエラーメッセージが現れる。メッセージの意味が分からない。何をどうすればいいのだろう?OS再起動?そりゃまずいでしょ、まだ他の人が仕事してるし。今は止められない、どうする?今夜もまた徹夜か?

システム管理者を経験した方なら、トラブルの原因と対処法がなかなか分からず、苦悶した経験を少なからずお持ちだろう。システム管理者の最大使命は、とにかく少しでも早く障害を復旧してユーザの業務に影響を与えないことだ。しかし、不測のトラブルが発生した現場では、プレッシャーを与えられ、冷静な判断が難しい。まして、意味不明なエラーメッセージを前にして、コンピュータだけでなく管理者までパニックを起こしてしまいそうだ。

Solaris 10の目玉機能のひとつである、『予測的セルフヒーリング(自己修復)機能』は、コンピュータを使ったことがある人なら誰もが身に覚えがあるこんな欲求不満から生まれた。この機能を編み出したのが、サンの若きエンジニア、マイク・シャピロである。彼のどんなアイデアから、Solarisが“真”のセルフヒーリング機能を備えるに至ったのだろうか?

このシリーズでは、製品の開発現場で様々な困難に挑戦するサンのエンジニアを紹介している。Solarisの画期的な機能は、開発者たち自身の“困った”ことを解決するために見出されたものが多い。ZFSDTrace、そして今回紹介するセルフヒーリングも、あるトラブルがきっかけに生まれた機能である。

Solarisの予測的セルフヒーリング機能について、簡単に説明しておこう。
予測的セルフヒーリングとは、多くのハードウェアやアプリケーションの障害を自動的に診断、分離、修復する機能である。Solaris 10は、CPUやメモリ、入出力など、障害の発生しそうなコンポーネントを検出し、オフラインにすることができる。さらに、障害の発生したサービスがあると、予測的セルフヒーリング機能が直ちにそれを検知し、ユーザの介在なしに自動的にこれを再起動することができる。このため、ハードウェア障害や、大きなハードウェア・コンポーネント障害、あるいはソフトウェアの構成エラーがあっても、ビジネス・クリティカルなアプリケーションや重要なシステム・サービスは、中断することなく動作を続けることができるのだ。まさに、OSの力で、コンピュータが自己(self)を治癒(heal)するのである。

さらに詳しく知りたい人はこちらの情報に目を通されることをおすすめしたい。

【参考資料】

このページの写真の通り、マイク・シャピロは、どこにでもいそうな若者である。
しかし、彼は、Solarisカーネル開発において、ソフトウェアの信頼性、可用性、および保守性へのサンの取り組みを具体化するために力を注いできた社員である。

Solaris 10では、同僚のブライアン・キャントリル(彼については次回に紹介しよう)とともに、セルフヒーリングを備えた障害管理およびサービス管理の設計とエンジニアリング、およびDTraceに取り組んだ経験を持っている。

コンピュータ業界では、「セルフヒーリング」という言葉が以前からかなり気軽に使われてきた。マイクは、このプロジェクトに取り組んでいた5年以上もの間、巷で、やたらと“この製品は壊れません!”とか、“この製品はセルフヒーリング対応です!”といった宣伝や広告が目についていたのを思い出す。

「でも、その舞台裏を見るととんでもないんだよ。実際には、保守サービスとかエラーメッセージがちょっと改善されたようなもので、以前と同じものに過ぎなかったんだ。」と彼は眉をひそめる。
「つまり、問題が起きたときに直面することはなんら変わっていない。特に画期的と思えることは、どこのメーカーも何も出来なかったということだったんだ。」

メーカーのその場限りの売り文句に過ぎない「セルフヒーリング」という流行語にユーザが振り回されているまさにその時、マイクと彼の同僚はこの言葉を確かな『現実』にするために、あるプロジェクトに粛々と取り組んでいたのである。

話は1999年にサンの得意先顧客を悩ませていた、『eキャッシュ問題』(コラム参照)にさかのぼる。社運をも左右しかねないこの大問題を解決するために、さまざまな部署からハードウェアとソフトウェアの専門家が集められ、特別プロジェクトチームが構成された。マイクはその一員となった。

そこで見つかった解決策は、OSのエラー処理をより洗練させて、エラーがキャッシュに溜まらないようにすることだった(現在、この機能はマイクロプロセッサにハードウエア的に組み込まれている)。

「専門的で意味の分からない内容のエラーメッセージがいくつも画面に現れることがあるよね。当然、お客さんはメッセージを理解できない。サンの現場の人間も理解できない。そのエラーメッセージを書いた人たちでさえ理解できないなんてことがあるんだ。みんな、そんな昔に書いたエラーメッセージのことなんて忘れてるからね。そこで、まず僕たちはエラーメッセージの改良という、えらく細かい作業を行う羽目になったわけ。」とマイクは振り返る。

「そうして残ったのが、わずか5人のこのチーム。プロセッサの下位レベルのかなり細かい説明まで明らかにしたので、エラーメッセージはすべて解読可能になったんだ。」

Solarisの開発エンジニアというと一見かっこよさそうだが、そう、彼らは実に地味で泣きたくなるような細かい仕事もたくさんしているのである。
このチームは、客先で問題が起きると、一連のメッセージを徹底的に調べ、システムの内部で何が起きているのかを突き止める。

「突然、“俺たち、なんで一つの部屋に5人も雁首並べて、こんな作業を繰り返しているんだろう?”という疑問が僕の頭に浮かび始めたんだ。」

後に、Solaris 10の開発の仕事が始まるようになり、マイクはこの問題解決のアプローチの仕方が完全に間違っていたと思うようになった。

「メンバーの頭の中には非常に多くの複雑なロジックが詰まっている。ところが、自分たちのしていることは繰り返し単にメッセージを受け取って、そのロジックを何度も繰り返し当てはめるだけ。言い替えれば、そこにある種のアルゴリズムが存在するということだ。」

彼の中に、『人間が行っているこの一連のロジックをコンピュータ内で自動的にするようにすべきなんじゃないだろうか?コンピュータなんだから、エラーを詳細に正しく知らせることに専念するんじゃなくて、それ以上のことをやらせることができるはず。』という考えが沸き起こり、そのひらめきが予測的セルフヒーリングへの道につながっていく。

エラーというのは問題があることを指摘するだけであり、それを見て何をするかは人間が考えなければならない。トラブルが起こっている現場では、正しい判断が難しく、また間違えることも多い。しかも大規模なシステムであるほど、いろいろ覚えておかなければならないことが多い。(どこかをさわると他がおかしくなるかもしれないからだ)これこそ、人間がコンピュータの助けを必要とする状況なのである。それらを自動化するのが、『セルフヒーリング機能』なのである。

マイクは、コンピュータのエラーメッセージを、私たちの体の喉の痛みや熱になぞらえて説明してくれた。
「喉の痛みや熱は目で観察できるし、言葉にできるけど、それらは病気の原因を示してはいないよね。医者の仕事は、それらの症状を調べて潜んでいる問題の根本原因を突き止めることなんだ。」

我々は、ハードウェアに埋められたさまざまな検出器や、デ―タの整合性を検査する小さなコードを使ってコンピュータシステムに問題がないか監視している。しかし、人の体内と同様に、同じ症状を持つ問題は数多くある。その逆に、根本原因は1つであるのに、多くの異なる症状が出る場合もある。

「潜んでいる問題は1つでも、幾層ものソフトウェアを通じて、数十、数百、あるいは数千もの症状となって現れることがあるでしょう。“デバイスドライバはこれを参照し、ファイルシステムはあれを参照・・・”、というようにいろいろな要素が次々と連鎖しているんだ。」

「100個のエラーメッセージを見ても、そこにどのぐらいの数の問題が発生しているのかは分からない。1つだけかもしれないし、あるいは100の問題があるかもしれない。これでは何も明らかにならないので、エラーメッセージ間にある何らかの関係性を解明し、その関係の意味(法則性)を考えることが必要なんだ。」

セルフヒーリングの開発の背景となった壮大なアイデアは、驚くほど単純だった。

「ソフトウェアに、いきなり人間に対するエラーメッセージを吐き出させるのではなく、それを別のソフトウェア向けのメッセージに変換するんだ。」とマイクは言う。

「エラーメッセージが遠隔測定データになり、“診断エンジン”と呼ばれる別のソフトウェアに渡される。この診断エンジンが『お医者さん』のようなものだ。そのソフトウェアは、実在する一連の問題に対して、“この症状の組み合わせには、こういう相互関係がある”というような情報を持っている。これは、症状と問題を結び付ける方法を知っている“エキスパート・システム”をコンピュータに埋め込んだようなものだと思えばいい。」

単純なアイデアで、複雑なことを行う。しかし、これでユーザ体験は劇的に変わる。

「ユーザの画面には、理解できないエラーメッセージが数え切れないほど表示されるのではなく、理解できる説明と、本当に大切なこと、つまり、どのように対処すればよいかを伝えるメッセージが1つ表示すればいいんだ。ディスクを取り出せばよいのか。その場合はどれか。CPUの交換が必要か。新しい部品を注文するのか。そんなことだよ。」

しかし、当然のことながら、マイクと同僚は、これだけに留まらなかった。

「次は、コンピュータに何が問題かを伝えさせるだけでなく、自動的に処置を行えるようにするんだ。何らかの処理をする。たとえば、ソフトウェアにバグがあるとしよう。そのソフトウェアのどこにバグがあるのかは、正確に突き止められないかもしれないけど、問題があると思われるソフトウェア・コンポーネントは特定できて、それを自動的に再起動してあげることができるんだ。」とマイクは説明する。

予測セルフヒーリングではハードウェアの問題そのものを解決することはできないが、問題を回避することができる。エラーに潜む問題を自動的に検出・診断し、分かりやすいメッセージで管理者が取るべきアクションを導いてくれるので、管理者はその指示に従って、人的な介在を必要とする修復作業を行うことができる。今日のシステムのメモリ容量とマルチコア、マルチスレッド処理能力があれば、効果的といっていい対策である。

たとえば、RAMにはソフトエラーと呼ばれる避けがたいエラーが発生する可能性がある。これは故障ではなく、ある一定の確率でどうしても起こる。通常システムはこれをECCで問題の発生の検出と訂正を自動的に行うが、同じチップが続けてエラーを起こす場合は実際の故障である可能性が高い。以前はこれをエラーメッセージの山から探し出して、同じチップがどうか判断して交換するという面倒があったが、これをSolarisのセルフヒーリング機能は簡単なデータベースで記録していき、必要な判断を行ってくれる。

余談になるが、SolarisとSunFire E6900などの組み合わせなどの場合は、エラーがあった一部のメモリを自動的に切り離して、ちょっと少なくなったメモリサイズで“何もなかったように”運用を継続することができる。

実際、マイクと同僚は最近、『信頼できるシステムとネットワーク(Dependable Systems and Networks)会議』において、Solaris 10でメモリエラーが起きた場合、セルフヒーリング診断と対応によって、システム停止時間が年間30~50%短縮できるという調査結果を記した論文を発表した。

(※論文(英語):Assessment of the Effect of Memory Page Retirement on System RAS Against Hardware Faults

「Solaris 10の診断エンジンはそこまで洗練しつつあり、OSの更新のたびに進化し続けているんだ。」とマイクは強調する。

しかし、サンにとっての挑戦は、ここからだ。せっかく素晴らしい機能を開発しても、すでに蔓延してしまった“セルフヒーリング”の間違ったイメージが邪魔をして、なかなか顧客は理解してもらえない。

「サンの競合会社はセルフヒーリングをくだらないものとして適当に扱った結果、深刻な害をもたらしたのではないだろうか。その反動が現れている。顧客はその真の意味を理解しないまま、麻痺してしまったんだ。」

いくらサンのセルフヒーリング機能について説明しようとしても、顧客はウンザリしたようにこう言うのだ。
『もちろん、どこの会社も自分のところのサーバはセルフヒーリングができるって当然のように言うんだよ。だけど実際のところは、保守担当者が何人もデータセンタ内を駈けずり回って、以前と同じことをやってるだけだ。サンのセルフヒーリングは、他社と何か違いがあるの?』

「僕たちのアプローチは、よりデータ志向かつ現実志向なんだ。お客さんに、何かの機能について僕が話をするときは、その機能を実際に見てもらうという方法をとっているんだ。」

サンのセミナールームでの顧客向けプレゼンテーションでは、マイクはまず概要から話を始め、次のように続ける。
「ここにサーバの実機をお持ちしています。これをどのようにしてテストするのか、皆さんは不思議に思われているかもしれませんね。我々はハードウェアに実際に起こりえる問題を強制的に起こさせることができるソフトウェアを用意しています。サンのハードウェアチームと我々Solarisチームが協力して、それらのインタフェースを設計しました。」

ここで重要なのは、非常に複雑なことをいたって簡単なことのように見せることだ。
参加者が見守る中で、プロセッサが問題を起こし、Solarisがその対応をする。

「お客様の前で実際にデモをやって見せれば、すぐにそれが理解されるので、話の本質が全く変わってくるんだよね。」とマイクは言う。

「Solarisのセルフヒーリングは、もはや単なる宣伝ではない。実在する機能なんだ。」

編集部注記:『eキャッシュ問題』

『eキャッシュ問題』とは、サンとしては、苦い経験だが、その後の製品の品質の向上において非常に重要なステップとなった歴史的な出来事でもある。

サンは、UltraSPARC IおよびIIを設計したときに2次キャッシュを外付けにしたが(External cacheが転じて“ecache”と呼ばれた。)これに対してECCではなくパリティのみのプロテクションにした。当時の設計者は、キャッシュに使うSRAMの信頼性は十分に高いから大丈夫と考えたと思われる。ECCであれば、シングルビット・エラーは補正できるので運用を続行できるが、パリティだと問題があったことだけが分かるのでシステムはpanicを起こす。製品の本格出荷が始まると、当初想定した率よりも遙かに高くE-Cacheエラーが起こり、問題が顕在化した。この時の問題は複数の原因が複雑に絡み合っていて抜本原因がなかなか見つからなかった。そのなかでも、エラーメッセージが分かりにくいことが、解決を遅らせていたため、マイクらがまず、エラーメッセージの改良から手をつけることになった。


マイク・シャピロ
肩書き:
米国サン・マイクロシステムズ社 Distinguished Engineer
座右の銘:
「設計とは、詰め込むことと同じぐらいに除外すること。」
職歴:
予測セルフヒーリングおよび障害管理のためのサンのアーキテクチャの設計、構築への取り組み。DTraceの共同作成。DTraceコンパイラ、Dプログラミング言語、カーネルパニックサブシステム、fmd(1M)、mdb(1M), smbios(1M)、dumpadm(1M)、pgrep(1)、およびpkill(1)の作成。また、/procファイルシステム、コアファイル、クラッシュダンプ、Solarisのハードウェアエラー処理に対する数多くの機能改良。
学歴:
ブラウン大学でコンピュータ科学の学士号と博士号を取得。
受賞暦:
技術革新に関するサン会長賞を3度受賞(2001年、プロセッサおよびメモリ障害から回復するSolaris技術での業績に対して。2004年、DTraceでの業績に対して。2005年、SPARCおよびAMD Opteronシステム用の予測セルフヒーリングでの業績に対して)。2005年、DTraceおよび予測セルフヒーリングに対してInfoWorldのInnovation Awardを受賞。2006年、DTraceでウォールストリートジャーナルからTechnology Innovation Awardを受賞。
特許:
14件(出願中)
少年時代の夢:
「ソフトウェア技術者になること。父からプログラミングを教わったため、覚えている限りでは、プログラミングが大きな関心事だった。」
嫌いなこと:
悲観主義。
サンに入社した理由:
「OSの技術者になりたかった。OSレベルのシステム設計で最も革新的な仕事がサンで行われているというはっきりした認識があったので、サンの一員になりたかった。」
影響を受けること:
「自分のしていることに情熱を注いでいる人によく刺激を受ける。技術者とは限らない。情熱的な俳優や数学者、芸術家からも刺激を受ける。ソフトウェア技術には芸術や言語、数学などの要素があるため、ソフトウェア技術者であることは非常に学際的な営みになる。だから情熱的でアイデアを探し求めている人の話に耳を傾けて刺激を受ける。そういうことに本当に刺激を受けるんだ。」
  前号へ     次号へ  
ご意見・ご感想をお聞かせください
この記事は参考になりましたか?
     

コメントがございましたらご記入ください


ページ先頭へ

Sun Fun Times


 

お問い合わせ 会社情報 ニュース 採用情報 プライバシー 利用規定 商標 Copyright  Sun Microsystems, Inc.