Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
FAANSを支えるアーキテクチャ
Search
tohae
February 17, 2022
Technology
0
1.4k
FAANSを支えるアーキテクチャ
https://zozotech-inc.connpass.com/event/236413/
ZOZO.go Meetupで発表した資料
tohae
February 17, 2022
Tweet
Share
More Decks by tohae
See All by tohae
ファッションコーディネートアプリWEARの リプレイスと組織の変遷 / wear-replace-2021
tohae
2
1.3k
Other Decks in Technology
See All in Technology
Github Copilot エージェントモードで試してみた
ochtum
0
140
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある / 2025.07.01 LLM品質Night
smiyawaki0820
1
470
AWS認定を取る中で感じたこと
siromi
1
140
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
220
rubygem開発で鍛える設計力
joker1007
3
340
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
1
3.6k
FOSS4G 2025 KANSAI QGISで点群データをいろいろしてみた
kou_kita
0
330
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
2
290
Node-REDのFunctionノードでMCPサーバーの実装を試してみた / Node-RED × MCP 勉強会 vol.1
you
PRO
0
130
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
160
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
1.5k
Featured
See All Featured
A designer walks into a library…
pauljervisheath
207
24k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Why Our Code Smells
bkeepers
PRO
337
57k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Bash Introduction
62gerente
614
210k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
940
Documentation Writing (for coders)
carmenintech
72
4.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
810
Transcript
FAANSを支えるアーキテクチャ 2022/02/17 ZOZO.go Meetup 株式会社ZOZO メディア開発本部 本部長 脇阪 博成 Copyright
© ZOZO, Inc.
© ZOZO, Inc. 株式会社ZOZO メディア開発本部 本部長 脇阪 博成 2019年6月入社 入社後はWEARのリプレイス開発、組織マネジメントを行い、
その後はFAANSの開発責任者としてサービスをローンチ。 2021年10月から本部長に就任し、両プロダクトの開発組織 のマネジメントを行う。 2
© ZOZO, Inc. 3 Agenda 1. FAANSとは 2.
FAANSのアーキテクチャ 3. コード生成の工夫 4. 失敗(と言い切るほどではないが)談 5. まとめ
© ZOZO, Inc. 4 1. FAANSとは
© ZOZO, Inc. 5 FAANS is Fashion Adviser Are Neighbors
ECでお買い物を楽しまれるお客様とショップスタッフの新たな接点を創出し、ショッ プスタッフの効率的な販売をサポートするショップスタッフ専用ツール。ZOZOTOWN が持つECでの販売ノウハウと、ショップスタッフが持つ実店舗での販売ノウハウを 掛け合わせ、オンラインとオフラインをシームレスにつなぐ新たな販売方法を実現し ます。 https://droidkaigi.jp/ninjas/post/zozo/
© ZOZO, Inc. 6 画面イメージ
© ZOZO, Inc. 7 FAANSの機能 • 招待制のtoB向けアプリ ◦ iOS, Androidアプリをストアに公開中
◦ 管理者向けの機能としてWebアプリも提供中 • 主な機能 ◦ アカウント、企業管理 ◦ 店舗在庫連携 ▪ ZOZOTOWNのAPIを利用
© ZOZO, Inc. 8 2. FAANSのアーキテクチャ
© ZOZO, Inc. 9 インフラアーキテクチャ概観 出典: https://techblog.zozo.com/entry/sre-work-for-cloudrun
© ZOZO, Inc. 10 FAANS技術スタック#1 開発言語 Go(レイヤードアーキテクチャ) コンテナ実行基盤
Cloud Run DB Cloud Firestore 非同期ジョブ Cloud Tasks 外部連携 Cloud Pub/Sub ファイルアップロード Google Cloud Storage
© ZOZO, Inc. 11 FAANS技術スタック#2 認証 Firebase Authentication
Push通知 Firebase Cloud Messaging ホスティング Firebase Hosting メール Amazon SES
© ZOZO, Inc. 12 今日話すこと 開発言語 Go(レイヤードアーキテクチャ) コンテナ実行基盤
Cloud Run DB Cloud Firestore 本資料ではこの3点を掘り下げます
© ZOZO, Inc. 13 Goの選択理由#1 • プロトタイプはRuby on Railsで開発していた •
Rails選択の理由 ◦ WEARでRailsを使っていたこと ◦ WEARのエンジニアを異動させる想定だったこと • 一方でWEARでRuby on Railsの難しさを感じていた ◦ 未経験者が書く動的型付け言語の品質 ◦ どこにコードを書けばいいか迷子になることがある ▪ model? controller? 独自のservice? • 全体的にレビューコストが高くなっていてモヤモヤしていた
© ZOZO, Inc. 14 Goの選択理由#2 • WEARからの異動の選択肢がなくなった ◦ 採用する or
他の部署からの異動 • 全社技術スタックが策定されJava or Goが強く推奨された ◦ https://qiita.com/sonots/items/629b8d5785c04ae9c953 • これらを理由にGoで書き直すことを決断 • 合わせて前述した迷子問題を解決するためにレイヤードアーキテクチャを選択
© ZOZO, Inc. 15 レイヤードアーキテクチャ • 割と一般的なレイヤードアーキテクチャを採用 • レイヤーごとの責務を明確にし、どこに実装すればよ いかの迷子を発生しにくくした
◦ なれないうちは迷子が発生するが、レビューの指針 があるのとないのでは大きく違う • コードの記述量が増えるという欠点があるが、コード 生成で負担を軽減している
© ZOZO, Inc. 16 Cloud Runの選択理由 • Go 1.16を利用できるコンテナ実行基盤 ◦
GCPの場合この時点でCloud RunかGKEの2択 • リリースまで時間が限られており、SREのリソースが不足していた • Cloud Runはシンプルで素早く利用開始でき、GCPサービスとの連携も容 易 • 基本的には素晴らしい
© ZOZO, Inc. 17 3. コード生成の工夫
© ZOZO, Inc. 18 controller(interface) • OpenAPIの定義に基づいてopenapi-generatorでコード生成している ◦ 公式で生成されるものはレイヤードアーキテクチャと相性が悪い ◦
Javaとmustacheで自前のものを用意して運用している • 最近はRESTを捨て、すべてPOSTリクエストにしている ◦ アプリはAPIクライアントを自動生成していて、RPCのように扱っている ◦ そのためパスパラメータやクエリストリングを意識することはない ◦ サーバ実装も全部Bodyできたほうがデシリアライズしやすい • そこまでやるならgRPCで良かったのでは??? ◦ そう思います
© ZOZO, Inc. 19 controller(interface)の生成物のサンプル
© ZOZO, Inc. 20 adapter zozo_apiについて • ZOZOTOWNのOpenAPIの定義をもとにopenapi-generatorでコード生成
© ZOZO, Inc. 21 adapter firestoreについて • こちらもスキーマ定義に基づいて自動生成しているが… • その前になぜFirestoreを選択したのかを説明します
© ZOZO, Inc. 22 Firestore • FAANSはマルチテナントなアプリケーション • RDBでマルチテナントの実現は、すべてのテーブルに テナントIDを仕込む運用で辛い
◦ DBを分離する方法もあるのだが、今度はマイグレー ションが辛い • Firestoreにはサブコレクションという概念がある • ルートコレクションをテナントにすることで、安全に分離 できるのではと考えて採用した • GCPに全寄せしたかった、使ってみたかったなどの理 由もある ※サブコレクションのイメージ図 出典: https://firebase.google.com/docs/firestore/data-model?hl=ja
© ZOZO, Inc. 23 FirestoreはスキーマレスなNoSQL • スキーマレスと型のあるGoの相性は悪い • 実装をミスると正しくサブコレクション以下にデータが作られないこともある •
単純なCRUDを都度実装するのは手間 上記問題が実装時に発覚 スキーマを定義してO/Rマッパー風のコードを自動生成してこれらの問題の解決へ
© ZOZO, Inc. 24 Protocol Buffersによるスキーマ定義
© ZOZO, Inc. 25 Protocol Buffersについておさらい • Googleにより開発されているインターフェース定義言語 ◦ gRPCにも使われている
• 一般的なユースケースは通信や永続化の際のデータシリアライズに利用すること • Protocol Buffersの本質はスキーマ定義 ◦ 簡素 ◦ 可読 ◦ protocとそのプラグインによるコード生成
© ZOZO, Inc. 26 protocプラグイン • protocコマンドはprotobufスキーマからクラスや構造体を生成するcompiler ◦ C++, Java,
Python, Rubyなどがサポートされている • 他言語のための拡張機構が用意されていて、それがprotocプラグイン • これを利用することでスキーマ定義から様々なコードを生成できるようになる
© ZOZO, Inc. 27 Protocol Buffersによるスキーマ定義(再掲)
© ZOZO, Inc. 28 protocプラグインの生成物1 スキーマに対応した構造体を生成
© ZOZO, Inc. 29 protocプラグインの生成物2 コレクションに対する操作を行うメソッドを生成
© ZOZO, Inc. 30 protocプラグインの生成物3 ドキュメントに対する操作を行うメソッドを生成 サブコレクションを取得するメソッドも生成 これによりスキーマ通りにデータを作成、取得することを強制
© ZOZO, Inc. 31 その他に利用しているコード生成ライブラリ • wire ◦ DIライブラリ •
moq ◦ Mock生成ライブラリ
© ZOZO, Inc. 32 4. 失敗(と言い切るほどではないが)談
© ZOZO, Inc. 33 Firestoreという選択 • ドキュメント指向DBの設計の難しさ ◦ マルチテナントをいい感じにすることを重視して選択したが、アプリケーションの性質上向 いていないと感じた
◦ 慣れれば解決するかと思ったが • マルチテナントはPostgreSQLなどが備えるRow Level Securityで実現可能だった ◦ 完全に調査不足 • 現在PostgreSQL移行(合わせてAWS移行)を検討中 ◦ Repositoryパターンを使ってるので移行しやすい…はず…
© ZOZO, Inc. 34 Cloud Runという選択 • Datadog APMに対応していない •
k8sをSREチーム標準にすることが決定 ◦ SREのリソースが確保できるようになってきた
© ZOZO, Inc. 35 5. まとめ
© ZOZO, Inc. 36 まとめ • FAANSはGCP, Firebaseを中心にGoで開発をしています • レイヤードアーキテクチャ、コード生成などの工夫をして開発をしています
• 導入企業拡大中で各社の需要をヒアリングしながら具体化していく予定です • それに備えてPostgreSQL移行、GKE移行などの大きな開発を予定しています 上記に興味があるエンジニアを募集中です!
None