はじめに
こんにちは。 CX部門 データ・AI戦略室 データ戦略Gの田中です。
ぐるなびには2018年に新卒として入社し、レコメンドエンジンの開発や在庫・予約関連のデータ分析等に携わってきました。
現在は主に検索結果の並び順アルゴリズムの改善を行っています。 私たちのチームではアルゴリズム自体の改善に伴い、MLOps（機械学習の運用改善）にも取り組みました。
今回は、
- MLOpsとは
- どうやって導入したか
- 導入で何が得られたか
についてお話ししていきたいと思います。
検索アルゴリズム改善プロジェクトについて
検索の並び順アルゴリズム改善のプロジェクトが始まったのは約2年前でした。 それまでの並び順は複雑なルールベースで決められていました。 そこで機械学習のモデルを用いてより効果的な並び順を予測し、検索結果の改善・CVRの向上を試みました。
2020年の2月からプロジェクトがスタートし、3月に初めてのPoCを実施しました。1回目のPoCはちょうど緊急事態宣言の発令と重なりアクセス数の急減などで思うようにいきませんでしたが、7月に改めてPoCを行いました。 その後、9月に初めて機械学習モデルを用いたABテストを実施し、10月に本番リリースを行いました。この機械学習モデルのリリースはぐるなびの中で初めての大きな機械学習プロジェクトとなりました。 本番リリース後はABテストを数回実施し、最初のリリースから1年後の2021年11月に機械学習モデルを用いた並び順の適用範囲の拡大を行いました。
MLOpsの導入も機械学習モデルの最初のリリースに向けて進められ、2020年10月のリリースの段階でGoogle Cloudが定めるMLOpsのレベル1、翌年のリプレイスに伴うアップデートの段階でレベル2を達成しています。
MLOpsについて
そもそもMLOpsとは何か？というところからお話しします。
MLOpsという言葉を聞いたことがなくてもDevOpsについては聞いたことがある人が多いのではないでしょうか。MLOpsはDevOpsのML（Machine Learning: 機械学習）版と考えてもらっていいと思います。機械学習プロジェクトの開発・運用を統合し、ワークフローの効率化を図るものです。
では、なぜDevOpsをそのまま機械学習プロジェクトに適用するのではなくMLOpsという概念が必要なのかというと、データセットの構築やモデルの実験・デプロイなどにおける機械学習特有の課題についてはDevOpsのみでは考慮しきれないからです。その結果、機械学習プロジェクトに特化して効率化を図るMLOpsという概念が生まれました。
まずは機械学習プロジェクトのワークフローについて簡単に説明し、実際にどんな課題をどうやって解決していったかについて話していきたいと思います。
レベル0: 手動プロセス
今回の検索アルゴリズムの改善における機械学習プロジェクトの基本的なワークフローについて図にしてみました。 これらのビルド・デプロイ全てを手動で行っている状態がレベル0とGoogle Cloudは定めています。
私たちのチームでも最初のABテスト実施時はレベル0の状態でした。データマートの作成のみ、日次のスケジューラ で動かしていましたが、モデルデプロイを手動で行っている状態でした。そして、手動で行うモデルデプロイには大きな課題がありました。
デプロイの煩雑さ
ABテストを行う際の並び順スコアの更新については、学習モデルの性能評価とデプロイ、推論処理、生成されたスコアの取得、加工、検索エンジンへの連携の全てを手動で行う必要がありました。
これらのプロセスにはある程度の時間を要したのでスコアの更新は週に1回程度が限界だと考えました。これではせっかく機械学習でよい精度のモデルを開発しても最新の状態が反映されませんし、手順が多いのでヒューマンエラーも起きやすい状態でした。
検索結果の表示順スコアのように学習データの更新頻度が高く、それに併せてモデルも高頻度で再学習する必要がある機械学習のプロジェクトにおいては、モデルのデプロイが容易に行えることが運用面で特に重要です。
レベル1: パイプラインの自動化
レベル0の状態でABテストを行った結果、モデル自体の性能はよいものの運用面で改善すべき点が多くありました。
そこで、まずはモデルデプロイの自動化を目標にGoogle Cloudの環境を構築しました。 他のクラウドサービスではなくGoogle Cloudを選んだ理由としては、アクセスログを含む学習データのほとんどがBigQueryで管理されていたことが大きな理由です。
最初に構築したワークフローは、Cloud Schedulerからモデル学習・推論用のVMインスタンスを立ち上げコードを実行するという単純なものでした。ABテスト時の課題であったモデルデプロイの煩雑さは解消され、毎日スコアを連携することができるようになりました。 このように機械学習モデルの学習から推論までのパイプラインが自動化されている状態はレベル1と定められています。
運用面で大きな改善があったおかげで、初めての機械学習プロジェクトのリリースに繋がりました。ただこの段階でもまだまだ課題がありました。
リカバリ・再実行時の手間
1つ目に、データマート生成・スコア作成・スコアの連携のそれぞれのフローは自動化されたものの、お互いに独立した実行トリガーを持っているため、いずれかの処理が失敗した際のリカバリ処理に手間がかかりました。最初のデータマート作成時に失敗していた場合、3つの処理を手動で再実行しなければなりませんでした。またいずれかの処理にバグがあれば、欠損データで学習したモデルがデプロイされてしまったり性能のよくないスコアが反映されてしまう危険性もありました。
実験管理の難しさ
2つ目に、コードのデプロイが自動化されていないために、実験管理が難しくなっていました。 検索アルゴリズムに最適なモデルをリリースするまでには、いくつかのデータセット・機械学習モデル・パラメータで実験を行い、オフライン性能がよかったものをABテストで試し、その中で結果がよかったものを採用しています。
しかし、レベル1の状態で実験を行うには管理がとても大変でした。 どのモデルがどんなデータセット・パラメータを用いたものなのか、いつ時点でのモデルなのかをきちんと管理するのは煩わしいものでした。
レベル2: CI/CDの自動化
機械学習モデルのリリースが終わり、さらなる精度向上・対象範囲の拡大のためには実験を多くこなしABテストを繰り返すことが必要となりました。 そこで実験管理がしやすい環境を目指してAI Platform Pipelinesを導入しました。
AI Platform PipelinesはGoogle Cloud上でKubeflow Pipelinesを簡単に利用できるサービスで、クラウドネイティブな機械学習プラットフォームです。Kubernetes上で動く機械学習のワークフローをGUIの操作から簡単に構築することができます。
コードのデプロイに関してはGitlab CI/CDも用いて自動化しました。
実験結果自体はブラウザで一括閲覧できますし、実行時のIDとコミットハッシュを紐付けているため、オフラインでの性能が良かったモデルがどれだったかを簡単に確認することができます。これによって実験管理が格段にしやすくなりました。
そして、実験管理が容易になったことで気軽に新しい特徴量やパラメータを試すことができるようになり、アルゴリズム改善のスピードが速くなりました。ソースコードの管理やデプロイの煩わしさがなくなり、バグの修正やマイナーアップデートが負担なく行えるのでモデルの性能を向上させることに集中できるようにもなりました。
データマートの作成、スコアの生成、スコアの連携のそれぞれの処理も連動するようにしました。検索エンジンの取り込み用のDBとGoogle Cloudの専用ネットワークの用意がコスト面で難しかったため、連携にはAWS環境を介す必要がありました。この連携フローは今後改善していきたい点です。
コスト削減とメンテナンスの負荷軽減
AI Platform Pipelinesの導入後の課題として、コストが高額な点がありました。これは実行用のGoogle Kubenetes Engine（GKE）が常に立ち上がっている状態になっていたからでした。この問題を解決するにはAI Platform Pipelinesの後継サービスであり、フルマネージドなVertex AI Pipelinesへの移行が必要でした。
11月のリリース以前からすでにVertex AI Pipelinesへの移行が推奨されていましたが、このリリースでは検索エンジンのリプレイスとタイミングを合わせること、CI/CDの自動化を優先事項としていたため、移行を見送りました。
そして、リリースから3ヶ月後の2022年の2月にVertex AI Pipelinesへ移行しました。
このタイミングで移行したのはコストカットに加えて、Google Kubenetes EngineクラスタやKubeflowのメンテナンスが難しくなったことも大きな理由でした。最初にリリースした際に作成したクラスタのバージョンが古くすでにサポート対象外となっていたため、起動中のクラスタ以外にKubeflow Pipelinesを新しくデプロイできない状態にありました。
Vertex AI Pipelinesに移行した結果、Google Kubenetes Engineの立ち上げ時間が24時間フル稼働から1日あたり1〜2時間程度に短縮されました。コストは稼働している時間のみの課金になったため、およそ89.4%の大幅なコストカットをすることができました。またクラスタやKubeflowのメンテナンスをする必要もなくなりました。メンテナンスが不要になったことで他のプロジェクトにKubeflow Pipelinesを導入するハードルも下がりました。さらに、実験結果の確認もよりわかりやすくなり開発のスピードアップにも繋がりました。
まとめ
私たちのチームで取り組んできたMLOpsの導入・改善について順を追ってお話ししてきました。これまでの話をまとめると以下のようになります。
- MLOpsとは
- 機械学習プロジェクトの開発・運用にあたってワークフローの効率化を図るもの
- どうやって導入したか
- 最初から最高レベルを目指さず改善できるところから取り組む
- その時にある一番大きな課題を解決することを目標とする
- 導入で何が得られたか
- 運用が簡易になったことで初めて機械学習プロジェクトのリリースができた
- 開発の効率化によってアルゴリズムそのものの改善に注力できるようになった
今後もぐるなびでは機械学習プロジェクトをどんどん進めていきたいと考えています。そのためにも今回のMLOpsの導入はとても意義のあることだったと感じています。最後に、今回のプロジェクトにおいて多大なご協力を賜った皆様に感謝いたします。
