Google Cloud で実践する Web アプリ開発
https://developers-jp.googleblog.com/2019/05/google-cloud-web.html
に行ってきたので、その時のレポート
Web フロントエンド開発最新動向：グーグル合同会社 宇都宮 佑亮
資料
以下、講演を聴きながらのメモ
chromeは生誕 10 周年
googleは生誕 20 周年
www ができてから、30 周年
いまはそんな時代。
そんな時代の中、
ユーザがwebを閲覧する環境が変わってきている
デスクトップ → スマートフォン → Feature Phone
このような環境に我々は対応していかないといけない。
現在の web の中央値の話
6sec (FCP)描画されるまでの時間
9sec (TTL)ユーザが使える状態になるまでの時間
速度がユーザ体験を向上させる。
それが、CVR の増加などビジネス側の向上にも繋がる。
速度改善のやり方として、いろいろなアプローチの方法があるが
「画像の最適化」 から初めてみるのもいいかもしれない
画像の最適化を CDN に任せることで、自社のサービスに集中できる。というメリットもある。
その上で、js, css 等の最適化を行っていってもよい。
よくある現象として、速度を改善したが、
半年後に、また遅くなっているという現象がよくある。
そのために、Performance Budget という考え方がある。
Performance Budget とは、これ以上遅くさせてはいけないよという基準のこと。
例えば、ユニクロでは、各スクリプトを 80kb 以下に抑えるという基準を設けている。
自社のモニタリングも大事。
その一つのツールとして、
Chrome UX Report
というものがある。
その他にも、
- Google Seach Console
- Firebase のパフォーマンスモニタリング
- Righthouse
- chrome のエンジニアが開発している
PROXX というアプリを作ってみた。
これは、Feature Phone でもサクサク動く。
使っている技術として、Web Workers などのノウハウを凝縮している
→ オープンソースなので、みんな参考にしてね。
その他の工夫の仕方として
あらかじめ次のページを読み込んでおくという方法もある。
WEB はモバイルだけの話ではない。
デスクトップでも PWA でホームに WEB アプリを配置できるようになってきている。
→ Desktop PWA という。
→ hulu がすでに実装している。
また続々と、Web でできる技術の範囲を広げている。
たとえば、
- 指紋認証も Web でやりたい
- Web Authentication という技術を使って実装できる
- カメラのアクセスもやりたい
- Shape Detection Api というのを使って実装できる。
まとめると、
新たな API を段階的に公開（予定）
→ 標準化と並行して、デベロッパーに使ってもらう環境を提供していくよ。
JS の AMP の話
AMP は 最初モバイル用に作られていたが、
いまではデスクトップ用に実装することも可能。
AMP は 3年間の歴史がある。
最初はできなかったことが、今ではできるようにもなってきている。
例えば、
- URL の問題
- domain が google.com になってしまう
- web packaging（AMP Packager Cloudflare）を使えば対応できる
- domain が google.com になってしまう
- AMPではJSが使えない問題
- AMP のページにも js が使えるようにします！
- トライアルを現在提供している。
- AMP のページにも js が使えるようにします！
AMP の面白い機能として
- AMP Stories
- 画面全体に画像を出して、テキストも出して、本を読んでいるような感覚になるような使い方もできる。
- 没入感もあって、時代にあった使い方ができる。
- 画面全体に画像を出して、テキストも出して、本を読んでいるような感覚になるような使い方もできる。
- AMP For Email
その他にも、youtube で THE AMP CHANNEL というチャンネルがあって
そこで、日本語での今後の AMP などについての配信をしている。
GCP のサーバーレスサービス紹介：グーグル・クラウド・ジャパン合同会社 篠原 一徳
資料
以下、講演を聴きながらのメモ
そもそもサーバレスって？
- インフラの管理がいらない
- 下のレイヤ（OSなど）はプロバイダがよしなにやってくれる
- 使った分だけの課金
web アプリケーションを開発する際に考えること
- アプリをどこでうごかすか？（コンピュート）
- DB
- 非同期処理
- 静的コンテンツ
- コード管理・ビルド・デプロイ
- モニタリング・ロギング・APM
今日は時間の関係で、 4 までの話をする
コンピュートの話
- Cloud Functions
- 関数を配置する
- イベントドリブン。いろいろなイベントを受け取ることもできる。
- サーバ管理なし。
- 20を超えるサービスと連携することができる。
- 注意点：サポートされている言語以外は使えない。
- 関数を配置する
- App Engine
- 世の中でいう、PaaS
- スケールアウトが高速
- アプリのコードに集中できる。
- Cloud Functions と同じで、ランタイムがある。
- 柔軟なデプロイが可能。
- コードに更新をかけてデプロイしたら、「v2」 のようにエディションを提供してくれる。
- 注意点：ランタイムに種類があるので、注意
- 世の中でいう、PaaS
- Cloud Run
- Knative：oss のツール。k8s の上にサーバレスの実行環境を作ってくれるもの
- Cloud Run はコンテナのイメージを渡して使うもの。
- つまり、言語やライブラリの制約がほとんどない。
- 2種類ある。Cloud Run と、 Cloud Run on GKE というものがある。
- on GKE に関しては、使った分の課金ではなく、載せる node の数での課金になる。
- 注意点：コンテナを必ず使わないといけない。ビルドプロセスを決めないといけない。
DBの話
GCP storage option で検索したらユースケースが出てくるよ！
- Cloud Firestore
- Firebase
- リアルタイムにデータを同期
- Cloud SQL の話
- フルマネージドDB
- 高可用性
- Cloud Spanner
- リレーショナルセマンティック + 水平スケール
- RDB, 非RDB, 両方の特徴を持っている。
- 注意すべき点：既存DBとの互換性がない場合がある。ので、改めてテーブル設計が必要になることも
非同期の話
- Cloud tasks
- キューイングして実行したり、スケジュールでの実行もできたりする。
静的コンテンツの話
- Cloud Storage を使った静的コンテンツ配信
まとめ
- GCP を使えば、インフラの管理がとても減るよ！
- コンピュートとDBがいろいろあって、特徴があるので、適材適所で使っていこう！
- モニタリング・ロギング・デプロイのサービスも GCP にはあるので、ぜひ使ってね！
リクルートにおけるWebパフォーマンス改善の取り組み：株式会社リクルートテクノロジーズ 新井 智士 氏
資料
以下、講演を聴きながらのメモ
リクルートでの取り組み
- ライブラリ・ツール開発
- 性能改善
- 教育
今日は「性能改善」について話すよ。
- パフォーマンス改善に関する勉強会開催
- Google主催のスピードハッカソン参加
- 社内スピードハッカソン開催
- AirSHIFT 性能速度改善
SUUMOでの性能改善の取り組み
- SUUMO は 2009 年から運営されていて、10年越えのサービスだよ。
- 多くの機能追加開発を続けてきているよ
そこで、
機能を追加する分、ページ表示性能低下の懸念が出てきた。
たびたび性能改善されているが、戻ってしまう。
- 「改善案件」になってしまう
- 改善する人が属人化してしまう
- なかなか定着しない。
「WEBパフォーマンスについて」（これまで）
- レスポンスはどのくらいで帰ってくるか
「WEBパフォーマンスについて」（現在）
- コンテンツがリッチに
- 低スペックな端末や通信環境
- 待ち時間の 80-90% がフロントエンド
つまり、サーバサイドの検証だけではいけない。
モバイルユーザが求めるものとしても、スピードが上位になっている。
ので、パフォーマンスはユーザ体験に影響を与える！
「SUUMOでのアプローチ」
- 予防
- 現状の可視化・共通認識化・案件の企画設計から意識
- 維持
- 指標と基準を定めてアラート
- 改善
- 基準に満たないページを改善
「性能改善ハッカソン」
- パフォーマンス改善に向けて、1日くらい時間を使ってハッカソンをする。
- ポイントとしては、
- アーキテクチャやビジネス上の制約を無視して点数をあげる！
- 範囲を狭める（数ページ程度）
- 効果は
- 案件リストが作成できる
- 普段触れない部分に触れる
- 意識向上
- ボトルネックが明確になる
- 結果
- 短期間で施策提案ができた
- スコア改善
- 適用
- 価値、難度、コストで評価
- 簡単にできて効果のあるものから順番に実施。
- テストはもちろんしっかり行う。
効果が出ても、すぐに戻ってしまうので、
パフォーマンスバジェットを定めていこう！
- レポーティングしよう
- 一定期間でサマリを出して、全体周知
- ビジネスサイドにも意識してもらうようにしよう！
まとめ
- SUUMO では、改善 -> 維持 -> 予防の順で進めている
- ハッカソンでの改善を入り口に
- レポーティングで共有し、企画・設計段階から意識できるように
- いろいろな人を巻き込むことで、属人化を防ぐ
インフラ管理不要の Firebase と GKE で実現するモバイルアプリ開発：株式会社Ginco 西川 達哉 氏
資料
以下、講演を聴きながらのメモ
モバイルアプリの技術選定
少数で、期間も短いプロジェクトだった。
そこで、重要な部分に集中したいので
Firebase と GKE を選定した。
ブロックチェーンとは
- 履歴データの保存（トランザクション）
- 特定の管理者によって操作されないというメリット
ブロックチェーンで大事なことは
- 可用性
- node が落ちないように
- バージョンアップのしやすさ
- 作って壊してをやり易い
- 未知な部分が多いので、あとから構成をばっくり変えたいということがおこるため
ここでぴったりな技術が、K8Sだった。
そこで、GKE を使った。
ブロックエクスプローラを作る際に大事なこと
- 可用性
- リアルタイム性
- 作りやすく、壊しやすい
Firebase を導入して変わったこと
- サーバ管理コストなし
- スケーリング対応
- リアルタイムアップデート
Cloud Firestoreにしてよかったこと
- APIが減る
- リアルタイムにできる
- インフラの複雑性が下がる
Firestore を導入するにあたって
- クライアントから直接アクセス可能
- APIキーはクライアントが持っている
- そのためのルールが必要
まとめ
- firebase 内での連携が簡単で工数低い
- サーバレスなのでメンテコスト低い
- クライアントエンジニア主体の開発に専念できる。