Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エキサイトブログの トップページを 段階的にリプレイスする
Search
Kazuki Yamagata
August 26, 2025
Technology
0
110
エキサイトブログの トップページを 段階的にリプレイスする
Kazuki Yamagata
August 26, 2025
Tweet
Share
More Decks by Kazuki Yamagata
See All by Kazuki Yamagata
エキサイトブログにおけるAzure→AWSへの移行とIaCの取り組み
zsp2088dev
0
1
Other Decks in Technology
See All in Technology
モダンフロントエンド 開発研修
recruitengineers
PRO
8
4.6k
知られざるprops命名の慣習 アクション編
uhyo
11
2.8k
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
450
ZOZOTOWNフロントエンドにおけるディレクトリの分割戦略
zozotech
PRO
18
5.8k
そのコンポーネント、サーバー?クライアント?App Router開発のモヤモヤを可視化する補助輪
makotot
4
760
アジャイルテストで高品質のスプリントレビューを
takesection
0
140
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
29
10k
Product Management Conference -AI時代に進化するPdM-
kojima111
0
260
自社製CMSからmicroCMSへのリプレースがプロダクトグロースを加速させた話
nextbeatdev
0
300
AI時代に非連続な成長を実現するエンジニアリング戦略
sansantech
PRO
1
610
クラウドセキュリティを支える技術と運用の最前線 / Cutting-edge Technologies and Operations Supporting Cloud Security
yuj1osm
2
110
「AI2027」を紐解く ― AGI・ASI・シンギュラリティ
masayamoriofficial
0
140
Featured
See All Featured
Code Review Best Practice
trishagee
70
19k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Navigating Team Friction
lara
189
15k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Building Adaptive Systems
keathley
43
2.7k
Transcript
エキサイトブログの トップページを 段階的にリプレイスする 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ディレクティブを採用し、段階的なリプ レイスを実現した 移行した結果、定量面と定性面でよい結果を残すことができた