AIBR プレミアム
拓海先生、部下から「MapReduceのジョブのCPU消費を事前に予測できる論文がある」と聞きました。正直、MapReduceって名前しか分からなくてして、うちの生産現場に関係あるのか見当がつきません。
素晴らしい着眼点ですね！MapReduceは大量データを分散処理する仕組みで、ジョブごとのCPU使用量をあらかじめ予測できれば、クラウドや社内サーバーのリソースを無駄なく配分できるんですよ。
なるほど。投資対効果で言うと、無駄なサーバーを増やすより予測で削減できれば助かります。しかし、経営判断で使えるほど正確なんでしょうか。
大丈夫、一緒に見ていけば分かりますよ。要点は三つです。第一にこの手法はジョブ全体の総CPU使用量を『事前に』予測することを目指す点、第二に入力はマッパー数とリデューサー数という設定パラメータで十分と考える点、第三に線形や多項式回帰でモデル化している点です。
これって要するにジョブの総CPU使用量を事前に予測できるということ？もしそうなら、クラウドのインスタンス数を抑えられると理解して良いですか。
その通りです。もっと正確に言うと、同じ種類のジョブを過去にいくつか試行してCPU使用量の傾向を学習し、その傾向から新しい設定での消費量を推定するのです。現場で使うときは、まず代表的なジョブのトレースを取る必要がありますよ。
トレースを取るのは現場に負担がかかりそうです。どれくらいの試行が必要で、誰がそのデータを見ればいいのか、現実的な運用面が気になります。
現場負荷は確かに考慮点です。まずは代表的な三つから五つのジョブで、各ジョブを異なるマッパー・リデューサー数で数回実行して総CPUを記録するだけで初期モデルは作れます。実務ではIT部門か外注がその収集と回帰モデル構築を担えば十分です。
精度の話もしてください。論文は多項式回帰を使ったと聞きましたが、複雑な作業では外れが出るとも。現場での誤差が大きければ意味がありません。
正直に言うと論文の手法はジョブの性質次第で効果が変わります。単純に集計するジョブ（例: WordCount）は多項式回帰でかなり良い予測が得られるが、TeraSortのような複雑な処理では精度が落ちる。だから運用では最初にジョブをクラスタ分類して、単純なジョブには回帰モデルを、複雑なジョブには別のモデルを当てる運用設計が必要です。
つまり、万能ではないが使いどころを見極めればコスト削減に寄与する、と。導入にあたっての優先順位はどう考えれば良いですか。
優先順位は明快です。第一に頻繁に実行する定型ジョブ、第二にクラウド利用でコストが直結するジョブ、第三に試行データが取りやすいジョブから着手する。これで初期投資を小さく抑えつつ効果を出せますよ。
分かりました。自分の理解を整理させてください。要するに過去のジョブ実行データから、マッパー数とリデューサー数という設定で総CPU使用量を回帰モデルで推定し、単純なジョブでは十分に使えるが複雑なものは別手法が要る、と理解して良いですか。
素晴らしい要約です！その理解で現場に提案すれば十分伝わりますよ。大丈夫、一緒に計画を立てて初期トレースから始めましょう。
