How to setup Production Ready Istio? Kubernetes Meetup Tokyo #42 2021/6/24 株式会社ZOZOテクノロジーズ SRE部 ECプラットフォームSRE 小林 明斗 Copyright © ZOZO Technologies, Inc.

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ SRE部 小林 明斗 @akitok_ 2020年7月にZOZOテクノロジーズへ中途入社 前職は通信系SIerでバックエンドやインフラを中心に テックリードとして活動していました 現在はZOZOTOWNリプレイスプロジェクトにSREとし て参画しています 2

© ZOZO Technologies, Inc. https://zozo.jp/ ● 日本最大級のファッション通販サイト ● 1,400以上のショップ、8,100以上のブランドの取り扱い（とも に2020年12月末時点） ● 常時83万点以上の商品アイテム数と毎日平均3,000点以上の新着 商品を掲載 ● 即日配送サービス ● ギフトラッピングサービス ● ツケ払い など 3

© ZOZO Technologies, Inc. アジェンダ ● はじめに ● What is Istio? ● How to setup Production Ready Istio? ○ どのようにリソース消費量を見積もるか ○ 何を監視するか ○ どのように可観測性を向上させるか 4

© ZOZO Technologies, Inc. 5 はじめに

© ZOZO Technologies, Inc. はじめに ● 今日話すこと ○ Istioをプロダクションレディにするための取り組み ■ 負荷試験、監視、可観測性 ● 今日（あまり）話さないこと ○ なぜマイクロサービスなのか？ ○ Istioの構築、設定方法など 6

© ZOZO Technologies, Inc. 7 What is Istio?

© ZOZO Technologies, Inc. What is Istio? ● マイクロサービスの複雑性を解決する「サービスメッシュ」を実現するための フレームワーク ○ Google、IBM、Lyftの3社共同開発により、2017年5月にOSS化 ○ KubernetesのPodにプロキシ（Envoy）をサイドカーコンテナとして注入し、 サービスのコード変更を伴わずにサービスメッシュを実現可能 8 Data Plane App A (container) envoy proxy Istiod Control Plane App B (container) envoy proxy Pod Pod envoy proxy Pod IngressGateway envoy proxy Pod EgressGateway Ingress Traffic Egress Traffic

© ZOZO Technologies, Inc. What is Istio? ● Data Plane ○ サイドカーとして注入されるEnvoyプロキシ（正確にはEnvoyプロキシの拡張）の コンテナから構成される ○ このプロキシがマイクロサービス間の通信を仲介・制御する ● Control Plane ○ Envoyプロキシコンテナのサービスへの注入や設定伝搬を司る 9 Data Plane App A (container) envoy proxy Istiod Control Plane App B (container) envoy proxy Pod Pod envoy proxy Pod IngressGateway envoy proxy Pod EgressGateway Ingress Traffic Egress Traffic

© ZOZO Technologies, Inc. 10 How to setup Production Ready Istio? - Istioをプロダクションレディにするために直面した課題

© ZOZO Technologies, Inc. 11 1. どのようにリソース消費量を見積もるか？ 2. 何を監視するか？ 3. どのように可観測性を向上させるか？

© ZOZO Technologies, Inc. 12 1. どのようにリソース消費量を見積もるか？ 2. 何を監視するか？ 3. どのように可観測性を向上させるか？

© ZOZO Technologies, Inc. どのようにリソース消費量を見積もるか？ ● Istioに限らず、プロダクションレディな状態で本番に導入するためには、 適切なキャパシティサイジングがされている必要がある ○ ZOZOTOWNマイクロサービスプラットフォーム基盤では、プロダクションレディ チェックリストを策定しており、以下のような規定（一部抜粋）を設けている ■ k8s の resources limit に適切なリソース使用量が設定されている ■ k8s の node affinity で適切な nodegroup を利用するように設定している ■ k8s の pod 辺りのスループット (req/s) が見積もられている ■ 平常時、ピーク時それぞれで何台のPodが必要になるかわかっている ■ k8s の オートスケール (HPA) が発動する... etc. ○ これらを達成するためには、Istioのアーキテクチャに基づき、Data Plane / Control Planeでそれぞれ分けて考慮する必要がある 13

© ZOZO Technologies, Inc. Data Planeサイジング ● Istioの公式ドキュメントによれば、Data Plane（Envoy）のパフォーマンスは、 以下のようにレポートされている *1。 ○ Envoyプロキシは、1,000リクエスト/秒あたり0.35vCPUと40MBメモリを使用する ○ Envoyプロキシは、90パーセンタイルで、レイテンシに2.65ミリ秒を追加する ● また以下のような要素にも依存し、パフォーマンスは変動する ○ クライアント接続数 ○ 目標リクエストレート ○ リクエストサイズとレスポンスサイズ ○ プロキシワーカースレッド数 ○ プロトコル ○ CPUコア数... 14 *1 これはIstio 1.10を使用した上で、以下のような条件に基づいている ・サービスメッシュが1,000個のサービスと2,000個のEnvoyプロキシで構成される ・サービスメッシュ全体で秒間70,000回のリクエストがある 詳細は、https://istio.io/latest/docs/ops/deployment/performance-and-scalability 参照のこと

© ZOZO Technologies, Inc. Data Planeサイジング ● Istioの公式ドキュメントによれば、Data Plane（Envoy）のパフォーマンスは、以下 のようにレポートされている *1。 ○ Envoyプロキシは、1000リクエスト/秒あたり0.35vCPUと40MBメモリを使用する
 ○ Envoyプロキシは、90パーセンタイルで、レイテンシに2.65ミリ秒を追加する
 ● また以下のような要素にも依存し、パフォーマンスは変動する
 ○ クライアント接続数
 ○ 目標リクエストレート
 ○ リクエストサイズとレスポンスサイズ
 ○ プロキシワーカースレッド数
 ○ プロトコル
 ○ CPUコア数...
 15 つまり *1 これはIstio 1.10を使用した上で、以下のような条件に基づいている ・サービスメッシュが1,000個のサービスと2,000個のEnvoyプロキシで構成される ・サービスメッシュ全体で秒間70,000回のリクエストがある 詳細は、https://istio.io/latest/docs/ops/deployment/performance-and-scalability 参照のこと

© ZOZO Technologies, Inc. Data Planeサイジング ● Istioの公式ドキュメントによれば、Data Plane（Envoy）のパフォーマンスは、以下 のようにレポートされている *1。 ○ Envoyプロキシは、1000リクエスト/秒あたり0.35vCPUと40MBメモリを使用する
 ○ Envoyプロキシは、90パーセンタイルで、レイテンシに2.65ミリ秒を追加する
 ● また以下のような要素にも依存し、パフォーマンスは変動する
 ○ クライアント接続数
 ○ 目標リクエストレート
 ○ リクエストサイズとレスポンスサイズ
 ○ プロキシワーカースレッド数
 ○ プロトコル
 ○ CPUコア数...
 16 つまり 推測するな。計測せよ。 *1 これはIstio 1.10を使用した上で、以下のような条件に基づいている ・サービスメッシュが1,000個のサービスと2,000個のEnvoyプロキシで構成される ・サービスメッシュ全体で秒間70,000回のリクエストがある 詳細は、https://istio.io/latest/docs/ops/deployment/performance-and-scalability 参照のこと

© ZOZO Technologies, Inc. Envoyプロキシチューニング ● Envoyプロキシのresource設定は、Envoyプロキシを注入するリソースに対し spec.template.metadata.annotationsの指定を追加することで、チューニング可能 ● 右記はEnvoyプロキシの CPU Limitを500m、 Memory Limitを512Miに 指定するサンプル 17 annotation 説明 sidecar.istio.io/proxyCPU EnvoyプロキシのCPU Requestを指定 sidecar.istio.io/proxyCPULimit EnvoyプロキシのCPU Limitを指定 sidecar.istio.io/proxyMemory EnvoyプロキシのMemory Requestを指定 sidecar.istio.io/proxyMemoryLimit EnvoyプロキシのMemory Limitを指定 apiVersion: apps/v1 kind: Deployment metadata: name: test-api spec: template: metadata: annotations: sidecar.istio.io/proxyCPULimit: 500m sidecar.istio.io/proxyMemoryLimit: 512Mi

© ZOZO Technologies, Inc. 負荷試験 ● ZOZOTOWNプラットフォーム基盤では、以下の3つの負荷試験フェーズに分け、パ フォーマンス測定・チューニングを繰り返す中で、キャパシティサイジングの精度向 上を図った 1. Istioベンチマーク試験 2. サービス単体負荷試験 3. サービス結合負荷試験 18

© ZOZO Technologies, Inc. Istioベンチマーク試験 Istioベンチマーク試験環境は、以下のような構成をとる ● Data Planeは実際のマイクロサービスではなく負荷試験クライアントであるFortio ● バックエンドサービスはhttpbinをモックとして水平スケールさせる 19 Data Plane httpbin Fortio envoy proxy Istiod Control Plane client

© ZOZO Technologies, Inc. Istioベンチマーク試験 この試験により、以下の結果を導出 ● Envoyプロキシの初期リソース（CPU、Memory）サイジング 他にもIstioのバージョンアップにおけるパフォーマンス変化を計測する環境としても利 用している 20 Data Plane httpbin Fortio envoy proxy Control Plane client Istiod

© ZOZO Technologies, Inc. サービス単体負荷試験 Data Plane envoy proxy Control Plane Istiod A Service 接続元 接続先 B Service client envoy proxy レイテンシ劣化 エラー多発 ● 複雑なサービスメッシュ構成においてはトラブルシューティングが困難 ● パフォーマンス問題が見られた場合、以下の被疑箇所を1つ1つ潰していく ○ 接続元サービス ○ 接続元サービスのEnvoyプロキシ ○ 接続先サービスのEnvoyプロキシ ○ 接続先サービス ○ さらに接続先サービスの... ● 一気にすべてのサービスを通貫した テストを行うのは悪手

© ZOZO Technologies, Inc. サービス単体負荷試験 サービス単体負荷試験は、以下のような構成をとる ● Data Planeは試験対象のマイクロサービス ● バックエンドサービスはNginxを用いて静的コンテンツを返すモックを準備 ● 負荷試験クライアントはGatling 22 Data Plane Mock by Nginx (External A Service) A Service envoy proxy Control Plane Gatling Istiod Mock by Nginx (Internal B Service) Mock by Nginx (External B Service) envoy proxy

© ZOZO Technologies, Inc. サービス単体負荷試験 この試験では、以下のチューニング完了を目的とする ● 接続元サービス ● 接続元サービスのEnvoyプロキシ このフェーズを終えた上で、サービス通貫したテストに進める 23 Data Plane Mock by Nginx (External A Service) A Service envoy proxy Control Plane Gatling Istiod Mock by Nginx (Internal B Service) envoy proxy Mock by Nginx (External B Service) 接続元 接続先

© ZOZO Technologies, Inc. サービス結合負荷試験 サービス結合負荷試験ではモックを用いずに、実際に各サービスを連携させる → この試験結果が期待通りでない場合は、単体負荷試験と比較し、切り分け・計測・ チューニングを繰り返す 24 Data Plane External A Service envoy proxy Control Plane Gatling Istiod Internal B Service External B Service A Service envoy proxy

© ZOZO Technologies, Inc. 負荷試験の3フェーズまとめ ● ZOZOTOWNプラットフォーム基盤では、以下の3つの負荷試験フェーズに分け、パ フォーマンス測定を行い、チューニング精度の向上を図った 25 Client Data Plane Backend Istioベンチマーク試験 負荷試験Client （Fortio） 負荷試験Client （Fortio） モック（httpbin） サービス単体負荷試験 負荷試験Client （Gatling） マイクロサービス モック（Nginx） サービス結合負荷試験 負荷試験Client （Gatling） マイクロサービス マイクロサービス

© ZOZO Technologies, Inc. Control Planeサイジング ● Control Planeを構成するIstiodコンポーネントのパフォーマンスは、以下の要素に 依存し、変動する ○ Deploymentの変更頻度 ○ Configurationの変更頻度 ○ Istiodに接続するEnvoyプロキシの数 → サービスメッシュが大きくなればなるほど、リソースを消費する。 ● Istiodは水平スケール可能なので、HPA（Horizontal Pod Autoscaler）設定を行う のが良い ● ZOZOTOWNプラットフォーム基盤では、Istio Operatorを用いた構築を行ってお り、これによりHPAは自動生成され、IstiodのCPU使用率が80%に到達したらオート スケールするようにしている 26

© ZOZO Technologies, Inc. 27 1. どのようにリソース消費量を見積もるか？ 2. 何を監視するか？ 3. どのように可観測性を向上させるか？

© ZOZO Technologies, Inc. 何を監視するか？ ● 前提としてZOZOTOWNプラットフォーム基盤における運用監視では、Amazon CloudWatchとDatadogを採用 ● 今回、既にDatadogで取得しているメトリクスと合わせたダッシュボードも作成する ことを考慮し、Istioに関する監視メトリクスもDatadogで取得する方針とした ● DatadogのIstio Integrationは公式ドキュメント参照のこと https://docs.datadoghq.com/ja/integrations/istio/ 28

© ZOZO Technologies, Inc. Data Planeメトリクス ● Data Planeの監視は以下2つのメトリクスを用いて、Data Plane全体のエラーレート に着目している 29 メトリクス 説明 trace.envoy.proxy.hits Envoyプロキシが受け付けたリクエスト数 trace.envoy.proxy.errors Envoyプロキシが受け付けたリクエストのエラー数 これらのメトリクスから、以下の計算でData Plane全体のエラーレートを算出し、監視 エラーレート ＝ trace.envoy.proxy.errors（エラー数） trace.envoy.proxy.hits（リクエスト数）

© ZOZO Technologies, Inc. Control Planeメトリクス Control PlaneはHPA設定をしているため インフラメトリクスではなく以下の事象 を捉えることが重要と考えた 1. 何らかの原因でEnvoyプロキシの 注入に失敗している 2. 何らかの原因でEnvoyプロキシへの 設定検証に失敗し、設定伝搬できない これらは、以下のメトリクスにより捕捉可能 30 メトリクス 説明 istio.sidecar_injection.failure_total Envoyプロキシの注入に失敗した回数 istio.galley.validation.failed Envoyプロキシへの設定検証に失敗した回数 Data Plane A Service envoy proxy Control Plane Istiod B Service envoy proxy C Service envoy proxy 2. 設定検証・伝搬失敗 1. 注入失敗

© ZOZO Technologies, Inc. 分散トレーシング 31 Data Plane envoy proxy Control Plane Istiod A Service 接続元 接続先 B Service client envoy proxy レイテンシ劣化 ● Istioでのサービスメッシュ導入により、サービス間の通信に複雑性が増し、トラブル シューティングは非常に困難 ● 例えば、あるサービスのレイテンシ劣化が観測 された場合に、すべてのサービス呼び出しを トレースし、原因特定するのは至難の業 ● そこで、分散トレーシングが登場 ➔ 複数サービスをまたいで処理される リクエストの流れをトレースする技術 ➔ サービスの依存関係やサービスごとの レイテンシの可観測性を高めることで、 トラブルシューティングを助ける

© ZOZO Technologies, Inc. 分散トレーシング 32 ● ZOZOTOWNプラットフォーム基盤では、Datadog APMを活用し、各マイクロサービ ス及びEnvoyプロキシの通信を一気通貫し、トレースできるようにした ● 右記は実際の例 ○ えんじ色の部分が Envoyプロキシ ○ 複数サービスを跨いだトレースで、 サービス間の呼び出し関係、 各サービスのレイテンシなど 調査しやすい

© ZOZO Technologies, Inc. 33 1. どのようにリソース消費量を見積もるか？ 2. 何を監視するか？ 3. どのように可観測性を向上させるか？

© ZOZO Technologies, Inc. どのように可観測性を向上させるか？ ● 監視検討を行う中で、監視対象としてアラートを出す必要はないものの、運用状態と して、見たいときにすぐ見られるよう可観測性高く保ちたいようなものもあった → Datadog Dashboardに集約 34

© ZOZO Technologies, Inc. どのように可観測性を向上させるか？ ● Dashboardは、障害発生時などの問題切り分けに役立つ 例えば、エラーレート高騰時に以下を切り分けたい場合がある ○ 特定のマイクロサービスのみで発生している？ ○ サービスメッシュ全体で発生している？ ● これについては、以下のグラフデータを参考にして、切り分けている ● 具体的には、以下のように判断する補助としている ○ 上位2つのデータが相関している → メッシュ全体で問題が起きているはず ○ 上位2つのデータが相関していない → エラー数上位にきているサービスが怪しい？ ■ ex. リクエスト数上位ではないのに、エラー数上位に現れるサービスがある 35 グラフ 説明 Top request resource メッシュ内でリクエスト数上位のサービス Top error resrouce メッシュ内でエラー数上位のサービス

© ZOZO Technologies, Inc. まとめ ● どのようにリソース消費量を見積もるか？ ○ Data Plane ■ ベンチマーク / サービス単体 / サービス結合 負荷試験による計測・チューニング ○ Control Plane ■ メッシュが大きくなればなるほどリソース消費が増すため、オートスケール対応 ● 何を監視するか？ ○ Data Plane 全体のエラーレート ○ Control Plane （Istiod） のふるまい異常 ○ 分散トレーシング ● どのように可観測性を向上させるか？ ○ Metrics Dashboard 36

No content