Google Cloudで実践するWEBアプリ開発に行ってきた話

Googleさんのイベントに行ってきたので自分の備忘録がてらのまとめです。

概要

1. Webフロントエンド開発最新動向
2. GCPサーバーレスサービス紹介
3. リクルートにおけるWebパフォーマンス改善の取り組み
4. インフラ管理不要のFirebaseとGKEで実現するモバイルアプリ開発

Webフロントエンド開発最新動向

• 2018年でChrome１０週年、Googleは２０週年、WWWは３０周年
• 新興国ではフィーチャーフォンが流行っている
• FCP ( First Contentful Paint )　６sec、TTI ( Time to Interactive )　９secが世の中のWEBサイトの平均
• サイト表示高速化のため、Preload DNSPrefetch Intersection Observerを適用
• 画像最適化CDNの利用で80%の画像サイズ削減事例もあり
• Performance Budgetを定めることが大事
• ex)ユニクロでは、スクリプト80kb以下、全体で２００ｋｂ以下という制約をかしている
• Speed Report(Search Console）
• Light house（WEBのベストプラクティスにどれだけ準拠しているか）
• Light wallet cliで追加された機能
• https://proxx.app/　廉価な端末でもサクサク動くように作ったデモWEBアプリ
• 画面遷移が遅い場合、ユーザーが気持ちよくサイト内回遊するには？
  
  →ナビゲーションからトランジション（予め次ページを読み込みシームレスなトランジションを実現）
• Portals
  
  →となりのヤングジャンプで実装
  
  →あらかじめ画面下に次ページを読み込んでおいて、タップすると表示される
  
  →今後主流になる
• PWA
  
  →oyoというスタートアップ機能がきれいなもの作っている
  
  →Trusted Web Activities(https://developers.google.com/web/updates/2019/02/using-twa)
  
  →デスクトップでもPWA追加出来る時代（hulu) 再訪問率２７％UP　desktop PWA
• 指紋認証
  
  →Web AuthenticationのAPI利用で使える
• Shape Detection API
  
  →QRコードなどオフラインの世界を認識（アクション補助、商品比較）
  
  →https://perceptiontoolkit.dev
• 新たなAPIを段階的に公開予定
  
  →アプリにしか搭載できなかったものをWEBAPIとして機能公開
• https://web.dev/
  
  →これまでの話を機能として公開している
• AMP
  
  →Yahooトラベル採用、トラフィック６０％UP、離脱率−５％改善
  
  →WebPackageing　amp packager or cloudflare
  
  →JSが使えなかった。。。けどカスタムJSを載せられるようにする。これが実現するとAMPでGBレベルのゲームが動かせる
  
  →bit.ly/amp-script-trial トライアル
• AMP Stories(https://amp.dev/about/stories)
  
  →画面全体に動画・画像を出せる
  
  →今年からデスクトップにも対応
  
  →リッチメディアをたくさん持ってるサービスにおすすめ
  
  →Google Searchとの相性もよい
  
  →レシピとトラベルの業界で先行
  
• AMP for Email
  
  →Google Docs対応（replay to comment)
  
  →SendGrid、Sparkpost、amazonpinpoint litmus, gmail,@mail,yahoomailが対応
  
  →YoutubeのAMPチャンネルに最新情報が乗っている

#GCP のサーバーレスサービス紹介

• サーバーレスって？
  
  →インフラ管理をしない
  
  →使った文だけ支払い
• GCPのサーバレスはフルスタック
• Webアプリ開発で考えること
  
  →コンピュート（アプリをどこで動かすか）
  
  →DB
  
  →非同期処理
  
  →静的コンテンツ
  
  →コード管理・ビルド・デプロイ
  
  →モニタリング・ロギング・APM
• コンピュート
  
  →CloudFunction（Function
  
  →AppEngine(Apps
  
  →CloudRun(Container
• サーバレスコンピュート公式使い分けページあるので詳細はそこで
• CloudFunction
  
  →イベントドリブン
  
  →サーバー管理なし、スケールアウト高速
  →ユースケース例、画像アップ（cloudstorage)→関数をトリガ(cloudfunciton)ー→画像のラベリング(cloudvisionapi)
  →追加居所、ランタイム環境管理したくない、サービス関連系
  →制約：関数レベルの粒度、イベント経由
• AppEngine
  
  →管理が容易（０にまでスケールイン・パッチ更新なし）、開発しやすい、サポートランタイム（Java,Python,Go、PHP
  
  →デプロイはブルー・グリーン、カナリア、A/Bテスト
  
  →使い所：ステートレス・急激なトラフィック増が責務
  
  →制約：ランタイム
• CloudRun
  
  →Knative（OSS）k8s 上にサーバレス実行環境を作るもの
  
  →高速なデプロイ（言語・ライブラリ制約なし）、サーバーレスネイティブ（0toNスケールが高速）、高いポータビリティ（ロックイン排除、Knativeの一貫したAPI）
  
  →２種類ある、CloudRunとCloudRunonGKE（k8sのマネジメント版、GKEのクラスタ上でサーバーレス、費用はGKEのクラスタに含まれる）
  
  →使い所：スパイク多い・読めない
  
  →制約：コンテナ必須、ビルドプロセスを決める必要あり
• GCP StorageOptionで検索すると出てくる
• CloudFirestore
  
  →NoSQL、トランザクション使える、ネイティブモード（realtime)、データストアモード
  
  →FirebaseSDKによるサポート（モバイルクライントから直接アクセス可能）
  
  →リアルタイムにデータ同期、マルチユーザ向けのモバイルアプリに最適
• CloudSQL
  
  →いわゆるRDB、Mysql、ポスグレ、SQLサーバーも
  →高可用構成可能
• CloudSpanner
  
  →トランザクション使える、SQL使える、＋水平スケール
  
  →RDBと非RDB両方の特徴を持っている
  
  →使いどころ：リレーショナル、高可用性、高スケーラビリティ
  
  →制約：既存DBとの互換性がない、リージョン間レプリケーションが追いついてない
  
• CloudTasks
  
  →マイクロサービス間の非同期タスクに向いている
  
  →スロットリングが可能
  
  →タスクの再試行
  
  →CloudTasksからいろんなGCPサービスを呼べる、GKE、CloudFunctionも可能
• CloudStorage
  
  →３６００secのキャッシュコントロールされる

#リクルートにおけるWebパフォーマンス改善の取り組み

• リクルートでの取り組み
  →ライブラリ・ツール開発
  →性能改善
  →開発支援・エンジニア育成
• 性能改善の取り組み
  →勉強会の開催
  →Google主催スピードハッカソン
  →タウンワークスピード改善ローンチ
  →SUUMOスピードハッカソン社内実施
  →AirShift性能速度改善
• SUUMO　２００９年スタート
• 多くの機能追加開発、細部にわたった使い勝手向上の取り組みの結果、ページ表示性能低下の懸念が出てきた
• たびたび改善しているが、改善案件になっている・属人化してしまう
  →なかなか定着させられない
• Webパフォーマンスとは！
  →コンテンツがリッチに、低スペック端末、通信環境（３G4G）も対応するには、サーバーのレスポンス性能だけでは不十分！
  →待ち時間の80%-90%がフロントエンド
• httparchive.org
• モバイルユーザーが重視するもの：ページのロード速度
• ページ速度がモバイルの検索順位に使用されるように！
• 多くの人に利用してもらうサービスとして、パフォーマンスを常に一定で保つ必要あり
• SUUMOのアプローチ
  →予防（現状の可視化・共通認識・案件企画・設計から意識）
  →維持（指標と基準を定めてアラート）
  →改善（基準に満たないページを改善）
• 性能改善ハッカソン
  →パフォーマンス改善のための調査・計測・見立てを１日で行う
  →https://web.dev/fast
• 性能改善ハッカソンのポイント
  →アーキテクチャやBusiness上の制約を無視して点数を上げる
  →範囲を狭める（1-数ページ）
  →現場の開発チームにも参加してもらう
• 性能改善ハッカソンの効果
  →具体的な案件リストが短期間で手に入る
  →業務知識の少ないメンバーでも貢献しやすい
  →普段触れない部分に積極的に手を入れられる
  →チームの性能への意識向上
  →性能上のボトルネックが明確になる。コードと性能の関連性が体験できる
• SUUMOで実施した結果
  →有効な施策を短期間で提案
  →特定環境下で１００点まで改善（もとの数倍）
  →読み込み不要の画面外の画像、アクセス解析・広告タグなど
• 改善施策の適用
  →価値・何度・コストで評価
  →簡単にできて効果の高いものから実施
  →正しく修正できていないと、画像みれない・崩れ！障害につながるためリリース前のテストはしっかりしてる
• 改善の効果計測
  →売上、CVR、滞在時間、ページビュー、離脱率を計測していく
• 改善のその後
  →価値あるサービスを継続的に届ける
• パフォーマンスバジェット
  →Googleの記事参照
  →ユーザー体験を一定に保つ前提で、機能と性能のトレードオフを可視化・説明・判断できる
• パフォーマンスバジェットでの指標
• SUUMOでのパフォーマンスバジェット
  →レポーティングに取り入れてる
  →定期的に計測し、傾向なども含めてレポーティング
  →開発チーム主体でレポート作成
  →一定期間でのレポートをまとめ、サマリして全体周知
  →最新状況と施策の進捗共有、Businessサイドとの共通認識
• SUUMOでのパフォーマンス計測
  →クラウド上に独自構築（既存サービスでは対応できない要件があった、表示内容を自由に決められる）
• パフォーマンス計測ツール
  →web/fundermentalsでいろんなツールが紹介されているのでチェック
• まとめ
  →SUUMOでは改善→維持→予防の順ですすめてる
  →ハッカソンでの改善を入り口に
  →レポーティングでチームない共有・共通認識（企画・設計から意識できるように）
  →チーム・組織全体で取り組む、非属人化
  →引き続き取り組んでいきたい

#インフラ管理不要の Firebase と GKE で実現するモバイルアプリ開発

• モバイルアプリの技術選定
  →エンジニアリソース低、開発期間短い
  →負担を減らしたい・・・そこでGKE,FireBase
  →ブロックチェーンノード：GKE
  →ブロックエクスプローラ：Firebase
• ブロックチェーンのバックエンド・フロントエンド開発
  →可用性・バージョンアップのしやすさ・作って壊してのやりやすさが大事
  →k8sが条件を満たしていた。このフルマネージドサービスがGKE
• ブロックエクスプローラの構築
  →可用性・リアルタイムに変更を取得可能・作って壊してのやりやすさが大事
• Firebase導入について
  →GAEとCloudDatastoreで以前は構築していたが、リソースがだいぶ割かれて業務に注力できてなかった
• CloudFirestoreにしてよかったこと
  →get/setAPIが減った（直接アクセス可能）
  →AppEngine不要でシンプルな構成になった
• FireStore導入注意事項
  →クライアントにAPIキーが埋め込まれている
  →rule決めが大事
  →read/write権限