Istioを活用したObservability基盤の構築と運用 / Constructing and operating the observability platform using Istio

© Hitachi, Ltd. 2021. All rights reserved.
Istioを活用したObservability基盤の構築と運用
CloudNative Days Spring 2021 Online
株式会社日立製作所
研究開発グループ
井出貴也

View Slide

はじめに
◇ SLI、SLOの決め方
◇ アラート設計、インシデント管理
◇ 監視結果に基づく運用の改善
1
Istioと監視系OSSを組み合わせ、アプリから透過的に
サービスレベルを監視する基盤を構築した際の知見の共有
◇ Observabilityとは何か
◇ IstioのObservability機能
◇ Istioと監視系OSSの連携のTips
セッションテーマ
話すこと話さないこと

View Slide

目次
2
1. 背景
2. IstioのObservability機能調査
3. Istioと監視系OSSの連携
4. 構築や運用を通したTips
5. まとめ

View Slide

1. 背景
3

View Slide

What is Observability ? ※1
4
Testing
Debugging
Observability
Monitoring
状態実現手段
Observability
Tracing
Logging
Metrics
Profiling
Test
Events Analyzing
Chaos Eng.
Simulating
etc.
※1. ソフトウェア分野では合意された定義が存在しない。あくまで発表者が理解した定義。元々は制御理論の用語
▪ 対象システムへの任意の質問に手持ちのデータや知識でどれだけ答えられるか
▪ Observabilityの実現手段が監視やテスト。システムの内部状態を明らかにする
システムが出力したデータを活用し、システム内部で何が・何故起きているか理解できる状態

View Slide

Why Observability ?
未知の現象への対応
5
▪ 曖昧で変化の早いビジネス環境に合わせ、素早くかつ探索的にシステムを成長させる
◇ 複数チーム開発を可能にする分散システム
◇ 頻繁なコードの更新
◇ 動的なスケーリング
◇ etc.
→ 「絶えずその挙動を変化させる、複雑な相互作用を持ったコンポーネント群」の運用
▪ 何が起こるか想定しきれない
▪ この中にあって意思決定ができるよう、未知の現象に気付き、理解するに足るだけの
データを収集・分析する体制を整える → Observability

View Slide

サービスレベルの監視
▪ サービスレベル：サービス品質の指標になりうる監視データ。リクエスト応答時間やエラー率など※1
▪ サービスレベルの監視はシステム監視では検知できないサービス品質劣化を検知できうる
▪ ただし、サービスレベル監視データはプラットフォーム側では取得できないことも多い
◇ 実際、Kubernetes単体では取得できず、アプリ側での対応が必要※2
6
運用者
ユーザ
応答が遅い
Kubernetes
・ CPU使用率正常
・エラーログなし
→問題に気付けず
アプリ
応答時間
情報
※1 書籍「Site Reliability Engineering」にて応答時間やエラー率はゴールデンシグナルと扱われる
※2 ブラックボックス監視はアプリによらず可能だが、ホワイトボックス監視に比べ情報量が落ちるほか副作用の恐れあり
システム監視
サービスレベル監視
運用者
応答時間の
問題に気付く
!!
監視
監視
シングルスレッド
で動作
??
アクセス

View Slide

◇ 実際、Kubernetes単体では取得できず、アプリ側での対応が必要
7
運用者
ユーザ
応答が遅い
Kubernetes
・ CPU使用率正常
アプリ
応答時間
情報
システム監視
運用者
応答時間の
問題に気付く
!!
監視
監視
で動作
??
アクセス

View Slide

◇ 実際、Kubernetes単体では取得できず、アプリ側での対応が必要※2
8
運用者
ユーザ
応答が遅い
Kubernetes
・ CPU消費正常
アプリ
応答時間
メトリクス
システム監視
運用者
応答時間の
問題に気付く
!!
監視
監視
で動作
??
アクセス
アプリ側での対応が必要
✓ 無数に稼働しているアプリ全てがサービスレベルの
監視に対応できるとは限らない
✓ 対応できたとしても仕様がバラバラの可能性
✓ 他社製品を利用していると改修も困難
どうすれば良いのか？

View Slide

© Hitachi, Ltd. 2021. All rights reserved. 9
I s t i o

View Slide

Istioによるサービスレベルの取得
▪ Istioは各アプリの前段にプロキシを配置し、アプリ間の通信を中継・制御するソフトウェア
▪ 中継する際の通信情報からサービスレベルの情報を収集
▪ HTTPで通信を行うアプリは、その仕様に依らずサービスレベルの監視が可能
10
▪ スループット
▪ 応答時間
▪ エラー率
▪ アクセスログ
▪ トレーシング
▪ etc.
…
Kubernetes
アプリ
監視ツール
(Prometheus等)
アプリ
Istio-proxy Istio-proxy
レスポンス
リクエスト
レス時刻 – リク時刻
→ 応答時間

View Slide

監視系
OSS
IstioのObservability対応
▪ 監視系OSSのバンドル機能があったが、2020/12月リリースのv1.8から廃止※1
◇ 理由：各監視系OSSの十全な機能を提供できないため
◇ 公式のドキュメントやサンプルに基づき、ユーザが自前で連携を行う
→ 連携のプラクティスを貯める必要はあるものの、高い自由度で連携可能
11
※1 “Reworking our Addon Integrations” https://istio.io/latest/blog/2020/addon-rework/
Istio Istio
監視系
OSS
バンドル
自由に
連携
Before After

View Slide

Istioを用いたObservability基盤の実践
▪ 連携にあたってのプラクティスや注意点を洗い出す。
サンプル実装に縛られず、自前でIstioと各種監視系OSSを連携させる
▪ 監視系OSSの機能を十全に活かす。Operatorなども積極的に活用し、
本番環境にも通用しうる運用性・管理性をもたせる
◇ ただし、データ永続化やmTLSは時間都合により断念
▪ 対象はObservability3本柱であるメトリクス、トレーシング、ロギング
◇ 活用機会や対応するOSSの多さを考慮
12

View Slide

2. IstioのObservability機能調査
13

View Slide

Istioで取得可能なデータの抜粋
▪ Istio公式サイトの情報を整理し、
取得できるデータのマップを作成
▪ HTTPにはサービスレベルの値を含む
重要なメトリクスが多い
▪ TCPは情報が限られる
14
※1 データ量が膨大になる懸念あり。カスタムメトリクスとして適宜フィルタして取得する
※2 istiod: Istio-proxyに制御命令を送付するコントローラ。
メトリクス
サービスレベル
プロキシレベル
HTTP
トレーシング
ロギング
TCP
istio-proxy
istiod
秒間リクエスト数
リクエスト応答時間
リクエストエラー率
データサイズ
コネクション数
プロキシ内部統計※1(リトライ回数など)
istiodの状態※2
トレーシングデータ
アクセスログ

View Slide

Observability基盤の取得対象
▪ プロキシ内部統計情報以外を取得
▪ プロキシ内部統計情報は粒度が細かく、量が多い
15
※1 データ量が膨大になる懸念あり。カスタムメトリクスとして適宜フィルタして取得する
※2 istiod: Istio-proxyに制御命令を送付するコントローラ。
メトリクス
サービスレベル
プロキシレベル
HTTP
トレーシング
ロギング
TCP
istio-proxy
istiod
秒間リクエスト数
リクエスト応答時間
リクエストエラー率
データサイズ
コネクション数
プロキシ内部統計※1(リトライ回数など)
istiodの状態※2
トレーシングデータ
アクセスログ

View Slide

Istioと連携可能な監視系OSSの整理
▪ Istioが連携可能な監視系OSSを関係性含め可視化
▪ Grafanaと連携可能なソフトウェアが多い
16
ダッシュボード有り
ロギング
メトリクス
トレーシング
ダッシュボード
Istio
Logstash
fluentbit
Promtail
Elastic
search
Grafana
Loki
Kibana
Prome
theus
Jaeger
Zipkin
Open
Sensus
Kiali
Istio-proxy
Istiod
Grafana
Grafana
Tempo
トレーシングはDataDogとLightstepとStackDriver
にも対応。OSSではないため省略

View Slide

Observability基盤に用いるOSSの選定
▪ Grafanaをメインのダッシュボードとし、Grafana連携に強みのあるOSSを選定
17
ダッシュボード有り
ロギング
メトリクス
トレーシング
Istio
Logstash
fluentbit
Promtail
Elastic
search
Grafana
Loki
Kibana
Prome
theus
Jaeger
Zipkin
Open
Sensus
Kiali
Istio-proxy
Istiod
Grafana
Grafana
Tempo
トレーシングはDataDogとLightstepとStackDriver
にも対応。OSSではないため省略

View Slide

K8s metrics
Observability基盤の設計
18
Prometheus
Operator
Jaeger
Operator
Kiali
Operator
Grafana
Jaeger
Kiali
Prometheus Sample App(Bookinfo)
Loki
front
app1
db
app2
Istio-pxy
Istio-pxy
Istio-pxy
Istio-pxy
Access log
Container log
Traffic
metrics
Logs
Metrics
Logs
istiod
Traffic
metrics
Istio
Operator
Operator Lifecycle
Manager
Kubernetes
Deploy
manifests
運用者
Browse
dashboards
監視系
Istio
Operator
情報の流れ
App
Grafana
Operator
Promtail
Tracing Data
Tracing Data
Tracing Data

View Slide

3. 監視系OSSとIstioの連携
19

View Slide

解説の流れ
20
監視系
Istio
Operator
情報の流れ
App
K8s metrics
Prometheus
Operator
Jaeger
Operator
Kiali
Operator
Grafana
Jaeger
Kiali
Prometheus Sample App(Bookinfo)
Loki
front
app1
db
app2
Istio-pxy
Istio-pxy
Istio-pxy
Istio-pxy
Access log
Container log
Traffic
metrics
Logs
Metrics
Logs
istiod
Traffic
metrics
Istio
Operator
Operator Lifecycle
Manager
Kubernetes
Deploy
manifests
運用者
Browse
dashboards
Grafana
Operator
Promtail
Tracing Data
Tracing Data
Tracing Data
Loki・
Promtail
p.23
Grafana
p.25
Jaeger
p.24
Prometheus
p.21
構築中のため説明は省略

View Slide

Prometheus との連携 1/2
▪ Prometheusの構成は共有・連携※1のどちらにするか
◇ 運用負荷削減のため、共有構成を採用
21
連携構成
共有構成
Istio
Prometheus
Production
Prometheus
Production
Prometheus
連携,
データ集約
データ収集
データ収集
利点
▪ 集約による負荷の削減
▪ 責任分界点の明確化
▪ 障害影響の局所化
▪ 公式の推奨方法※2
----
懸念点
▪ 構成複雑化
▪ 管理負荷の増加
▪ リソース消費増加
利点
▪ 構成の単純化
▪ 管理工数削減
▪ リソース消費削減
----
懸念点
▪ Prod Prometheus
への負荷集中
▪ 責任分界点の判断
▪ 障害の伝播
※1 名称は独自のもの
※2 Observability Best Practices https://istio.io/latest/docs/ops/best-practices/observability/#using-prometheus-for-production-scale-monitoring

View Slide

Prometheus との連携 2/2
▪ kube-prometheusをベースにPrometheusを構築して省力化
◇ Prometheus-Operatorコミュニティが提供する監視系ツールのパッケージ
◇ 設定済みPrometheusやGrafana、Alert Managerを構築できる
▪ 以下2種のデータの取得設定をPrometheusに投入する。
Prometheus Operatorを用いると管理しやすい
◇ Istio-proxy：PodMonitorにて設定
◇ istiod：ServiceMonitorにて設定
◇ 注意：spec.namespaceSeletor.any = true
とすると動作せず。環境依存か
22

View Slide

Loki・Promtail との連携
▪ LokiやPromtailにはOperatorが存在しないため、
HelmやTanka(推奨)にてデプロイ
◇ 今回はHelmを使用し、問題なく動作
▪ Istioは初期状態だとアクセスログを出力しないため、
Istioデプロイ時の設定要
◇ Istio Operatorを用いる場合、
spec.meshConfig.accessLogFile を設定する
◇ Jaeger用設定も含め、本基盤のIstioは
右の設定のみで一通りの動作が可能
# Observability基盤のIstio設定
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istio
spec:
profile: default
meshConfig:
accessLogFile: /dev/stdout
enableTracing: true
defaultConfig:
tracing:
sampling: 1
zipkin:
address:
:9411
Jaeger設定
Loki設定
23

View Slide

Jaegerとの連携
▪ JaegerはOperatorを用いて、容易に本体をデプロイ可能
▪ Istioとの連携方法
◇ Istioデプロイ時の設定でトレーシングデータの送付先を指定
◇ サンプリングレートも設定可能※1 。初期状態は1%
◇ トレーシング設定を反映するにはIstio-proxyの再起動が必要
▪ なお、Isio連携以外にアプリ側でトレースIDの伝播を行う必要あり※2
◇ Istio-proxyではリクエストの対応関係を判断できないため
◇ トレーススパン生成やJaegerへのデータ送付はIstio-proxyが実施
24
※2 Trace-Context Propagation ↓
https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation
※1 Podの proxy.istio.io/config アノテーションでも指定可能。Pod単位で異なる値を設定できる

View Slide

Grafana との連携
▪ Grafanaは前述のkube-prometheusでも導入できるが、
Grafana Operatorが有用であるため、Operator経由で導入すると良い
◇ 一方、kube-prometheusはダッシュボード群が作り込まれている。適宜移植する
▪ 各監視ツールとの連携
◇ GrafanaDataSourceリソースにてPromtheus、Loki、Jaegerと連携
◇ GrafanaDashboardリソースにてIstio公式ダッシュボード追加（5+1種）※1、2
▪ GrafanaDashboardはPluginの取得やDataSource連携を宣言的に指定できる
◇ GUIからの直接編集はGrafanaコンテナの再起動で消えるため注意
25
※1 https://istio.io/latest/docs/ops/integrations/grafana/ … 公式に提示されている5種のダッシュボード
※2 https://grafana.com/grafana/dashboards/13277 ... GrafanaサイトのIstioリポジトリにはWASM用のダッシュボードも存在

View Slide

Observability環境の稼働
▪ Observability基盤を稼働させ、実際にリクエストの応答時間やエラー率など、
サービスレベルに関するデータを取得できることを確認
▪ 多少の試行錯誤は必要だったものの、Istioや監視系OSSの公式Docsで情報が完結
26
メトリクス
ロギングトレーシング
スループットエラー率応答時間

View Slide

4. 構築や運用を通したTips
27

View Slide

構成をシンプルに保つ
Observabilityもスモールスタートに
▪ 最初はメトリクスだけで良い。最初から色々あっても使いこなせない
▪ その後、ロギング→トレーシング。トレーシングは必要性を感じてからの導入で良い
▪ プロキシ内部統計のような細かいデータも同上。メリットと運用負荷を比較する
Istioと監視系OSSの分離
▪ システムの複雑化を避けるため、監視系OSSはIstioのメッシュ外に置く
▪ Istioの障害に監視系OSSが巻き込まれると原因分析もできない
▪ mTLS配下でも監視系OSSを分離できるかは要検証
ダッシュボードの集約
▪ 一つのGUIでメトリクス、ロギング、トレーシングすべてに対応できるのは大きなメリット
28

View Slide

構成管理
複数のOSS・Operatorを扱うと、どうしても構成は複雑化。一貫性のある管理を行う
ファイルべースの宣言的な構成管理（ Single Source of Truth ）
▪ 各種構成をKubernetesマニフェストの状態でGit管理する → 再現性・操作の一貫性向上
▪ PrometheusやGrafanaのOperatorはこの管理方法と相性が良い
▪ GrafanaのGUIの操作や、kubectl operatorなどのCLI操作で構成を変更すると
ファイル管理の一貫性が崩れる。変更内容をマニフェストに反映し、状態を追えるようにする
管理方法の管理
▪ OSSごとにHelm、Operator、OLM、CLI、GUIと管理方法が異なる
▪ マニフェストの作成方法をスクリプトやドキュメントで管理要
29

View Slide

Istio導入の検討
▪ Istioは大きなシステム。簡単に抜き差しできるものではない
▪ 利点が懸念点を上回るか、自分にユースケース※1 は当てはまるか、
30
▪ アプリ改修なしに、システム全体へ
一貫性のあるポリシーを適用
▪ 多くの機能、高い品質
◇ サービスレベル監視
◇ 動的な通信制御
◇ 通信暗号化や認証認可
◇ VM連携
▪ 活発な開発、etc.
▪ Service Meshレイヤー追加
によるシステム複雑化
▪ 多数の機能に対する学習コスト
▪ Istio本体の管理コスト
▪ 消費リソースの増加
▪ 2-10msの通信遅延
▪ Kubernetesへのロックイン
▪ 3~6ヶ月単位のアップデート、etc.
※1 便利なユースケース集
▪ Megan O’Keefe, “Istio by Example!”, https://www.istiobyexample.dev/ , 日本語版(少々古い) https://istiobyexample-ja.github.io/istiobyexample/
▪ Istio公式ドキュメント(Tasks), https://istio.io/latest/docs/tasks/
利点懸念点

View Slide

5. まとめ
31

View Slide

まとめ
Observabilityとは「システムが出力したデータを活用し、
システム内部で何が・何故起きているのか理解できること」
▪ 未知の現象に対処するため
Istioと監視系OSSを組み合わせ、アプリから透過的に
サービスレベルを監視する基盤を構築
▪ Prometheus、Jaeger、Loki、Grafana を連携
構築および運用から得た知見
▪ 構成をシンプルに保つこと、構成管理を行うこと
▪ Istioは利点と懸念点の両方を鑑みて導入を判断すること
32

View Slide

今後の展望
▪ Observabilityの実践
◇ 安定性や利便性の向上、運用を通した課題の抽出
◇ ある程度使えるものになれば社外公開したい
▪ mTLS対応の検証
◇ 監視データを取得する際の証明書の設定・管理方法を整理する
▪ データ永続化対応
◇ PV適用方法の整理や、監視データのディスク消費量を検証
▪ 環境に応じた取得メトリクスの自動調整
◇ 次ページ
33

View Slide

環境に応じた取得メトリクスの自動変換
▪ 同じ意味のメトリクスでも、環境が変わると算出方法や取得方法が異なりうる
◇ 例. CPU使用率が一方は 100% 換算、他方は (コア数)*100% 換算
◇ 例. クラウドだと基盤機能で取得可能なメトリクスが、オンプレだと取得できない
▪ 個々のメトリクスを抽象的にマッピングさせ、複数環境への移植性を向上させる
34
On Premise
Cloud A
App
基盤監視機能
App
Side
Car
式構成
Cloud A $val*$cores -
On Premise $val add $sidecar
デプロイ
変換処理
$val * $cores $val
DB
CPU Usage 変換マップ
メトリクス変換機
運用者
CPU使用率
800%
300%
50%
CPU使用率
300%
CPU使用率
vCPUx16

View Slide

参考文献
▪ John Porcaro, “Observability (re)defined”, https://www.humio.com/whats-new/blog/observability-redefined, 2019
▪ Betsy Beyer, Chris Jones, Niall Richard Murphy, Jennifer Petoff, “Site Reliability Engineering”, O'Reilly Media, Inc., 2017
▪ Mike Julian, 松浦隼人, “入門監視 ―モダンなモニタリングのためのデザインパターン”, O'Reilly Media, Inc., 2019
▪ Cindy Sridharan, “Distributed Systems Observability”, O'Reilly Media, Inc., 2018
▪ Charity Majors, Liz Fong-Jones, George Miranda, “Observability Engineering”, O'Reilly Media, Inc., 2022(Early Release)
▪ Cindy Sridharan, “Monitoring in the time of Cloud Native”, https://copyconstruct.medium.com/monitoring-in-the-time-of-
cloud-native-c87c7a5bfa3e, 2017
▪ “Istio”, https://istio.io/latest/, Istio Authors, 2021
▪ Megan O’Keefe, “Istio by Example!”, https://www.istiobyexample.dev/, 2021
▪ “kube-prometheus”, https://github.com/prometheus-operator/kube-prometheus, prometheus-operator, 2021
▪ “grafana-operator”, https://github.com/integr8ly/grafana-operator, integr8ly, 2021
▪ “Tempo Documentation”, https://grafana.com/docs/tempo/latest/, Grafana Labs, 2021
▪ “jaeger-operator”, https://github.com/jaegertracing/jaeger-operator, jaegertracing, 2021
▪ “Installation Guide”, https://kiali.io/documentation/latest/installation-guide/, Kiali, 2021
▪ “operator-lifecycle-manager”, https://github.com/operator-framework/operator-lifecycle-manager, operator-framework, 2021
▪ Benjamin H. Sigelman, etc., “Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”, Google Technical Report (2010)
35

View Slide

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

View Slide

Appendix

View Slide

Observabilityの側面
38
▪ Observabilityの目的は「未知の現象に対応すること」こと
▪ 目的を達成するには、データを集める以外の側面もある
データから洞察を得られるようにする
Data Mining、Profiling、
Dependency Analyzing
未知の現象のとり得る範囲を狭める
System Design、Testing
Chaos Engineering
必要なデータを得られるようにする
Monitoring、Tracing、Logging
システム
未知の
現象
データ
洞察
対応

View Slide

Istio-proxyのObservabilityデータ出力仕様
39
▪ メトリクスはPull型、トレース情報はPush型、ログはNode経由で送付
▪ PrometheusはIstio-proxyの宛先情報が必要、Istio-proxyはJaegerの宛先情報が必要
Node
Kubernetes Cluster
Promtail
コンテナログ
Prome
theus Istio-proxy
アプリ
Jaeger
標準出力
Push
Pull

View Slide

Classifying Metrics Based on Request or Response
▪ Istio-1.8で追加された機能。URLやHTTP Headerの情報を加工し、監視データに付与
▪ 監視データの解像度を大きく向上（L4 → L7）できるため、非常に強力。
例えば、Webページ単位やユーザ別、アクセス元ブラウザごとのエラー率を算出できる
▪ Web Assembly(WASM)を用いて実装されたプラグインの公式実装としても要注目
40
Front
Service
1. 属性生成プラグイン
(WASM)をデプロイ
Prometheus
Request
Response
Original Info
Metrics
2. 分類ルール
を設定
ユーザ
3. メトリクスの
動的分類
通信
ルールに基づきメトリク
スに情報を付与
4. メトリクス保存

View Slide

Google
トレーシング規格に関わる国際動向
41
OpenTracing
OpenCensus
OpenTelemetry
W3C Distributed
Tracing WG
規格詳細化
CNCF
W3C
Dapper
Zipkin
Jaeger
Google社の分散トレーシ
ングシステムの設計をまと
めた論文
Dynatrace
2010年
Googleの分散トレーシン
グライブラリ（モニタリング
もサポート）
分散トレーシング仕様の標
準化（データ細部は除く）
2016年 2019年
OpenCensus と OpenTracing
の統合仕様およびライブラリ群
種々の製品/OSSが乱立
標準化
派生
統合
統合
2020年
トレーシングデータ構造の細部を
OpenTelemetryベースに標準化
ベース仕様標準化

View Slide

View Slide

Istioを活用したObservability基盤の構築と運用 / Constructing and operating the observability platform using Istio

Istioを活用したObservability基盤の構築と運用 / Constructing and operating the observability platform using Istio

id

More Decks by id

Other Decks in Technology

Featured

Transcript