WebエンジニアからデータエンジニアになったらMLOpsやってた件

はじめに

はじめまして。データ戦略室データエンジニアリンググループの柳澤です。
昨年の7月に入社してからあっという間に1年が経ってしまいました。

簡単に自己紹介しますと、私は元々受託開発系の会社でWebエンジニアとしてエンジニアのキャリアを開始し、3年間Webアプリ開発やネイティブアプリ開発に従事した後、レバレジーズに入社しデータ戦略室にやってきました。

思えばデータ戦略室に来たときはデータエンジニアの仕事そのものよりも、仕事を通してインフラエンジニアや機械学習エンジニアの方向にスキルの幅を広げたいという思いが強かった気がします。

そんな私も、今ではすっかりデータエンジニアリングの奥深さに魅了され、どうすれば社内の人たちが利用しやすいデータになるのか、どうすればデータ加工にかかる時間を最小にできるかなど、あれこれ工夫が必要な事柄に考えを巡らせる毎日を過ごしております。

そんな弊社でのデータエンジニアの仕事ですが、自分にとって大きなステップとなったのが入社1ヶ月後にMLOpsのプロジェクトにアサインされたことでした。

MLOpsの基幹となる技術としてクラウドインフラや機械学習があり、実装ではそれらを組み合わせていく必要があるわけですが、インフラ開発の業務経験がなく、機械学習は全くの素人、それどころかPythonすら使うのはほぼ初めてという状態だったため、MLOpsの意義の大きさはなんとなく分かるものの技術自体はこれから身につけるという、挑戦への期待と不安の入り混じったスタートとなりました。

今回はこのMLOpsプロジェクトの振り返りを記事として書きたいと思います。MLOpsについて興味のある方、クラウドインフラや機械学習に関心がある方、データエンジニアの仕事について知りたい方の参考になれば嬉しいです。

そもそもMLOpsってなに？

ここまでさらっとMLOpsについて言及していたわけですが、そもそもMLOpsという言葉を皆様ご存知でしょうか？ご存知の方、流石です。
私は入社までに1回だけ耳にしたことがある程度でした（笑）
そもそもMLOpsという言葉の定義が人や組織によって細かいところが変わるため、どこまでの範囲を表しているのかを特定するのは非常に大事なことです。

MLOpsは比較的新しい概念で、エンジニアリングにおけるDevOpsの考え方を機械学習にも採用してモデルの開発・運用を効率的に実現しようとするものです。

まずMLOpsプロジェクトの中心には機械学習を用いて実現したいサービスが存在しています。今回のプロジェクトにおいてはSA360を用いて運用型広告の最適化を実現することがそれにあたります。

SA360はGoogle社が提供している、有償の広告最適化ツールです。詳しく知りたい方は弊社のデータサイエンティストの方がブログ記事にしてくださっているので、そちらをご覧ください！

このような中心となるサービスの開発を効率化して手動で作業しなければいけない部分を少なくする。そして本番環境にてサービスが安定稼働をし続けることを今回のMLOpsプロジェクトでは目指しました。

MLOpsアーキテクチャ

MLOpsを実現するサービスは色々ありますが、レバレジーズではAWS SageMakerを主に利用しています。
Webアプリケーションに馴染みのある方にとってはRuby on RailsやLaravelに相当するようなフレームワークをイメージしてもらえると良いかもしれません。

今回のMLOpsにおいてはSageMakerで2つのパイプラインを作ることになりました。推論パイプラインと学習パイプラインです。
以下では2つのパイプラインについて順番に見ていきます。

推論パイプライン

SA360との連携にはバッチ処理で1日1回機械学習モデルに推論を実行させることを想定していたため、SageMakerでのアーキテクチャはWebサーバーのようなエンドポイントではなく、ジョブを作ってパイプラインにつめて定期実行するという構成になりました。
これが1つ目の推論パイプラインとなります。

推論パイプラインの構成はシンプルで、SageMaker ProcessingJobをSageMaker Pipelineにいれて、AWS EventBridgeを用いてパイプラインを定期実行するというものです。

この構成の特徴としては実装が容易であることが挙げられます。

SageMaker ProcessingJobは他のジョブと比べてもかなり柔軟な使い方ができるものであり、実行に制約が少ないのが利点です。

今回の対応ではリリースまで時間も限られていたため、データサイエンティストがローカル環境でテストのために実行しているソースコードをあまり手を加えることなく本番環境でも利用できることは魅力的でした。

学習パイプライン

機械学習モデルは1回作ればあとは放っておいても良いというものではありません。推論の精度を落とさないためにもモデルには定期的に再学習をさせてやる必要があります。

例えばコロナ前とコロナ後で社会が変化しましたが、そのような変化が反映されたデータをもとに学習を繰り返し行われなければ、機械学習モデルも古くなり実情と合わない推論ばかりすることになってしまうでしょう。

このため、モデルの再学習を実行する環境が必要になりました。この役割を担うのが学習パイプラインです。

パイプライン自体は推論パイプラインと同じSageMaker Pipelineを使いますが、中身はSageMaker TrainingJobやSageMaker ProcessingJob、それからパイプライン内での条件分岐や再学習されたモデルの保存を行うステップ(ConditionStep、ModelStepなど)で構成されています。

パイプラインの中身を大まかに分けると
「データ取得と前処理」「モデルの学習」「モデル精度評価と保存」
この三つに分けられそうです。

「データ取得と前処理」ではBigQueryからデータを取得し、特徴量作成のような前処理を行っています。学習時に使う教師データや、学習済みモデルの精度評価時に使うテストデータがここで準備されます。

「モデルの学習」では実際にモデルに学習を行わせます。学習が完了したモデルは推論で実行しているようにデータに対してスコア予測が可能となります。しかし、それらの予測が高い精度を持っているかのチェックが別で必要となります。

「モデル精度評価と保存」では上述のような精度のチェックを行っています。テストデータと言われる精度チェック用のデータを用いることで、過学習と言われるような学習用のデータにモデルが特化してしまっていないかを判断します。

そしてここでも問題なく高い精度での推論が確認できたら最後にモデルを保存します。モデルの保存にはSageMaker Model Registryを利用しており、保存されたモデルの最新版が推論パイプラインでも利用される流れとなります。

ここが難しい！Webエンジニアが見た面白さと大変さ

SageMakerを利用してMLOpsを実現していくのは、すごくやりがいのある内容だったのですが、Webアプリ開発をしていた頃と比べると色々と困惑することもありました。

機械学習の経験がある方にとっては何を当たり前なことを…と思われるかもしれないのですが、何もかも初めての状態で入り込んでしまった私にとっては結構なパニックです。

特にこんなに違うのだなと思ったのはテストについてです。

私がWebエンジニアとして理解していた「テスト」とは、APIのレスポンスや画面の表示が入力内容に対して適切かどうかをチェックするものでした。
Aという入力でリクエストしたら必ずBというレスポンスが戻ってくる。それを自動テストとして作っておいて確認。非常にシンプルで分かりやすいものだったなと思います。

しかし、機械学習の世界はそれではうまくいきません。モデルが推論する結果がAのときもあればBのときもあるしCかもしれない。そのようにモデルが学習した内容によって推論結果はどんどん変わるし、時間が経ってデータの質が変化したら当初は正しいとされていた推論結果も間違いになってしまうかもしれない…
こんな世界でどうやったらテストができるというのか？そんな気持ちになったのを覚えています。

実際のところ機械学習でのテストには「精度」を用いており、過去の実際のデータと照らし合わせてモデルが正しい予測結果を出せているかを確認しています。詳細は省くのですが、今回のMLOpsにおける精度のメイン指標はPR-AUCであり、実際の過去データを利用して出されたこの指標が一定の値を超えていれば、モデルの推論精度は高いと判断できるわけです。

このように機械学習プロダクトにおけるテストは複雑で、テストをするためにも実際の結果となるデータが集まってくるまで待たなければなりません。
Webアプリケーション開発をしていた時には、テストのためのタイムラグがあるなんて考えたこともなかったので非常に難しく感じましたし混乱もしました。

しかし、精度計測の指標がいくつも存在しており、それらを駆使することでモデルの質を担保できるというのを理解できた時、MLOpsに向き合うのが一層楽しくなったように思います。モデルの精度を上げるために努力するデータサイエンティストが、多くのテストを短時間で実行できるようMLOpsの構築をしてサポートしていく。このような具体的な目標が見えてきたことで、どうすれば自分がプロジェクトで役に立てるのかをイメージできるようになったからなのかもしれません。