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

see also: https://mazgi.github.io/posts/2019.12/went-to-gcpug-tokyo-dec-2019/

- p.5
- https://de20.dena.com/present
- p.20
- https://cloud.google.com/compute/docs/gpus/#introduction
- https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-eks-adds-support-for-provisioning-and-managing-kubernetes-worker-nodes/
- https://cloud.google.com/security/encryption-at-rest/
- p.21
- https://code.visualstudio.com/docs/remote/containers
- p.25
- https://developer.github.com/v4/guides/using-the-explorer/

Transcript

1. MLアプリケーション短期開発 on GKE & GCP @mazgi / GCPUG Tokyo December 2019
2. Agenda • ⾃自⼰己紹介 • プロジェクト概要 • システム構成 • プロジェクトの課題と解決 • まとめ 1 min 1 min 6 min 6 min 6 min 2
3. ⾃自⼰己紹介 • Hidenori MATSUKI • DeNA AI System Dept. • ML Ops / DevOps • ここに何書けばいいかわからない程度にはコミュ障 1 min 3
4. プロジェクト概要 • 概要と要件 • スケジュール • チーム構成 • マイゴール 2 min 1 min 1 min 2 min 6 min 4
5. プロジェクト概要 - 概要と要件 https://de20.dena.com/present 5 「未来のエンジニアに必要なスキルを1⽇日で学ぶ」をテーマに、将来エンジニア を⽬目指す⼩小学⽣生対象に「1⽇日DeNA学校」を2019年年12⽉月15⽇日(⽇日)に開催、 より多くの⼦子どもたちがAIやインターネットを活⽤用したモノづくりの楽しみに触れ、 もっと新しいものを創りたいと思う未来を実現する
6. プロジェクト概要 - 概要と要件 6 応募してくださった⼩小学校4年年⽣生〜6年年⽣生 に、⽂文字通り1⽇日かけて3つの”授業”を提供。 最初の授業は「AI⼊入⾨門」。 座学で「AIとは？」を解説した後、実際 に”AI”に写真を学習させ「この写真は何か」 推論する精度をグループ同⼠士で競う体験講座 を⾏行行った。 本プロジェクトでは、この体験講座のために 機械学習をWebアプリケーションとして開 発した。 I’m here. 概要
7. プロジェクト概要 - 概要と要件 要件 iPadで体験できる Web or ネイティブ 写真アップロード必須 ⼩小学⽣生が操作できるUI/UX ⽂文字⼊入⼒力力不不要にしたい しかしログイン相当機能は必要 （⼈人ではなくグループの区別） 個⼈人情報保護 ⾊色々な写真がアップロードされる （写真撮影の許諾はアリ） 会場外からのアクセスを拒否 7
8. プロジェクト概要 - スケジュール • 2019.10半ばくらいにスタート • 私の知ってる初回MTGが10/15 • リポジトリできたのもその頃 • 本番当⽇日が2019/12/15 • ぴったり2ヶ⽉月！ 8
9. プロジェクト概要 - スケジュール 本番は12/15 9
10. プロジェクト概要 - チーム構成 • A - データサイエンティスト, プロジェクトリーダー • B - AI研究開発エンジニア • C - AI研究開発エンジニア, ML Web API開発担当 • D - AI研究開発エンジニア, 資料料作成と講義担当 • 私 - DevOps, とりあえず浮いてるところ全部担当するつもり 兼務 兼務 兼務 兼務 兼務 2019 新卒⼊入社 2019 新卒⼊入社 2019 新卒⼊入社 2019 新卒⼊入社 10
11. プロジェクト概要 - チーム構成 • チームの共通⾔言語 • Python • ⽇日本語 • 圧倒的なローカル開発経験 • 本業はWebサービス開発ではない • Webサービス開発とDeployの意識合わせからスタート 11
12. プロジェクト概要 - マイゴール • ⾮非同期開発（⼈人間的な意味で） • 全員が兼務 • 途中で出張も予定 • 短期間でそこそこ正しい技術選定 • 試⾏行行錯誤している時間がない • 「これなら出来上がる」確信が必要 • せっかくならチームの実になる技術を導⼊入したい • 今後も深掘りし甲斐がある技術を導⼊入したい • チームとして可視化と表現の術を身に付けたい 12
13. システム構成 • Frontend + Backends For Frontends • Machine Learning Web API • Infrastructure on GCP • 全体構成 6 min 2 min 1 min 1 min 2 min 13
14. システム構成 - Frontend + BFF • Frontend: TypeScript + Next.js + React + GraphQL.js + Material UI • FrontendといいつつSSRまでは⾏行行う • BFF: TypeScript + Express + TypeGraphQL + TypeORM • Web APIのプロトコルはGraphiQLのみ（RESTなし） • ⾮非同期開発（⼈人間的な意味で）必⾄至だったのでサンプル提供 • 形があるものを元に議論した⽅方が理理解しやすいし話が進む • ※選定理理由は数分後 14
15. システム構成 - Machine Learning Web API • Python 3 + Flask + Flask-GraphQL + PyTorch + CUDA 10 • BFFからGraphQL Mutationを受け学習/推論を⾏行行う • 画像はGCS経由でやり取り • GCEインスタンスで実⾏行行 • GPUをAttache: K80 * 8 @台湾 • GKEには載せず（後述） 15
16. システム構成 - Infrastructure on GCP • GKEを中⼼心にGCPのみで構成 • GCPプロジェクトはProduction / Sandboxの2つ • 個⼈人情報（写真）を扱うためGCPプロジェクト⾃自体分離 • 公開イベントだが情報を垂れ流して良いわけではない • Cloud Armorで接続元制限 • ProvisioningはTerraform • Deployはkustomize + kubectl 16
17. GCP GKE システム構成 - 全体構成 17 ML LB LB LB Admin Frontend BFF GCS Cloud SQL SSH Cloud Armor Cloud Armor Cloud Armor
18. プロジェクト進⾏行行 • 本番環境の技術選定 • 開発環境特有の技術選定 • 各レイヤーの技術選定 6 min 2 min 2 min 2 min 18
19. プロジェクト進⾏行行 - 本番環境の技術選定 • なぜKubernetesか？ • インスタンスをProvisioning/管理理したくなかった • チームの経験値はWebアプリケーション開発に寄っていなかった • 仕様もとてもふわふわしていた • GAEや各種Serverlessは途中で知識が⾜足りず詰む確信があった • 「Dockerで動けばDeployできる」安⼼心感を担保したかった • k8sは使うが最⼩小限の基本的な使い⽅方に限定する • k8s触ったことあるのが私1⼈人 • MLワークロード（要GPU）はk8sに載せない 19
20. プロジェクト進⾏行行 - 本番環境の技術選定 • なぜGKEか？ • Kubernetesのノードを管理理したくなかった • 部内的にはIaaSといえばGCP or AWS • ただしGCEのGPUはメンテナンスによるTerminateが不不測 • 今回はイベント当⽇日だけ⽌止まらなければ良いのでGCP使⽤用に踏み切れた • EKSのManaged Nodeも11/18に発表された • Cloud ArmorでIPアドレスベースの接続制御できる • GCPのストレージはデフォルトで暗号化済みという安⼼心感 • 特に今回お⼦子さんが参加される • もし保護者の⽅方が「HDD抜かれたらどうなるの？」と⼼心配になった時に応えられる安⼼心感は⼤大きい 20
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
22. プロジェクト進⾏行行 - 開発環境特有の技術選定 ソリューション Linux開発機導⼊入 即決済、即対応いただき開発環境をLinuxに変更更 マネージャや情シス部⾨門の⽅方に感謝 22
23. プロジェクト進⾏行行 - 各レイヤーの技術選定 • Frontend: TypeScript + Next.js + React + Material UI • テスト削減と安全な開発のためにTypeScript導⼊入 • 書いた瞬間にIDEが叱ってくれるのは安⼼心感ある • Next.js 頼りでwebpackをできるだけ回避 • デザイナーさんがいないプロジェクトなので Material UI 導⼊入 • 慣れるまで都度調べる必要はあるが Component が充実している 23
24. プロジェクト進⾏行行 - 各レイヤーの技術選定 • BFF: TypeScript + Express • 新たに⾔言語を習得する時間はなかった • 選択肢は Python or TypeScript • Backend For Frontend • BFFはFrontendと密に連携する想定がありFrontend側に寄せた • Express + 軽量量ライブラリでシンプルに構成 • Apollo ServerやPrismaのような⼤大型ライブラリの導⼊入は⾒見見送った 24
25. プロジェクト進⾏行行 - 各レイヤーの技術選定 • GraphQL • チームとしてREST Web APIの開発実績少なかった • 命名の枯渇やモデルの変更更が予測された • 私が今回使⽤用する機能の実装イメージを持てていた • GraphQLで最初に躓くのはCookie周りと画像アップロード（だと思う） • メンバーでGitHubのGraphQL API Explorer体験し導⼊入を決めた • Frontendはシンプルに GraphQL.js を導⼊入 • BFFはTypeGraphQLを導⼊入 25
26. プロジェクト進⾏行行 - 各レイヤーの技術選定 • プロジェクト構成は（ほぼ）mono repository • IaCのコードだけは別repositoryに分けた • 明らかに更更新のライフサイクルが違う • IaCの docker-compose.yaml を分けたかった • IaCのコードが開発のみ⾏行行うメンバーにとってノイズ • 今回規模ならソースコードはrepository分ける必要ないと考えた • repository分けるとI/Fの同期取るコストが発⽣生する 26
27. プロジェクト進⾏行行 - 各レイヤーの技術選定 Dockerfiles for Production & Development 本番と開発を同じDockerfileにまとめる ただしmulti stage buildを使⽤用 開発時は docker-compose.yaml で target 指定 27
28. プロジェクト進⾏行行 - 各レイヤーの技術選定 開発／本番を同じstageから派⽣生 1つのDockerfile内に書く ⾒見見通しよくレビューで気付きやすい 差異異を最⼩小限に抑える 例例）本番と開発でbaseイメージ違うとか 例例）本番と開発でライブラリバージョン違うとか 28
29. プロジェクト進⾏行行 - 各レイヤーの技術選定 TypeGraphQL + TypeORM このようにライブラリをimport Entityクラスのフィールドにアノテーション @Field => TypeGraphQLのアノテーション @Column => TypeORMのアノテーション GraphQLでDBレコードを取得できる 29
30. まとめ • ⾮非同期開発（⼈人間的な意味で） • 初期にサンプル提供できたのはとても良かった • Frontend -> BFF -> ML Web APIの接続イメージが共有された • 実装の参考にもなったとのこと • ドキュメンテーション⼤大事 • 時間が限られる中で明⽂文化する⼯工夫が必要 • コミュニケーションは特に問題なし • 元々Slack⽂文化、テキストコミュニケーションスキルが⾼高い • 元々Work From Homeや国内外出張が多く「誰か不不在」が当たり前 1 min 30
31. まとめ • 短期間でそこそこ正しい技術選定 • 特に以下はメンバー満⾜足度⾼高かった • Docker Compose => 「無しでは⽣生きていけない」 • TypeScript => 「最⾼高」「良き」 • GraphQL => 「GraphiQLは便便利利」「素晴らしい」 • Next.js, React, Material UIは正解の1つだったとは思うが導⼊入⽅方法に改善の余地があった • それぞれの分界点が把握しづらく学習コスト⾼高くなってしまった • サンプルあったのでハンズオンできれば学習コスト削減できた • 使⽤用⾔言語を2つに絞り込めたのは⼤大正解 • 今回のスケジュールで「BFFだけ別の⾔言語」などやったら破綻してた 1 min 31
32. まとめ • チームの実になる技術を導⼊入できた • チームとしてWebアプリケーション開発実績と技術スタックができた • 今後のMLを使⽤用したWebアプリケーションでも使えるスキームが構築できた • 以下は追加で必要になる想定 • FrontendへのRedux導⼊入 • BFFあるいはそのバックエンドでのJob管理理 • 2ヶ⽉月でGKE上にML WebアプリケーションをDeployできた • 性能やコスト、運⽤用監視は今後のチャレンジ項⽬目 • AI研究開発エンジニアとML Opsの分担も考慮 • 次回はML部分のコンテナ化⽬目指したい • 少なくともインスタンスのProvisioning／管理理を削減したい 1 min 32