Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ZOZOTOWNのクラウド活用戦略 / Zozotown Cloud Strategy (Tech-on MeetUp 03)

ZOZOTOWNのクラウド活用戦略 / Zozotown Cloud Strategy (Tech-on MeetUp 03)

Title: ZOZOTOWNのクラウド活用戦略

Event: Tech-on MeetUp Online#03「マルチクラウドで解決するものしないもの 〜エンタープライズにおけるマルチクラウドのリアル〜」

https://techplay.jp/event/793105

Yoichi Kawasaki

October 05, 2020
Tweet

More Decks by Yoichi Kawasaki

Other Decks in Technology

Transcript

  1. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ SRE部 川崎 庸市 Yoichi Kawasaki

    株式会社ZOZOテクノロジーズ SRE部所属のエンジニア。過去に国内 大手インターネット企業にて大規模サービスの基盤プラットフォーム 開発に従事、外資系ソフトウェアベンダーにてエンタープライズ検索製品の コンサルやクラウドサービスのアーキテクチャ策定支援に従事。 現在はインフラ運用の自動化・効率化が目下の関心事。業務外では NoOps Japanコミュニティーの運営に従事。趣味はサウナ。
 2 Twitter / GitHub: @yokawasa
  2. © ZOZO Technologies, Inc. https://zozo.jp/
 • 日本最大級のファッション通販サイト
 • 1,300以上のショップ、7,900以上のブランドの取り扱い(ともに2020年6 月末時点)


    • 常時83万点以上の商品アイテム数と毎日平均3,000点以上の新着商品 を掲載
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など
 3
  3. © ZOZO Technologies, Inc. ZOZOTOWNのクラウドリプレイスの背景
 5 ZOZOTOWN運営開始 クラウドリプレイス開始 マイクロサービス
 アーキテクチャに移行開始

    2004年 2018年 2020年 オンプレミス オンプレ+クラウド(ハイブリッド) • ビジネスの拡大 • 求められる市場投入スピード • 高まるインフラの拡張性・俊敏性の要求 • 巨大化するモノリス • コードの肥大化、特定技術への依存
  4. © ZOZO Technologies, Inc. アーキテクチャーの変遷
 オンプレからクラウドベースに、モノリスからマイクロサービスへ 6 フロントエンド 統合DB フロントエンド

    API / BFF フロントエンド API Gateway API DB DB API API API API オンプレ DC クラウド マイクロサービス化 参照・書き込みすべてAPI化 Read Only Read & Write APIはサービスごとに 独立しDBも分離 弾力性・可用性を要する参照系機 能をAPI化してクラウドで提供 書き込み系はオンプレ BFF 絶賛取り組み中 レプリケーション リプレイス開始前 ① ② ③ ロジックがDBに載っている(ストアド)
  5. © ZOZO Technologies, Inc. 7 IIS (ASP) RO ロジックがDBに載ってい る(ストアド)

    ロジック(表示と処理が混在) DB接続 ストアド iOS Android PCブラウザ クラウドリプレイス前 データの読み書きがDBと一体化されている状態 ストアド ストアド ストアド
  6. © ZOZO Technologies, Inc. 8 新フレームワーク ロジック (Web表示のみ) ユーザー サービス

    RO お気に入り サービス RW 商品 サービス RW ネイティブアプリはAPI 直呼び出し PCブラウザ iOS Android WebのUIに 新技術が使える ようになる それぞれのAPIが 独立したサービスに = マイクロサービス化 API Gateway データの読み書きがすべてAPI化されている状態 = マイクロサービス化されている状態 目指す姿 ID認証 サービス RW
  7. © ZOZO Technologies, Inc. ZOZOTOWNにおけるクラウドテナンシーの方針
 • 基本はシングルクラウド ◦ まずはシングルクラウドでアプリやインフラの信頼性の向上に集中 ◦

    できることはたくさんある:マルチAZ・リージョンの可用性構成、回復性設計、運 用基盤・体制強化 • 要件に応じてマルチクラウドを検討 ◦ シングルクラウドでは実現できない高い信頼性が必要とされる場合において、 信頼性とコストのトレードオフを考慮しマルチクラウドを検討する ◦ コストとは学習コスト、設計・運用コスト、設備コストなど 11
  8. © ZOZO Technologies, Inc. マイクロサービス基盤のシングルクラウド可用性設定例
 12 • ロードバランサー(ALB): ◦ 3AZ可用性構成

    • NAT Gateway: ◦ AZごとに作成(全体で1つを共有しない) • Amazon EKS: ◦ コントロールプレーン(マネージド) ▪ マスターコンポーネント(api server、etcdなど)の3AZ可 用性構成 ◦ ワーカーノード ▪ 3AZ構成のAuto Scalingグループ(ASG)の一部として 展開 ▪ マネージドノードグループによるワーカーノードのAZ分 散配置
  9. © ZOZO Technologies, Inc. ZOZOTOWNにおけるクラウド利用パターン
 • ハイブリッド ◦ オンプレF/EとクラウドのAPIやデータ基盤の連携 ◦

    オンプレのサーバ仮想環境をクラウドに拡張(VMware Cloud on AWS) • シングルクラウド ◦ マイクロサービス主要機能(AWS)、データ基盤(GCP) • マルチクラウド ◦ パーソナライズ検索基盤:検索機能をAWSとGCPでマルチクラウドで提供 13
  10. © ZOZO Technologies, Inc. マルチクラウド活用例 - パーソナライズ検索
 利用者の行動履歴・属性を元にパーソナライズされたおすすめ順機能のための仕組み 14 •

    オンプレのフロントエンドはAWS上に構築されたAPIを通じて検索結 果を取得 • 検索エンジンはElasticsearch(Elastic Cloud)で、負荷分散・可用 性向上のためAWSとGCPに構築 • APIはAWSとGCP上のElasticsearchに対してクエリを発行 • 検索データ更新処理のためのデータ基盤はGCPに構築 • オンプレ・クラウド間は専用線接続 • ZOZOTOWNの検索基盤におけるElasticsearch移行で得た知見 https://techblog.zozo.com/entry/migrating-zozotown-search-platform • ZOZOTOWNを支える検索パーソナライズ基盤  https://speakerdeck.com/dama_yu/zozotech-gcp-01
  11. © ZOZO Technologies, Inc. 15 フロント (ASP) API Gateway API/BFF

    BigQuery App Engine 更新対象取得 更新 更新 SQL Server SQL Server CDC 検索データ更新のための仕組み レプリケーション 専用線 専用線 クライアント パーソナライズ検索全体図 ZOZO DC GCP AWS • AWSとGCP上のElasticsearchに対してク ロスクラウドでクエリを発行 • 失敗したらクラウド間でリトライ ( Elastic Cloud ) ( Elastic Cloud )
  12. © ZOZO Technologies, Inc. 一般論 - マルチクラウドのメリット・デメリット
 • 信頼性向上 ◦

    リスク分散 ◦ 可用性向上 • 柔軟な選択肢 ◦ 可搬性確保 ◦ ベンダーロックイン回避 16 • アーキテクチャの複雑化 • コスト増の可能性 ◦ 学習コスト ◦ 運用コスト ◦ インフラコスト メリット デメリット
  13. © ZOZO Technologies, Inc. ZOZOTOWNリプレイスで得たマルチクラウド知見
 • 信頼性 ◦ 単一クラウドのSLAを越える信頼性確保が可能になる。ただし、中途半端な複数クラウド 活用は逆に信頼性低下になる可能性がある

    • 制約条件 ◦ 選択肢は増える一方、効率性、共通化やベンダーロックイン回避のために特定クラウド に依存しない選択を取ることでシングルクラウド以上に制約条件が増え、また最大公約 数のメリットしか得られない可能性がある • アーキテクチャの複雑化・学習コスト増がもたらす主な弊害 ◦ アジリティが低下してビジネスチャンスを逃す可能性がある 17 求められるビジネス要件、得られる信頼性、必要とするコスト、開発体制、習熟度レ ベルなどのトレードオフで考えるべき
  14. © ZOZO Technologies, Inc. N%リリースによる段階的な移行
 • サブシステムごとに段階的(N%: 0→100)にクラウドベースに移行 • 新規システムではなく既存サービスを回しながらの段階的移行(ストラングラーパ

    ターン)であるため、移行期間中のシステム全体の複雑性は高くなり、リスク要因が 多いことが特徴 • 基本的にクラウドで構築するアプリはコンテナーベースで、アプリ基盤に Kubernetesを採用したクラウドネイティブを前提とする 19 ストラングラーパターンのイメージ
  15. © ZOZO Technologies, Inc. 利用技術・ツール選定方針
 信頼性・柔軟性・コストなどを考慮したケースバイケースの選択 • マネージドサービスの活用 ◦ 運用負荷軽減、ポータビリティなどが考慮ポイント

    ◦ 必要に応じて自作も考える • オープンソース、またはオープンソース互換の採用 • 特定クラウドに依存する技術・ツールも必要に応じて採用 ◦ ステートレスなアプリ基盤に対しデータ基盤はクラウド特化になりがち 20 Automation / Configuration CloudFormation, Terraform Observability Datadog, Sentry, PagerDuty, CloudWatch, Stackdriver Code Repo, CI/CD GitHub, GitHub Actions, CircleCI DB, Analytics RDS (SQL), Aurora (MySQL), BigQuery, AWS Athena 利用ツール・サービス例
  16. © ZOZO Technologies, Inc. 堅牢性より回復性 - Design for Resiliency
 •

    クラウドは進化(Update)し続ける ⇒ クラウドは壊れる可能性がある • 回復性を重視した設計思想 ◦ 堅牢性より壊れること前提として、ダウンタイムやデータ損失を回避しサービス 提供を維持できる回復性のための設計や仕組みを構築する • その他、回復性を支えるために重視している能力・活動 ◦ 構成管理力(IaC、CI/CD) ◦ 可観測性(ログ、メトリクス、可視化、分散トレーシング) ◦ DevOps + サイト信頼性のためのエンジニアリング(SRE)
 21
  17. © ZOZO Technologies, Inc. 構成管理の自動化の徹底 - IaCとCI/CD
 • CI/CDを起点としたアプリ・インフラ環境の構築、リリース、構成変更 ◦

    コード化: IaC(Infrastructure as Code) ◦ リリース・構成変更作業の自動化: CI/CD • 初期コストはかかるものの得られるメリットはとても大きい ◦ ミスの低減、開発効率とリリーススピードの向上 ◦ 運用・開発業務の非属人化でスケール拡大が見込める 22 ZOZOTOWNマイクロサービスプロジェクトにおける 継 続 的 な 改 善 を 支 えるCI/CD 戦 略 https://techblog.zozo.com/entry/zozotown-cicd-strategy  アプリ・インフラIaC + CI/CD例
  18. © ZOZO Technologies, Inc. まとめ
 • ZOZOTOWNは成長を加速させるためクラウドネイティブに移行 • クラウド活用方針 ◦

    まずはシングルクラウドで信頼性向上に集中し、必要に応じてマルチクラウドを検討 • マルチクラウドについて ◦ マルチクラウドはメリットはあるものの、アーキテクチャの複雑化や運用・学習コスト 増がもたらす弊害もある。さまざまなトレードオフを考慮して判断すべき • 信頼性を保ちつつ効果的にクラウド活用するために実践していること
 ◦ 段階的な移行、技術・ツール選定方針、回復性を重視した設計思想、CI/CD、可観 測性、など 24
  19. © ZOZO Technologies, Inc. 25 We are hiring! https://tech.zozo.com/recruit/ ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる

    方を募集しています。ご興味がある方は以下のリンクから 是非ご応募ください!