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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大規模なデータを扱う難しさ (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 - データ指向アプリケーションデザイン

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

大規模なデータを扱うためのアーキテクチャ (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

大規模なデータを扱うためのアーキテクチャ (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