ビジネスイノベーターは、nikkeibp.jpビジネススタイルに変わりました。こちらをクリック。

ビジネス イノベータートップへ

ーーー
編集部からのお知らせ

ーーー
連載企画
「IT」と「環境」
まれる心、
企業生き残りの代償


境生活のススメ

塊消費動向研究所
--シニアを“生かす”
ビジネスの可能性


門「近自然学」
〜豊かさと環境の
両立は可能だ


"ビジネス基礎力"向上計画
〜ワンランク上の
プロを目指す


"会社"に頼らない生き方を探れ!

代リスクの基礎知識

「環境」を考える
(日経エコロジー)


ーーー
日経ビズテック創刊!
雑誌関連のお知らせ

ラム・ショーケース

島の眼

ーーー
今週の市場データ

ーーー
読者から
 (Reader's Opinion)

ーーー
仕事の本棚

ーーー
オフタイム・クリエーター
新ワークスタイル研究

出張、リデザイン

充実空間


ーーー
from nikkeibp.jp 倶楽部

ーーー
アーカイブ

ーーー

お問い合わせ

ビジネス イノベーター
spacer
nikkeibp.jp

テクノロジ解説
プロフィール
第18回  問題の所在を明らかにする--複雑なシステムの問題判別技術

2003/09/02

著者近影
福田 剛志氏
著者近影
奥田 邦夫氏
 近年、コンピュータ・システムは単純なクライアント・サーバー型から多種多様な製品を蜘蛛の巣のようなネットワークでつないだウェブ・システムへと変化しています。このため、障害時には調査対象が複数の製品・拠点にまたがり、今までのような単一製品・単一地点での調査では解決できず、広範囲な製品の知識と多様なツールが必要となってきました。

 私たちはIBM大和研究所にある統合システム技術センター(通称ISEL: Integrated System Engineering Laboratory)において、1996年以降、お客様のシステムで発生した障害の中で通常の方法では解決できない複雑な問題を1000件以上解析し、解決してきました。現在、IBM東京基礎研究所と共同で新しい問題判別技術の研究開発に取り組んでいます。今回は、その経験を元に、最新の問題判別技術について解説します。

ネットワークの問題判別--現代のネットワーク事情

 ネットワーク・システムは年々複雑化する傾向にあります。例えば、ショッピング・サービスを行うウェブ・サイトには、ウェブ・サーバーにアプリケーション・サーバー、データベース・サーバーなどがあり、そこにアクセスするユーザーのコンピュータはインターネットのどこか遠くで繋がっています。また、大規模なネットワーク・システムには、レイヤー3スイッチやファイアウオール、ロード・バランサといったネットワーク・トラフィックを制御するための機器も多数存在します。

いかにして障害を発見するか

 残念な話ですが、これだけ複雑になったネットワーク・システムをトラブルなしに運用し続けるのは極めて困難です。そこで重要になるのが、いかにしてトラブルを発見し、それを修正するかということです。

 しかしながら、複雑なシステムでは、まずどこで障害が起こっているかを見つけるだけでも膨大な労力と時間が必要です。従来は、1台ないし数台のネットワーク・アナライザを用いて、障害が発生していると考えられる箇所を順番にモニターしてデータを収集・解析していました。ところがネットワークの複雑さが増してくると、この方法が破綻するのは明らかです。アナライザの数を増やして一度にすべてのデータ収集を行えば破綻は回避できますが、アナライザは決して安くはありませんし、全二重対応やギガビット・イーサネット対応などは個別オプションである場合が大半です。

 我々が提供するネットワーク解析ツールでは、この点を改善するために汎用のパーソナル・コンピュータをベースに開発を行っており、従来に比べて数分の1程度のハードウエア・コストで種々のネットワークでのデータ取得が可能となっています。また、取得した大量のデータから障害の原因を究明するには、経験豊富なエンジニアが時間をかけて調べる必要がありますが、この労力と時間を減らすために、過去の障害解析の経験に基づいた、取得したデータを効率よく解析するためのソフトウエア・ツール群の開発も行っています。

障害対応の効率化

 データ取得が簡単になり、解析に必要な時間も短縮されるとなれば、次に「常にデータを取り続けておけば、いつ起こるかわからない障害への対応時間が短縮されるのではないか」という発想が出てきます。現在ではまだ障害の自動検知機能はないため、障害発生後に手動でデータ取得を止める必要がありますが、それでもすでにいくつかの障害事例において実績をあげています。

 また、常にデータを取り続けるということは、常時監視が可能ということにもなります。障害解析のときと同レベルの解析をリアルタイムで行うのはまだ困難ですが、データ流量等のリアルタイム表示やSNMP(Simple Network Management Protocol)データの表示などであれば問題なくできます。「Tivoli」のようなシステム監視ソフトウェアが導入されていれば、システム側の情報とネットワーク上の情報を相互補間することも可能です。

 さらに、多点同時データ取得の特徴を生かして、ネットワークのボトルネック発見や、ロード・バランサやNAPT(Network Address Port Translation)をまたがる障害への対応が、より効率的に行えるようになっています。

ソフトウエアの問題判別--障害解析の難しさ

 現在のウェブ系システムは多種多様なコンピュータが複雑に絡み合ったサーバー群で構成しており、インターネット上の不特定多数のクライアントからのアクセスを受けます。このようなシステムでは、障害が検知された場所と真の原因がかけ離れていることが多く、資料収集・解析に多大な時間と労力を要します。また多くの場合、障害発生時には復旧を優先させるため、十分な問題判別資料が収集できません。これも障害解析を困難にしています。

自動障害解析

 これらの問題点は障害解析の自動化を推し進めることによって解決できます。

 コンピュータが得意とするのは定型的データ処理です。これを障害解析の中に生かし、障害検知や資料の収集・送付ならびにすでに定型化されている既知の問題の判別を行わせるのが良いでしょう。

 障害検知は 各種ソフトウエアで広く行われています。ただし、現状では障害通知にとどまることが多く、資料送付や解析、追加の資料取りなどには対応していないものがほとんどです。

 私たちが提供しているソフトウエア自動障害解析ツールでは、あらかじめ各サーバーに導入してあるエージェント・ソフトウエアが、障害を検知すると自動的に解析資料を収集し、復旧処理を行うと共に収集した資料を解析サーバーに送付します。解析サーバーでは既知の問題を判別するための定型処理を次々に流し問題判別を行います。世の中で発生している障害の8割以上は既知の問題だと言われているため、これだけでかなりの効果があります。また、解析中に追加で必要な資料があった場合、サーバーからのリクエストに応じてエージェントが自動的に収集・送付してくれます。これは、未知の問題を解析する時に非常に役に立ちます。

 これらの機能により、時間と手間がかかる資料収集と既知の問題の検索ならびに修正の適用を自動化することができます。技術者は純粋に未知の問題の解析に労力を注ぐことができるのです。

パフォーマンスの問題判別

 多くのコンポーネントが組み合わさった複雑なシステムでは、たとえ機能が正しく動いていたとしても、期待された性能が出ずに、頭を抱えることが良くあります。最近はSLA(Service Level Agreement)と呼ばれるシステムの品質に対する客観的な取り決めを行うことも増えてきており、パフォーマンスに関しても深刻な問題になっています。

 一口にパフォーマンスの問題といっても、原因も解決方法もさまざまです。数百もある設定パラメータのうちたった1つが不適切な値に設定されていたために、本来の性能が全くでなくなってしまうこともありますし、データベースの問い合わせやインデックスに問題があることもあります。また、アプリケーションのロジック自体を見直すことが必要な場合もあります。では、パフォーマンスを良くするためには、どのように対処すればよいのでしょう。

負荷テスト

 当たり前のことですがまずは現状を把握すべきです。そのために負荷テストによるプロファイリングを行います。通常、人工的な負荷(処理要求)をシステムに与えて、各コンポーネントの処理時間、スループット、CPUやディスクの利用率などを記録します。その結果を、経験を積んだ技術者がじっと眺めて、問題箇所を見つけ出し、修正を加え、また負荷テストを繰り返すのです。しかしこの方法では試行錯誤に陥りやすく、時間と労力がかかります。

 この課題を解決するために、私たちは負荷テストの結果を自動的に解析し、問題箇所を推定するツールを開発しています。このツールにはこれまでの事例に基づく知識が、ルールとして組み込まれており、実際の運用を通じて新しい知識が追加できるようになっています。

モデル化とシミュレーション

 負荷テストを行うためには実際のシステムを準備しなければならないので、構成を変更するのは文字通り労力がかかりますし、「もしサーバーがあと1台多かったらどうなるか」といった問いにはどうしても答えられません。また、実運用に入ったシステムを一旦止めて、負荷テストすることは多くの場合現実的ではありません。そこでコンピュータ上にシステムのモデルを構築し、モデルを使ったシミュレーションによって性能が評価できると便利です。

 待ち行列理論にもとづく従来の性能モデルは、比較的単純なシステムをかなり大雑把にしかモデル化することができません。これに対して私たちは、システムの中で起こるイベントをコンピュータ上で再現して処理時間を求める、離散イベント・シミュレーションの方法を用いて、複雑なシステムの性能をコンピュータ上で評価する技術を開発しています。先に説明した負荷テストで収集したデータから、モデルのパラメータを決定することにより、シミュレーションによってさまざまな設定でシステムの性能評価を行うことができます。

オートノミック・コンピューティングに向けて

 残念ながら現在のところ、複雑なシステムを障害なく運用することは非常に困難です。しかしながら、冗長化したシステムにここで紹介した技術を組み合わせることにより、障害の影響を最小限に食い止めながら復旧までの時間を短縮できます。さらに、障害データと修正方法のナレッジ・ベースが蓄積されていくと、既知の問題が発生すれば直ちに修正されるようになります。限定的な自己修復機能の実現です。このような自己修復機能は、e-ビジネス・オンデマンドのビジョンの実現に不可欠なインフラ技術となるでしょう。

(奥田 邦夫/日本IBM 統合システム技術センター 担当部長、福田 剛志/日本IBM 東京基礎研究所 オートノミック・コンピューティング グループ・リーダー)

奥田 邦夫・福田 剛志

奥田 邦夫:1974年、日本IBM入社。1974〜1991年、ネットワーク、ソフトウエア、ハードウエアの製品評価試験担当。1993〜1995年、統合システムの評価試験担当。1996年から現在まで、統合システム技術センター担当部長として、システム障害の解析、障害解析ツールの開発を担当。

福田 剛志:1991年、早稲田大学大学院理工学研究科修士卒。同年、日本IBM入社。博士(情報科学)。オブジェクト指向データベース、データマイニングなどの研究に従事。2002年よりオートノミックコンピューティングの研究プロジェクトを担当している。日本IBM東京基礎研究所 オートノミック・コンピューティング グループ・リーダー。

バックナンバー
■第21回[2003/9/22]
・XMLを使った高度な情報管理

■第20回[2003/9/16]
・オープンなWebサービスでの安全性

■第19回[2003/9/9]
・システム全体の安全を確保する

■第18回[2003/9/2]
・問題の所在を明らかにする--複雑なシステムの問題判別技術

■第17回[2003/8/26]
・ThinkPadとオートノミック・パーソナル・コンピューティング

■第16回[2003/8/19]
・自律的に動くコンピュータ

■第15回[2003/8/5]
・最適化技術でビジネスの効率を上げる

■第14回[2003/7/29]
・大量のデータを効率的に配信する

■第13回[2003/7/22]
・音声認識技術で"声"を活用する

■第12回[2003/7/15]
・「使いやすさ」を追求するには

■第11回[2003/7/8]
・ユビキタス時代のID技術(その2)

■第10回[2003/7/1]
・ユビキタス時代のID技術(その1)

■第9回[2003/6/24]
・データの洪水から何かを見つけ出す

■第8回[2003/6/17]
・進化する分散処理

■第7回[2003/6/10]
・ビジネスにおけるグリッドの真価

■第6回[2003/6/3]
・グリッド・コンピューティングとは?

■第5回[2003/5/27]
・エージェント技術でモバイルサービスの領域を広げる

■第4回[2003/5/20]
・Webサービス

■第3回[2003/5/13]
・データ構造を把握する

■第2回[2003/5/6]
・ビジネス・プロセスをはっきりさせる

■第1回[2003/4/25]
・オンデマンドへのビジネス変革を支えるITシステムとは


日経BP社 www.nikkeibp.co.jp

サービスよくあるご質問 | 記事に関するお問い合わせ
会社案内日経BP社案内 | プライバシーポリシー | 著作権・リンクについて | 広告ガイド
© 2005 Nikkei Business Publications, Inc. All Rights Reserved.