「日経電子版」は“ユーザー体験爆速化”をどう実現したのか　ユーザー数80万人以上・月間アクセス数3億以上のメディアを支える開発の舞台裏

2022年に新卒で入社　フロントエンド、CDN開発を担当

林仁氏：「NIKKEI Tech Talk #3」、「メディア企業のWebフロントエンド～多様な開発と技術選定～」のトップバッターとして「爆速の日経電子版開発の今」というテーマで発表します、よろしくお願いします。

まず、自己紹介から始めたいと思います。林仁と申します。「Twitter」「GitHub」は「Shinyaigeek」というIDで活動しているので、プライベートではしにゃい君と呼ばれることが多いです。

会社でも本名よりもハンドルネームのしにゃい君で呼ばれることが増えてきていて、ちょっとうれしいような恥ずかしいようなというのが最近の悩みです。

日本経済新聞社には新卒として2022年に入社しました。サブスクリプション事業デジタル編成ユニットという、日経電子版など、サブスクリプション事業のデジタル関連を扱う部門中のWebチームというチームで、日経電子版やその周辺サービスのフロントエンド、CDN開発に携わっています。

プチ自慢です。入社時点で「クラウド技術周りの知識がぜんぜんない」というのがコンプレックスだったのですが、最近会社の補助を受けて勉強しつつ、GCP（Google Cloud Platform）のPCA（Professional Cloud Architect）という資格を取得しました。いい会社ですね。

主に、Webフロントエンドのビルドツールチェーン周りのエコシステムが好きで、OSS活動を趣味でちまちま行っています。最近だと、パフォーマンスとかnode_modules によるマシンメモリの専有を避けるための取り組みがおもしろいなと思って、「pnpm」の開発をメインでやったりしています。よろしくお願いします。

「日経電子版」の有料購読登録者数は80万人以上、月間アクセス数は3億以上

今回の発表では、テーマどおり日経電子版Web開発の話をしようと考えています。

「そもそも、日経電子版ってなんやねん？」といったところから話を始めます。日本経済を扱うニュースメディアとして、1876年に「中外物価新報」という新聞が創刊されました。これがいわゆる今の日本経済新聞の前身です。

その後、日本経済新聞社はデジタルインターネット技術に可能性を見出し、すごく早い段階の1996年から「NIKKEI NET」というインターネット上のメディアサービスを展開しました。これが今の日経電子版の前身となっています。

その後2010年に、日経電子版が創刊され、本格的にインターネット上での情報発信にも注力していくようになりました。

先ほどお話ししたとおり、日経電子版は、2010年から続く歴史あるWebサービスで、現在は有料購読登録者数が80万人以上、月間アクセス数が3億以上を抱える、かなり巨大なサービスとなっています。

これは紙の新聞との違いの話になりますが、電子版では、紙の新聞では実現できなかったニュースのAI推薦機能や、後で見返したいニュースを個々人で保存しておいて見返すことのできるMyニュース機能など、パーソナライズ機能も提供しています。

「日経電子版」が持つ事業特性とは何か？

先ほどの「電子版とは何ぞや？」という話と一緒に、開発する際に注意せねばならない日経電子版の事業特性についてもお話しします。

日経電子版はマスメディアとしての側面があり、情報インフラとして社会基盤の一部であると言えるでしょう。先ほどお話ししたとおり、ユーザー数が80万人以上、アクセス数も月間3億以上と、かなりの数があるため、少しの間サービスがダウンした、例えば「ちょっとデプロイをミスっちゃって3分間サービス落ちちゃった」という場合でも、かなり多くのユーザーに影響を及ぼしてしまいます。

また、そもそもマスメディアとして“今の情報”を提供し続けなければならないため、サービスの信頼性がかなり重要になってくる事業であると言えるでしょう。

ほかにも、例えばTwitterなどのSNS上で日経の記事がバズった時に、そのバズに比例してユーザーへの露出が増えてアクセス数がスパイクすることもありますし、みんなが興味ある重大な事件が起きた時に、多大なアクセスが生じることがあるサービスとなっています。

また、これは電子版というより日経という会社の話にもつながるのですが、日経は、電子版を配信しているnikkei.comから記事を表示するページだけではなく、選挙ページやニュースライブ配信を行う「NIKKEI LIVE」など、多種多様なサービスを配信しています。

そのため、シンプルにプロダクトとしてかなり大きく、私が所属するWebチームの場合だと、社員メンバーのみならず、業務委託の方や、学生でインターン生として携わっている方や、協力会社の方など、多種多様なメンバーで開発しています。また、プロダクトのサービスの数、プロダクトの大きさに比例して、チームの規模もかなり大きなものになっています。

日経電子版が"ユーザー体験の爆速化"を目指すワケ

では、日経電子版そのものの話と事業の話に触れたところで、次は日経電子版開発の話に移らせていただきます。

本セクションでは、「日経電子版の爆速のユーザー体験への取り組み」にフィーチャーして紹介したいと思います。

2017年のITmediaに、『日経電子版はなぜ"爆速化"したのか、どれだけ速いのか』という記事があります。先ほど、日経電子版は2010年に創刊したと紹介しましたが、スマートフォンの普及を受けて、実は2017年にモバイル端末向けの表示、いわゆるレスポンシブデザインの実現のために、日経電子版Webの刷新が行われました。その際の表示速度向上のための取り組みがITmediaに取り上げられています。

その時の取り組みは「Google I/O 2019」などでも紹介されていて、ここで行った爆速化の取り組みは、今もなお電子版開発において守り抜かれています。

本発表では、この爆速の電子版開発の取り組みについて紹介したいと思います。

具体的な取り組みに入る前に、そもそもなぜ爆速の電子版を目指したいのかというモチベーションの部分からお話ししようと思います。

先ほど紹介したとおり、日経電子版は情報メディア事業であるため、ある種、Webという情報伝達媒体を利用して、記事という情報コンテンツをより早く、より確実にユーザーへ届けることに事業価値があります。

みなさんにも経験があるかもしれませんが、Webサイトの表示に時間がかかってしまうと、肝心の情報、電子版でいうところの見出しや記事本文などが表示される前にユーザーが離脱してしまうことが生じ得ます。

読み込み速度が遅いために、情報が届く前にユーザーが離脱してしまうというのは、「そもそもお前、情報を届けられてないやんけ」ということで、事業価値を揺るがしてしまうことでもあります。

また、ユーザーの離脱率が高いと、ビジネス上でも解約率が上がったり、逆に契約率が下がったりなど、インパクトが大きいです。

さらには、これを聞いているみなさんにとっては耳タコな話だと思いますが、Googleの策定した「Core Web Vitals」というWebサイトの指標が、Googleの検索エンジンのSEOスコアにも反映されるようになっており、Largest Contentful Paintといった表示速度に関する指標を改善することで、Google検索エンジンからの流入量を増やして、情報をより多くの人に届けられるようになります。

かつ、ビジネス上でも有利になるといった効能もあるため、メディア事業を運営していく以上、表示速度の爆速化はかなり重要であると言えるでしょう。

「日経電子版」のサービス構成

爆速化のモチベーションをお話ししたところで、ようやく本題へと移りたいと思います。

まず、日経電子版のサービス構成について解説をします。WebブラウザといったHTTPクライアントから、電子版を配信しているnikkei.comへアクセスがあると、そのHTTPリクエストをCDNで受けます。

CDNには「Fastly」を利用しており、そのCDNのバックエンドに、例えば記事を表示する画面のサーバーやトップページを表示する画面のサーバーなど、それぞれの画面ごとに独立して稼働しています。

CDNでIncoming HTTP Requestのパスを見て、例えばパスが「/」であればトップページのサーバーにルーティングしたり、パスが「/article/hogehoge」であれば、記事ページのサーバーにルーティングしたりなど、パスを見てよしなにそれぞれのバックエンドへとルーティングをするようにしています。

日経電子版はいわば、CDNでサービスを結合しているMicroservicesになると言えるでしょう。この取り組みによってMicroservicesらしい恩恵があり、例えば特定のサービスで起きた障害がほかのサービスへと波及することを防げるといったメリットがあります。

例えば、NIKKEI LIVEをデプロイした時に、コードにちょっとミスがあり、NIKKEI LIVEのサーバーの負荷がすごく上がった結果、パフォーマンスが落ちるという状況になってしまっても、記事ページのサーバーなどには影響がないなど、システム全体の信頼性を向上させることができたり、各サービスに応じて開発メンバーを編成できたりなど、チーム編成上の恩恵も享受できています。

また、CDNでサービスを結合していますが、CDNでのキャッシュもフルに活用しており、なるべくユーザーからのアクセスを、ページをサーバーサイドレンダリングしているオリジンサーバーへと到達させずに、CDNからキャッシュを返すことでさばくポリシーでサービスを開発しています。これによりオリジンサーバーでのSSRのロジックの実行を省力できます。

先ほど紹介した、メディア事業につきまとうアクセス数のスパイクによって生じるアクセスの増加も、そもそもなるべくCDNからキャッシュを返すようにして、オリジンサーバーまでアクセスを到達させないようにすることで、アクセス増加への耐久性を上げたり、オリジンサーバーへの過負荷起因によるオリジンサーバーのパフォーマンスの低下を防いだりしています。

また、FastlyのCDNベンダーとしての特色として、Instant Purgeによる即座のキャッシュのパージなども挙げられるのですが、記事の更新時にフックによってInstant Purgeを実行して、CDN上のキャッシュがパージして更新が即座に反映されるようにしています。

「日経電子版」のCDNキャッシュ戦略

そもそもの話になりますが、電子版は、CDNでなるべくキャッシュを返せるようにするための工夫を行っています。それについて紹介したいと思います。

ユーザーからのアクセスにおいて、そのユーザーの認証情報は、HTTP Request中のCookieに詰められて送信されます。

しかし、オリジンサーバーのページを描画するというロジックにおいて、Cookieにあるような、そのユーザーが誰であるかというID情報は、たいていtoo muchである場合が電子版の場合は多く、実際に必要なのはアクセスしているユーザーの契約ステータスや、有料会員か無料会員などといったユーザーのセグメント情報になります。

例えば、簡単に記事を描画するページのサーバーで記事をSSRする時に、有料会員だったら記事を全文表示しますが、無料会員だったら記事を一部分しか表示せずに、かつ課金導線を表示します。こういったことを考えると、やはりオリジンサーバーでは、契約ステータスさえあれば必要十分であることがわかるでしょう。

そのため、電子版ではCDN上でIncoming HTTP Request中のCookieをデコードして、そのユーザーの契約ステータスなどのセグメント情報を取得して、それを、例えば先ほどの契約ステータスの場合は、User-Paid-StatusといったHTTP Request Headerとして詰め込んでオリジンサーバーへと転送しています。

こうすることで、例えば先ほどの契約ステータスの例でいうと、オリジンサーバーではHTTP Requestが来た時点で、User-Paid-Status Headerを参照すれば、アクセスしているユーザーの契約ステータスが取れるようになり、記事を描画するロジックを遂行できるようになるシステムを構築しています。

こうしたことを行い、オリジンサーバーからのHTTP ResponseにVary HeaderでCDN上で解かれたセグメント情報が載るHTTP Headerを指定することにより、同じURLのページだけど、ユーザーの契約ステータスなどによって異なる表示がされるようなページであってもオリジンサーバーからの HTTP Response を CDN にキャッシュして適切なキャッシュを出し分けることが可能になります。

例えば記事ページの場合、有料会員であれば全文表示されますが、そうでなければ記事の一部分しか表示されません。そうしたページにおいても、CDN上でオリジンサーバーから返却されるレスポンスをキャッシュしてVary Headerに指定されたHTTP Request Headerもキャッシュのkeyとして扱うことで、ユーザーのセグメント情報ごとにキャッシュのパーティショニングが可能になります。

そうするとセグメント情報に応じてキャッシュを出し分けることができるため、なるべくCDN上でShared Cacheとしてキャッシュをして、CDNでリクエストを捌くことができるようになります。

こうした仕組みは、先ほど例示したような認可だけではなく、A/Bテストなどでも用いられています。こうした戦略によって、電子版システムの爆速と高負荷への耐久性が実現されています。

ちなみに、この発表の前に、日経電子版のCDNにおけるキャッシュヒット率を確認してみましたが、90パーセントを記録していて、総アクセス数のうち90パーセントはオリジンサーバーへそもそも到達せずにCDNキャッシュでさばかれていることを確認しました。

また、理論上、アクセスのスパイクが生じて短期間にいっぱいアクセスが来た時には、もっとCDNで捌かれるようになる、つまりキャッシュヒット率が上がるはずで、オリジンサーバーの負荷がドンッと伸びることもほぼないはずです。すばらしい仕組みですね。

（次回へつづく）