近年のシステムは様々なサーバ，ネットワーク機器，アプリケーション等のソフトウェアとインフラストラクチャ（インフラ），ままたはクラウドサービスが複雑さに関係しあうシステムが多い．このように複雑化する一方で，ソフトウェア，またはインフラ，クラウド等を環境に合わせて正常に設定する必要がある．しかし，設定項目が多すぎるため，設定ミスによる障害の発生や，更にどの機器に原因が発生したのかがわからない上に特定する事には多大なコストがかかる．複雑なシステムの障害を検出するための第１段階としてソフトとインフラをシームレスにリプレイするログリプレイヤのプロトタイプを開発した
近年のシステムは様々なサーバ，ネットワーク機器，アプリケーション等のソフトウェアとインフラストラクチャ（インフラ），ままたはクラウドサービスが複雑さに関係しあうシステムが多い．このように複雑化する一方で，ソフトウェア，またはインフラ，クラウド等を環境に合わせて正常に設定する必要がある．しかし，設定項目が多すぎるため，設定ミスによる障害の発生や，更にどの機器に原因が発生したのかがわからない上に特定する事には多大なコストがかかる．そこで本研究では，このような複雑なシステムの障害を検出するための第１段階としてソフトとインフラをシームレスにリプレイするログリプレイヤのプロトタイプを開発した
開発したソフトウェアはそのシステムのネットワーク図と，そこに記載される機器のログからシステム全体のアクセス状況等を時系列に再生できるものである．図2では各機器を線で結んでおり，線が赤くなった場合には機器間でアクセスがあったということになる．また，赤い線が太くなるとそれだけアクセス量が多いということになる．
図2は実際のシステムでセッションエラーが多発するという障害のあったログを読み込み再生した様子である．ロードバランサによって分散化されているが，1台はアクセス量が多いことがわかるが，2台目はアクセス量が少ない．本来ロードバランサはある程度の負荷がかからないと分散化をしない設定のはずが，負荷が低いにも関わらず分散化されており，それが原因でセションエラーが多発していたことが本ツールでわかった．試作したリプレイヤツールの実際の運用の流れは図3に示す．
本研究の目的はインフラとソフトウェアのどちらに障害があるかの分類を行うことが目的の1つである．そこで，本研究ではログからソフトウェアとインフラのどちらに不具合があるかを判定するフレームワークを提案したものが図4である．フレームワークは3フェーズから構成され，フェーズ1では通常レベルのログ（以降ノーマルレベルログと呼ぶ）を運用稼働中に常時収集する．障害が発生した時，その時刻とIPアドレスでログより障害に関連するログを抽出する．フェーズ2では過去の蓄積されたログより障害発生と同一操作で障害が発生しなかったログを抽出し，フェーズ1の障害が発生したログとの差分を抽出する．フェーズ3ではテスト環境を構築してデバッグレベルログを収集しインフラ，ソフトウェアのどちらが障害原因かの特定を行うものである．
さらに今後，フレームワークを発展させるため，今後は図4のステップ1-1，ステップ2-1を自動化し，さらにその中からエラーログには出力されないような障害を検知する．このようなエラーログに出力されるログを「不吉なログ」と命名し，不吉なログを検出することで開発者や運用者が気づいていない障害を早期に検知し，より素早い対応を行うことができる．
研究シーズ・教員に対しての問合せや相談事項はこちら
技術相談申込フォーム© INNOVATION DAYS 2024 智と技術の見本市.
