DSOC Development Group の 木田 です。
先日行われた Google Cloud Next '18 in Tokyo に参加してきました。
今までは AWS を中心に触ってきたので、GCP のホットな話題にも触れたいと思い、参加しました。個人的には、最近 Firebase に注目しているので、その話を聞けるのも楽しみでした。
本ブログは、私がセッションを聞きながら取ったメモを、まとめたものになります。セッション後に独自で調べた内容も追加しています。6セッション分と、かなりボリュームがあるので箇条書きととさせていただきました。
イベントに参加できなかった方や、聞きたいけど聞けなかったセッションがある方などのお役に立てば良いな、と思います。
- Google Cloud Next '18 in Tokyo とは
- DMM の課金系 API における GAE と Cloud Spanner による NoOps の実現
- GCE を利用した Sansan のマイクロサービス移行とそのメリット
- 機械学習＋スマートIoTで、じゃんけんに勝つ方法
- Cloud Firestore でスケーラブルなアプリケーションを開発しよう
- Firebase 入門、低コストで迅速な開発を行うには？
- Web API の育て方：駅すぱあと Web サービスでの Apigee 適用事例
- Cloud Dataflow を利用したサーバーレスデータ処理
- おわりに
Google Cloud Next '18 in Tokyo とは
公式のイベント開催概要 には、以下のように書いてあります。
- Google Cloud 製品やデバイスの最新テクノロジーや活用事例を学べる様々なコンテンツ
- 興味やレベルに合わせて選べる 130 を超えるセッション
- Google Cloud のテクノロジーに直接触れられる体験ブースやハンズオン セッション
- 様々な IT の専門家、技術者、経営者、そして Google のエキスパートたちと交流できる 2 日間
GCP の各サービスの概要や、企業における活用事例を学べる貴重なイベントだと思います。
以降、私が参加したセッションの内容と感想を箇条書きベースでまとめています。 補足 : と書いてあるのは、私が追加で調べた箇所になります。
DMM の課金系 API における GAE と Cloud Spanner による NoOps の実現
9月 19日 水曜日 1:20–2 PM 東京プリンスホテル | Room A
Google App Engine と Cloud Spanner の概要
- Google App Engine
- アプリケーションを書いてデプロイするだけで、後は Google にお任せ
- 対応言語豊富
補足 :https://cloud.google.com/appengine/?hl=ja によると、追加設定なしで以下の言語に対応している。- Node.js
- Java
- Ruby
- C#
- Go
- Python
- PHP
- ストレージオプション豊富
補足 :https://cloud.google.com/appengine/docs/standard/python/storage?hl=ja#app_engine_datastore によると、以下のストレージオプションを選択可能。言語によっても違うようです。- Google Cloud Datastore
- Google Cloud SQL
- Google Cloud Storage
- Cloud Spanner が適するケース
- RDB, 水平スケールが必要な場合
- Cloud Spanner の特徴
- 一貫性のあるトランザクション
- 水平スケール
- RDB
- 99.999%の可用性
DMM 課金基盤の課題
- 課金基盤の課題
- オンプレミスも残っている
- 停止時の機会損失が大きい
- 数十のサービスが利用している
- 拡張性の限界
- サービス増やロードの特性の変化
- サービス毎にロード特性が異なる
- 課金基盤の要件
- マネージドサービス
- 高い可用性
- 高い拡張性
- 要件を満たすマネージドサービス
- Google App Engine
- API 基盤
- PaaS
- Cloud Spanner
- Database 基盤
- 最初は Cloud SQL だったが、以下の課題があった
- 容量制限
- メンテナンスウィンドウ
- Google App Engine
API基盤のサービス概要とプラクティス
- App Engine を使用
- Compute 系の PaaS 基盤
- Webアプリケーションなどで利用
- Standard Environment (SE)
- 責任分界点が高い
- 開発対象・運用対象が少ない
- 責任分界点より下が高性能
- 責任分界点が高い
- 機能とエコシステムは想像以上
- 我々のプラクティス
- Environment はスタンダート環境(SE)とフレキシブル環境(FE)がある
- SE の拡張性とマネージド率が重要
- Java 系の強い型付けに期待（基幹系）
- Java8 Runtime で制約が外れた
- 雛形の活用
- スピンアップ対策
- Instance のスピンアップ時間の確認
- ベンチマークツールを活用してスケールアウトさせる
- Transaction 制御
- Transaction 制御の機構は Cloud Spanner の制約により自作
- Cloud Spanner の JDBC ドライバは読み取り専用
- Project の構成
- 本番・本番以外の2系統に押さえて
- Deploy 手法
- git tag で version を打つと自動で配布
- Traffic 分割
- 人間が柔軟に対応できるよう Cloud Console 上から手動で実施
- 事前のスモークテスト
- 次 Version の URL を叩き検証
- Cloud Console 上で Traffic 割当
- 監視系
- ダッシュボードと Stackdriver を活用（一部 Mackerel）
- SE の制約は Java8 Runtime で軽減できた
Database 基盤のサービス概要とプラクティス
- Cloud Spanner を使用
- 非機能を充足させた NoSQL に RDB の機能性を追加し GCP のクラウド特性を付与したサービス
- NoSQL（非機能）
- 整合性
- 可用性
- 拡張性（水平方向）
- RDB（機能）
- スキーマ定義
- SQL
- 外から見ると一つのDBを触っているよう
- GCP（クラウド特性）
- フルマネージド
- 豊富なクライアント
- GUI, CUI, API, SDK
- 充実のエコシステム
- NoSQL（非機能）
- 裏では様々なテクノロジを駆使して高品質なデータベースを実現している
- コスト対策
- Cloud Spanner は高価なサービス、導入時にはコスト対策も行った
- Regional(複数Zone)
- Multi-Region(複数 Region)
- 設計最適化
- RDB とは勝手の違う要素
- PKの生成ロジックをUUIDベースに変更
- 連続したPK値の生成を回避した
- 連続したPK値は負荷集中を招く
- Secondary Index
- 必要性が確認できてから追加
- index は列を入れ替えた table
- index 増は書き込み対象の増加
- PKの生成ロジックをUUIDベースに変更
- 暖気処理
- 初回アクセス時とインターバル後に遅い場合があった
- 初回時の対策として App Engine の Warm-up 用の Queryをたたいた
- RDB とは勝手の違う要素
- クエリ最適化
- 実行計画を見てみる
- 処理時間の99%が最初の表結合
- ディレクティブを使って指示を入れる
- インデックスを入れる
- Managed なサービスなので（クラウド上）での検証が必要だった
- Export / Import 機能 も追加された
課題の解決状況
- 高い可用性
- 現時点で API, DB のダウンはない
- Cloud Spanner
- 無停止メンテナンス
- 無停止でのスキーマ変更や Index の追加が可能となった
- 自動ではないが、 Node 数の調整で柔軟にスケールできる
- 無停止メンテナンス
所感
- Kubernetes の波が来ていて、コンテナ時代を感じさせますが、GAE で済むものは GAE のような PaaS にした方が圧倒的に楽だろうな、と思います。
- 恥ずかしながら
Cloud Spannerは存じ上げておりませんでした。NoSQL に RDB の機能性を追加し GCP のクラウド特性を付与したサービスって最強やないか！と思いましたが、お値段もするということなので、コストとのバランスなのでしょうか。
GCE を利用した Sansan のマイクロサービス移行とそのメリット
9月 19日 水曜日 4–4:40 PM 東京プリンスホテル | Room A
弊社の 永井 が登壇しました。別途、記事を公開する予定ですので、詳しくはそちらを御覧ください。
（10月3日追記：記事を公開しました）
機械学習＋スマートIoTで、じゃんけんに勝つ方法
9月 19日 水曜日 5:20–6 PM ザ・プリンス パークタワー東京 | Room 05
機械学習も IoT もあまり知識がないので、理解できていない部分が多いです。メモしている内容も間違っている場合もありますので、参考程度にご覧いただければと思います。
アルゴリズムでじゃんけん判定
- littleBits の曲げセンサーモジュール
補足 :https://www.littlebits-jp.com/ によると littleBits はマグネット式の各モジュールをつなぎ合わせることで、電子回路を楽しく学べるオープンソースのライブラリーと記載されています。
- littleBits と Arduino とサーボモジュール
補足 :Arduino はアルディーノと読むようです。
- じゃんけんの手の判定方法
- all numbers < 100 => paper
- all numbers > 300 => rock
- Otherwise => scissors
機械学習で「賢い」じゃんけん判定
- Cloud Datalab
- Jupyter Notebook のクラウド版
- 曲げセンサーのデータを可視化
- 1D から 1D への線形変換
- 3D から 3D への線形変換
- センサーデータからグーチョキパーへの線形変換
- 特徴量を抽出したい
- 曲げたり伸ばしたりひっくり返したりして、ほしい形に変換する
TensorFlow で機械学習
- TensorFlow で線形モデルを書く
- 損失関数 : 学習の「コーチ」
- softmax_cross_entropy()
- 多クラスロジスティック回帰
- Matplotlib で可視化
- Arduino コードで機械学習モデルを利用
よりディープに
- TensorFlow Object Detection API
- 物体の識別
- Cloud Vision API のように
- ショッピングカートにラズパイ、カメラ
- ショッピングカートの中身を検出できるのでは
- ラズパイ側でやるやり方と、クラウドでやるやり方がある
- Google Cloud IoT Core
- Cloud Pub/Sub
- Kubernetes Engine
- Cloud Machine Learning
- デモ : TensorFlow で物体検知
- 1秒に1回クラウドに送っている
- クラウドで学習するメリット
- 集合知を活用できる
- Smart Shopping Navigator
- カーナビみたいに
- カート履歴、カートアイテム
- ベクトルで表す
- お手軽な時系列分析
- CNN を使う
補足 :CNN(Convolutional Neural Network) : 畳み込みニューラルネットワーク
- 一次元で畳み込み
- 結果をフラット化
- CNN を使う
- MLP で次のアイテムを予測
補足 :MLP(Multilayer Perceptron) : 多層パーセプトロン
- デモ : Smart Shopping Navigator
- Edge TPU
- Google が開発した AI チップ
- 画像認識を圧倒的に早く行う
- クラウドに送っていると時間がかかる
所感
- Web アプリケーション開発が好きで、個人開発などもしていますが、Webで完結してしまい、現実に直接影響を及ぼせない限界のようなものを感じています。（上手く表現できないですが・・・）
- そのような意味で、IoTも注目している分野の一つです。さらに機械学習も組み合わせるということで、非常に面白いセッションでした。知識不足で理解できない箇所も多く、勉強していくモチベーションになりました。
Cloud Firestore でスケーラブルなアプリケーションを開発しよう
9月 19日 水曜日 6:40–7:20 PM ザ・プリンス パークタワー東京 | Room 04
- アジェンダ
- Cloud Firestore 入門
- 新機能
- 共通のアーキテクチャ
- デモとコード
- スケーリングのヒント
- Firebase Hosting, Cloud Firestore, Firebase Auth, Cloud Functions
Cloud Firestore 入門
- 小さなチームで大きな成果
- 強力かつシンプル
- サーバーレスのデータベース
- アプリ + クライアントSDK
- 直接操作できる
- サーバー側のクライアントライブラリにも対応
- Cloud Firestore と以下のサービス間で連携可能
- Compute Engine
- App Engine
- Cloud Functions
- Kubernetes
- あらゆる言語をサポート
- Cloud Firestore と以下のサービス間で連携可能
- 使っていない時は一切課金されない
- 構造化可能、クエリが簡単
新機能
- 新たに対応予定のロケーション
- 特定リージョン : 東京、日本
- Datastore モード
- 次世代（3世代目）の Cloud Datastore
- 既存の API とクライアントライブラリをサポート
- 強整合性
- 99.999%の可用性
- 既存のユーザーは全てアップグレード対象
- Cloud Firestore のモード
- Datastore モード
- 種類とエンティティ
- サーバー側 NoSQL データベース
- ネイティブモード
- ドキュメントとコレクション
- Backend as a Service
- Datastore モード
- 特定リージョン
- 99.99% の可用性(SLA)
- Cloud Storage にエクスポート
- インポート も可能
- BigQuery 内にインポート
- Cloud Console によって設定及び管理できる
アーキテクチャの構成例（事例）
- Guesswork
- 新規ユーザーにレコメンド
- eコマース
- Google Tag Manager
- Cloud Firestore
- Cloud Functions
- BigQuery
- Cloud Functions
- Cloud Vision
- Cloud Functions
- Cloud Firestore
- リアルタイム
- Hawkins Dynamics
- スポーツサイエンス
- IoT
- スマホとBluetoothで同期
- Firebase Auth => Cloud Firestore => Cloud Function がトリガー
- Nerdery と Google
- Google Cloud Next '18 in Tokyo のアプリ
スケーリングのヒント
- 覚えておくべき性質
- 書き込みのスケーリング
- トラフィックが増大すると、書き込みはどのように変化するか？
- トラフィック増加
- 5 分毎に 50% ずつプラスする
- 同時接続
- 100万件まで
- 書き込みのスケーリング
所感
- アプリから直接操作できるという感覚は、触ってみないとわからないと思うので、時間ができ次第触りたいと思います。
- 使っていない時は一切課金されない、というのはすごいですね。
- 東京リージョンも対応予定ということで、待ち遠しいところです。
- 可用性もマルチリージョンで99.999%、特定リージョンで99.99%とかなり高い印象です。
Firebase 入門、低コストで迅速な開発を行うには？
9月 20日 木曜日 2:40–3:20 PM ザ・プリンス パークタワー東京 | Room 02
内容
- なるべくドキュメントにない話
- gifted.ninja
- Firebase Japan User Group Co-Founder
アジェンダ
- 概要
- 技術概要
- コスト、コンプライアンス
- 移行方法
- まとめ
Take-home message
- 保守/改良系はとりあえず使ってみるべし
- 開発系も多くの場合便利
- Firebase は今後世界を席巻する
概要
- 不向きな成果物
- アクションゲーム
- リアルタイムといっても、数百ミリ秒、1,2秒
業務系・研究系の分析ツール- 複雑なクエリ・複雑なデータ取得は苦手だった
- が・・・BigQuery にインポートするのが簡単になった
- BigQuery は機械学習が簡単になった
- このデメリットはなくなった
- アクションゲーム
- 開発しやすい成果物
- チャット
- 十八番
- SNS
- データ構造は多少複雑にはなる
- 戦略ゲームなど、アクション性の低いもの
- 個人管理ツール
- ソーシャル性を持たせると向いているかも
- TODO とか
- メディアアプリ
- テキストじゃなくても扱える
- チャット
- 活用事例
- Evernote
- クックパッド
- 某全国放送テレビ局
- TED
- Trivago
- etc...
- 最近の盛り上がり
- 右肩上がり
補足 :恐らく Google Trends のグラフを表示されていたと思います。すべての国,過去5年間でfirebaseで検索すると、たしかに右肩上がりでした。
- Google Cloud Platform Compute Options Decision Tree
- GCP でどのサービスを使ったら良いのか、フローチャート表示してくれている
補足 :Google Cloud Platform Blog: Choosing the right compute option in GCP: a decision tree の図だと思われます。- mobile/HTML5 developer には、いきなり Firebase が推奨されています。
技術概要
- 古典的な設計
- アプリケーションサーバー + DBサーバー
- ロードバランサー、管理
- アプリケーションサーバー + DBサーバー
- Firebase の設計
- Firebase のみ
- mBaaS
- 処理はクライアント側で行う
- シンプルなアーキテクチャになる
- 性能や実用性も問題ない
- 機能
- 公式サイト -> 「プロダクト」
- 開発系
- db, 認証, 機械学習, サーバー側処理等
- db
- realtime database, firestore
- サーバー側処理等
- cloud functions
- db
- db, 認証, 機械学習, サーバー側処理等
- 保守系
- エラー・性能監視, テスト
- crashlitics, parformance~~
- エラー・性能監視, テスト
- 改良系
利用統計・予測 (GA for firebase, predictions), 通知(cloud messaging, in app messaging)
- in app messaging
ディープリンク
- アプリの中の特定の画面に飛ばす
- Danamic links
- A/Bテスト等
- A/B testing
- 言語
- 公式サイト -> 「ドキュメント」
- クライアント側
- Web(JS), iOS(Swift, Obj-C), Android(Hava), Unity(C#), C++
- サーバー側
- Node.js, Java, Python, Go, .NET(C#)
- 非公式で PHP, Ruby
- 歴史
- 2011 創業
- 2012 サービス提供開始
- 2014 Google が買収
- 2017 twitter のいち部門を買収、Cloud Firestore ベータ公開
- Google の技術
- 機械学習で消費電力を大きく削減（データセンターの）
- インフラのプロがチューニングしたところから更に40%
- The Datacenter as a Computer
- Google社内では Datacenters as a computer とも言われ始めている
- ライブマイグレーション
- サーバーを動かしたまま別のマシンに移し替える
- インフラの更新、メンテナンスに役立つ
- 普通なら一瞬途切れる
- サーバー同期が本気すぎる
- 原子時計をそれぞれのデータセンターで使用
- 機械学習で消費電力を大きく削減（データセンターの）
- Cloud Firestore の技術
- Spanner
- Cloud Spanner もある
- SQL が使えるのに、トランザクションもマルチリージョンで使える
- Cloud Spanner もある
- マルチリージョンでのトランザクション
- 原子時計を利用して実現
- 性能劣化なし
- 元データが100でも1億でも同じ
- 遅いクエリを書くことは不可能
- Spanner
- もはやシンギュラリティと言えるのではないか
- 簡単安価かつ実戦投入にも耐えうるパラダイムシフト
- Google, 2009年のシンギュラリティ大学の設立にも関与
コスト、コンプライアンス
- コスト
- 公式サイト => 料金
補足 :https://firebase.google.com/pricing/?hl=ja- シュミレーターもある
- 総合的は安くなるはず
- 古典的
- フロント、バック、インフラ
- 意思疎通コスト、保守コスト、誤操作リスク
- 2人になっても1.5倍とか
- 30万 x 4 + 保守コスト
- Firebase
- フロントのみ
- 公式サイト => 料金
- 法律・プライバシー
- 「firebase プライバシー」で検索
- GDPR 対応ガイド
- 個人データの扱い方の透明化
- データの保管場所
- セキュリティなどの規格
- 「firebase プライバシー」で検索
移行方法（開発系）
- db のデータ構造の違いやルール設定に注意
- 独自のセキュリティルールがある
- 小・中規模なら一度に置き換え
- 大規模なら徐々に
- クライアント主導ではない方が良いと思われる
- クライアント主導
- クライアントがサーバーにアクセスする度に firebase に移してもらう
- サーバ主導
- サーバー側で一気にデータを移行してしまう
- こちらのほうが楽なのでは
- クライアント主導
- ログイン連携まわりは各々で認証するのが良さそう
- サーバー側で連携
- 各々で認証
- クライアントでログインし直してもらう
- クライアント主導ではない方が良いと思われる
まとめ（Take-home message）
- 保守/改良系はとりあえず使ってみるべし
- 開発系も多くの場合便利
- アクションゲーは苦手
分析計は苦手- firebase は今後、世界を席巻する
- firebase.asia
- gifted.ninja
所感
- Firebase を使っていく上で必要なことを丁寧に説明してくださり、とても良いセッションでした。
Firebase は今後、世界を席巻するというのは、実際に使った方ならではの言葉だと思いました。- 採用事例も増えてきている。
- 個人的には使っていきたい！
Web API の育て方：駅すぱあと Web サービスでの Apigee 適用事例
9月 20日 木曜日 4–4:40 PM ザ・プリンス パークタワー東京 | Room 03
- アジェンダ
- API エコノミーと API 管理
- Web API の育て方
API エコノミーと API 管理
- API エコノミーとは
- 企業が自らのビジネスをAPIとして公開し、それらを互いに活用していくことで、新たな価値を生み出しながら広がっていくデジタル経済圏
- API エコノミーの例
- ライドシェアサービス
- 他社APIを活用して自社サービスを迅速に構築
- APIを提供して他社サービスからの利用を促進
- ライドシェアサービス
- API のライフサイクル
- 構築、利用、運用
- API 管理とは
- フロントアプリ - API管理基盤 - バックエンドシステム
- Apigee API Platform
- セキュリティ
- 認証認可、量料制御
- 運用管理
- モニタリング、アナリティクス、課金
- 使いやすさ
- I/F変換、キャッシュ、開発ポータル
Web API の育て方
- アジェンダ
- 「駅すぱあとWebサービス」について
- Web API 成長の推移
- ファーストリリース
- ...
「駅すぱあとWebサービス」について
- サービスの特徴
- API へのアクセスに課金するビジネスモデル
- 交通費申請等のシステムに組み込んで使われることが多い
- 自社のスマホアプリ等のバックエンドとしても利用
ファーストリリース
- ポイント
- あまり人手をかけない
- 実装と運用が容易な方法を選ぶ
- 中核となる機能から公開
- 想定ユーザーを絞る
- 既存の法人顧客
- 自動化に固執しない
- 簡易的な認証・集計システム
- 独自実装
- キー発行は手動
- 課金も手動
- つまり、スモールスタート
- ただし、APIの公開仕様は安易に決めない
- わかりにくい・使いにくい仕様は、サービスの開発・運用負荷を下げる
- 拡張性に乏しいデータ構造だと機能追加がしにくくなる
- こうかいして利用が増えてくると、使用の大きな変更が難しい
- あまり人手をかけない
- 開発メンバー3名、規格１名、営業数名
- 全員兼任
- 開発期間は半年
- 開発メンバー3名、規格１名、営業数名
- 容易な方法を選ぶ
- 社内向けの XML RPC サーバーをベースに開発
- RESTful 風 Ruby のラッパー
- 社内向けの XML RPC サーバーをベースに開発
インフラ整備と不足機能開発
- ポイント
- 運用してみてツライ部分から整備する
- 不足している機能のうち一般的なものから実装する
- 再実装もいとわない
- ツライ部分から整備する
- オンプレからクラウドへ
- 再実装もいとわない
- Cで再実装（XML RPC サーバ と同じ？）
- 実装上の問題によりレスポンスが思い問題への対応
- Ruby と XML RPC サーバ のやりとりに時間がかかる
- 外部連携のみ Ruby
- Cで再実装（XML RPC サーバ と同じ？）
- その影で
- API 管理面はそのまま
機能拡張
- 認知度を高める
- ドキュメントの公開
- ハッカソン等への Web API の提供
- エバンジェリスト活動
- 運用・対応の手間を減らす
- ドキュメントの見直し
- ユーザーがわかりやすく、戸惑わないように
- 最初は自動生成だった
- プロジェクトチームによる継続的な改善
- 開発メンバー以外も入る
- 結果としてサポート対応の手間を削減
- ユーザーがわかりやすく、戸惑わないように
- ドキュメントの見直し
- 競争力強化に注力する
- 外部サービスを利用する
- 監視、ステータスページ
- API 管理
- 外部サービスを利用する
- API 管理面の強化
- 運用不要
- 使いやすさ
- 設定の自由度
- 201806 に Apigee を導入
- Apigee
- 公開仕様の変更化起きないようにできる
- API のコール数に応じた収益がないと、API管理サービスの費用と釣り合わない
まとめ
- API 管理サービスの適用は早くて良い
- 手動のオペレーションが肥大化すると、簡単に移行できない
所感
- Apigee の話というよりは、一般的な Web API の話でした。
- 最初は人手も時間もかけず、後から再実装は厭わない、という姿勢が印象的でした。
Cloud Dataflow を利用したサーバーレスデータ処理
9月 20日 木曜日 5:20–6 PM ザ・プリンス パークタワー東京 | Room 03
超巨大データセットをどう処理してきたか
- 1TB のデータを同処理してきたか
- 2000 年
- 大きなマシン、SANストレージ付属
- 2004 年
- 多数の小さなマシン、ローカルストレージ
- Linux
- 多数の小さなマシン、ローカルストレージ
- 2000 年
- クラウドに移行していった
- Dremel コンセプトを基にした BigQuery をリリース
- BigQuery におけるストレージコンピューティングとシャッフル
- シャッフルとは？
- 分散されていないデータ要素
- ゴール : キーでデータ要素を整理
- 複数のデータノードがあると、メモリでソートできない？
- シャッフルプロセス
- バッチ Cloud Dataflow パイプラインのライフサイクル
- ノードクラスタの作成
- ソースから読み取り
- データ変換を動作
- Cloud PD でのシャッフル
- BigQuery と一緒
- 永続デスクを使う
- Sinks に書き込み
- クラスタをシャットダウン
- Dataflow 内で分散型インメモリシャッフルを使用
- Dataflow Shuffle
- プロキシのシャッフル
- 分散型インメモリファイルシステム
- 分散型オンディスクファイルシステム
- ユーザーは気にしなくて良い
- 開発者が唯一やること
- パイプラインパラメータの指定
- Dataflow Shuffle
- Cloud Dataflow のメリット
- より早い処理
- チューニング不要
- Dataflow Shuffle は通常、ワーカーベースのシャッフル(SSD - PD 利用者を含む)より高速
- 大きなデータセットのサポート
- 100TB以上のシャッフル
デモ
- 100TB サイズのデータセット２つを join する
- 2つのデータセットが join するパイプライン
- GCS => join => GCS
- Cloud Dataflow にシャッフルモードをパラメータで指定する
- 8時間くらいかかる
- 1000ワーカーまでオートスケール
ストリーミングパイプラインとは？
- 状態を格納する
- ストリーミングシャッフル
- ストリーミングパイプラインのライフサイクル
- Pub/sub
- ウィンドウ
- Group by
- カウント
- BigQuery
- ストリーミングデータは常にキーによって区分される
- PD ボリュームがキーの状態ごとに格納
Dataflow ストリーミングエンジン
- 自動スケーリングをスムーズに
- 状態を持っていなので、変更が容易
まとめ
- Cloud Dataflow でのコンピューティングからのステートの効果的な分離のための分散型シャッフルキー
- バッチ パイプラインのシャッフル
- 高速動作
- 大きなデータセットも対応可能-
- ストリーミングパイプラインのためのストリーミングエンジン
- より良い自動スケーリング
- 容易なメンテンナンス
- 東京リージョンは comming soon
所感
- 頑張ってメモは取りましたが、仕組みの話は正直あまり理解できませんでした・・・。こういう時、コンピューターサイエンスを専攻していなかったコンプレックスを感じます。
- 異なるデータセットから大量のデータを結合できる、と理解しました。様々なサービスを利用していく流れの中で、かなり需要があるソリューションなのではないか、と思いました。
おわりに
イベントに参加できなかった方や、聞きたいけど聞けなかったセッションがある方などにとって、この記事が少しでもお役に立てば良いな、と思います。
私がセッションに登録しようとした時点で、既に満席のものも多く、他にも面白そうなセッションがたくさんありました。
今回参加できなかった方も、ぜひ来年は検討されてみてはいかがでしょうか。
