Slide 1

Slide 1 text

JAWS DAYS 2019 Engineer Akihisa Takeda [AI/ML] PythonとSageMakerで始める MLチームのみで完結するAPIの構築事例 1

Slide 2

Slide 2 text

事業紹介 弁護士によって行われる契約書のレビュー*を 機械学習によって行う あなたのためのリーガルサービス(The Legal Service For You)を提供 2 ※「レビュー」…条項別のリスク判定/修正案の提案/修正意図の提案など

Slide 3

Slide 3 text

自己紹介 Akihisa Takeda @ababa831 活動 ● 2018年11月~ GVA TECH 正社員 ○ ML/NLPエンジニア(見習い) ■ MLアルゴリズム研究開発~APIの構築まで ■ AWSは入社後に触れ始める 修行中! ● Kaggler (Competitions Expert) 3

Slide 4

Slide 4 text

内容 ● ML API構築の課題 ● 本講演の目的 ● Amazon SageMakerについて ● カスタムアルゴリズムによるAPIの実装 ● APIの管理 ● 得られた効果 Note: 研究開発(機械学習(ML),自然言語処理)の話はいたしません 4

Slide 5

Slide 5 text

ML API構築の課題 5

Slide 6

Slide 6 text

データ分析・ML開発業務で求められること 検証結果をAPI化し,プロダクトに反映して, 初めてユーザに体感してもらえ,サービスの価値が生まれる 検証〜プロダクト反映までのスピードが 会社の利益に直結 分析・検証 学習・ モデル変換 APIのデプロイ アルゴリズム 開発 プロダクト に反映 ユーザに初めて届く 6

Slide 7

Slide 7 text

データ分析・ML開発業務で求められること 検証結果をAPI化し,プロダクトに反映して, 初めてユーザに体感してもらえ,サービスの価値が生まれる 検証〜プロダクト反映までのスピードが 会社の利益に直結 分析・検証 学習・ モデル変換 APIのデプロイ アルゴリズム 開発 プロダクト に反映 ユーザに初めて届く この流れをできる限り高速化したい! 7

Slide 8

Slide 8 text

検証〜プロダクト反映の高速化を阻む課題 ⭕ 左半分までは普段の業務でカバー可能 ❌ APIの構築に関しては,普段の業務では扱わない別種のスキルセットが必要 分析・検証 学習・ モデル変換 APIのデプロイ アルゴリズム 開発 プロダクト に反映 別種のスキルセット 普段の業務範囲 MLチームにとって,APIの構築が大きな壁となる 8

Slide 9

Slide 9 text

EC2を利用してAPIを構築する場合 ● 初期環境設定(Linux, サーバ フレームワーク etc.)周りに手間がかかる & 作業する人によって設定の差分が発生しやすい ● 運用管理(Kernel更新,脆弱性対応)に手間がかかる ● APIをデプロイするための(インフラ, CI/CD)基盤を作るのがつらい ● 負荷分散の対応が必要 9

Slide 10

Slide 10 text

EC2を利用してAPIを構築する場合 ● 初期環境設定(Linux, サーバ フレームワーク etc.)周りに手間がかかる & 作業する人によって設定の差分が発生しやすい ● 運用管理(Kernel更新,脆弱性対応)に手間がかかる ● APIをデプロイするための(インフラ, CI/CD)基盤を作るのがつらい ● 負荷分散の対応が必要 インフラの構築・管理の知識やリソースが必要 10

Slide 11

Slide 11 text

EC2を利用してAPIを構築する場合 ● 初期環境設定(Linux, サーバ フレームワーク etc.)周りに手間がかかる & 作業する人によって設定の差分が発生しやすい ● 運用管理(Kernel更新,脆弱性対応)に手間がかかる ● APIをデプロイするための(インフラ, CI/CD)基盤を作るのがつらい ● 負荷分散の対応が必要 インフラの構築・管理の知識やリソースが必要 データサイエンティスト・MLエンジニアが 本業に集中できず生産性が落ちる 11

Slide 12

Slide 12 text

WEB・インフラチームがAPIの構築を担当する場合 ● WEB,インフラエンジニアの人的コストがかかる ● データサイエンティスト・MLエンジニアが作成した コードを読むスキルがWEB側に要求される (MLの知識,やんちゃなコードの解読) 12

Slide 13

Slide 13 text

WEB・インフラチームがAPIの構築を担当する場合 ● WEB,インフラエンジニアの人的コストがかかる ● データサイエンティスト・MLエンジニアが作成した コードを読むスキルがWEB側に要求される (MLの知識,やんちゃなコードの解読) 高速化の代わりにコスト面が犠牲に 連携がうまく行かず,あまり高速化できない 13

Slide 14

Slide 14 text

本講演の目的 14

Slide 15

Slide 15 text

本講演の目的 Amazon SageMaker + 検証・モデリングに使ったコードをそのまま利用 MLチームだけでAPIの構築・運用して, 検証〜API化までを高速化した事例を紹介 15

Slide 16

Slide 16 text

Amazon SageMakerについて 16

Slide 17

Slide 17 text

Amazon SageMaker フルマネージド型の機械学習サービス データサイエンスのワークフロー全体をカバー ● 調査・分析 あらかじめ環境構築されたJupyter notebookで手軽に分析 ● 開発・学習 SageMaker Python SDKで簡単に学習可能 ● デプロイ・運用 フルマネージドなのでEC2でAPIを構築・運用するときの問題を考えなくてよい 17

Slide 18

Slide 18 text

Amazon SageMaker フルマネージド型の機械学習サービス データサイエンスのワークフロー全体をカバー ● 調査・分析 あらかじめ環境構築されたJupyter notebookで手軽に分析 ● 開発・学習 SageMaker Python SDKで簡単に学習可能 ● デプロイ・運用 フルマネージドなのでEC2でAPIを構築・運用するときの問題を考えなくてよい WEB・インフラに詳しくないデータサイエンティスト・MLエンジニア でも簡単にMLモデルのAPI化が可能 18

Slide 19

Slide 19 text

SageMakerで使用できるアルゴリズムの選択肢 ● 組み込みアルゴリズム SageMakerで標準的に実装されている標準的なアルゴリズム MLアルゴリズムの選択,パラメータ値の設定だけで 簡単に学習・推論可能 ● カスタムアルゴリズム 自分で用意したMLのアルゴリズムをSageMakerで使えるようにしたも の SageMakerで動く学習・推論用のDockerコンテナをカスタマイズ 19

Slide 20

Slide 20 text

組み込みアルゴリズムの特徴 ⭕ 主要なMLフレームワーク(scikit-learn, TensorFlow, Chainer, etc.)に対応 ❌ 使用できるMLアルゴリズムは多くない ❌ 組み込みアルゴリズムの文法を覚える学習コストがかかる ❌ 検証で使ったMLコードを組み込みアルゴリズムに改変する工数がそれなりに かかる Note: script modeの登場で大分改変しやすくなったが,まだ対応アルゴリズムは多くない 20 ⭕: 長所, ❌: 短所

Slide 21

Slide 21 text

組み込みアルゴリズムの特徴 ⭕ 主要なMLフレームワーク(scikit-learn, TensorFlow, Chainer, etc.)に対応 ❌ 使用できるMLアルゴリズムは多くない ❌ 組み込みアルゴリズムの文法を覚える学習コストがかかる ❌ 検証で使ったMLコードを組み込みアルゴリズムに改変する工数がそれなりに かかる Note: script modeの登場で大分改変しやすくなったが,まだ対応アルゴリズムは多くない 検証の成果を素早くサービスに反映させたい データサイエンティスト・MLエンジニアのニーズにあわない 21 ⭕: 長所, ❌: 短所

Slide 22

Slide 22 text

カスタムアルゴリズムの特徴 ⭕ 手元のMLコードをほとんど改変せずにSageMaker用のコンテナ化できる ❌ 自分でコンテナを作成する必要がある →DockerfileとECR(Elastic Container Registry)にコンテナイメージを pushするスクリプトを初回用意して, SageMakerコンテナ内のコードを少し改変するだけ 22 ⭕: 長所, ❌: 短所

Slide 23

Slide 23 text

カスタムアルゴリズムの特徴 ⭕ 手元のMLコードをほとんど改変せずにSageMaker用のコンテナ化できる ❌ 自分でコンテナを作成する必要がある →DockerfileとECR(Elastic Container Registry)にコンテナイメージを pushするスクリプトを初回用意して, SageMakerコンテナ内のコードを少し改変するだけ 検証に使ったMLコードを生かして素早くAPI化したいので, カスタムアルゴリズムを利用する 23 ⭕: 長所, ❌: 短所

Slide 24

Slide 24 text

カスタムアルゴリズムによるAPIの実装 24

Slide 25

Slide 25 text

AWS構成 学習済みモデルのUP 学習時に行われること Docker imageのpush時に行われること デプロイ時に行われること API利用時に行われること VPC ECR SageMaker API EC2 web/app リクエスト & レスポンス 学習済みモデル (S3に配置) Docker image のDL 開発したMLコードが入った Docker Imageをpush ローカル開発環境 モデルDL 25

Slide 26

Slide 26 text

学習済みモデルのUP 学習時に行われること Docker imageのpush時に行われること デプロイ時に行われること API利用時に行われること VPC ECR SageMaker API EC2 web/app リクエスト & レスポンス 学習済みモデル (S3に配置) Docker image のDL 開発したMLコードが入った Docker Imageをpush ローカル開発環境 モデルDL フルマネージドなため ● ALB ● API GateWay が不要 AWS構成 26

Slide 27

Slide 27 text

学習済みモデルのUP 学習時に行われること Docker imageのpush時に行われること デプロイ時に行われること API利用時に行われること VPC ECR SageMaker API EC2 web/app リクエスト & レスポンス 学習済みモデル (S3に配置) Docker image のDL 開発したMLコードが入った Docker Imageをpush ローカル開発環境 モデルDL 処理の流れ 27

Slide 28

Slide 28 text

学習済みモデルのUP 学習時に行われること Docker imageのpush時に行われること デプロイ時に行われること API利用時に行われること VPC ECR SageMaker API EC2 web/app リクエスト & レスポンス 学習済みモデル (S3に配置) Docker image のDL 開発したMLコードが入った Docker Imageをpush ローカル開発環境 モデルDL 処理の流れ 28

Slide 29

Slide 29 text

学習済みモデルのUP 学習時に行われること Docker imageのpush時に行われること デプロイ時に行われること API利用時に行われること VPC ECR SageMaker API EC2 web/app リクエスト & レスポンス 学習済みモデル (S3に配置) Docker image のDL 開発したMLコードが入った Docker Imageをpush ローカル開発環境 モデルDL 処理の流れ 29

Slide 30

Slide 30 text

学習済みモデルのUP 学習時に行われること Docker imageのpush時に行われること デプロイ時に行われること API利用時に行われること VPC ECR SageMaker API EC2 web/app リクエスト & レスポンス 学習済みモデル (S3に配置) Docker image のDL 開発したMLコードが入った Docker Imageをpush ローカル開発環境 モデルDL 処理の流れ 30

Slide 31

Slide 31 text

ディレクトリ構成と各階層の役割 公式のリポジトリのscikit-learn用 サンプルコード*をベースにカスタマイズ * 「scikit_bring_your_own」で検索 . ├── container │ ├── Dockerfile │ ├── build_and_push.sh │ └── custom_algorithm │ ├── apps │ │ ├── .temps/ │ │ ├── 検証・学習用コード群 │ │ ├── main.py │ │ └── s3_upload.py │ ├── predictor.py │ ├── debug_api.py │ ├── test_api.py │ ├── train │ ├── serve │ ├── nginx.conf │ └── wsgi.py ├── dummy_data ├── generate_endpoint.py └── test_endpoint.py https://github.com/awslabs/amazon-sagemaker-examples/tree/master/advanced_functionality/scikit_bring_your_own 31

Slide 32

Slide 32 text

ディレクトリ構成と各階層の役割 ● ./container/custom_algorithm/apps 検証・学習用コードを利用して S3に学習済みモデルをupload . ├── container │ ├── Dockerfile │ ├── build_and_push.sh │ └── custom_algorithm │ ├── apps │ │ ├── .temps/ │ │ ├── 検証・学習用コード群 │ │ ├── main.py │ │ └── s3_upload.py │ ├── predictor.py │ ├── debug_api.py │ ├── test_api.py │ ├── train │ ├── serve │ ├── nginx.conf │ └── wsgi.py ├── dummy_data ├── generate_endpoint.py └── test_endpoint.py 32

Slide 33

Slide 33 text

ディレクトリ構成と各階層の役割 ● ./container/custom_algorithm/apps 検証・学習用コードを利用して S3に学習済みモデルをupload ● ./container/custom_algorithm SageMakerで動かすAPIサーバ(Flask), デバッグ用ローカルAPIサーバ(Flask), 学習済みモデルをSageMakerでDLするスクリプト . ├── container │ ├── Dockerfile │ ├── build_and_push.sh │ └── custom_algorithm │ ├── apps │ │ ├── .temps/ │ │ ├── 検証・学習用コード群 │ │ ├── main.py │ │ └── s3_upload.py │ ├── predictor.py │ ├── debug_api.py │ ├── test_api.py │ ├── train │ ├── serve │ ├── nginx.conf │ └── wsgi.py ├── dummy_data ├── generate_endpoint.py └── test_endpoint.py サンプルを そのまま利用 33

Slide 34

Slide 34 text

ディレクトリ構成と各階層の役割 ● ./container/custom_algorithm/apps 検証・学習用コードを利用して S3に学習済みモデルをupload ● ./container/custom_algorithm SageMakerで動かすAPIサーバ(Flask), デバッグ用ローカルAPIサーバ(Flask), 学習済みモデルをSageMakerでDLするスクリプト ● ./container カスタムアルゴリズムを入れたSageMaker用 Docker imageをECRにpushする . ├── container │ ├── Dockerfile │ ├── build_and_push.sh │ └── custom_algorithm │ ├── apps │ │ ├── .temps/ │ │ ├── 検証・学習用コード群 │ │ ├── main.py │ │ └── s3_upload.py │ ├── predictor.py │ ├── debug_api.py │ ├── test_api.py │ ├── train │ ├── serve │ ├── nginx.conf │ └── wsgi.py ├── dummy_data ├── generate_endpoint.py └── test_endpoint.py 34

Slide 35

Slide 35 text

ディレクトリ構成と各階層の役割 ● ./container/custom_algorithm/apps 検証・学習用コードを利用して S3に学習済みモデルをupload ● ./container/custom_algorithm SageMakerで動かすAPIサーバ(Flask), デバッグ用ローカルAPIサーバ(Flask), 学習済みモデルをSageMakerでDLするスクリプト ● ./container カスタムアルゴリズムを入れたSageMaker用 Docker imageをECRにpushする ● . エンドポイントの作成とAPIの動作確認 . ├── container │ ├── Dockerfile │ ├── build_and_push.sh │ └── custom_algorithm │ ├── apps │ │ ├── .temps/ │ │ ├── 検証・学習用コード群 │ │ ├── main.py │ │ └── s3_upload.py │ ├── predictor.py │ ├── debug_api.py │ ├── test_api.py │ ├── train │ ├── serve │ ├── nginx.conf │ └── wsgi.py ├── dummy_data ├── generate_endpoint.py └── test_endpoint.py 35

Slide 36

Slide 36 text

PC(ローカル)上に次を用意 ● 手元の検証用 MLコード ● 一時的に保存したモデルをS3に Uploadするコード main.pyの実行 1. モデルの学習 2. 学習済みモデルをローカルに 一時的に保存 3. モデルをS3にUpload apps 検証用MLコード .tmps そのまま利用 s3_upload.py main.py main.py py 検証用ML コード .tmps 学習 UP S3 Bucket py 実装のポイント [学習 & モデルのUpload] 36

Slide 37

Slide 37 text

Flaskでルーティング 受信,推論,レスポンス処理 predictor.py(抜粋) apps .tmps s3_upload.py main.py 検証用MLコード custom_algorithm predictor.py 実装のポイント [推論用 API] 37

Slide 38

Slide 38 text

Flaskでルーティング 受信,推論,レスポンス処理 predictor.py(抜粋) apps .tmps s3_upload.py main.py 検証用MLコード custom_algorithm predictor.py 具体的な推論処理はapps内で! アルゴリズム変更時に ここを変えなくて良い 推論結果 実装のポイント [推論用 API] 38 頻繁に変更

Slide 39

Slide 39 text

デプロイ時にtrainスクリプトが走る →このとき,boto3でS3からSageMaker用コンテナにDLされるようにコードを作成 custom_algorithm predictor.py apps train # (省略) model_path = '/opt/ml/model' class Train(object): def train(self): # (省略) self.download_from_s3(model_s3_path, dst_filename) # (省略) def download_from_s3(self, obj_s3_path, dst_filename): # (省略) dst = os.path.join(model_path, dst_filename) with open(dst, 'wb') as data: s3.download_fileobj(bucket_name, obj_s3_path, data) デプロイ時に走る 実装のポイント [デプロイ時にSageMaker用コンテナにモデルをDL] 39

Slide 40

Slide 40 text

デプロイ時にtrainスクリプトが走る →このとき,boto3でS3からSageMaker用コンテナにDLされるようにコードを作成 custom_algorithm predictor.py apps train # (省略) model_path = '/opt/ml/model' class Train(object): def train(self): # (省略) self.download_from_s3(model_s3_path, dst_filename) # (省略) def download_from_s3(self, obj_s3_path, dst_filename): # (省略) dst = os.path.join(model_path, dst_filename) with open(dst, 'wb') as data: s3.download_fileobj(bucket_name, obj_s3_path, data) SageMakerが想定するモデルの配置先 実装のポイント [デプロイ時にSageMaker用コンテナにモデルをDL] 40

Slide 41

Slide 41 text

デプロイ時にtrainスクリプトが走る →このとき,boto3でS3からSageMaker用コンテナにDLされるようにコードを作成 custom_algorithm predictor.py apps train # (省略) model_path = '/opt/ml/model' class Train(object): def train(self): # (省略) self.download_from_s3(model_s3_path, dst_filename) # (省略) def download_from_s3(self, obj_s3_path, dst_filename): # (省略) dst = os.path.join(model_path, dst_filename) with open(dst, 'wb') as data: s3.download_fileobj(bucket_name, obj_s3_path, data) Trainクラス > trainメソッドに S3からモデルをDL 実装のポイント [デプロイ時にSageMaker用コンテナにモデルをDL] 41

Slide 42

Slide 42 text

1. ローカル上でAPIの動作確認をできるように,次のコードを用意 ● local_api.py predictor.pyに,Flaskのdebugモードを追記 ● test_api.py urllib.requestを用いて,適当なデータを送信し,結果を取得 custom_algorithm predictor.py apps train local_api.py test_api.py 実装のポイント [ローカルでAPIのdebug] 42

Slide 43

Slide 43 text

2. ECRにpushするDocker imageを使い,ローカル上でコンテナを起動 ● APIサーバ側 ● クライアント側 a. `docker ps`で起動中コンテナIDを確認 b. `docker exec`でAPIを叩く 実装のポイント [ローカルでAPIのdebug] 43

Slide 44

Slide 44 text

カスタムアルゴリズム入りDocker imageをつくるため,ローカルの `custom_algorithm`ディレクトリをコンテナにコピペするコードをDockerfileに記述 COPY custom_algorithm /opt/program WORKDIR /opt/program Dockerfile(抜粋) custom_algorithm コピー custom_algorithm container Dockerfile build_and_push.sh 実装のポイント [Dockerfile] 44

Slide 45

Slide 45 text

Docker image作成して,ECRにpushするシェルスクリプトをつくる # ECRリポジトリの確認 aws ecr describe-repositories --repository-names "${image}" > /dev/null 2>&1 # 該当するリポジトリが一覧になければ,新規作成 if [ $? -ne 0 ] then aws ecr create-repository --repository-name "${image}" > /dev/null fi # ECRにログイン $(aws ecr get-login --profile ${profile} --region ${region} --no-include-email) # Docker image 作成→ECRへpush docker build -t ${image} . docker tag ${image} ${fullname} docker push ${fullname} build_and_push.sh(公式リポジトリ*引用, Dockerfileと同ディレクトリ) 実装のポイント [Docker imageのpush用コード] 45 https://github.com/awslabs/amazon-sagemaker-examples/blob/master/advanced_functionality/scikit_bring_your_own/container/build_and_push.sh

Slide 46

Slide 46 text

AWS上でIAM, VPC周りを設定した後, APIをデプロイしてエンドポイント作成 APIをデプロイするためには SageMaker SDK+組み込みアルゴリズム を介す必要あり # 学習用ダミーデータセットをS3に配置 data_location = session.upload_data( './dummy_data.pkl', key_prefix=s3_prefix) # (中略) # SageMaker SDKの学習器を設定 clf = sagemaker.estimator.Estimator( training_image, arn_iam_role, train_instance_count=1, train_instance_type='ml.m4.xlarge', sagemaker_session=session, subnets=subnets, security_group_ids=secur_group_ids) # 空学習 clf.fit(data_location) 実際の学習済みモデルは,デプロイ中に前述のtrain スクリプトが走り,S3からSageMakerコンテナにDL 実装のポイント [エンドポイントの作成] ダミー組み込みアルゴリズムを空学習 46

Slide 47

Slide 47 text

● boto3で確認 ● AWS CLIで確認 SageMaker側のログはCloudWatchで確認できる runtime_client = boto3.client('runtime.sagemaker') response = runtime_client.invoke_endpoint( EndpointName=sagemaker_endpoint_path, ContentType='application/json', # リクエストのMIMEタイプ Body=test_serialized, # 送るデータの中身 Accept='application/json' # レスポンスのMIMEタイプ ) $ aws sagemaker-runtime invoke-endpoint --endpoint-name 'hoge' ¥ > --body '{"input": 1}' --content-type 'application/json' output.txt 実装のポイント [APIの動作確認] 47

Slide 48

Slide 48 text

APIの管理 48

Slide 49

Slide 49 text

APIのモニタリング(負荷,scaling)エンドポイントの管理(確認,削除)機能 AWSコンソール > Amazon SageMaker APIの管理 49

Slide 50

Slide 50 text

APIのモニタリング(負荷,scaling)エンドポイントの管理(確認,削除)機能 AWSコンソール > Amazon SageMaker APIの管理 API運用に関する知見の少ない データサイエンティスト・MLエンジニアにとっても扱いやすい 50

Slide 51

Slide 51 text

得られた効果 51

Slide 52

Slide 52 text

● SageMakerによって,API構築がMLチームで完結 ○ EC2の初期環境設定の工数(数日)→ 不要 ○ EC2のメンテナンス((不)定期 x 日/回)→ 不要 →分析業務にリソースを割ける!APIの数が増えても平気! ● 検証用コードの改変自由度が高く,(ほぼ)そのまま使える → 新version APIリリースが1日で! ● フルマネージド+SageMaker APIの管理機能 ○ リクエスト数が増えた時のスケールアウトを勝手にやってくれる ○ 過去作成したエンドポイントへの切り替えが簡単 → WEB側もその切り替えのみで対応可能 得られた効果 52

Slide 53

Slide 53 text

● SageMakerによって,API構築がMLチームで完結 ○ EC2の初期環境設定の工数(数日)→ 不要 ○ EC2のメンテナンス((不)定期 x 日/回)→ 不要 →分析業務にリソースを割ける!APIの数が増えても平気! ● 検証用コードの改変自由度が高く,(ほぼ)そのまま使える → 新version APIリリースが1日で! ● フルマネージド+SageMaker APIの管理機能 ○ リクエスト数が増えた時のスケールアウトを勝手にやってくれる ○ 過去作成したエンドポイントへの切り替えが簡単 → WEB側もその切り替えのみで対応可能 得られた効果 53 検証の成果をプロダクトへ素早く反映できる体制が整った

Slide 54

Slide 54 text

最後に... We're Hiring! 54 Wantedly GVA TECH