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

Transcript

1. ZOZOTOWNマイクロサービス基盤の Service Meshアーキテクチャへの移行
 ZOZO Tech Meetup 〜 ZOZOTOWNアーキテクトナイト 〜
 株式会社ZOZOテクノロジーズ


   EC基盤本部 SRE部 ECプラットフォームSRE チームリーダー・テックリード
 川崎 庸市 Copyright © ZOZO Technologies, Inc.

2. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 EC基盤本部 SRE部 ECプラットフォームSRE
 チームリーダー・テックリード 川崎

   庸市
 Yoichi Kawasaki 2019年10月中途入社。ZOZOTOWNマイクロサービス基盤を
 担当するSREチーム所属。過去にインターネットサービスの基盤開発
 エンジニア、クラウドサービスの技術コンサルやアーキテクチャ策定
 支援などに従事。最近はインフラ運用自動化・効率化が目下の関心事。趣味 はサウナ
 
 Twitter & GitHub @yokawasa 2

3. © ZOZO Technologies, Inc. https://zozo.jp/
 3 • 日本最大級のファッション通販サイト
 • 1,400以上のショップ、8,200以上のブランドの取り扱い（ともに2021年3月

   末時点）
 • 常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品 を掲載
 • コスメ専門モール「ZOZOCOSME」や靴の専門モール
 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン
 「ZOZOVILLA」を展開
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など


4. © ZOZO Technologies, Inc. トピック
 • Istio / Service Mesh導入の背景・理由

   • Service Meshアーキテクチャへの移行方法 • Istio / Service Mesh導入における考慮点 4

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


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


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年 表示とロジック処理が混在

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

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

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

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へのトラフィック制御 段階的なリプレイスをすすめるた めの中心的なコンポーネント

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

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

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

13. © ZOZO Technologies, Inc. サービス間通信の課題を解決するための選択肢
 1. 共通ライブラリを各アプリへ組み込む ◦ 高いコスト（アップグレード、開発・SRE間のコミュニケーション） ◦

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

14. © ZOZO Technologies, Inc. サービス間通信問題対応のためのアプローチ
 1. 共通ライブラリの各アプリへの組み込み ◦ 高いコスト（アップグレード、開発・SRE間のコミュニケーション） ◦

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

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


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/ 参考情報

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

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 参考情報

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/ 参考情報

20. © ZOZO Technologies, Inc. Istio導入で実現可能となる一貫性・自動化
 20 理想 現状・GAP 解決方法 クラスタ全体で一貫性のある回復性のた

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

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


22. © ZOZO Technologies, Inc. Service Meshアーキテクチャへの移行
 Service Meshアーキテクチャへの移行で行ったことは大きく分けて2つ • 機能整理と責務の分担

    ◦ ZOZO API GatewayとIstioの機能を整理して、役割が重複しないように設計 ▪ 通信回復性の機能は基本的にIstioで管理 ▪ Mesh化できない箇所はこれまで通りZOZO API Gatewayの機能を活用 • 段階的な移行 ◦ 導入しやすい箇所から段階的に移行 ◦ カナリアリリース 22

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へのトラフィック制御

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利用 クライアント観点で機能提供 内部ネットワークの通信制御 （外への通信も含む） レートリミット

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化

26. © ZOZO Technologies, Inc. Service Meshアーキテクチャ移行前
 26 クラスタ全体で一貫性のないトラ フィック制御設定 •

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

27. © ZOZO Technologies, Inc. 段階的な移行例
 27 フェーズ１→ フェーズ２への移行 Gateway〜各サービスまで一貫したIstioによるトラフィック制御が可能になった 1.

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

28. © ZOZO Technologies, Inc. Service Meshアーキテクチャ移行完了イメージ
 28 ZOZO API Gatewayを含め各クラスタ内のサービスPodにサイドカープロキシが注入されService

    Meshデータプレーンとして透過的な通信制御が可能となる サービス間通信が抽象化され、クラスタ全体で一貫性のあるトラフィック制御設定が可能となる 参考情報

29. © ZOZO Technologies, Inc. VirtualService設定例
 29 Istio VirtualServiceで統一されたトラフィック制御設定 ZOZO API

    GatewayのVirtualService設定 ZOZO Search APIのVirtualService設定 注意: パラメータ数値、host名は仮 参考情報

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


31. © ZOZO Technologies, Inc. その他、安定性・運用性のための考慮点
 安定的にService Meshアーキテクチャに移行し、運用管理していくために行ったこと 31 • 運用管理の複雑化への対応

    ◦ 構成管理の自動化・効率化 ◦ 負荷試験を通じた十分なチューニング ◦ 可観測性の担保 • 変化への追従 ◦ 短いアップデートサイクル（3ヶ月に1回ペースのminorリリース＋Security updates）

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


33. © ZOZO Technologies, Inc. 運用管理複雑化への対応 - 可観測性・性能予測 
 Service Meshはサイドカープロキシにより各Podマイクロサービス間の通信が透過的にルーティングされ

    る仕組みであるため、問題が発生した際の追跡が複雑になり、また各Podにかかる負荷やリソース消費 量は変わってくる。よって以下のことが非常に重要となる 33 • 可観測性の向上 （メトリクス、分散トレーシング、ダッシュボード） ◦ 運用負荷軽減のため監視・観測システムはマネージド・サービス（Datadog）を活用 • 負荷試験によるチューニングとサイジング Istioのプロダクション環境導入のために実施した可観測性向上対策、負荷 試験、チューニング、サイジングなどの取り組みについて詳しくはこちらの テックブログを参照ください
 
 Istioによるサービスメッシュをどのようにプロダクションレディにするか
 https://techblog.zozo.com/entry/zozotown-istio-production-ready


34. © ZOZO Technologies, Inc. Service Meshの導入におけるトレードオフ
 34 さまざまな選定ポイントを考慮し適切にトレードオフしていきましょう • アーキテクチャの複雑度

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

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 （意訳）アーキテクチャに正解はない - あるのはトレードオフのみ

36. © ZOZO Technologies, Inc. まとめ
 36 • マイクロサービスにおけるサービス間通信の課題解決のためにService Mesh アーキテクチャに移行（現在進行中）

    • 既存のAPI Gatewayとの機能整理と責務の分担を行い、リスクを低減すべく段 階的な移行を実施 • 構成管理の自動化・効率化、可観測性の担保など、運用性の向上にも着手
37. None