ZOZOTOWNマイクロサービス化に向けたサービス粒度の話/Service granularity for ZOZOTOWN microservices

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ  EC基盤本部　ECプラットフォーム部  高橋智也  2011年、株式会社スタートトゥデイ（現：株式会社ZOZO）中途入社。  バックエンドエンジニアとして、ZOZOTOWN、WEARにおける  多数のプロジェクトに従事。  現在は、バックエンド領域において、ZOZOTOWNリプレイス  プロジェクトを推進する部署を担当。    2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© ZOZO Technologies, Inc. ZOZOTOWNリプレイスの目的  5 柔軟なシステム開発生産性技術のモダン化採用強化 ● 中長期目標：商品取扱高5,000億円を捌けるシステム  ● セールなどの高負荷イベント時におけるスケール可能な柔軟なシステム  ● 事業における各種施策を適切なタイミングで展開したい  ● 事業案件だけでなく、作り手視点でのやりたいことにも時間を使えるように  したい  ● エンジニアとしての成長に繋がる経験が出来ることによる採用強化を図りたい  ● レガシー技術を利用していることによる独自実装ケースを減らしたい  ● 新メンバーがZOZOTOWNのシステムを理解するための時間を減らしたい  ● Datadog、SentryなどのSaaSを利用し運用監視を効率化したい  ● 技術情報のアウトプットによるZOZOエンジニアの認知を向上させたい 

Slide 6

Slide 6 text

© ZOZO Technologies, Inc. ZOZOTOWNリプレイスの目的  6 柔軟なシステム開発生産性技術のモダン化採用強化 ● お客様にいつでも快適に買い物をしていただけるサービスを提供するため  ● ZOZOTOWNの成長のため  ● 中長期目標：商品取扱高5,000億円を捌けるシステム  ● セールなどの高負荷イベント時におけるスケール可能な柔軟なシステム  ● 事業における各種施策を適切なタイミングで展開したい  ● 事業案件だけでなく、作り手視点でのやりたいことにも時間を使えるように  したい  ● レガシー技術を利用していることによる独自実装ケースを減らしたい  ● 新メンバーがZOZOTOWNのシステムを理解するための時間を減らしたい  ● Datadog、SentryなどのSaaSを利用し運用監視を効率化したい  ● 技術情報のアウトプットによるZOZOエンジニアの認知を向上させたい  ● エンジニアとしての成長に繋がる経験が出来ることによる採用強化を図りたい 

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© ZOZO Technologies, Inc. ZOZOTOWNのアーキテクチャ  9 IIS (Web) DB 推薦基盤 ID基盤 DB DB etc. AWS GCP ストアドストアドストアド API Gateway 商品基盤検索基盤現在  IIS (API) ※一部省略している箇所があります  PC / SP ブラウザ iOS / Android App オンプレ一部の機能がマイクロサービスとして稼働しており、最終的なマイクロサービスの形が未定義 

Slide 10

Slide 10 text

© ZOZO Technologies, Inc. ZOZOTOWNのアーキテクチャ  10 オンプレ IIS (Web) DB 推薦基盤 ID基盤 DB DB etc. AWS GCP ストアドストアドストアド API Gateway 商品基盤検索基盤今後（仮）  IIS (API) 会員基盤カート決済基盤セッション基盤ログ基盤 ※一部省略している箇所があります  PC / SP ブラウザ iOS / Android App

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© ZOZO Technologies, Inc. マイクロサービス粒度の考慮ポイント - 開発における側面  ● システムにおける機能とデータ、データとデータの関連性を把握する  ○ サービス単独での意思決定やデプロイを含めた効率的な開発フローを実行したい（自律性）  ○ 分散トランザクションによるサービス間データ不整合の可能性を極力小さくしたい    ■ 機能：商品詳細、商品検索、推薦、カート投入、購入、ログイン、会員登録、会員メニューなど  ■ データ：商品情報、在庫、ブランド、ショップ、カテゴリ、会員、外部ID連携、注文など    ● 事業展開において、どの機能に対する開発が多いのか把握する  ○ 特定のチームに開発が偏らないように、チームの担当サービス、人員配置を決定したい    ■ 材料：JIRA、GitHub、開発ロードマップなど          15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© ZOZO Technologies, Inc. マイクロサービス粒度の考慮ポイント - 運用における側面  ● 事業特性や過去実施イベント、障害記録を分析し、  高負荷になる機能を把握する    ○ セール、ZOZOWEEK、福袋  ○ 過熱商品販売  ○ LINE、メルマガ、PUSH配信  ○ PayPayキャンペーン  ○ ショップクーポン  　　　　　↓  ○ カート投入、購入  ○ 認証  ○ 商品検索    18 A B C D A B C D A C D B モノリス  マイクロサービス 

Slide 19

Slide 19 text

© ZOZO Technologies, Inc. マイクロサービス粒度の考慮ポイント - 運用における側面  ● 事業特性や過去実施イベント、障害記録を分析し、  高負荷になる機能を把握する    ○ セール、ZOZOWEEK、福袋  ○ 過熱商品販売  ○ LINE、メルマガ、PUSH配信  ○ PayPayキャンペーン  ○ ショップクーポン  　　　　　↓  ○ カート投入、購入  ○ 認証  ○ 商品検索    運用において、リソース増強が必要な機能をきちんと把握し、  効果的に実施出来るようにする  19 A B C D A B C D A C D B モノリス  マイクロサービス 

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© ZOZO Technologies, Inc. マイクロサービス粒度の考慮ポイント - 組織における側面  ● 業務知識の専門性が高い機能を把握する  ○ 技術スタックや人員配置・教育面で、他サービスと特徴が異なる可能性がある  ■ カート投入、購入  ■ 商品検索  ■ 推薦    ● 現在の開発体制と、マイクロサービスに合わせた組織体制のギャップを把握する  ○ 大幅な組織変更になってしまうのを極力避けたい  ■ 新任チームリーダーの必要性、教育  ■ チームビルディングの難易度  ■ チーム間の連携    21

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© ZOZO Technologies, Inc. （再掲）ZOZOTOWNのアーキテクチャ  23 オンプレ IIS (Web) DB 推薦基盤 ID基盤 DB DB etc. AWS GCP ストアドストアドストアド API Gateway 商品基盤検索基盤今後（仮）  IIS (API) 会員基盤カート決済基盤セッション基盤ログ基盤 ※一部省略している箇所があります  PC / SP ブラウザ iOS / Android App

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© ZOZO Technologies, Inc. （補足）サービス横断による統制  ● 開発ガイドラインの整備  ○ インフラ、iOS、Android、Backend、Frontend、DBなど    ● 標準技術スタックの定義  ○ 人事（採用・異動）と教育面で困るため  ○ あくまでも標準であり、定義外の技術を使用出来ないということではない    ● リリースフローの標準化  ○ CI/CDによるデプロイの話ではなく、ある特定の要件を満たした案件を進める場合に必要なフロー  ○ 企画、設計、テストレビューなど  ○ 関係各所との調整漏れやセキュリティリスクの露呈による手戻りを回避するため  25

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© ZOZO Technologies, Inc. まとめ  ● マイクロサービス粒度の考慮ポイント  　マイクロサービス粒度を考える上で我々が重視した考え          ○ 開発における側面  ■ システムにおける機能とデータ、データとデータの関連性を把握する  ■ 事業展開において、どの機能に対する開発が多いのか把握する    ○ 運用における側面  ■ 事業特性や過去実施イベント、障害記録を分析し、高負荷になる機能を把握する    ○ 組織における側面  ■ 業務知識の専門性が高い機能を把握する  ■ 現在の開発体制と、マイクロサービスに合わせた組織体制のギャップを把握する  28 開発、運用、組織の側面から考えたときに、  事業が展開しやすいアーキテクチャとなっているのか。 

Slide 29

Slide 29 text

No content