はてなのMackerelが明かす、機械学習プロジェクトに潜む2つの「不確実性の山」を乗り越えるコツ：手掛かりは「スクラム」「ゲームソフト開発」（1/2 ページ）

2019年8月29〜31日に開催された「builderscon tokyo 2019」のセッション「われわれはいかにして機械学習プロジェクトのマネージメントをすべきか」で、はてなの「Mackerel」のディレクターが機械学習技術の開発における「不確実性」のマネジメント術を説明した。

[高橋睦美，＠IT]

　機械学習（ML）や人工知能（AI）には何となくかっこいいイメージがある。ただ「その開発はとても泥臭いもの。そして、新しい分野だけに、従来のソフトウェア開発のアプローチとは別の考え方をする方がうまくいくのではないか」――2019年8月29〜31日に開催された「builderscon tokyo 2019」のセッション「われわれはいかにして機械学習プロジェクトのマネージメントをすべきか」で、はてなの粕谷大輔氏（@daiksy）が登壇。主に、サーバ管理／監視サービス「Mackerel（マカレル）」のディレクターとしてML技術の開発に携わった経験を踏まえながらML技術の開発における「不確実性」のマネジメント術を説明した。

　「ソフトウェア開発のマネジメントとは、不確実性の制御である」と、粕谷氏が指摘するように、ソフトウェア開発はさまざまな不確実性をはらんでおり、予想通りに進捗（しんちょく）することは少ない。いわゆる「不確実性コーン」の図が示すように、「初期工程では工程の見積もりに4倍程度のばらつきがある」といわれる。もちろん後の工程になればなるほどばらつきは収束し、スケジュールの見通しに確実性が生まれていく。

Software Costing and Sizing Accuracy vs. Phase（『The Cocomo 2.0 Software Cost Estimation Model』（PDF）から引用）

　ところが「MLプロジェクトの場合は必ずしも不確実性コーンが当てはまるとは限らない。終盤にもう一回不確実性の山がたくさんあり、ちょうど『鼓』のような形をイメージで捉えるといいかもしれない」（粕谷氏）。一般的なソフトウェア開発と同様に前工程にも不確実性の山があるが、リリース前のチューニングやテスト工程にも多くの不確実性があり、ちょうどVの字のように2つの「高不確実性ポイント」があると説明した。

「それはそもそも、ML技術を使うべきなのか？」PoC段階に潜む不確実性

はてな 粕谷大輔氏

　まず前工程、どのようなアルゴリズムを適用するかを検討するPoC（概念）段階に「めちゃめちゃ大きな不確実性がある」と粕谷氏は述べた。

　そもそも、課題を解決するのに難易度の高いML技術を使うべきなのか、他にもっと容易な選択肢はないのか。また使うとしても課題を解決できるアルゴリズムを見いだし、適切な難易度で、現実的な計算量で実装できるのか――ここは手を動かして試行錯誤しなければ分からない部分で、「PoCの結果、答えにたどり着かずに頓挫するプロジェクトもけっこうある」（粕谷氏）のが実情だ。このため、普通のソフトウェア契約とは異なり、PoC単体で契約を結ぶ場合もあるという。

　では、はてなではどのように進めたのだろうか。

　Mackerelはサーバ監視のためのサービスだ。各種リソースの使用量やパフォーマンスにしきい値を設定して監視する他、ログにエラーが出力されていないかを確認したり、あるいはURL外形監視を行ったりと、従来の伝統的な監視手法を実装し、異常があればSlackなどで通知してくれる。

Mackerel（講演資料から引用）

　だが、「それ以外の方法でサーバの異常を検知したい」というニーズがあった。ただ、サーバ異常の検知には、サーバの種類や性質の違いを理解したり、アプリケーションの設計思想を踏まえたりと、さまざまな専門的な知識や経験が求められる。粕谷氏は「そこをML技術によって補助し、専門的な知識を持たなくても異常を検知できないか」と考えた。そこで検討したのが、ML技術を活用した「ロール内異常検知」機能だった。

　Mackerelでは、サーバの役割をWebやデータベースといった「ロール」として定義し、それぞれに異なるメトリックを設定している。粕谷氏は「ロールごとに普段の傾向を把握し、過去の傾向から逸脱したものがあればアラートを発することで、専門的な知識がなくても異常を検知できる」と考えた。そして「普段の傾向」を学習し、差分を取ってくる部分と相性が良かったのがMLだと判断した。

　こうしてPoCのステップに進んだはてなでは、まず過去の障害事例を集め、さまざまなMLアルゴリズムを適用し、「どのアルゴリズムが良い結果を出してくれるか」「難易度や必要な計算量はどのくらいか」を、プロトタイプを作りながら確認していった。

　「このプロセスでは『優秀なMLエンジニアをアサインして要件を伝えたらいい感じにやってくれる』というのはあり得ない。非常に深いドメイン知識が必要で、課題を深いレベルで理解した上で試行錯誤しないと良い結果は得られない。この場合は『障害とは何なのか』『何をもってサーバ異常と判断するか』という知識のインプットに時間を費やした」（粕谷氏）

　こうして幾つかアルゴリズムの候補を絞り込んでいったが、Mackerelの場合はさらに幾つかの条件があった。「ただ異常を検知すればいいわけではなく、なぜ異常と判断したのか、結果が説明可能でなければならない。また、決してMLのエキスパートばかりではないわれわれが恒久的に運用し、メンテナンスできるよう、アルゴリズムの理解が容易でなければならないと考えた」（粕谷氏）

　こうした条件に基づき、複数のガウス分布を足し合わせることによって周期的な変動にも対応できる「混合ガウス分布」が有効そうだと決断。うまくPoCが成功したことも踏まえて開発工程に入り、普通のソフトウェア開発と同じアプローチで進捗を管理していった。

混合ガウス分布に基づく異常検知（講演資料から引用）