10年以上稼働し続ける大規模Webアプリケーション、どうやって改善する？

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

　リクルートには有名なアプリケーションや、これから作られる新規アプリケーションが大小合わせて数百存在し、中にはタウンワークのように10年以上運用されてるアプリケーションもあります。リクルートテクノロジーズではこれらのサービスのパフォーマンスやメンテナンス性の向上に取り組んでいます。本連載では、タウンワークで行った「パフォーマンス改善の取り組み」と「Webのフロントエンドにおけるモダナイズの取り組み」を2回に分けて紹介し、最後に未来の話として「これから利用するフロントエンドの技術」について解説します。本稿含めて全4回の連載でお送りする予定です。

はじめに

　リクルートテクノロジーズでシニアソフトウェアエンジニアとグループマネージャをしている古川陽介です。これから、リクルートテクノロジーズとリクルートジョブズにおけるWebアプリケーション改善の取り組みについて連載形式でお届けします。

パフォーマンス改善の取り組み

　リクルートテクノロジーズでは、ハッカソンの形式でパフォーマンスチューニングする取り組みをいくつか実施しています。ひとつは「R-ISUCON」と呼ばれる、仮想的なWebアプリケーションを対象に、リクルート全社対抗でそのアプリケーションをチューニングするというものです。

• R-ISUCON 2018 Winterレポート/ 「準備」と「計測」ーー基本を重視するものがISUCONを制す？
• R-ISUCON 2018 Winter解説記事

　R-ISUCONは仮想的なWebアプリケーションを対象にしていますが、実際のアプリケーションを対象にしたスピードハッカソン（注：Google Speed Hackathonを参考にしています）という取り組みもあります。

　実際に、タウンワークやSUUMOをベースとして、スピードハッカソンで1日かけてチューニングを行ったことがあります。

スピードハッカソンでチューニングしている様子

　このハッカソンでは「Lighthouse」というパフォーマンス調査ツールを用いて、初期スコアから何点向上できるかを競います。実際のページのアセット部分をチューニングし、点数を100に近づけるようにしています。

Lighthouseでタウンワークのアプリの点数を出しているときの図

　これは「パフォーマンスチューニングしたくても実際にやってみないとどれだけ大変で、体感できる効果があるかわからない」という問題に対処するものです。実際にやってみると、数時間の取り組みでも体感できるくらいに速度が上がります。

　ハッカソンで得たコストと効果をもとに、実際の案件ではタスクとしてどうやって改善ポイントを取り込むか検討します。詳細は第2回の「タウンワークのパフォーマンス改善の取り組み」で紹介します。

Webのフロントエンドにおけるモダナイズの取り組み

　タウンワークもオープンから10年以上が経過し、JavaScript、CSS、HTMLを含めてフロントエンドは老朽化しています。過去のA/Bテストの名残や、暫定対応と思われるコードが継ぎ足された結果、似たようなコードが残っていることも多かったのです。結果として、フロントエンドのエンハンスで手戻りが多く発生し、問題視されていました。

　これらを一気にリファクタリングしようとしても、すべてを置き換えるのは複雑で難しいため、まずは小さくスコープを切った上で整理された層を作り、その上でテストを書きながら少しずつ老朽化された部分を砕いてリファクタリングしていくようにしています。

　その際は、全員で仕様を学びながらモブプロしつつ、改善していきます。

モブプロをしながらリファクタリング

　以前のコードではフロントエンドでテストを書いてなかったため、実際に期待する動作がわからず、リファクタリングの妨げになってしまっていました。今回のリファクタリングではコードのモダナイズだけではなく、テストを中心に書くようにコードを変更させています。

testファイルを追加可能なアーキテクチャにする

　この部分は弊社の技術顧問である和田卓人からも助言をもらいながら、議論しつつ進めています。詳細は第3回の「Webのフロントエンドにおけるモダナイズ」で紹介します。