ABEMA Webブラウザ版をより高速で高信頼にするために / Towards more performant and reliable ABEMA

CA BASE NEXT (2021/05/28) での登壇資料です．
https://ca-base-next.cyberagent.co.jp/2021/sessions/abema-web-performance-and-reliability/

Transcript

2. 野⼝ 直寛 (Tadahiro Noguchi) 2018年度 新卒⼊社 株式会社AbemaTV 開発本部 Web チームテックリード Web Performance Engineering チームリーダー Client SRE Web 担当メンバー @nodaguti @nodaguti
3. ໨࣍
   $POUFOUT
   
   ໨࣍
   $POUFOUT
   
   ໨࣍
   $POUFOUT
   
   ໨࣍
   $POUFOUT
   
   ໨࣍
   $POUFOUT 1 . なぜ ABEMA はパフォーマンス‧信頼性を 重視するのか？ 2 . パフォーマンスへの取り組み 3 . 信頼性への取り組み 4 . まとめ INDEX
4. なぜ ABEMA はパフォーマンス‧信頼性を 重視するのか？
5. 品質はサービスの価値を構成するから
6. Source: https://contents-abema.com/ 5 th/index.html
7. Source: https://contents-abema.com/ 5 th/index.html
8. ソフトウェアの品質とは？ 性能効率性 機能適合性 互換性 使⽤性 信頼性 セキュリティ 保守性 移植性 有効性 効率性 満⾜性 リスク回避性 利⽤状況網羅性 Source: ISO/IEC 25 0 00 Series ソフトウェア製品品質 利⽤時の品質
9. ソフトウェアの品質とは？ 性能効率性 機能適合性 互換性 使⽤性 信頼性 セキュリティ 保守性 移植性 有効性 効率性 満⾜性 リスク回避性 利⽤状況網羅性 Source: ISO/IEC 25 0 00 Series ソフトウェア製品品質 利⽤時の品質
10. パフォーマンスへの取り組み
11. 現状分析 ⽬標設定 改善実施 効果計測 品質維持
12. 現状分析 ⽬標設定 改善実施 効果計測 品質維持
13. • Real User Monitoring (RUM, Field Data) メイン • パフォーマンスメトリクスの収集と分析 • パフォーマンスメトリクスとビジネスメトリクス (KPI) の相関分析 • 競合分析 現状分析
14. メトリクス収集‧分析
15. ビジネス KPI との相関分析 ロード時間 vs. 直帰率 起動時間 vs. 5 分視聴化率 起動開始時間のセグメント ５ 分 視 聴 化 率
16. 競合分析 Synthetic Monitoring (Lighthouse)
17. 競合分析 Real User Monitoring (PageSpeed Insights)
18. 現状分析 ⽬標設定 改善実施 効果計測 品質維持
19. • 短期的: Core Web Vitals の基準から設定 • ⻑期的: 競合分析から設定 ⽬標設定
20. 短期的⽬標: Core Web Vitals Source: https://web.dev/vitals
21. 短期的⽬標: Core Web Vitals
22. ⻑期的⽬標: 競合分析
23. 現状分析 ⽬標設定 改善実施 効果計測 品質維持
24. • Di ff erential Serving (poly fi lls, bundles, images) • Critical CSS Extraction • Granular Chunks & Chunk Optimisation • etc, etc. 改善実施
25. Di ff erential Serving • ブラウザに応じて最適なアセットを配信 • poly fi lls • 必要な poly fi ll だけを配信する • bundles • 必要なトランスパイルだけを適⽤する • images • <picture> 要素で対応ブラウザに最新の画像 フォーマットを使⽤ Chrome に配信される poly fi ll.js IE に配信される poly fi ll.js
26. Critical CSS Extraction • Above-the-fold の描画に必要な CSS だ けを事前に抽出しておき，HTML に埋 め込んで配信
27. Granular Chunks & Chunk Optimisation • Granular Chunks • webpack の chunks 分割設定を最適化 • https://web.dev/granular-chunking-nextjs/ • Chunk Optimisation • 不要な dependencies や imports の削除 • Tree Shaking が⼀部効いていなかったのを修正 Granular Chunks: After Granular Chunks: Before
28. 現状分析 ⽬標設定 改善実施 効果計測 品質維持
29. 効果計測 リリース前 Synthetic Monitoring • Lighthouse/DevTools • Lightkeeper • 前後⽐較 • A/B テスト Real User Monitoring リリース後
30. 効果計測: Synthetic Monitoring DevTools Lighthouse
31. 効果計測: Synthetic Monitoring Lightkeeper Statistical Analysis
32. 効果計測: Real User Monitoring - 前後⽐較 番組表の CLS が⼆回のリリースで改善した例 ホーム⾯の CLS が逆に悪化してしまった例
33. 効果計測: RUM - A/Bテスト • Fastly 上で A/B テストの fl ag system を構築 • Fastly • A/B テスト⽤の UserId を発⾏ • UserId は Cookie に保存してユーザーごとの⼀貫性を保つ • Bucket を割り振って Origin Server にヘッダーで通知 • Origin Server • Bucket に基づきコンテンツ出し分け • Vary を設定してテストごとに Fastly のキャッシュを分ける User Fastly Origin 
 Server Cookie: user-id=kdfv... Fastly-ABTest 1 : Bucket-a Fastly-ABTest 2 : Bucket-b • Bundle や meta タグの出し分けなど， 
 origin で処理を変えられる A/B テストが必要
34. 効果計測: RUM - A/B テスト Critical CSS の A/B 別施策における起動時間の確率密度関数の⽐較
35. 現状分析 ⽬標設定 改善実施 効果計測 品質維持
36. 品質維持 Source: https://developer.akamai.com/devops 各フェーズに対するアプローチが必要
37. 開発フェーズへのアプローチ • Plan • LCP, CLS が悪化しにくい UI デザイン • Code • ⾮効率な書き⽅への linter / type check • Build & Test • 開発環境への Synthetic Monitoring
38. 運⽤フェーズへのアプローチ • Monitor • User-perceived Performance Metrics • ユーザー環境で実現されたパフォーマンスは何か？ • 参考: RED method と USE method • Internal Performance Logs • どこを改善すればパフォーマンスが向上するのか？ • User Timing API • Layout Instability API • Largest Contentful Paint API • Long Tasks API • 参考: Debug Web Vitals
39. 信頼性への取り組み
40. 信頼性と開発サイクル 実装 テスト リリース 運⽤ 実装ミス リグレッション QA ⼯数の増⼤と 
 バグ⾒落とし 新バージョンリリース 
 によるエラー率上昇 外部要因の障害 リリース頻度を⾼めたい
41. 各フェーズへのアプローチ 実装 テスト リリース 運⽤ 実装ミス リグレッション QA ⼯数の増⼤と 
 バグ⾒落とし 新バージョンリリース 
 によるエラー率上昇 外部要因の障害 単体テストの充実 Visual Regression Test E 2 E テスト カナリアリリース Feature Flag モニタリング Client SLI/SLO
42. 実装 テスト リリース 運⽤ 単体テストの充実 Visual Regression Test E 2 E テスト カナリアリリース Feature Flag モニタリング Client SLI/SLO
43. 実装へのアプローチ: 単体テスト
44. 実装へのアプローチ: Visual Regression Test VRT アーキテクチャ GitHub への通知
45. 実装 テスト リリース 運⽤ 単体テストの充実 Visual Regression Test E 2 E テスト カナリアリリース Feature Flag モニタリング Client SLI/SLO
46. テストへのアプローチ: E 2 E テスト リグレッション防⽌のため 
 既存機能チェック ⼈的‧時間的コスト Selenium とモックサーバー 
 を使った⾃動テストへの移⾏
47. 実装 テスト リリース 運⽤ 単体テストの充実 Visual Regression Test E 2
48. リリースへのアプローチ カナリアリリース 99%: 前バージョン 1%: 新バージョン エラーレート等をモニタリングして 
 問題がなければ 100% リリース デプロイ 機能A有効化 機能B 機能C システムのデプロイと機能のリリースを 
 切り離して柔軟な ON/OFF を実現 Feature Flag
49. 実装 テスト リリース 運⽤ 単体テストの充実 Visual Regression Test E 2
50. 運⽤へのアプローチ: モニタリング なぜモニタリングが必要か？ テスト == Synthetic Monitoring 外的要因による故障 • テストは限定的な時間，限定的な環境 下でのみ⾏われる • テストされていない環境で問題が起こ る可能性 • 運⽤枠の⼊稿ミス • クライアント環境のアップデート • 静的にバンドルしていない 3rd party program のアップデート • etc.
51. モニタリング
52. モニタリングから SLI/SLO へ モニタリングの悩み SLI/SLO • ページやユーザー属性でセグメント分け はできるが，特定の機能がどういう状態 なのか掴みにくい • アラートの閾値調整が難しい • 機能と品質のリソース配分が感覚的 • 機能単位で SLI/SLO を設定して監視 • Error Budget / Burn Rate の考えに基づく アラーティング • Error Budget の残⾼によって攻めてよい のか守るべきかがすぐにわかる
53. Client SLI/SLO Action Dispatcher Store View Action SLI: Start SLI: Start SLI: End Availability := end / start 
 Latency := end - start
54. おわりに
55. • パフォーマンスとリライアビリティ向上に向けて，開発‧運⽤の両⾯で動いている おわりに *: https://www.slideshare.net/ygoto 3 q/technical-challenges-that-abematv-faces • 品質の維持‧向上のためには，⽂化の醸成が必要 • 同僚の開発者から経営層まで，「品質」について同じ⽅向を向いていないと難しい • "テレビ品質" * を追求し，⾼品質なサービスを提供できるよう引き続き 
 努⼒していきます！