|
| Japan Worldwide |
突然、サーバのコンソール画面にエラーメッセージが現れる。メッセージの意味が分からない。何をどうすればいいのだろう?OS再起動?そりゃまずいでしょ、まだ他の人が仕事してるし。今は止められない、どうする?今夜もまた徹夜か? ![]() システム管理者を経験した方なら、トラブルの原因と対処法がなかなか分からず、苦悶した経験を少なからずお持ちだろう。システム管理者の最大使命は、とにかく少しでも早く障害を復旧してユーザの業務に影響を与えないことだ。しかし、不測のトラブルが発生した現場では、プレッシャーを与えられ、冷静な判断が難しい。まして、意味不明なエラーメッセージを前にして、コンピュータだけでなく管理者までパニックを起こしてしまいそうだ。 Solaris 10の目玉機能のひとつである、『予測的セルフヒーリング(自己修復)機能』は、コンピュータを使ったことがある人なら誰もが身に覚えがあるこんな欲求不満から生まれた。この機能を編み出したのが、サンの若きエンジニア、マイク・シャピロである。彼のどんなアイデアから、Solarisが“真”のセルフヒーリング機能を備えるに至ったのだろうか? このシリーズでは、製品の開発現場で様々な困難に挑戦するサンのエンジニアを紹介している。Solarisの画期的な機能は、開発者たち自身の“困った”ことを解決するために見出されたものが多い。ZFSやDTrace、そして今回紹介するセルフヒーリングも、あるトラブルがきっかけに生まれた機能である。 予測的セルフヒーリング機能って何? 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のセルフヒーリングは、もはや単なる宣伝ではない。実在する機能なんだ。」
| Sun Fun Times
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||