AIBR プレミアム
拓海さん、最近部下から「マイクロサービスの遅延を機械学習で予測して対応すべきだ」って言われて困っているんです。正直、何がどう問題で何を導入すれば投資対効果が出るのか見当もつかなくて。
素晴らしい着眼点ですね！まず結論を言うと、該当の論文Seerは「過去の大量トレースデータを使って、サービス品質（QoS: Quality of Service）違反を事前に察知する」仕組みを示しているんですよ。結果としてダウンタイムやユーザー不満を未然に防げる可能性があるんです。
なるほど。で、それって導入コストに見合うんでしょうか。現場はまだExcel中心で、クラウドや分散トレーシングなんて触ったことがありません。
大丈夫、一緒にやれば必ずできますよ。要点を3つにまとめると、1) トレースデータは既に多くのクラウドで取れている、2) Seerはそのデータから「近い将来の問題」を予測する、3) 予測があれば先回りしてリソース調整やトラフィック制御が可能である、ということです。
これって要するに障害の予知ということ？もしそうなら、予測の精度が悪ければ現場の信頼を失いそうで怖いんですが。
素晴らしい懸念ですね！予測の信頼性は最重要です。論文ではまず「予測してから対応できるだけの余裕（slack）」があるかを重視しており、さらにどのマイクロサービスが原因かを指し示すことで、無駄な対処を避けられる設計になっています。
なるほど。で、現場の負担はどれぐらいでしょう。ログを全部クラウドに上げるとか、運用チームの手間が膨らみそうで心配です。
現実的な視点も素晴らしい着眼点です。Seerの実装では分散トレーシング（distributed tracing）を使い、RPC（リモートプロシージャコール）やRESTの到着・出発時刻を記録して中央データベースに集約します。トレースの処理オーバーヘッドは論文で0.1%未満と評価されており、常時の負荷増大は限定的です。
なるほど。導入するとしたら、まず何から始めるべきですか。小さく始めて成果を示したいのですが。
大丈夫、順序立てれば小規模で実証できますよ。まず1) 代表的なサービス一つに分散トレーシングを導入し、データが取れる環境を作る、2) Seerに相当する予測モデルをそのデータで学習させて「どのくらい先に」予測できるかを評価する、3) 精度とアクションの関係を示してから拡張する、という流れです。これで初期投資を抑えつつ効果を確認できますよ。
わかりました。拓海さんの言い方だと安心しますね。要点を私の言葉で言うと、「まず小さなサービスでトレースを集めて、機械学習で問題が来る前に教えてもらい、その結果でどう動くかを決める」ですね。
