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
1.6k
エキサイトブログの トップページを 段階的にリプレイスする
Kazuki Yamagata
August 26, 2025
Tweet
Share
More Decks by Kazuki Yamagata
See All by Kazuki Yamagata
エキサイトブログにおけるAzure→AWSへの移行とIaCの取り組み
zsp2088dev
0
9
Other Decks in Technology
See All in Technology
SREのプラクティスを用いた3領域同時 マネジメントへの挑戦 〜SRE・情シス・セキュリティを統合した チーム運営術〜
coconala_engineer
2
780
Claude Code for NOT Programming
kawaguti
PRO
1
110
広告の効果検証を題材にした因果推論の精度検証について
zozotech
PRO
0
210
今こそ学びたいKubernetesネットワーク ~CNIが繋ぐNWとプラットフォームの「フラッと」な対話
logica0419
5
490
AWS Network Firewall Proxyを触ってみた
nagisa53
1
240
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
5
1.6k
CDKで始めるTypeScript開発のススメ
tsukuboshi
1
560
ClickHouseはどのように大規模データを活用したAIエージェントを全社展開しているのか
mikimatsumoto
0
270
AIエージェントを開発しよう!-AgentCore活用の勘所-
yukiogawa
0
190
学生・新卒・ジュニアから目指すSRE
hiroyaonoe
2
770
Cloud Runでコロプラが挑む 生成AI×ゲーム『神魔狩りのツクヨミ』の裏側
colopl
0
140
Bedrock PolicyでAmazon Bedrock Guardrails利用を強制してみた
yuu551
0
260
Featured
See All Featured
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
170
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
230
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
0
3.4k
Believing is Seeing
oripsolob
1
58
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
WCS-LA-2024
lcolladotor
0
450
30 Presentation Tips
portentint
PRO
1
220
Mind Mapping
helmedeiros
PRO
0
90
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
320
Leading Effective Engineering Teams in the AI Era
addyosmani
9
1.6k
GitHub's CSS Performance
jonrohan
1032
470k
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ディレクティブを採用し、段階的なリプ レイスを実現した 移行した結果、定量面と定性面でよい結果を残すことができた