プロダクション環境でフル活用するSageMaker

DeNA では、Amazon SageMaker をフル活用して実際のプロダクトの実装に取り入れています。本セッションでは、バッチ推論と Processing を Airflow と組み合わせてスケーラブルなバッチ推論パイプラインを構築した事例と、Amazon SageMaker 上にデプロイした推論エンドポイントで完全サーバレスな推論アプリケーションを構築した事例を紹介します。 これらの事例を通して、プロダクション環境で Amazon SageMaker を利用する方法と、それによってどのような利点があったのかを考えます。

Transcript

1. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. プロダクション環境でフル活用する Amazon SageMaker takumi otani Engineer DeNA Co., Ltd. 1
2. 大谷 拓海 (Takumi Otani) 経歴 - 2019/04 DeNA新卒入社 - 2019/04~ AIシステム部共通インフラ開発 - 2019/05~ 横浜DeNAベイスターズ強化プロジェクト: 機械学習パイプラインの開発運用 - 2019/07~ Nota(社内アノテーションツール): インフラ開発運用 - 2019/12~ : リアルタイム音声合成APIの構築 AIシステム部MLエンジニアリンググループ 2
3. Agenda Amazon SageMaker活用の背景: DeNA AIシステム部とは？ Amazon SageMakerとは何か？ 活用事例紹介 まとめ: Amazon SageMakerは何をもたらしたか 3
4. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
5. DeNA AIシステム部とは？ 機械学習システムの提案/開発/運用を一気通貫に担う全社横断組織 - 研究領域から、プロダクションでのシステム運用までをすべて行う 2つの役割を持つ - リサーチ: AIシステムの核となる機械学習モデルを研究開発し、その精度を保つ - エンジニアリング: モデルをサービスとして仕立て、効率的に運用する 単にモデルを開発するだけでなく、 プロダクトとして継続的・効率的に運用していくことが求められている https://dena.ai/ 5
6. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
7. Amazon SageMakerとは何か？ 複数のサービスからなるマネージド機械学習基盤 - 「すべての開発者やデータサイエンティストが機械学習 (ML) モデルを迅速に構築、トレーニ ング、デプロイできるようにする完全マネージド型サービス」 - データの作成、学習や評価、推論・運用までのすべてをサポートするプラットフォーム - Notebook/Endpoint/Processing/BatchTransformなど多くのサービスを含む - 2019年末にはSageMaker Studioが追加されるなど、急激に発展している 7
8. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
9. 事例1: リアルタイム音声合成システム 音声合成によって自然な会話を実現する 9
10. 事例1: システムへの要求 低コストに音声合成APIを提供する - APIは一般公開されず、限定された特定のクライアントから送られる - 極端なスパイクや高トラフィックは想定されない - APIコールには認証が必要 - 複数のモデルを使用して、様々な声色を合成する - 推論コストを最小化しつつ、柔軟にスケールしていく必要がある 10
11. Amazon SageMaker Endpoint - モデルを定義するだけで、webAPIサーバとして動かしてくれる - webサーバの実装はAmazon SageMakerが内部的に提供してくれるので、 開発者はそれを全く意識する必要がない webAPIサーバとしてモデルをデプロイする AWS Cloud Amazon SageMaker Endpoint モデルの読み込み 推論API インスタンスを起動して デプロイ HTTP経由でアクセス 11
12. Amazon SageMaker Endpoint import sagemaker model = sagemaker.pytorch.model.PyTorchModel( name=‘model_name’, model_data=‘s3://your-bucket/model.tar.gz’, # モデルパラメータ entry_point=‘src/serving.py’, # ローカルにあるファイルがuploadされる image='999999999999.dkr.ecr.ap-northeast-1.amazonaws.com/custom-image:latest’, role='arn:aws:iam::999999999999:role/custom-role', ) model.deploy( instance_type='ml.t2.medium’, endpoint_name=‘endpoint_name’, initial_instance_count=1, ) デプロイコード例 12
13. Amazon SageMaker Endpoint model = sagemaker.pytorch.model.PyTorchModel( name=‘model_name’, model_data=‘file://model/path’, # ローカルファイルも指定可能 entry_point=‘src/serving.py’, image='999999999999.dkr.ecr.ap-northeast-1.amazonaws.com/custom-image:latest’, role=‘/’, # roleはダミー model.deploy( instance_type=‘local’, # ‘local’を指定 initial_instance_count=1, endpoint_name=‘endpoint_name' ) LocalMode: エンドポイントをローカルで実行 13
14. Amazon SageMaker Endpoint client = boto3.session.Session().client('sagemaker-runtime') response = client.invoke_endpoint( EndpointName=‘endpoint-name’, # リクエストするエンドポイント ContentType='application/json', Body=json.dumps({‘data’: ‘hello’}), # モデルへの入力 ) エンドポイントの呼び出し - boto3からエンドポイント名指定で呼び出せる - 生のhttpインタフェースを叩くこともできる 14
15. Multi Model Endpoints - 単一エンドポイント(instance)内に複数のモデルをホストできる - モデルごとの負荷が少ないユースケースでは大幅にコスト削減が可能 通常のEndpoint instance instance instance instance instance instance instance Multi Model Endpoint 15 Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker Amazon SageMaker
16. アーキテクチャ - Amazon API Gateway + AWS Lambdaで構成されたweb APIが認証などを行い、 Amazon Sagemaker Endpointを叩いてレスポンスを作成 - 開発用webUIはAmazon S3に静的ホスト deploy Amazon SageMaker Endpoint API Key リサーチャー 学習用 EC2 instance 認証などの処理を実装 学習済みモデル 開発者/ユーザ WebUIの提供 16 AWS Lambda Amazon API Gateway
17. メリット 運用コスト最適化 - 複数のモデルを運用する必要があるが、モデルごとのリクエスト数は多くない - Multi Model Endpointsでコスト削減 - API Gateway + Lambdaの完全サーバレスで定常コストやメンテナンスコストを削減 更新容易性 - モデルパラメータを置き換え、エンドポイントをデプロイし直すだけでいい - デプロイプロセスがシンプルなため、リサーチャーはモデルの改良に集中できる 17
18. 事例2: 横浜DeNAベイスターズのチーム強化 DeNAではベイスターズの試合動画をAIで解析し、選手強化に繋げるシステ ムを運用している 18
19. 事例2: システムへの要求 毎日生成される大量の動画を複数のモデルからなるパイプラインに通し、 様々なデータを抽出する - 動画は順次メタデータが付与されてuploadされる - 多数のモデルの処理順序が複雑な依存関係を持っている - 必要な計算リソースはモデルごとに異なる - 可能な限り短時間で結果を出力し、チームにフィードバックしたい 19
20. 事例2: 初期のアーキテクチャ - 映像がAmazon S3にアップロードされるとSQSにメタデータが格納され、 オートスケールするEC2インスタンスがパイプラインを実行する - 困難な並列化、遊んでしまうGPU、低いメンテナンス性 推論結果 Developer 研究開発環境 Gateway経由でssh 試合動画 パイプライン実行 EC2 instance SQSメッセージ数で auto scaling CloudWatchで監視 SQS Amazon S3 学習済みモデル us-east-1 さらなる解析へ 20
21. Amazon SageMaker BatchTransform Amazon S3上にあるデータに対してバッチ処理による推論を実行する - リアルタイム性の必要ない推論に使う - モデル実装はEndpointと全く同じものをそのまま使える - 追加の実装コスト無しに、一つの実装でAPI化にもバッチ処理にも対応できる Amazon SageMaker BatchTransform モデル/データの読み込み 結果の書き込み 推論リクエスト モデルを使用してバッチ処理を実行する 21
22. Amazon SageMaker BatchTransform transformer = model.transformer( instance_count=1, instance_type='ml.c5.2xlarge', output_path=‘s3://your-bucket/outputs’ , # 結果が書き出されるパス ) transformer.transform( data=‘s3://your-bucket/inputs’, # 入力データが置いてあるパス ) transformer.wait() # 終了待機 - 入力データは1データ1ファイルで置いておく - 出力も1ファイルごとに出力される - ローカルモードもある 22
23. ManifestFile BatchTransformは入力としてs3上の一つのprefixしか指定できない - つまりパイプラインの各所で生成された別々のデータを参照できない - data_typeに’ManifestFile’を指定すると、複数のファイルを指定できる - 必要なobjectのpathを書いたjsonファイル - SplitTypeを’Line’に設定すると、改行区切りで複数のjsonを1ファイルに格納できる Amazon SageMaker BatchTransform 複数パスからデータを読み込む 結果の書き込み 推論リクエスト 推論に必要なデータpathを jsonで記述しs3に配置 自動で読み込まれる 23
24. 新アーキテクチャ AirFlow + Amazon SageMaker BatchTransform - ECSにAirflowを建て、SQSをポーリングしてパイプラインが起動 - 一つの機械学習モデルが一つのオペレータに対応 - 各オペレータでの処理はBatchTransformで実装 推論結果 Developer 研究開発環境 Gateway経由でssh 試合動画 SQS Amazon S3 学習済みモデル us-east-1 さらなる解析へ BatchTransform Amazon Elastic Container Service 24
25. 問題はどうなったか 並列化が容易になった - BatchTransformは独立に、並列に実行される 余分な計算資源の削減 - モデルごとに最適なリソースを分配できるようになった メンテナンス性の向上 - コンポーネントが疎結合になり、運用が容易になった 25
26. しかし、新たな問題が・・・ BatchTansformは内部的にEndpointを起動してリクエストを投げている - HTTP通信がパフォーマンスのボトルネックになりがち - 本来不要なはずのHTTPレイヤーに配慮する必要が生じる - エラー時のスタックトレースの分かりにくさにもつながっていた データ読み込みが隠蔽されていて、最適化出来ない - ナイーブな使い方では1データずつ処理されるので低速 - ミニバッチ化も可能だが、呼び出し元で行う必要があり手間 - ミニバッチ化したとしてもデータ読み込みとシリアライズがボトルネックになる - 特に動画・画像系のデータは工夫すればもっと速くロードできるはず パフォーマンスがでない？ 26
27. しかし、新たな問題が・・・ Amazon SageMakerが定義する特定の名前の関数を実装する - 実装に制約が課される。テストが書きにくい。 ローカルモードでも起動に若干時間がかかる - コードをこまめに実行しなながらデバッグするのが難しい いままでAmazon EC2内で直接実行しながら開発していたのと比べて、 試行錯誤がしにくくなりリサーチャーの負担に リサーチャーの開発効率が低下？ 27
28. Amazon SageMaker Processing - 任意のコードをコンテナ上で実行できる - BatchTransformと似ているが、よりシンプルで自由度が高い データ前処理/後処理などを簡単に実行する AWS Cloud Amazon SageMaker Processing モデル/データの読み込み 結果の書き込み 処理リクエスト 28
29. Amazon SageMaker Processing from sagemaker.processing import Processor, ProcessingInput, ProcessingOutput proc = Processor(role, image_uri, instance_count, instance_type) # 単に入力と出力を指定して任意のコードを実行する proc.run( inputs=[ ProcessingInput( source='s3://your-bucket/inputs', destination='/opt/ml/processing/input/’ ) ], outputs=[ ProcessingOutput( source='/opt/ml/processing/output', destination='s3://your-bucket/outputs’ ) ], ) 29
30. 新たなソリューション Amazon SageMaker Processingの利用 - Proessingは本来前処理などで使用することが想定されているが、これを推論に用いた - 既存の実装をほとんど無修正でそのままデプロイできるようになった - BatchTransformはEndpointと同じコードで使用できるのが強みだが、今回はEndpointを建て るユースケースが存在しない - 開発効率は向上し、実装は単純になった 30
31. さらに新たなソリューション Amazon SageMaker Training jobsの利用 - Processingは使用できるインスタンスタイプに制限があり、スポットインスタンスも使えない - AWSと共にコスト最適なソリューションを調査した結果、推論にもTraining Jobsを使うのがベ ストであることが分かった - コスト削減のため、継続的にシステムを改良している DeNAは、機能要望やフィードバックを通してAWSと密に コミュニケーションを取り、 システムやAmazon SageMaker自体の改善に協力して取り組んでいます 31
32. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. 32
33. まとめ: Amazon SageMakerは何をもたらしたか モデルの高速で低コストなデプロイ モデルさえ用意できれば、Endpointによって即座にAPI化できる 同じコードをバッチ処理で使うこともできる デプロイは様々な機能を活用してコストを最適化することも容易 33
34. まとめ: Amazon SageMakerは何をもたらしたか 規律と管理 規律なく開発されるモデルは、バージョン管理が混乱しインタフェースが曖昧になる Amazon SageMakerではモデルのバージョンが容易に管理でき、インタフェースも明確になる 34
35. まとめ: Amazon SageMakerは何をもたらしたか リサーチャーからみた使い勝手 運用の都合から生じた制約をリサーチャーに押し付けるのは避けるべき 最低限の制約と工数で、自由度の高いモデリングプロセスと確実なデプロイを実現できる 35
36. まとめ: Amazon SageMakerは何をもたらしたか - モデルの高速で低コストなデプロイ - 規律と管理 - リサーチャーからみた使い勝手 Amazon SageMakerは、モデリングと運用双方の観点から 現実的なソリューションを提供する 36