爆速の日経電子版開発の今

Nikkei Tech Talk #3 メディア企業のWebフロントエンド～多様な開発と技術選定～ https://nikkei.connpass.com/event/268793/ で発表させていただいた際の資料です。

日経電子版の開発の今についてお話ししました。

Transcript

1. 1 Nikkei Tech Talk #3 日本経済新聞社 デジタル編成ユニット 林 仁 2023年01月26日 爆速の日経電子版開発の今
2. 2 whoami • サブスクリプション事業デジタル編成ユニット Web チーム • Web Developer ◦ フロントエンド, CDN • Google Professional Cloud Architect • 新卒1年目 • Member of pnpm • OSS、ギター、お酒が好き 林 仁(Shinobu Hayashi) @Shinyaigeek (Twitter/GitHub) #nikkei_tech_talk
3. 3 日経電子版 Web 開発の話をし ます #nikkei_tech_talk
4. 4 日経電子版って？ • 1876年 中外物価新報創刊 (日本経済新聞の前身 ) • 1996年 NIKKEI NET 創刊 (日経電子版の前身) • 2010年 日経電子版創刊 • 有料購読登録者数80万人以上(資料作成時点) • 月間3億アクセス以上 • 経済分野のニュースを中心に、スマホアプリ、 Web で配信 • 紙の新聞にはない、ニュースの AI推薦機能や保存したニュースを閲覧 できるMyニュース機能など, パーソナライズ機能も提供 #nikkei_tech_talk
5. 5 日経電子版の持つ事業特性 • マスメディアとしての側面 ◦ 情報インフラとして社会基盤の一部と言える ◦ ユーザー数、アクセス数の多さ ◦ → ダウンタイムが深刻 • ニュースメディアとしての側面 ◦ SNS での “バズり” によりアクセス数がスパイクしうる ◦ また重大な事件が起きた時にも多大なアクセスがある • 大規模なサービス展開 ◦ NIKKEI LIVE や選挙ページなど、 nikkei.com から多種多様な サービスが配信されている #nikkei_tech_talk
6. 6 日経電子版の爆速のユーザー 体験への取り組み #nikkei_tech_talk
7. 7 #nikkei_tech_talk https://marketing.itmedia.co.jp/mm/articles/1712/21/news039.html
8. 8 #nikkei_tech_talk Google I/O 2019
9. 9 なぜ爆速を目指したいのか • ”記事” という情報コンテンツをユーザーへと伝えるため ◦ 読み込みが遅いと情報へとアクセスできる前にユーザーが離 脱してしまう ◦ より情報を伝えるための手段として、読み込み速度は事業価値 的にもビジネスインパクト的にも肝 • SEO 上でも有利に ◦ Google の策定した、Core Web Vitals が SEO スコアにも反映 されるように ◦ その指標の中にはパフォーマンス指標も ... #nikkei_tech_talk
10. 10 日経電子版 Web のサービス構成 #nikkei_tech_talk
11. 11 日経電子版 Web のサービス構成 • CDN(Fastly) でサービスを結合している MicroServices • 特定サービスでおきた障害の波及を防ぐ • サービスに応じて、開発メンバーを編成できる • なるべく CDN Cache から返す ◦ 読み込み速度の向上 ▪ Origin Server への過負荷を防止する ▪ オリジンサーバーで SSR ロジックの実行の省略 ◦ アクセス数のスパイクによる高負荷への耐久性向上 • Fastly の活用 ◦ 記事の更新時などに Instant Purge により CDN Cache を purge #nikkei_tech_talk
12. 12 電子版での CDN Cache 戦略 • ユーザーの認証情報は Cookie に詰められている ◦ Origin Server のページを描画するロジックで必要なのは Incoming HTTP Request を 送信しているユーザーの、契約ステータスといったセグメント情報 ◦ CDN で Cookie をセグメント情報へと解いてしまう ◦ Origin Server へ HTTP Request を転送するときに、解いたセグメント情報を HTTP Request Header として詰める #nikkei_tech_talk
13. 13 電子版での CDN Cache 戦略 • Shared Cache として HTTP Response を CDN に Cache する • Cookie 中のユーザー情報を CDN で解いてセグメント情報を Origin Server への Backend Request に載せそれに応じて Backend Response も変わる • Backend Request に含まれるユーザーのセグメント情報によっても Shared Cache した HTTP Response を CDN から出し分けるために Vary Header を使う • 認可だけでなく、A/B テストででも用いられている #nikkei_tech_talk
14. 14 電子版での CDN Cache 戦略 #nikkei_tech_talk
15. 15 日経電子版の爆速の開発者体 験への取り組み #nikkei_tech_talk
16. 16 > 日経といえば「爆速」のイメージが強いですが、昨今では「爆速」な上に生 産性の爆上げにも注力しています。これまではテンプレートエンジンを用い てのHTML生成とWeb標準技術に振り切った技術選定でしたが、最近では React, Next.js, Rust といった新しいものを取り入れて基盤を置き換えつ つ、次世代基盤を開拓しています。その過程で様々なフロントエンドエコシ ステムに還元したいものも多く、フロントエンド技術コミュニティを応援したい と考えています。 #nikkei_tech_talk JSConf 2022 スポンサー紹介文
17. 17 これからも爆速であり続けるために • 今の開発基盤は 2017 年から開発されており、ところどころ技術的負 債が存在する • 開発対象サービスが多く、社員メンバーだけでなく業務委託 , 協力会社 など多くの人員で開発されている • 開発者体験の向上により、新しいサービス、より良いユーザー体験を 実現するための開発をより早いサイクルで回せる • そもそも働いていて気持ちのいい職場のためにも重要 #nikkei_tech_talk
18. 18 直近の取り組み > アプリケーションパフォーマンスの外形監視 • アプリケーションパフォーマンスを外形監視できる基盤の “Reboot” • わざわざ人の手で測定せずとも Performance Regression に気づけるように ◦ SpeedCurve での Reporting、CI での LighthouseCI の実行 • 競合他社との比較設定の見直し ◦ 組織として、アプリケーションパフォーマンスへの意識向上 #nikkei_tech_talk
19. 19 直近の取り組み > ビルドパフォーマンスの改善 • コードベースのサイズが大きく、ビルド /テストでもかなり時間がかかっ ている • 単純に TypeScript/JavaScript Compiler/Transpiler を babel から swc へと移行することで、ビルドパフォーマンスの改善を図った • まずはローカル環境で、次に dev/staging 環境で、最後に本番環境へ と swc を投入し移行を完遂 • 1 サービスのビルドに 130 sec ほどかかっていたのが、 75 sec ほどま で改善された #nikkei_tech_talk
20. 20 直近の取り組み > Fastly VCL → Compute@Edge 移行検証 • 日経では Fastly VCL を大いに活用しているが、プログラマブルな処理は VCL で記述することは難しくメンテナンス性が落ちる ◦ Fastly VCL から Compute@Edge へと移行することで解消できないか ◦ またローカル/CI環境でのデバッグ、テストもできない • 法人向けプランである 日経電子版 FOR OFFICE の社内報サービスや NIKKEI Financial で Compute@Edge への移行の検証が行われている ◦ (まだ実戦投入はできていない ) • 鋭意検証中...… #nikkei_tech_talk
21. 21 Summary • 爆速の日経電子版/開発の今 ◦ 日経電子版 Web 開発チームでは, 今なお爆速の情報メディアを 目指している • 爆速の/日経電子版開発の今 ◦ “爆速の電子版” というブランドの維持、さらなる爆速の実現のた めユーザー体験のみならず、開発者体験の爆速化への取り組み も行っている #nikkei_tech_talk
22. 22 ご清聴ありがとうございました！ #nikkei_tech_talk