ZOZOのMLOpsチームにおける監視への取り組み / Observability in 10 mins at ZOZO MLOps

社内の勉強会資料を公開します

Transcript

1. MLOps チームにおける監視への取り 組み
 SRE技術共有会 #15 
 株式会社ZOZOテクノロジーズ
 MLOpsチーム
 太田 航平 Copyright © ZOZO Technologies, Inc.
2. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 開発部
 MLOpsチーム エンジニア 太田 航平
 2018年4月入社
 開発部のPBチームにて、AWSを中心とした海外向け自社ECのインフ ラ開発や運用などを担当後、SREとして各所のインフラに従事。
 2019年6月より、MLOpsチームに配属となり、主にGCPを使った機械 学習基盤の設計構築や運用などを行っている。
 2
3. © ZOZO Technologies, Inc. • MLOps について
 • 提供しているサービスの紹介
 • 監視の考え方と各サービスの使い分け
 アジェンダ
 3
4. © ZOZO Technologies, Inc. MLOps について
 4
5. ZOZO MLOpsチーム 2019年4月に発足 • リーダーのsonotsさんが入社して３ヶ月後　 • 発足時2名 → 現在4名 • ZOZO研究所があったが、本番にML機能を出せていない課題があった MLOps チームのミッション • MLプロダクトを世に出すために必要となるモデル作成以外の全てのエンジニアリングを担当 し、MLエンジニアが優れたモデルを作ることに注力できるようにする • 特にMLエンジニアが(一般的に)得意としていないプロトタイプからプロダクションレベルへの 引き上げフェーズで成果を発揮することがミッション
6. チームの現状のフェーズ Phase1: ML機能を１つプロダクションに出す • チーム自体のオンボーディング(立ち上げ) • レベルの高い(技術選定が妥当である、安定している、十分に高速)インフラを構築できることを示す ◦ MLOpsチームへの社内からの信頼を得る → 次の仕事を得る ◦ 社外からの技術プレゼンスを得る → 優秀な人材の採用に繋げて仕事の幅を広げられる下地を作る • １つ目なので社内外からの信頼度はまだ低い状態 Phase2: ML機能を複数プロダクションに出す • ML機能をさらに出すことで、再現性があることを示す。 • それにより、社内外からの信頼度をさらに高める。 • 新メンバーを受け入れて、新メンバーのオンボーディング Phase3: ML機能の量産体制を整える, e.g., ML基盤？ イマココ
8. © ZOZO Technologies, Inc. 提供しているサービスの紹介
 8
9. © ZOZO Technologies, Inc. 9 • サイトの画像からアイテムを検出 • カテゴリごとに分類 • ZOZOTOWN で実際に販売されてい る類似のアイテムを表示 ↓ 安い商品や、売り切れた商品からの導 線としてサジェストすることでユーザー の購買意欲を促進 ZOZOTOWN の類似画像検索

10. © ZOZO Technologies, Inc. 10 • WEAR のトップ画面で動作 ◦ 個人の興味関心によってオス スメのコーディネートを出し分 け WEAR のパーソナライズ機能

11. © ZOZO Technologies, Inc. 11 MLOps チーム の基本的なソフトウェアスタック(その1)
 サーバアプリケーション • Python/Flask/Gunicorn/Swagger/gRPC • Chainer/CuPy (TensorFlow/TPU も検証) インフラ • 推論 API: Google Kubernetes Engine (GKE) + Memorystore (Redis) • Cloud Load Balancer (L7) + Cloud Armor • 学習: Cloud Composer + GKE + Filestore (NFS) • Cloud Storage (GCS) / Container Registry (GCR) • AWS Route53 (ドメイン発行) / Terraform • Datadog / Stackdriver / Sentry Cloud Composer Kubernetes Engine Cloud Memorystore Cloud Filestore Cloud Load Balancing Cloud Armor Cloud Storage Container Registry Stackdriver
12. © ZOZO Technologies, Inc. 12 MLOps チーム の基本的なソフトウェアスタック(その2)
 サーバアプリケーション • Java/Spring Boot インフラ • API: Google Kubernetes Engine (GKE) + Cloud SQL (MySQL) • Cloud Load Balancer (L7) • インデクシング: Cloud Dataflow / BigQuery • Cloud Functions / Cloud SQL / Cloud Scheduler • Terraform Kubernetes Engine Cloud SQL Cloud Scheduler Cloud Load Balancing Google App Engine Cloud Functions Container Registry Stackdriver Cloud Dataflow
13. © ZOZO Technologies, Inc. 主に GCP を中心とした
 アプリ基盤を扱っています
 13
14. © ZOZO Technologies, Inc. 監視の考え方
 14
15. © ZOZO Technologies, Inc. 15 GCP における監視サービス
 Cloud Monitoring メトリクスの監視 Google Cloud Operations Suite (旧Stackdriver) Cloud Logging ログの監視 Cloud Trace アプリの監視
16. © ZOZO Technologies, Inc. 16 GCP における監視サービス
 Cloud Monitoring メトリクスの監視 Google Cloud Operations Suite (旧Stackdriver) Cloud Logging ログの監視 Cloud Trace アプリの監視 これらをサービスが継続して提供できているかどうかという基準で組み合わせる ・例えばプロセス監視などは原則しない 理由: コンテナやマネージドな基盤ではプロセスが入れ替わる回数がVMやベアメタルに比べ 大幅に増えるので、メトリクスを取ってもあまり意味がない ・ログはN分間にM回以上継続して出た場合などをトリガーにアラート ・余計なログを見つけたらアプリケーション側と協力して潰す (必要ならコードを書く) ・最終的には、E2Eで正常に動いてればヨシ！ モニタリング、ロギング、トレーシングの組合せによって可観測性(Observability)を担保
17. © ZOZO Technologies, Inc. 17 • Cloud Monitoring (Monitoring) ◦ e.g., CloudWatch Metrics, Datadog Metrics, Prometheus + Grafana • Cloud Logging (Logging) ◦ e.g., CloudWatch Logs, Datadog Logs, Splunk • Cloud Trace (Tracing) ◦ e.g., AWS X-Ray, Datadog APM, NewRelic APM (G社にとって) 競合のツール

18. © ZOZO Technologies, Inc. 18 • Cloud Monitoring (Monitoring) ◦ e.g., CloudWatch Metrics, Prometheus + Grafana, Datadog Metrics • Cloud Logging (Logging) ◦ e.g., CloudWatch Logs, Datadog Logs, Splunk • Cloud Trace (Tracing) ◦ e.g., NewRelic APM, Datadog APM (G社にとって) 競合のツール
 お値段や要件に合わせて使い分け ・予算の出るサービスでは会社的に使おうとしているDatadogを使う ・そうじゃないプロジェクトでは原則そのクラウドで使える範囲で頑張る Datadog Logsはかなり高いので敬遠気味・・・ メトリクスも基本的にCloud Metricsで十分なことが多い APMだけはDatadogのものが使いやすいので採用することが多い
19. © ZOZO Technologies, Inc. 19 実際に見ている内容
 ・LBのリクエスト数やその傾向 ・レスポンスタイムの監視 ・200以外のステータスを返す場合の通知やエラー内容 ・バッチがコケたり期待通りの時間に終わっていない場合の通知 etc → サービスへの影響度が高いものを優先的に見ている
20. © ZOZO Technologies, Inc. 20 • アプリケーションのエラー監視 ◦ Sentry ▪ アプリケーションに関わるログだけを可視化できるサービス ▪ 安いし機能も十分だし使いやすい ◦ Cloud Error Reporting ▪ GCPのサービスだけど通知機能が貧弱で使いづらかった その他のサービス

21. © ZOZO Technologies, Inc. 21 • 死活監視 (GCP ではサービスとしてカバーしていない) ◦ E2E の監視に利用 (HTTP Status 200かどうか) ◦ MLOpsではDatadog の Synthetics を活用 ▪ HTTP Headerとかを気軽に渡せるのでとても便利 ▪ New Relic でも使えるし、最近だと AWS でも出ましたね その他のサービス

22. © ZOZO Technologies, Inc. 22 • パブリッククラウドのコンソールにログインしなくても良い ◦ 非基盤運用者が余計な操作をするリスクを考えなくて良い ◦ IAM権限の管理コスト削減 • インテグレーションが豊富なことが多い ◦ 複数クラウド・複数プロジェクトを同じサービスで監視できるので監視にお けるコンテキストスイッチが減らせる • (主観だが) Datadogは全体的にかなり使い勝手(利用体験)が良かった 監視SaaS を使うメリット

23. © ZOZO Technologies, Inc. 23 • 高い (Sentryは安い) ◦ CloudWatch や Cloud Operations Suite に比べて圧倒的に高い ◦ APMもCloud Traceとそれ以外ではかなりお値段に差がある • 横断的に使える一方で連携の設定は必ず必要だし、メトリクスの自由度もク ラウドまたは監視サービスの限界に引っ張られる • (特に外資の場合) サポートの対応が大手クラウドに比べ弱い ◦ 日本法人がいずれも小さいので日本語だとなお弱い 監視SaaS を使うデメリット

24. © ZOZO Technologies, Inc. 24 • 高い (Sentryは安い) ◦ CloudWatch や Cloud Operations Suite に比べて圧倒的に高い ◦ APMもCloud Traceとそれ以外ではかなりお値段に差がある • 横断的に使える一方で連携の設定は必ず必要だし、メトリクスの自由度もク ラウドまたは監視サービスの限界に引っ張られる • (特に外資の場合) サポートの対応が大手クラウドに比べ弱い ◦ 日本法人がいずれも小さいので日本語だとなお弱い 監視SaaS を使うデメリット
 値段相応の使い込み方ができるかも重要な観点 監視は基本的にプロダクト運用においては純粋なコストなので、それ なりのコストで使い倒せるものを選ぶのが良い