Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

8f77b55e0b7f5a2a51199b9e1578a88f?s=128

nodaguti

May 27, 2021
Tweet

Transcript

  1. None
  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 分視聴化率

    起動開始時間のセグメント 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 • 品質の維持‧向上のためには,⽂化の醸成が必要 •

    同僚の開発者から経営層まで,「品質」について同じ⽅向を向いていないと難しい • "テレビ品質" * を追求し,⾼品質なサービスを提供できるよう引き続き 
 努⼒していきます!
  56. None