第4回 SHIBUYA SYNAPSE

多角型事業と集約型事業、
それぞれのMLOps / AI基盤

イベント開催 Report04

去る 2018年12月11日(火)、DeNA本社Sakura Cafeにて、「先端AI技術を活用した新たな価値あるサービスの共創」をテーマに「SHIBUYA SYNAPSE」を開催。
AI技術活用に携わるエンジニアやビジネス&サービスの企画担当者など、総勢70名の方が参加しました。

第4回となる今回は、「多角型事業と集約型事業、それぞれのMLOps / AI基盤」をテーマに、機械学習を活用した実サービス開発や運用におけるE2Eでのセキュアなデータフローから、モデルの自動学習やデプロイメントなどのエコシステムをカバーするMLOpsを主軸に据え、事業規模やフェーズなどによって異なるケーススタディを株式会社ディー・エヌ・エーとクックパッド株式会社の両社の事例で紹介しました。

セッション1
マイクロチームでの機械学習PoC

SPEAKER

加茂雄亮

株式会社ディー・エヌ・エー AIシステム部 MLエンジニアリンググループ

2013年4月に中途入社。前職では大手自動車部品サプライヤーや大手教育系出版社と先進技術を活用した研究開発業務に従事。DeNAではMobageプラットフォームの開発運用、大規模チャットサービスの開発運用、デザイン/エンジニアリングマネージャを経て、Mobageサービス上での対話ボット導入を企画立案。PFDeNA立ち上げに携わる。現在はMLOpsにおけるシステムアーキテクチャからインフラ,バックエンド,フロントエンドまで一貫した開発担当として従事。

まずはDeNA システム本部AIシステム部 加茂雄亮 より、マイクロチームにおける、研究要素の強い機械学習案件でのPoC (Proof of Concept) について、少人数のメンバーで成果を最大化するためのMLOpsを事例ベースで紹介しました。

PoCにおけるユーザー体験

研究要素の強い小規模の機械学習案件では、スモールスタートでありながら高い成果が求められます。そこでまず成果物として提案されるのが、レポートレベルでのPoCです。研究成果をレポートとしてまとめることは最初からシステム化をした場合に比べエンジニアリングコストが低く抑えられるため、通常第一の選択肢にあがりやすいと考えています。
しかしながら、一方でレポートレベルでは見る側のハードルが高く、実際の価値提供としてのサービス適用イメージが湧きにくい欠点があると指摘しました。当初からシステム化を想定して計画することで、「うごくもの」としてサービスレベルで達成することで、本質的な価値提供が行えます。
これによって、研究要素と事業要素を両輪により本格的なステップに進むことができます。

機械学習サービスを短期間でリリースするコツ

次に、実際にリサーチャー2名とエンジニア1名でスタートから2ヶ月でサービス化した事例を紹介しました。そこで実際の立ち上げのコツとして下記のポイントをシステムアーキテクチャとともに解説しました。
・クラウドインフラやセキュリティなどの足回りを基盤化
・最低限の基盤にコンテナ技術を透過的に適用する
・案件規模やトラフィックに応じた柔軟な技術選択
・データパイプラインではクラウドオーケストレーションに最大限乗っかる
高トラフィックなWebサービスでは足回りやコンテナーマネジメントにおいて、より綿密な設計が求められますが、トラフィックやスケーリングがある程度想定しやすい機械学習案件の場合、より小回りの効く最小限の技術選択をすることで、スピードと成果を最大化させること可能になるという事例紹介でした。

セッション2
オートモーティブ事業におけるMLOps

SPEAKER

鈴木翔太

株式会社ディー・エヌ・エー AIシステム部 MLエンジニアリンググループ

2018年3月にDeNAに入社。前職では分析基盤の新規構築、ユーザ行動の可視化ツール開発、機械学習システムの開発、運用に従事。現在はオートモーティブ事業におけるAIシステムの構築を行なっている。

続いて、DeNA システム本部AIシステム部鈴木翔太によるオートモーティブ事業におけるMLOpsの発表がありました。
DeNAでは交通事故の削減という社会的課題解決の実現に向けて、車載カメラから得られる映像や各種センサ情報を使い、脇見、車間距離不足、急ブレーキなどの危険運転行動検出技術を研究開発しています。実際のプロジェクトを例に、MLシステムをサービスへ組み込む時の工夫、苦労した点、またリサーチャ、データサイエンティストといった他職種との役割分担や仕事の進め方についてエンジニア側の視点から紹介しました。

大規模チームでのAIプロジェクトの進め方

本プロジェクトはコンピュータビジョンエンジニア、データサイエンティストといったいわゆるAIの専門家だけではなくデータエンジニア、サーバサイドエンジニア、車載器開発エンジニアなど多様なスキルを持った人が協力して進めています。各自の専門性に応じてタスクを分担して進める事により得意領域に集中して取り組むことができる一方、チームをまたぐところでのミスが度々発生するなどの苦労もありました。

MLOpsで取り組んでいること

機械学習システムの流れを3つのフェーズ(データの準備、モデルの学習、モデルのデプロイ)にわけそれぞれでの工夫を紹介しました。まずデータ準備では収集したセンサーデータと画像データに対する前処理を行っています。チームの作業環境としてSageMakerを使いセキュアにデータにアクセスできる環境を構築しており、モデルの学習ではGPUのスポットインスタンスを積極的に使っています。実験の管理はConfigファイルにハイパーパラメータや使用モデル、データを記載して行っています。実験結果はスプレッドシートで管理していますがここはより良い方法を探っています。次にデプロイですが、本番へのデプロイを行う前には過去のデータを別環境で処理し大きな問題がないことを確認してからデプロイを行うようにしています。デプロイ後はBIツールで新しいモデルの精度をモニタリングしています。

セッション3
にんげんがさき、基盤があと

SPEAKER

染谷悠一郎

クックパッド株式会社

東京工業大学大学院 計算工学専攻修士。クックパッド株式会社2016年新卒入社。AWSを中心とした機械学習基盤の整備に従事する傍ら、レシピの画像/テキストデータを利用した機械学習系の研究開発に取り組む。JSAI 2017、AWS Summit Tokyo 2017、AWS re:Invent 2017などに登壇。

次にクックパッド株式会社 染谷悠一郎氏から、組織にとって『最適な機械学習基盤』は、その組織のサイズ、メンバースキルセット、事業内容に至るまで様々な要因により変化するなかで、2016年7月の発足から今まで、複数のプロジェクトをこなしながらチーム規模を拡大してきたクックパッド研究開発部を題材とし、組織にとって最適な機械学習基盤を求めるためのケーススタディの紹介です。

チーム発足から、「料理きろく」のリリース。最小限の基盤。

研究開発部発足当時からチームに在籍していた染谷氏は、機械学習のための基盤が存在しなかった発足当時からの背景を振り返ります。手探の中で、まずは「zooey」というSlack経由で起動停止ができる学習用GPU環境を構築。これによって、必ずしもクラウド環境に習熟していないメンバーでも、インフラエンジニアなしで手軽にGPU環境の立ち上げができるようになりました。
そこから段々とチームが大きくなっていきます。GPU環境の可用性だけでなく、クックパッドという大規模サービスから効率的に複数のデータソースからデータを読み出すことのできる akagi (https://github.com/ayemos/akagi)を開発しました。
そんななかリリースされたサービス、「料理きろく」では染谷氏がサービス開発チームに入ります。「サービスを作る上では優先されるべきはサービスのユーザー体験。それを実現させるために機械学習があるべき」とする染谷氏は、基盤担当メンバーとしての氏がサービスチームに入り込むことが素早く密接な連携を取り、本質的な価値提供には良かったとし、 「基盤と言えるものがなかった中で、少なくとも5人までは余計な物を導入せずに、最低限のコストでサービスチームが満足できるものが提供できた」と語りました。

組織のスケールと機械学習基盤

「料理きろく」のリリース後も、研究開発部は組織として海外拠点で積極的な採用を行うなどスケール。人員も5人から15人と増え始めます。「この頃になって、プロダクション環境へのデプロイがボトルネックになってきた」としながらも、まだ「基盤は様子見」という染谷氏。「現状のフェーズとしてはしばらくは眼の前の課題を解決しながら、ベストプラクティスを探り、その集約として基盤を作っていきたい」と抱負を述べました。

セッション4
パネルディスカッション

プログラムの締めくくりに、お酒を呑みながらカジュアルな雰囲気でのパネルディスカッションが行われました。パネルでは事前に共有されたTwitterハッシュタグから質問を選り抜き、登壇者の3人がそれに応じました。その中の一つをご紹介します。

「機械学習案件にアサインされてまず考えることは?」

翔太「今関わってる案件では開発の途中からのアサインだったので、まず環境や案件のキャッチアップからはじめました。学習に扱うデータにも高いセキュリティが求められるので、セキュリティ専門の部門と安全性を地道に詰めて行きました」
染谷「個人的には、まずはサービスニーズからアーキテクチャとスケーラビリティの検討に入ります。また、機械学習案件では特に推論が必要となるタイミングが重要で、非同期的か同期的かで最終的な難易度を左右すると思っています」
加茂「そうですね、リクエスト時推論は、現状ではユーザーへのレスポンスタイムを考えた場合、ユーザー体験的には厳しくなりがち。案件にもよりますが、非同期的に推論できるものは事前推論をさせておき、キャッシュをレスポンスするなどの工夫が必要だと思います。」

イベント情報はこちらから