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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ SRE部川崎庸市 Yoichi Kawasaki 株式会社ZOZOテクノロジーズ SRE部所属のエンジニア。過去に国内大手インターネット企業にて大規模サービスの基盤プラットフォーム開発に従事、外資系ソフトウェアベンダーにてエンタープライズ検索製品のコンサルやクラウドサービスのアーキテクチャ策定支援に従事。現在はインフラ運用の自動化・効率化が目下の関心事。業務外では NoOps Japanコミュニティーの運営に従事。趣味はサウナ。  2 Twitter / GitHub: @yokawasa

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© ZOZO Technologies, Inc. ZOZOTOWNのクラウドリプレイスの背景  5 ZOZOTOWN運営開始クラウドリプレイス開始マイクロサービス  アーキテクチャに移行開始 2004年 2018年 2020年オンプレミスオンプレ＋クラウド（ハイブリッド） ● ビジネスの拡大 ● 求められる市場投入スピード ● 高まるインフラの拡張性・俊敏性の要求 ● 巨大化するモノリス ● コードの肥大化、特定技術への依存

Slide 6

Slide 6 text

© 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に載っている（ストアド）

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© ZOZO Technologies, Inc. 8 新フレームワークロジック（Web表示のみ）ユーザーサービス RO お気に入りサービス RW 商品サービス RW ネイティブアプリはAPI 直呼び出し PCブラウザ iOS Android WebのUIに新技術が使えるようになるそれぞれのAPIが独立したサービスに = マイクロサービス化 API Gateway データの読み書きがすべてAPI化されている状態 = マイクロサービス化されている状態目指す姿 ID認証サービス RW

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© ZOZO Technologies, Inc. ZOZOTOWNにおけるクラウドテナンシーの方針  ● 基本はシングルクラウド ○ まずはシングルクラウドでアプリやインフラの信頼性の向上に集中 ○ できることはたくさんある：マルチAZ・リージョンの可用性構成、回復性設計、運用基盤・体制強化 ● 要件に応じてマルチクラウドを検討 ○ シングルクラウドでは実現できない高い信頼性が必要とされる場合において、信頼性とコストのトレードオフを考慮しマルチクラウドを検討する ○ コストとは学習コスト、設計・運用コスト、設備コストなど 11

Slide 12

Slide 12 text

© ZOZO Technologies, Inc. マイクロサービス基盤のシングルクラウド可用性設定例  12 ● ロードバランサー（ALB）： ○ 3AZ可用性構成 ● NAT Gateway： ○ AZごとに作成（全体で１つを共有しない） ● Amazon EKS： ○ コントロールプレーン（マネージド） ■ マスターコンポーネント（api server、etcdなど）の3AZ可用性構成 ○ ワーカーノード ■ 3AZ構成のAuto Scalingグループ（ASG）の一部として展開 ■ マネージドノードグループによるワーカーノードのAZ分散配置

Slide 13

Slide 13 text

© ZOZO Technologies, Inc. ZOZOTOWNにおけるクラウド利用パターン  ● ハイブリッド ○ オンプレF/EとクラウドのAPIやデータ基盤の連携 ○ オンプレのサーバ仮想環境をクラウドに拡張（VMware Cloud on AWS） ● シングルクラウド ○ マイクロサービス主要機能（AWS）、データ基盤（GCP） ● マルチクラウド ○ パーソナライズ検索基盤：検索機能をAWSとGCPでマルチクラウドで提供 13

Slide 14

Slide 14 text

© 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

Slide 15

Slide 15 text

© 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 )

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© ZOZO Technologies, Inc. ZOZOTOWNリプレイスで得たマルチクラウド知見  ● 信頼性 ○ 単一クラウドのSLAを越える信頼性確保が可能になる。ただし、中途半端な複数クラウド活用は逆に信頼性低下になる可能性がある ● 制約条件 ○ 選択肢は増える一方、効率性、共通化やベンダーロックイン回避のために特定クラウドに依存しない選択を取ることでシングルクラウド以上に制約条件が増え、また最大公約数のメリットしか得られない可能性がある ● アーキテクチャの複雑化・学習コスト増がもたらす主な弊害 ○ アジリティが低下してビジネスチャンスを逃す可能性がある 17 求められるビジネス要件、得られる信頼性、必要とするコスト、開発体制、習熟度レベルなどのトレードオフで考えるべき

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© ZOZO Technologies, Inc. N%リリースによる段階的な移行  ● サブシステムごとに段階的（N%: 0→100）にクラウドベースに移行 ● 新規システムではなく既存サービスを回しながらの段階的移行（ストラングラーパターン）であるため、移行期間中のシステム全体の複雑性は高くなり、リスク要因が多いことが特徴 ● 基本的にクラウドで構築するアプリはコンテナーベースで、アプリ基盤に Kubernetesを採用したクラウドネイティブを前提とする 19 ストラングラーパターンのイメージ

Slide 20

Slide 20 text

© 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 利用ツール・サービス例

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

© 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例

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© ZOZO Technologies, Inc. まとめ  ● ZOZOTOWNは成長を加速させるためクラウドネイティブに移行 ● クラウド活用方針 ○ まずはシングルクラウドで信頼性向上に集中し、必要に応じてマルチクラウドを検討 ● マルチクラウドについて ○ マルチクラウドはメリットはあるものの、アーキテクチャの複雑化や運用・学習コスト増がもたらす弊害もある。さまざまなトレードオフを考慮して判断すべき ● 信頼性を保ちつつ効果的にクラウド活用するために実践していること  ○ 段階的な移行、技術・ツール選定方針、回復性を重視した設計思想、CI/CD、可観測性、など 24