Next.js を選定した ZOZOTOWN のフロントエンドリプレイス、その全体像 / zozotown frontend replacement project

Transcript

1. Next.js を選定した ZOZOTOWN のフロント エンドリプレイス、
 その全体像
 株式会社ZOZO
 ZOZOTOWN開発本部
 
 武井 勇也 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 2 株式会社ZOZO
 ZOZOTOWN開発本部 ZOZOWEB部
 リプレイスバックエンドブロック
 武井 勇也
 2020年4月 新卒入社 ZOZOTOWN 開発本部に配属
 2021年10月 フロントエンドリプレイスを担当開始
 2023年4月 リプレイスバックエンドチーム異動
 ZOZOTOWNのWebのリプレイスを担当
 Twitter : @takewell_ Zenn : @takewell

3. © ZOZO, Inc. 目次
 • Next.js でのリプレイスに至った経緯 • フロントエンドリプレイス • Next.js をプロダクション投入するためのレンダリング • 振り返り • 今後について • まとめ 3
4. © ZOZO, Inc. 4 Next.js でのリプレイスに至った経緯

5. © ZOZO, Inc. リプレイス開始前
 5 • 一つのアプリケーションにすべての責務を集 約したモノリシックな構成 • Classic ASP/VBScriptで実現できない機能 は独自ライブラリを作成し対応 • スケールに成功し日本最大級のファッション 通販サイトとして成長 ※ 説明のため簡略化しています
6. © ZOZO, Inc. さらなる成長のための課題
 6 • 技術スタックが時代的に一般的ではなくなってきているため • クラウド化が困難 • OSSやSaaSのSDK導入が困難 • 人材採用が困難 • モノリシックなため • 責務が集中し、ロジックが密結合なため変更コストが高い • 開発組織のスケールが困難
7. © ZOZO, Inc. リプレイスの目的
 7 これを達成できる組織にする

8. © ZOZO, Inc. 8 柔軟なシステム 開発生産性 技術のモダン化 採用強化 • セールなどの高負荷時 にスケール可能 • 技術情報のアウト プットによるプレ ゼンス向上 • レガシー技術による 独自実装の減少 • 汎用ミドルウェア、 SaaSを利用可能 • 並行開発 • リリースの自動化 リプレイスの効果

9. © ZOZO, Inc. フロントエンドリプレイス前の構成
 9 ※ 説明のため簡略化しています • 達成 • ビジネスロジックをマイクロサービスに移譲 • クラウド化 • 人材採用の加速 • インフラ基盤のベースを構築 • 未着手 • Webサーバーのリプレイス
10. © ZOZO, Inc. 10 フロントエンドリプレイス

11. © ZOZO, Inc. ホーム画面のリプレイスをフロントエンドリプレイス Phase1 と設定
 11 Phase1 の狙い • 新フレームワークの導入 • インフラ基盤を構築する ホーム画面から始めた理由 • ホーム画面で利用しているAPIは、大部分が新BFF(Backend For Frontend) API から提供されており、レガシーシステムへの依存が比較的少ない • アクセス数や機能が多く、開発や運用のナレッジを蓄積しやすい • サービスの象徴的ページであり、開発のモチベーションが湧きやすい
12. © ZOZO, Inc. 新フレームワークは Next.js を選定
 12 選定理由 • Reactでの開発をwebpackの細かい設定なしに始められる • ページごとの SSR/SG などのレンダリング手法を柔軟に切り替えることができる • ルーティングとビルドコード分割の提供している • 数々のパフォーマンス最適化など新機能が毎年リリースされており、アクティブに開発され ているため将来性も期待できる 　開発生産性◎　パフォーマンス◎　人材採用のポテンシャル◎
13. © ZOZO, Inc. フロントエンドリプレイス後のシステム構成
 13 • (1) ホーム画面のパスをリプレイス後のシステムへ、ホーム画面以外のパスは既存 システムへリクエストをルーティング • (2) リプレイス後のシステムと既存オンプレミスのIISサーバーとセッションデータ共有 や、既存システムとの通信も可能にしている
14. © ZOZO, Inc. 14 Next.js をプロダクション
 投入するためのレンダリング

15. © ZOZO, Inc. レンダリング
 15 • Next.js には様々なレンダリング手法があるが、SSRするか否かがポイント • SSR が必要な理由 • メタタグに動的データが必要 • ファーストビューに表示されるUIはローディングなどを挟まず表示したい • セールやキャンペーンの開始や終了のタイミングに合わせて時限式に切り替わるUIを 提供したい • SEO は極めて重要、懸念はないようにしたい
16. © ZOZO, Inc. レンダリングを選ぶためのフローチャート 16 • SEO効果に影響するコンテンツ • メタタグ • ファーストビューに表示される • 検索エンジンにクローリングして欲しいものか • キャッシュ可能なコンテンツ • ユーザーによって変化しない • 時間で動的に切り替わる
17. © ZOZO, Inc. SSR の問題点
 17 • アプリケーションを監視するエンジニアのオンコール体制の構築が必要 • サーバーの費用的なコストが生じる • Node.js はシングルスレッド故に SSR のようなCPUバウンドな処理を同時処理された場 合、イベントループがブロックされ、性能が低下する可能性がある ZOZOTOWN はセールのタイミングなどリクエストがスパイクすることが あります。 快適に買い物してもらうためには、この高負荷に耐えられる必要があります
18. © ZOZO, Inc. SSR の問題点に対する対策
 18 • リクエスト(req/sec) の見積もりと、負荷性能試験の実施 • CDN を用いたキャッシュ • SEOに無関係な場合、CSR を積極的に利用していく • Node.js のマルチプロセス化によるコスト最適化
19. © ZOZO, Inc. 19 振り返り

20. © ZOZO, Inc. 必要となるスキル 20 ハードスキル • マークアップ : CSS, アニメーション, アクセシビリティー • FEアプリケーション : ステート管理, レンダリング設計, ミドルウェアのノウハウ • BFFレイヤー : Node.js SSR/SG などの設計 マイクロサービスAPIのノウハウ • FE インフラ : Docker, GitHub Actions, CDN, 開発環境基盤のノウハウ • 既存システム : VBScript, 独自ミドルウェアのノウハウ ソフトスキル • 未知の知識を幅広く・早く吸収できる探索学習力 • 他部署と共通認識を形成できるコミュニケーション力・推進力 • 現場特性から最適なソリューションを判断・提案できる力
21. © ZOZO, Inc. よかった取り組み 21 • 他プロジェクトの兼任をやめてリプレイス専属FEチームを発足させた • やらないことを決めた • ビックバンリリースはしない • 大きい機能改修はしない • レスポンシブサイトにはしない • 技術顧問古川さんに定期的に相談し、客観的に設計レビューをいただく
22. © ZOZO, Inc. 22 今後について

23. © ZOZO, Inc. 23 ～2021 Webフロントエンド リプレイス マイクロサービス 2022 2023 2024 HOME 会員基盤Phase1 カートリプレイス Phase2 お気に入り 会員基盤Phase3 検索結果 商品詳細 会員基盤Phase2 カート決済面リプレイス 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 現行システムの 完全削除に向けた後始末 商品API拡充 会員登録情報 カート決済面 一覧系、その他 検索結果残対応 注文リプレイス 注文履歴リプレイス 商品基盤構築 2025 1Q 2Q 3Q 注文リプレイス Phase1.0 注文処理の非同期化 事前調査 事前調査 注文履歴 検索系APIリプレイス 検索バッチリプレイス サイトリプレイス ロードマップ 遂行
 フロントエンドリプレイスPhase1
 完了 未着手 進行中
24. © ZOZO, Inc. Core Web Vitals の向上 24 Desktop Mobile 改善しているが、劇的な変化には至らず...! 伸び代まだまだあります！ Before After
25. © ZOZO, Inc. その他やる可能性のあるもの 25 • パフォーマンス改善 • アクセシビリティー対応強化 • デザインシステム構築 • マイクロフロントエンドな設計
26. © ZOZO, Inc. まとめ 26 • ホーム画面のNext.js化をフロントエンドリプレイス Phase1 というマイルストーンに設定した • Next.js 化のプロダクション投入するためにはレンダリング設計が肝 • システムリプレイスは多岐にわたるスキルが必要となる。加えて、心構えやそれに至るまでのステップも 重要