機械学習システムアーキテクチャ入門 #1

機械学習システムのアーキテクチャを検討する上で考慮すべき課題について調査しまとめた資料です。Money Forward 社内で開かれた MLOps についての勉強会のために作成しました。

## Reference

### 大規模なデータを扱う難しさ

- Architecture Evolution in Repro https://speakerdeck.com/joker1007/architecture-evolution-in-repro
- Sidekiq to Kafka ストリームベースのmicro services https://speakerdeck.com/joker1007/sidekiq-to-kafka-sutorimubesufalsemicro-services
- ReproのImport/Exportを支えるサーバーレスアーキテクチャhttps://speakerdeck.com/joker1007/exportwozhi-erusabaresuakitekutiya
- Next.js + Railsでリニューアルした社内ニコカレシステムの技術スタックを公開します - Fusic Tech Blog https://tech.fusic.co.jp/posts/2021-07-15-nicole-renewal/
- Repro における Presto の安定化・パフォーマンス改善の歩み / Repro Tech Meetup #9 https://speakerdeck.com/a_bicky/repro-tech-meetup-number-9
- MySQL/InnoDB の裏側 / Rails Developers Meetup 2018 Day 1 - Speaker Deck https://speakerdeck.com/a_bicky/rails-developers-meetup-2018-day-1
- AWS 導入事例：株式会社マネーフォワード | AWS https://aws.amazon.com/jp/solutions/case-studies/moneyforward/
- 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ / Multi-tenant EKS Muti-account architecture at Money Forward https://speakerdeck.com/0gajun/multi-tenant-eks-muti-account-architecture-at-money-forward
- O'Reilly Japan - データ指向アプリケーションデザイン https://www.oreilly.co.jp/books/9784873118703/

### 機械学習システムの難しさ

- Vertex Model Monitoring で活用する、Google の MLOps 監視手法 | Google Cloud Blog https://cloud.google.com/blog/ja/topics/developers-practitioners/monitor-models-training-serving-skew-vertex-ai
- A brief introduction to Training/Serving Skew https://zenn.dev/asei/articles/e593da33c53ee4

### 大規模なデータを扱うためのアーキテクチャ

- Big Data + Fast Data = ラムダアーキテクチャー！ | NTTデータ先端技術株式会社 https://www.intellilink.co.jp/column/bigdata/2015/041500.aspx
- ビッグ データ アーキテクチャ - Azure Architecture Center | Microsoft Docs https://docs.microsoft.com/ja-jp/azure/architecture/data-guide/big-data/#lambda-architecture
- O'Reilly Japan - データ指向アプリケーションデザイン https://www.oreilly.co.jp/books/9784873118703/
- Data preprocessing for machine learning: options and recommendations  |  Cloud Architecture Center  |  Google Cloud https://cloud.google.com/architecture/data-preprocessing-for-ml-with-tf-transform-pt1
- The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing – Google Research https://research.google/pubs/pub43864/)
- The Beam Model [model evolution and details, ~45 min] - Google スライド https://docs.google.com/presentation/d/1SHie3nwe-pqmjGum_QDznPr-B_zXCjJ2VBDGdafZme8/edit#slide=id.g12846a6162_0_4764
- Streaming 101: The world beyond batch – O’Reilly https://www.oreilly.com/radar/the-world-beyond-batch-streaming-101/
- From Lambda to Lambda-less: Lessons learned | LinkedIn Engineering https://engineering.linkedin.com/blog/2020/lambda-to-lambda-less-architecture
- MOVの機械学習システムを支えるMLOps実践 https://www.slideshare.net/takashisuzuki503/movmlops
- beam/wordcount.py at master · apache/beam https://github.com/apache/beam/blob/master/sdks/python/apache_beam/examples/wordcount.py#L80-L90
- Quotas & limits  |  Cloud Dataflow  |  Google Cloud https://cloud.google.com/dataflow/quotas#compute-engine-quotas

Transcript

1. 機械学習システム
   アーキテクチャ入門 #1
   Asei Sugiyama
   

   View Slide

2. 主旨
   機械学習システムのアーキテクチャの検討の際に考慮すべき課題につい
   て共有します
   

   View Slide

3. まとめ
   「大規模なデータを扱いたい」という要求について、単一のストレージ
   サービスですべてを賄うのは非現実的
   機械学習システムのアーキテクチャを考える上では、次の矛盾する要件
   を両立する必要がある
   学習と推論は大きく要件が異なるため別のインフラが必要
   学習と推論で共通の処理が必要 (例: 前処理)
   アーキテクチャの検討の際には推論におけるレイテンシやダウンタイム
   に注意し、できるだけ複雑にならないように注意する
   

   View Slide

4. TOC
   大規模なデータを扱う難しさ <-
   機械学習システムの難しさ
   大規模なデータを扱うためのアーキテクチャ
   実際にはどうすべきか？
   

   View Slide

5. 大規模なデータを扱う難しさ
   「なぜこんなにストレージサービスは多いのか」について次の順番で考えて
   いきます
   Repro の歩み
   単一のサービスでは解決困難な課題
   トランザクションシステムと分析処理システム
   データレイク・データウェアハウス・データマート
   なぜこんなに分析サービスは多いのか
   まとめ
   

   View Slide

6. Repro の歩み
   (1/3)
   Ruby on Rails で
   Google Analytics
   のようなシステム
   を組んでいた
   Joker さんの資料が
   詳しい
   Architecture Evolution in Repro - Speaker Deck
   

   View Slide

7. 補足: 典型的な Ruby on Rails アプリケーションの構成
   Next.js + Railsでリニューアルした社内ニコカレシステムの技術スタックを公開します - Fusic Tech Blog
   

   View Slide

8. Repro の歩み
   (2/3)
   クライアント数が
   増えるにつれバッ
   チ処理に時間がか
   かるように
   集計結果を保持す
   る中間テーブルを
   作成するも一時し
   のぎ
   Architecture Evolution in Repro - Speaker Deck
   

   View Slide

9. Repro の歩み (3/3)
   Rails アプリケーションとは
   別にデータの集計を行うバ
   ックエンドを構築
   大規模集計用に Apache
   Cassandra, Hive を採用
   リアルタイムな集計を行う
   ように Apache Kafka によ
   るストリーム処理
   

   View Slide

10. 補足: なんで遅くなるの？
    レコード数が多くなると計算量が増
    える
    SELECT: (要 index)
    JOIN: (NLJ, index なし)
    サービスが成長するにつれて、結合
    するテーブル数もテーブル内のカラ
    ムも増える
    O(log N)
    O(MN)
    MySQL/InnoDB の裏側 / Rails Developers Meetup 2018 Day 1 - Speaker Deck
    

    View Slide

11. 注意: RDB = 悪ではない
    開発しやすいことは立上げ
    期において重要
    プロダクトが拡大していく
    と要件が変わっていく
    プロダクトの状況に合わせ
    てアーキテクチャの変更が
    必要
    組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/
    マルチアカウントアーキテクチャ / Multi-tenant EKS Muti-account
    architecture at Money Forward - Speaker Deck
    

    View Slide

12. 単一のサービスでは解決
    困難な課題
    企画開発用の分析処理が困
    難
    数カ月間に渡る集計
    複数のデータソースに
    またがる集計
    プロダクト (右図) とは異な
    る期間での集計が必要
    Architecture Evolution in Repro - Speaker Deck
    

    View Slide

13. トランザクションシステムと
    分析処理システム (1/2)
    オンライントランザクショ
    ン処理 (OLTP): ユーザーの
    入力をインタラクティブに
    処理
    オンライン分析処理
    (OLAP): 大量のレコードを
    処理
    Martin Kleppmann 著 斉藤 太郎 監訳 玉川 竜司 訳 データ指向アプリケーション
    デザイン――
    信頼性、拡張性、保守性の高い分散システム設計の原理
    https://www.oreilly.co.jp/books/9784873118703/
    

    View Slide

14. トランザクションシステムと分析処理システム (2/2)
    プロダクトでは低いレイテンシーで大規模データを扱う
    クライアントが結果をすぐに知りたがっていた
    運用チームもそれに答えるため、できる限り安く安定的な運用基盤
    を目指していた
    企画開発チームは時間がかかってもべつに良かった
    社内なので1日は待てる、分析頻度も高くない
    プロダクトに負荷を与えてしまうことは望ましくない
    

    View Slide

15. データレイク・データウェアハウ
    ス・データマート
    プロダクトとは別に分析用シス
    テムを作成する
    データレイク: データを集約
    データウェアハウス: 集めたデー
    タを整形
    データマート: 使いやすいデータ
    を提供
    Martin Kleppmann 著 斉藤 太郎 監訳 玉川 竜司 訳 データ指向アプリケーションデザイン
    ――
    信頼性、拡張性、保守性の高い分散システム設計の原理
    https://www.oreilly.co.jp/books/9784873118703/
    

    View Slide

16. なぜこんなに分析サービ
    スは多いのか
    想定しているユースケ
    ースが違う
    とはいえ共通するもの
    を使っていたりもする
    (Athena, EMR, Glue)
    

    View Slide

17. まとめ
    大規模なデータを扱うためにはシステムのアーキテクチャについて継続
    的な検討が必要
    「大規模なデータを扱いたい」という要求について、単一のストレージ
    サービスですべてを賄うのは非現実的
    今扱おうとしている業務はトランザクションシステムなのか、分析処理
    システムなのかの見極めが必要
    

    View Slide

18. TOC
    大規模なデータを扱う難しさ
    機械学習システムの難しさ <-
    大規模なデータを扱うためのアーキテクチャ
    実際にはどうすべきか？
    

    View Slide

19. 機械学習システムの難しさ
    想定する機械学習システム
    学習時と推論時の非機能要件
    Training/Serving Skew
    

    View Slide

20. 想定する機械学習システム
    分析環境でモデルを訓練
    本番環境にモデルをデプロイして推論
    MLOps: 機械学習における継続的デリバリーと自動化のパイプライン | Google Cloud
    

    View Slide

21. モデルの訓練と推論
    モデルの訓練は OLAP 的な
    特性を持つ
    モデルの推論は OLTP 的な
    特性を持つ
    この2つは特性が違うので別
    のシステムとしたい
    Martin Kleppmann 著 斉藤 太郎 監訳 玉川 竜司 訳 データ指向アプリケーション
    デザイン――
    信頼性、拡張性、保守性の高い分散システム設計の原理
    https://www.oreilly.co.jp/books/9784873118703/
    

    View Slide

22. Training/Serving Skew
    訓練環境と推論環境とで、モデルに異なるデータが入力されることによ
    り発生する不都合な事象
    原因として次のものが挙げられる
    訓練環境と本番環境で実装が違う
    訓練時から時間が経過し、データの分布が変化した
    モデルの利用による不都合なフィードバックループ
    理想的には訓練時と推論時で同じパイプライン実装を使いたい
    

    View Slide

23. 機械学習システムのアーキテクチャで考慮すべき問
    「異なるシステムが必要」「同一のパイプラインが必要」という2つの
    要件をどう両立する？
    

    View Slide

24. TOC
    大規模なデータを扱う難しさ
    機械学習システムの難しさ
    大規模なデータを扱うためのアーキテクチャ <-
    実際にはどうすべきか？
    

    View Slide

25. 大規模なデータを扱うためのアーキテクチャ
    ラムダアーキテクチャ
    ラムダアーキテクチャの欠点
    Dataflow
    TensorFlow Transform + Apache Beam
    

    View Slide

26. ラムダアーキテクチャ
    同一のデータソースを2つの
    パスで処理
    Hot path: 精度を犠牲に素早
    く処理
    Clod path: すべてのデータ
    を対象にバッチ処理
    ビッグ データ アーキテクチャ - Azure Architecture Center | Microsoft Docs
    

    View Slide

27. ラムダアーキテクチャの欠点
    2つのパスの保守が難しい
    集計の要件に変更が発生した場
    合両方のパスに変更が必要
    そもそも必然的に数値がずれる
    (2つのシステムの「現在」が揃
    うことはない)
    LinkedIn では Lambda アーキテクチ
    ャを廃止した
    From Lambda to Lambda-less: Lessons learned | LinkedIn Engineering
    

    View Slide

28. Dataflow (1/2)
    「すべてストリーム処理で
    いいじゃないか」という発
    想
    バッチ処理では何らかの集
    計単位でデータを区切って
    処理している
    ストリーム処理において柔
    軟にウィンドウを設けて集
    計できれば良い
    The Beam Model [model evolution and details, ~45 min] - Google Slide
    

    View Slide

29. Dataflow (2/2)
    信じがたいが本当に作った
    (MilWheel)
    Google CLoud でサービス
    化した (Dataflow)
    ストリーム処理を書きやす
    いような SDK を作成し
    OSS にした (Apache
    Beam)
    The Beam Model [model evolution and details, ~45 min] - Google Slide
    

    View Slide

30. TensorFlow Transform + Apache Beam (1/2)
    「前処理をストリーム処理に寄せればいいのでは」という発想
    学習用のデータをストリーム処理で集計し、バッチ処理
    推論用のデータもストリーム処理で集計し、リアルタイムに推論
    ストリーム処理しかないので実装は1つで良い (!?)
    Data preprocessing for machine learning: options and recommendations | Cloud Architecture Center | Google Cloud
    

    View Slide

31. TensorFlow Transform
    + Apache Beam (2/2)
    どんな前処理でもできるわ
    けではないので要検証
    Google Cloud のドキュメン
    トは一読の価値あり
    Data preprocessing for machine learning: options and recommendations |
    Cloud Architecture Center | Google Cloud
    

    View Slide

32. TOC
    大規模なデータを扱う難しさ
    機械学習システムの難しさ
    大規模なデータを扱うためのアーキテクチャ
    実際にはどうすべきか？ <-
    

    View Slide

33. 実際にはどうすべきか？
    非機能要件に注意する
    ストリーム処理は開発とテストを複雑にする
    マネージドサービスを用いる場合であっても、十分に検証を行う
    

    View Slide

34. 非機能要件に注意する (1/2)
    レイテンシーと許容可能な
    ダウンタイムについては十
    分注意する
    MLPerf のようなベンチマー
    クを参考にする
    Data preprocessing for machine learning: options and recommendations |
    Cloud Architecture Center | Google Cloud
    

    View Slide

35. 非機能要件に注意する (2/2)
    できる限り SLA を低くでき
    るように交渉する
    Mov: 機械学習バッチが正常
    に完了しない場合のフォー
    ルバック先を用意
    m3: 機械学習 API が正常に
    動作しない場合の処理をプ
    ロダクトに実装
    MOVの機械学習システムを支えるMLOps実践
    

    View Slide

36. ストリーム処理は開発とテストを複雑にする
    Dataflow で主にサポートしている言語は Java であり Python から利用
    できる機能/利用できない機能がある (継続して改善されている)
    Python でも「Python...?」という見た目になる
    採用する場合はチーム内でのレビュー体制やスキル移転まで含めた検討
    が必要
    

    View Slide

37. Apache Beam のプログラムの例
    読めますか？
    # The pipeline will be run on exiting the with block.
    
    with beam.Pipeline(options=pipeline_options) as p:
    
    # Read the text file[pattern] into a PCollection.
    
    lines = p | 'Read' >> ReadFromText(known_args.input)
    
    counts = (
    
    lines
    
    | 'Split' >> (beam.ParDo(WordExtractingDoFn()).with_output_types(str))
    
    | 'PairWithOne' >> beam.Map(lambda x: (x, 1))
    
    | 'GroupAndSum' >> beam.CombinePerKey(sum))
    
    beam/wordcount.py at master · apache/beam
    

    View Slide

38. マネージドサービス
    を用いる場合であっ
    ても、十分に検証を
    行う
    クォータにより無
    限にはスケールし
    ない
    Dataflow はノード
    に IP が必要で、利
    用できる IP の数は
    意外と少ない
    Quotas & limits | Cloud Dataflow | Google Cloud
    

    View Slide

39. まとめ
    「大規模なデータを扱いたい」という要求について、単一のストレージ
    サービスですべてを賄うのは非現実的
    機械学習システムのアーキテクチャを考える上では、次の矛盾する要件
    を両立する必要がある
    学習と推論は大きく要件が異なるため別のインフラが必要
    学習と推論で共通の処理が必要 (例: 前処理)
    アーキテクチャの検討の際には推論におけるレイテンシやダウンタイム
    に注意し、できるだけ複雑にならないように注意する
    

    View Slide

40. Reference
    大規模なデータを扱う難しさ (1/2)
    Architecture Evolution in Repro - Speaker Deck
    Sidekiq to Kafka ストリームベースのmicro services - Speaker Deck
    ReproのImport/Exportを支えるサーバーレスアーキテクチャ - Speaker
    Deck
    Next.js + Railsでリニューアルした社内ニコカレシステムの技術スタック
    を公開します - Fusic Tech Blog
    

    View Slide

41. 大規模なデータを扱う難しさ (2/2)
    Repro における Presto の安定化・パフォーマンス改善の歩み / Repro
    Tech Meetup #9 - Speaker Deck
    MySQL/InnoDB の裏側 / Rails Developers Meetup 2018 Day 1 -
    Speaker Deck
    AWS 導入事例：株式会社マネーフォワード | AWS
    組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS ク
    ラスタ/マルチアカウントアーキテクチャ / Multi-tenant EKS Muti-
    account architecture at Money Forward - Speaker Deck
    O'Reilly Japan - データ指向アプリケーションデザイン
    

    View Slide

42. 機械学習システムの難しさ
    Vertex Model Monitoring で活用する、Google の MLOps 監視手法 |
    Google Cloud Blog
    A brief introduction to Training/Serving Skew
    

    View Slide

43. 大規模なデータを扱うためのアーキテクチャ (1/2)
    Big Data + Fast Data = ラムダアーキテクチャー！ | NTTデータ先端技術
    株式会社
    ビッグ データ アーキテクチャ - Azure Architecture Center | Microsoft
    Docs
    O'Reilly Japan - データ指向アプリケーションデザイン
    Data preprocessing for machine learning: options and
    recommendations | Cloud Architecture Center | Google Cloud
    The Dataflow Model: A Practical Approach to Balancing Correctness,
    Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data
    Processing – Google Research
    

    View Slide

44. 大規模なデータを扱うためのアーキテクチャ (2/2)
    The Beam Model [model evolution and details, ~45 min] - Google スラ
    イド
    Streaming 101: The world beyond batch – O’Reilly
    From Lambda to Lambda-less: Lessons learned | LinkedIn Engineering
    MOVの機械学習システムを支えるMLOps実践
    beam/wordcount.py at master · apache/beam
    Quotas & limits | Cloud Dataflow | Google Cloud
    

    View Slide