How to setup Production Ready Istio?

by akitok

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 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 Traﬃc Egress Traﬃc

Slide 9

Slide 9 text

© 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 Traﬃc Egress Traﬃc

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© 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 参照のこと

Slide 15

Slide 15 text

© 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 参照のこと

Slide 16

Slide 16 text

© 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 参照のこと

Slide 17

Slide 17 text

© 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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

© 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

Slide 23

Slide 23 text

© 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) 接続元接続先

Slide 24

Slide 24 text

© 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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

© 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（リクエスト数）

Slide 30

Slide 30 text

© 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. 注入失敗

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

No content