イベント詳細
日付： 2016年2月25日
時間： 4:00 PM 〜 8:00 PM
場所: グーグル株式会社
基調講演
Googleクラウドサービスをざっと説明する話
- 例えば、Big TableはGmailの技術なのでお金かければ同じ性能出せる(ちょっと言い過ぎてるけどだいたい同じ)
- 仮想鯖は自動でスケールout / inするので開発者はインフラ回りを気にせずに開発OK（お金かかるけどね）
- 安いハードウェアを横に並べてスケールout / inやってる（性能のわりに安い理由）
- 海底ケーブルも自社で買ってるよ
- 他の地域で展開する際もGoogleのローカルネットワークで繋がってるのでVPNとかする必要なし（リージョンを考えなくていい）
- GCP(google cloud platform)は自社ツール、自社システムを外部に公開してるもの(自社サービスとはサービス名がちょっとずつ違うけど)
- あと、機械学習も力いれてるよ
事例紹介
株式会社grasys代表取締役 長谷川様
GCP専門のシステム設計、構築、運用保守やってますgoogle work partner認定コンソールゲーム、スマホゲームやってるよ
事例紹介
事例１： スマホRPGゲーム
- web socket使ってる レイドボス出てきたらそのレイドボスとweb socket鯖とを紐付けて、ユーザにはその鯖に接続してもらう形で共闘を実現
- web socket鯖は常に監視してる サービスインできるかどうかを常にチェックしスタンバイ状態に昇格した鯖をRedisで管理し、レイドボス現れたらそこから一台選ぶ方式
- あまりスケールアウトに関しては考えてない 鯖落ちたらボス逃げたことにする
事例２： 秘密(言えないらしい・・。)
- Web RTC使ってる！ 秘密なのでいえないことが多すぎ・・。なぜこれを題材に選んだのか疑問
事例３： 株式会社PIALA
事例４： capy
- CAPTCHAをパズル形式でつくったよ画像ならCPUに解析されにくいからいいね ネットワークのレイテンシユーザに届くまでに0.3secを目指してる
経験則を共有
- compute-image-packages これは気を付けよう。ちゃんといれてちゃんと起動しないと、コマンドからの変更が反映されない
- ライブマイグレーション ミリセックでの監視はちょっと厳しい
- インスタンス作成するときに service scope は後から作り替えれないので気を付ける
- Aggregate api いいよ！
- IP Forward フローティングIPの向き先を変更できるよー（でも変更に2、3秒かかる）プロキシーみたいなやつ
- インスタンス作成する際に選択できるDiskの種類は3種類
PD/SSDPDで十分LocalSSDはインフラの最終兵器
BootDISKは10Gだからちょっと増やした方がいいかもね - LoadBalancer
台数に注意するべし、台数少ないとちょっと片寄る
プロトコルとポートに制限がない！！ - HTTP LoadBalancer http <-> httpsのリダイレクトができないよ
- CloudStorage Nearlineは安いからいいよ
- BigQuery いいね！
考察
時間が少なかったからか説明がざっくりしすぎているのと、進行中の案件とか他社との契約上詳細に説明できない資料とかが多くあまり意味の無い時間だった
Using player telemetry to create better games
ゲームアナリティクス
まずはバッチ処理のスピードアップをしましょうー
バッチ処理の流れとして、
- まずログデータが入ってくる（JSONとか）
- それをクラウドストアに格納する
- ビッグクエリということで分析し、グラフとかで出力する
https://cloud.google.com/datalab/?hl=ja ここで分析、可視化するよこれを使うとリアルタイムでクエリを投げてグラフでみせれるよー（index張ってないのに5億行のデータが１桁秒ぐらいだったよ・・・）
ざっとシステム構成を書くとこんな感じ
game server -> cloud storage -> cloud dataflow -> bigquery
間にcloud dataflowを挟むのがミソcloud dataflowにいろんなデータが入ってきて整形してbig queryにいれる役割
cloud dataflowの利点データのinから処理、格納、分析、可視化までがひとつのpipelineでできる - 直視的なデータ処理フレームワーク
- フルマネージド
- ミッドジョブのオートスケーリング データ量によってのスケールを自動で
- ミッドジョブのリキッドシャーディング 前の処理を待つ時間が発生しない（処理をすべて管理して自動でやるから）
- バッチ処理とストリーム処理を一つに
次に、バッチからリアルタイム解析のスピードアップ
ゲームデータ → cloud pub/sub -> cloud dataflow -> bigquery
簡単に言うと、 JSON → テーブルフォーマットという流れだからシンプルだねーこれがリアルタイムで動いてるからJSONで入ってきながらすぐすぐテーブルフォーマットになってるからクエリを実行できるサンプルサイト
そして最後に、開発期間のスピードアップ（期間短縮）ー 典型的なビッグデータ処理
Dataflow と apache sparkの場合、Dataflowのコードの方が短く簡潔にかけるよ
Agility: Firebase
Firebaseの紹介googleが買収したよゲームじゃない部分の開発が楽になるよなにするやつ？
リアルタイムのアプリケーションとモバイルのPFリアルタイムデータベースリアルタイムユーザ認証静的なホスティングデバイスにfirebaseを直結させるデータはfirebaseに繋いでイベントドリブンする感じNoSQLでJSONでいれる感じ
http://www.infoscoop.org/blogjp/2015/01/24/realtime-app-firebase/ 参照ユーザ同士のチャットいけるよ（同時5万人ぐらいは実績あり）イベントのトラッキングにもってこい（クリアしたとかクリックしたとか）Jsonでデータ保存するんだけど「UIDが一致するときのみWrite」みたいなqueryも実行できるよ(リアルタイムユーザ認証)
考察
AmazonのDynamoDBにデータ入れられたときにバックエンドでそのイベントを監視しておいてイベントをトリガーとして他のスクリプトを起動するやつににてる
AmazonのLambdaだったかな
Start your engine：App Engine と Compute Engine のデモンストレーション
- バックエンドの選択肢
app engine
PaaS ソース書いたらデプロイしておわり！完全管理
cumpute engine
IaaS 仮想マシン 柔軟 高パフォーマンス
container engine
中身はGCE docker
- ストレージ
datastorecloud SQL（第２世代）
MySQL リードレプリカ バックアップのスケジュールSSDも選べるよ
cloud storage
オブジェクトストレージ ファイルとか 一時的に有効なURL発行とかもできるよ エッジキャッシュ(CDNサービスがα版のものがあるけどそれの代替)
big table
datastoreと同じだけどさらに高パフォーマンス 10ms以下での読み書き
- その他
Memcahe
app engine内で使えるよ共有領域ならただ！データ漏れるかもだけど
cloud endpoints pubsub
メッセージング コンポーネントの結合 ← こっちがメインネットワーキングgoogleの専用ネットワーク使えるよ
実際の例
app engineでAPIエンドポイントapp engineではできない部分はcompute engineで補ってるよapp engine中心アプリケーション層がスケーラビリティデータストア層もスケーラビリティサーバインスタンスの起動が早い(Goなら１秒かからない)アプリのバージョンの切り替え、切り戻し容易(トラフィックをバージョンごとに割り振れる)CloudEndpointsでRESTfulAPIが簡単に作れるよ
グローバルローバランサが国ごと繋ぎ先を分けれるcompute engine中心OSSが利用できるよ既存環境からのマイグレーションが楽AppEngineでできないこともできるロードバランサが強力ライブマイグレーションVMの種類が豊富だからちょうどいいのを選べる
マッチメイキングコンテナー（なかではGCEが動いてる）
プロフィールとセッション管理アップエンジンからソケットAPIを利用してDBに繋いでるMySQLはクラウドSQLを使ってなくてGCEに自前でたててる（このころはまだ第1世代だったから性能が・・
0コメント