エキサイトブログの トップページを 段階的にリプレイスする 2025.08.26 / エキサイト株式会社 / 山縣 寿樹 

自己紹介 エキサイト株式会社 メディア・プラットフォーム事業部 2021年にエキサイト株式会社へ新卒入社し、現在5年目。バックエンド を主軸に、フロントエンドやインフラ領域も担当しています。エキサイ トブログの開発に加え、最近は他サービスにも関わり、複数プロジェク トを横断して開発・運用をしています。 山縣 寿樹 Kazuki Yamagata 

旧アプリケーションの課題 リプレイス前の旧アプリケーションの構成や課題について話します。 新アプリケーション リプレイス後のアプリケーションの構成や新たに導入したモノについて話します。 段階的なリプレイスを実現する 段階的リプレイスを実現するために検討・実装した内容、またリプレイス後の結果につい て話します。 発表概要 

エキサイトブログ https://www.exblog.jp/campaign/exblog20th/ 

旧アプリケーションの構成図 DB Aurora PostgreSQL REST API Java / SpringBoot Web PHP5 / 独自フレームワーク 

11年前から変更されていないコード バージョン管理システムにSVNを使用していた時から変更されていないコード 11年以上前から変更されていないコードも存在 新機能の開発や既存機能の修正が大変 過去の開発に携わっていたメンバーは退職済み 開発に関係のあるドキュメントが整備されていない 

旧アプリケーション PHP5 / 独自フレームワーク コンテナ化しており、Amazon Elastic Container Service (ECS)で稼働 ECSではサイドカーにnginxを使用し、リーバスプロキシを使用した構成 

トップページのリプレイスを始める前に リプレイスの方針を決める 移行中もサービスは稼働し続けるようにし、メンテナンスしないようにする どんな技術を使うか？ どうやって切り替えるか？ 旧アプリケーションで使われているページを調査 一旦スプレッドシートに全部まとめる コード上は残っていても参照されていないページも数多く存在 ほとんど参照されていないページは、ビジネス側と協調しながら削除 

新アプリケーションの構成 DB Aurora PostgreSQL REST API Java / SpringBoot Web Java21 / Spring Boot3 

新アプリケーションにJava21 / Spring Boot3を採用 Java21 / Spring Boot3 過去のPHP → Javaの切り替えを経て、事業部内で知見が溜まっていた バックエンドAPIもJavaで構築済み マルチモジュール構成を採用しており、必要なコードを再利用できる OpenAPI OpenAPI Generatorを使用してAPIクライアントを自動生成 旧アプリケーションでは、エンドポイント毎に都度書いており面倒だった こちらも事業部内で知見があり、導入することにした https://tech.excite.co.jp/entry/2024/02/15/192547 

マークアップ周辺の変更 Smarty → Thmeleafに変更 事業部内の別サービスでThymeleafを使用しており十分な知見がある Tailwind CSSを導入 適切な分割がされておらず、複数のファイルにバラバラに記載されている PC表示とモバイル表示で2つのファイルが存在していた Alpine.jsを導入 アプリケーションの性質上、JavaScriptを使用した複雑な処理がない ナビゲーション等で活用 https://tech.excite.co.jp/entry/2025/06/23/110637 

デザインシステムの整備 https://tech.excite.co.jp/entry/2024/12/04/082041 Figmaを活用したデザインシステム 担当のデザイナー中心に見た目を整備する 旧アプリケーションでは整備されておらず、色や文字の大きさ、間隔がバラバラ リプレイスにあたり、カラー、タイポグラフィ等を整備 

レスポンシブデザイン PC表示とモバイル表示を1つのテンプレートに統一化 これまでは1つ機能の修正に対して、2つのファイルを変更していた 統一化したことで、修正漏れを無くすことができた 

ALBのルール/パス条件で振り分ける方法の検討 ALBのルール/パス条件で振り分ける 1つのルール内で設定できる条件値の上限がある リリース毎にインフラレベルで変更しなくてはらならない 

nginxを使用した新旧の切り替えを採用 1つのタスク内に4つのコンテナを配置 nginxのlocationディレクティブを使用し、新旧の切り替えを実現 少し大きめのサイズに変更し、切り替え完了までのサーバーコスト増加を受け入れる 

locationディレクティブで切り替える server { # リプレイスしたページはSpring Bootコンテナを参照する location ~ ^/genre/ { proxy_pass http://springboot; } location ~ ^/ranking/ { proxy_pass http://springboot; } # リプレイス前のページはPHPコンテナを参照する location / { proxy_pass http://php; } } 

段階的リプレイスのメリット/デメリット メリット 全てのページのリプレイスを待つ必要がなく、段階的にリリースができる 問題が発生した場合に、locationのみを変更すればよく全体への影響を抑えられる デメリット 旧ページのみだけの修正が入ると、新旧のどちらも面倒を見なくてはならない ページ毎に見た目が異なってしまう 切り替えが完了するまでサーバーコストが増加してしまう 

新アプリケーションに移行した結果: 定量面 期間 / 人数 2024年6月 〜 2025年1月 / 3名(エンジニア2名、デザイナー1名) コンテナ稼働台数の減少 2vCPU / 4GiB / 5台 → 1vCPU / 2GiB / 2台 Lighthouseのスコア改善 移行前のデータは残っていないが、移行後にパフォーマンス面、アクセシビリティ面 において十分な結果を出せた 

新アプリケーションに移行した結果: 定性面 開発体験の向上 見通しの悪いアプリケーションコードから脱却できた OpenAPI GeneratorによるAPIクライアントの自動生成でサクサク開発できる トップページに新機能の開発がしやすくなった 今回採用した技術で、その後の社内管理画面のリプレイスも進めることができた AIコーディングエージェントの活用 適切な粒度でコンポーネント・ファイル分割をしたことで、AIコーディングエージェ ントの出力する結果を受け入れやすくなった 

まとめ PHP5 / 独自フレームワーク → Java21 / Spring Boot3 に移行した 1つのECSタスクにまとめる + nginxのlocationディレクティブを採用し、段階的なリプ レイスを実現した 移行した結果、定量面と定性面でよい結果を残すことができた