斎藤です。こんにちは。
今回は、学術論文の要約・解説の後半です。"Bridging the Divide between Software Developers and Operators Using Logs"を更に読み進めて行きます。
※謝辞と参考文献は省略します
※誤訳やより良い解釈がある等ありましたら、twitterの @koemu までお知らせください。
IV. 開発者と運用者を支えるログ解析
ここでは、開発者と運用者をサポートする、ログを基に提案されたアプローチを紹介します。
A. 開発者向け - ソフトウェアの品質を向上させるために運用の知識を活用
エラーが発生しやすいソフトウェアコンポーネントの識別
- 問題点: フィールドで発生する問題は、伝統的なデプロイ前のテストや静的解析を用いて特定する事は困難です。
- 役立つ知識: 頻繁に更新が行われる箇所は、今後発生するバグに対する有効なサインであります。
- 提案: 開発履歴を用い、全ソフトウェアコンポーネントの活動ログの量を測定します。リリース前のバグ、変更の合計数、およびコードの複雑さが対象です。
大規模システムの運用テスト範囲を評価する
- 問題点: 大規模システムに置いて、テストの網羅性が運用で信頼性が高くなる事を保証はしていません。テスターが運用のデータに基づき、システムテストの範囲を理解する事が大切です。
- 役立つ知識: 運用のログとテストラン(斎藤注:恐らくテストコードや手動テストをひっくるめていると思います)のログを比較することで、評価する。
- 提案: 第一段階では、運用ログから運用状態の実行モデルを作成します。第二段階で、テストログ(斎藤注:先のテストランのログ)に同様のモデルを採用します。第三段階で、それらを比較します。
A. 運用者向け - 運用の複雑さに対処するために開発の知識を活用する
ログの自動ドキュメンテーション
- 問題点: 問題の迅速な診断のために、ログ行の背後にある理論的根拠を理解することが必要です。
- 役立つ知識: ログ出力に関する変更についてのこれまでの知識が、ログの行を説明するための手段として用いる事が出来ます。
- 提案: ログに、バグレポートも添付する事です。
ログ出力量削減に開発履歴を用いる
- 問題点: リリース後、運用者は影響を調べるために全てのログを調べる必要があります。しかし、全ての機能が影響を受けている訳ではなく、それは労力の無駄につながります。
- 役立つ知識: 変更されたソースコードより、影響を受けたログを導き出す事が出来ます。
- 提案: 新しいリリースで変更されたソースコードを解析し、影響を受けているログ テンプレートを識別します。影響は、間接的・直接的なものが含まれています。そして、開発履歴に基づいて、ログフィルタを使用し、情報を利用する事が出来ます。
V. ログ分析の課題
C1. ログは構造化されていない
開発者がログを生成する際、特定の形式には従っていません。フォーマットがあったとしても、開発者は一貫して従ってはいません。Jiangらは、静的実行イベントと動的パラメータの値に、実行ログを抽象化する事を提案しています。
C2. ロギング及びログ利用のための流れはたいていアドホックである
ログの取得の際、運用者はスクリプトを利用してアドホックな方法でログを利用します。しかし、スクリプト自体がアドホックなので、他で流用できず効率的ではありません。
そこで、ログ及びソフトウェア開発データ間の類似性を導くために、関係代数(斎藤注:集合論と表を用いて演算を行う操作の総称 おそらくSQLのような仕組みでデータを分析できるようにしたいのでしょう)を用います。
C3. ログが大きい
ログが大きい事が問題です。典型的なHadoopクラスタの小テストベッド セットアップで、既に 200MB/sec. 以上のログを出力します。
そこで、pig(斎藤注:Hadoopを対話的に操作するためのAdd-in)を用いる事を提案します。
VI. 最先端と実践
開発支援のためのログ分析手法
4つの論文を紹介します。
- 負荷テストの機能検証を支援
- ログから実行モデルを推論する自動化ツール
- ロギングコードを改良することで問題の診断を行いやすくするためのアプローチ
- 設計ログから運用プロファイルを抽出するための効率的なアルゴリズム
著者のとるアプローチは、非常に大規模なシステムでもスケーラブルであるのを確認する事を目指しています。これからも、パートナーと共に研究を進めて行く予定です。
スケーラブルでシステマティックなログ分析プラットフォーム
2つのソフトウェアを紹介します。
既存のプラットフォームの多くは、grepライクな操作は出来るものの、複雑な分析は出来ません。著者らは、関係代数を用いて一般的なログ分析フレームワークを作成しようとしています。
VII. まとめ
筆者の先行実証研究では、大規模システムにおいて、開発者と運用者間の保守活動中における広がる格差を強調しました。本論文では、そのギャップを埋めるべくソフトウェア工学およびシステムコミュニティに対し、ログを用いることで解決することを提案しています。
開発者に貢献するべく、問題を引き起こしやすい部分を特定し、テスト範囲を評価するためにログの運用知識を利用します。また、運用者に貢献するべく、ログのドキュメントを自動化したりログの削減を支援する方法として、開発履歴を用います。そして、ログ分析の問題を克服するべく、関係代数を用いた言語を開発しています。
最後に: 斎藤より
ソフトウェア工学において、今回取り上げた論文の手法は、特に「実証的手法」と呼ばれています(他に「形式的手法」「解析的手法」「実践的手法」があります)。開発中に生成される"ログ"を活用して云々という取組は、バグトラッキングシステムでバグ収束曲線を作成したり、今後の開発時の見積根拠を持ち出す際に用いられている方も少なからずいらっしゃるかと思います。その上で、DevOpsの問題がクローズアップされつつある現在、このような手法が提案されるのはごく自然な事なのかもしれません。
私自身も、何となく問題点が何かを抱いていましたが、具体的に示される事で「ああ、自分ならこんな解決方法をとれるかもしれない。」と思う事もありました。恐らく、読者の方それぞれにそれぞれの解決策が浮かんだ方もいらっしゃるのではないでしょうか。
また、著者も述べていますが、ログ出力ルールはたいていはルールがごちゃごちゃで、体系的に分析するには帯に短し襷に長しと、悩ましいところであります。その解決策の一つに、活動の状況等多面的なデータを用いてスクリーニングするというのは、興味深いところであります。
また、データマイニングの技術が、マーケティングばかりでなくソフトウェア工学でも積極的に用いられている事も、大切な事実であるとも理解しています。とりあえず、手元のRでゴリゴリっとやり始めてみても、いいかもしれませんね。
それでは皆様、ごきげんよう。
