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
6
2k
AIエージェントの活用に重要な「MCP (Model Context Protocol)」とは何か
masayamoriofficial
0
200
シークレット管理だけじゃない!HashiCorp Vault でデータ暗号化をしよう / Beyond Secret Management! Let's Encrypt Data with HashiCorp Vault
nnstt1
2
120
「AI2027」を紐解く ― AGI・ASI・シンギュラリティ
masayamoriofficial
0
140
Postman MCP 関連機能アップデート / Postman MCP feature updates
yokawasa
1
210
AIとTDDによるNext.js「隙間ツール」開発の実践
makotot
6
770
実践AIガバナンス
asei
3
210
実運用で考える PGO
kworkdev
PRO
0
110
mruby(PicoRuby)で ファミコン音楽を奏でる
kishima
1
330
異業種出身エンジニアが気づいた、転向して十数年経っても変わらない自分の武器とは
macnekoayu
0
220
Understanding Go GC #coefl_go_jp
bengo4com
1
1.1k
実践データベース設計 ①データベース設計概論
recruitengineers
PRO
4
1.6k
Featured
See All Featured
Unsuck your backbone
ammeep
671
58k
For a Future-Friendly Web
brad_frost
179
9.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Making Projects Easy
brettharned
117
6.3k
Documentation Writing (for coders)
carmenintech
73
5k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Building Applications with DynamoDB
mza
96
6.6k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Designing for humans not robots
tammielis
253
25k
It's Worth the Effort
3n
187
28k
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ディレクティブを採用し、段階的なリプ レイスを実現した 移行した結果、定量面と定性面でよい結果を残すことができた