FAANSを支えるアーキテクチャ

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. 5 FAANS is Fashion Adviser Are Neighbors 
  ECでお買い物を楽しまれるお客様とショップスタッフの新たな接点を創出し、ショップスタッフの効率的な販売をサポートするショップスタッフ専用ツール。ZOZOTOWN が持つECでの販売ノウハウと、ショップスタッフが持つ実店舗での販売ノウハウを掛け合わせ、オンラインとオフラインをシームレスにつなぐ新たな販売方法を実現します。    https://droidkaigi.jp/ninjas/post/zozo/   

© ZOZO, Inc. 7 FAANSの機能  • 招待制のtoB向けアプリ  ◦ iOS, Androidアプリをストアに公開中 
◦ 管理者向けの機能としてWebアプリも提供中  • 主な機能  ◦ アカウント、企業管理  ◦ 店舗在庫連携  ▪ ZOZOTOWNのAPIを利用   

© 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. 18 controller(interface)  • OpenAPIの定義に基づいてopenapi-generatorでコード生成している  ◦ 公式で生成されるものはレイヤードアーキテクチャと相性が悪い  ◦
Javaとmustacheで自前のものを用意して運用している  • 最近はRESTを捨て、すべてPOSTリクエストにしている  ◦ アプリはAPIクライアントを自動生成していて、RPCのように扱っている  ◦ そのためパスパラメータやクエリストリングを意識することはない  ◦ サーバ実装も全部Bodyできたほうがデシリアライズしやすい  • そこまでやるならgRPCで良かったのでは？？？  ◦ そう思います 

© 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. 25 Protocol Buffersについておさらい  • Googleにより開発されているインターフェース定義言語  ◦ gRPCにも使われている 
• 一般的なユースケースは通信や永続化の際のデータシリアライズに利用すること  • Protocol Buffersの本質はスキーマ定義  ◦ 簡素  ◦ 可読  ◦ protocとそのプラグインによるコード生成     

© ZOZO, Inc. 26 protocプラグイン  • protocコマンドはprotobufスキーマからクラスや構造体を生成するcompiler  ◦ C++, Java,
Python, Rubyなどがサポートされている  • 他言語のための拡張機構が用意されていて、それがprotocプラグイン  • これを利用することでスキーマ定義から様々なコードを生成できるようになる   

© ZOZO, Inc. 33 Firestoreという選択  • ドキュメント指向DBの設計の難しさ  ◦ マルチテナントをいい感じにすることを重視して選択したが、アプリケーションの性質上向いていないと感じた 
◦ 慣れれば解決するかと思ったが  • マルチテナントはPostgreSQLなどが備えるRow Level Securityで実現可能だった  ◦ 完全に調査不足  • 現在PostgreSQL移行（合わせてAWS移行）を検討中  ◦ Repositoryパターンを使ってるので移行しやすい…はず… 

© ZOZO, Inc. 36 まとめ  • FAANSはGCP, Firebaseを中心にGoで開発をしています  • レイヤードアーキテクチャ、コード生成などの工夫をして開発をしています 
• 導入企業拡大中で各社の需要をヒアリングしながら具体化していく予定です  • それに備えてPostgreSQL移行、GKE移行などの大きな開発を予定しています      上記に興味があるエンジニアを募集中です！ 

FAANSを支えるアーキテクチャ

FAANSを支えるアーキテクチャ

More Decks by tohae

Other Decks in Technology

Featured

Transcript