※この記事は、2025年8月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
山縣 寿樹（Yamagata Kazuki）
エキサイト株式会社
Webエンジニア
2021年にエキサイト株式会社へ新卒入社し、現在5年目。バックエンドを主軸に、フロントエンドやインフラ領域も担当しています。エキサイトブログの開発に加え、最近は他サービスにも関わり、複数プロジェクトを横断して開発・運用をしています。
山縣：今回は、段階的なリプレイスというテーマでお話しします。
まず、「移行前の旧アプリケーションが抱えていた構成や課題」についてご説明します。
次に、「リプレイス後の新アプリケーションの構成や、新たに導入したもの」について説明いたします。そして最後に、段階的なリプレイスを実現するために検討・実装した内容と、リプレイス後の結果についてお話しさせていただく予定です。
はじめに、エキサイトブログについて簡単にご紹介します。
このサービスは昨年20周年を迎え、現在まで約20年間続いているサービスです。これまで多くのブロガーの皆様に記事を書いていただき、現在でもご愛用いただいております。中には10年以上も利用してくださり、非常に多くの記事を投稿してくださる方もいらっしゃるなど、皆様に愛されているサービスです。
リプレイス前の構成図と検討事項
それではまず初めにリプレイス前の旧アプリケーションがどのようなものだったか、その構成についてご説明します。
元々、今回リプレイスの対象としたWebフロント部分は、PHP5系で、かつ独自フレームワークで動作していました。このアプリケーションはAWS上で稼働しており、バックエンドのREST APIを呼び出し、最終的にデータベースにアクセスするというシンプルな構成でした。今回の移行対象となったのは、このトップページを含むWeb部分です。
コードを確認したところ、上図のように非常に古く、メンテナンスされていない箇所が残っていました。最長で11年前から変更されていないコードも存在しており、バージョン管理システムがSVNだった時代（当時のまま）から残っているものもありました。現在ではGitを使用していますが、その当時のコードがそのまま残存していたのです。このような状況下では、新機能の開発や既存機能の修正は非常に大変でした。また、過去の開発メンバーは、私が入社した時点ですでに退職しており、開発関連のドキュメントも整備されていませんでした。このように、非常に困難な状況からのスタートとなりました。
旧アプリケーションの構成ですが、元々はVMで稼働していましたが、私が入社後、AWSへの移行とコンテナ化を行い、ECS上で稼働するようになりました。しかし、その際もアプリケーション自体にはあまり手を加えられなかったため、新機能開発や既存機能の修正には依然として苦労していました。
ECSタスク内の構成としては、ALBで受けたリクエストをまずnginxで受け、それをPHPに流していました。そして、そのPHPからバックエンドのAPIを呼び出すという流れになっていました。
トップページのリプレイスを始めるにあたり、いくつか検討事項がありました。
エキサイトブログは長年続いているサービスであり、長くメンテナンスされていなかったため、技術的な課題を抱えていました。Webサービスとして提供している以上、メンテナンスでサービスを停止するとユーザーにご迷惑をおかけしてしまいます。そのため、できるだけサービスを停止しない形で移行できる方法が望ましいという話になりました。その上で、リプレイス後にどのような技術を使うか、そして具体的にどうやって切り替えていくかという方針を話し合って決めました。
また、リプレイスにあたり、旧アプリケーションで実際にどのページが使われているかを一つひとつ調査する必要がありました。アプリケーションのコード上から、また実際にWebページを使いながら、「こんなページがあったのか」「これは本当に使われているのか」といった点を洗い出しました。当然ながら、コード上には残っていても実際には参照されていないページも数多く存在しました。そうしたページについては、エンジニアの判断だけでは削除できないため、ビジネス側のメンバーと協議しながら、不要なものは削除し、必要なものは残すという判断を進めていきました。
新しいアプリケーションの構成
次に、新しいアプリケーションの構成についてお話しします。簡潔に言いますと、旧来のPHPの部分をJava21とSpring Boot3に置き換えた形となります。ここからは、その詳細について具体的にご説明します。
まずJava21とSpring Boot3を採用した理由ですが、過去にバックエンドAPIをPHPからJavaへ切り替えた経緯があり、事業部内ですでにJavaやSpring Bootに関する知見が溜まっていたことが大きいです。私自身も経験があったため、非常に採用しやすい状況でした。また、すでにJavaで構築されている資産を有効活用できる点も魅力でした。
具体的には、マルチモジュール構成を採用することで、既存の必要なコードを再利用できる設計になっており、これも採用を強く後押しした理由の一つです。さらに、バックエンドAPIはOpenAPIに沿って構築されており、OpenAPI Generatorを利用してAPIクライアントを自動生成しました。
これにより、バックエンドAPIの呼び出しを効率的に実装でき、移行作業をスピーディーに進めることができました。旧アプリケーションでは、エンドポイントごとに手動でコードを書いており非常に手間がかかっていましたが、他サービスでOpenAPI Generatorの導入効果が高いという話を聞き、エキサイトブログでも導入することにしました。
マークアップ周辺にもいくつか変更を加えました。
まず、テンプレートエンジンについては、PHPで使っていたSmartyから、Spring Bootへの移行に伴いThymeleafに変更しました。これも、社内の別サービスで利用実績があり、知見が十分にあったためです。次に、CSSについてはTailwind CSSを導入しました。旧アプリケーションでは、独自に作られた汎用的なCSSがあったり、適切なファイル分割がされておらず複数のファイルにスタイルが散在していたりしました。
さらに、PC表示用とモバイル表示用でファイルが分かれており、一つの機能を修正する際に二つのファイルを変更する必要があるなど、非常に煩わしい状況でした。これを解決するため、レスポンシブデザインに対応し、効率的に開発できるよう改善しました。また、JavaScriptについては、軽量なライブラリであるAlpine.jsを導入しました。トップページはブロガーの記事をまとめたポータルサイトという性質上、動的な複雑な処理が少ないため、軽量なライブラリで十分だと判断し、主にナビゲーションなどで活用しています。
デザイン面に関しても、デザイナーから整備したいという要望が上がり、デザインシステムの整備を進めることになりました。今回のリプレイスにあたり、Figmaを活用したデザインシステムを構築し、担当デザイナーを中心に見た目を整えていきました。旧アプリケーションでは、色や文字の大きさ、要素間の間隔などがバラバラで整備されていませんでしたが、今回のリプレイスでカラーやタイポグラフィなどを整理し、全体的にすっきりとした、見栄えの良いデザインにすることができました。
先ほども少し触れましたが、今回はレスポンシブデザインに対応し、これまでPC表示とモバイル表示で分かれていたテンプレートを一つに統一しました。以前は、例えば「index.tpl」と「index.sp.tpl」のようにファイルが分かれており、一つの機能を修正する際には二つのテンプレートファイルと、それぞれのスタイルファイルを変更する必要がありました。このため修正漏れが発生することもありましたが、テンプレートを統一したことで、そうした問題をなくすことができました。
次に、移行をどのように進めるか、その手法の検討についてお話しします。
我々のアプリケーションはAWS上で稼働しており、ALB（Application Load Balancer）を利用してECSへの振り分けを行っています。そのため、ALBのルールにあるパス条件を使えば、例えば「/genre/」や「/ranking/」といった特定のパスへのアクセスは新しいアプリケーションに、それ以外のアクセスは既存のアプリケーションに振り分ける、といったことが可能です。
しかし、この方法にはいくつかの課題がありました。まず、一つのルール内で設定できる条件値の上限が5つまでとなっており、30から40ページある移行対象のすべてをカバーするには不十分でした。また、リリースごとにインフラレベルでの変更が必要になる点も、運用上好ましくないと考え、この方法は見送ることになりました。
nginxを用いた切り替え方法では、1つのタスク内に4つのコンテナ（nginx、新アプリ、旧アプリ、firelens）を配置する必要があったため、タスクのサイズを少し大きめに変更しました。これにより、切り替えが完了するまでの期間はサーバーコストが増加しましたが、その点は許容することにしました。
段階的なリプレイスのメリット/デメリットと結果について
今回採用した段階的リプレイスのメリットとデメリットをまとめます。
メリットとしては、全てのページのリプレイス完了を待つ必要がなく、段階的にリリースできる点が挙げられます。これにより、一括リリース時のリスクを避け、問題が発生した場合でも影響範囲を限定しやすくなります。例えば、何か問題が発生しても、nginxのロケーション設定を変更するだけで、すぐに全体への影響を抑えることが可能です。
一方でデメリットもあります。移行期間中は旧ページと新ページの両方をメンテナンスする必要があり、例えば旧ページのみに修正が入る場合、両方の面倒を見なければなりません。また、ページごとに見た目が異なってしまうという問題も発生します。さらに、切り替えが完了するまでは、新旧両方のアプリケーションを稼働させるため、サーバーコストが増加してしまいます。
新アプリケーションへの移行結果について、まず定量面からですがサーバーリソースに関しては、以前は2vCPU/4GiBのコンテナを5台稼働させていましたが、移行後は1vCPU/2GiBのコンテナ2台で運用できるようになり、約75%のリソース削減を達成しました。また、Lighthouseのスコアも大幅に改善され、パフォーマンス面、アクセシビリティ面において十分な結果を出すことができました。
次に、定性的な結果についてです。
まず、開発体験が大きく向上しました。古いバージョンのPHPや整備されていないコードから脱却し、クリーンなアプリケーションコードになったことで、新機能の開発がしやすくなりました。また、OpenAPI GeneratorによるAPIクライアントの自動生成で、バックエンド連携もサクサク開発できるようになりました。今回採用した技術で得た知見は、その後の社内管理画面のリプレイスにも活かすことができ、脱却して本当に良かったと感じています。
さらに、最近のトレンドであるAIコーディングエージェントの活用という点でも良い効果がありました。適切な粒度でコンポーネントやファイルを分割したことで、AIコーディングエージェントが出力する結果を受け入れやすくなったと感じています。
まとめ
以上からこの移行の結果、定量面・定性面ともに良い結果を残すことができたと考えております。
私からの発表は以上となります。
▼▼ ぜひ他登壇者の発表レポートもご覧ください
