MLアプリケーション短期開発 / Fast development for ML Web Service on GKE & GCP

MLアプリケーション短期開発 / Fast development for ML Web Service on GKE & GCP

553d5f63a9ee17b37369c03437b3aece?s=128

MATSUKI Hidenori

December 18, 2019
Tweet

Transcript

  1. 3.

    ⾃自⼰己紹介 • Hidenori MATSUKI • DeNA AI System Dept. •

    ML Ops / DevOps • ここに何書けばいいかわからない程度にはコミュ障 1 min 3
  2. 7.

    プロジェクト概要 - 概要と要件 要件 iPadで体験できる Web or ネイティブ 写真アップロード必須 ⼩小学⽣生が操作できるUI/UX

    ⽂文字⼊入⼒力力不不要にしたい しかしログイン相当機能は必要 (⼈人ではなくグループの区別) 個⼈人情報保護 ⾊色々な写真がアップロードされる (写真撮影の許諾はアリ) 会場外からのアクセスを拒否 7
  3. 10.

    プロジェクト概要 - チーム構成 • A - データサイエンティスト, プロジェクトリーダー • B

    - AI研究開発エンジニア • C - AI研究開発エンジニア, ML Web API開発担当 • D - AI研究開発エンジニア, 資料料作成と講義担当 • 私 - DevOps, とりあえず浮いてるところ全部担当するつもり 兼務 兼務 兼務 兼務 兼務 2019 新卒⼊入社 2019 新卒⼊入社 2019 新卒⼊入社 2019 新卒⼊入社 10
  4. 11.

    プロジェクト概要 - チーム構成 • チームの共通⾔言語 • Python • ⽇日本語 •

    圧倒的なローカル開発経験 • 本業はWebサービス開発ではない • Webサービス開発とDeployの意識合わせからスタート 11
  5. 12.

    プロジェクト概要 - マイゴール • ⾮非同期開発(⼈人間的な意味で) • 全員が兼務 • 途中で出張も予定 •

    短期間でそこそこ正しい技術選定 • 試⾏行行錯誤している時間がない • 「これなら出来上がる」確信が必要 • せっかくならチームの実になる技術を導⼊入したい • 今後も深掘りし甲斐がある技術を導⼊入したい • チームとして可視化と表現の術を身に付けたい 12
  6. 13.

    システム構成 • Frontend + Backends For Frontends • Machine Learning

    Web API • Infrastructure on GCP • 全体構成 6 min 2 min 1 min 1 min 2 min 13
  7. 14.

    システム構成 - Frontend + BFF • Frontend: TypeScript + Next.js

    + React + GraphQL.js + Material UI • FrontendといいつつSSRまでは⾏行行う • BFF: TypeScript + Express + TypeGraphQL + TypeORM • Web APIのプロトコルはGraphiQLのみ(RESTなし) • ⾮非同期開発(⼈人間的な意味で)必⾄至だったのでサンプル提供 • 形があるものを元に議論した⽅方が理理解しやすいし話が進む • ※選定理理由は数分後 14
  8. 15.

    システム構成 - Machine Learning Web API • Python 3 +

    Flask + Flask-GraphQL + PyTorch + CUDA 10 • BFFからGraphQL Mutationを受け学習/推論を⾏行行う • 画像はGCS経由でやり取り • GCEインスタンスで実⾏行行 • GPUをAttache: K80 * 8 @台湾 • GKEには載せず(後述) 15
  9. 16.

    システム構成 - Infrastructure on GCP • GKEを中⼼心にGCPのみで構成 • GCPプロジェクトはProduction /

    Sandboxの2つ • 個⼈人情報(写真)を扱うためGCPプロジェクト⾃自体分離 • 公開イベントだが情報を垂れ流して良いわけではない • Cloud Armorで接続元制限 • ProvisioningはTerraform • Deployはkustomize + kubectl 16
  10. 17.

    GCP GKE システム構成 - 全体構成 17 ML LB LB LB

    Admin Frontend BFF GCS Cloud SQL SSH Cloud Armor Cloud Armor Cloud Armor
  11. 19.

    プロジェクト進⾏行行 - 本番環境の技術選定 • なぜKubernetesか? • インスタンスをProvisioning/管理理したくなかった • チームの経験値はWebアプリケーション開発に寄っていなかった •

    仕様もとてもふわふわしていた • GAEや各種Serverlessは途中で知識が⾜足りず詰む確信があった • 「Dockerで動けばDeployできる」安⼼心感を担保したかった • k8sは使うが最⼩小限の基本的な使い⽅方に限定する • k8s触ったことあるのが私1⼈人 • MLワークロード(要GPU)はk8sに載せない 19
  12. 20.

    プロジェクト進⾏行行 - 本番環境の技術選定 • なぜGKEか? • Kubernetesのノードを管理理したくなかった • 部内的にはIaaSといえばGCP or

    AWS • ただしGCEのGPUはメンテナンスによるTerminateが不不測 • 今回はイベント当⽇日だけ⽌止まらなければ良いのでGCP使⽤用に踏み切れた • EKSのManaged Nodeも11/18に発表された • Cloud ArmorでIPアドレスベースの接続制御できる • GCPのストレージはデフォルトで暗号化済みという安⼼心感 • 特に今回お⼦子さんが参加される • もし保護者の⽅方が「HDD抜かれたらどうなるの?」と⼼心配になった時に応えられる安⼼心感は⼤大きい 20
  13. 21.

    プロジェクト進⾏行行 - 開発環境特有の技術選定 • 「開発はDocker Composeで完結したい」とコンセンサス取れていた • ローカルPCは全員Mac • しかしDocker

    for Macは遅かった、とてつもなく • package-lock.json の成⻑⾧長とともに開発不不可能な遅さに… • node_modules の扱いに苦慮 • コンテナの外に出すと遅い、コンテナ内に⼊入れるとIDEの補完や警告が効かない • VSCode Remote - Containerのような機能はあるがAttacheできるコンテナは1つだけ • Docker for Mac限定の不不可解な事象も発⽣生し始める • Volumeのmount順が変わる • 明らかに存在するファイルが認識されない 21
  14. 23.

    プロジェクト進⾏行行 - 各レイヤーの技術選定 • Frontend: TypeScript + Next.js + React

    + Material UI • テスト削減と安全な開発のためにTypeScript導⼊入 • 書いた瞬間にIDEが叱ってくれるのは安⼼心感ある • Next.js 頼りでwebpackをできるだけ回避 • デザイナーさんがいないプロジェクトなので Material UI 導⼊入 • 慣れるまで都度調べる必要はあるが Component が充実している 23
  15. 24.

    プロジェクト進⾏行行 - 各レイヤーの技術選定 • BFF: TypeScript + Express • 新たに⾔言語を習得する時間はなかった

    • 選択肢は Python or TypeScript • Backend For Frontend • BFFはFrontendと密に連携する想定がありFrontend側に寄せた • Express + 軽量量ライブラリでシンプルに構成 • Apollo ServerやPrismaのような⼤大型ライブラリの導⼊入は⾒見見送った 24
  16. 25.

    プロジェクト進⾏行行 - 各レイヤーの技術選定 • GraphQL • チームとしてREST Web APIの開発実績少なかった •

    命名の枯渇やモデルの変更更が予測された • 私が今回使⽤用する機能の実装イメージを持てていた • GraphQLで最初に躓くのはCookie周りと画像アップロード(だと思う) • メンバーでGitHubのGraphQL API Explorer体験し導⼊入を決めた • Frontendはシンプルに GraphQL.js を導⼊入 • BFFはTypeGraphQLを導⼊入 25
  17. 26.

    プロジェクト進⾏行行 - 各レイヤーの技術選定 • プロジェクト構成は(ほぼ)mono repository • IaCのコードだけは別repositoryに分けた • 明らかに更更新のライフサイクルが違う

    • IaCの docker-compose.yaml を分けたかった • IaCのコードが開発のみ⾏行行うメンバーにとってノイズ • 今回規模ならソースコードはrepository分ける必要ないと考えた • repository分けるとI/Fの同期取るコストが発⽣生する 26
  18. 29.
  19. 30.

    まとめ • ⾮非同期開発(⼈人間的な意味で) • 初期にサンプル提供できたのはとても良かった • Frontend -> BFF ->

    ML Web APIの接続イメージが共有された • 実装の参考にもなったとのこと • ドキュメンテーション⼤大事 • 時間が限られる中で明⽂文化する⼯工夫が必要 • コミュニケーションは特に問題なし • 元々Slack⽂文化、テキストコミュニケーションスキルが⾼高い • 元々Work From Homeや国内外出張が多く「誰か不不在」が当たり前 1 min 30
  20. 31.

    まとめ • 短期間でそこそこ正しい技術選定 • 特に以下はメンバー満⾜足度⾼高かった • Docker Compose => 「無しでは⽣生きていけない」

    • TypeScript => 「最⾼高」「良き」 • GraphQL => 「GraphiQLは便便利利」「素晴らしい」 • Next.js, React, Material UIは正解の1つだったとは思うが導⼊入⽅方法に改善の余地があった • それぞれの分界点が把握しづらく学習コスト⾼高くなってしまった • サンプルあったのでハンズオンできれば学習コスト削減できた • 使⽤用⾔言語を2つに絞り込めたのは⼤大正解 • 今回のスケジュールで「BFFだけ別の⾔言語」などやったら破綻してた 1 min 31
  21. 32.

    まとめ • チームの実になる技術を導⼊入できた • チームとしてWebアプリケーション開発実績と技術スタックができた • 今後のMLを使⽤用したWebアプリケーションでも使えるスキームが構築できた • 以下は追加で必要になる想定 •

    FrontendへのRedux導⼊入 • BFFあるいはそのバックエンドでのJob管理理 • 2ヶ⽉月でGKE上にML WebアプリケーションをDeployできた • 性能やコスト、運⽤用監視は今後のチャレンジ項⽬目 • AI研究開発エンジニアとML Opsの分担も考慮 • 次回はML部分のコンテナ化⽬目指したい • 少なくともインスタンスのProvisioning/管理理を削減したい 1 min 32