貴金属比とその関連数列によるシングル，ダブル，トリプル型の正三角形螺旋と正六角形螺旋
黄金比，白銀比，青銅比など貴金属比と関連するサブタイトルの数列を活用して，図余りと図足らずを許した場合の正三角形による螺旋図を考察しました．その結果，シングル，ダブル，トリプル型の正三角形螺旋図の特徴が分かりました．また，副産物として正三角形の特徴を有する正六角形の螺旋図も考案しました．どうぞお楽しみください！
近年のシステムは様々なサーバ，ネットワーク機器，アプリケーション等のソフトウェアとインフラストラクチャ（インフラ），ままたはクラウドサービスが複雑さに関係しあうシステムが多い．このように複雑化する一方で，ソフトウェア，またはインフラ，クラウド等を環境に合わせて正常に設定する必要がある．しかし，設定項目が多すぎるため，設定ミスによる障害の発生や，更にどの機器に原因が発生したのかがわからない上に特定する事には多大なコストがかかる．複雑なシステムの障害を検出するための第１段階としてソフトとインフラをシームレスにリプレイするログリプレイヤのプロトタイプを開発した
概要
近年のシステムは様々なサーバ，ネットワーク機器，アプリケーション等のソフトウェアとインフラストラクチャ（インフラ），またはクラウドサービスが複雑さに関係しあうシステムが多い．このように複雑化する一方で，ソフトウェア，またはインフラ，クラウド等を環境に合わせて正常に設定する必要がある．しかし，設定項目が多すぎるため，設定ミスによる障害の発生や，更にどの機器に原因が発生したのかがわからない上に特定する事には多大なコストがかかる．そこで本研究では，このような複雑なシステムの障害を検出するための第１段階としてソフトとインフラをシームレスにリプレイするログリプレイヤのプロトタイプを開発した
試作したログリプレイヤツール
開発したソフトウェアはそのシステムのネットワーク図と，そこに記載される機器のログからシステム全体のアクセス状況等を時系列に再生できるものである．図2では各機器を線で結んでおり，線が赤くなった場合には機器間でアクセスがあったということになる．また，赤い線が太くなるとそれだけアクセス量が多いということになる．
図2は実際のシステムでセッションエラーが多発するという障害のあったログを読み込み再生した様子である．ロードバランサによって分散化されているが，1台はアクセス量が多いことがわかるが，2台目はアクセス量が少ない．本来ロードバランサはある程度の負荷がかからないと分散化をしない設定のはずが，負荷が低いにも関わらず分散化されており，それが原因でセッションエラーが多発していたことが本ツールでわかった．試作したリプレイヤツールの実際の運用の流れは図3に示す．
障害特定のためのフレームワークの提案
本研究の目的はインフラとソフトウェアのどちらに障害があるかの分類を行うことが目的の1つである．そこで，本研究ではログからソフトウェアとインフラのどちらに不具合があるかを判定するフレームワークを提案したものが図4である．フレームワークは3フェーズから構成され，フェーズ1では通常レベルのログ（以降ノーマルレベルログと呼ぶ）を運用稼働中に常時収集する．障害が発生した時，その時刻とIPアドレスでログより障害に関連するログを抽出する．フェーズ2では過去の蓄積されたログより障害発生と同一操作で障害が発生しなかったログを抽出し，フェーズ1の障害が発生したログとの差分を抽出する．フェーズ3ではテスト環境を構築してデバッグレベルログを収集しインフラ，ソフトウェアのどちらが障害原因かの特定を行うものである．
不吉なログの検出の試みへの発展
フレームワークを用いた障害の特定はOS，ミドルウェア，アプリケーション等から出力される数GBにも及ぶ膨大なログを分析し設定ファイルの修正や開発者に修正依頼を行う必要がある．障害は複数のソフトの組み合わせで発生する場合が多く，障害内容によってはログにエラーメッセージが出力されない場合があり，正常に動作した膨大なログから障害原因を調査する必要がある．このような障害の原因となりうるログメッセージ群（本研究では不吉なログと呼ぶ）を開発者や運用者の経験だけで発見することは困難である．そこで本研究では不吉なログを自動的に検出するための試みを行っている．
不吉なログを検出する手法として全体像を図4に示す．（１．実際にバグを潜在させたシステムを稼働させログを収集し，その時の正常動作ログと障害発生時のログを分別する．この時対象とするログはOS，ミドルウェア，アプリケーション等のログを出力する全てを対象に行う．（２．パターン認識を高速化させるためにログフォーマットの統一化と軽量化を行う．またログデータは膨大な文字列から構成される事が多いためログ内容を数値化する．（３．障害のあるログと障害の無いログには必ずログのメッセージが異なるというコンセプトを基に障害のあったログメッセージ（ログパターン）から不吉なログを検出する．
不吉なログ検出手法の提案と適用
現在，不吉なログの検出方法として定型的なログメッセージを削除後に類似するログメッセージをクラスタリングし，その結果の内クラスタサイズが小さいログメッセージを不吉なログとして扱う提案を行っている．本提案手法の概念図を図6に示す．本手法は大きく4つの工程に分かれており，Step1では出力されるログの整形，Step2ではログに含まれる変数のマスク，Step3では定形的に出力されるログメッセージの除外，Step4でクラスタリングの結果，規模の小さなクラスタを不吉なログとして扱う．本手法を実際に運用・利用している複数のオープンソースプロジェクトに適用した結果，不吉なログとして検出されたログにはバグやサーバ設定のミス等の様々な障害が含まれる可能性が高いことがわかっている．
研究シーズ・教員に対しての問合せや相談事項はこちら
技術相談申込フォーム