Share
Embed

Slide 1

Slide 1 text

ZOZOTOWNアプリAPIリプレイスに おける、リスクとスピードの『最適解』 株式会社ZOZO ZOZOTOWN開発本部 ZOZOTOWN開発2部 アプリバックエンドブロック 髙井 隆大 Copyright © ZOZO, Inc. 1

Slide 2

Slide 2 text

© ZOZO, Inc. 株式会社ZOZO ZOZOTOWN開発本部 ZOZOTOWN開発2部 アプリバックエンドブロック 髙井 隆大 好きなお笑い芸人：エバース 2

Slide 3

Slide 3 text

© ZOZO, Inc. 3 アジェンダ 背景と目的：なぜ今、リプレイスが必要なのか 全体方針：安全とスピードを両立する戦略 実践の軌跡：フェーズ1〜3での挑戦と葛藤

Slide 4

Slide 4 text

© ZOZO, Inc. 4 技術的負債の蓄積 長年の運用で肥大化したVBScript。コー ドの複雑化により、機能追加のコストとリ スクが年々増大していた。 採用と教育が困難 古い言語スタックではエンジニアの採用が 難しく、新規参画メンバーの学習コストも 高かった。 リプレイスの背景：レガシーがもたらす限界

Slide 5

Slide 5 text

© ZOZO, Inc. 5 VBScriptからの 脱却 型安全でエコシステムの 豊かなJavaへ。保守性 を劇的に向上させる。 マイクロサービス化 機能単位でサービスを 分離。開発効率と独立性 を確保する。 オンプレサーバー 縮退 オンプレサーバーの運用 負荷を削減。クラウドへ の移行を加速。 リプレイスの目的：将来への技術投資

Slide 6

Slide 6 text

© ZOZO, Inc. 6 ZOZOTOWNアプリのアーキテクチャ

Slide 7

Slide 7 text

© ZOZO, Inc. 8 リプレイスの全体方針 ストラングラーパターン 既存システムを一度に壊さず、少しずつ機 能を切り出して新APIへ移管。安全に進行 を進める。 LEGACY

Slide 8

Slide 8 text

© ZOZO, Inc. 9 リプレイスの全体方針 インターフェースの維持 レガシーAPIのI/Fをそのまま引き継ぎ、ク ライアント側の修正を不要にする。 API Gatewayで新旧を切り替える。 ↓ ↓

Slide 9

Slide 9 text

© ZOZO, Inc. 10 リプレイスの全体方針 カナリアリリース API Gatewayによるトラフィック制御。 10％→50％→100％のように、段階的に 切り替えることで、障害時のユーザー影響 を最小化。 Traffic Ratio New API: 10% / Legacy: 90%

Slide 10

Slide 10 text

© ZOZO, Inc. 10 ※調査結果を参考に各Phaseの対象エンドポイントを選定 調査項目 詳細内容 ロジック複雑度の算出 エンドポイントごとのコード行数や分岐数から大まかに複雑度を算 出。 接続経路の特定 各エンドポイントがどのマイクロサービスやストアドから情報を取得 しているか可視化。 事前準備：現状の徹底解剖

Slide 11

Slide 11 text

© ZOZO, Inc. 11 実績作り・Java習熟 現実解・DB接続確保 難関突破・セッション連携 リプレイスの流れ Phase 1 Phase 2 Phase 3 Ongoing

Slide 12

Slide 12 text

© ZOZO, Inc. 12 Phase 1 まずは「実績」と「経験」を積む

Slide 13

Slide 13 text

© ZOZO, Inc. 13 狙い 対象エンドポイント リプレイスの実績を作る チームのJava開発経験を増やす 複雑度が低い スコープが小さい Phase1：成功実績の構築

Slide 14

Slide 14 text

© ZOZO, Inc. 14 Phase 2 実務的な要求に応える「現実解」

Slide 15

Slide 15 text

© ZOZO, Inc. 15 並行案件に間に合わせるため、早急なアクセス経路確保が求められた。 レガシーAPIではDBへの直接アクセス経路があるが、リプレイス先APIはDBの直接アク セス禁止 進行中案件でリプレイス先APIからDBへのアクセス経路が必要 Phase2：課題

Slide 16

Slide 16 text

© ZOZO, Inc. 16 狙い 対象エンドポイント DB直アクセス経路のリプレイス 並行稼働案件に間に合わせる DB直アクセス経路があるもの 複雑度が低い Phase2：DBアクセス経路確保

Slide 17

Slide 17 text

© ZOZO, Inc. 17 「過渡期API」という戦略的選択

Slide 18

Slide 18 text

© ZOZO, Inc. 18 ※理想を追いすぎず、スピードと将来性を両立させる「最適解」。 過渡期APIの活用 マイクロサービス化に多大な工数がかかるため、 VBScriptで実装しオンプレサーバーで一時稼働さ せる。 ロジックの分離 BFF層 vs マイクロサービス層を論理的に分離。将 来の完全なマイクロサービス化に備える。 「過渡期API」という戦略的選択

Slide 19

Slide 19 text

© ZOZO, Inc. 19 Phase 3 高負荷・難関機能への挑戦

Slide 20

Slide 20 text

© ZOZO, Inc. 20 サーバー縮退に合わせ、オンプレサーバーの負荷軽減を考慮する必要 セッション情報へのアクセス経路がない オンプレサーバー縮退スケジュールの確定 Phase3：課題

Slide 21

Slide 21 text

© ZOZO, Inc. 21 狙い 対象エンドポイント セッションへのアクセス経路の構築 オンプレ負荷を劇的に下げる セッションアクセスを伴うもの 高リクエストかつサーバー負荷が 高い Phase3：システム負荷の削減

Slide 22

Slide 22 text

© ZOZO, Inc. 22 Session基盤への経路

Slide 23

Slide 23 text

© ZOZO, Inc. 23 現在、そしてこれから。 Phase 1〜3を土台に、リプレイスはさらに加速中！ Coming Soon! フェーズ3以降のさらなる挑戦については、 ZOZO TECH BLOGで詳しく執筆予定です。 お楽しみに！

Slide 24

Slide 24 text

No content