基調講演

オープニング

Amazon.com CTO Werner Vogles

メモ

• このカンファレンスはセールスではなく教育である
• 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 藤本 真樹

• いろんなことを試した
• 数千台のオンプレミスサーバを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

• 機械が発生したデータはクラウドにあがっていない
• 医療機器、産業機械、極端な環境
• 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

メルカリスピーカー

• 長野 雅広

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
• DNSRRに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

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

AWSSummit参加のまとめ