CA BASE NEXT (2021/05/28) での登壇資料です. https://ca-base-next.cyberagent.co.jp/2021/sessions/abema-web-performance-and-reliability/
View Slide
野⼝ 直寛 (Tadahiro Noguchi)2018年度 新卒⼊社株式会社AbemaTV 開発本部Web チームテックリードWeb Performance Engineering チームリーダーClient SRE Web 担当メンバー@nodaguti @nodaguti
࣍$POUFOUT࣍$POUFOUT࣍$POUFOUT࣍$POUFOUT࣍$POUFOUT1. なぜ ABEMA はパフォーマンス‧信頼性を重視するのか?2. パフォーマンスへの取り組み3. 信頼性への取り組み4. まとめINDEX
なぜ ABEMA はパフォーマンス‧信頼性を重視するのか?
品質はサービスの価値を構成するから
Source: https://contents-abema.com/5th/index.html
ソフトウェアの品質とは?性能効率性機能適合性 互換性使⽤性 信頼性 セキュリティ保守性 移植性有効性 効率性 満⾜性リスク回避性 利⽤状況網羅性Source: ISO/IEC25 000Seriesソフトウェア製品品質 利⽤時の品質
パフォーマンスへの取り組み
現状分析 ⽬標設定改善実施効果計測品質維持
• Real User Monitoring (RUM, Field Data) メイン• パフォーマンスメトリクスの収集と分析• パフォーマンスメトリクスとビジネスメトリクス (KPI) の相関分析• 競合分析現状分析
メトリクス収集‧分析
ビジネス KPI との相関分析ロード時間 vs. 直帰率 起動時間 vs.5分視聴化率起動開始時間のセグメント5分視聴化率
競合分析Synthetic Monitoring (Lighthouse)
競合分析Real User Monitoring (PageSpeed Insights)
• 短期的: Core Web Vitals の基準から設定• ⻑期的: 競合分析から設定⽬標設定
短期的⽬標: Core Web VitalsSource: https://web.dev/vitals
短期的⽬標: Core Web Vitals
⻑期的⽬標: 競合分析
• Differential Serving (polyfills, bundles, images)• Critical CSS Extraction• Granular Chunks & Chunk Optimisation• etc, etc.改善実施
Differential Serving• ブラウザに応じて最適なアセットを配信• polyfills• 必要な polyfill だけを配信する• bundles• 必要なトランスパイルだけを適⽤する• images• 要素で対応ブラウザに最新の画像フォーマットを使⽤Chrome に配信される polyfill.jsIE に配信される polyfill.js
Critical CSS Extraction• Above-the-fold の描画に必要な CSS だけを事前に抽出しておき,HTML に埋め込んで配信
Granular Chunks & Chunk Optimisation• Granular Chunks• webpack の chunks 分割設定を最適化• https://web.dev/granular-chunking-nextjs/• Chunk Optimisation• 不要な dependencies や imports の削除• Tree Shaking が⼀部効いていなかったのを修正Granular Chunks: AfterGranular Chunks: Before
効果計測リリース前Synthetic Monitoring• Lighthouse/DevTools• Lightkeeper• 前後⽐較• A/B テストReal User Monitoringリリース後
効果計測: Synthetic MonitoringDevTools Lighthouse
効果計測: Synthetic MonitoringLightkeeper Statistical Analysis
効果計測: Real User Monitoring - 前後⽐較番組表の CLS が⼆回のリリースで改善した例 ホーム⾯の CLS が逆に悪化してしまった例
効果計測: RUM - A/Bテスト• Fastly 上で A/B テストのflag system を構築• Fastly• A/B テスト⽤の UserId を発⾏• UserId は Cookie に保存してユーザーごとの⼀貫性を保つ• Bucket を割り振って Origin Server にヘッダーで通知• Origin Server• Bucket に基づきコンテンツ出し分け• Vary を設定してテストごとに Fastly のキャッシュを分けるUserFastlyOrigin ServerCookie: user-id=kdfv...Fastly-ABTest1: Bucket-aFastly-ABTest2: Bucket-b• Bundle や meta タグの出し分けなど, origin で処理を変えられる A/B テストが必要
効果計測: RUM - A/B テストCritical CSS の A/B別施策における起動時間の確率密度関数の⽐較
品質維持Source: https://developer.akamai.com/devops各フェーズに対するアプローチが必要
開発フェーズへのアプローチ• Plan• LCP, CLS が悪化しにくい UI デザイン• Code• ⾮効率な書き⽅への linter / type check• Build & Test• 開発環境への Synthetic Monitoring
運⽤フェーズへのアプローチ• 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
信頼性への取り組み
信頼性と開発サイクル実装 テスト リリース 運⽤実装ミスリグレッションQA ⼯数の増⼤と バグ⾒落とし新バージョンリリース によるエラー率上昇外部要因の障害リリース頻度を⾼めたい
各フェーズへのアプローチ実装 テスト リリース 運⽤実装ミスリグレッションQA ⼯数の増⼤と バグ⾒落とし新バージョンリリース によるエラー率上昇外部要因の障害単体テストの充実Visual Regression TestE2E テスト カナリアリリースFeature FlagモニタリングClient SLI/SLO
実装 テスト リリース 運⽤単体テストの充実Visual Regression TestE2E テスト カナリアリリースFeature FlagモニタリングClient SLI/SLO
実装へのアプローチ: 単体テスト
実装へのアプローチ: Visual Regression TestVRT アーキテクチャ GitHub への通知
テストへのアプローチ: E2E テストリグレッション防⽌のため 既存機能チェック⼈的‧時間的コストSelenium とモックサーバー を使った⾃動テストへの移⾏
実装 テスト リリース 運⽤単体テストの充実Visual Regression TestE2
リリースへのアプローチカナリアリリース99%: 前バージョン1%: 新バージョンエラーレート等をモニタリングして 問題がなければ 100% リリースデプロイ機能A有効化機能B機能Cシステムのデプロイと機能のリリースを 切り離して柔軟な ON/OFF を実現Feature Flag
運⽤へのアプローチ: モニタリングなぜモニタリングが必要か?テスト == Synthetic Monitoring 外的要因による故障• テストは限定的な時間,限定的な環境下でのみ⾏われる• テストされていない環境で問題が起こる可能性• 運⽤枠の⼊稿ミス• クライアント環境のアップデート• 静的にバンドルしていない 3rdparty program のアップデート• etc.
モニタリング
モニタリングから SLI/SLO へモニタリングの悩み SLI/SLO• ページやユーザー属性でセグメント分けはできるが,特定の機能がどういう状態なのか掴みにくい• アラートの閾値調整が難しい• 機能と品質のリソース配分が感覚的• 機能単位で SLI/SLO を設定して監視• Error Budget / Burn Rate の考えに基づくアラーティング• Error Budget の残⾼によって攻めてよいのか守るべきかがすぐにわかる
Client SLI/SLOActionDispatcherStoreViewActionSLI: StartSLI: StartSLI: EndAvailability := end / start Latency := end - start
おわりに
• パフォーマンスとリライアビリティ向上に向けて,開発‧運⽤の両⾯で動いているおわりに*: https://www.slideshare.net/ygoto3q/technical-challenges-that-abematv-faces• 品質の維持‧向上のためには,⽂化の醸成が必要• 同僚の開発者から経営層まで,「品質」について同じ⽅向を向いていないと難しい• "テレビ品質" * を追求し,⾼品質なサービスを提供できるよう引き続き 努⼒していきます!