AWS Summit 2015 - Day2 - 今日から始められる、機械学習！Amazon Machine Learningのご紹介
- AWS 今井さん
機械学習の例
スパムメール判定
- 二値判定、二項分類
- 教師データ
- 別の方法でSpam判定ずみのデータを元に学習
- それを元に判定
商品カテゴリの判定
- マルチクラス分類
- この商品はどのカテゴリのものか？
明日の売上の予測
- 回帰分析
- 過去のデータ群を教師データとする
- それを元にモデルの線を引き、明日の条件に最も合う条件で予測する
スマートのアプリケーションを作るには
これは大変
- なので、Amazon Machine Learning
Amazon Machine Learning
- Amazonがアルゴリズムを提供
- パッケージサービスとして提供
- ワークフローが予め提供されている
- MLは教師あり学習に対応している
スケーラビリティ
取り扱えるモデルとアルゴリズム
- 二項分類
- ロジスティック回帰
- 多クラス分類
- 多項式ロジスティック回帰
- 回帰分析
- 線形回帰
- 二項分類
予測手法
- バッチ予測
- S3にあるデータをまとめて予測を実施
- リアルタイム予測
- データを一件ずつAPIを使って投げて予測
- バッチ予測
AMLの使い方
- 教師用・評価用データを準備
- 教師データからモデルを作成
- モデルの品質評価
- 評価用のデータを流してテスト
- 7割の教師データを使って学習、3割を使って品質評価をする(自動で分けてくれる)
- Scoreの許容度をどこにするかをグラフィカルに設定できる！
- 制度に満足できない場合は、教師データを精査して繰り返す
- 実際の予測に使う
料金
- 分析、トレーニング、評価
- $0.42/インスタンス時
- バッチ予測
- $0.10/1000
リアルタイム予測
- $0.10/1000
- +モデル10MBあたり$0.001/h
リージョンはus-east-1のみ
- どのS3リージョ運のデータでも大丈夫
利用例
広告の不正クリック検出
- 教師データ: 実際のクリックログ
- 問題の分類: 二項分類
- 出力: ログごとに不正かどうかチェック
広告のリダイレクタの中でAPIを叩けば、その場で不正かどうかの判定が可能
デモグラ推定
- 教師データ: でもグラがわかっているユーザーの行動ログ
- 問題の分類: 多クラス分類
- 出力: ユーザーを行動ログからデモグラ判定
デモグラに基づいたレコメンデーション
- 教師データ:購入履歴にデモグラをマッピングされたもの
- 問題の分類: 多クラス分類
- 出力: ユーザーのデモグラを入力し、F1なので商品カテゴリこれがいい、みたいな出力
写真からの判定
- この後デモ
アーキテクチャへの組み込み
- S3からデータを出し、MLにかけてまたS3へ
- Redshiftをデータソースとして扱い、S3へ
- リアルタイム予測
- DynamoDB StreamsやLambdaを使って MLにかける
AML説明まとめ
- 機械学習の導入が用意になり、すぐにでもデータ分析が始められる
AMLデモ
榎並さん
顔写真から特定の人物判定
- 顔写真をグレースケールにしたビットマップ
- 各ピクセルの明度を数値化して、大きな配列にする
- 二項分類
- 顔写真をグレースケールにしたビットマップ
構成
- OpenCVで顔部分を検出
- 写真をグレースケールに
トレーニングデータについて
- 前処理の部分は自分で用意する必要はある
流れ
- トレーニングデータCSVをS3にアップロード
- AMLのコンソールからCSVを指定
- CSVの最後の部分が二項分類の値だよね(binaryだよね)というのを予測してくれる
- 自動で学習と品質評価をしてくれる
- アップロードデータの3割を自動で評価データにしてくれる
- 出た結果を元に、許容度を設定
ML real time の設定をすると、リアルタイム予測ができるようになる
APIで正しい写真を渡すと、正解フラグとスコアが帰ってくる
- 間違った写真でも同様
まとめ
AWS Summit 2015 - Day2 - keynote
- 昨日と同じ話は省略
AWS Mobile Service
Mobile SDK
Mobile SDK for Unity
- Machine Learningのサポート
- Lambdaのサポート
Cognite
- ユーザー認証
- データ同期
- セキュリティ
Cogniteのアップデート
Mobile Analytics
- 短期間でデータを取得
- MAU/DAU/セッション/リテンションレポート
- ユーザーのイベントをトラッキング
Mobile Analyticsアップデート
- S3 / RedShiftへのエクスポート
SNS Push Notifications
- CloudWatchの通知の配信ステータス
- SNSでのLabmdaの起動
成功は突然、予期しないタイミングで来る
- その時のスケーラビリティ
Labmda
- イベント駆動型バックエンド
- 実行時だけの100ms単位の課金
- モバイル単位の課金不要
Lambdaの新たなイベントソース
- SNSからの通知をトリガーにLambdaを起動
- CloudWatch
- Cogniteデータが変更されるごとにLabmdaを実行
- LambdaのJava対応！
LabmdaとCogniteが東京リージョン対応
IoT
- Dash.lyの事例
- ODB-2ポートのデータをKinesisに送って解析
Kawamotoさん
- スイスアーミーナイフとRDBは似てる
色々な機能を持っている
- だが、拡張が難しい
Dynamo
- Amazon.comの救世主となるDB
- 拡張性・スキーマレス
基板となるインフラ運用にはまだ課題があった
- ベンチマーク
- キャパシティプランニング
一元化したサービスの運用
キーワードはマネージドサービス
DynamoDBのリリース
- フルマネージドのNoSQL
- 高可用性・堅牢性
- 3つのゾーンでレプリケーション
Dynamoはモバイル・IoTにも効果的
DynamoDB Stream
- DBの更新情報を外部アプリケーションから利用可能
- Device -> Dynamo -> Stream -> lambda -> Redshift/SNS/Machine Learningなどの連携
Community HERO 横田さん
スシローとガリバーの事例
スシロー
ガリバー
- モバイル業務アプリ
- Cognite ベースで認証
- モバイルからLabmda -> Dynamo -> Labmda -> SNSで通知
ほとんどEC2を使っていない
- 最初にAWSを使おうと決意すると、まずオンプレからEC2に移そうとかんがえる
- 次のステップで出てくるのがこれらのクラウドネイティブなサービス
- マネージドサービスを組み合わせることで、運用・構築をもっと楽に
Gene
- モバイルのもう一つのアプローチ
- エンタープライズモビリティ
- WorkSpaces
- WorkDocs
- WorkMail
すべてがモバイルデバイス対応
- タブレットの例
Amazon WorkDocsの日本語UI・東京リージョン
Wrap up
- 10月にAWS re:Invent
AWS Summit 2015 - Day1 行ってきたまとめ
AWS Summit 2015 に行ってきた！
とりあえず自分の参加したセッションの内容を全部記事化した(一つに書くには長すぎた)ので、 まとめ用Index記事をつくったよ！(｀・ω・´)
- AWS Summit 2015 - Day1 - keynote - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - Amazon CloudSearch Deep Dive - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - Aurora Deep Dive - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - Redshift Deep Dive - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - デベロッパーが切り拓く、次の時代 - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - 自動デプロイ - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - EBSパフォーマンスベンチマーク2015 - 絶品ゆどうふのタレ
雑感
AWS Summit 2015 - Day1 - EBSパフォーマンスベンチマーク2015
- AWS 小林さん
EBSのおさらい
- ブロックレベルのストレージ
- スナップショットを使ってバックアップ
- 暗号化
99.999%の可用性
特徴
- 容量は1G単位で16TBまで
- マグネティックは1TBまで
- AZごとに独立
- スナップショットから任意のAZに復元可能
- 容量は1G単位で16TBまで
-
- 付け替えは可能
アーキテクチャ
ボリュームタイプ
汎用SSD
- デフォルト
- 費用対効果の高いディスク
- 一時的に3000IOPSになるバースト機能を備えている
1GBあたり3IOPSを常時確保(ベースパフォーマンス)
- 容量が1000GB以下の場合は3000IOPSに一時的に引き上げるバーストが可能
- たとえばOS起動時にはバーストさせて一気に起動させたり
- 最大は10,000 IOPSまで上昇
- 3334GBを超えたところで、常時10000IOPS
- 容量が1000GB以下の場合は3000IOPSに一時的に引き上げるバーストが可能
バーストの継続時間はIOクレジットの残高で決まる
- バーストが発生するとクレジットを消費
- 下回ったら時間とともにクレジットが溜まっていく
容量とスループット
- 容量依存でスループットが上がる
- 170GB以下では128MB/s
- 徐々に上がる
- 214GB以上では常時160MB/s
Provisioned IOPS
- SSDを超える性能
- 99.99%の時間について、指定IOPSの+-10%の範囲で性能発揮する
- 最大20000IOPSまで
- 最大320MB/s(1280IOPS以上)
- IOPS設定値依存
Magnetic
- 磁気ディスク
- かつてのデフォルト
- コスト安
- 1TBまで
- 平均100IOPS
- 最大数百IOPSまでバーストできる場合がある
- IOPSの命令回数ベースで課金
パフォーマンスの律速要素
EC2インスタンス側のスループット
- EBS-Optimized オプションを有効に
インスタンスタイプごとに上限値があるので、そこに到達していないか
- CloudWatchの Volume Read/Write Bytesの合計値で判断
上限に達している場合は、インスタンスタイプを大きくする
- EBS最適化をOnにすると、EBSへのアクセス回線をインターネットの帯域と別に確保する
- インスタンスタイプごとに帯域が異なる
EBS側のIO性能を改善する
- EBS側の実績値を確認する
- CloudWatchの Volume Read/Write Opsを参照
- OS から見てもいい
- 上限に達していたばあいは、ボリュームの上限を改善
EBS側のスループットを改善する
事前ウォーミング
- EBS各ブロックの初回アクセスに限り、IOPSが5~50%低下する
- 性能測定など
- プレウォーミングを実施すると、回避できる
実運用時には事前ウォーミング不可能な場合もある
実行方法
RAID構成
ベンチマーク検証
- それぞれのボリュームタイプについて、仕様通りの性能が出ていることを確認
RAIDによってそれを超えた性能が出せることをチェック
構成
- c3.8xlarge
- 2015.03
- xfs
- EBSはpre-warmingずみ
このへんはもうグラフ見ないと伝えづらい。。。
- こまかいブロック(8KB, 16KB)の場合はIOPSが高まって、そちらで頭を打つ
- スループットは余力があがったりする
- 大きなブロック(4MB)の場合は、IOPSの上限の前に、スループットが頭を打ってしまう
- 大きなブロックの場合、IOPS値を大きく取り過ぎてしまうと費用がもったいない場合があるので、注意
インスタンスストアとEBS
- もっと性能が欲しい場合は、インスタンスストアを使う
- 追加ストアなしで使えるディスク
- スループットはEBSとは独立している
- インスタンスを止めるとデータは消える
- 再起動では消えない
- アプリケーションが使う一時的なデータの置き場所や分散システムのデータ置き場
ベンチマークをしてみる
ボリュームの暗号化
- AES-256
- ハードウェア機能を使って暗号化するので、パフォーマンスに影響しない
- ほんと？というのを確認
fioで負荷をかけてiostat/vmstatでチェック
実際にグラフを見ると、IOPSはほぼ変わらない
- CPU使用率も殆ど差がない
典型的な構成例
小さいデータへのアクセスが多い場合
大きいデータへのアクセスが多い場合
- IOPSよりもスループットを重視
- シーケンシャルな場合も同様
- 無駄にIOPSを高めないようにするほうが、コストを抑えられる
低コストなストレージが必要な場合
- アクセス頻度が低い・パフォーマンスが不要な場合はマグネティック
極めて高いIOが必要な場合
- インスタンスストアを利用する
- OSやアプリケーションが必要とする大事なデータはEBSを利用する
まとめ
AWS Summit 2015 - Day1 - 自動デプロイ
- Elastic Beanstalk, Opsworks, CodeDeploy, CloudFormation
AWS 舟崎さん
どう使い分けたらいいか、どう組み合わせるか
Intro
- EC2 / ELB / RDS / S3 を組み合わせる事が非常に多い
設計としては多いが、デプロイを自動化する点まで考えられていることは少ない
- デプロイの自動化がなぜ必要か、はこのセッションの対象ではない。その前提で話す。
デプロイを考える際のフェーズ
- コーディング
- ビルド
- テスト
- デプロイ
- プロビジョン(リソース生成)
- モニタリング
Code Commit
Code Pipeline
- コードをデプロイする際の処理・ワークフローを自動化させる
- まだAWSとしてリリースされてない
Elastic Beanstalk / OpsWorks
- Deploy / Provision / Monitor
- Code Deploy
- Deploy のみ
- CloudFormation
- Provisionのみ
- Cloud Watch
- 監視
Elastic Beanstalk
- 定番構成の構築・アプリデプロイの自動化サービス
Opsworks
- 多様なアーキテクチャをサポートするデプロイ・管理サービス
- chefのレシピを使ってデプロイや運用タスクを自動化可能
- ライフサイクルイベントに従った動的な構成の変更
- 継続的な構成管理
Code Deploy
- アプリケーションのデプロイに特化
- agentをインストールして管理。オンプレミスも管理可能
- グループ内に一度にデプロイしたり１台ずつデプロイしたり、といった処理が可能
CloudFormation
Wordpressをデプロイする手法
wordpressのデプロイを題材に、４つのサービスを比較
- コンフィグも自動生成したり。
構成イメージ
どれがベストか、という話をするわけではない。
- 自分達の要件に合うかを検討する材料にしてください。
Beanstalk
起動の流れ
- ElasticBeanstalkがインスタンスを起動
- 中にHost Managerが入っていて、それが通信
GitHubと連携
- 順次バッチ処理でのデプロイ
- 一度に(1台/25%/全部)にデプロイ
- というのを調整できる
- Blue Green Deploy なんかもあり(今回は違う)
- 一度に(1台/25%/全部)にデプロイ
- 環境のカスタマイズ
- AMIを作りなおさなくても、Elastic Beanstalk Configuration fileで動作中のコンテナをカスタマイズできる
- 環境設定のRolling Update
- インスタンスの置換えを伴う操作を一部ずつ実行
- 裏ではCloudFormationのupdate policyという機能で実現してる
OpsWorks
起動の流れ
OpsWorksに指示を出すと、Agentがポーリングに合わせてAppを取得
- デプロイJSON を書いておけば、それをchefのレシピの中から呼び出せる
レシピの実行タイミングについて
Cookbookの更新
- リポジトリにPush
- カスタムCookbookの適用を指示
- ポーリングのタイミングで適用される
Code Deploy
サーバは起動しないので、自分でエージェントを入れる
- 入れたら、グループにインスタンスを追加
Depoyの流れ
- 環境のカスタマイズ
- appspec.ymlのなかに、hooksを設定できる
- shellscriptの実行が可能
- CloudFormation都の連携
CloudFormation
- CloudFormation template(JSON)の中にプロビジョニングとデプロイの内容を書いておく
- 頻繁にデプロイしないのであれば、CloudFormationでやってしまうのがいい
- 頻繁にやるなら、プロビジョニングだけを担当させる方がいい
まとめ
- それぞれ簡単にできるが、手順が異なる
- 要件に合わせて活用してください
AWS Summit 2015 - Day1 - デベロッパーが切り拓く、次の時代
プラットフォームの変遷
- 5年スパンぐらいで、なにか起きている感じ
- また今年辺り、なにか新しいムーブメントが来るのでは
テーマ１: 外部環境が変わる中で、変わったこと、変わらなかったこと
変化の最初の頃ってわからない
- EC2が最初話に上がった時、凄さがわからなかった
- iPhoneで、最初誰がネットするんだって感じだった
今クラウド全盛だが、５年後ぐらいには違うことが起こっている
その時はやっているものに安住しないようにする
一番変わったことはなんですか？
変わらない所
やってる時はシンプルなのは不安だし厳しい
- 色々やってると、もっとしっかりした仕様が必要では？と迷うことも
- ただ、実際にはUnixの哲学のようなものが勝つ
テーマ２: 技術を取捨選択した際の大原則・考え方は？
オープンな方を選択してきた
- それが正解かはわからない
テーマを否定するようだが、技術は手段でしか無い
- 技術選択の善し悪しによって、キャリアを築いてくという考え方自体が危うい
- OSSはコミュニティとしてやっていく、というトレンドだからそうしただけ
- それは単純に流儀に乗っただけ
問題を設定して、それを解決するための技術を選択する、というのがあり方
- 選択するのは結構怖くて、ブログに書いて一晩たったらなんかあれれ？ということもある
- メインストリームからみて「おもちゃ」と言われるようなモノを選んでやってったところはある
課題が先にあるか？それとも、おもちゃとして触ってみる感じが強いか？
- やはり課題ベースで触ることが強い
- 興味ベースで触ることもあるが、今やっている仕事の中で何かしら課題が前提としてあるからやってる
- なんの課題もなく触ることはない
自分で問題設定を生み出せる人なんて起業しちゃえばいい、という気持ち(おおばさん)
- 会社にいるのは、問題が常に降ってくるから
技術から出発する、というのは非常に危険だと思っている(伊藤さん)
- この技術ではここまでしかできない、という制限が発生してイノベーションは起きない
- たとえば、デザイナーが先にプロダクトをデザインして、無茶なものを試行錯誤しながら何とかすると素晴らしい物が出来る、ということもある
世の中の大発明みたいなものは、好奇心から生まれるということもある
- 電気とか。最初は皆どうしていいかわからない
- ただ、僕らがやってるのはビジネス。そこは違う
これからの外部環境の変化を、どう迎え撃てばいいか？
- 個人としてどうすればいいか？
チームとしてどうするか？
マネジメントの話(伊藤さん)
- スタートアップだと、曖昧さに対する耐性が高いか低いか、というのが重要になる
- 最初にもやっとしたものを渡されて、徐々に形を作っていく
- モヤモヤした中を皆で突き進んで作っていく
- いい感じのPMがこっちだ！といって引っ張っていってくれるわけではない
- そういう状態でも進めていける人と一緒だと、やりやすい
そもそも変化を受け入れられる、という事が前提(大場さん)
- 開発にかぎらずビジネスを考える
- 開発部門、というかたちで区切ってしまったら、全員がビジネスのゴールを見るのが難しくなってしまった。
- そのため、企画とエンジニアの枠組みを切り離し、各チームにばら撒くようにしてみた
ビジネスのゴールでも、やはり同じ話で、責任を区切るべきではない
- そうやってエンジニアだから、という責任境界を区切らずに、モヤモヤした中でやることを見つけていける力が必要
いちデベロッパーとしてはどうか？
- 年齢の問題もあるが。。。
- 新しいテクノロジーが出てきた時に、一つにフォーカスしていくのは危うい
- 新しいテクノロジーを牽引していくのは、やはり若い人のやること
まとめ
- 最後に一言
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 鼓舞したかったんだろうが、現実が見えてない
- 現実を把握して、その状況を見てやっていく
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 正解がわからないから、いろんな人の話を聞きたくて皆カンファレンスに来てるのだろうが。。。(伊藤さん)
- そんなのはこっちもわからない
- 正解はわからなくていいんだけど、先行ってるのがどれくらいのポジションで、自分がどんな位置にいるのか
- トップと自分とのギャップを把握するのは大事
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
AWS Summit 2015 - Day1 - Redshift Deep Dive
Redshiftの概要
LeaderNodeと並列のComputeNode
超並列演算
- CPU / disk /network /ioの並列化
データの格納
- 列思考(カラムナ)
各CPUコアにプロセスを張り付けていくような形で実行していく
- ノードスライス
データのロード
- COPYコマンドを実行すると、S3から直接ComputeがCSVファイルを引っ張ってくる
- ファイル数はスロットの倍が望ましい
Redshiftの主要アップデート
カスタムドライバ
- Redshift用ネイティブドライバが出た
- PostgreSQLのドライバよりも、パフォーマンス、信頼性が高い
Interleaved Sort Key
- Sort Keyを複数のカラムで指定可能になった
- それぞれのキーがフェアに扱われるようにデータが格納される
インテグレーション
データ連携をどうするか
オンプレミスとのデータ連携
- S3に一旦CSVをアップロード
- オンプレミスからRedshiftへの直接insertは推奨していない
- 不可が高い場合はDynamoなどを一旦挟んでからRedShiftへ
AWSサービス間のデータ連携
- S3がハブとなり、他のサービスと連携
- Data Pipeline
- Kinesis
- Lambda
サンプルシナリオ
- シナリオ
- RDBMSから抽出
- S3へアップ
- EMRに変換
- Redshiftにロード
バッチ
- Talendというツールを使ってみた
- 一旦S3にアップロード
- EMRに流してフィルタリング
結果をRedShiftへ
Talend
Extract
- CSVファイルとしてレコードを抽出
この時点で複数ファイルに分割
Change Data Capture - CDC
ポイント
- 大量レコードの場合は、メモリの枯渇を防ぐためにカーソルを利用
- 抽出後、圧縮すればアップロード時のコスト削減
- ファイル分割数は、スロットの倍に
Upload
- S3に並列アップロード
転送時間が短縮できる
ポイント
- Uploadの並列度は、クライアント側のCPUスペックを考慮
- S３のキー(先頭４文字)をランダム化するのが理想
Transform
どこで実行するか？
Amazon EMR
ポイント
Load
- Redshiftへのロード
ファイル一覧や正規表現に寄るCOPYコマンドを指定したり
ロードに失敗したレコードは
stl_load_errorsに格納MAX_LOAD_ERRORを指定し、一定回数のエラーは無視
ポイント
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
- ロード先のテーブルを本番テーブルと差し替えたり
- INSERT ~ SELECT はCOPYと同様にコンピュートノードで並列処理されるので効率が良い
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
