ZOZOTOWNマイクロサービス基盤のService Mesh アーキテクチャへの移行 / Serivce Mesh Architecture at ZOZOTOWN Microservices Platform

Presentation Slides for ZOZO Tech Meetup〜ZOZOTOWNアーキテクトナイト〜

Transcript

1. ZOZOTOWNマイクロサービス基盤の
   Service Meshアーキテクチャへの移行

   ZOZO Tech Meetup 〜 ZOZOTOWNアーキテクトナイト 〜

   株式会社ZOZOテクノロジーズ

   EC基盤本部 SRE部 ECプラットフォームSRE
   チームリーダー・テックリード

   川崎 庸市
   Copyright © ZOZO Technologies, Inc.
   

   View Slide

2. © ZOZO Technologies, Inc.
   株式会社ZOZOテクノロジーズ

   EC基盤本部 SRE部 ECプラットフォームSRE

   チームリーダー・テックリード
   川崎 庸市

   Yoichi Kawasaki
   2019年10月中途入社。ZOZOTOWNマイクロサービス基盤を

   担当するSREチーム所属。過去にインターネットサービスの基盤開発

   エンジニア、クラウドサービスの技術コンサルやアーキテクチャ策定

   支援などに従事。最近はインフラ運用自動化・効率化が目下の関心事。趣味
   はサウナ

   

   Twitter & GitHub @yokawasa
   2
   

   View Slide

3. © ZOZO Technologies, Inc.
   https://zozo.jp/

   3
   ● 日本最大級のファッション通販サイト

   ● 1,400以上のショップ、8,200以上のブランドの取り扱い（ともに2021年3月
   末時点）

   ● 常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品
   を掲載

   ● コスメ専門モール「ZOZOCOSME」や靴の専門モール

   「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン

   「ZOZOVILLA」を展開

   ● 即日配送サービス

   ● ギフトラッピングサービス

   ● ツケ払い など

   

   View Slide

4. © ZOZO Technologies, Inc.
   トピック

   ● Istio / Service Mesh導入の背景・理由
   ● Service Meshアーキテクチャへの移行方法
   ● Istio / Service Mesh導入における考慮点
   4
   

   View Slide

5. Istio / Service Mesh導入の背景・理由

   

   View Slide

6. ZOZOTOWNの成長のため
   スピード
   をあげる
   コスト
   をさげる
   人材
   をふやす
   ZOZOTOWNはリプレイスをすすめています

   

   View Slide

7. © ZOZO Technologies, Inc.
   ZOZOTOWN アーキテクチャの変遷

   オンプレからクラウドベースに、モノリスからマイクロサービスへ
   7
   フロントエンド
   統合DB
   フロントエンド
   API / BFF
   フロントエンド
   API Gateway
   API
   DB
   DB API API API API
   オンプレ
   クラウド
   マイクロサービス化
   データ読み書きが全てAPI化
   Read Only Read & Write
   APIはサービスごとに
   独立しDBも分離
   弾力性・可用性を要する参照系機
   能をAPI化してクラウドで提供
   書き込み系はオンプレ
   BFF
   絶賛取り組み中
   レプリケーション
   リプレイス開始前
   ① ② ③
   ロジックがDBに
   載っている
   （ストアド）
   目指す姿
   表示のみ（処理との分離）
   新フレームワークで
   Web UI新技術利用
   変更しづらい
   ● モノリスで変更の影響範囲が広い
   ● DBにロジック（ストアド）
   運用負荷が高い
   ● 限定的な自動化
   ● DBボトルネック
   ● 大量バッチ処理
   2004〜2017年 2017〜2019年
   表示とロジック処理が混在
   

   View Slide

8. © ZOZO Technologies, Inc.
   マイクロサービスアーキテクチャ（MSA）

   8
   

   View Slide

9. © ZOZO Technologies, Inc.
   API Gatewayパターン

   9
   Service A
   ZOZO API
   Gateway
   PCブラウザ
   UI
   アプリ
   UI
   Service B
   Service C
   Service D
   Service E
   

   View Slide

10. © ZOZO Technologies, Inc.
    ZOZO API Gatewayの機能と責務

    10
    APIクライアント認証
    URIパスルーティング
    ロギング（アクセスログ）
    IPレンジホワイトリスト
    (クライアントごと)
    メンバー認証
    スロットリング
    （追加候補）
    ZOZO API Gateway（独自実装）
    リトライ制御
    タイムアウト
    加重ルーティング
    ZOZO API Gatewayの責務
    ● API利用クライアントの認証管理
    ● API利用クライアント向けの共通インターフェー
    スの提供（HTTP/HTTPS）
    ● 外からのリクエストとAPIサービスのマッピング
    （URIパスルーティング）
    ● GatewayからAPIへのトラフィック制御
    段階的なリプレイスをすすめるた
    めの中心的なコンポーネント
    

    View Slide

11. © ZOZO Technologies, Inc.
    マイクロサービスが抱える課題（一般論）

    MSAは小規模・独立したサービスで構成されるためリリーススピード、柔軟なアップデート
    など様々なメリットが得られる
    一方、分散システムであるために対処しなければならない様々な課題が存在する
    11
    Communication（複雑なサービス間通信）
    Discovery（サービス・依存関係の発見）
    Observability（分散アプリの監視・問題検知）
    Security（サービス間認証・認可、暗号化）
    Fallacies of distributed computing
    1.The network is reliable;
    2.Latency is zero;
    3.Bandwidth is infinite;
    4.The network is secure;
    5.Topology doesn't change;
    6.There is one administrator;
    7.Transport cost is zero;
    8.The network is homogeneous.
    https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
    

    View Slide

12. © ZOZO Technologies, Inc.
    サービス間通信における課題

    12
    Service A
    ZOZO API
    Gateway
    PCブラウザ
    UI
    アプリ
    UI
    Service B
    Service C
    Service D
    Service E
    複雑に発生しうるサービス間通信に対してもZOZO API Gatewayから各サービスへの
    ルーティングのように一貫したトラフィック制御を行いたい
    

    View Slide

13. © ZOZO Technologies, Inc.
    サービス間通信の課題を解決するための選択肢

    1. 共通ライブラリを各アプリへ組み込む
    ○ 高いコスト（アップグレード、開発・SRE間のコミュニケーション）
    ○ 根本的に一貫性の担保が困難（異なるアプリ言語、チーム）
    13
    2. サービス間通信でもAPI Gatewayを介した通信にする
    ○ 導入は容易だがAPI Gatewayに負荷が集中しボトルネックとなる問題
    ○ 別途クライアント認証の制御が必要になる
    3. Service Meshを導入する
    ○ サイドカープロキシへのポリシー適用でアプリのコード変更なく透過的に機能注入が可能
    ○ サービス間通信に対して一貫したトラフィック制御が可能
    実装＆コミュニケーションコスト、抽象度の高さ、今後のサービス増によるトポロジーの複雑化の
    見通しなど総合的な観点でZOZOTOWNマイクロサービス基盤においてはService Meshのアプ
    ローチがベストと判断
    採用
    

    View Slide

14. © ZOZO Technologies, Inc.
    サービス間通信問題対応のためのアプローチ

    1. 共通ライブラリの各アプリへの組み込み
    ○ 高いコスト（アップグレード、開発・SRE間のコミュニケーション）
    ○ 根本的に一貫性の担保が困難（異なるアプリ言語、チーム）
    14
    2. サービス間通信でもAPI Gatewayを介した通信にする
    ○ 導入は容易だがAPI Gatewayに負荷が集中しボトルネックとなる問題
    ○ 別途クライアント認証の制御が必要になる
    3. Service Meshの導入
    ○ サイドカープロキシへのポリシー適用でアプリのコード変更なく透過的に機能注入が可能
    ○ サービス間通信に対して一貫したトラフィック制御が可能
    モノリシック、もしくはサービスの数が少なくその実装の多様性が
    限定的な場合は共通ライブラリによるアプローチが最適解になる場合もある
    参考情報
    

    View Slide

15. Service Meshの実装にIstioを採用

    

    View Slide

16. © ZOZO Technologies, Inc.
    Istioとは？

    ● Googleなど複数社の共同開発により2017年5月にOSS化されたService Meshフレームワーク
    ● ネットワークを抽象化するインフラ層
    ○ アプリPodにプロキシ（istio-proxy ≒ Envoy）をサイドカーコンテナとしてInjectさせることで、アプリコード変更を伴わずに
    Service Meshの実現が可能
    ● Control PlaneとData Planeで構成
    ○ Control Planeが設定・ポリシーを伝達。Data Planeはそれに応じてトラフィック制御、セキュリテイなどの機能を提供
    16
    Istioが提供する機能
    ● リトライ制御、サーキットブレイク
    ● 流量制限
    ● ロードバランス
    ● Blue/Green、カナリアリリース
    ● トレーシング、メトリクス
    ● サービス認証
    ● サービス・依存関係の発見
    https://istio.io/latest/about/service-mesh/
    参考情報
    

    View Slide

17. © ZOZO Technologies, Inc.
    Istioを選択した理由

    ● 実現したい機能・非機能要件が満たせる（PoCを通じて確認）
    ● OSSであり、クラウド基盤に影響されず同様の開発者体験を得られる

    ○ ZOZOではEKS以外に、ML系ワークロードでGKEを利用

    ● プロダクション環境における利用実績の豊富さ、エコシステムの充実
    ● 分散トレーシングに利用しているDatadogとのインテグレーションをサポート
    17
    参考: 有名なService Mesh実装の一覧
    ● AWS App Mesh
    ● GKE Istio
    ● Alibaba Cloud Service
    Mesh
    ● Aspen Mesh
    ● Grey Matter
    ● Istio
    ● Consul
    ● Open Service Mesh
    ● Meshery
    ● Kuma
    ● Netflix Zuul
    ● Linkerd 2.X
    ● NGINX Service Mesh
    ● Traefik Mesh
    ● Cilium
    ● Network Service Mesh
    ● Service Mesh Interface
    Managed / Commercial Services
    Open Source Service Mesh
    

    View Slide

18. © ZOZO Technologies, Inc.
    プロダクションにおけるIstioの利用実績

    CNCF Service Mesh 2020 Survey結果
    ● 2019年と比較しService Meshの本番利用を答えた企業が18%から27%に増加
    ● その中でも47%がIstioを利用
    18
    https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf
    https://github.com/cncf/surveys
    参考情報
    

    View Slide

19. © ZOZO Technologies, Inc.
    充実したIstioエコシステム

    ● Istioとのシームレスなインテグレーションが可能なプロ
    ダクトが豊富
    ● これらを活用した将来的な機能拡張も想定
    （特にProgressive Delivery）
    Istioインテグレーションによる機能追加
    ● Datadog - Observability
    ● Flagger - Progressive Delivery
    ● Argo Rollout - Progressive Delivery
    ● cert-manager - Certification Management
    ● Calico - Network policy
    ● Kubeflow - ML workflows
    19
    https://istio.io/latest/about/ecosystem/
    参考情報
    

    View Slide

20. © ZOZO Technologies, Inc.
    Istio導入で実現可能となる一貫性・自動化

    20
    理想 現状・GAP 解決方法
    クラスタ全体で一貫性のある回復性のた
    めのトラフィック制御設定
    - リトライ制御
    - タイムアウト
    - サーキットブレーカー、など
    独自実装、ライブラリ活用などを要するため
    設定方式の統一が難しい
    - Gatewayとサービス間
    - サービス間
    VirtualServce, DestinationRuleなどIstio
    CRDによる宣言的かつ統一された方式で
    設定が可能
    安心安全なデプロイメントのための
    カナリアリリース方式の統一と自動化
    異なるカナリアリリース方式
    - Edge(ALB)とGateway間
    - Gatewayとサービス間
    加重率変更に複数の手動作業を要する
    Istio CRD（VirtualService）による統一され
    た方式
    さらに将来的にはIstioエコシステムの活用
    によるProgressive Deliveryで加重率変更
    プロセスの自動化も視野に入る
    代表的なもの2つ
    

    View Slide

21. Service Meshアーキテクチャへの移行方法

    

    View Slide

22. © ZOZO Technologies, Inc.
    Service Meshアーキテクチャへの移行

    Service Meshアーキテクチャへの移行で行ったことは大きく分けて2つ
    ● 機能整理と責務の分担
    ○ ZOZO API GatewayとIstioの機能を整理して、役割が重複しないように設計
    ■ 通信回復性の機能は基本的にIstioで管理
    ■ Mesh化できない箇所はこれまで通りZOZO API Gatewayの機能を活用
    ● 段階的な移行
    ○ 導入しやすい箇所から段階的に移行
    ○ カナリアリリース
    22
    

    View Slide

23. © ZOZO Technologies, Inc.
    ZOZO API GatewayとIstioの機能整理と責務の分担

    23
    APIクライアント認証
    URIパスルーティング
    ロギング（アクセスログ）
    IPレンジホワイトリスト
    (クライアントごと)
    メンバー認証
    スロットリング
    （追加検討中）
    ZOZO API Gateway
    リトライ制御
    タイムアウト
    加重ルーティング
    ZOZO API Gatewayの責務（移行前）
    ● API利用クライアントの認証管理
    ● API利用クライアント向けの共通インターフェー
    スの提供（HTTP/HTTPS）
    ● 外からのリクエストとAPIサービスのマッピング
    （URIパスルーティング）
    ● GatewayからAPIへのトラフィック制御
    

    View Slide

24. © ZOZO Technologies, Inc.
    ZOZO API GatewayとIstioの機能整理と責務の分担

    24
    APIクライアント認証
    URIパスルーティング
    ロギング（アクセスログ）
    IPレンジホワイトリスト
    (クライアントごと)
    メンバー認証
    スロットリング
    （追加候補）
    ZOZO API Gateway
    リトライ制御
    タイムアウト
    加重ルーティング
    サーキットブレーカー
    可観測性機能
    Istio/Service Mesh
    セキュリティ機能
    ● ZOZO API Gatewayはクライアント認証とリクエストと各APIのマッピング機能を提供
    ● Istioでトラフィック制御機能を提供するように変更（一部例外を除く）
    EdgeゲートウェイとしてAPI利用
    クライアント観点で機能提供
    内部ネットワークの通信制御
    （外への通信も含む）
    レートリミット
    

    View Slide

25. © ZOZO Technologies, Inc.
    段階的な移行

    移行方針
    ○ 無停止を前提とした段階的な移行
    ○ 優先度の高いサービス・コンポーネントから徐々にService Mesh化
    ○ サービス・コンポーネント単位でカナリアリリース
    25
    移行フェーズ
    1. 新規リリースのマイクロサービスとその通信先の一部サービスをService Mesh化
    ○ EKSクラスタにIstiod（Control Plane）のデプロイ
    ○ Istio運用監視に必要な監視システム＋構成管理方法を確立
    2. ZOZO API GatewayをService Mesh化
    ○ Gateway 〜 各マイクロサービスまでIstioによる一貫したトラフィック制御設定の準備完了
    3. マイクロサービス全体のService Mesh化（イマココ 2021/09時点）
    ○ 優先度の高いサービスから移行
    4. EKSクラスタ跨ぎのService Mesh化
    

    View Slide

26. © ZOZO Technologies, Inc.
    Service Meshアーキテクチャ移行前

    26
    クラスタ全体で一貫性のないトラ
    フィック制御設定
    ● Gatewayからサービスへのルーティングは
    ZOZO API Gatewayの機能で実現
    ● サービス間通信は個々に実装（統一されたトラ
    フィック制御の仕組みは無い）
    ZOZO API GatewayとZOZO Search API間のルーティング例
    ZOZO API Gatewayの機能で実現
    ● 加重ルーティング機能
    ● タイムアウト
    ● リトライ制御
    参考情報
    

    View Slide

27. © ZOZO Technologies, Inc.
    段階的な移行例

    27
    フェーズ１→ フェーズ２への移行
    Gateway〜各サービスまで一貫したIstioによるトラフィック制御が可能になった
    1. 部分的なService Mesh化 2. ZOZO API GatewayをService Mesh化
    Gatewayからサービスへのルーティングと
    サービス間通信でトラフィック制御設定がバラバラ
    Gateway〜各サービスまでVirtualService、DestinationRuleなどIstio
    のリソース定義でトラフィック制御が可能となった
    参考情報
    

    View Slide

28. © ZOZO Technologies, Inc.
    Service Meshアーキテクチャ移行完了イメージ

    28
    ZOZO API Gatewayを含め各クラスタ内のサービスPodにサイドカープロキシが注入されService
    Meshデータプレーンとして透過的な通信制御が可能となる
    サービス間通信が抽象化され、クラスタ全体で一貫性のあるトラフィック制御設定が可能となる
    参考情報
    

    View Slide

29. © ZOZO Technologies, Inc.
    VirtualService設定例

    29
    Istio VirtualServiceで統一されたトラフィック制御設定
    ZOZO API GatewayのVirtualService設定 ZOZO Search APIのVirtualService設定
    注意: パラメータ数値、host名は仮
    参考情報
    

    View Slide

30. Istio / Service Mesh導入における考慮点

    

    View Slide

31. © ZOZO Technologies, Inc.
    その他、安定性・運用性のための考慮点

    安定的にService Meshアーキテクチャに移行し、運用管理していくために行ったこと
    31
    ● 運用管理の複雑化への対応
    ○ 構成管理の自動化・効率化
    ○ 負荷試験を通じた十分なチューニング
    ○ 可観測性の担保
    ● 変化への追従
    ○ 短いアップデートサイクル（3ヶ月に1回ペースのminorリリース＋Security updates）
    

    View Slide

32. © ZOZO Technologies, Inc.
    運用管理複雑化への対応 - 構成管理自動化

    インフラからアプリまでサービス環境の構成は可能な限りIaC化しており、その構築・更新はCI/CDパ
    イプラインからの実行を基本としている。Istioも同様の仕組みで行う。
    32
    ● Istio構成設定とトラフィック制御、セキュリティ関連ポリ
    シー設定など全てのマニフェストは他のk8sマニフェスト同
    様CI/CD経由でサービス環境にデプロイ
    ● Istio構成設定はIstio Operatorによる自動ロールアウト方
    式を採用
    ZOZOTOWNマイクロサービス基盤のCI/CD戦略についてはこちらのテック
    ブログも参照ください

    

    ZOZOTOWNマイクロサービスプロジェクトにおける継続的な改善を支えるCI/CD戦略

    https://techblog.zozo.com/entry/zozotown-cicd-strategy

    

    View Slide

33. © ZOZO Technologies, Inc.
    運用管理複雑化への対応 - 可観測性・性能予測 

    Service Meshはサイドカープロキシにより各Podマイクロサービス間の通信が透過的にルーティングされ
    る仕組みであるため、問題が発生した際の追跡が複雑になり、また各Podにかかる負荷やリソース消費
    量は変わってくる。よって以下のことが非常に重要となる
    33
    ● 可観測性の向上 （メトリクス、分散トレーシング、ダッシュボード）
    ○ 運用負荷軽減のため監視・観測システムはマネージド・サービス（Datadog）を活用
    ● 負荷試験によるチューニングとサイジング
    Istioのプロダクション環境導入のために実施した可観測性向上対策、負荷
    試験、チューニング、サイジングなどの取り組みについて詳しくはこちらの
    テックブログを参照ください

    

    Istioによるサービスメッシュをどのようにプロダクションレディにするか

    https://techblog.zozo.com/entry/zozotown-istio-production-ready

    

    View Slide

34. © ZOZO Technologies, Inc.
    Service Meshの導入におけるトレードオフ

    34
    さまざまな選定ポイントを考慮し適切にトレードオフしていきましょう
    ● アーキテクチャの複雑度
    ○ モノリシック、もしくはサービスの数が少なくその実装の多様性が限定的な場合はメリットよりも導入代償のほうが大き
    くなるかもしれない
    ● 運用管理体制、スキルレベル、資金力
    ○ Service Meshフレームワークに加えて、複雑化する運用管理の対応のために構成管理の自動化・効率化、可観測性
    の担保など行い運用性を維持していく必要がある
    ○ ある程度の運用管理リソースをオフロードしたい場合はマネージドサービスを利用する
    ■ ZOZOTOWNマイクロサービス基盤ではメトリクス・トレーシングにDatadogを活用している
    ■ ただし利用料金がかかる
    ○ 自由度、ポータビリティなどを重視する場合はOSS、自前運用。ただし、十分なスキルレベルが必要となる
    ○ 学習コストの考慮も必要。k8s知識に加えてある程度の学習期間を要する（弊チーム実績： 2〜3ヶ月）
    ○ アップデートサイクルが短いので変化に追従できる自動化・監視観測の仕組みと運用体制が必要となる
    

    View Slide

35. © ZOZO Technologies, Inc.
    "There are no right or wrong answers
    in architecture - only trade-offs."
    35
    By Neal Ford at Fundamentals of Software Architecture
    （意訳）アーキテクチャに正解はない - あるのはトレードオフのみ
    

    View Slide

36. © ZOZO Technologies, Inc.
    まとめ

    36
    ● マイクロサービスにおけるサービス間通信の課題解決のためにService Mesh
    アーキテクチャに移行（現在進行中）
    ● 既存のAPI Gatewayとの機能整理と責務の分担を行い、リスクを低減すべく段
    階的な移行を実施
    ● 構成管理の自動化・効率化、可観測性の担保など、運用性の向上にも着手
    

    View Slide

37. View Slide