エキサイトブログのトップページを段階的にリプレイスする

エキサイトブログのトップページを段階的にリプレイスする 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ディレクティブを採用し、段階的なリプレイスを実現した移行した結果、定量面と定性面でよい結果を残すことができた

エキサイトブログのトップページを段階的にリプレイスする

エキサイトブログのトップページを段階的にリプレイスする

Kazuki Yamagata

More Decks by Kazuki Yamagata

Other Decks in Technology

Featured

Transcript