Google Cloud Next '22 の MLOps セッション書き起こし
MLOps Advent Calendar 2022の23日目のエントリ、そしてGoogle Cloud Japan Advent Calendar 2022の24日目のエントリです。
Google Cloud Next '22 の MLOps関連セッションの内容を書き起こしました。長い。登場するのは以下の皆さまです。
本当はスライド画像も貼りたかったのですが、文字起こしで力尽きてしまいました。。スライドをご覧になりたい方は、セッションタイトルからリンクされているYouTube動画をご覧ください。
MLOps と Vertex AI について語る会
（Google 佐藤）MLOpsとVertex AIについて語る会ということで、MLOpsと呼ばれるようになった機械学習の基盤の構築ですとか運用に実際に携われてきた識者の方にお集まりいただきまして、いろいろ議論するセッションです。
最初に自己紹介していきたいと思います。私はグーグル入ってもう11年以上もうすぐ12年になります Google Cloudチームももう10年ぐらいになります。今はAIや機械学習系のプロダクトに関するデベロッパーアドボケイトというプロダクトチームとお客様のデベロッパーコミュニティの間に入って情報交換をする、こういったイベント登壇したりブログを書いたりということをやっています佐藤一憲と申します。では続いて杉山さんお願いします。
（Citadel AI 杉山）はい、杉山と申します。Citadel AIというところでソフトウェアエンジニアとしてプロダクト開発に携わっていたり、こういったイベントで登壇してMLOpsに関する情報発信などをやっています。もともとはiOSエンジニアだったんですが、機械学習を使い出して使うのが難しいなって言ってたら、いつのまにかそれが本業になってたみたいな形です。
（CADDi 河合）CADDiという製造業ITベンチャーでテックリードをやらせてもらっています河合と言います。私はCADDiのAI LabというAI組織のゼロからの立ち上げだとか、MLOpsの文脈で言うとアーキテクトのような立ち位置で開発をやっていたり、あとはもともとは MLエンジニアとしてモデリングもやっていたので、今日は広くいろいろなことをお話しできるかなと思ってます。
（DeNA 藤原）株式会社DeNAの藤原ですDeNAという会社にはMLエンジニアリンググループというMLOpsをやるグループが2つありまして、そのうちの一つでグループリーダーという立場でリーダーをやっております。
（MLOpsコミュニティ）田中と申します。都内のIT会社で日本やAPACリージョンのお客様向けに機械学習のコンサルタントやMLOpsを含めたソリューションの提供開発をしております。プライベートではMLOpsコミュニティの運営をやらせていただいております。今日はこの場で何か知見とか共有できたらなと思っております。
（Google 牧）Google CloudでAI/MLスペシャリストをやっています牧と言います。私は普段Google Cloudのお客様を支援する立場にありまして、Vertex AIでどのようにMLOpsを実現していくのかを支援しております。今日はそういった中から知見とか、普段どういった問い合わせが多いのか、というところをディスカッションできればなと思っています。
（佐藤）はい、ありがとうございます。ではちょっと会場の人にも聞いて見たいと思います。MLOpsを実際やってるよ、って人はどれぐらいいますか？ まあ、10%って感じですよね。
機械学習は今、実用期に入りつつあるんですが、じゃあ実際、実開発、実運用基盤の構築だとかをやってる会社さんはまだまだ少ないですね。それでここ数年ですね、MLOpsが注目を集めています。
このMLOpsってそもそも何なのかという話と、Google CloudのAIプラットフォームであるVertex AIでMLOpsやるとすればどのプロダクトをどういうふうに使えばいいのかという話をまず最初にします。
2番目はですね、実際そのVertex AIのPipelinesというプロダクトを使ってMLOps基盤を使ったり運用されている状況のお話を聞いたり、皆さんとディスカッションしてこれが足りない、これはいいね、という話をできればと思います。
最後は、これからMLOpsを本格的に導入しようと思っても、MLOpsエンジニアってちょっとまだふわふわしてない？ とか、どのチームに属せばいいのか？ とか、どうやったらなれるのか？ という疑問があると思いますので、皆さんと話し合えればと思います。
まずはMLOpsとは何ぞや、というテーマですが、ML OnAirというウェビナーをGoogle Cloudで提供していまして、つい1ヶ月前くらいに杉山さんに解説いただきましたので、そのダイジェスト版として簡単にご説明いただきたいと思います。
（杉山）はい、ではMLOpsについて話していこうと思いますが、その前にMLOpsでどんな課題を解決したいのかという一例をご紹介できればなと思います。その一つが、ここで掲げている機械学習チームの悲劇というものです。これ結構いろいろな職場で見られるパターンなので、共有できたらと思います。
機械学習のチームってまず始めるときに小さく始めていくと思うんです。小さなチームができて、PoCを行って、実際に使ってみて成果確認できてよかった、ってここまではいいんです。けれど、さらにその成果をスケールさせようとしてプロダクトに組み込もうとすると、結構課題が出てきます。
まずプロダクトに組み込もうとすると、開発ですとか運用設計が必要になるので、そのタスクが作成されて見積もりされるけれど、その見積もりってどうしても大きくなりがちです。他の機能と比べて機械学習ってまだまだ新しいものなので、不確定な分どうしても見積もりが大きくなってしまう。定型的な他の機能開発の方が見積もりが小さいので優先度が上がり、機械学習の成果がなかなかプロダクトに組み込まれず成果が出ない。 そうなると経営層的な目線からは、あそこに結構投資したんだけど成果できてないな、ちょっと見直すか、みたいな感じになりチームが解散してしまう。こういった悲劇が結構な現場で発生していると思います。
この原因ですが、基本的にはML機械学習チームとDevOpsチームがあった時に、互いに対立してたんですね。機械学習チームって機械学習の成果をどう組み込んでいけばいいかうまく説明できないし、システムがわからないが故にDevOpsチームはシステムは分かるけど機械学習がわからない。それをどう組み込んでいけばいいかわからない。こんな対立があると成果が出ないので、これを変えていこう、互いに協業するような形に変えていき成果をスケールさせよう、というのがMLOpsです。
このMLOpsですが、やろうとするとすごく難しいことが知られています。これは機械学習に関わる方なら何回も見たことがあると思いますが、機械学習というのは一つ導入しようとするといろいろな困難がつきまとうという図です。黒いところが機械学習のコードで、書いたことある方ならわかると思うのですがコード自体はすごく小さいのですね。小さいのですが、それを生かそうと思うと、すごくいろいろなことを考えなければいけないです。
例えば、データを収集するパイプライン、ETLどうするとか、その収集したデータは正しいのか検証しなきゃいけないとか、GPU、CPU、メモリ等、結構使うのでそのリソース管理どうするのか、インフラどうするのか、監視って何を監視したらいいんだろうか、みたいなところを全部考えていかなきゃいけない。これが総体として見ると複雑になってしまう、というのがこの図です。
それを整理したのが次の図です。僕が多分世界で一番好きな図なのですが、TFXという論文がありまして、これをパイプラインとレイヤーの形で整理したのがこの図になっています。
機械学習の一連のタスクというのをこういうふうにコンポーネントとして整理して、それを逐次実行していくパイプラインとして整理した。その下を見るとストレージ等のプリミティブなレイヤーがあり、対して上にはアクセスコントロールや、パイプラインの実行管理やオーケストレーションが必要だよね、設定のフレームワークも必要だよね、さらに上にはフロントエンドが必要だし、モニタリングやデバッグ、あとはデータの可視化が必要だよね、っていう。こういうところをきれいに整理したのが、TFX論文の大きなコントリビュートだと思います。
このTFXの図はGoogle社内の機械学習基盤の設計図を表していて、その機械学習基盤をひとつずつサービスとしてリリースしてきているのがVertex AIだと思います。先ほどのいろいろなコンポーネントに相当するサービスが一つ一つ出てきているので、これを繋ぎ合わせたり、自社のワークフローに合わせてカスタマイズして使っていくのがVertex AIだと思います。
ここが一番僕の言いたいところなんですが、機械学習の運用というとどうしても難しいですとか厳しいとか辛いとか、そういったイメージがありがちなのですけれども、楽しい仕事にしたいなというのが僕の考えです。機械学習プロジェクトって、そもそもAIは育てるものだと思うのです。まだ今は精度が出ていないし賢くないけれど、これから使っていくとだんだん賢くなっていくのですと、僕はいつも言っていたんです。そう言って乗り切ってきたんです。始めた時には確かに精度悪かったのですけど、サービス運用していくことでだんだんデータが貯まり賢くなるっていうのを見ていく。これがすごく楽しいことなんです。なのでMLOpsっていうのは、厳しいとか辛いとかではなく、AIを育てる活動なんだと今後いろいろなところで言っていきたいと思っています。
ここがDevOpsとMLOpsのポイントをまとめているスライドなのですが、左側がDevOpsで右側がMLOpsに関するものです。歴史を振り返ると、DevOpsはDevとOpsの対立を解消して、対立ではなくて協業する形で成果を出していこうというものでした。MLOpsも全く同じで、開発運用しているチームと機械学習チームの対立ではなく、協業する形で成果をスケールさせていこうという取り組みです。
DevOpsの文脈ですと、やはり有名なのはGoogleのSREですよね。ここでは日々の定期的な運用業務のコードによる自動化に取り組んでいるのですが、MLでこういうことをやろうとするとやっぱり難しいところはあります。ユーザーのフィードバックっていうのをちゃんと利用できればいいんですけれど、どうしてもうまくフィードバックは利用できないとか、かえってバイアスが入ってしまってサービスとして変なものになってしまう、ということが発生する箇所もあります。
かといって、全然取り組みが進んでいないかというとそういうわけではなくて、先ほどTFXの図でお見せしたような機械学習パイプラインについては自動化がかなり進んできたかなと思います。それもKubernetesのクラスタを立ち上げるとか、サーバーを自分で立ち上げて管理するという形ではなくて、Vertex AI Pipelinesの話がこの後にありますけど、そういったマネージドなサービスを使いながら機械学習の様々なものを自動化していくというのが、ここ最近進んできたのかなと思います。
（佐藤）はい、ありがとうございます。では、ここまでご説明いただいた観点で皆さんのご意見も聞いてみたいと思います。あ、目が合いましたね、DeNAの藤原さん。
（藤原）目が合うとなんかやらされるんですか（笑）。
（佐藤）そうなんですよ、目をそらさないでください（笑）。こういうDevOpsとMLの統合とか融合という意味では、国内ではDeNAさんが進んでる印象があるのですが、簡単に概要をご説明いただいて、ご意見ですとかお話しいただけると。例えば、さきほどMLOpsのチームがあるとおっしゃってましたけども、最初はなかったわけですよね。どうやって生まれたのか等を説明いただけますか？
（藤原）僕が入社をした段階ではチームの箱という意味では結構整っていたんですよ。DeNAという会社の場合、データサイエンティストはアルゴリズム屋さん的なポジション、MLエンジニアはMLOpsのポジション、っていうのがもう僕が入社した3年前の時点であったんです。
（佐藤）かなり進んでる会社だったんですね。
（藤原）そういう意味では、そこの成り立ちはあまり参考になる話ができるわけではないです。ただ、最近ちょっと困ってるというか嬉しいことなのですが、データサイエンティストの人たちがMLOpsにちゃんと興味を持って取り組んでくれるケースが出てきているので、わりと境界が難しいなという課題を感じてます。
（佐藤）境界というのは?
（藤原）データサイエンティストがどこまでやるのですか、という。DeNAではMLOpsやる人をMLエンジニアって呼んでいるのですが、 MLエンジニアはどこまでやるのですか、っていう責任分界点がエンジニアリング側にずれ込んできているので、そのあたりどうやるのがいいのか模索中だったりします。
これまでは割とデータサイエンティストという冠がつくと、モデル作るところはノートブックで作るけど、それ以外のことはよろしくね、コンテナが出てきたらあとはDevOpsの人へ、って感じだった。それが今はコンテナ化やインフラの周りも考えられる、また書ける人が増えつつある。それも人によってどこまで興味があるか、どこまでやりたいかは割と違うし、アルゴリズム屋さんだったらアルゴリズムのスペシャリストでありたい、っていうのも別に全然間違ったことじゃない。エンジニアリングをここまでやりたいっていう人に対しては自由にできる形でサポートしてあげたいと思いつつ、結構難しいなと思ってたり。
（佐藤）そうですね、マネージャーのスキルが要求されますよね。一人一人のレーダーチャートみたいなのを把握して。このプロジェクトはインフラ系に強い人があまりいないからこの人をアサインしよう、とか考えなきゃいけないですね。なるほど。河合さんの現場ではどうでしょう？ 今まさしくMLOpsチームを作っているところですね。
（河合）そうですね、うちはMLOpsチームを3ヶ月前くらいに立ち上げたのですが、そこで活動しているメンバーは、先ほど藤原さんがおっしゃられたような、いわゆるデータサイエンティストでモデリングをしている人たちです。極端な例を言うと、例えばKaggleのGrand Masterだったり、世界トップ100とかに入るようなメンバーがMLOpsインフラを作るところをやってたりします。ですので、本当に境界はなくなって行くだろうなと藤原さんの話を聞いて思いました。
一方で、やはりMLOpsって難しいと先ほどおっしゃられた通り、最初の60%くらいまでは専門的な知識がなくても行けても、最後例えばデータを連携させるだとか、Human in the loopの文脈でモデルが出した結果を人が見てもう一回データを追加して学習して、みたいなことまで考え始めると、やはりアーキテクチャやDevOpsについてより一層専門的な知識が必要になってくる。あるところまでは行けるが、どこかで切り分けないといけないみたいな意識が今ちょうどうちのチームでも出てきてます。
（佐藤）単純にパイプライン組むだけだったらできるけど、さらにもう少しレベルが高いところを目指そうとすると、MLのこともよく分かってなきゃいけないし、そもそもモデルの再学習ってどういうタイミングでどういう形でやらなきゃいけないのかとか、かつそれをKubernetesでやるとPodはどういう動きをしてどうモニタリングしてとか、どんどんハードルが上がっていくという状況ですね。
私自身は2018年ぐらいにMLOpsというキーワードを使い始めたのですが、その時に読んだのは先ほどご紹介いただいたGoogleの論文です。そこですごく面白かったのは、単純にDevOpsを持ってくるだけじゃダメだと。例えば機械学習モデルの設計のところも、単純にDeepモデルを持ってくるのではなくて、例えば凸最適化ができる、つまり誰が何回どういう条件で学習しても同じ最適なモデルが出来上がるシンプルなモデルを使った方がトラブルシューティングや運用現場での対応が簡単になる、といったことが書いてあって、いやこれ単純にDevOpsを持ってきてデータサイエンティストと連携すればいいという話じゃないなと。場合によっては、モデル設計の段階から運用のことを考えて設計しなきゃいけないね、という側面もあり、面白い話題と思っています。
では、このあたりで次の話題に行きますか。実際にそのMLOpsという課題があって、それをプロダクトを使って導入した事例を見ていきたいと思います。
まずは私の方から、Vertex AI Pipelinesってどんなプロダクトかを紹介したいと思います。先ほど出てきたTFXというのはTensorFlow Extensionの略で、Google社内で実際にTensorFlowを使って実運用の環境を構築したり運用するためのフレームワークです。その論文が出たのがMLOpsの普及の非常に大きなきっかけでした。そして、それをそのままプロダクトに持ってきているのがVertex AIであり、Pipelinesはその全体のオーケストレーションツールです。
まずデータをBigQueryなりCloud Storageから持ってきて、それに対してDataflowですとかBigQueryを使ってもいいのですがデータの変換をしたりきれいにしたり特徴量抽出をしたりということをやって、場合によってはデータの検証もすると。学習する前に分布をチェックする。学習で出来上がったモデルの振る舞いもチェックし、そしてプロダクションのサービングの環境にデプロイするという一連の流れがあります。これを自動化して、Infrastructure as a Codeとして誰が実行しても同じ学習やデプロイメントができる流れをコードで定義して、かつその内容を後で監査したりガバナンスを効かせるようにデータベース化する、という仕組みがこのVertex Pipelinesの基本的な考えです。
ベースになっているのはKubeFlow Pipelinesというオープンソースツールです。OSSといっても、結構な割合をGoogle Cloudのエンジニアが書いてます。皆さんがソースコードを見てプルリクやIssueを投げたりもできますよと。このオープンソースのツールを、サーバレス環境でボタン一つで簡単に使えるようにしたのがVertex Pipelinesという環境です。
ここでやはり一番メリットというのは、これまでデータサイエンティストによる実験やPoCのレベルだったらノートブックをポチポチ手作業で実行して、いい感じの精度のモデルが出来上がったね、って終わってたのですが、そうではなく全部の流れをコードで表現して誰でも共有して再現できるようにし、かつどれぐらいの精度のモデルがいつどういう条件で出来上がったのか、メタデータのデータベースを作って管理する。
それでガバナンスを効かせる。ガバナンスと言ってもセキュリティの話じゃなくて、例えばデータ管理の分野にもありますが、テーブルをみんな好き勝手使ったり作ったりするのではなく、ある程度のルールやプラクティスを設けてテーブルを作る、という話です。それと同じように、機械学習のモデルを継続的に作るとなったら、一体誰がどういうデータからどういうルールで作ってるのか、責任は誰が持ってるのか等々のガバナンスや監査ができるような、本当に実運用実開発で使えるような体制を作っていこうというものになっています。
このメタデータはデータベースに保存されます。これまではスプレッドシートやオープンソースの実験管理ツールを使っていた方もいたかもしれませんが、そういった形ではなくステークホルダー全員、プロダクトマネジャーからDevOpsの人まで全員が一つの Google Cloudプロジェクトの中で共有できる。特にリネージという依存関係ですね。このデータからこのモデルが出来上がって、それがここにデプロイされてる、という関係をGUI上で簡単に管理できるデータベースが統合されています。
このプロダクトをCADDiさんでは実際に導入されているということで、河合さんに簡単に概要をご説明いただけますか。
（河合）CADDiでもVertex Pipelinesを使っていて、これは先ほどのMLOpsとMLエンジニア、 データサイエンティストの役割の分担が難しいという部分をうまく解消したプロダクトになっており、それを活用しています。
これが私たちが作ったものの図です。もともとCADDiという会社はRust言語を使っていて、そのつなぎ合わせにVertex Pipelinesをかなり広く活用しています。データサイエンスと今までの資産をうまくつなぎ合わせている事例になっています。Vertex Pipelinesにはすごく良いところがいくつかあるのですが、その一つがコンテナベースでパイプラインを組める点。ここまではRustのコンテナをで機械学習に入れるデータの事前処理をして、その後にPythonのコンテナで別の処理をするという流れが実際に実現できています。
もう一つメリットは、例えばコンテナをつなげる仕組みを作るのために、バッチを組むのかCloud Runを使うのか、もしくはKubernetesにするのか等、色々な選択肢がありますが、そうした知識を持っていなくてもVertex PipelinesではPythonの知識だけでパイプラインを書けることです。データサイエンティストが「こういうパイプラインを実現したい」と考えた時にすぐに実現しやすい。
最後にもう一つのメリットは、Vertex AIという機械学習プラットフォームに組み込まれている点です。我々が使っているLightGBMやディープラーニングのモデルをサポートするコンポーネントがたくさんあり、それをストレージやBigQueryと組み合わせられる。メタデータと連携したモデルの管理も、MLエンジニアやデータサイエンティストが自分で行える状況になっています。
（佐藤）ありがとうございます。実はCADDiさんでのVertex Pipelinesの導入事例は、今回のNextスポットライトセッションでも河合さんにご紹介いただきました。私がそこで非常に感銘を受けたのが「機械学習のエンジニアがMLモデルの先に行ける」という言葉です。これについてちょっとお話いただけますか。
（河合）まさに先ほどKaggleのGrand MasterがMLOpsをやっているという話に近いんですが、KaggleのGrand Masterの方はデータサイエンスの能力はすごく評価されるのですが、逆に言うとデリバリーというか、それを実際の現場に（ひとりでは）持っていけないよね、っていうところが足枷になって、会社から評価が少し下がってしまう。もちろんスペシャリストの枠を作る方法もありますが、それができる会社は限られる。そうした枠のない会社でも、現場で活躍でき評価されるようなエンジニアにどんどん進化しているな、っていうことを今メンバーを見ていてすごく感じます。そうした変化をサポートするツールとしてVertex Pipelinesが非常に役立っていると思ってます。
（佐藤）これが例えば何もないところからやろうとすると、自分でKubernetesのクラスタ作って運用して、コンテナイメージ作って自分で運用管理って、やっぱりさすがにやらないですよね。
（河合）そうですね、結構知識が必要になってくるので、やっぱりそれやると半年くらいかかる。ところがこのVertex Pipelinesを学ぶことで、インフラに興味ある人もパッと手を伸ばしやすくなります。
（佐藤）では、このVertex Pipelinesを実際に使ってMLOpsを構築されている事例、他にどなたかご存知の方はいますか？
（藤原）DeNAでは、少なくとも僕が見ているグループでの新しい案件は大体このVertex AI Pipelinesでこなしています。もともと自前で作っていたのですが、こういう製品が出てくるのをずっと待っていました。ないので仕方がなく作っていたのですね。僕が待っていたのは、フルマネージドのワークフローエンジンです。これが今までなくて、Cloud Composerはかなりそれに近いのですが、GKEのクラスターが裏で作られて見えている状態だったりするので、見えている以上管理しなきゃという気持ちになってしまった。
（佐藤）お金かかっちゃいますしね。
（藤原）そういう意味では本当にインフラを気にしなくていいワークフローエンジンというのは、このVertex Pipelinesで初めて出てきた。今では基本的にはVertex Pipelinesに移行する方向でモリモリ動いてますね。
（佐藤）一つ前のバージョンとしてAI Platform Pipelinesという製品がありましたが、あの時は（サーバレスではなく）まだGKEが下で動いていたので、例えばデータサイエンティストが実験管理するために気軽に使えるような感じじゃなかったですよね。
ただ同時に、サーバレスだから便利だけれども、サーバレスゆえの、ここはもうちょっと頑張ってほしい点や使いにくい点はありますか? 若干SDKやAPIが変わったり、ストレージの使い方が変わってきますよね。
（藤原）まあでもあの辺はしょうがないかなという気はしていて、あと僕はあんまり気にしてないというか諦めてるんですけど、各コンポーネントの起動に結構時間かかるみたいなのは使った人から結構声として聞きますね。そこはもうちょっと速くしてほしいそうですね。
（杉山）サーバレスゆえのわかりにくいエラーっていうのは確かにあって、僕やっちゃったのがIAM周りのアカウントで必要なアカウントを殺してしまって、エラーメッセージすら出ずにパイプラインが失敗し続ける状況になって。その原因の切り分けに時間がかかったことがあります。そうした謎のエラーが出た時に、自分で原因をどこまで切り分けられるのかという点は、もうちょっとGoogle Cloudの実装でエラーメッセージをわかりやすくするとか頑張ってほしいというところです。
また、出たばかりの頃はドキュメントが足りなかったですね。サンプルもなかったですし、KubeFlow PipelinesのSDKがダイナミックに変わっている時期にVertex Pipelinesが出てきたので、ちょっと前に使えていた記述方法がVertex Pipelinesでは使えないこともあって、結構難しかった。ただ、その後にいろいろなところからサンプルが出てきたり、僕も書きましたがドキュメントが出てきたりしたので、今は結構書きやすくなってきたのかなと思います。
（佐藤）それも含めて全部OSSで何が起きているのか見ようと思えばいつでも見られる。OSSで全部詳らかになっているところはいい点ですね。
（杉山）そこはすごくいいですね。OSSですし、今後の実装についてもオープンに議論されていて、DesignDocを見れば今後何が起こるか分かったり。
（佐藤）やろうと思ったら自分でプルリク投げたり。
（杉山）そうそう、やりましたね。
（佐藤）牧さんのお客様にもPipelinesユーザーはいますよね。
（牧）私から共有させていただこうと思った点は、いま登壇してくださっている方々、どちらかというとITに関する成熟度というのが非常に高い企業様から来られている方が多いのかなと思っています。一方で、そもそもDevOps側のチームがないような企業様も結構あるのかなと。ビジネスのコアとなるところがアプリケーション（Webサービス）として存在していない場合って、DevOpsという考え方がそもそもない場合も多いです。
そうした企業で、例えばデータサイエンスのスキルを持っている方々が徐々にMLOpsに染み出していくとき、Pipelinesという製品は良いスタートなのかなと思っています。簡単な日頃の業務を自動化したり、あるいはインフラの知識はないけどスケールできる環境に簡単にデプロイできます、といった体験ができるのは、ある種（MLOps習得の）カリキュラムのようなものにもなっているのかなと思っています。
（佐藤）MLOpsの最初の一歩目として、サーバレスで手軽に始められるから最適で、一方でDeNAさんみたいにガッツリGKEでインフラ作られてたお客様もPipelinesのメリットを感じて移っていただいているケースもある。
（牧）そうですね、あらゆる文脈で使える、というところがPipelinesの魅力なのかなと思っています。
（佐藤）ありがとうございます。もう一つ、Pipelinesを使ったCI/CDのような継続学習や、そもそもモデルを再学習することのプラクティスに関するお話も伺いたいです。例えば再学習の頻度って要件によって変わりますよね。例えば音声認識モデルだったら別に毎日やる必要ないけど、商品のリコメンデーションだったら1日や1時間に1回は再学習したいかもしれない。その頻度やタイミングは誰がいつ決めるのか。もしかしたらプロダクトマネジャーが絡まなきゃいけないかもしれない。
また、再学習するときは誰がどういう役割で責任を持ってどういうトリガーを押すのか。もしトラブったときのロールバックはどうするのか。Vertex AI Pipelinesを使うとすべて自動化できますよね。精度が下がってきたらトリガーして再学習を始めて、デプロイまで自動化できます。一方で、巨大インフラを運用している現場では、Human in the loopの考え方で間に人間が入り、本当にいいんですかとチェックしてからデプロイする方法もあります。そういった役割分担ですとか、SRE立てるならSREのプレイブックどうするのかとか、再学習のコストと精度のトレードオフの問題もあります。このあたりについてはどう考えますか。
（牧）さっきのお話と少し関連するのですけど、私が日頃お話をしているお客様から最初に聞かれる質問っていうのが大体この辺ですね。MLOpsを実現していくにあたって、いま動いているモデルをどれくらいの頻度で再学習すべきなのかであったり、再学習するためのしきい値だったりルールみたいなのを、ユースケースと共に紹介してほしいと。
やっぱりプロダクションレベルでの運用経験がないと、その辺がまず自然な疑問として出てくる。おそらく皆さんの場合でも、一意な答えがないじゃないですか。ケースによっても全然違いますし、そのビジネスとか要件とかによっても変わってくる。なので、どういう思考回路と言いますか、どういった手順でアプローチされているかをお話しいただけるとありがたいと思っています。
（杉山）再学習の頻度とタイミングですが、考えることが2つあると思っています。
データが新しくなる頻度と、あとはデータを利用するときのコストですね。例えばBigQuery等にデータを置いていて、その特徴量を使う場合どれだけのテーブルをスキャンするかでコストが変わってきます。やっぱり一番やりたいのは、データが更新されたタイミングで学習し直すことですよね。ただ、それをやろうとすると特徴量としてスキャンするデータが多すぎてコストがかかりすぎる。一回10万円かかっちゃう、みたいなことになってくる。じゃあ週1くらいに抑えますか、といった話になるのかなと思います。
（藤原）再学習の頻度に関して、基本的にDeNAの場合はデータサイエンティストとMLエンジニアとサービス側事業部側の人で組んで動くので、ここはもう分かりやすくとにかく事業部側の人と握る。その3チームでちゃんと握れればそれでOKと。基本的にデータは全部BigQueryに入っているので、アクセスする時に特別コストがかかることにはなりにくい。学習にそれなりにコストがかかる場合はそれを考慮することもありますが、それよりはどれくらいの頻度でモデルが新しくなると嬉しいか、という観点で決めますね。
（佐藤）そういう判断って定量評価されているのですか？ それともPdMの人と、だいたいこれくらいでやっていきたいね、みたいな。
（藤原）定量評価がやっぱり難しくて、どうしても感覚的になっちゃいますね。
（佐藤）そろそろ（モデルが）古くなってね？って、冷蔵庫の野菜みたいな。
（藤原）そうなんですよね。モデルの評価はやっぱりどうしても難しいです。Human in the Loopについても、新しく学習したモデルは本当にこれリリースしていいのかを自動でやるのはやっぱり怖いので、事業部側の人に実際に結果を目で見て確かめてもらうケースもありましたね。モデルが出した結果をザーッと見て。
（佐藤）例えばGoogleがやってるようなガチなフェアネスの評価はすごく大変じゃないですか。全ての性別、国、人種、地域で全部精度チェックしてとか、そこまで必要なのかどうかとか。
（藤原）ROCのグラフを出して面積を見るとか、そういう見方もありますが、結局そういう数値化できるものと、人間が見たときに本当に違和感がないかどうかって、完全には一致しないという難しさがあって。なので、やっぱり最後はどうしても人間が結果をチラッとは見ないと怖いみたいな気持ちがあり、そういうステップを挟んでることもありました。
（佐藤）リコメンデーションだったらリコメンデーションのサービスをチクチク触ってみて？
（藤原）触らなくても、リコメンデーションで並ぶリストをザーッと見て、まあまあこうなるよね、みたいな。ある程度分かってる人が見ると違和感ないよねってのがパッと分かるんだけれども、それを機械というか自動で数値化できるかって言われると、割と難しい。
（佐藤）でもDeNAさんレベルでもそういう現状なので、なかなかそこを定量的に評価して再学習を判断します、みたいなところはこれからですかね。
（藤原）なんとかなりませんかね。気にせず勇気を持って全部デプロイすればいいんですかね（笑）。
（佐藤）Vertex AIでは、そうしたニーズにできるだけアプローチするためのツールとして、例えばModel Monitoringというデータの分布をリアルタイムにチェックする機能であるとか、最近出たModel Registryにモデルをアップロードするとそのモデルの精度を自動的にチェックするくらいはカバーできます。ただ、その先のUXまで行くと、UXの定量評価ってなかなか難しい。これからの課題ですね。
ありがとうございました。では最後のお題に行きますね。各社まだ手探り状態で始めているMLOps、自分の会社でどうやって始めるのかを議論していきたいと思います。
私が見たお客様事例ですと、例えばPLAID様はすでにいくつかのセッションで登壇いただいていて、Light MLOpsというプラクティスを提唱されています。例えばVertex AIのドキュメントに、MLOpsの最初から最後までのフル構成の図が出てきますけども、あれを最初からそのままドーンと導入する必要はないんですよ、と。
例えばデータサイエンティストがこれまでJupyter Notebookを手作業で動かしていたものを、サーバーレスのPipelinesで手軽に自動化するところから始めてみる。そうしたデータサイエンティストの方の手軽なツールとして位置づかないままMLOpsやりましょうと一気に自動化したら、現場からのプッシュバックが来るでしょう。イテレーションを小さく回しながら、MLOpsを徐々に導入していく考え方ですね。
皆さんにもご意見を伺いたいのですが、Vertex AIが手軽に使えることで良かった点は他にもありますか？
（河合）私たちはPipelinesの他にPredictionをよく使っています。Predictionは何かというと、ディープランニングのモデルをModel Registryにアップロードしておくと、その（推論サービスの）APIを運用してくれるサービスです。GPUが使えて、しかもオートスケールしてくれるフルマネージドなので、我々が何も考えなくてもかなりの量のリクエストを勝手にさばいてくれる。今ではMLエンジニアがやることは、そのモデルをアップロードするだけみたいな状態です。これは一番最初の（MLOpsの）導入として簡単に使える事例じゃないかなと思ってます。
（佐藤）やっぱり推論の実運用環境を立てるっていうのは結構な大仕事でしたからね。
（河合）そうですね、基盤を立てるのが一番大変だったところなので。先ほどもMLOpsは「MLとかAIを育てる」という話がありましたが、最初の推論ができると、そこからじゃあちょっと育てようか、そのファーストステップがすごく速くできる点が良いなと思ってます。
（中略）
（佐藤）では次のお題です。「私はこうしてMLOpsエンジニアになった。」このお題は田中さんからいただいたと思いますので、では田中さんこのお話を。
（田中）はい、私はMLOpsコミュニティの運営メンバーなのですけが、毎月MLOpsの事例を紹介した際にアンケートを取らせていただくと、やっぱり「MLOpsエンジニアにどういう風になったらいいか」、もしくは「どういうキャリアパスがあるのか」という質問を結構多くいただきます。これに対して初級者向けのセッションを今後用意したりとか考えています。
半年前ぐらいに藤原さんにも「私はこうしてMLOpsエンジニアになった」というタイトルで話していただきました。データサイエンティストからの移行であったり、SWE（ソフトウェアエンジニア）やDevOps SREからの移行であったり、プロジェクトマネージャとしてデータサイエンスのプロジェクト担当し、そこからさらに興味を持たれて学んでMLOpsエンジニアになった方も。現職の途中から徐々に染み出し染み出ししてMLOpsエンジニアになっていった、というケースもありました。
昨日この話を登壇者の人とも話をした時に出てきたのが、新卒でMLOpsエンジニアのロールがあったら（スキル要件の）難しいところはどうするんだろうね、っていうのは話していました。今まさにMLOpsエンジニアに求められるスキルセットであったり技術要件をどの会社様も作っている状況なのかなと思っています。
私個人としては2016年ぐらいから機械学習のデータサイエンティスト10人規模のチームにいまして、データサイエンティストとSREと開発というチーム一丸になって、障害が起きたらデータサイエンティストも駆けつけて何が起きた？ みたいな感じで対処していました。実際に手を動かすのは開発者ですが。でもチームで機械学習モデルを育てていく文化があって、そうなると僕も複数のロールをやることでMLOpsに興味を持ちました。まさしく杉山さんが先ほどおっしゃった「AIを育てるカルチャー」がMLOpsエンジニアに必要不可欠だし、必要な技術要件につながっていくと私は思っています。
（佐藤）田中さんが前にいらっしゃった現場はかなり先進的だと言えますよね。データサイエンティストとDevOpsが別れていて、Notebook渡すからあとはよろしく、みたいなケースもありますが、全然違ってたと。
（田中）そうですね。僕のお師匠さん（の影響）だと思いますが、本当にどちらにも入ってくるし、開発の人もじゃあこれどういう要件なんですか？ とか、こうした方がいいんじゃないですか？ って提案もしてくれた。そういうチームビルディングが必要不可欠だったなと思ってます。
（佐藤）なるほど。では、どうやってMLOpsエンジニアを育てるかという話、どうですかね。
（藤原）僕はもともとアルゴリズム屋さんだったのですが、アルゴリズム屋さんがアルゴリズム書いたり機械学習やったりしても、結局それを事業貢献に結びつけて、ちゃんと経営層に「良いことしたね」って評価してもらうためには、やっぱりちゃんとシステムとして作れないといけない。
アルゴリズム屋さんだけだとどうしてもそこができないから、じゃあどうするか？ って言われたときに、ある程度自分で頑張って学ばざるを得ない。というのが、みんな多分経験してきたんじゃないかなと思ってます。なのでデータサイエンスからMLOpsに来た人って、狙ってきたというよりは、やらなければいけないことをやった結果流れついたみたいな人が多いのかなと思っていて、少なくとも僕はそうなんです。逆に、最初からMLOpsをやりたくて来る人が現れ始めた今の世代に対してどう教育すればいいかというのは、正直まだ自分の中で定まってないですね。
（佐藤）ありがとうございます。
CADDi 河合さんには、SpotlightセッションでもMLOpsについて語っていただいたので、その内容も以下に抜粋します。
AI ネイティブ世代」の 3 人に訊く、AI / ML で仕事と人生を変える方法（河合さんパート）
（Google 佐藤）続いてはCADDiの機械学習エンジニアの河合俊典さんをお迎えしたいと思います。河合さんは2021年からCADDi AI Labのテックリードを担当されています。CADDiは製造業のDXによるものづくりのポテンシャルの開放を目指して、2018年に創業したITベンチャー企業です。
河合さんはもともとTwitter上では「ばんくし」というアカウント名で、2万7000人のフォロワーに向けて日々機械学習に関する情報発信されたり、イベント登壇されたりですとか、ブログ書かれたりしますけれども、今回CADDiに入られたきっかけも実はTwitter上でのオファーがあったというお話ですよね。
（CADDi 河合）はい。CADDiの社員とCTOの方から熱いDMをいただいて、CADDiのミッションだとか、その実現したい世界、あとは環境の方を聞いて、非常にいい会社だなと思って入社することになりました。
（佐藤）ちょうどCADDiが創業から4年経ったというところで、データが集まってきたとかそういったことですかね。
（河合）そうですね。ちょうど4年目ということで、データもそうですし、業界のノウハウですとか知見もたまってきたところで、そろそろ機械学習だとか、あとはAIといった文脈で技術が応用できるんじゃないかという形ができてきたというお話をいただいていて、ちょうど私が入社するタイミングでAIラボというものを立ち上げるということで、これは私にとってもいいタイミングだということで、入社の一つのポイントになったなとは思っています。
（佐藤）Twitter上のCADDiのCTOさんからの熱いオファーを受けた理由は何でしょうか。
（河合）2つポイントがあったなと思っています。1つはMLOpsだとかRustといったキーワードをCTOからいただいたことです。機械学習ってなかなかサービスに導入するまでの時間がかかるものであるというのが結構広く知られていることだと思うんですけれども、そういった基盤を作る、それをゼロから作り始めるというところが私にとって魅力的でした。
（佐藤）では、そういった機械学習の基盤構築であるMLOps、そしてプログラミング言語のRust、この2つを武器に機械学習エンジニアがよりビジネスに深く関われるという観点で判断されたというのですか。
（河合）特に機械学習というものはビジネスのコアになるプロダクトマネジメントとしての判断というのは難しい技術の1つだなと思っています。例えば非常に機械学習のモデルとしては精度の良いものができたとしても、ビジネスだとかプロダクトのコアになり得なかったことで導入がなされなかったモデルだとか、あとはコアになっていないという同じキーワードなんですけど、コアになっていなかったことによって一度出したものを改善する機会を事業判断で与えられないまま続くということがよくあるものだなと思っています。
そういった中で2つポイントがあると思っていて、1つはやっぱりプロダクトマネジメントの機械学習をどうやって回していくかということだと思うんですけど、エンジニアリングの観点ではもう1つ、MLOps だとか、それを技術的負債を作らずにPDCA を高速に回していくというところがポイントになるなと思っています。
（佐藤）そういった課題があるところで、具体的に機械学習をどう使って製造業のDXを実現しようとされているのでしょうか。
（河合）CADDiはCADDi DRAWERというSaaSを提供しています。CADDi DRAWERは図面を管理して活用するためのサービスになっています。類似の図面を検索するエンジンを搭載していたり、図面に書かれているいくつかの材質や加工の情報という形で検索できる。またそれに紐づいた図面をベースにした発注の情報も検索の対象に入っていて、過去、ものづくり業界でたまってきた図面を活用できるようなSaaSを今作っています。
その中で、我々機械学習のエンジニアが何をやっているかというと、情報抽出だとか、あとは検索エンジニアリングの部分を担当しています。特に特徴的な部分で言いますと、ディープラーニングを使った類似の画像検索ですとか、そのディープラーニングだけでなくて、アルゴリズムベースでの特徴量抽出も行っていて、それらを複合的に扱うようなシステム構築というものを行っています。
（佐藤）機械学習のアルゴリズムですとかモデル、これを学習によって作っても、そこから実際にお客様へのサービスとして役に立つ、価値を提供するサービス、ここに持ってくるまでに必要な機械学習の基盤の構築ですとか、このあたりが今、MLOpsというキーワードで注目を集めています。そこで機械学習をビジネスを支えるコアのエンジンとして位置づけるためのMLOps基盤をCADDiに導入される上で、河合さんはスケーラブルなMLOps基盤の構築に取り組まれていると。
（河合）はい、スケーラブルというのはいろいろな捉え方があるかなと思いますが、一つはビジネスが急拡大したときに大きくスケールすることができる、もう一つがビジネスの方向性が変わったときに、そこの横に対してもスケールすることができるという二つの側面があるなと思っていて、そういったMLOpsを実現したいと思っています。
MLOps自体は結構難しいと言いますか、新しくここ数年で出てきた概念というところもあると思いますけれども、いわゆるDevOpsだとかSREといったチームとはまた一つ違った難しさがあるなと思っています。
まず機械学習におけるMLOpsの難しさにおいて二つポイントがあると思っていて、一つが学習と推論をそれぞれ別の形で用意しないといけない。よくライフタイムの違いって言っているんですけど、学習は時間がかかったりとか、デイリー、マンスリーだったりするのに対して、推論というのはすごく短いスパンで実行しないといけない。
あとはKubernetesがよくMLOpsでは使われますけれども、KubernetesをGPU向けにチューニングするって結構大変なんですよね。機械学習のあるプロジェクトで突然メモリが大量に使われるですとか、そういったところに対するチューニングがKubernetesの知識も必要だし、機械学習の特性みたいな部分の知識も必要で、いわゆるDevOpsだとかSREだとか、そういった他のチームと協業すること自体で今まで解決してきました。でも、それって人同士でやり取りする部分のコストがかかります。
近年ではMLOpsエンジニアを採用しようという体制も多くの会社で取られていると思うんですけれども、先ほど言ってたインフラ、例えばKubernetesですとか、あと機械学習ですとか、その2つの知識を持ち合わせるエンジニアってなかなか存在しないんですよね。MLOpsエンジニアの採用も難しいという中で、そこをどうやって進めていくかという意味でもスケーラブルであることが必要です。少ないMLOpsのエンジニアの中でどうやってそのシステムをスケールしていくかみたいなところも私はポイントだなと思っています。
（佐藤）そうしたスケーラブルなMLOps環境を構築するという課題をクリアすべく、CADDiではGoogle Cloudの機械学習プラットフォームであるVertex AIを導入しました。具体的にはどういった扱われ方をされているんでしょうか。
（河合）大きく2つ使っているサービスがありまして、Vertex PipelinesとPredictionを使わせていただいています。特に一番使っているのはPredictionなんですけれども、ある機械学習のモデルをコンテナベースでデプロイすることでWeb APIにできる機能になっています。特にディープラーニングのモデルとして私たちはTorchServeを使っており、TorchServeをPredictionにデプロイする形をとっています。
これのメリットは、MLOpsの文脈ではほとんど私たちが考えることがなくなっていることです。あとはPipelinesですね。Pipelinesもヘビーに使わせていただいていまして、特に先ほどのMLOpsにおける課題である学習と推論、それぞれ必要だよねというところで、学習の部分をPipelinesで組んで、先ほど出てきたPredictionですとかモデル、あとはPipelinesでの推論みたいなところにつなげています。
（佐藤）なるほど。ではVertex AIのPredictionとVertex AIのPipelines、この2つのサーバレスでかつスケーラブルなMLOps環境、これを構築されたということによって、河合さんご自身のエンジニアとしての立場だとか、あと働き方はどう変わりました?
（河合）実はこれは非常に大きく変わっていまして、今までってやはりMLエンジニアがインフラ、いわゆるプラットフォームな部分に触れなかったことによって、モデルは作るんだけれども、そこから先インフラがあって、さらにその先サービスがあってという形でいろんなサービスが提供されていると思うんですけれども、その先に一歩も進めなかったという状況が長く続いていたなと思っています。
Vertex AIはある意味MLエンジニアでもそういったところに触っていけるようになる1つのきっかけになったなと思っていて、私はVertex AIにすべてをお任せして、その仕組みをどうやってつなげるか、いわゆるインフラアーキテクチャの文脈だと思うんですけれども、どうやってつなげてサービスに価値を提供するかというところをより深く考えられるようにやったというのが、1つ大きな変わったポイントだなと思っています。
私はそういったものをやってみた中で、結局やっぱり機械学習がコアになる、ビジネスのコアになるところを考えるのって楽しいと思えたというのも大きかったなと思います。そこにたどり着くには、やっぱりひとつ間に挟まっていたプラットフォームだとか、アプリケーションだとかという部分を取り除くことが必要だったなと思っていて、そこに一歩大きく近づいたのはVertex AIのおかげだなと思っています。
（佐藤）私もずっとVertex AIを紹介する立場から話を聞いていますと、技術的にいいところというのは説明できるんですけれども、やっぱり河合さんのように、自分の働く楽しさにMLOpsですとか、スケーラブルであること、またはサーバレスというキーワードがダイレクトにつながってくるというのは新しい発見だなと思いました。
（河合）CADDiのMLエンジニアの働き方も随分変わってきているなと思っています。プロダクトだとか、使われ方が本当にこれっていい使われ方なんだっけだとか、これはあくまでPDCAの一環だよねとか、使われ方とか活用のされ方みたいなところを非常に強く考えるメンバーが増えてきているなと思っていて。それはもうインフラだとか、それをどうやってデプロイするかみたいなところのある意味障壁になっていた部分が除かれたというのが大きいなと思っています。
（佐藤）なるほど。ここではCADDiの河合さんに貴重なお話をお伺いしました。どうもありがとうございました。
Disclaimer この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり､私の雇用者には関係はありません｡
Discussion