Google Cloud Next '19 参加レポート

Google Cloud Next ’19

  • 基調講演 1日目

    • DeNA
      • 2015年- クラウド利用
      • 2018年 クラウド vs オンプレ
      • オンプレでは管理とかしんどい
      • クラウドを使い倒すことでコストダウン
        • オンプレでの場合のコストに近づける
      • クラウドの導入により人材を創造的な仕事にフォーカス
      • オンプレサーバーの管理は無駄な時間を取られる
      • サーバーの知識の蓄積があるからカタログスペック以上のことを要求
      • 分析的エンターテインメント
        • BigQuery
      • Pokemon Mastersは全てクラウドで開発
    • メルペイ
      • 年間で5000億円
      • 15ヶ月でサービス展開 (2017年11月創業)
      • 金融関連事業のメルカリとの統合
      • マイクロサービス化
      • k8sエンジンを採用
      • Cloud Spannerでスケーラビリティ
      • 信用を想像して、なめらかな社会を創る
    • アクセンチュア
    • ゼロバンク
      • 福岡フィナンシャルグループの戦略部門的な子会社
      • 次世代のバンキング
      • GCPをフル活用したMAINRIがベース
      • 東京ー福岡でアジャイルな研究開発
      • CloudSpannerによる分散データ処理
    • Gungho
      • mspo : GCPによるモバイルサービス
      • 初めてRDBMS以外のデータサービスを採用
      • BigQueryでデータを素早く集積
    • Anthosについて
      • 仮想マシンに自動的に移行する
      • セキュリティなどを一元的に管理することができる
      • マルチクラウドでも一貫性のある環境
      • モダナイズを簡単に、仁宗に
    • NTTコミュニケーションズ
      • Anthosを最初に利用
      • Enterprise Cloud
  • 三越伊勢丹における統合リアルタイム

    • テーマ: おもてなし×デジタル
    • お客様にとってより快適で最高な体験をどう実現しようとしているか
    • 現在
      • ビジネスモデルの革新
      • オンラインでもオフラインでも最高の顧客体験
      • 店舗とEC
      • ニーズを的確に捉え、最適な情報を届けることで自身のプラットフォームへ誘導する方法の確立
    • これまで
      • 顧客データ
        • クレジットカード
      • 購買データ
        • POS
      • 顧客分析(誰に)
      • 商品分析(何が)
      • MD・販促の重心≒取得データの密度
      • 購買データだけの分析では客のニーズを理解しているとは言えないのでは?
      • デジタル化されたデータ、すぐ活用できる状態の情報が圧倒的に少ない
    • 現在
      • データをまとめる
        • ファイル伝送からETLへ
        • GCPを新たな分析基盤として構築
          • Cloud Storage
          • BigQuery
      • データをとる
        • BigQueryがゼロベースで使えるよさ
      • データを活用する
        • 機械学習を活用したDM宛先抽出
        • セグメントを意識したメール出し分け
        • KPI可視化ダッシュボード / ビジュアライズ
      • 課題
        • 組織、ロール、スキルセット
        • 目的が先か?仕組み/データが先か?
        • リテラシー
    • これから
      • 顧客にとって”百貨”とは?
      • 顧客は本当に欲しいものに出会えているか?
        • 情報が多すぎて見つけられない
        • 欲しい商品のイメージが湧かない
        • 信頼できるアドバイスが欲しい
      • 柔らかい顧客ニーズをスムーズに具体化
      • サービスのバランスの見極め
        • UXとCX
      • 顧客の購買意欲の変化を捉える
        • 顧客のタイミングに合わせるとなると、必然的にリアルダイム性が求められる
      • マーケティングにおける優先度の変化
        • 顧客中心
  • ファイルのセキュリティ

    • 自社にとって最も脅威となる事象は?
      • 標的型攻撃による情報漏洩
      • ランサムウェア
      • 内部不正による被害、情報漏洩や業務停止
    • 実際起きた事件
      • 電子メール等の誤送信
        • 添付ファイル付きメールの誤送信
      • 情報機器の紛失など
      • 暗号化ZIPファイル?
        • パスの別メール送信は効果的?
        • 暗号化は十分な強度?
        • 他人は信用できる?
    • ファイル共有はGoogle Drive
      • 管理者権限で色々できる
  • アサヒビール

    • 市場ニーズに早くたどり着きたい
      • データ・ドリブンであり続ける
    • ニーズのサイクルの短期かと多様化
    • 様々なデータを活用して小売向けに最適な棚割を提案したい
    • オンプレの管理にコストかかりすぎ
    • SaasとPaaSのみで構築、インフラ運用がほぼゼロ
    • 軽く緩いアーキテクチャ、ニーズに応じて変更可能
    • 利用している技術
      • BigQuery
        • バッチ処理のために利用
        • ビジネスに必要な状態に一括処理
        • マシンスペックを決めたりする手間がない
        • チューニングいらず
      • Kubernetes Engine
        • 全ての処理をマイクロサービス化
        • 追加改修に柔軟に対応
        • Kubernetesを自前構築するのはきつい
        • Stackdriverとの相性が良い
    • AKSからGKEへ
      • コスト
        • 処理ごとに適切なマシンスペックで処理させる
      • スピード
        • 機能追加のスピードが早い
      • 将来性
    • 移行方法
    • なぜGKSか?
      • なぜコンテナか?
        • 軽量
        • ポータブル
        • 効率性
          • リソース使用量が少ない
      • Kubernetesクラウドネイティブ時代の新しい基盤
        • 関心事の分離
        • 基盤運用は自動運転
        • アプリケーションデプロイ期間の短縮
      • GKEの特徴
        • 2015年にGA
        • 容易に利用可能
        • 昨日の充実
          • 足回り
          • ネットワーク
          • セキュリティ
      • GKE On-Prem
        • Anthosの関連でのサービス
        • オンプレミスでもGKEを使える
      • 今後の展開
        • Kubernetesはプラットフォームのためのプラットフォーム
        • Kubernetes -> GKE / GKE On-Prem
        • Istio -> Cloud Service Mesh
  • Stackdriver

    • SREはDevOpsの実践方法
    • Site Reliability Engineering
      • 意思決定にデータを用いる
      • 運用の課題をそ風呂ウェアエンジニアリングで解決
        • スケーラビリティ
        • 信頼性
          • 効率
    • SLI, SLO, SLA
      • Service Level Indicator
      • Objective
      • Agreement
    • エラーバジェット
      • SLOを高く設定してしまうとシステムの改善に手が回らない
    • ユーザーの幸福度の向上
    • SREで使うデータをどう確保するか
      • オブザーバビリティ
        • システム運用において判断に必要な情報が取得できる状態である
        • テスト、パフォーマンス、使い勝手
    • アプリケーション メトリクスの重要性の増加
      • Applicaiotion Performance Management
        • カスタムメトリクス
        • プロファイラー、
        • 分散トレース、
        • サービスメッシュ
      • 従来のモニタリンングで見ていた範囲
    • Stackdriver製品群
      • 最小限の実装でオブザーバビリティを提供
      • 障害対応用のダッシュボードも提供
      • GCPAWSに対応
    • 運用プロセスで必要なデータ
      • 通常運用
        • 全体間のわかる統計データ
        • メトリクス
          • 統計的に全体が問題なく動いているか
          • Stackdriver Metrics
        • アラートの設定
          • SLO違反が発生した場合の対応
      • 高負荷・調査
        • プロファイラ
          • CPU, メモリ, OSのメモリ
        • 分散トレース
          • マイクロサービスで強い
      • 障害対応
      • 振り返り
    • 概要
      • プラットフォームしか提供できない情報
      • STRの実践の共有
      • 他のGCP製品との連携
      • プラットフォームとしてオブザーバビリティを提供し、ユーザーの幸福度を高める
  • ゲノム解析

  • グローバル企業の集まり

    • Google
      • 標準化is最適化
    • Twitter
      • 情熱を持って構成を考える
    • LT
      • プレイド
        • KARTEというサービス
        • 開発者という人を見る
        • GCPを使い始めた理由
          • コスパ
            • スタートアップとして嬉しい
            • イベントが増えても大丈夫
        • まだ使い続ける理由
          • 技術者(Googler)が素晴らしい
            • 圧倒的ユーザー志向
            • 顧客が本質的に欲しいものを与える
      • BizReach
      • Ubie
        • 医療系でAI問診
        • GCPへの移行理由
          • マイクロサービス
            • Kubernetesで柔軟にアプリケーションを動かす基盤構築
      • トレタ
        • データ分析基盤の構築方法
        • SQLが書けなくても自分でデータ分析ができるようなBIツールを導入
      • ZOZO
        • BigQueryのAmazon S3 Transfer
        • AWSのAthenaよりもBigQueryが速い
        • Amazon S3のデータ転送料金が意外と高いので注意
      • DMM
  • 基調講演

    • ジョン・ジェスタ
      • 顧客体験を支える5つの柱
        • プロフェッショナルサービス
        • サポート
        • ラーニング
        • カスタマーサクセス
        • カスたらー&パートナーエクスペリエンス
      • Your success is our success
    • ファミマ
      • ファミペイをダウンロードしておいて
      • 実態把握
        • ブレスト2000会長
        • 課題に対しては徹底的に協議し改善へ
      • 改革の断行
      • G Suite
        • 動画や写真を中心にコミュニケーション
        • 社内SNS
      • 地域密着
        • デジタル化の中で人と人のふれあいが強く求められる
    • エイミー・ローキー
      • UX
      • Voice
        • クラウド通信サービス
        • 管理者向けプロビジョンサービス
        • 日本に導入予定
    • 小林
      • Gmail+Hangoutのチャットルーム
        • ファイルのアクセス権などが簡単
        • リアルタイムに確認可能
    • 日本商工会議所
      • 中小企業で組織されている
      • 人手不足
      • 生産性向上のためにITを使う
        • IT人材がいない
        • 資金がない
        • サイバーセキュリティによる脅威
      • 低コスト・専門知識不要・セキュリティ・使いやすさ
      • クラウドで日本全体をひとつに
      • 中小企業への取り組み
    • ウルス・ヘルツる
      • データセンターに5兆円以上を投資
      • お客様のデータはお客様のもの
    • G Suiteのサービス
      • Cloud Data Fusion
        • オンプレ、クラウドのいずれのデータソースとも接続可能
        • データベースからBigQueryへの移行を滑らかに
      • Connected Sheets
      • AutoML
        • コードレス
    • Asahi
      • 期待を超えるおいしさ、楽しい生活文化の創造
        • 様々なデータを活用して市場ニーズ・変化よりも早く答えに辿り着く
      • 課題
        • オンプレミスの既存システム運用コストが負担
        • 投資できるお金が少ない
      • BigQueryの導入
        • サーバーレスで使った分だけ
        • 10TB程度のRAWデータを一瞬で処理
      • Kubernetes Engine
        • 処理を全てマイクロサービス化
        • 市場ニーズの変化に柔軟に対応可能
        • コンテナ導入で市場の一歩先に
      • SORの再定義
    • 博報堂
      • テクノロジーソリューションの開発・提供に注力
      • データ・マネージメント・プラトフォーム
        • 国内最大級のオーディエンスデータ
      • データの統合
      • 生活者データ・ドリブンマーケティングの開発や実践における今日的な課題
        • 生活者のより深い理解
      • メッセージング管理ソリューション
      • 安全で健全なマーケティング施策の実行
      • 広告体験
    • SOMPOホールディングス
      • デジタルディスラプション
      • SOMPO Digital Lab
        • アジャイル開発チーム
        • Digital Sandbox
        • Firebase&Cloud Rynでスマート介護システム
  • リクルート

    • hacciとは
      • リクルート車内で開発したパイプライン基盤
      • 特にデータの種類に制限なし
      • ログ収集?
    • hacci構成
    • hacciを支えるマネージドコンポーネント
      • 利用しているコンポーネントは全てマネーいjど・スケーラブル
      • 運用がとても楽
    • 言語
    • 監視
      • Stackdriver Logging/Monitoringによるメトリクスの監視・アラート制御
      • SlackでGoogle Cloud Status Dashboardの情報を取得・検索を可能に
    • hacciにおける開発・運用
      • Web API
        • Cloud Functions
          • コストをかけず
          • スピード感でプロダクトの価値を検証
        • Firebase Hosting + Cloud Functions
          • カスタムドメインで内部を隠蔽
          • Cold Start PubSub同期処理がネック
        • GKE
          • パフォーマンスと自由度を追求
      • Dataflow
    • ———
    • 機械学習を用いたビジネス改善の事例
      • Airシリーズ
        • お店の業務を手伝いをするサービス
        • 商うを自由に
      • 業務システムの導入はクライアントも負荷が大きい
      • データを用いてCSのセオリーに合わせた運用を行っていた
      • マーケティングにより利用を始める店舗が増加
        • サポートに必要なリソースの増加
        • 機械学習を利用
          • 誰をサポートするか
          • 人間がルールを考えて優先順位をつけるのはきつい
        • 実現性?
          • 機械学習基盤の用意
          • データサイエンティストのアサイ
          • モデルの試行錯誤/ビジネス知識の反映
      • データはあるが分析基盤なし
        • BQMLがいいのでは
      • サポート対象の優先順位づけを実現
      • サポートを絞りながら導入率のキープ
      • 同種のデータプロダクト案件への事業内での興味が高まる
      • 結論 : 自分たちでやることが重要
        • データサイエンティストに任せたりしない
      • サイエンティストに重要な案件に集中してもらうためにBiz自身でやるべきところをやることは必要
      • その際にサイエンティストと同じレベルを目指すのではなく適したツールを採用することも必要
  • サーバーレスコンピューティング

    • App Engine : ウェブアプリ
      • PHP7, GO, Node.js, Java11, Ruby2.5
      • アップグレードされたやつが提供される
    • Cloud Functions : 軽量関数
      • イベント駆動型のサーバーレスコンピューティングプラットフォーム
      • Python3, Node8, 10, Go, Java8
      • サーバーレスVPCアクセス
      • IAMの細かい設定が可能
    • Cloud Tasks
      • 非同期タスク実行
      • ポイントtoポイントのタスク実行
      • 動的スケジューリング
      • 動的HTTPターゲット
    • Cloud Scheduler
    • 次の一手
      • サーバーレス
        • ソース主導
        • NoPos
        • 使用量に応じた課金
      • コンテナ
    • Cloud Run
        * サーバーレスコンテナ
        * コンテナ化されたアプリケーションでサーバーレスのアジリティ
        * コンテナから本番環境までを数秒で
        * ネイティブなサーバーレス
        * 環境に依存しない
        * インスタンスのConcurrency
            * 非同期処理が行けるね
            * 従来型モデルはサーバーレスではない
            * 通常、サーバーレスモデルはConcurrencyは1
            * 効果
                * コールドスタートの減少
                * 迅速なスケールアップ
                * 使用率の向上
            * コード変更が必要なケースもある
                * デッドロック?
      
      • Knative
        • Kuvernetes&Istio
        • Build
  • 働き方改革と地方創生

    • Smart Workチームとしての取り組み
      • リモートワーク支援サービス
      • コミュニケーション支援デバイス
      • テレワーク文化情勢への取り組みと情報収集
      • わーケーション・リゾートテレワーク
    • なぜ働き方改革
      • 働き方改革の文脈を理解することは今後のビジネスおよびソリューションの検討に大きく役立つ
      • 大前提としての「人口減」
      • 高齢者の就労機会
      • 多様性の尊重
      • 子育てしやすい環境
      • 持続可能な働き方へのシフトが必要
    • ICTの進化と働き方の変化
      • フラットな組織で自律分散協調的に処理をラリー
      • スマホとPC
      • 事務処理はソフトウェアが代行
      • 電子化して持ち歩きしてどこでも仕事
      • 情報化による人の価値観の変化
        • 閉鎖的から開放的へ
        • 個人の尊重による共同参画社会
      • 技術的側面 + 文化的側面 = 働き方改革
    • テレワーク
      • 要求
        • コスト
        • グローバルな人材獲得
        • BCP
        • 通勤時間
        • 育児介護
        • 居住地
      • 求められる体制・リソース
        • プロジェクト毎のアドほくな人員配置とリソース
        • コンテキストの低い仕事、非属人化
        • 車内リソースのACLの見直し、クラウド
      • テレワークでサボる奴はオフィスでもサボる
    • ワーケーション = Work + Vacation
      • 仕事と休暇の融合
      • 地方における関係人口の増大
      • 東京一色集中の回避
      • 知的生産性の向上
      • チームビルディング・ロイヤリティ
    • 地方創生
  • 機械学習モデルの開発

    • 再利用できる機械学習関連アセット
      • TensorFlow Hub
      • Seedbank
    • 機械学習をモデルをもっと簡単に作れるように
      • 知る、試す、作る
    • Cloud AI Platformでモデル開発を効率化
      • 全体像
        • 機械学習モデルの開発者がプロジェクトを効率的に遂行するために必要な機能を提供
          • 準備 - ラベリング、前処理
          • 開発 - データ分析、各種実験、最適化
          • 運用 - 学習済みモデルのデプロイ、パイプライン構築と自動化
          • 連携 - アセット共有とコラボレーションの促進
    • 知る : AI Hub
      • 機械学習アセット発見
      • ワンストップのアセットカタログ
      • ワンクリックデプロイ
      • アセットの組織内共有
    • データ分析と実験におけるポイント
      • インタラクティブな実験環境
      • データ分析や各種実験に必要なライブラリの準備
      • オンデマンドに構成変更できる計算機リソース
    • 試す : AI Platform Notebook
      • データ分析や各種実験に必要なライブラリ
      • 計算機リソース
        • オンデマンドに構成変更できる
          • CPUやGPUなどを自由に変えられる
      • R + BigQuery
      • 様々なアイデアを効率良く試す
        • KubeFlow Fairingによる並列実行
          • モデルをトレーニングするクラスや関数を定義
          • 実行するクラスや関数、実行環境を指定
          • モデルトレーニングを実行するコンテナを作成
          • モデルトレーニングの実行
    • 作る : AI Platform Training
      • 最適化におけるポイント
        • 最適な計算機環境
        • ハイパーパラメータチューニングの自動化
        • パイプラインへの組み込み
      • 機械学習モデルのトレーニングのを効率化するマネージドサービス
        • GPU/TPU
        • ハイパーパラメータのチューニングを自動化
        • アイドル状態のインスタンスには課金しない
        • コンテ化したトレーニングジョブを実行可能
        • メンテナンスイベントが発生してもチェックポイントから再開可能
      • Custom Container Supportで任意のフレームワークがオッケー
      • 動作
      • ハイパーパラメータチューニングの自動化
        • ベイズ最適化によるパラメータ探索
        • トライアルの多重化による探索時間短縮
        • Early stoppingによるコスト効率化
      • パッケージをパイプラインに組み込む
  • Cloud Spanner in Action

    • 概要
      • Cloud Spannerとは
        • リレーショナルデータベース構造
        • 水平方向のスケーラビリティ
      • 特徴
        • リレーショナルデータベース
        • 水平方向のスケールアウト/いんが任意に実施可能
        • フルマネージドかつ計画的なダウンタイムなし
        • 業界最高水準のSLAを提供
          • リージョナル99.99% / マルチリージョン99.999%
        • リレーショナルと非リレーショナルのメリットをトレードオフなく提供
      • アーキテクチャ
        • Node
          • 読み書き処理
          • 本番では3ノード以上を推奨
        • Split
          • Cloud Spannerにおけるデータの単位
          • テーブルのデータ等はこのSplitに自動的に分割
        • NodeとSplitは各ゾーンに作成、レプリケートされる
        • Split毎に担当するNodeが決まっている
          • Nodeは対象Splitにあるデータの読み書きを行う
          • NodeがどのSplitを扱うかは自動で設定
          • この関係は固定でなく動的に変更される
      • スケール
        • コンピュート
          • Nodeを追加することで処理能力を上げられる
        • ストレージ
          • データの増加に合わせてSplitを自動的に分割
          • ストレージの追加はNodeの追加で行う
        • ReadだけでなくWriteも水平にスケール
        • Splitとホットスポット
          • データの追加は常に最後のSplitに対して行われる
          • 防ぐ
            • 主キーの選択が重要
            • 単調増加/減少する値を主キーに使用しない
            • 十分に分散する値を主キーに使用する
          • 主キーの選択による性能の違い
    • インデックス
      • Cloud Spannerのセカンダリインデックスはテーブルとして実装
      • データ
      • セカンダリインデックスの使用
        • SQLで自動でやってくれる
      • セカンダリインデックス
        • 典型的なリレーショナルよりも効率的ではない
          • 事実上ベーステーブルとのinner join
        • インデックスの作成は必要最低限に抑えるべき
        • 様々な要素があるためそれらを考慮する必要がある
    • エクスポート
      • 流れ
        • Cloud Spanner -> Cloud Dataflow -> Cloud Storage
      • 方法
        • コンソールから
          • Cloud Storageの選択
          • エクスポートするデータベースの選択
          • Cloud Dataflowのジョブを十国するリージョンの指定
            • Cloud Spannerと同じリージョンを選択することでオーバーヘッド削減
          • 定期実行
            • Cloud Consoleからの実行(難しい)
              • Spanner
              • Dataflow
            • コマンドからの実行
              • gcloud
            • APIからの実行
              • Cloud DataflowのAPI
            • Cloud Composer
              • airflow.contrib.operators.dataflow.operator.Dataflow.TemplateOperator
      • モニタリングツール
        • 高優先度ユーザータスク
        • 高優先度システムタスク
          • インデックス作成やデータスプリッド処理
        • 程優先度ユーザータスク
          • バッチReadやバッチクエリの処理
        • 程優先度システムタスク
          • データベースコンパクションやスキーマのValidation
        • 結果
          • エクスポート処理のあり/なしでそこまで影響なし
          • ワークロードに影響を及ぼさない
    • モニタリング
      • モニタリング/アラーティング
        • ConsoleのSpannerモニタリングタブ
          • CPU使用率など基本的なメトリクスを提供
          • 過去データは事前定義された期間からの選択
            • 最小1時間から最大30日
        • Stackdriver Monitoring
          • キュレーション済みダッシュボード
            • Spannerに関するスループット
            • ストレージ容量
            • インシデント
            • イベント
          • カスタムグラフ
          • アラーティング
      • クエリの分析
        • 統計テーブル
          • ビルトインのテーブル
          • 2種類のてーブル
            • 各クエリ毎に集計
            • 全てのクエリを集計
          • 特的の期間におけるクエリの統計情報を保持
            • 平均CPU利用時間
            • 平均実行時間
            • スキャンした平均行数
            • 実行回数
            • etc
        • 実行プラン
          • Cloud Spanner
          • クエリを実行するための手順
        • 関係演算子のツリーとして表現
        • どのクエリが遅いかを分析