【エンジニア 情報 収集】Google Cloud Next19 @2019-7-31
2019年7月31日と2019年8月1日にプリンスホテル東京、ザ・パークプリンスタワー東京で開催されたGoogle Cloud Next19のイベントに参加してきましたので、そのメモです
阿部伸一氏
Google Cloud
19000人の来場者
増上寺にGoogleのエンジニアがオススメする書籍スペースあり
→こんな本でした（とりあえず技術関連のものだけをアップします）
■ウルスヘルツル氏
インフラエンジニア
クラウド売上
８０億ドル
大阪リージョン
日本２
アジア７
世界２０
目のリージョン
Googleからくる海底ケーブルは３つめ
Anthos
一度書いたコードをどこでもデプロイ
ハイブリッドクラウドワークロード
コンテナで作って、プラットフォームを選ばずにどこでも利用できるように
Googleのビジョン
アプリケーション開発ソリューション
オンプレミスの現代化
デジタルトランスフォーメーションプラットフォーム
機械学習によるイノベーションの加速
南場智子氏
DeNA
技術のアウトソース依存を反省
→技術の内製化
５０億
１秒数十万も捌ける
3000台のサーバ
３０人ほどの技術者
２０１５〜クラウド利用増大
2018
オンプレ派とクラウド化で派閥形成
意見が対立
→ 宗教的
南場氏自身も会議に参加し、内状を
クラウド派
ベンチャー企業であり続けたい
オンプレ派
コストメリットを謳う
経営層的に気になったのは。。。
→ 人材
創造的な仕事にフォーカス
管理等の創造的ではない仕事ではもったいない
タルク氏
Googleインダストリープラットフォームソリューション
メルペイ
曽川氏
メルカリの年間トランザクション２０００億
金融
アクセンチュア
関戸氏
三和銀行が日本の銀行システムを作った
最近の金融システムはオンラインシステム化を推進してきた
Cloud Spanner + GKE
マイクロサービスをどれだけスケールしていくか？
MAINRI
GCP上の金融基幹システムソリューション
zero bank design factory
永吉氏
フィンテック系の
福岡の金融会社
ブロックチェーンを利用したポイントサービス
今の技術を使って、新しいことを常に模索している
[銀行機能は必要だが、今の銀行はいらない」
ビルゲイツ 1984年
Cloud Spanner + GKE
→ マイクロサービスをスケール
次世代の金融世界を作る
東京ー福岡間でアジャイルな研究・開発
ガンホー
CTO 菊池氏
mspo
問題があったので、ガンホーで再開発
本プロダクトで初めてGCPを採用した
ユーザの認証周りの簡素化
Cloud Spanner
初めてRDBMS以外のDBを採用
BigQuery
広告データの集約
looker
スクエアエニックスの新作ゲームドラゴンクエストの新作を
Kubernetss Engine + Cloud Spanner
で構成
クマル
Anthos vice president
別のプラットフォームでサービスを利用
３時間でサービス開始できる
カスタマーエンジニアリング技術部長
佐藤氏
インフラの管理は煩雑
→ コンテナで管理するケースが増えてきている
Migrate for Anthos
ベータ版開始
アプリの書き換え等不要で、GCPのK8s上に簡単にデプロイ可能
ECサービス例
コンテナなら
・ パッチ管理
・ スケーリング
・ 顧客データ保護
を簡単に行える
ディスクの購入、パッチのためのサービス停止も不要
インフラ管理から解放され
ビジネスに集中できる
Google Cloud Service Mesh
セキュリティ管理
セキュリティを高めつつ、アジャイルであり続けることが可能
稼動場所にかかわらず、一元的な管理が可能になる
Anthosはマルチクラウドでも一貫性のある体験を提供
モダナイズを簡単かつ迅速に
マルチクラウド戦略の加速
NTT Communications
工藤氏
Anthosを初めて活用する企業
一部にGKEの活用
→ 20％の稼働の削減
GCPのサーバレスプラットフォーム
サーバ管理不要
フルマネージドなセキュリティ
コンテナの柔軟性
サーバレスの機敏性
Cloud run（コンテナでサーバレスを実現）
あらゆる言語
あらゆるライブラリ
あらゆるバイナリ
サーバレスなワークロードをあらゆる場所で
Cloud Code
ビルド、デバッグ、K8sへのデプロイを迅速に
囲い込みされることなく、クラウド構築ができる
GoogleCloud
エイミー氏
データマネジメント
Cloud SQL for SQL Server
Google Cloud
おおの氏
GCEのVMインスタンスのインスタンスタイプから選択可能
既存のライセンスの持ち込みも可能
Managed Serveice for Active Directory
エイミー氏
Cloud SQL → Big Query
Elastic
Microsoft Services
Google Japan代表
ピーターフィッツジェラルド氏
ZOZOテクノロジーズ
クラウド上のGPUを使って
５５倍の改善
JR東日本の一日の利用者 → 1800万人（世界最大）
JR東日本取締役副会長
おがた氏
STTTモデル
STTT = Shortning total trip time
→ MaaS （Mobility as a Service）の概念にとって重要
MTOMIモデル
Management
Technology
Operation
Maintainance
Infrastructure
PT Public Transformation 公共交通
Google CloudのAI技術をCBM（Condition Basaed Maintanance）に活用
Mercari US事例
JPよりもUSの方がまだまだ利用者が少ない
CRM
Customer RelationShip Management
どのタイミングで通知を送るか
パーソナライズされていないCRM
↓
イベントトリガーCRM
↓
人ベースのCRM
機械学習を利用したCRM
Churn Prediction
二度目の購入をしないと決めたユーザを機械学習で予測
→そのユーザに対して、クーポンを配布する仕組みの作成
ログ収集基盤の作成
アプリ起動
CTAタップ
PV
A/Bテスト的タップ
商品の購入、いいね
これらのログを収集
ログ収集基盤
Cloud Pub/Sub
Cloud Dataflow
JSON形式のログを見やすいように成形
トレーニングデータの選定
探索的データ解析
・アプリ起動回数の分散
・継続購入あり、なし
無効な特徴例
購入後からの配送日数
継続購入あり、なし別
トレーニングデータの作成
BigQuery
中間データの取得する
Cloud Composer
Apache AirFlowベースのフルマネージドワークフローオーケストレーション
DAG（）を構成でき、簡単にワークフローの作成ができる
→ 複雑なバッチ処理の代替手段に
PHP BigQueryClientLibralyを利用して、BigQueryからユーザ情報を抽出
機械学習モデル詳細
特徴量prepocessiong
BigQuery
モデルの詳細
Wide ＆Deepモデル
線形モデルとニューラルネットワークのハイブリッドモデル
ハイパーパラメータ調整
AI Platformで自動調整
→ モデルに適用すべき最適なハイパーパラメータを求める
学習したモデルはCloud Storageへ保存
Google dribetのGitHubに全て公開されている
成果
９９％ROAS（クーポン付与後２１日）
＋１５％継続購買率
課題
学習データの自動更新
購買予測率に連動したクーポン施策
BigQueryを利用した視聴データのリアルタイムダッシュボード構築
テレビ東京 テックリード 段野氏
リソースが限られているからこそ、インフラの管理はマネージドサービスに任せたい
詳しくは、スライドを参照
Googleが開発したAIプロセッサ「CloudTPU」とZOZOTOWNでの活用事例
Google
佐藤さん
デベロッパーアドボケイト＝エバンジェリスト的ポジション
TPU(Tensor Processing Unit)
AI専用プロセッサ
なぜTPUを作った？
→ ムーアの法則の限界が見えてきているから
CPUクロックは3~4Gのままずっと変わらない
スレッドを増やすだけ
→ ムーアの法則的な限界が見えてきている
↓
Domain Specific Architecture DSAという手法がムーアの法則を破るためのアプローチとして
考えられるようになってきた
Alphabet会長のジョンヘネシー氏（いわゆるヘネシーアンドパターソンのヘネシーさん,2017年にチューリング賞を受賞）が考案。
応用領域ごとにハードとソフトを最適設計するもの
例 ブロックチェーンのハードウェア利用変遷
GPU → FPGA → ASIC ベーシック？
ASICでないと、マイニングができない時代になった
グーグルはハードウェア企業
8年前に佐藤さんがグーグルへやってきて、Googleが自社で開発しているプロセッサが
世間の何歩も先を行っている質であることに驚いたらしい。
初代 TPU v1を開発（現在v3まで）
CPUにはノイマンボトルネックがある。（GPUでも）
TPUはメモリアクセスがない分、電力性能比が良い（85倍）
TPUは行列演算特化なので、スパースモデルや分岐の多いものには
性能がさほどでない。行列演算を多用する機械学習には適応したプロセッサである。
→ 機械学習の計算ならTPU
ZOZOTOWNでの事例紹介
西原氏、家富氏
GPU → Cloud TPUにしたところ、GPUの5倍くらい早く済むようになった
CloudTPUPodsとは
佐藤氏
TPUを並列させたスパコン
一般的に大規模並列させると、ネットワークがボトルネックになり、
速度がサチることが多いが、Podsの場合にはそれも起こらない
→ 同期をハードウェア的に行うので、速度が出る
AIと量子コンピュータで開く、新たなビジネスの可能性
最首英裕氏
機械学習をやればやるほど、組み合わせ最適化問題をとく必要性が出てくる
商用ベースで量子コンピュータ(アニーリング型)の製品を出しているのは、世界でgroove notesだけ
GrooveNotesはGoogleのAIを使っていない
Googleのサーバだけを使っている
世の中の問題
・世の中は単純ではない
・データがない
→ マルチモーダルという解決策を提唱
マルチモーダルとは？
画像と数値から結果を予測
どこもかしこも、胸部レントゲンの画像を10万枚も持っているわけじゃない
だからこそ、マルチモーダルという手法を提唱する
マルチモーダル
機械学習がやっていることとは？
→ データから「特徴ベクトル」を抽出すること
その特徴値をもとに、回帰問題なのか分類問題なのかを判別し分析する
抽出した特徴量をBigQueryに流す
→ k-meansでクラスタリング
顔識別
少ない顔画像から特徴を学習
個人を識別
Beyond AI
AI×量子コンピュータ
量子ゲート式には興味がない
組み合わせ最適化に興味がある
個人的感想
最首さんは本当に話すのがうまい。
組み合わせ最適化問題がなぜ量子コンピュータで解けるのか？
エネルギー準位間のトンネリング現象を利用するから
コードではなく、数式を書いている
世の中の課題をエネルギー式（ハミルトニアン）として表現
→ その結果を利用
エネルギー式（ハミルトニアン）
なら微妙なニュアンスが表現可能。条件の追加・除去が行いやすい
写真参照：
制約条件が決まれば、確実に答えが出る
でた結果はスプレッドシートで管理
→ WebAPIのQUBO（最適化構成モデル）へ渡す
シフト最適化、配送ルート最適化、等々を行なっている
式のみを利用しているので、量子ビットの数に依存しない
要素が増えても式は一つなので、計算負荷にもそれほど影響しないものらしい
各国でアニーリングの量子コンピュータを開発しているが、
GrooveNotesにとってはどこの開発したマシンが性能が良いのかを評価する
立場にいる。例えばgoogleが良いものを出せば、GrooveNotesとしてはそれを利用すれば
良いだけのこと。というスタンス
D-waveのマシンリソースを使っているが、
手引き等は利用していない。
→ プログラム等は自社で作っている
量子ゲート型モデルには興味がない、最適化問題に興味がある。
感想
あくまでもビジネス主導に物事をやろうとしている趣を感じる
量子力学、機械学習の知識を持ちながら、象牙の塔にはならずに
あくまで経営者としての目線と立場を忘れていない
マネックス証券の事例
GoogleCloud
法貴氏、関谷氏
Apigeeとは
安全な運用等を指向したシステム
Apigee Edge
API gateway
リバースプロキシ等、ノンコーディングで各種処理を行なってくれる
運用管理画面
API gateway設定
モニタリング
アナリティクス
開発者、アプリの管理
開発者ポータル
API利用者のサインアップ
APIドキュメント
任意のコンテンツ
カスタムテーマ
マネックス証券の事例
関谷氏
関谷氏のやっていること
システムの内製化を推進する中の
その管理等々
マネックス証券API
→ フィンテック関係者向け
パートナー型
RESTful WEB API
Security
残高照会API
ID/PWを第三者に預ける必要がなくなった
APIを公開した理由
・既存のスクレイピング問題
セキュリティ
パフォーマンス
予期せぬ連携の切断
・社外のサービスとの新規連携のスピードアップ
新たなフィンテックサービスとの連携基盤
・社内の新サービス構築のスピードアップ
新サービスの立ち上げのたびに、基幹システム側の改修をしたくない
なぜApigeeを選んだのか
・OAuth2.0準拠の認可（アクセストークンの発行と管理）
・認可と認証を分離できる
既存のシステムの認証機能をそのまま活かせる
エンドユーザは新たなSecretを覚える必要がない
認証技術の進化に対応できる
・フルマネージドなクラウドサービスである
オンプレの場合には、インフラの面倒を見る必要が出てくる
写真参照：
【まとめ】
・k8s + Cloud Spannerの構成をとっている事例をよく聞いた
比較的大規模なサービスの場合には、モノリシックよりもマイクロサービスアーキテクチャを採用
するケースが増えていることから、クラスタリングされたアプリケーション群＝k８s、DB=Cloud Spannerという構成が多く採用されているものだと思いました。
・サービスを指向するほど、クラウドを利用したくなる
DeNA南場氏のお話にもありましたが、ウェブサービスを運用していく上でオンプレ派とクラウド派の対立があったということでした。オンプレ派はコストメリットやノウハウの豊富さを主張したようですが、最終的には経営層が人、創造性を重視し、クラウド化されたいまに至るようです。テレビ東京の段野氏の話にも同様なことがありましたが、人的リソースが少ないからこそ、なるべくインフラの管理運用にはリソースや労力を割きたくはないということです。