機械学習のワークフローってどうなっているの ? AWS の機械学習サービスをグラレコで解説

2020-03-02
AWS 最新ドキュメント紹介

Author : 辻 陽平

本連載では、様々な AWS サービスをグラフィックレコーディングで紹介する awsgeek.com を、日本語に翻訳し、図の解説をしていきます。

※ awsgeek.com は Amazon Web Services, Inc. プリンシパル・テクニカル・エバンジェリスト、ジェリー・ハーグローブが運営しているサイトです。

みなさんは Amazon SageMaker というサービスをご存知でしょうか ?
 
トップページではこのように紹介されています。

Amazon SageMaker は、すべての開発者やデータサイエンティストが機械学習 (ML) モデルを迅速に構築、トレーニング、デプロイできるようにする完全マネージド型サービスです。

この文章から具体的に実現できることを想像するのは難しいかもしれません。そもそもモデルの構築、トレーニング、デプロイというものがどういうもので、どういう手順で行うかがわからないですよね。そこで、機械学習に必要なことを紐解きながら、対応する SageMaker の機能を紹介します。

今回はそんな Amazon SageMaker について、具体的に、どのような機能を提供してくれるのか見ていきます。

機械学習のワークロードとは ?

Amazon SageMaker では機械学習のワークロードを簡単にする機能を提供します。ここで言うワークロードというのは一体どのようなものなのでしょうか、簡単に整理してみましょう。

よく機械学習のワークロードとして登場するのは、「データの前処理」、「学習」、「推論」の 3 つです。現実ではこれら 3 つだけでは成立せず、他のワークロードと組み合わせることで実現されます。どのようなものがあるかはユーザーによって様々だとは思いますが、ここでは右の図にあるように 7 つのワークロードを考えます。

7 つのワークロードがつながってループ構造のワークフローを形成しています。お客様の実際のワークフローも一致とまではいかないまでも近いものになっているのではないでしょうか。

図にはありませんが、追加の大事なワークロードとして「モデルの構築」もあります。これは、4 番と 5 番を巡回するように処理されます。

「モデルの構築」を加えた合計 8 つのワークロードを処理するときの Amazon SageMaker の便利な機能を紹介していきます。

img_awsgeek_sagemaker_01

データの収集

機械学習で始めに立ちはだかる困難はデータの収集です。

一般論としてデータは多ければ多い方が良いです。しかし、これを達成するのは用意ではありません。特に教師あり学習では入力データ 1 つ 1 つに対して、機械学習のモデルが正解として出力してほしいラベルをつける作業が必要となります。これをラベリングと呼びます。このラベリング作業は人手が要求されることが多く、大きな負担になります。

ラベリングの負荷を下げるための1つの選択肢として Amazon SageMaker Ground Truth があります。Amazon SageMaker のマネジメントコンソールや API を通して利用することができます。

Amazon SageMaker Ground Truth では手動ラベリングと自動ラベリングを選択することができます。

手動ラベリングを選択した場合、3 種類のチームのうち、どのチームに仕事を振り分けるか選択することができます。1 つ目が社員などのプライベートのチーム。2 つ目が Amazon Machanical Turk を使用したパブリックのチーム。そして 3 つ目はベンダーなどのサードパーティーのチームです。チームのメンバーは Amazon SageMaker Ground Truth が用意した UI を通してラベリング作業を行います。

自動ラベリングは、手動ラベリングに追加して有効化することができます。自動ラベリングを有効化すると、ビルトインアルゴリズムを利用した機械学習のモデル学習が行われ、その後、自動でラベリングが実行されます。

ラベリングされたデータは安価で高耐久なオブジェクトストレージである Amazon S3 のバケットに格納されます。

ラベリングを簡単にするサービスを紹介しましたが、そもそもラベリングが必要なデータ量を減らすという手もあります。すでに公開されている学習済みのモデルを使えば、少量のデータでも精度の良いモデルを作れる可能性があります。その上で Amazon SageMaker Ground Truth などを利用してラベリングを簡単にし、全体のコストを削減していきます。

データの収集ができたら、適切に変換していきます。

データの前処理 (データのクレンジング、データの変換)

ワークフローの図の「データのクレンジング」と「データの変換」にあたる箇所になります。データのクレンジングでは、収集ミスやラベリングミスによるデータを取り除いたり、欠損値を違う値で埋める作業などを行います。一方データの変換では、数値データを -1 から 1 のデータに標準化したり、次元削減などでデータ量を減らす作業などを行います。前者はモデルへの入力時のエラーや学習が破綻するのを防ぐため、後者はモデルの品質を向上させるため、が主な目的です。どちらも処理としては似ているため、まとめて「データの前処理」として扱うことが多いです。

データは多ければ多いほど良いと言ったものの、品質が悪ければ意味はありません。適切な前処理は、多くの場合、ハイパーパラメータチューニングなどよりもモデルの良し悪しを左右します。

データの前処理では、まず人によるデータの理解から始まります。Ad-hoc にデータの可視化をしつつどのような処理が適切か探ります。このようなワークロードでは Jupyter Notebook/JupterLab などを利用して、コーディングや可視化を対話的に実行するのが適しています。

Ad-hoc な検証が終わり、データの前処理に関する実装方針が決まれば大量のデータに対してバッチ処理します。バッチ処理では必要な時に、必要な分だけリソースを用意するのが望ましいです。このような処理はクラウドのスケーラビリティと従量課金の性質を活かすことができます。バッチ処理を実現できる AWS のサービスはたくさんありますが、機械学習のワークロードでは Amazon SageMaker Processing が 1 つの選択肢となります。

Amazon SageMaker Processing では Amazon SageMaker SDK を通して、コンテナイメージ、前処理のコード、入力と出力の Amazon S3 バケットを指定することで、自動でインフラの構築と処理をしてくれます。Amazon EC2 インスタンスの起動や停止、ライブラリのインストールなどを考える必要はなくなります。

Amazon SageMaker で一気通貫に行う必要がない場合は AWS Batch などのサービスも利用できます。より複雑なデータの変換などをしたい場合や Apache Spark で大規模に処理した場合などは AWS Glue を利用すると良いでしょう。

データの前処理ができたら、学習対象となるモデルを構築していきます。

モデルの構築

モデルの構築の最初のステップは学習させるモデルの種類を選択することです。線形回帰なのか、決定木なのか、それともニューラルネットワークなのか、適用する問題によって適切なモデルの種類を選択します。

モデルの種類を選択したら開発に取り掛かります。Python や R の開発環境をローカルまたはリモートに立ち上げ、モデルを構築していきます。

環境構築の負荷を下げたいのならば Amazon SageMaker Notebook Instances を利用すると良いでしょう。Amazon SageMaker Notebook Instance では Jupyter Notebook/JupyterLab を実行するためのインスタンスをフルマネージドで提供します。マネジメントコンソールや API を通して起動することができます。MXNet / TensorFlow / PyTorch / scikit-learn などのライブラリは予めインストールされているため、自身でインストールする必要はありません。また GPU を搭載したインスタンスも選択ができ、開発速度を上げることができます。先ほど説明したの「データの前処理」のワークロードでもこちらの Amazon SageMaker Notebook Instances を利用することができます。

img_awsgeek_sagemaker_02

普段使い慣れた別の IDE や開発環境がすでにある場合はもちろんそちらを利用することもできます。

ほとんどの場合、モデルはフルスクラッチで作成するのではなく、既存のモデルの改良という形で作成します。GitHub などのリポジトリにある OSS のコードなどを利用することになります。AWS でもモデルのサンプルを用意してます。こちらのサンプルには時系列予測や顧客離反分析などといったモデルのテンプレートが含まれているので、活用すると良いでしょう。

Amazon SageMaker には事前に AWS が用意したモデルのテンプレートをそのまま利用することもできます。Amazon SageMaker ではこれらのモデルを「組み込みアルゴリズム」と呼んでいます。例えば K-means や XGBoost なども組み込みアルゴリズムに含まれています。これらのアルゴリズムを使用する場合、機械学習のためのコーディングは一切せず、学習時に Amazon SageMaker SDK を通してオブジェクトを作成するだけで済みます。組み込みアルゴリズムが利用できる場合は、さらに開発コストを抑えることができます。

img_awsgeek_sagemaker_03

モデルの学習

大量のデータで学習する場合や、条件を変えながら並行して学習する場合、多くの計算リソースが必要になります。「データの前処理」でも述べたように、このように計算リソースが大量に必要な場合はクラウドのメリットが活きてきます。必要な時に、必要な分だけリソースを用意しましょう。

Amazon SageMaker SDK を利用すると、自動で起動・停止する計算リソースを構築することができます。SDK でユーザが指定するのは、学習データ、学習コード、そしてコンテナイメージなどです。これらを指定して学習を開始する Python の関数 fit() を呼び出すことで、自動で学習がインスタンス上で開始されます。ユーザはインフラを意識する必要はありません。学習はコンテナ上で実行されます。好きなコンテナイメージを使用することもできますが、AWS が用意したイメージを利用することもできます。

こちらの Amazon SageMaker SDK は pip を利用してローカルのマシンにもインストールできるので、AWS を利用した学習をローカルのマシンから呼び出すこともできます。

自動ハイパーパラメータチューニングをしたい場合も、SDK で利用して実行することができます。

学習し終えたモデルのデータは Amazon S3 バケットに格納されます。

img_awsgeek_sagemaker_04

モデルの評価 (推論)

モデルを本番環境にデプロイする前に、そのモデルを評価する必要があります。ここで言う評価は、モデルが想定した通りの振る舞いをしてくれるかどうか、ということです。定量的に評価できる場合もありますが、定性的な評価しかできない場合もあります。どちらの場合でも、入力データは必要となります。入力データは、オフラインで取得したものか、オンラインで取得したものかによって分類することができます。

オフラインで取得したデータとは、すでに収集済みで、学習に利用可能なデータのことです。学習データは学習用・評価用の 2 種類ないし学習用・評価用・テスト用の 3 種類のデータに分割するのが一般的です。この場合のモデル評価というのは、評価用のデータに対するモデルの評価になります。

オンラインで取得したデータとは、本番環境の入力されるデータそのものとなります。ミラーリング等で別途取得してもよいかもしれません。本番用エンドポイントから一部のトラフィックだけを評価対象のモデルに流すことで評価しても良いです。この場合、致命的なモデルの欠損はあってはならないので、オフラインでの評価が問題ないモデルを利用すべきでしょう。

先ほど述べたように Amazon SageMaker では学習済みモデルを Amazon S3 バケットに保存します。評価する際に保存してあるバケットからダウンロードして、推論させることも可能です。この方法以外に Amazon SageMaker では推論 HTTP エンドポイントを作成することができます。S3 バケットに保存してあるモデルから自動的にエンドポイントを作成してくれるため、より簡単に推論計算を呼び出すことができます。

img_awsgeek_sagemaker_05

モデルをデプロイ

モデルの評価が問題なければ、本番環境にデプロイします。

モデルの評価と同じように推論処理でもオフラインのものとオンラインのものがあります。オフラインはいわゆるバッチ処理で推論する場合です。バッチ処理ではスループットを上げることが重要となります。一方でオンラインは (ニア) リアルタイムのレスポンスが要求されるので、いかにレイテンシを下げるかが重要となります。オフラインの場合は Amazon SageMaker Batch Transform という機能、オンラインの場合には Amazon SageMaker ホスティングサービス という機能を利用することで、インフラをほとんど意識せずに処理ができます。ここでは後者のホスティングサービスに絞って説明をしていきます。

「デプロイ」と一言で表していますが、本番環境で利用する場合は多くのことを考慮する必要があります。Web サーバーとしての作り込みや、スケーリング、負荷分散、耐障害性など、機械学習とは直接関係の部分を考える必要があります。機械学習の研究・開発を主なタスクとするユーザでは、負荷の高いタスクとなります。

Amazon SageMaker ホスティングサービスでは Amazon SageMaker SDK や API を通して HTTP エンドポイントを作成することができます。ユーザはこのエンドポイントに対してデータを含めた POST リクエストを送信すると、推論が自動的に実行されます。エンドポイントはスケーリングや負荷分散は自動で行ってくれます。また複数のモデルを 1 つのエンドポイント上にデプロイし、トラフィックをその複数にモデルに対して分散させることで、A/B テストなどを実施できます。

img_awsgeek_sagemaker_06

モデルを監視

時間とともにトレンドやエンドユーザーの傾向は変化します。変化後もそのまま古いデータで学習させたモデルを利用し続けてしまうと適した推論結果を返すことができません。

本番環境にモデルをデプロイした後も継続的にモデルの品質 (予測精度など) を監視してやる必要があります。評価の基準は、学習時に使用した評価基準でも良いですが、学習時と大きく異るのが本番環境でのモデルの監視は「継続的」に行う必要があるということです。例えば教師あり学習の場合では、定期的に新しいデータに対してラベリングを行い、再び評価する必要があります。

監視の方法として有効であると知られているのが、モデルへの入力から計算される特徴量です。入力データさえあれば計算できるため、常に最新の値が取得できます。ラベリングなどを行うよりも運用負荷が低くできます。Amazon SageMaker では Amazon SageMaker Model Monitor と呼ばれる特徴量ベースでモデルの監視ができる機能があります。こちらも Amazon SageMaker SDK を通して設定することができます。特徴量は Amazon CloudWatch Logs の送信されます。Amazon CloudWatch 上でダッシュボードを作成したりアラートの設定をするなどの統合が可能です。

セキュリティ

Amazon SageMaker で構築・学習・推論ができますが、セキュリティに関してはどうなのでしょうか ? 機密性の高いデータを扱う場合などは特にセキュリティに気をつける必要があります。

Amazon SageMaker では、インターネットアクセスが発生しないようにすることも、暗号化も可能になっています。IAM Policy によってアクセス制御や、IP addresss を絞ることも可能です。

img_awsgeek_sagemaker_07

料金

Amazon SageMaker は東京リージョンでも利用可能です。課金対象は 3 つあります。1 つ目が計算リソースであるインスタンスに対して。2 つ目が構築・学習・推論で使用するストレージに対して。そして 3 つ目が Amazon SageMaker Notebook Instaces と Amazon SageMaker ホスティングサービスで処理されるデータの入出力に対してです。

インスタンスの料金は「単位時間あたり、いくら」で設定されており、秒単位で課金されます。値段はインスタンスタイプで変化します。例えばコンピュート最適化のインスタンスタイプである ml.c5.xlarge を Amazon SageMaker Notebook Instance として一時間使用した場合、0.3 USD の料金が発生します (2020 年 2 月 21 日の東京リージョンの値段)。

SSD ストレージの料金は「単位 GB あたり、単位月あたり、いくら」で設定されています。こちらも秒単位の課金です。ストレージの料金は 0.168 USD/GB/月 です (2020 年 2 月 21 日の東京リージョンの値段)。SSD ストレージのは最大 6TB まで増やすことができます。

データの入出力の料金は「単位 GB あたり、いくら」で設定されています。例えば入出力合計で 100 MB のデータを処理したとすると、0.008 USD の料金が発生します (2020 年 2 月 21 日の東京リージョンの値段)。

img_awsgeek_sagemaker_08

最後に全体の図を見てみましょう。

img_awsgeek_sagemaker_09

いかがでしたか?
Amazon SageMaker が提供する多くの機能のうち、基本的な機能を機械学習のワークロードと合わせてご紹介しました。

Amazon SageMaker を利用する際は、取り組む機械学習のワークロードを決めて、それをキーワードに SageMaker のドキュメントなどを検索すると目的の機能にたどり着きやすいです。

機械学習ワークロードを処理するプラットフォームを検討の方は、この機会に是非お試しください。

photo_tsuji_yohei

筆者紹介

辻 陽平

アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト。
2019 年に入社後 ML や HPC 分野のお客様を担当。好きなサービスは Amazon Rekognition。趣味は筋トレと自転車。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する