DevFest Tokyo 2017
DevFest Tokyo 2017
日時
2017年10月9日 10:00〜17:00
会場
国際交流館（東京都江東区青海2-2-1）
主 催
GDG Tokyo, Shibuya.apk, DroidKaigi, 日本Androidの会, golang.tokyo, html5j, GTUG Girls, Women Who Go, XR 女子部, Droid Girls, Geek Women Japan, GCPUG, TFUG, TangoWG
スライド資料
聴講したセッション資料
- クラウドってなんだろ？クラウドを活かすアプリケーションの設計とは？
- 大半のウェブサービス/アプリは，Firebaseなら簡単で安いですよ
- Go徒然日記
- Goのサーバーサイド実装におけるレイヤ設計とレイヤ内実装について考える
- FirebaseAnalytics + BigQuery + DataStudio
- AWSとGCPのいいとこどりでつくる分析基盤のきほん
他セッション資料
- GCP パネルディスカッション
- FirebaseとReact Nativeでのモバイルアプリの作り方
- GCPではじめるかんたん機械学習
- React Nativeアプリをリリースし続けるために、最初に行う８つの取り組み
- deeplearn.js入門
- TensorFlowで趣味の画像収集サーバーを作る
- Android Things+TensorFlowで作る猫トイレ監視システム
- FlutterでAndroid/iOS両対応のアプリ開発
- BlockChain on Go
- Go1.8 for Google App Engine
- Android Studio 3.0 profiler ハンズオン
- Android Studio 3.0 ハンズオン : LayoutEditor & ConstraintLayout
- Instant Apps or Progressive Web Apps
- Android 1.5 - 8.0 Walk through - Retro/Prospective Android Application Development
- Android1.5~8.0 Walkthrough
クラウドってなんだろ？クラウドを活かすアプリケーションの設計とは？
October 9 Session / 10:40 - 11:20 / 会議室2/ Japanese
GCPUG Tokyo Organizer
メルカリ/ソウゾウ
@sinmetal
https://goo.gl/X54o2S
クラウドってなんだろ？
- データセンター上に存在するハードウェアリソースをAPIを利用して動的にリソースを借りることができる仕組み
- 柔軟に迅速にリソース提供を受けることができる
- 料金はだいたい従量課金制
- 使ったリソースの料金を払う
- スモールスタートに適している
クラウドの利点
- H/Wを調達するイニシャルコストがかからない
- H/Wをリプレースする必要がない
- いつでもマシンリソースの構成を変更できる
クラウドのレイヤー
- SaaS(Software as a Service)
- イメージは「部屋を借りる」
- OS、ハードウェア、ネットワーク、ミドルウェア(DB等)、アプリケーション
- PasS(Platform as a Service)
- イメージは「家を借りること」
- OS、ハードウェア、ネットワーク、ミドルウェア(DB等)
- DBaaS(Database as a Service)
- FaaS(Function as a Service)
- IaaS(Infrastracture as as Service)
- イメージは「部屋を借りること」
- OS、ハードウェア、ネットワーク
クラウドは壊れないのか？
クラウドを活かすには？
リトライ
- 間にネットワークが入れば、エラーは起こる
- 色んなレイヤーでリトライする
- クラウドのサービスにはレプリカが存在するものが多い
- １つ壊れても、他のものたちが応えてくれる
- アプリケーション側で適切なタイムアウトを設定して、リトライする
冪等性
- リトライ時に複数データを作成してしまわないように冪等性を考える
- アプリケーション側で同じキーを生成して同じ場所に上書きするようにする
- すでに更新されていたら、処理をスキップする
リクリエイト
- 複数インスタンスを用意しておく
- 自分のアプリケーションが0台にならないように
- 起動にかかる時間を短くする
- なるべく早く役割を果たせるように
- 状態はなるべく持たないようにする
- メモリは消し飛ぶので、状態はなるべく外へ
- 役割を小さくして、初期処理を少なく
- クラッシュした時の影響範囲を限定的に
パフォーマンス
非同期処理
- 同期的に処理する必要がない処理は非同期に処理したほうが安くパフォーマンスを上げれる
- 非同期処理はQueueのサービスが便利
- GCPだとCloud Pub/Sub,App Engine Task Queueがある
- Queueを挟むことで、処理の粒度でWorkerを分離できる
- Workerのマシンスペックを変更できる
- Workerの生成タイミングを遅延できる
- Taskの管理をQueueがしてくれる
- 非同期処理、分散処理をする時に気を付けること
コンパクトな環境
- 必要なときに必要なリソースを用意するには
- Container
- Docker
- Borg(Google内部のみ)
- Binary
- Go
- Container
高速なネットワーク
- 分散したタスクの分配や、コンテナの配備のために、高速なネットワーク
めんどうだったら
- GCPのフルマネージドサービスにある程度任せる
- App Engine
- BigQuery
- Cloud Dataflow
Google App Engine
- Web ApplicationのためのPaaS
- 非常に高いスケーラビリティ
- デフォルトでオートスケール
- Versioning
- Task Queue
Google BigQuery
Google BigQueryがなぜはやいのか？
- データを元に分割して大量のHDDに保存している
- クエリ実行時に動的に数千台のインスタンスを起動する
Google Cloud Dataflow
- パイブライン処理をフルマネージドで行うサービス
- バッチ処理、ストリーミング処理、どちらも可能
- Java or Python SDK(Apache Beam)
- BigQueryではやりにくい処理を任せされる
大半のウェブサービス/アプリは，Firebaseなら簡単で安いですよ
October 9 Session / 11:30 - 12:10 / 会議室1/ Japanese
神楽坂やちま yati.ma/qi
https://speakerdeck.com/yatima/apuriha-firebasenarajian-dan-dean-idesuyo
Agenda
- ざっとFirebase全体像
- dbについて
- 概要
- コスト
- よくある誤解、苦手なこと
Firebase
- オールインワン
- 細かい融通は聞かないことも
- PC用webにも使用できる
開発コア系
realtime database
- クライアントと直接
- オフライン対応
- リアルタイム
- ダウンロード 1ドル/GBなど
Hosting
- htmlなど置いておく
- httpsにも対応
- 簡単に戻せる(バージョン管理)
- ダウンロード 0.15ドル/GBなど
Cloud Storage
- 写真、音楽なのでメディア
- ネット状況に応じ一時停止・再開
- ダウンロード 0.12ドル/GB
Could Functuion
- サーバー側の処理をサーバー管理なしで
- サーバーの性能、更新を考えなくて良い
- サーバーの更新を考えなくていい
- 1GHz 24h30dで約20ドルなど
便利機能
Authnetication
- セキュリティなログイン機能
- 他サービスとの連携
- アクセス可否など
- 電話認証のみ 0.06ドル/アカウント
Cloud Messaging
- 通知を飛ばせる
- 優先度、有効期限
- 無料
Dynamic Links
- アプリ内への直リンク
- 特典の提供
- ユーザー同士でのコンテンツ共有
- 無料
Invites
- Dynamic Links上
- メールなどで知人に招待
- 無料
監視系
Analytics
- 多数の広告サービスと連携
- BigQueryとも
- 無料
- web:Google Analytics
Crash Reporting
- エラーの優先順位
- グループ化
- メール通知
- 無料
- web:Stackdriver Error Reporting
Performance Monitoring
- ネット状況も把握できる
- 無料
- web:(Stackdriver Trace)
テスト系
Test Lab for Android
- 既存環境と容易に統合
- テストコードなしでも
- 1or5ドル/聞き/時間
- web:なし
Remote Config
- アプリを更新なしで変更
- 日替わりセール
- ユーザそうにより異なるUI
- 無料
- web:Google Optimize
広告系
App Indexing
AdWords
- 広告を出す側(宣伝)
- 検索広告、ディスプレイ広告、動画広告
- Analyticsで定義した条件宛、も可
AdMob
- 広告を貼る側(収入)
- バナー広告、動画広告、画面遷移遷移時の広告
- コンテンツそっくり広告
realtime database
Firebaseは真の「サーバレス」！
Firebaseは複雑化しにくい！
Cluod Firestore
Cluod Firestore
- おおむねrealtime databaseと同じ
- そこそこクエリ使える
- とても落ちにくい
- realtime databaseの約1/10の値段
「realtime databaseは高価」
- 前述してきたように
- 総合的には安くあがる
「検索使えない」
- 検索がほぼ使えないのは確か
- しかしAlogoliaというサービスと連携できる(公式サンプルもあり)
「フィルタ使えない」
- フィルタは工夫で結構いける
- Firestoreならクエリもあるし
「落とし穴があるはず」1
- 情報はまだ少ないのは確か
- 今後に期待
「落とし穴があるはず」2
- データ量は普通より消費しやすい
- 「時間と空間のトレードオフ」みたいな処理を減るので開発の手間も減る
「すこしずつ切り替えよう」
- 辞めた方がいい
- シンプルにできるという強みが活きない
- むしろ相性の問題で裏目に
- 使う時は一気にするべき
(web)使うならAngular？
- 確かに公式はAngularを推すけど...
- Angularは重厚長大
- Reactは学習コストが
- Vueがちょうどいい
FiVeスタック！
- Firebase + Vue
- 相性もいいし
- Vue単体としても良い
- 学びやすい
- 拡張性など公式で対応
苦手なこと
一部の企業・研究向けアプリ
- 基本的にざっくり感
- クエリも貧弱(Firestoreなら改善)
- 厳密さ重要ものには不向き
FPSや格闘ゲームなど
- 遅延少なめではあるがめちゃくちゃ少ないわけでもない
- 通信遅延が致命的なアクションゲームも不向き
Go徒然日記
October 9 Session / 13:20 - 14:00 / 会議室3/ Japanese
Women WHo Go Tokyo
https://speakerdeck.com/mom0tomo/gotu-ran-ri-ji
1年くらいかけてGoでどんなことをしてきたのか
Agenda
- はじめてのプログラミングGo
- やってみたからのプロダクト導入
- Goでやっていき宣言
はじめてのプログラミングGo
よかったところ
- 公式ドキュメントを読むようになる
- Go Docを見るようになった
- Goで書かれているので読める、勉強になる
- 型を意識してコーディングできる
- OSや低レイヤーを意識できる
- 活発なコミュニティがいくつもある！
難しかったところ
- 習得に時間がかかる
- 出来る人がすごすぎる
- 新しい言語なので、先駆者として導入している企業・エンジニアの皆さんが錚々たる顔ぶれ。
- 身近にロールモデルとする人を見つけにくいかも。
やってみたからのプロダクト導入
こんなことやりました
よかったところ
- デプロイがとにかく楽
- コンパイルが早い
- こう書くのが良い！がはっきりしている言語なので、Issueを受け渡しやすかった。
- 低レビューコスト
- interfaceのおかげでレガシーで謎のデータ構造を目の前にしても扱える安心感
懺悔
- No CI No Life
- buildしてデプロイするまでの仕組み化をやらなかった
- ユーザーいじめ問題
- 一括更新等を行った際に大量のプルリクエストが...悪
- Gopher少ない問題
- 新しく取り組む言語なのだから、もう2名くらいプログラマーを巻き込めばよかった。
Goでやっていき宣言
やっていきたいこと
Goのサーバーサイド実装におけるレイヤ設計とレイヤない実装について考える
October 9 Session / 14:10 - 14:50 / 会議室2/ Japanese
https://www.slideshare.net/pospome/go-80591000
Agenda
- レイヤとは？
- レイヤ設計について
- レイヤ内実装について
なぜレイヤーが必要なのか？
- コードの依存関係を整理できる
- レイヤ間の差し替えを担保することができる
- レイヤ内のパッケージ凝集度を高めることができる
どういうレイヤ設計が適切なのか？
- 世の中には色々あるが、大体どれを採用しても以下は担保される
- モデルはどのレイヤにも依存しない
- にたような責務を持ったレイヤがある
- 各レイヤ間の依存が単一方向依存になる
レイヤ内実装については以下の資料
https://www.slideshare.net/pospome/go-80591000
FirebaseAnalytics + BigQuery + DataStudio
October 9 Session / 15:00 - 15:40 / 会議室2/ Japanese
https://www.slideshare.net/ssuser8463f8/firebaseanalyticsbigquerydatastudio/1
Agenda
- Firebase Analyticsって？
- BigQuery Export
- DataStudio
Firebase Analyticsって
- アプリにFirebaseSDKを導入するだけで、自動的にある程度のデータを収集してくれる
- 自分で収集するイベントを設定することもできる
- データの収集はイベント単位
- 他のサービスとも統合出来る
- BigQuery
- Firebase Crash Reporting
- FCM
- Firebase Remote Config
- Google タグマネージャ
BigQueryの仕組み
- The 12 Components of Google BigQuery
- 重要なコンポーネント
- Dremel(クエリエンジン)
- Colossus(ストレージエンジン)
- Jupiter(ネットワーク)
- Borg(大規模コンテナ・クラスタ管理)
サーバレス・サービスモデル
- 完全なサーバレスモデルである
独自のストレージエンジン
- Colossus
- Capacitor
- カラムナーストレージフォーマット
- データの最適化(並び替えなど)
- テーブルパーティショニング
- Poseidon
Dremelというクエリエンジン
独立したストレージとネットワーク
- Jupiterネットワーク
- Googleが独自に開発したネットワーク(H/W,S/Wともに)
- 1Pb/secの帯域
- ストレージはネットワークで接続
費用について
- クエリ課金
- クエリ毎にりようしたカラムに対するデータ容量で課金
- 月額固定料金
- ストレージ課金
- データ容量に対して課金
- 90日以上変更のないテーブルはデータ容量に対しての課金が半額
- ストリーミングインサート
- バッチでInsertするのではなく、１行ずつ個別にいれるデータ量に対して課金
- https://cloud.google.com/bigquery/pricing?hl=ja#transfer
IAMと認証、監査ログ
- Google CloudのIAMと権限の連携
- DataSet単位での権限付け
- 認証はO-Authとサービスアカウント
- 全ての操作を監査ログで保存し、BigQueryへExportも可能
BigQueryの制限事項
BigQuery Export
- ユーザー単位で行動ログ(JSON)がBigQueryにExportされる
- RealTimeExport(間隔は20分)と1日1回のExportの２つがある
- Blazeの契約が必要
それで何が嬉しいの？
- そもそもそんなデータ作るのめんどい
- 他のデータと行動データをくっつけることが出来る
- 持ってるアプリのデータ
- Adword,DCM,YouTubeのレポートなどなど
DEMO
DataStudioとは
- 簡単にパワポに数値を埋め込むことが出来るツール
- リアルタイムにデータを取得することが出来たり
- BIツールの超簡易版(Tableauみたいな機能はない)
DEMO
- リアルタイムに表示出来る
- 会話しながらお絵かき出来る
- Googleのサンプルを分解出来る
- 無償でお絵かきできる
私たちクラウドのこんなところが好き
October 9 Session / 15:50 - 16:30 / 会議室3/ Japanese
https://speakerdeck.com/chie8842/awstogcpfalseiitokodoridetukurufen-xi-ji-pan-falsekihon
クラウドフル活用で大規模分析基盤を超短期間で構築した事例を共有
今日話す範囲
進め方そのものの話アプリレイヤの話- 基盤レイヤの話 ← ここの話をします
そもそも分析基盤とは？
- データを蓄積・活用するための基盤
- 分析基盤
- 施策への評価
- アドテク
- レコメンド
- 分析基盤
もともとあった分析基盤の課題①
もともとあった分析基盤の課題②
- マスタデータは別のDBにある
- マスタデータと突合して分析したい場合は 別の環境にデータを移す必要がある
- joinしたカラム同士でデータ型が異なる
もともとあった分析基盤の課題③
新しい分析基盤に求められるもの
- 分析者にとって使いやすい
- 追加開発・運用がしやすい
- 列変更等が柔軟にできる
- 複雑なETL処理に柔軟に対応できる
- コスト(イニシャル/ランニング)が現実的である
- スケーラブルである
作った分析基盤
- EC2(fluentd) → Kinesis → S3 → EMR(Spark) → S3 → EC2(embulk) → BigQuery(GCP)
- RDS(MySQL) → EC2(embulk) → BigQuery(GCP)
- BigQueryへデータを集約した
- 分析者、プランナーはtableauを使用してBigQueryへ
- S3 → データレイク
- EMR(Spark) → データ加工ツール
- BigQuery → DWH・DM
データレイク：S3
- 非構造化データの保存
- サービスの動いている環境(AWS)に近い場所にデータを保持するほうが都合がよい
- ネットワーク転送コスト
- 管理しやすさ
- 同じバケット内でもプレフィックスやタグを利用した柔軟なライフサイクルの運用
- Kinesis Firehoseを利用することでかんたんに日時ごとにディレクトリを分けて保存できる
DWH・DM：BigQuery
- 分析者にとって使いやすい
- StandardSQLが利用できる
- UDFやWindow関数も使える
- スプレッドシートやpandas dataframeとの連携
- 後のテーブル設計変更がしやすい
- テーブルへの列追加ができる
- 安定したレイテンシとスループット
- メンテナンスフリー
- 時間課金でなくクエリ課金
- RedShiftやAthenaを使う場合に比べて、AWSからGCPへのデータ転送が発生するが運用コストの削減で相殺できる範囲だった
EMR(Spark)：データ加工
- サービス側のログ設計の関係で、以下が必要だった
- 不要なログ出力が全体の９割占めているため、BigQueryへ転送する前にフィルタ処理
- SQLで表現できない飛行増加データに対する複雑なETL処理
- ログが増大してもクラスタ台数をふやすことでスケールできる
- SQLで済ませられるものはBigQuery上で加工
使われる分析基盤構築のコツ
- 早く作っても長くつかえないものを作っても意味がない
- DWHの場合、基盤部分は「作って壊して」が簡単にはすまない
- 基盤部分は慎重に決めた
まとめ
用語説明
- データレイク
- 加工前の生ログを保存する場所
- DWH
- 分析しやすいように加工されたデータを格納するデータベース
- DM(データマート)
- 分析用途に応じて集計後のデータなどを格納するなど、サンドボックス的につかうためのデータベース
- データ加工ツール
- ログを分析しやすい形に整形するツール
- ワークフローエンジン
- 一連のデータ処理のフローを管理するツール
