Discovery DataScience Meet up (DsDS) #0に参加しました

「Discovery DataScience Meet up (DsDS) #0」に参加したので(オンライン)、まとめました。
間違っている箇所がある場合、指摘いただけると助かります(専門でない部分も多いため、間違っていたらすみません)

どんなイベント？

Yahooエンジニア, CAエンジニア, DeNAエンジニア, MoTエンジニア合同イベント！ ScrambleTech19が主催している、データサイエンティストが日頃の業務で得た知見や悩みについて情報共有する会です！ 「組織の枠を超えて、支えあえるDSコミュニティを創る」ことを目指しています！

scramble.connpass.com

今回は6名のLTから構成されていました。

LT

広告文自動生成プロダクトでDataflowを導入した話

• Dataflowをコピー生成プロダクトに導入した話
  • 既存の構成:マイクロサービス化したcloud run群で構成
  • 課題点
    • pandas on GCEだとメモリに限界があり、時間がかかる→Dataflow導入へ
  • Dataflowとは？:GCPでApache Beamを動かしてくれるフルマネージドサービス
  • DataflowのTips
    • デバッグしづらい:ログが分かりづらい
    • 実行環境:Makefileでdev/stg/prdで環境を分離
    • APIでロジックを流用(今回悩んだ所とのこと)
      • 形態素解析器のインストールが必要、Dataflowでは非PyPIパッケージのインストールが面倒
      • 運用で使用しているマイクロサービスを使用
      • メリット:コスト削減
      • デメリット:API側に負荷が強いられる、レスポンスの待ちが長いと割高になる(これは結構問題になる)→バッチで投げると良い

TensorflowのモデルをGCPでサービングしてきた話

• APIで予測結果をフロントに提供する必要がある→どのようにしてきたか？
  • サービス(極みAI):AIで広告の良さをスコア化
  • なぜGCP使っているか？→BigQuery最強
  • 最初:Saved Model Predictionを利用
    • メリット
      • モデルを自動で読み込んでAPIを提供してくれる
      • アプリケーションなしで予測を返してくれる
  • 次にCustom Prediction Routineを利用
    • from_path()でモデルを読み込んで、predict()で返すだけ
    • デメリット
      • モデルの容量に制限がある(500MB以上無理)
      • 将来的に廃止される
  • 最後に:GKEを利用
    • マシンタイプの選択が自由かつ楽
    • モデルの容量制限なし
    • デメリット
      • 自前の実装は相当コストがかかる

SageMakerで試行錯誤する推論パイプライン

speakerdeck.com

• 動画を入力とする推論パイプラインをSageMakerで作った話
  • 当初のつらみ
    • PoC段階でずっと生EC上でモデル実装、検証していた
    • 近づく限界
      • パイプラインの全ステップが密結合→バージョン管理困難
      • 一番リソースを食うステップに合わせてインスタンス選択→リソースの無駄(GPU使っているけど、常に使うわけではなし)
      • 依存関係が分離できてない→ライブラリバージョンが固定しづらい
  • SageMaker導入
    • 最初SageMaker Batch Transformで推論
      • 感想
        • Airflowの管理が面倒くさい
        • 書き出し先のpathが分散しててイケてなかった
        • Batch Transformへの書き換えが辛い(これが一番大きかったとのこと)
        • Batch Transformのイケてない所があった
    • 修正事項
      • 次にBatch Transformの代わりにProcessingを使う
        • コードの修正は最小限になった
        • スポットインスタンス未対応でコストがかかる
      • 書き出し先pathをdag_idでまとめた
    • 最終構成
      • Training jobで推論
        • スポットインスタンス使える
      • 未だ残るつらさ
        • manifest fileがローカルモードに対応してない

Cloud Composerで組む機械学習パイプライン

speakerdeck.com

• お客様探索ナビの機械学習パイプラインについて
  • Cloud Composer
    • ワークフローエンジン
    • Airflowを採用
    • タスクへの情報の渡し方
      • Variable:Composer環境全体で共有される環境変数のようなもの
      • XCom:動的な値を渡す(複数のdagでは参照できない)
  • パイプラインを作っていく際
    • GKEPodOperatorで全部やる
      • PythonOperatorの制約等、Composer環境は複雑な処理に不向き
        • 外部パッケージを良く使うような扱いでは、環境汚染が起きやすいPythonOperatorは向いてない
  • まとめ
    • Cloud Composerは構築・運用・実装がお手軽なワークフローエンジン
    • 目標:MLリポジトリに変更があっても、パイプライン側は修正不要な状態が理想
    • パイプラインはあくまでがわなので、実際の処理はGKEやAI Platformに全て任せる
    • Composerの有効活用により、前処理からモデルの本番デプロイまで自動化と安定運用を実現できる

検索システムのMLRモデル更新の自動化

• Solrのリランクプラグイン
  • リッチなラインキングを提供するためのプラットフォーム
    • 多段フェーズランキングによる絞り込み
    • 高速な処理系の実装
    • 柔軟なモデル記述をサポートしたDSL
  • 運用上での課題
    • オペレーションコストを減らしたい
      • モデルが古くなると定期的に再学習する必要がある
      • デプロイする時にSolrクラスタのサービスアウトの必要→リクエストを受けながら更新したい
      • モデルサイズが大きくてGitのリモートリポジトリに保存できない→GitLFSが導入され解決
• まとめ
  • チーム内での検証が終わった段階でサービス導入はこれから
  • A/Bテストやモデル選択も自動化したい
  • モデル開発等にリソースを割くためにオペレーションコストを減らすのは大事

全社共通レコメンドプラットフォームへのKubernetes/Airflow導入

• 共通レコメンドプラットフォームを社内のKubernetes基板に移管
  • プラットフォーム
    • 専属のレコメンドチームを持たないサービス向けで様々なサービスが導入されている
  • システム構成
    • ETL・集計・学習を集約
  • なぜAirflow？
    • GUIで実行進捗管理出来る
    • Kubernetesとの相性が良い→Kubernetes上で動的に学習リソース管理をしたい用途にマッチ
    • Pipeline as Code
    • Slack通知機能
  • 効果
    • DNN学習の運用改善
    • DNNハイパラチューニングの定常稼働
    • Airflowにおるworkflow管理の一元化・状況の可視化
  • 現状の課題
    • 特徴量管理
      • サービス内の一部のログしか使えてない
    • 実験管理
      • kedro + MLFlow trackingに着目
    • 監視
      • オンライン性能の継続監視はまだ