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