Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
•
3 j'aime•1,610 vues
2020年7月29日-30日開催のCloud Operator Days Tokyo 2020の講演資料です。 PFNの太田と佐藤が、Kubernetesによるインフラ構築やCI/CDについて説明します。
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Similaire à Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用 (20)
Plus de Preferred Networks
Plus de Preferred Networks (20)
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
- 1. Cloud Operator Days Tokyo 2020 Preferred Networks 少人数チームでの 機械学習製品の効率的な開 発と運用
- 2. アジェンダ • 自己紹介 • Preferred Networks(以下、PFN)の紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 3. アジェンダ • 自己紹介 • PFNの紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 4. 自己紹介: 太田 佳敬 - 職歴 - 2013-2016 - ドリコム: ゲームのクライアントエンジニア - 2016-2019 - FiNC Technologies: Ruby on Rails等のサーバサイド側 - 2019-現在 - PFN: インフラ・サーバサイドエンジニア - 技術領域
- 5. 自己紹介: 佐藤 拓弥 - 職歴 - 2014-2018 - DeNA: ゲームのサーバ/クライアントサイドエンジニア - 2018-現在 - PFN: ロボット、サーバ/クライアントサイドエンジニア - 技術領域 C#
- 6. アジェンダ • 自己紹介 • PFNの紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 9. アジェンダ • 自己紹介 • PFNの紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 11. - 2500を超えるGPU - 自社製プロセッサ (MN-Core)を搭載 したクラスタも - Kubernetesで制御 - 多くの研究者が 利用 大規模な計算クラスタ
- 13. 製品開発の必要性 - 研究開発を通し、様々な分野の製品開発の必要性が 高まってきた - 約1年前から製品開発チームが発足して、 開発を行いつつ、基盤を整えている - 製品化の手段として、特にWeb技術を駆使して、学習モデ ルの推論サーバ・UI開発を行っている
- 15. 製品開発の課題:分野によってコンテキストが異なる - 開発アプリケーションの種類が全く異なる - 「簡素なUIだけ」・「業務システム一式」 - 「オンプレ」・「クラウド」 - 機密情報の取り扱いが重要 - 特許が関わる - BtoBなので、お客様の企業秘密を預かる
- 16. 製品開発の課題: 開発/運用を行うメンバー数が少ない - Web技術を用いて製品化を行うメンバー数が少ない - 研究開発が主だったため - 運用を行う人数が少ない - １プロジェクト１－２人程度で、兼任も - 複数プロダクトを開発/運用している - プロダクトは増加傾向にある
- 18. アジェンダ • 自己紹介 • PFNの紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 19. 課題のおさらい • 分野によってコンテキストが異なる – 開発アプリケーションの種類が全く異なる – 機密情報の取り扱いが重要 • 通信や企業秘密は分離が必要 • メンバーは少人数 – １プロジェクト１－２人程度で、兼任も – 開発と運用を同時にこなす
- 20. 課題のおさらい • 分野によってコンテキストが異なる – 開発アプリケーションの種類が全く異なる – 機密情報の取り扱いが重要 • 通信や企業秘密は分離が必要 お客様ごとに別々の環境が必要 • メンバーは少人数 – １プロジェクト１－２人程度で、兼任も – 開発と運用を同時にこなす 複数の環境を少人数で開発・運用する必要
- 21. 解決するために • 複数の環境の作成・運用コストを減らす – 共通化やモジュール化をして再利用をする – 差を意識するところを最小限にする • 誰でもアプリを安全に作れるようにする – インフラ作業待ちのようなボトルネックを減らす – アプリ開発側が気軽に新しいアプリを作れるように – 他のアプリには影響が出ないように
- 22. インフラ・アプリの関心を分離 • インフラはアプリに環境固有の問題を意識させない – VPN、インスタンス数、etc... – 可能な限り同じ作りに • 複数環境の管理の難易度も低下 • アプリはアクセスするAWSリソースを管理する – S3/KMS等 – 作成・更新・変更がアプリの関心内で収まる – 環境毎にリソースのARNを切り替えるだけにする
- 28. 開発環境Namespace内の構成が全部に使える EKS_dev app-2 pod app-1 pod pod EKS_prod_b app-2 pod pod vpc_dev vpc_prod_b
- 29. 基本戦略 AWS(terraform)+EKS • 各環境のベースは作り込まずに揃える • 構成は全てコード管理&モジュール化 – AWSリソースはterraform – アプリケーションはk8sのYAML • 必要なリソースはアプリケーション毎にモジュール化 – 相互依存をなくす – 必要なものだけ本番にデプロイ
- 30. 環境を作り込まない • ネットワークは全環境で同じ構成 – オペレーション差異をなくす – EC2の種類や個数は可変 • EKS Nodeとして使う • アプリは意識しなくてすむ – 一部例外あり(VPNとか) • 場合によっては複雑すぎる時も – EC2が1,2台で済む場合とか
- 31. terraform + モジュール管理 • アプリはモジュール内を自由に作る – S3/KMS/ACM…. – モジュール毎に基本完結 • zone_id等一部例外あり • 基本は外から注入 • アプリのモジュールを持っていけばどこでも動かせる – 環境名等をprefixでつけてかぶらないように – ${tenant}-${env}-${project}-RESORUCE_NAME
- 32. Kubernetes Namespace管理 • ベース部分は同じ構成にしたEKS – ネットワーク、Prometheus、ログ収集、etc… • Namespace内はアプリが自由に使える – １アプリ１Namespace – Pod立てたりJob作ったり比較的なんでも – Namespace間は独立 • 相互通信は基本ブロック – 本番環境に必要なNamespaceだけを持っていく
- 34. ECSでもいいのでは？ • 自社でGPU用のKubernetesクラスターがある – 研究は主にこのクラスターで行われる – Kubernetesに慣れている人が多い – 知見も豊富 • EKSならKubernetesの知見を利用できる – GPUクラスタ内で建てたアプリも持ってこれる – モデルの更新を研究者だけで可能にできる
- 36. インフラの今後の展望 • 集中監視 – 複数の環境に分断されているので個々に監視が必要 • 大変 • 外部への接続が許されないケース等も – 何を監視するかの目線合わせ
- 37. アジェンダ • 自己紹介 • PFNの紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 38. 課題のおさらい • 分野によってコンテキストが異なる – 開発アプリケーションの種類が全く異なる • 基本的に、研究開発用の推論モデルが存在する • メンバーは少人数 – １プロジェクト１－２人程度で、兼任も – 開発と運用を同時にこなす
- 39. 課題のおさらい • 分野によってコンテキストが異なる – 開発アプリケーションの種類が全く異なる • 基本的に、研究開発用の推論モデルが存在する 研究開発者とのやりとりをスムーズにしたい • メンバーは少人数 – １プロジェクト１－２人程度で、兼任も – 開発と運用を同時にこなす 簡単なオペレーションでリリースできる状態が必要
- 40. CI/CDで行いたいこと • CI – 研究成果の部分と製品部分の結合テスト – アプリケーションのテスト – dockerビルド & ECRへのpush
- 41. CI/CDで行いたいこと • CD – どのプロジェクトでも共通の方法でデプロイ – 研究者でもdev環境にデプロイできるように – 権限の絞り込み
- 42. ワークフロー 1. PRを投げるとCIでDocker ビルド 2. テストOKだったらECRにPush 3. Githubにdeployment変更のパッチ 4. マージするとArgo CDでauto deploy 5. deploy状況をUIで確認
- 43. ECR GitHub Enterprise CI Pull Request Argo CD EKS App1 App2 App3 ... Build & Test Change Deployment Push Event Notification Deploy UI Merge Notify Developer
- 44. ECR GitHub Enterprise CI Pull Request Argo CD EKS App1 App2 App3 ... Build & Test Change Deployment Push Event Notification Deploy UI Merge Notify Developer ① PRを投げるとCIでDocker ビルド
- 45. ECR GitHub Enterprise CI Pull Request Argo CD EKS App1 App2 App3 ... Build & Test Change Deployment Push Event Notification Deploy UI Merge Notify Developer ② テストOKだったらECRにPush
- 46. ECR GitHub Enterprise CI Pull Request Argo CD EKS App1 App2 App3 ... Build & Test Change Deployment Push Event Notification Deploy UI Merge Notify Developer ③ Githubにdeployment変更のパッチ
- 47. ECR GitHub Enterprise CI Pull Request Argo CD EKS App1 App2 App3 ... Build & Test Change Deployment Push Event Notification Deploy UI Merge Notify Developer ④ マージするとArgoCDでauto deploy
- 48. ECR GitHub Enterprise CI Pull Request Argo CD EKS App1 App2 App3 ... Build & Test Change Deployment Push Event Notification Deploy UI Merge Notify Developer ⑤ deploy状況をUIで確認
- 49. CI – 社内独自CIを使っていることが多い – PFNで重要なのはモジュールの分け方とテスト対象 • 研究成果とアプリケーション部分を分ける • 単体テストを基本的に入れる
- 50. CI – 社内独自CIを使っていることが多い • プロジェクトによって異なる – PFNで重要なのはモジュールの分け方とテスト対象 • 研究成果とアプリケーション部分を分ける • 単体テストを基本的に入れる
- 54. CI Research Engineer Application Engineer 開発 開発 Docker Image (Model) Docker Image (App) EKSModel Pod App Pod CI - 連結部分のテスト - 主にgrpcを使用 - Protocol Bufferのス キーマチェック
- 55. CD • ArgoCDを採用 – Kubernetesを使っている – Argoのコミッターが社内にいる • UIで簡単にデプロイ/確認を行える – 研究者も触るため – 兼任が多いため、できるだけ可視化したい • 権限を絞れる
- 56. CD • ArgoCDを採用 – Kubernetesを使っている – Argoのコミッターが社内にいる • UIで簡単にデプロイ/確認を行いたい – 研究者も触るため – 兼任が多いため、できるだけ可視化したい • 権限を絞りたい
- 61. CD • ArgoCDを採用 – Kubernetesを使っている – Argoのコミッターが社内にいる • UIで簡単にデプロイ/確認を行いたい – 研究者も触るため – 兼任が多いため、できるだけ可視化したい • 権限を絞りたい
- 62. Application Engineer Research Engineer Research Engineer ProductA Application Engineer Research Engineer Research Engineer ProductB Application Engineer Research Engineer Research Engineer ProductC Product Development Team Argo CD EKS AppA AppB AppC ... Deploy - プロダクトが分かれている - プロダクト毎にAppがある
- 63. Application Engineer Research Engineer Research Engineer ProductA Application Engineer Research Engineer Research Engineer ProductB Application Engineer Research Engineer Research Engineer ProductC Product Development Team Argo CD EKS AppA AppB AppC ... Deploy UI GitHub EnterpriseSSO - GitHubのSSO認証
- 64. Application Engineer Research Engineer Research Engineer ProductA Application Engineer Research Engineer Research Engineer ProductB Application Engineer Research Engineer Research Engineer ProductC Product Development Team Argo CD EKS AppA AppB AppC ... Deploy UI GitHub EnterpriseRBAC - ProductCはAppCのみ操作 - RBACによる制御 - GithubOrg/Teamで制御
- 66. Application Engineer Research Engineer Research Engineer ProductA Application Engineer Research Engineer Research Engineer ProductB Application Engineer Research Engineer Research Engineer ProductC Product Development Team Argo CD EKS AppA AppB AppC ... Deploy UI GitHub EnterpriseRBAC - Product Dev Teamは全て 操作可能に
- 67. CI/CD まとめ - CI - 研究者と製品開発者の部分を分離 - それぞれCIで単体テスト/ビルドを行う - これによりコミュニケーションコストを削減 - CD - ArgoCDを採用 - UIで簡単なデプロイ/確認 - 権限管理
- 68. 今後の展望 – PR単位でkubernetes上にnamespaceを切って、e2eテ ストを行う環境を簡単に立ち上げ – 全ての環境を1つのArgoCDで処理するような仕組みを 導入する • 現在は各環境に対して入れている • 機密情報の取り扱い含め、できるかどうかを 調査中
- 69. アジェンダ • 自己紹介 • PFNの紹介 • PFNの研究開発の取り組み • インフラ設計 • CI/CD • まとめ
- 70. まとめ – PFNの課題 • 製品開発の需要が高まってきたが、様々な課題 – 分野によりコンテキストが異なる – 少人数での運用
- 71. まとめ – 解決策 • インフラ – インフラとアプリの関心範囲の分割 – 他に影響しない設計で作業ボトルネックをなくす • CI/CD – 研究部分と製品部分を分け、結合部分をテスト – ArgoCDの利用 » UIから簡単にデプロイ/確認 » 権限の管理