大規模Webサービスの改善に向けたR＆Dの取り組み――SPAのボイラープレート開発とFastlyの活用

大規模レガシーサービスにおけるパフォーマンス改善の道のり 第4回

　本連載ではリクルートテクノロジーズにおける大規模Webサービスの改善についてお伝えしてきました。最終回となる本稿では前回までの話とは異なり、今後のリクルートのWebフロントエンド技術について紹介します。具体的には、Single Page Applicationのボイラープレート開発と、Fastlyなどに代表されるCDN導入に焦点を当てた内容をお送りします。

はじめに

　リクルートテクノロジーズでフロントエンドエンジニアを務めている可児潤也です。

　リクルートテクノロジーズでは、レガシーなWebサービスのパフォーマンス改善やコードのモダナイズを行うとともに、R＆Dとして新規技術獲得にもチャレンジしています。それらの技術は実際にリクルートグループ内の新規案件や既存サービスのリプレースとして先行実装を行い、A/Bテストなどを通じて技術検証します。さらに案件を通じて得られた知見は共有し、効果的なものは次のサービスへ横展開していく流れになります。

　今回はR＆Dとしての取り組みの中で、Single Page Applicationのボイラープレート開発と、「Fastly」などに代表されるCDN導入に焦点を当てた内容を紹介します。特にFastlyの活用はまだ実際にリクルートのサービスに導入されておらず技術検証段階ですが、本稿においては次期サービスへの導入を行う予定の内容を先んじて紹介させていただきます。

R＆Dの取り組み その1「redux-plutoの活用」

　私たちのグループでは、高いパフォーマンスが要求される大規模なWebサービス向けに、React/Reduxを活用した「redux-pluto」と呼ばれるボイラープレートを開発しています。リクルートのWebサービスにおける機能は、検索結果をリストで表示するようなケースなど横展開しやすいものも多いため、ボイラープレート化することにより案件を通じて得られた知見を社内で広く活用し続けることを可能にしています。現在も実際にredux-plutoを使った案件開発を通じて得られたプラクティスを知見という形で共有すると同時に、ボイラープレートへフィードバックすることで、常にモダナイズし続ける運用を行っています。

図1　概要図：redux-plutoの構成

　Reactのような仮想DOMを利用したクライアントサイドレンダリング（以下、CSR）は、ユーザーがページを操作する際にサクサク動くような感覚が得られることでユーザーエクスペリエンス（以下、UX）を高めることが可能になります。

　一方、HTMLをサーバーサイドで生成するサーバーサイドレンダリング（以下、SSR）は、Webページの初期表示までの時間が高速化されUXを良くすることができるとともに、SEOの観点でもJavaScriptの実行を待つことなくHTMLが描画されるためリスクが低いと考えられます。

　redux-plutoでは、ユーザーからのリクエストにはnode.jsで開発したBackends for Frontends（以下、BFF）でSSRを実施し、ユーザーの手元ではReactを用いてWebページのCSRを行うように開発しています。これによって初期表示を高速化し、ユーザーが操作する際のサクサク動くような感覚も得られ、CSRとSSRのいいとこ取りができる構成になっています（BFFはSSRを実施するためだけでなく、セッション管理やAPIのアグリゲーションなど様々な機能を持ち合わせています）。

　OSSとして公開しているredux-plutoは得られた知見を社内に閉じずに共有することで、さらなるブラッシュアップを行っていく予定です。

R＆Dの取り組み その2「Fastlyの活用」

Fastlyとは？

　Content Delivery Network（以下、CDN）は、ユーザーに対し高速にWebページを提供するために利用されているネットワークです。リクルートのWebサービスの中にも、「Akamai」などのCDNを利用しているものがあります。その中でも、Fastlyは近年急成長しているCDNサービスプロバイダのひとつです。FastlyのEdge（エッジ）サーバーでJavaScriptやCSS、HTMLなどのコンテンツをキャッシュしておくことで、BFFに到達することなくエッジサーバーからコンテンツを提供できるため、ユーザーがWebページを高速に閲覧することが可能になるのです。

　今回はFastlyとBFFを組み合わせた構成で、A/Bテストのケースについて紹介します。

図2　概要図：一般的なCDNの構成

Fastlyを導入した構成

　ブラウザとBFFの間にFastlyのエッジサーバーが入ります。リクエストされてからレスポンスされるまでの流れは以下のようなものになります。

1. ユーザー1がページAにアクセスする。
2. エッジサーバーはキャッシュがないことを確認する。
3. エッジサーバーはBFFにリクエストを送信する。
4. BFFはページAをSSRしてレスポンスを返す。
5. エッジサーバーはレスポンスをキャッシュする。
6. エッジサーバーはレスポンスをユーザー1に返す。
7. ユーザー2がページAにアクセスする。
8. エッジサーバーはキャッシュを返す。

図3　概要図：Fastly導入時の構成

　エッジサーバーはそれ以降ユーザーからのリクエストに対してキャッシュからレスポンスを返すことができるため、BFFにまでアクセスが来ることはなくなり、ほとんど負荷がかからない状態にすることができます。