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

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

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

nodaguti

May 27, 2021
Tweet

More Decks by nodaguti

Other Decks in Technology

Transcript

  1. 野⼝ 直寛 (Tadahiro Noguchi) 2018年度 新卒⼊社 株式会社AbemaTV 開発本部 Web チームテックリード

    Web Performance Engineering チームリーダー Client SRE Web 担当メンバー @nodaguti @nodaguti
  2. ソフトウェアの品質とは? 性能効率性 機能適合性 互換性 使⽤性 信頼性 セキュリティ 保守性 移植性 有効性

    効率性 満⾜性 リスク回避性 利⽤状況網羅性 Source: ISO/IEC 25 0 00 Series ソフトウェア製品品質 利⽤時の品質
  3. ソフトウェアの品質とは? 性能効率性 機能適合性 互換性 使⽤性 信頼性 セキュリティ 保守性 移植性 有効性

    効率性 満⾜性 リスク回避性 利⽤状況網羅性 Source: ISO/IEC 25 0 00 Series ソフトウェア製品品質 利⽤時の品質
  4. • Real User Monitoring (RUM, Field Data) メイン • パフォーマンスメトリクスの収集と分析

    • パフォーマンスメトリクスとビジネスメトリクス (KPI) の相関分析 • 競合分析 現状分析
  5. • Di ff erential Serving (poly fi lls, bundles, images)

    • Critical CSS Extraction • Granular Chunks & Chunk Optimisation • etc, etc. 改善実施
  6. Di ff erential Serving • ブラウザに応じて最適なアセットを配信 • poly fi lls

    • 必要な poly fi ll だけを配信する • bundles • 必要なトランスパイルだけを適⽤する • images • <picture> 要素で対応ブラウザに最新の画像 フォーマットを使⽤ Chrome に配信される poly fi ll.js IE に配信される poly fi ll.js
  7. 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
  8. 効果計測: 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 テストが必要
  9. 開発フェーズへのアプローチ • Plan • LCP, CLS が悪化しにくい UI デザイン •

    Code • ⾮効率な書き⽅への linter / type check • Build & Test • 開発環境への Synthetic Monitoring
  10. 運⽤フェーズへのアプローチ • 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
  11. 信頼性と開発サイクル 実装 テスト リリース 運⽤ 実装ミス リグレッション QA ⼯数の増⼤と 


    バグ⾒落とし 新バージョンリリース 
 によるエラー率上昇 外部要因の障害 リリース頻度を⾼めたい
  12. 各フェーズへのアプローチ 実装 テスト リリース 運⽤ 実装ミス リグレッション QA ⼯数の増⼤と 


    バグ⾒落とし 新バージョンリリース 
 によるエラー率上昇 外部要因の障害 単体テストの充実 Visual Regression Test E 2 E テスト カナリアリリース Feature Flag モニタリング Client SLI/SLO
  13. 実装 テスト リリース 運⽤ 単体テストの充実 Visual Regression Test E 2

    E テスト カナリアリリース Feature Flag モニタリング Client SLI/SLO
  14. 実装 テスト リリース 運⽤ 単体テストの充実 Visual Regression Test E 2

    E テスト カナリアリリース Feature Flag モニタリング Client SLI/SLO
  15. リリースへのアプローチ カナリアリリース 99%: 前バージョン 1%: 新バージョン エラーレート等をモニタリングして 
 問題がなければ 100%

    リリース デプロイ 機能A有効化 機能B 機能C システムのデプロイと機能のリリースを 
 切り離して柔軟な ON/OFF を実現 Feature Flag
  16. 運⽤へのアプローチ: モニタリング なぜモニタリングが必要か? テスト == Synthetic Monitoring 外的要因による故障 • テストは限定的な時間,限定的な環境

    下でのみ⾏われる • テストされていない環境で問題が起こ る可能性 • 運⽤枠の⼊稿ミス • クライアント環境のアップデート • 静的にバンドルしていない 3rd party program のアップデート • etc.
  17. モニタリングから SLI/SLO へ モニタリングの悩み SLI/SLO • ページやユーザー属性でセグメント分け はできるが,特定の機能がどういう状態 なのか掴みにくい •

    アラートの閾値調整が難しい • 機能と品質のリソース配分が感覚的 • 機能単位で SLI/SLO を設定して監視 • Error Budget / Burn Rate の考えに基づく アラーティング • Error Budget の残⾼によって攻めてよい のか守るべきかがすぐにわかる
  18. Client SLI/SLO Action Dispatcher Store View Action SLI: Start SLI:

    Start SLI: End Availability := end / start 
 Latency := end - start
  19. • パフォーマンスとリライアビリティ向上に向けて,開発‧運⽤の両⾯で動いている おわりに *: https://www.slideshare.net/ygoto 3 q/technical-challenges-that-abematv-faces • 品質の維持‧向上のためには,⽂化の醸成が必要 •

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