AWSSummit2016 参加メモ
今年もAWSSummitに行きました。
IoTがテーマでしたが、IoT以外のセッションもありました。
厚切りジェイソンには会えなかったのが残念です。
６月３日のランチセッションから参加しました。
ランチセッションとは別にランチチケットがもらえ
お昼ご飯を２回も食べ満腹と戦うことに必死でした。
聴講したセッション
- IoT プロジェクトはなぜ失敗するのか
- PARCO が進める IoT とデータ活用事例
- ドワンゴが AWS を使ってメディアストレージ基盤を開発してみた
- 秒間数万のログをいい感じにするアーキテクチャ
- GREE 流！AWS をお得に使う方法
- タウンワークにおけるサーバレスアーキテクチャデザイン
1. IoT プロジェクトはなぜ失敗するのか
竹之下 航洋（株式会社ウフル IoTイノベーションセンター マネージャー）
クラウドインテグレータ、マーケティングの両方を生業としている会社
2013年からIoTをもう一個の柱にしようとして力を入れてきた。
これからは、IoTがビジネスを牽引する
５００億個ものののがインターネットにつながる
ウフルさんは、IoTを 人、プロセス、データ、モノがつながること ととらえている
事例紹介
- GEの航空事業事例
航空機メーカー ジェットエンジン
エンジンが出力することに課金 サブスクリプション
Iotにより事業ドメインを変えた 当社は、路面管理の高度化実証実験を実施
これからIoTを事業として考えるには、次のXXを意識した方が良い
２０２０年インフラ投資のマイルストーン
２０１８年までに商用サービスインしておきたい
２０１６年までにプロジェクトを開始しておかないと間に合わない
IoTへの取り組み方
- IoTは相対的な取り組みである
- ビジネスサイドのコミットメントがないとPOCをやってみただけになりかねない
- ありもののサービスだけでは運用が難しい
やってみてわかったこと
- WEBソケット ３Gは相性が悪い
- 実運用の話とでもの要件を混同してつくってしまった。失敗
- プロジェクト体制も重要
POC→準委任契約
実際の開発→請負 - ビジネスサイドの課題
開発前後のプロセスも見ている
感想
新しいことをやろうとして、まずはPOCでやりましょうとなるんだけど
そのあとどうすんの？みたいなことが戦略としてないと。
結局POCやったけどなんだったの？みたいな事になるのは実体験として
納得感がある話でした。
まずはやってみるのがPOCといえばPOCなんだけど、
POC後に進めるのか撤退するのかの戦略を作った上で、
POCをすべきなんかな〜
でも、いろいろ考えると結局はじまれない。見たいのもダメだしねー。
あとで調べる用語
node-red
http://deferloader.blog.uhuru.co.jp/?p=5329
enebular（エネブラー）
http://uhuru.co.jp/information/20141121-2/
PARCO が進める IoT とデータ活用事例
林 直孝 様（株式会社パルコ 執行役 WEB／マーケティング部、メディアコミュニケーション部担当）
社内サークルに参加している、IoT同好会部長
もともとマーケティングの人
全国に１９店舗
ZERO GATE
一定期間の個客LTVの和
一定期間の接客LTVの和
接客は来店前からすでに始まっている
店舗接客、WEB接客の考え方を取り入れようとしている
ポケットパルコをリリースした。
なんのためにリリースしたか
* データを活用するためのツールとしている
* お客様の行動を可視化できないか？
* WEB上では離脱などが可視化できるが、リアルでできないか？
- ブログのクリップ
クリップするとコインが溜まる - 来店するとチェックインしてもらう
チェックインコインを渡す - アプリに登録されたカードで買い物してコンバージョンとする
→チェックインした人がなんで買い物しなかったのかがわからない
クラスメソッドさんと実証実験した時のスライド
https://speakerdeck.com/quiver/parukomiyuziamunihua-xiang-sensinguiotwodao-ru-siteke-ceng-fen-xi-sitemita
２週間くらいで導入した
ソラコム、AWS
人数カウントの精度が課題
スタッフに、外で雨が降っている事を今まではアナウンスで知らせていた
「お足元の悪い中〜〜」
感想
お客のデータをどうやって取得するのかっていうのが肝だと思いますが
PARCOさんはうまくいっているのかな〜という気がします。
もう少し突っ込んだ話も是非聞きたい。
部長が自ら同好会を立ち上げて、ITに力を入れる動きをするっていうのも
良さげです。
ドワンゴが AWS を使ってメディアストレージ基盤を開発してみた
- 車輪の再発明は防ぐ
利用している技術
- grape(http://qiita.com/hkusu/items/2ca0323cc276ab31e926)
- dinamo(ruby製DynamoDB)
- rabl(view)
- shoruken(SQS)
- aws-sdk-ruby(All)
苦労した点
- サーバレスなアーキテクチャを実現するためにはAWS固有のリソース・サービスへの理解が必要
- VPC・ネットワーク周りなどの知識は、別に必要
- フルマネージドのサービスを前提としたアプリケーションのテスト実装は今後も課題
- サードパーティのモックだと厳しい
- cloudformatinについては、整備が足りていない部分もある
- aws-sdkを活用したが、ドキュメントから読み取れない。検証が大事
秒間数万のログをいい感じにするアーキテクチャ
星 北斗（クックパッド株式会社 インフラストラクチャー部 セキュリティグループ グループ長）
＊ESC
＊なぜログを集めるのか
起きたことを示せる
＊サービス改善をするためには不可欠
仮説の検証
パフォーマンス改善
システムトラブルの解消
＊WEBDBプレスに記事書いたので、読んでほしい
＊ログに求める要件
分析できないログはいらない。多すぎるログ
＊現在の規模
＊ログ収集の変遷
＊Fluentdについて
トレジャーデータのOSS
＊Apache Kafka
＊KPLによる集約の導入
＊kinesis-baibain
GREE 流！AWS をお得に使う方法
堀口 真司（グリー株式会社 開発本部/インフラストラクチャ部 リードエンジニア）
今井 祐介 （グリー株式会社 West Game事業本部 / RPG Studio部 シニアエンジニア）
神谷 侑司（グリー株式会社 West Game事業本部 / RPG Studio部 エンジニア）
籠島 啓介（Glossom株式会社 開発部）
dynamoDBのメリット
atomic counter
conditional save
コストの可視化
writeはreadの１０倍かかる
surottorinngu の問題
パーティションの機能
capacityも分割される
一度割れたらもどらないAmazonAuroraをつかったコスト削減
５倍近いパフォーマンスが出る
イベント開始終了の負荷が非常に高い
＊大量のログをなるべく早く
ltsv形式にしたら半分になった
コストエクスプロラーで毎日チェック
＊Lamdaを使えると安く済む
タウンワークにおけるサーバレスアーキテクチャデザイン
会社紹介
６７アプリリリース
パンダ一郎コアテクノロジープロジェクトを立ち上げ
データサイエンス＋エンジニアリング＋インフラ
どういった特徴のユーザがコンバージョンにいたるのか- タウンワーク
回遊する度にユーザの嗜好をひろう
アルタイムパーソナライズドソートの取り組み - ６人データサイエンティスト
- ログ基盤の整備
- 特徴量更新、予測の高速な処理
データベースの選定
高速な読み書き
特徴量の変更に対して柔軟である
AWSのサービスとの親和性が高い
管理コストが押さえられる - どうやって決めて行ったか？
NOSQLに絞った
自前で運用したくない
dainamo DB,elasticcasheにした - インフラ管理コスト
クラウドフォーメンションと ラムだを使った
ブルーグリーンデプロイメント
→DBを含めたブルーググリーンデプロイメント
→クラウドフォーメーションを使った - ラムダで管理コストを削減した話
ストリームデータ処理
バッチジョブ
インテグレーション
エラー事象をslackに通知する。他のコミュニケーションに紛れない？
専用の通知チャンネルに送る
使用料金をラムダでslackに送る。毎日slackに送る→これは試せそう
6/3の戦利品はコレ
ランチチケットでもらったランチ
ランチセッションのランチ写真
撮り忘れました。
来年も参加しまーす。
