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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

© ZOZO Technologies, Inc. https://zozo.jp/  3 ● 日本最大級のファッション通販サイト  ● 1,400以上のショップ、8,200以上のブランドの取り扱い（ともに2021年3月末時点）  ● 常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着商品を掲載  ● コスメ専門モール「ZOZOCOSME」や靴の専門モール  「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン  「ZOZOVILLA」を展開  ● 即日配送サービス  ● ギフトラッピングサービス  ● ツケ払いなど 

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

© 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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Service Meshの実装にIstioを採用 

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

© 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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

© 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 

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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