Posted on

AWS Summit Tokyo 2017:Day3 参加レポ

前回に引き続きAWS Summit Tokyo 2017 Day3の参加レポ

基調講演

基調講演会場は相変わらず広くて豪華

オープニング

Day3のオープニングはDJだったけど前日の生ライブと比べたらまぁ普通に音楽流してるのとなんら変わらん感じで特に感動はなし

Amazon.com CTO Werner Vogles

オープニングのDJが終わるとAmazon CTOのWerner Voglesが出てきた。身体がでかくいかにも貫禄があっていい感じ。スピーチもさすがという感じで各所にAWSをスーパーパワーという表現で伝えていて聞いていてワクワクしてくるような内容だった。

メモ

  • このカンファレンスはセールスではなく教育である
  • Cisco、IBM、HPEはマイナス成長。古い保守派の企業は成長してない(オンプレミスはおわってる)
  • ストックホルム、中国、大阪ローカルリージョン追加
  • ワールドワイドなリージョンの運用が可能

この辺の話は前日とだいたい同じ

ゲストスピーカー/ソラコム 安川健太

メモ

  • デバイスを直接クラウドに接続する(インターネットを経由しない)
  • キャリアと連携して直接AWSにアクセスする網を作った
  • awsを活用してapiを使ってmicroservicesで構成している
  • DynamoDB使ってる
  • 疎結合化と非同期化
  • kinesis+lambda functionを使ってる
  • awsをフル活用することで小さなスタートアップでもすごい速度でサービス開発ができている

Werner Voglesに戻る

  • 2014年にクラウドが明確に当たり前になった
  • 今は進化の過程のどこにいるのか?
    • プロダクションの中心(IT自体が差別化にはならない)
    • 検索などはできなければならない、できなければ他よりも劣るだけ
  • AWSはスーパーパワーを与えた
    • 超音速(スーパーパワー)
    • AWSを使って利用社はプロダクトをユニークにすることだけに集中すればいい
    • AWSが開発の制約になってはいけない(利用者の目標を達成してもらう為にやっている)

ゲストスピーカー/NTT東日本 中村 浩

  • CloudGateway (re:connect)の紹介(もともと社内で使ってたものをサービス化した)
  • コスト・セキュリティ・アジリティを重要視
  • 企業の基幹システムでクラウド利用が進まない状況
  • NTTがAWSと直結するサービスとし安く、すぐに、セキュアに使いたい分だけ使えるように

Werner Voglesに戻る

目に見えないスーパーパワー(サーバレス)

  • 常に可用性が高い
  • AWS Lambdaを使えば簡単にアプリを実行できる
  • Finraの例
    • 常にマーケットイベントを処理しているがそれらはLambdaを活用して稼働できている
  • 複数の関数を使う場合は?
    • AWS Step Functionsを使うことが可能
    • いろんな枝分かれしたものでもAWS Step FunctionsでLambda実行利用可能

AWS X-Ray

  • 分散型の情報のトレーシングができる

Amazon DynamoDB

  • 他のNoSQLにはコンフィグがたくさんあって大変だが、そもそもやりたいことというのは一貫したパフォーマンスが必要だということだけ
  • レイテンシが非常に重要
  • マイクロ秒での速度が求められている
  • 応答時間をマイクロ秒に短縮
  • DynamoDB Accelerator(DAX)(マネージド)(インメモリでDynamoDBの10倍速)
  • コスト効果が高い

ゲストスピーカー/ソニーモバイルコミュニケーションズ

  • エレクトロニクス・エンタテイメント・金融
  • デザイン・デバイス・ネットワーク&クラウド・AI
    • System Integrateする

Werner Voglesに戻る

AWS IoT

  • デバイスゲートウェイ
  • デバイスシャドー
  • Rules Engine
  • ほとんどのマシンデータはクラウドに保存されてないない
  • IoTの3つの柱
    • もの、クラウド、知能
  • クラウドとすべてやりとりする必要はないがサマリはクラウドに必要
  • ローカルで開発がしたい

AWS Greengrass

  • クラウドに行かなくても実行できる
  • レイテンシがない

スーパーパワー(飛び立つ)

  • 古いDBベンダーから飛んで(逃げて)行きたいのでは?
  • 高価、独自仕様、ロックイン、罰則的なライセンスがあるが最後にはすべてを利用できていない
    • だからこそオープンDBへ移行する(AWSマイグレーションサービスを提供)
    • MySQL互換、ハイエンドで最大5倍、可用性あり、Postgres互換、コストは1/10

ゲストスピーカー/Gree 藤本 真樹

Greeさんのスピーチはそもそもこういう場になれているだろうということもあるが、冒頭に自虐ネタから入ってきておもしろかった。「2013年から業績が下降してきている、株価もね」「まだ居たの?」という感じかもしれないなど。ただ色々大変だったけど、過去2回の4半期はよい業績を出すことができてこういった場に呼んでもらえて嬉しいということを話されていた。

  • いろんなことを試した
  • 数千台のオンプレミスサーバをAWSへ移行
    • 1年くらい(いろいろ合わせるとトータル2年くらい)
  • どう実現したか?
    • Direct Connectはなくてはならなかった
  • プロダクトサイドの協力が大きかった
  • サービスは増やすよりも減らすほうが難しい
  • 技術選択
    • いろんな要素があるのがご存知の通りだが正解・不正解を決めきるのは難しい
    • 未来はどうなるかわからないが「速さは裏切らない」ということを最後の決断としている
    • AWSを使えば早いよ

Werner Voglesに戻る

透視(X-RAY VISION)

  • AWSでペタバイト規模のデータを分析可能
  • Amazon Athena、Amazon EMR
  • Athena
    • S3に格納:クエリ分だけ支払い、アドホッククエリ
  • EMR (より細かい)
    • Hadoop、Spark、HBase
  • Redshift
    • 前の2つとは毛色が違う
    • データウェアハウス(データを引っ張ってくることに特化)
    • AWSの中でも一番使われてるサービス
    • データレイクで検索できないかという要求があった

Redshift Spectrum

  • Redshiftにデータを移す必要がない
    • エクサバイト規模のデータセットに対する複雑なクエリ(1000ノード)とした場合、Hiveの場合5年かかるのがSpectrumだと155秒ですむ(非常にコストがさがる)

予見(スーパーパワー)機械学習

  • マシンラーニングはAmazonでは最初から使っている
    • トレーニング(S3、Redshift、AMI、カスタム深層学習モデル)
    • 機械学習にエキスパートは必要ない(みなさんがつくるのはアプリケーションだ)

Amazon Rekognition

  • 画像認識サービス
    • 属性を認識することができる
    • トレーニングデータも組合わせ可能
    • スコアリングすることができる
    • これは下着か?水着か?ということが判別できる

Amazon Polly

  • 本物そっくりの音声の生成ができる
  • ライセンスフリー
  • 感情を付加することが可能(スピーチマークやささやき)
  • 口の動きに合わせてテキストを朗読できる

Amazon Lex

  • 自動音声認識と自然言語理解

最後に:不朽(IMMORTALITY)

  • スタートアップがほぼすべての業界に新しい命を吹き込んでいる
  • 企業が生き残る為にの鍵はデジタルトランスフォーメーション
  • 現在は企業は15年程で存在しなくなる
  • 若いスタートアップ企業で生きる
  • 今ビルドするなら絶好のタイミングである(2008年では24機能しかなかた)
  • Go Build!!!

ランチ

キーノートが終わると無料ながらも弁当とお茶が配られるのが嬉しい

セッション

大規模広告クリック率予測システムの実践

smartnewsスピーカー

  • 蘭雨陽

個人的にはなかなか難しい内容でメモはとったもののあまり内容は覚えていない・・・

  • 機械学習ドリブンのオンラインシステムを構築する際のパターン
  • パフォーマンスを出すことのキーは問題とモデルに対する理解
  • パフォーマンスとコストとバランスのポイントを選ぶ
  • AI is new Electric
  • AIではなくリアルワールドの機械学習
  • なぜリアルワールド?
    • 特定のユーザと特定のContextにてたくさんの候補から一番いい広告を選ぶ
    • GBDT (Randamforestとは違う)

AWS Greengrass Deep Dive

スピーカー

  • アマゾンウェブサービスジャパン:榎並利晃
  • Amazon Web Services:Craig Williams

Greengrassがどういうものでどういったことができるかを説明してくれたけど、実際に利用してみないとイメージが湧かない印象

  • 機械が発生したデータはクラウドにあがっていない
    • 医療機器、産業機械、極端な環境
    • Edgeで処理していく必要がある
  • 物理的、経済的、地域的な問題がある
  • IoTにおける3つのレイヤ
    • Things、Cloud、Intelligence
  • AWS IoT
    • GreengrassはAWS IoTの拡張
    • Device Gateway、Authentication & Authorization (Registry)、Device State
    • Device Shadow(オフラインでもデータがたまりオンラインになったら通信する)
  • AWS IoTはEdgeまで拡張する
    • 同じ機能や同じFeatureを使ってEdgeでも利用できる(Lambdaを利用できる)
    • SecurityモデルはAWS IoTと同じ
    • Shadowと通信ができる
  • メリット
    • ローカルイベントを早くレスポンス
    • オンラインでの運用
    • シンプルなでデバイスプログラミング
    • IoTアプリケーションコストを削除
      • 5年に1回通信すればよい
  • Greengrass Components (GGC) (Greengrass Core)
    • Lambdaの実行、メッセージング、Device Shadow、セキュリティ及びクラウドとの直接連携を可能にするランタイム(ソフトウェア)
    • 小さな端末でも大丈夫(ラズベリーパイでも起動可能)
  • SDK
    • ローカルネットワークを介してGreengrass Coreと通信可能
    • 現在はC++のみ
  • デバイスはローカルで稼働
    • Greengrass GroupはCoreとその他のデバイス群のコミュニケーションに関する設定セット
  • Groups + Deploymentsの利点
    • Lambda関数をGG Coresにデプロイ
    • ルートテーブルの設定のデプロイ
    • すべてのデバイスを集中管理
  • Local Lambda
    • 現在はPython2.7で実行可能
  • Local Lambdaは何ができるか
    • コマンドとコントロール
    • オフライン実行
  • Shadows
    • デバイスとLambdaの造替を示すJsonドキュメント
    • 車、エンジンなど
    • クラウドとsyncすることもローカルに保持することも可能
  • Messaging
    • ローカルなMQTT Pub/Sub messaging
    • Brokerの特徴
  • Security
    • ローカル/クラウドどちらにおいても相互認証
    • 直接AWSサービスを呼び出せる
  • 要求仕様
    • Linux 4.4
    • glibc2.14
    • python 2.7
    • SQLite

Cloud connect the world as a Glue

メルカリスピーカー

  • 長野 雅広

興味のあるメルカリの内部アーキテクチャやグローバル化についての話を中心ししてくれた。驚いたのは現在もJP版のサーバはSAKURA Internetだということ。

SRE Teamの紹介

  • Site Relability Engineeringの略
  • 運用チームを率いるBen Treynorが提唱
  • Site Relability Engineerging (オライリー)
  • 運用を50%以下に下げる
  • エラーバジェット

Mercari SRE

  • 信頼性の高いサービスを実現するチーム
  • インフラチームからSREへ名称変更
  • インフラよりもサービス指向
  • 6人で稼働中
  • 新しい機能開発以外全部やる

Global Service

  • JP、US、UK(Tokyo、サンフランシスコ、ロンドン)

Globalの進め方

  • Slack、PRレビュー、ハングアウト、リモートペアプロ
  • 自立したチームとして課題解決する
  • チーム丸ごと出張する

SREチームのケース

  • 現在6人のうち1一人が長期US出張中

アーキテクチャ

  • JP
    • SAKURA Internet 石狩DC
    • 2013年/7月リリース(当時はVPS1台にWebとDB同梱)
    • 検索:Solr
    • Diagonal Scale指向
    • DBにはioMemory
  • US
    • AWS
    • 2014/09リリース(AWSにてサービス構築)
  • UK
    • Google Platform
    • DB:GCE
    • 構成はほぼ同じ

2015年kazeburoさん入社

  • SRE発足
  • サーバ中心のアーキテクチャ
  • 少人数での運用
  • Ansible Playbook再利用

まとめ

  • JS/JS/JKは採用してるものは違うけど構成は同じ
  • ここまではそこまでAWSをつかってない
  • Globalインフラストラクチャ
    • それぞれのインフラは独立している
    • Route53、CloudFront、GoogleBigQuery、S3(バックアップとして利用してる)
  • Route53
    • DNS-RRにRoute53のHealth Checkを使い解決
  • 内部DNS
    • すべてのサーバにunboundを導入
  • ログ
    • batch+awscli
    • fluentd+S3
  • バックアップ
    • xtrabackup+aws cli
  • S3 as a Hub
    • S3をhubとして疎結合を実現
  • 機械学習への取り組み
    • 価格のサジェストとか
  • 距離を超えて世界を繋ぐ
    • 距離とレイテンシ
    • 光は50msecで地球半周

Startup CTO Night with Amazon CTO

ゲスト

  • Amazon CTO Werner Vogles

このセッションは3社のCTOがAazon CTOの前でサービスのプレゼンを行い課題を解決してもらうといった趣旨のセッション。Werner Voglesの指摘で印象的だったのが、料金体系とサーバ費用のことがしっかりと考えられているかという質問が多かった(例えば無制限の使用を許可するのはそれなりの代償が伴う)。また、最最後にはAmazonの例を挙げ、Amazonではしばらくとてつもない量のデータをOracleDBで管理していた。ただ購買情報というのは普遍の情報である為、DBで管理しておく必要はない為、すべての履歴データをS3に移行して現在の履歴情報はS3から直接出力している。そうすることで大幅なコストカットができた。という話があり、純粋になるほどなと思った。

面白かったWernerの質問の一例

Werner)なぜRubyを選んだの?
回答)Rubyが好きだったから
Werner)まぁそれも一つの答えだね

AWSSummit参加のまとめ

AWSSummitに参加するまでもやっとしていたことが、今回のサミットによってある程度具体的な利用イメージが持てたことが大きかった。各セッションもよかったが、EXPOのAWSブースで普通に疑問を投げかけることができたこともよかった。「Amazon S3をData Lake(ストレージ)に」というようにS3をHubにすることでいろんなアプローチができるという考え方でこれから色々試して行こうと思う。

最後はEXPOでビールがもらえた。めっちゃ疲れたけど最高によい2日間だった。

Posted on

AWS Summit Tokyo 2017:Day2 参加レポ

AWS Summit Tokyo 2017 Day2の参加レポ。そもそも私はこれまでAWS Summit参加したことがなく、AWSについてもこれから本格的に使っていこうとしている段階なので自分にとっては大変為になるサミットだった。
※ 以下の内容については参加時メモが元になっているので一部誤っている箇所があるかもしれないですがご容赦ください。動画やスライドがあがってくれば確認できるのですがまだ見つけられなかったので確認ができませんでした。

基調講演

まず基調講演会場に入って真っ先に思ったのはめっちゃ広い!!ってこととめっちゃ豪華!!ってこと。この先もそうだけどこれが無料で参加できるなんてさすがAmazon様。という感じだった。

オープニング

基調講演は三味線・バイオリン・ギターのスペシャルライブから始まった。これはめちゃくちゃよくてもっと聞いていたかった。

アマゾン ウェブ サービス ジャパン 長崎忠雄

オープニングのスペジャルライブが終わりホストスピーカーとしてAWS Japan代表取締役社長が出てきた。スピーチは社長らしく今回は去年と違って規模が約2倍であることやAWSのこれまでの成長・現状そしてこれからの未来について話された。あとサービスコンソールが6月末まえに100%日本語化すると明言していたのにはちょっと驚いた。厳密には以降ホストとゲストが入れ替わってスピーチしていたがスピーチメモは以下まとめて記載する

メモ

  • 今回のサミットはRegistration 20,000人以上(世界で一番多い?)
  • 去年の2倍の規模
  • スタートアップ企業の支援を強化してる
  • 事例大全集ダウンロードできる
  • ユーザコミュニティあるしエンタープライズ版もある
  • サービスコンソールを6月末までに100%日本語化予定
  • 現在90以上のサービスがある
  • 2016年には1017の新サービスおよび機能改善数(数年前は100程度だった)
  • Amazon AIすごいよってことでルービックキューブ動画を再生
    • パターンが多いので普通なら35年ほどかかるのがこれを使うと0.9秒になるよ
  • 他にもマシンラーニングを導入した企業のコスト削減の紹介
    • コスト1億円削減したり10日かかってたのが10分に削減したり
  • 5/31からAmazon LightsailがTokyoリージョンで使えるようになる(データ転送量込みで月額5ドルから)
  • いろんな企業にとってデータの移行の課題が大きい
    • AWS Database Migration ServiceでDBを簡単に移行ができるので現在25,000以上が移行済みである
  • ペタバイト級のデータ移行もあるけどそんな場合はAWS Snowballが利用できる
  • AWSサポート充実してる(ベーシック・開発者向け・エンタープライズ向けなど)
  • コストダウンについて
    • これまで2006年のサービスインから明確な競合がいないにもかかわらず61回の値下げをしてる
    • これはユーザファーストであることの表れである
  • オンプレからAWSとのハイブリットのつなぎを重要視
  • フルマネージドサービスで運用負荷軽減
  • 災害に対するリスクは高い(日本では2018にOsaka Regionが利用可能になる予定)
  • セキュリティとコンプライアンスをファーストプライオリティとしている

ゲストスピーカー/三菱UFJファイナンシャルグループ 村林 聡

まず初めのゲストスピーカーは三菱UFJファイナンシャルグループ執行役専務グループCIO。まず最初に自分たちはレガシーな企業だと2回程念を押すように言ったのち、これからはデジタルトランスフォーメーション、オープンイノベーションへ向かっていくという話をされた。具体的にはAPI、BlockChain、AIなどを駆使し7年後には銀行のコアの業務を4割ほどをAIに置き換えられるのではないかと。また、現在はオンプレから順次AWSへサーバ移行中で、現在は5つ程稼働しているが、100程が移行検討中である。ただ最後に今期で退任して次のところへ行きますといって締めていったのでなんとも言えない空気になった。

メモ

  • デジタルトランスフォーメーション、オープンイノベーションへ
  • オンプレから移行予定
  • AWSでは現在稼働中5つ(100くらい検討中)
  • 今期で退任する

ゲストスピーカー/セイコーエプソン 熊倉一徳

続いてのゲストスピーカーはセイコーエプソン株式会社のIT推進本部 本部長が登壇。セイコーエプソンは創業当時からものづくりの企業でありリアルな世界にこれからも提供していくのは変わらないといった一方で現在はサイバー空間も重要視し力を入れている。

メモ

  • ものづくりの企業
  • リアルな世界に提供するのは変わらない
  • サイバー空間も重要視
  • クラウドへの移行はかなり困難だった
  • サーバレスアーキテクチャを採用

ゲストスピーカー/レコチョク 稲荷 幹夫

続いてのゲストスピーカーはレコチョク執行役員CTOが登壇。レコチョクも最初はガラケーからの発信だったので大変だったが、現在はAWSへ全面移行することができた。当時の一番懸念点はやはりDBだったが、移行後は運用工数0、ライセンス費用0(オラクルだった)、パフォーマンス障害0になりかなり健康な状態が保てている。

メモ

  • 現在はVRの取り組みに力を入れている

ゲストスピーカー/Sansan 塩見 賢治

最後のゲストスピーカーはSansan株式会社Co-founder Eight事業部 事業部長が登壇。AWSサービスは30以上使っていてそのメリットはセキュリティ、止まらない、拡張性高いと言及した

セッション

IoT/Bigdata/AI時代におけるスケーラブルなDeepLearning実行基盤と応用

ABEJA スピーカー

  • カズンズ・ジェーン

前半は、Pythonistaの海外出身のエンジニアの方が話、後半は日本人のAWSに精通しているインフラエンジニアが登壇した。前半では簡単に言うとPythonずっと使ってるけどいいよっていう話がされてたと思う。後半ではアーキテクチャについて割と細かく説明されていた。詳しくは以下のメモとして記載。

Pythonistaのエンジニア

  • AIを投入する
  • LocalでAIを導入
  • Lambda利用でchaliceやzappaあるよ
  • Falcon APIに特化して使うのいいよ
  • Python Fireいいよ (Google製)

DeepLearningのスケール

Deep Learningの開発プロセス

  • データを集める
    • Collection
    • Annotation(pandas、numpy)
  • Model Depelopment
    • Exploration
    • Training(jupyterなど)
  • Model Management
    • Inferring
  • Monitoring
    • Falcon、Requests

AWSアーキテクチャについて

データ収集

  • Kinesis Streams
    • スケーラブルなQueueサービス
    • 1000req/sec/shard

データの保管

  • 言わずもがなS3
  • データレイク

学習環境で意識していること

  • 並列実行やGPU環境
  • スケーラビリティの高い環境
  • 安価に必要な時に必要な分だけ
  • 開発スピードを落とさないように
  • ECS
    • マネージドなDocker管理サービス
    • EC2の上に薄く載る感じ
    • ローカルで開発可能
    • 少しパラメータを変えて数十台分同時実行することも可能
    • GPUも利用可能

なぜGPU?

  • Core数が多くて並列計算が得意
  • 行列計算が得意

アーキテクチャ

  • API Gateway → Kinesis → Lambda → S3
  • ECS → LB → Annotation → S3

※ Kinesisに依存しないためにAPI Gatewayを利用してる
※ kinesis firehose使ってみたい
※ API Gatewayはできればやめたい
※ データにAWS Glueも興味ある

モデル作成

  • S3からトレーニングデータを取得してECSでJupiterなどを使ってS3に返す
    • Scalable
    • AWS Batch
    • Spot Fleet

Model Management

  • CodeBuild

アーキテクチャ

  • S3を間に置いて疎結合にしてる

まとめ

  • 疎結合を意識してる
  • AIの過渡期だから小さく開発を意識している

ChatWorkの新メッセージングシステムを支える技術

ChatWorkスピーカー

  • かとじゅんさん
  • 大村 伸吾

こちらも前半はプログラムサイドの話がメインで後半にインフラサイドの話という構成だった。ただ前半のプログラムサイドの話については最初以外は話が難しくてほぼ分からなかった。あとあえて言うとおそらくだけど発表者ノートをひたすら読み上げる形の発表だったので聞いているのが若干辛かった。これは自分が発表する際には気をつけないとなと思うポイントだった。

アーキテクチャ詳解

  • CharWorkは当初社内FW+既存システムの相乗りでサービス公開した
  • なんとか改善しながらやってきたが限界がきてシステム刷新を決断
  • 最初はライブマイグレーションプランで移行を実行したがいろんな問題が起きてプロジェクトを再起動することになった
  • 新しいアーキテクチャに移行することにして2016年に大規模なデータ移行を完了した

新しいアーキテクチャの方針

  • メッセージ数の遷移が毎年増大している背景がある
  • 保守性を維持するためにDDDは継続
  • リアクティブシステム(Akka)をベースにしたCQRS+ESを採用
  • cassandra + aurora

モチベーション

  • 当初はEC2、Jenkins、Capipstrano、Fabricだった
  • 困ってたこと
    • デプロイフローの改修が大変
    • 負荷試験をカジュアルにやりたい
  • 新しいアーキテクチャで達成できたこと
    • 負荷試験が通ったアプリコードを開発チームだけで維持できた

どうやった?

  • 実行環境をKubernetesにCIをConcourse CIに
  • 負荷テストツールの自動化(ECS等)

それぞれ

  • Kubernetesにした理由
    • デファクト
    • 開発が活発
    • kube-awsのメンテナの@mumoshuさんが社内にいる
    • ローカル開発環境minicubeがある
    • インフラチームと開発チームの責務が分離できる
  • 責務の分離
    • 必要なAWSリソースはteraformを利用

concourse CI

  • 特徴
    • パイプライン
    • YAML
    • Dependable Results
    • プラグインが不要
  • CIサーバの運用が楽になった
  • ローカルで開発したパイプラインがそのまま本番にデプロイできる
  • vagrant upで簡単にローカル起動可能
  • Gitlab flow with Environment Branchesを採用

負荷テストの自動化

  • これまではFullBokを利用していた
  • Amazon ECS + Gatlingを使った負荷テスト自動化ツールの導入
  • DSLでシナリオがコードで作れる
  • Gatlingの苦手
    • クラスタ実行
    • 複数レポートのaggregation

【ライブコーディングも実施】Amazon Payの仕組みと実装方法

アマゾンジャパン スピーカー

  • Johnathan David Froeming
  • 吉村周造

このセッションは二人とも熱のあるスピーチでとてもよかった。Amazonがいかにユーザのことを突き詰めて考えているかというのがとても伝わってきた。ECの最大の目的は商品の購入であることやユーザにとって一番よいESサイトは画面遷移と入力が最小限であることだということをひたすら伝えていた。Amazon Payの存在をすっかり忘れていたけど使いたくなった。

Amazon Pay特徴

  • 利便性
  • スピード(2クリック)
  • 安心感(マケプレ保証)
  • 実績1000社オーバー

日本赤十字社の例

  • 熊本地震がきっかけ
    • 寄付はしてみたいけど・・・
    • より多くの人にネット経由で寄付をしてもらいたい
  • 課題
    • 信頼できるページが必要(amazon.co.jp)
    • 管理を楽にしたい(aws)
  • すぐに開始したい
    • JSとSDK開発のみですぐに開始できる
  • Amazon Payの仕組み
    • フロント:Javascriptだけで可能
    • バックエンド:SDKで実装
  • LB+EC2?もしくはAPI Gateway+Lambda?
    • Lambdaを選択した
    • 困ってる人を早く助けたい(AWSならそれができる)
    • グローバルでも利用が可能
  • 購入画面のBest Practice(ECサイトのゴールは何?)
    • 商品購入(たくさん商品を購入してほしい)
  • 代表的な課題にカゴ落ちがある
    • カゴ落ちの一番の理由は?それは面倒だから(入力が多すぎる)
  • amazon payは商品購入の機会を最大化できる
  • AmazonのGolden Rule14項目を日本初公開した
    • 1ページで購入
    • 項目は最小限
    • ゲスト購入OK
  • ライブコーディング実施(ウィジェットを読み込むコーディング)

GunosyにおけるAWS上での自然言語処理・機会学習の活用事例

Gunosyスピーカー

  • 大曽根 圭輔

Gunosyの仕組みを丁寧に説明していて大変参考になった。またこれからやろうとしているプロダクトにも当てはめられるところがあったので紹介されていたブログもチェックしたい。また勉強会もやっているようなのでそれにも参加したい。

紹介

  • ユーザの行動分析を担当
  • ブログ開設してる(http://data.gunosy.io/)
  • JSAI 2017, COLING 2016に参加
  • 8割当たる予測器をつくるのは難しくない時代になったけどユーザ満足につなげるにはまだ壁がある

Gunosyと機会学習

  • 600超の媒体と契約し記事を収集・分類・リスト作成してユーザに届けている

記事分類

  • 文言からカテゴリ分類
  • 同一イベント判定(内容が似ている記事をまとめる)して代表記事を選択
  • ユーザの行動ログをリアルタイムで収集
  • ユーザの属性推定
  • スコアリング(ユーザ属性ごとのCTR予測しリストを並べ替え)
  • 大中小でカテゴライズしている
  • 形態素解析
  • カテゴリ分類器
  • カテゴリ分類APIにエンキューして分類してRDBに格納
  • モデルはS3に保存

属性推定+スコアリング

  • ユーザ行動ログ→ユーザ属性推定→スコアリング
  • 属性毎に性別・年齢・地域でクリックの傾向が分かりやすく別れる
  • どうやって属性を知るか
    • ユーザが読んだ記事情報をもとに属性を推定している
  • 年齢推定にはCNN for NLPを応用して畳み込みニューラルネットワークを使ってる

AWSではなにを?

  • ユーザログをS3に格納
  • GPUインスタンスを使って学習させてる
  • 集計後のデータをRDBに入れる
  • prestoを使ってslackやReDashなどで可視化して随時通知したり表示したり
  • logはkinesis streamを利用、kinesis analyticsで集計してkinesis firehoseを使ってElasticSearch Serviceで検索してリアルタイム通知

評価(ABテスト)

  • よくない例は機能リリース後に大きなイベントが発生して山が大きくなると計測不能になること
  • イベントに左右されにくいようにハッシュ関数を利用した割り当てをしABテスト対象の選定をしてる
  • スコアリング(Python)→Dynamo DB→記事リストAPI(Go)→ユーザ
  • どのABにあたってるかはS3にいれる
  • 細かいことを確認するにはJupiter Notebookを使ったりしてる
  • 自動集計
    • Group Validation
    • ABテストが適切に割り当てられてるか
    • 自動化進行中
  • 今回伝えたかったこと
    • 実際のサービスで動かして検証することが重要
  • gunosy-dm.connpass.comで勉強会もやってる

Pavilion

Pavilionは、IoTゾーン、AIゾーン、VRゾーン、Amazon Innovationゾーンがあり企業のVRなどの体験ができた。

EXPO

EXPOでは様々な企業が活気よくブースを展示していてみているだけで楽しかったし持っているQUコードを利用するだけで名刺交換がほぼ不要なシステムになっていたことでとても回りやすかった。また、AWSブースも設けられていて不明点などの聞きたいことが聞けたことが何よりよかった。

ギャラリー


次回はDay3についてのレポートを書きます。