web-technical-blog

web開発に関する技術メモ

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

スライド資料


聴講したセッション資料


他セッション資料



クラウドってなんだろ?クラウドを活かすアプリケーションの設計とは?

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、ハードウェア、ネットワーク

クラウドは壊れないのか?

  • クラウドサービスが構築されているデータセンターには、H/Wが存在し、日々壊れていっている
  • クラウドサービスは壊れないのではなく、壊れてもすぐに蘇るもの

クラウドを活かすには?


リトライ

  • 間にネットワークが入れば、エラーは起こる
    • 色んなレイヤーでリトライする
  • クラウドのサービスにはレプリカが存在するものが多い
  • 1つ壊れても、他のものたちが応えてくれる
  • アプリケーション側で適切なタイムアウトを設定して、リトライする

冪等性

  • リトライ時に複数データを作成してしまわないように冪等性を考える
  • アプリケーション側で同じキーを生成して同じ場所に上書きするようにする
  • すでに更新されていたら、処理をスキップする

リクリエイト

  • 複数インスタンスを用意しておく
    • 自分のアプリケーションが0台にならないように
  • 起動にかかる時間を短くする
    • なるべく早く役割を果たせるように
  • 状態はなるべく持たないようにする
    • メモリは消し飛ぶので、状態はなるべく外へ
  • 役割を小さくして、初期処理を少なく
  • クラッシュした時の影響範囲を限定的に

パフォーマンス


非同期処理

  • 同期的に処理する必要がない処理は非同期に処理したほうが安くパフォーマンスを上げれる
  • 非同期処理はQueueのサービスが便利
  • GCPだとCloud Pub/Sub,App Engine Task Queueがある
  • Queueを挟むことで、処理の粒度でWorkerを分離できる
    • Workerのマシンスペックを変更できる
    • Workerの生成タイミングを遅延できる
    • Taskの管理をQueueがしてくれる
  • 非同期処理、分散処理をする時に気を付けること
    • タスクを小さくしておく
      • リトライ範囲を小さく
      • 分割してたくさんにしないと分散できない
      • 巨大なCSV -> たくさんの小さなCSV

コンパクトな環境

  • 必要なときに必要なリソースを用意するには
    • Container
      • Docker
      • Borg(Google内部のみ)
    • Binary
      • Go

高速なネットワーク

  • 分散したタスクの分配や、コンテナの配備のために、高速なネットワーク

めんどうだったら

  • GCPのフルマネージドサービスにある程度任せる
    • App Engine
    • BigQuery
    • Cloud Dataflow

Google App Engine

  • Web ApplicationのためのPaaS
  • 非常に高いスケーラビリティ
    • デフォルトでオートスケール
  • Versioning
  • Task Queue

Google BigQuery

  • データを分析するためのフルマネージドサービス
  • SQLを利用してインタラクティブな分析が可能
  • TB単位のデータでも数秒でフルスキャン

Google BigQueryがなぜはやいのか?

  • データを元に分割して大量のHDDに保存している
  • クエリ実行時に動的に数千台のインスタンスを起動する

Google Cloud Dataflow

  • パイブライン処理をフルマネージドで行うサービス
  • バッチ処理、ストリーミング処理、どちらも可能
  • Java or Python SDK(Apache Beam)
  • BigQueryではやりにくい処理を任せされる
    • SQLではやりづらいこと
    • ストリーミング処理

大半のウェブサービス/アプリは,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

  • アプリをグーグル検索に
  • コンテンツも反映
  • (Androidのみ)個人的なコンテンツ
  • (Androidのみ)履歴記録
  • 無料

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

  • コントりびゅーたのDave Cheneyさんの授業
  • じゃんけんゲームを作成
  • PaizaでGo
  • バッチの作成

よかったところ

  • 公式ドキュメントを読むようになる
    • Go Docを見るようになった
    • Goで書かれているので読める、勉強になる
  • 型を意識してコーディングできる
    • PHPRubyは型を意識せずにかけるのがいいところ
    • しかし、プログラミング初心者は型を意識しながら書いた方がきちんと理解できる
  • OSや低レイヤーを意識できる
  • 活発なコミュニティがいくつもある!

難しかったところ

  • 習得に時間がかかる
    • 他の言語をマスターしたことがある方には問題ないが、初学者は型など基本からしっかり学ぶので時間がかかる。
    • コンパイル時に丁寧なエラーになるので、一つ一つ修正していくことで勉強になる
  • 出来る人がすごすぎる
    • 新しい言語なので、先駆者として導入している企業・エンジニアの皆さんが錚々たる顔ぶれ。
    • 身近にロールモデルとする人を見つけにくいかも。

やってみたからのプロダクト導入


こんなことやりました


よかったところ

  • デプロイがとにかく楽
  • コンパイルが早い
  • こう書くのが良い!がはっきりしている言語なので、Issueを受け渡しやすかった。
  • 低レビューコスト
  • interfaceのおかげでレガシーで謎のデータ構造を目の前にしても扱える安心感

懺悔

  • No CI No Life
    • buildしてデプロイするまでの仕組み化をやらなかった
  • ユーザーいじめ問題
    • 一括更新等を行った際に大量のプルリクエストが...悪
  • Gopher少ない問題
    • 新しく取り組む言語なのだから、もう2名くらいプログラマーを巻き込めばよかった。

Goでやっていき宣言


やっていきたいこと

  • blogの記事をサルベージするツールを作りたい!
    • DocBaseの記事を一気に取得するツール
  • Goで静的解析をやりたい!
  • if err!=nilなんども書かなくていいようにするアレ

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の仕組み


サーバレス・サービスモデル

  • 完全なサーバレスモデルである
    • HW、機能アップデートの管理はすべてGoogleが行う
    • VMやCPU、メモリ、ディスクサイズなどの設定も不要
    • 数秒で数十万コアを利用することが出来る
    • 利用者はデータを入れること、抽出することだけを考える

独自のストレージエンジン

  • Colossus

  • Capacitor
    • カラムナーストレージフォーマット
    • データの最適化(並び替えなど)
    • テーブルパーティショニング
  • Poseidon
    • 様々なファイルフォーマットへの対応
    • CSVJSON、Avro、DataStore
    • ==クエリとインポート/エクスポートの分離==

Dremelというクエリエンジン

  • 2015年にアップデート
  • 初めはBigQuery独自のSQLだけでしたが、Standard-SQLにも対応
  • シャッフルやソートはインメモリで実施
  • Borgで管理
  • ==いつでも元気にフルスキャン==

独立したストレージとネットワーク

  • Jupiterネットワーク
    • Googleが独自に開発したネットワーク(H/W,S/Wともに)
    • 1Pb/secの帯域
    • ストレージはネットワークで接続

費用について

  • クエリ課金
    • クエリ毎にりようしたカラムに対するデータ容量で課金
    • 月額固定料金
  • ストレージ課金
    • データ容量に対して課金
    • 90日以上変更のないテーブルはデータ容量に対しての課金が半額
  • ストリーミングインサート
    • バッチでInsertするのではなく、1行ずつ個別にいれるデータ量に対して課金
  • https://cloud.google.com/bigquery/pricing?hl=ja#transfer

IAMと認証、監査ログ

  • Google CloudのIAMと権限の連携
  • DataSet単位での権限付け
  • 認証はO-Authとサービスアカウント
  • 全ての操作を監査ログで保存し、BigQueryへExportも可能

BigQueryの制限事項

  • DMLが使用できるみたい
  • Updateとかができる
  • 詳しくはマニュアルを読んでください

BigQuery Export

  • ユーザー単位で行動ログ(JSON)がBigQueryにExportされる
  • RealTimeExport(間隔は20分)と1日1回のExportの2つがある
  • Blazeの契約が必要

それで何が嬉しいの?

  • そもそもそんなデータ作るのめんどい
  • 他のデータと行動データをくっつけることが出来る
    • 持ってるアプリのデータ
    • Adword,DCM,YouTubeのレポートなどなど

DEMO

  • サンプルデータでデモする
  • データはiosandroidで別れる
  • ユーザーの属性とイベントにデータが入ってくる

DataStudioとは

  • 簡単にパワポに数値を埋め込むことが出来るツール
  • リアルタイムにデータを取得することが出来たり
  • BIツールの超簡易版(Tableauみたいな機能はない)

DEMO

  • リアルタイムに表示出来る
  • 会話しながらお絵かき出来る
  • Googleのサンプルを分解出来る
  • 無償でお絵かきできる

私たちクラウドのこんなところが好き

October 9 Session / 15:50 - 16:30 / 会議室3/ Japanese

https://speakerdeck.com/chie8842/awstogcpfalseiitokodoridetukurufen-xi-ji-pan-falsekihon


クラウドフル活用で大規模分析基盤を超短期間で構築した事例を共有


今日話す範囲

  • 進め方そのものの話
  • アプリレイヤの話
  • 基盤レイヤの話 ← ここの話をします

そもそも分析基盤とは?

  • データを蓄積・活用するための基盤
    • 分析基盤
      • 施策への評価
      • アドテク
      • レコメンド

もともとあった分析基盤の課題①

  • DWHのテーブル設計の問題 例)
    • 不要なログが全体の9割
    • 適切なデータ型が使われていない
    • jsonオブジェクトがテキスト形式で入っている
  • 分析者/システム開発
    • 分析しづらい(アドホック分析の度に複雑な正規表現抽出)
    • クエリ実行時に過大なサーバーリソースが必要
    • ストレージ容量逼迫

もともとあった分析基盤の課題②

  • マスタデータは別のDBにある
    • マスタデータと突合して分析したい場合は 別の環境にデータを移す必要がある
    • joinしたカラム同士でデータ型が異なる

もともとあった分析基盤の課題③

  • ログ増大に伴うパフォーマンスボトルネック
    • 日次バッチが終わらない
    • 気軽にアドホック分析ができない
  • クエリを投げる際はSlackに報告する運用

新しい分析基盤に求められるもの

  • 分析者にとって使いやすい
  • 追加開発・運用がしやすい
    • 列変更等が柔軟にできる
    • 複雑なETL処理に柔軟に対応できる
  • コスト(イニシャル/ランニング)が現実的である
  • スケーラブルである
    • 分析対象データの種類やサイズが増えても対応できる

      AWSGCPのいいとこどりした分析基盤


作った分析基盤

  • 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

  • 分析者にとって使いやすい
  • 後のテーブル設計変更がしやすい
    • テーブルへの列追加ができる
  • 安定したレイテンシとスループット
  • メンテナンスフリー
  • 時間課金でなくクエリ課金
  • RedShiftやAthenaを使う場合に比べて、AWSからGCPへのデータ転送が発生するが運用コストの削減で相殺できる範囲だった

EMR(Spark):データ加工

  • サービス側のログ設計の関係で、以下が必要だった
    • 不要なログ出力が全体の9割占めているため、BigQueryへ転送する前にフィルタ処理
    • SQLで表現できない飛行増加データに対する複雑なETL処理
  • ログが増大してもクラスタ台数をふやすことでスケールできる
  • SQLで済ませられるものはBigQuery上で加工

使われる分析基盤構築のコツ

  • 早く作っても長くつかえないものを作っても意味がない
  • DWHの場合、基盤部分は「作って壊して」が簡単にはすまない
  • 基盤部分は慎重に決めた

まとめ

  • クラウドフル活用で分析基盤を超短期間で作れる
  • クラウドも他の技術も、一つにこだわらず柔軟に活用するの大事

用語説明

  • データレイク
    • 加工前の生ログを保存する場所
  • DWH
    • 分析しやすいように加工されたデータを格納するデータベース
  • DM(データマート)
    • 分析用途に応じて集計後のデータなどを格納するなど、サンドボックス的につかうためのデータベース
  • データ加工ツール
    • ログを分析しやすい形に整形するツール
  • ワークフローエンジン
    • 一連のデータ処理のフローを管理するツール