分析ステップ学習ステップモデルデプロイステップまとめ参照はじめにここでは、これまでLambdaで行なっていた推論をSageMakerに置き換えた話を書きます。置換え前は、推論を行うLambdaをデプロイするための準備作業(デプロイ先環境に合わせたコード整理など)が煩雑で、データ分析者とデプロイ担当のエンジニア間での役割分担がうまくできていないという課題がありました。そこで、全体の開発フローも含めて見直そうということでSageMakerへの置換えを検討しました。役割を完全に分けることは難しいが分析担当者とエンジニアがお互い歩み寄るための機能がSageMakerに備わっていることが分かりました。おける役割分担を検討したい方にとっての一例として参考になればと思います。SageMakerを検討する際に何を考えどう判断したかを記しています。上図が移行前の構成をシンプルに表した図です。各サービスの役割や処理の流れは以下の通りです。基本的には移行前と同じですが、それを以下のように変更しました。学習済みモデルのデプロイ推論用エンドポイントの作成これまで手動や自前のスクリプトで行なっていた作業をSageMaker組込み機能により行うことができるようになります。これによって、よりシンプルな操作で作業することが可能になります。SageMaker上で分析用コードを作成していれば、そのままデプロイまで行うことができます。他プロジェクトでもSageMakerを採用していれば、作業を統一でき属人化を防ぐことができます。「移行前の構成」にした理由APIを構築するにあたりLambdaを採用した理由は運用コストを減らすためです。死活監視などの手間をできるだけ減らし分析に集中するため、EC2ではなくLambdaを選択しました。選択当時、機能としてLambdaで十分だったためSageMakerはあえて選択しませんでした。この時の開発の流れは以下の通りでした。整理したコードをLambdaへデプロイ移行理由その後、機能や人員が増える一方で、分析担当者皆がLambdaを用いた開発が得意という訳ではない状況になってきました。分析担当者が書いたコードをLambda用に書き換える作業のコストが高く、この作業を減らしたいという要望がありました。この工程としては以下の通りです。継続してメンテナンス可能なよう必要に応じてクラス化など行う学習・推論などのテストコード作成モデルなどの参照パスをデプロイ先のファイルを参照するよう変更FlaskによるAPIインターフェイスの作成APIリクエスト含むテストコード作成Lambdaへデプロイ動作確認できるまで修正加え上記作業繰り返しまた、1回のデプロイ処理に20分前後かかっていたため、うまくいくまでの試行錯誤に非常に時間がかかりました。分析時のコードとデプロイ時のコードに乖離があることといったところです。そこで、SageMakerを導入し分析担当者が書いたコードをそのままデプロイできないか各々の役割の範囲を明確に分けることができないかということを検討しました。結論としては、完全に分けることは難しいが分析担当者とエンジニアがお互い歩み寄るための機能が備わっていることが分かりました。その機能というのは前にも述べていますが、SageMaker上で分析、学習、モデルデプロイ、推論用エンドポイントの作成を比較的簡単に行うことができるというものです。メリットであると感じた点は、分析時からデプロイ時の環境(モデルの配置先など)などを意識してコーディングすることになるため、その修正作業が最小限になるといった点です。Lambdaでも同じことが言えるのではないかと考えると思いますが、分析からデプロイまでSageMaker上で行うことを想定されてつくられているため、Lambda使用時よりシームレスにコーディング可能だと感じました。これらを活用し、分析担当者が分析からモデルのデプロイまで担当可能な環境を整えることを目指しました。SageMaker上での開発フローここでは、SageMakerを用いた具体的な開発について記します。対象としている作業の範囲は以下の通りです。分析ステップ学習ステップモデルデプロイステップ主にSageMakerの機能について触れ、上記前後に必要であろうデータ準備や外部サービスとの連携については割愛します。ここまでの作業を分析担当者が行うことで、その後のエンジニア担当作業への連携を円滑に行うことができる想定です。基本的には以下を参考に進めると良いです。本稿ではすぐに使えるよう要点のみ記します。SageMakerまで進めて、ノートブックを作成します。ノートブックにおける下準備ノートブックを作成したので、最初に下準備を行います。これ以降はノートブック上での作業となります。sess.boto_session.region_nameデータ格納先の指定S3へデータをアップロードします。ここでは、ノートブックインスタンス上のデータ格納先ディレクトリを指定し、S3へアップロードしています。sess.upload_data("notebook_instance_dirname")分析ステップ分析担当者が思い思いの実験を行います。ここで有効だと判断した手法を次の学習ステップで使用しましょう。このステップは必ずしもSageMakerを介して行う必要はありません。各自の環境で実験し、学習はSageMakerのリソースを使用するといったことも可能です。その場合は、SageMaker組込みの機能を使用せず、自前のDockerイメージをECRへ登録することになります。はまりどころが多く長くなってしまうのでこの話は別の機会に。(いきなりECRに触れましたが、自前のDockerイメージを使わない限りは特別ECRの存在を意識せず済むよう隠蔽されたつくりとなっています。この後のステップで出てくる「イメージ」というのはSageMakerで使用するアルゴリズムが登録されたもの程度の認識でも問題ないと思います。重要なのはそういったことを意識せず済むということなので。)学習ステップイメージ指定まず、学習に使用するアルゴリズムのコンテナイメージを指定します。'xgboost')独自の学習・推論コンテナイメージを使用することも可能で、その場合はECRに登録したイメージを参照することになります。推論用にWebサーバを含めたりとデータ分析範囲外の作業が発生するためエンジニアの協力が必要です。基本的には組込みのイメージで済ませる方がシンプルで分かりやすいシステムを構築できると思います。インスタンスを作成します。SageMakerが学習結果を保存するのに使用します。学習タスクの重さに応じて変更してください。実行すると学習が始まるので終わるまで待ちます。"data.csv")モデルデプロイステップモデルをデプロイすることで、Lambdaからのリクエストを受け推論を行うことができるようになります。デプロイここではCSVの入力を想定しています。