【レポート】AWS Summit Tokyo 2017: Machine Learning on AWS #AWSSummit
2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。
当エントリでは2017年06月1日に行われた『Machine Learning on AWS』に関する内容をレポートしたいと思います。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
志村 誠
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 ソリューションアーキテクト
AI や機械学習という言葉が話題になる遥か前から、Amazon では機械学習技術を活用したさまざまな取り組みを行ってきました。
本セッションでは AWS の上でご利用いただける機械学習サービスについてご紹介するととともに、それらをどのように使い分けるか、また機械学習をどのように皆さまのサービスに役立てて行くかについてご紹介します。
セッションレポート
以下、セッションのレポートです。
このセッションのポイント
- 機械学習サービスをAWSでどう構築するか
- 問題ごとにAWSをどう選択するか
アジェンダ
- 解くべき問題を明確にする
- AWSの機械学習サービス
- AWsを活用したサービスの構築
- 典型的なユースケース
解決したいビジネス課題から出発する
- 技術(Deep Learning, AI)からではない
- 機械学習はあくまで問題解決のためのツール
- ニーズはあるが、解決に至っていない問題に対して、機械学習を検討する
機械学習とはなにか
- 特定事象のデータを学習し、モデルを構築することで予測を行う
一般的な流れ
- トレーニング
- データ -> 学習アルゴリズム -> モデル
- 予測
- モデルを利用して、実際の問題に対して予測をおこなう
機械学習活用のポイント
- 大量の良質なデータによって精度が向上する
- 判断や予測を自動化することが可能
- 大規模に展開するほどコストが下がる
- 裏返すと
- 良質なデータが継続的に手に入るか?
- 自動化する勝つのあるクリティカルな予測か?
- 費用対効果に見合っているか?
機械学習に向いている典型的なビジネス課題
- レコメンド
- 人間に扱えないほどの大量のデータ/ユーザに対して個別のおすすめしたい
- 異常検知
- 24/365の監視を自動化
- 画像認識
- 大量の画像を識別
- クラスタリング
- ユーザをセグメントに分類
- セグメント別にマーケティングを実施したい
AWSの機械学習サービス
- AI Service
- AI platform
- AI Engines
- AI Hardware
AI Hardware
- p2 instance
- GPU特化
- Tesla K80 最大16個
- Deep learning向き
- Tesla K80 最大16個
- GPU特化
- Greengrass
- エッジコンピューティング
- デバイス内に学習モデルを同期
- エッジで推論処理を完結できる。
- デバイス内に学習モデルを同期
- エッジコンピューティング
AI Engines
- 機械学習パッケージ設定済みのAMIを提供
- MXNetを全面サポート
AI Platform
- Amazon machine learnig
- スケーラビリティ
- パッケージ化
- 学習、モデル評価、API提供
- Amazon EMR
- フルマネージドなHadoopクラスタ
AI Service
- polly
- Rekognition
- Lex
その他の機械学習関連サービス
- Kinesis Analytics
- 異常検知アルゴリズム
- Elasticsearch
- 検索機能を機械学習用途で利用可
- Data Pipeline
- EMRのバッチジョブをスケジューリング
- API Gateway
- 機械学習の結果をAPIで提供
サービス選択における指針
- Right Tools for the Job
- 機能的特性と性能的特性の両面からサービスを見極める
- <anaged Service First
- インフラの運用をAWSに任せて、アルゴリズムを
ゴールを明確化する
- 解決したい課題
- 最終的なアウトプット
機械学習の3つのステージ
- モデルの設定
- レコメンド
- 強調フィルタリング spark MLLib
- コンテンツベース
- Elasticsearch Service
- ルールベース
- EC2
- 異常検知
- K-means
- ChangeFinder
- 分類
- logistic Regression
- Machine Learning
- Deep Learning
- Rekognition
- EC2 + MXNet
- SCW
- logistic Regression
- トレーニング
- データサイズ
- 単一インスタンスで扱えるサイズか?
- EC2
- クラスタで扱うべきか
- EMR
- 単一インスタンスで扱えるサイズか?
- データの場所
- ストレージ
- S3
- DB
- RDS
- ストリーム
- Kinesis
- ストレージ
- 更新頻度
- バッチ定期
- Pipeline
- オンライン
- Spark Streaming
- 更新しない
- バッチ定期
- ハードウェア特性
- 通常はCPU優先
- C4
- Deep LearningなどGPGPUが必要
- P2
- スケールアップで無理くりインメモリで終わらす
- X1
- 通常はCPU優先
- データサイズ
- 予測
- モデルサイズ
- 単一のインスタンス
- EC2
- モバイルデバイスに組み込む
- Greengrass
- DBに格納する
- dynamoDB
- 単一のインスタンス
- 提供形態
- API
- デバイス
- モデルサイズ
- レコメンド
ユースケース
- ECサイトでの商品レコメンド
- 要件
- アイテムベース+ルールベース
- ストレージのログデータとDBのマスタデータ
- アイテムベースのレコメンドは日時で更新
- スマホなどからAPI経由で取得
- アイテムベース
- EMRでモデル構築
- ルールベース
- Kinesis Firehose + Elasticache
- 要件
- 画像SNSにおける同一人物の顔判定
- 要件
- 画像から顔を抽出,同一判定
- S3上の大量の画像データ
- モデルの更新は習字-にちじ
- スマホアプリからAPI
- 顔認識
- Rekognition
- 要件
- プラントのセンサデータによる異常検知
- 要件
- 数百のセンサがjsonde-taを送信5秒
- ストリーミング処理
- 異常検知
- アラートを上げる
- kinesis firehose -> analytics -> streams -> lambda -> sns analyticsで異常検知
- 要件
まとめ
- ポイント
- 解決したいビジネス課題から出発する
- ニーズはあるが実現できていない課題に注目する
- 機械学習はあくまでツール
- どのサービスを使うか
- システム要件を定める
- 要件に即したAWSサービスを選択する
- ユースケースを参考に
感想
AWSでの機械学習のサービスについて、網羅的にまとめられていて非常に勉強になりました。後半のサービスの選定基準のまとめがとてもよかったです。