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

はじめに

エキサイト株式会社 Webエンジニアの山縣(@zsp2088dev)です。 普段の業務では、エキサイトブログの新機能開発や運用、その他メディア関連のサービスも兼任しています。

先日TECH Street主催のイベントで登壇した「エキサイトブログのトップページを段階的にリプレイスする」について、登壇内で発表したことと補足内容について紹介します。

イベント内容

以下のイベントで登壇しました。 詳細はリンク先をご参照ください。

www.tech-street.jp

登壇資料

リプレイスに至った背景

エキサイトブログのトップページには、エキサイトブログに投稿した数多くのブログをジャンルやテーマごとにまとめて掲載しています。 トップページは、新機能開発や機能修正の頻度が少ないものの、サービス全体の顔となる重要なページです。 そのため、デザインの統一性やアクセシビリティの改善なども取り組むべき課題として認識していました。

技術的な側面に着目すると、長年の間、PHP5系かつ社内独自フレームワークで稼働しており、テストコードも存在しない環境となっていました。 このような状況で、新機能の開発や既存機能の修正に時間がかかってしまうことも多く、技術的な負債も無視できない状況になっていました。

そんな中、事業部内ではSpring Boot 3 / Java 21を使用したアプリケーションの構築への知見が溜まってきたことを受けてトップページをリプレイスすることに決定しました。

エキサイトブログ 20周年

システム構成

トップページのリプレイスで採用した主な技術スタックは以下の通りです。

  • Spring Boot 3 / Java 21: アプリケーション
  • Thymeleaf: テンプレートエンジン
  • Tailwind CSS: スタイリング
  • Alpine.js / htmx: JavaScriptライブラリ
  • OpenAPI / OpenAPI Generator: APIクライアントの自動生成
  • AWS Copilot CLI: コンテナアプリケーションの管理

段階的なリプレイスを目指した理由

トップページのリプレイスにあたり、全機能を一括でリリースするのではなく、段階的な移行戦略を採用しました。 全てのアプリケーションを完成させてから一括切り替えの場合、問題が発生した際に全体をロールバックする必要があり、影響範囲が大きくなってしまいます。 そこで、アプリケーションを作成しながら段階的にリリースすることで、影響範囲を小さく抑えながらリリース後のバグや問題に対処できるようにしました。

具体的には、まず参照頻度の低い静的なページ(有料プランの案内、利用規約など)からの制作に取り組み、順次リリースをすることとしました。 これにより、リスクを最小限に抑えながら新システムの動作確認ができ、その後の段階的なリプレイスの流れを確立することができました。

段階的リプレイスを実現する

エキサイトブログで稼働している多くのアプリケーションは、Amazon ECS上で、nginxとアプリケーションを一つのタスクにする構成で運用しています。 新しく作成するSpring Boot 3 / Java21のアプリケーションを同一のタスクにまとめ、nginxのlocationディレクティブを使用して新旧の切り替える方法を採用しました。

本手法を導入するにあたり、新旧の切り替えが完遂するまでのサーバーコストの増加や、リプレイス中の新旧の双方の機能追加が大変といった問題があります。 これについては、サーバーコストの増加を許容し、リプレイス中は既存機能に手を加えないことで対応することとしました。

server {
    # リプレイスしたページはSpring Bootコンテナを参照する
    location ~ ^/genre/ {
        proxy_pass http://springboot;
    }

    location ~ ^/ranking/ {
        proxy_pass http://springboot;
    }

    # リプレイス前のページはPHPコンテナを参照する
    location / {
        proxy_pass http://php;
    }
}

ALBのリスナールールを使用した振り分けの検討

当初、段階的リプレイスの実現方法として、Application Load Balancer(ALB)のリスナールールを使用した振り分けも検討しました。 ALBのリスナールールでは、パスごとに異なるターゲットグループへトラフィックを振り分けることができます。 しかし、この方法には以下の制約があり、見送ることとしました。

  • パスのルールの登録上限が5つまでである
  • AWS Copilot CLIYAML パッチオーバーライドの設定管理が煩雑になる
  • 設定変更のたびに時間がかかる

移行した結果

定量面と定性面でよい結果を残すことができました。 記事執筆時点でトップページは安定稼働しており、特にこれといって困っていることはありません。

関連リンク

スライド中で紹介した記事のリンクです。

tech.excite.co.jp

tech.excite.co.jp

tech.excite.co.jp

おわりに

本記事では、PHP5系を使用した独自フレームワークのアプリケーションを、Spring Boot 3 / Java21を使用したアプリケーションに段階的に切り替えた背景や方法についてまとめました。

旧アプリケーションからリプレイスしたことで、技術的負債を抱えたPHP5システムからの脱却することができ、開発効率の向上や安定した稼働を実現できました。また、アプリケーションのコードも整備できたことで、AIコーディングエージェントの生成するコードの質の向上を実感しており、今後の開発にも期待できます。

本記事が今後リプレイスを検討している方々の参考になれば幸いです。最後まで読んでいただき、ありがとうございました。