Ml desginpattern 16_stateless_serving_function_21210511
- 2. 2 4.レジリエントサービングパターン（Resilient Serving） 1. データ表現パターン（ Data Representation） 2. 問題表現パターン（Problem Representation） 3. モデル訓練パターン（ Model Training） 4. レジリエントサービングパターン（ Resilient Serving） 5. 再現性パターン（Reproducibility） 6. 責任のあるAIパターン（Responsible AI）
- 3. 3 4章概要 本番環境に関連するさまざまな状況下での問題を解決する Stateless Serving Function サービング?インフラストラクチャが 毎秒数千から数百万の予測リクエストを処理できる Batch Serving サービングインフラストラクチャが非同期的に 数百万から数十億の予測に対する 臨時または周期的なリクエストを処理できる Continued Model Evaluation 展開されたモデルが目的に適さなくなったことを検出する Two-Phase Predictions モデルを洗練された性能に保つという 洗練されたパフォーマンスを維持する Keyed Predictions 説明したいくつかのデザイン パターンをスケーラブルに実装するために必要なもの
- 4. 4 4-1. Stateless Serving Function
- 5. 5 Stateless Serving Function 概要 本番環境のMLシステムにおいて、1秒間に数千から数百万の予測リクエストを同期的に処理 することが可能にする仕組みについて。 問題 大規模なMLシステムを検討するにあたって、性能面、多様なプラットフォームでの利用、モデルの出力形式な ど考慮すべきことは多数ある。ステートフルなモデル作成を行うと複雑度が増してスケールさせることが出来な い。 解決 ステートレスな関数と REST形式の出力でスケールアップ可能な仕組みを導入する。 それにより、スループット向上させられ、クラウドのマネージドサービスを活用してマイクロサービス化を実現す ると、クライアントのニーズに応じた多様な機能を提供できる。 さらにプロトコルバッファを利用したモデルの出力で、プラットフォーム非依存になるため 多様な環境でモデル活用できる。
- 6. 6 ステートレスとステートフル ステートフルな関数例 class State: def __init__(self): self.counter = 0 // 自分が呼び出された回数をカウンターで管理し、 // そのカウンターが奇数か偶数かによって // 異なる値を返す def __call__(self, x): self.counter += 1 if self.counter % 2 == 0: return 3*x + 15 else: return 3*x - 15 ステートレスな関数例 def stateless_fn(x): return 3*x + 15 ステートレス ステートフル 出力が純粋に入力によって決定される →同じ入力に対して常に同じ値が返る 別の表現 重みやバイアスが定数として保存されている不変のオ ブジェクト 自分が呼び出された回数をカウンターで管理し、その カウンターが奇数か偶数かによって異なる値を返す →同じ入力に対して異なる値が返る
- 7. 7 ステートレスのメリット ステートレスコンポーネント ● 状態を持たないため、複数のクライアントで共有可能 ● 拡張性に優れている ステートレス関数を使用すると、サーバーのコードが単純化され、スケーラブルに ● Webアプリケーションは、 REST APIをベースに設計が主 呼び出しのたびにクライアントからサーバーへの状態の転送 機械学習モデルでは、学習時に多くの状態が取得される ステートフルコンポーネント ● コストが高く、管理が難しい
- 8. 8 ステートフルなモデルの事例 事例：スペルチェックモデル 単語を受け取り修正された形を返す。この場合、スペルチェックモデルのクライアントは ステートフルである必要がある。 文脈に応じて "there "を "their "に修正するためには、前の数単語を知る必要がある （一連の単語を集めて文に分解するための）状態を管理し、リクエストごとにそれを送信する必要がある ↓ RNNユニットのような特殊な構造を用いて履歴を保持
- 9. 9 問題 Internet Movie Database（IMDb）の映画レビューのネガポジ予測 ● テキスト埋め込み層は、英単語の全語彙の埋め込みからかなり大きなサイズ ● 多くのレイヤーを持つ深層学習モデルも、かなりの規模 ● 予測メソッドの呼び出しは 1つずつ行う 性能面 このアーキテクチャでは達成できるレイテンシーに限界。 多様なプラットフォームで の利用 モデル開発を Python で作成しても、AndroidやiOSなどのモバイル プラットフォームでも利用可能な工夫が必要。 モデルの出力形式 モデルの出力はどうあるべきか。 予測を確率表現でする方がクライアントには後処理が少なくて良い。本番環 境ではJSON形式が使いやすい
- 10. 10 解決のステップ 1. モデルをプラットフォーム非依存形式で出力 モデルをプログラミング言語に依存しない形式で出力。 モデルの状態全体（学習率、ドロップアウト、ショートサーキットなど）は保存せず、 入力から出力を計算する数式だけを保存する。学習された重みの値は数式の中では定数。 2. ステートレス関数として復元 本番システムにおいて、モデルの「フォワード」計算で構成される数式をステートレス関数 として復元する。 3. REST形式フレームワークに展開 ステートレス関数を、 RESTエンドポイントを提供するフレームワークに展開する。
- 11. 11 プロトコルバッファとは Protocol Buffers ● データをシリアライズ (マーシャル)するためのフォーマット、メカニズム ○ クライアント/サーバー間の通信や、データの永続化などに用いる ● 様々な言語とプラットフォームで利用可能 ○ iOS や Android でも利用可能 ● バイナリ形式にシリアライズする ○ 通常サイズを大幅圧縮可能で高速 ● シリアライズ/デシリアライズ をするためのコードが自動生成される ● その他 ○ 既存のプログラムに影響を与えずにメッセージを更新 (フィールドの追加)が可能
- 12. 12 SavedModelフォーマット KerasのSavedModelフォーマット プラットフォーム非依存の効率的な復元メカニズム。プロトコルバッファを利用。 model.save()メソッドは、モデルをプロトコルバッファ (拡張子.pb)として書き込み、 学習済みのウェイトやボキャブラリなどを標準的なディレクトリ構造の他のファイルに外部化。 モデルの復元 モデルの式は、プロトコルバッファやその他の関連ファイルから、 入出力変数名とデータタイプを持つ特定のモデルシグネチャに準拠したステートレス関数として 復元される。 TensorFlow saved_model_cli エクスポートされたファイルを調べ、サービングで使用できるステートレス関数の シグネチャを決定することができる。 $ saved_model_cli show --dir ${export_path} --tag_set serve -signature_def serving_default
- 13. 13 ウェブエンドポイントの作成 マイクロサービスアプローチ ステートレス関数をWebシステムに組み込む。 例：Webアプリケーション、Google App Engine、AWS Lambda、Azure Functions、Google Cloud Functions、 Cloud Runなどのサーバーレスフレームワーク ↓ インフラのオートスケールに対応する 秒単位でのスループットを向上させるため 注意 ● シングルトンクラス化 サービング関数をグローバル変数（またはシングルトンクラス）として定義 リクエストごとにリロードされないように。
- 14. 14 why it works ● オートスケール機能 耐障害性に優れたWebアプリケーションやWebサーバーの構築が可能に ● サービングシステム活用 エクスポートしたファイルを提供するだけで、ソフトウェアが Webエンドポイントの作成 例：TensorFlow Serving、PyTorch TorchServe ● フルマネージドサービス活用 クラウドサービス活用でさらに簡易なエンドポイント生成が可能 ● 言語に依存しない REST用のHTTPスタブを自動生成するディスカバリーサービスが利用可能 ● 分業を進めてアジャイル開発可能 MLエンジニア、データサイエンティスト：独自にモデル変更可能 インフラ、アプリケーション開発者：エンドポイント変更
- 15. 15 why it works 強力なエコシステムの利用 MLモデルをWebアプリケーションフレームワークに展開すれば、既存のエコシステムを利用可能。 ● システム監査 システム監視の一環としてモデル監視可能 ● ビジネス開発担当者 機械学習モデルの計測と収益化に
- 17. 17 Trade-Offs and Alternatives オンライン予測 エクスポートされたサービング機能は、単なるファイルフォーマット ↓ モデルをエクスポートする機能がなかったとしても、 重みを抽出し、線形モデルを実行する数学モデルを書き、コンテナ化し、コンテナイメージを サービングプラットフォームにデプロイ可能 例：BigQuery＋オンライン予測 BigQueryは主に分散型のデータ処理に適、バッチ処理に適 オンライン予測を実行するには、 TensorFlow SavedModelとしてモデルをエクスポートするように BigQueryに依 頼可能
- 18. 18 ライブラリ化のメリット?デメリット 予測コードをライブラリ関数として提供 ↓ アプリケーション開発者は，アプリケーションにライブラリを組み込むことが可能 ライブラリ化の利点 ● ネットワーク遅延が発生しないため、パフォーマンスが向上 ● 計算負荷がクライアントにかかるため、サーバサイドの予算観点から望ましい場合も。 ● TensorFlow.jsでライブラリアプローチを使用すると、モデルをブラウザで実行したい場合に、 クロスサイト問題を回避可能 ライブラリ化の問題 ● ライブラリはモデルのメンテナンスとアップデートが難しい →モデルの更新頻度が高いほど、マイクロサービス?アプローチが適 ● ライブラリはプログラミング言語依存 →マイクロサービス?アプローチでは非依存 ● マイクロサービス?アプローチ並列化でスケールアップが可能