1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio

© Hitachi, Ltd. 2019. All rights reserved.
1年間のシステム運⽤を通して分かった
Istioの嬉しさと活⽤における注意点
#cndk2019 #roomB
株式会社⽇⽴製作所
研究開発グループ
井出貴也
CloudNative Days Kansai 2019

View Slide

§ ServiceMeshやIstioが注⽬を集めている
ü IstioはGitHubのFastest Growing Projectの第4位
§ ⼀⽅で，国内でのIstio活⽤事例はまだ少数
Q. 実サービスに導⼊済の⼈
Q. 検証中の⼈
Q. 使ったことがある⼈
Q. 概要を知っている⼈
§ ⽇⽴では社内向けシステムにIstioを導⼊し，1年に渡って運⽤
§ そこで得たIstioの嬉しさや問題点，
問題への対策といったプラクティスを共有します
本セッションの趣旨
1

View Slide

内容
1. なぜServiceMeshが求められるのか
2. Istioとは?
3. 社内でのIstio活⽤ユースケース
4. 運⽤を通して分かったこと
2

View Slide

なぜServiceMeshが求められるのか
3

View Slide

Microservice
§ 複数の⼩さなサービスを連携させてシステムを構成する設計⼿法
§ サービスごとに⼩さなチームが存在。⾃律的に開発・運⽤
§ 利点
ü ⼤規模開発しやすい
ü 変更しやすい
ü スケーリングしやすい
ü 障害が波及しにくい
4
Microservice
UI
Auth
Svc1
Svc2
Svc3

View Slide

Microserviceの成⻑
§ ビジネスの成⻑に伴いシステムは⼤きくなる
ü サービスやサービスチームの増加
ü それぞれのサービスが随時変化していく
ü サービスの開発⾔語や品質も様々
5
※イメージ図
Death Star Diagram

View Slide

Microserviceの運⽤
§ ⼤きなMicroserviceをどう運⽤するか
ü サービス間のルーティングは？
ü 通信先のサービスが落ちていた場合の対応は？
ü 通信のアクセス制御は？
ü システム全体の可視化は？
§ 各サービスチームが上記課題を個別解決 → ✕
ü 開発・運⽤の⼯数が⼤きい
ü 仕様や品質がバラバラになる
§ 個々のサービスに影響を与えず，
システム全体に渡って⼀貫性のある解決⼿段が求められる
→ ServiceMeshというアイデア
6

View Slide

© Hitachi, Ltd. 2019. All rights reserved. 7
Istio

View Slide

Istioとは？
8

View Slide

Istio Overview
§ GoogleとIBMが開発するOSSのServiceMesh実装
ü ⾼機能，⾼い知名度
ü 機能⽐較：INNOQ Service Mesh Comparison https://servicemesh.es/
ü 「servicemesh es」で検索
§ 価値：
個々のサービスから透過的に
システム全体に渡って⼀貫性のある⽅法で
サービス間通信を管理
9

View Slide

Istioの挙動
10
Pod
Pod
Service
Container Container
Service
Kuberntes内の通信はServiceを
介してPod内のコンテナに届く
Ingress

View Slide

Pod
Pod
Container Container
Istioの挙動
Service
Istioは各Podに透過プロキシサーバ
を挿⼊。プロキシ経由でコンテナ
に通信が届く
Service
Proxy
11
Proxy Proxy

View Slide

Istioの挙動
Pod
Pod
Proxy Proxy
Container Container
Service
Proxy
Service
Control
Plane
12
Istio Control Planeが
各プロキシを動的制御
に通信が届く

View Slide

Istioの挙動
Pod
Pod
Proxy Proxy
Container Container
Service
Service
Proxy
端点を抑えているため、コンテナ
から透過的にネットワークを制御
できる
13
Control
Plane
Routing
Monitoring
Access Ctrl
Late Limit
etc.
に通信が届く

View Slide

Istioの挙動
Pod
Pod
Proxy Proxy
Container Container
Service
Service
Proxy
できる
14
Routing
Monitoring
Access Ctrl
Late Limit
etc.
に通信が届く
Control
Plane

View Slide

Istio Control Plane
§ Pilot
ü プロキシへの設定デリバリ
ü Service Discovery
§ Mixer
ü メトリクス収集
ü Policyチェック
§ Citadel
ü TLSの鍵管理
§ Galley
ü 基盤システム(k8s)連携
15
https://istio.io/docs/concepts/what-is-istio/

View Slide

Istioの挙動
Pod
Pod
Proxy Proxy
Container Container
Service
Service
Proxy
できる
16
に通信が届く
Control
Plane
Routing
Monitoring
Access Ctrl
Late Limit
etc.

View Slide

Envoy Proxy
§ Lyftが開発したL4/L7プロキシ
§ API経由での動的な設定変更
§ 多機能
§ 本番サービスでの利⽤実績
§ 多くのService Meshがプロキシ
として採⽤
https://github.com/Proxyproxy/artwork 17

View Slide

Istio機能
§ 通信管理 Traffic Management
Service Discovery, Dynamic Request Routing,
Load Balancing, Mirroring, Splitting, Shaping,
Timeout, Retry, CORS, Circuit Braking, Chaos Engineering
§ セキュリティ管理 Security Management
Authorization, Authentication,
Access Control, TLS key management, etc.
§ 可観測性 Observability
Monitoring, Logging, Distributed Tracing
18
→ ⾯⽩い機能をいくつか抜粋して紹介

View Slide

Traffic Management
§ Dynamic Request Routing
ü ポリシーに基づく動的な通信制御
ü ルーティングに利⽤可能な値
ü Kubernetes情報：Namespace，Service，Label...
ü トラフィック情報：URI，HTTP Method，HTTP Header...
ü VirtualServiceリソースとDestinationRuleリソースで制御
ü MirroringやSplittingとも連携でき，とても柔軟な通信制御を実現
19

View Slide

§ カナリアリリース
§ ユーザ通信のうち
90% は v1 の app に,
10% は v2 の app に転送
Proxy
Container
version: v1
Proxy
Container
version: v2
90%
10%
app
例 | ポリシーに基づく動的な通信制御
20
https://istio.io/blog/2017/0.1-canary/

View Slide

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: canary
spec:
hosts:
- app
http:
- route:
- destination:
host: app
subset: v1
weight: 90
- destination:
host: app
subset: v2
weight: 10
Proxy
Container
version: v1
Proxy
Container
version: v2
90%
10%
app
21
apiVersion: networking.ist
kind: DestinationRule
metadata:
name: canary
spec:
host: app
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2

View Slide

metadata:
name: canary
spec:
hosts:
- app
http:
- route:
- destination:
host: app
subset: v1
weight: 90
- destination:
host: app
subset: v2
weight: 10
Proxy
Container
version: v1
Proxy
Container
version: v2
90%
10%
app
22
apiVersion: networking.ist
metadata:
name: canary
spec:
host: app
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Labelに
紐付け
割合を指定

View Slide

metadata:
name: canary
spec:
hosts:
- app
http:
- match:
- headers:
cookie:
regex: "^(.*?;)?(email=[^;]*@foobar.com)(;.*)?$"
route:
- destination:
host: app
subset: v1
weight: 90
- destination:
host: app
subset: v2
weight: 10
- route:
- destination:
host: app
subset: v1
§ foobar.comのメールアドレスを
持つユーザ通信のうち,
90% は v1 のアプリに,
10% は v2 のアプリに転送
例2 | ポリシーに基づく動的な通信制御
23
apiVersion: networking.istio.io/v1alph
metadata:
name: canary
spec:
host: app
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Proxy
Container
version: v1
Proxy
Container
version: v2
app
[email protected]
90%
10%
100%

View Slide

§ foobar.comのメールアドレスを
持つユーザ通信のうち,
90% は v1 のアプリに,
10% は v2 のアプリに転送
例2 | ポリシーに基づく動的な通信制御
24
metadata:
name: canary
spec:
hosts:
- app
http:
- match:
- headers:
cookie:
regex: "^(.*?;)?(email=[^;]*@foobar.com)(;.*)?$"
route:
- destination:
host: app
subset: v1
weight: 90
- destination:
host: app
subset: v2
weight: 10
- route:
- destination:
host: app
subset: v1
apiVersion: networking.istio.io/v1alph
metadata:
name: canary
spec:
host: app
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Proxy
Container
version: v1
Proxy
Container
version: v2
app
[email protected]
cookieにfoobar.comの
メールアドレスを含む
含まない
※ cookieにユーザ情報を格納する
ことはセキュリティ上の懸念あり
90%
10%
100%

View Slide

Security and Policy
§ サービス間認証
ü mTLS：サーバとクライアント双⽅が証明書で互いを認証する
ü 受信側のmTLSはPolicyリソース，送信側のｍTLSはDestinationRuleで設定
ü 設定が複数リソースにまたがるため混乱しやすい
§ 認可
ü L7レベルのアクセス制御を⾏う
ü 認可の条件にはk8sの情報とトラフィックの情報が利⽤できる
ü ただし，k8sの情報は「送信元がプロキシ経由」&&「mTLS」が条件
ü Kubeletからのhealth checkは送信元がプロキシ経由ではないため落とされる
→ health checkを受け⼊れる設定ができた(rewriteAppHTTPProbers)
25

View Slide

Observability
§ アドオンとしていくつかの可視化ツールと連携
ü Prometheus，Grafana，Jaeger，Kiali
§ 相応の計算リソースを消費するため注意
26
画像引⽤元
Grafana: https://istio.io/docs/tasks/observability/metrics/using-istio-dashboard/
Jaeger: https://istio.io/docs/tasks/observability/distributed-tracing/jaeger/
kiali: https://github.com/kiali/kiali
Grafana Kiali
Jaeger

View Slide

社内でのIstio活⽤ユースケース
27

View Slide

対象システム
§ 社内の開発者向けに開発環境を提供するサービス
ü Webエディタやバックエンドサービスなどを提供
ü バックエンドサービスは各チームが⾃律的に開発
§ Kubernetesベース。100+ Nodes，2000+ Pods
28
Kubernetes
Web
Editor
Backend
Service
1
Backend
Service
2
App
App開発,
実⾏
社内開発者
(ユーザ)
Backend Service1
開発チーム
Backend Service2
開発チーム
呼び出し
プラットフォーム
チーム
Backend
Service1開発
Backend
Service2開発
環境構築,運⽤
稼働

View Slide

Istio導⼊のモチベーション
1. サービス間通信を管理したい
ü 柔軟なルーティング
ü サービス間アクセス制御
ü 通信メトリクスの収集
2. しかし，バックエンドサービス
の内部には⼲渉したくない
3. Istioのトレンドが急浮上
29
検証も兼ねてIstioを導⼊
本番環境で1年ほど運⽤
Kubernetes
Web
Editor
Backend
Service
1
Backend
Service
2
App
App開発,
実⾏
社内開発者
(ユーザ)
Backend Service1
開発チーム
Backend Service2
開発チーム
呼び出し
プラットフォーム
チーム
Backend
Service1開発
Backend
Service2開発
環境構築,運⽤
稼働

View Slide

運⽤を通して分かったこと
30

View Slide

総評
便利だが
運⽤負荷は重い
§ 運⽤負荷をペイできるユースケースがあるか
§ 運⽤体制は整っているか
31
運⽤負荷以外にも観点はある
• システムの複雑化を許容できるか?
• リソースの消費は?
• レイテンシの追加は?

View Slide

総評
便利だが
32

View Slide

Istioを利⽤して良かった点
1. サービスから透過的な通信管理
2. Kubernetesネイティブ
3. コミュニティの活発さ
33

View Slide

良かった点1｜サービスから透過的な通信管理
§ 個々のサービスを改修しなくて良い
ü OSSや既存プロダクトなど，改修が⼤変なアプリを使う際に便利
ü Auto-Injection機能によりプロキシの⾃動挿⼊もできる
ü サービスチームとのコミュニケーションコストも少ない（はず）
§ 柔軟・⾼機能な通信管理
ü NamespaceやLabelによるルーティング・アクセス制御
ü 今までサービス内で設定していたリトライ数やタイムアウト，
サーキットブレイクなどの設定もできる
34

View Slide

良かった点2｜Kubernetesネイティブ
§ Istioの全制御がカスタムリソースで完結
ü HelmなどのKubernetesエコシステムを活⽤できる
§ Istio本体もKubernetesで動作
ü Replicaによる可⽤性
ü Horizontal Pod Autoscalingによるスケーラビリティ
ü ControlPlaneの処理負荷には注意
§ 宣⾔的ネットワーク管理
ü 設定ファイルがそのままネットワーク構成の定義になる
ü CI/CDやGitOpsの世界観でネットワークを管理
35

View Slide

良かった点3｜コミュニティの活発さ
§ コミュニティが⼤きく，活発
ü Issueの平均対応時間：5⽇※1
ü 隔週レベルでのパッチアップデート
ü v1.1以降品質も安定
§ 情報も多い
ü 公式ドキュメント，Issue，書籍，ブログ
ü ただし，陳腐化も早い
36
※1 Istio Project Dashboards
https://istio.teststats.cncf.io/d/11/issues-age-by-repository-group?orgId=1

View Slide

総評
便利だが
37

View Slide

Istio活⽤における注意点
1. 運⽤難度が⾼い
2. 3ヶ⽉ごとのアップデート
3. サービスとプラットフォームの境界
4. Proxyのメモリ消費
5. 認証・認可のマイグレーション
38

View Slide

注意点1｜運⽤難度が⾼い
§ Istioは通信制御, 認証認可, 監視の機能を集約している
ü 様々な機能，⾼い⾃由度，無数の設定ファイル
ü サービス間の整合担保が⼤変
ü 運⽤に辺り覚えることが多く，属⼈化しやすい
§ 障害時の原因切り分けが困難
ü 物理, Kubernetes, App,…様々な要素が絡む
ü プロキシのタイムアウトで障害が顕在化 → Istioが疑われやすい
ü 例: 通信先のアプリが落ちた → Envoy「504 gateway timeouts」
ü 障害時，Istioの名前が上がるため悪いイメージが付きやすい
ü デバッグの最終⼿段：Envoyコンテナにnetcatとtcpdumpが⼊っている
39

View Slide

対策1｜社内Istio情報共有Wiki
§ Istioの情報を⼀元管理する
Wikiを作成し社内で情報共有
（社外公開の予定なし）
§ コンテンツ
ü Istioの価値，概要
ü Istioの挙動調査結果
ü 過去の障害情報
ü デバッグ⽅法
ü etc.
40

View Slide

注意点2｜3ヶ⽉ごとのアップデート
§ Istioは3ヶ⽉ごとにリリース + 過去1バージョンのみサポート※1
ü バージョンアップへの追従が必要
ü 検証や移⾏の⼯数は⼤きい。⼀⼈は専任した⽅が良い
§ アップデートに伴う構成の再検討が必要な場合も
ü PatchアップデートでServiceEntryの宛先をanyにする設定が禁⽌に
§ リソース消費量も変化する
○ v1.1からv1.3までの間にPilotの消費メモリは1/5に減少
✕ envoy_statsdログの出⼒がデフォルトで有効化（1.0.3以降無効化）
→ Pod数の2乗に⽐例する量のメトリクスを出⼒。輻輳発⽣
41
※1 Istio Build & Release Cadence https://istio.io/about/release-cadence/

View Slide

対策2｜Istio-Operator
§ Istioの運⽤操作を⾃動化するOperator
ü 現在はインストールやアップデートがメイン
ü インストールの複雑さを隠す⾼レベルなAPIを提供
ü ValidationやDeprecatedポリシーの適⽤による堅牢性向上
ü Helmによるインストールは今後廃⽌予定
ü マルチクラスタ連携の議論が進んでいる
§ Istioプロジェクト以外にも2種のIstio-Operatorが存在
ü Banzai Cloud版：OperatorHub.io掲載。マルチクラスタ連携の機能あり
ü Maistra版： OpenShiftが採⽤。Kiali，Jaeger，Elasticsearchと連携
42
Introducing the Istio Operator
https://istio.io/blog/2019/introducing-istio-operator/

View Slide

注意点3｜サービスとプラットフォームの境界
§ サービスとIstioで機能が重複
ü Timeout，Retry，CORSなどの機能はサービス側にもIstio側にも存在
ü 無理なIstio押し付けはサービスチームの反発をまねく
ü 「サービス側でRetryを実装済みだからIstioの機能は使わないよ？」
ü 「HTTPSが前提のOSSを使っているから、
プロキシでHTTPS終端しないで」
§ Istioリソースの操作権限問題
ü Istioはクラスタ全体に適⽤される機能がある（例 DestinationRule）
ü サービスチームがこれらリソースを⾃由にデプロイ → クラスタ障害
ü ⼀⽅でルーティングやTimeout等の設定はサービスチームに任せたい
43

View Slide

対策3｜Helm chart化
§ Istioの設定をHelm Chartとしてパッケージングし，
サービスチームに提供
ü サービスチームに操作してほしい機能のみを
設定項⽬(values)として切り出す
ü 公開するポート番号，プロトコル
ü Timeout，Retry，etc.
§ サービスチームは⾃分の使いたい機能をHelmを介して設定
44

View Slide

注意点4｜プロキシのメモリ消費
§ 各プロキシはどうやって他プロキシの宛先を把握しているのか？
→ ControlPlaneで宛先リスト(Clusters情報)を作成し，各プロキシに配布
§ 弊環境だとPod数に⽐例して宛先リストが増加
ü 宛先リストは各プロキシのメモリに格納
ü Pod数が多くなると，このメモリ消費量が無視できない値に
ü 最初期はPod数が1000になると個々のプロキシが750MBのメモリを消費
ü 750MBのメモリを消費するPodが1000個もある!?
ü 上⼿くサイジングしないと，OOM KillerでPodやNodeが落ちる
ü また，リソース消費傾向はバージョンごとに変化
→ リソース管理のためには，Istioアップデートのたびに性能評価要
45

View Slide

対策4｜性能評価⾃動化ツール「istio-bench」
§ Pod数に応じた計算リソース消費量を予測するツール
ü ダミーPodを50個デプロイし，Istioコンポーネントの
リソース消費量（メモリ・CPU・通信量）をPrometheusから収集
ü ダミーPodが500個になるまで繰り返し, 近似式を算出
§ コミュニティに提案したい
46

View Slide

対策4｜(参考)プロキシのメモリ消費量の変遷
47
§ Podが1000個存在するときのプロキシ⼀個あたりの消費メモリを算出
§ v1.0の間に急激に減少(嬉しい)。それ以降も緩やかに減少中
771MB
268MB
163MB 145MB 127MB
0
200
400
600
800
1000
1.0.2 1.0.7 1.1.7 1.2.9 1.3.2
メモリ消費量[MB]
Istioのバージョン

View Slide

対策4｜SideCarリソース (alpha)
§ プロキシを直接制御するリソース
§ 通信先を限定することで宛先リストのサイズを固定できることを確認
§ 設定の抽象度が他と異なる。導⼊するかは未定
48
kind: Sidecar
metadata:
name: clusters-reducer
namespace: default
spec:
egress:
- hosts:
- "default/*"
- "istio-system/*"
Sidecar https://istio.io/docs/reference/config/networking/sidecar/

View Slide

注意点5｜認証・認可のマイグレーション
Istioの機能をいきなりシステム全体に適⽤するとリスク⾼
⼀⽅で，⼀部のみにIstioを適⽤すると認証・認可が複雑になる
§ 認証
ü mTLS：クライアントとサーバ双⽅が証明書で互いに認証
ü Istioが適⽤されていないPodはmTLSが使えない
ü 送信元はIstio適⽤済みか，宛先は…と適⽤対象を考慮した設定が必要
§ 認可
ü 認可条件にKubernetesの情報を使うには，
送信元/宛先双⽅でmTLSの有効化が必須
ü このため，認証と同じ問題があり，Istio配下ではないサービスごとに
認可の⽅法を考える必要あり
49

View Slide

対策5｜認証のパターン整理
Istio適⽤の有無で通信の条件を整理し，前述のHelm Chartに反映
50
#
送信元
Istio適⽤
宛先
Istio適⽤
通信可能な条件
1 済済
送信側/受信側ともにTLS設定が
有効 or 無効で統⼀されている
2 済未送信側でTLS設定が無効化されている
3 未済
受信側のTLS設定が無効、もしくは
mode: PERMISSIVEになっている
4 未未
無条件で可能。
ただし，⼀切のアクセス制御をかけられない

View Slide

対策5｜よくあるエラーとその原因の共有
よくあるエラーとその原因をまとめ，プラットフォームチーム内で共有
51
# エラーメッセージ原因
1
upstream connect error
or disconnect/reset
before header
ü プロキシが落ちている or 調⼦が悪い※1
2
Connection reset by
peer
ü 認証設定の問題。受信/送信の何れか⼀⽅が
mTLSで、もう⽚⽅がPlainTextになっている
3 403 access denied
ü 認可設定の不整合，もしくは
送信側がプロキシを経由していない
ü 受信側プロキシのログをdebugレベルで⾒て，
アクセス情報にNamespace等があればプロキシ経由
※1 Proxyが落ちるとPodはUnhealthyにはなるが，
PID1(pilot-agent)が⽣きているため再起動されない

View Slide

対策5｜Automatic mutual TLS (Alpha)
§ Istio 1.4で導⼊された機能
§ 送信側mTLS設定（DestinationRule相当）を⾃動で⾏う
ü 両⽅ともプロキシが挿⼊されたPod間の通信 → mTLS
ü ⽚⽅でもプロキシが無いPod間の通信 → Plain Text
§ 受信側mTLS設定（Policy）は⼿動設定
52
Automatic mutual TLS
https://istio.io/docs/tasks/security/authentication/auto-mtls/
Pod
Container
Proxy
Pod
Container
Proxy
mTLS
Pod
Container
Proxy
Pod
Container
Plain Text

View Slide

[再掲] 総評
便利だが
53

View Slide

まとめ
IstioはMicroserviceの運⽤を⾏うためのもの
§ サービスから透過的で⼀貫性のある通信管理を実現
§ 通信管理，セキュリティ管理，可観測性の機能を持つ
便利だが運⽤負荷は重い
§ ⾼機能・柔軟な通信制御，Kubernetesネイティブ
などの利点あり
§ しかし，運⽤負荷は重く，プラクティスも発展途上
§ コストをペイできるユースケースがあるか
55

View Slide

Trademarks
§ Istioは、Google LLCの⽶国における登
録商標または商標です
§ Envoyは、The Linux Foundationの⽶国
またはその他の国における登録商標ま
たは商標です
§ Kubernetesは、The Linux Foundationの
⽶国またはその他の国における登録商
標または商標です
§ Prometheusは、The Linux Foundationの
⽶国またはその他の国における登録商
標または商標です
§ Grafanaは、Grafana Labsの⽶国または
その他の国における登録商標または商
標です
§ Jaegerは、 The Linux Foundationの⽶国
またはその他の国における登録商標ま
たは商標です
§ Kialiは、 Red Hat, Inc.の⽶国またはその
他の国における登録商標または商標で
す
§ その他記載の会社名、製品名、サービ
ス名、その他固有名詞は、それぞれの
会社の商標または登録商標です
§ 本発表中の⽂章、図では、TM、マー
クは表記しておりません。
56

View Slide

View Slide

1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio

1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio

id

More Decks by id

Other Decks in Technology

Featured

Transcript