1.
実践Observability
株式会社ユーザベース 阿南 肇史
1

2.
阿南 肇史 (Anan Toshifumi)
仕事：SPEEDA の SRE 担当
好き：GCP / Istio / Aerospike
Twitter：@toshanan
自己紹介
2

3.
z
社名：株式会社ユーザベース / Uzabase, Inc.
創業：2008年4月1日
本社所在地：東京都港区六本木 7-7-7 TRI-SEVEN ROPPONGI 13F
事業内容：企業活動の意思決定を支える情報インフラの提供
上場市場：東証マザーズ（ 3966）
COMPANY OVERVIEW
提供サービス：
経済情報
プラットフォーム
ソーシャル
経済メディア
スタートアップ情報
プラットフォーム
B2Bマーケティング
プラットフォーム
米クオリティ
経済メディア
サブスクリプションビ
ジネスに特化した
テーマ型ファンド
3

4.
Contents
01 What is Observability?
02 SPEEDA Architecture
03 Use cases at SPEEDA
4

5.
What is Observability?
可観測性
5

6.
6
● システムの内部状態を観測できる状態にあること
● Monitoringはシステムの状態を評価すること
○ Observabilityを高めることによってより良い
Monitoringができる
What is Observability?

7.
● 様々なパターンのエラー
○ 数パーセントのリクエストだけ500エラー or レスポンスが遅延
○ 関連するリソースの数が多いので、原因の特定が難しい
● システムの全体像が把握しづらい
○ そもそもどのサービスを経由しているのか
○ 思わぬリソースにアクセスしていることもある
7
分散システムにとってObservabilityは重要
What is Observability?

8.
The Three Pillars of Observability
8
Traces / Metrics / Logs
What is Observability?

9.
● Monitoring / Logging / Tracingそれぞれに
多数のOpenSourceやマネージドサービス
が存在
https://landscape.cncf.io/
9
What is Observability?

10.
◎ Logs
● 主な形式は３つ
○ Plain Text
○ Structured (json ...)
○ Binary (Protocol Buffers ...)
10
特定の時間に発生した個別のイベントを記録するレコード
What is Observability?

11.
◎ Metrics
● AlertingやDashboardの構築に利用
● データ量はおおよそ一定に増加
○ ユーザーのアクセス増加等と関連が薄い
● 下記のようなタイミングで増える
○ 新しいサービスが追加された
○ コンテナが増加した
11
一定間隔で計測されたデータの数値
What is Observability?

12.
End to Endのリクエストフローを表現する（Distributed Tracing）
◎ Traces
12
● 最初のリクエストでユニークなRequestIDを発行し、それを次のホップ
に渡していく
● ServiceMeshの場合、アプリケーションはヘッダーをメッシュ内の次の
ホップに転送する
○ backendへのデータ送信はsidecarで実施
What is Observability?

13.
一意のRequestIdを引き継いでいくことにより、各システムをTrace
13
https://istio.io/docs/tasks/observability/distributed-tracing/jaeger/
What is Observability?

14.
14
実装コスト 小 実装コスト 大
Logs Metrics Traces
単一システム向き 分散システム向き
LogsMetrics Traces
個別リクエスト向き 全リクエスト向き
Metrics
データ量 小 データ量 大
LogsMetrics Traces
Traces Logs
環境によって異なるが、上記のような傾向がある
What is Observability?

15.
15
What is Observability?
重要なのは Traces / Metrics / Logs だけではない
テストの観点も重要

16.
16
● テストもObservabilityの一部
● ProductionにDeployするまでがテストではない
○ Testing in Production
What is Observability?
◎ Testing

17.
17
Production Release後もテストが続く
What is Observability?
Development Deploy Release Post-Release
・Unit Test
・E2E Test
・Manual Test
・
・
・
Testing in Production
・Canary Release
・Traffic Shifting
・A/B Tests
・Monitoring
・Chaos Engineering
・
・
・
Testing in
Develop / Staging

18.
18
What is Observability?
Observabilityをどう実現する？

19.
SPEEDA Architecture
19
SPEEDAのアーキテクチャー

20.
-7-
多様なニーズを持った
多様な顧客
多くの
データサプライヤー
600 万社を超える
超巨大な企業 DB
20

21.
SPEEDA Architecture
CDNCDN
Load
Balancer
AP
tomcat
CDNCDN
RDB
MySQL
FileServer
Data
ES
on-premise # GOOD
● シンプルな構成
# BAD
● 小さな改修でも全体に影響
● 開発スピードが落ちてくる
● デプロイに時間がかかる（ようになってきた）
21
SPEEDAの歴史

22.
Load
Balancer
Monolith AP
tomcat
# GOOD
● 機能別に開発可能
● リリース時の影響範囲が小さくなる
# BAD
● 多数のVM構築（インフラへの依頼増加）
● リソース効率が悪い
● LBのRoutingが複雑に
Internal LB
Microservice with VMs
22
SPEEDA Architecture
on-premise

23.
Load
Balancer
Monolith AP
tomcat
Microservice with k8s
(Rancher)
Ingress
# GOOD
● インフラ構築の負担が減る
● 基本的なMetricsはDiscoveryして収集
# BAD
● Blue/Green切替は上位のLoad Balancerで実施
● リクエストの流れが把握しづらい
23
SPEEDA Architecture
on-premise

24.
Load
Balancer
Monolith AP
tomcat
istio-
ingressgateway
istio-
ingressgateway
on-premise GCP
Microservice with k8s + Istio
# GOOD
● IstioでTraffic Routing
● Deploy Pipelineがシンプルに
● Observabilityが向上
# BAD
● 導入コストはかかる
● ProxyをInjectionすることによるトラ
ブル
● 通信自体はより複雑に
24
SPEEDA Architecture

25.
Data Plane
25
app
istio-proxy
app
istio-proxy
app
istio-proxy
Control Plane
Management Plane
Mixer
adapter
adapter
● 全リクエストがistio-proxyを経由
● istio-proxyからreportsをMixerに送信
● Mixerで集約し、backendに送信
SPEEDA Architecture

26.
Use cases at SPEEDA
26
SPEEDAでのユースケース

27.
例えば
27
Use cases at SPEEDA

28.
28
Use cases at SPEEDA
● リクエストの全体像を把握したい
● どこで問題が発生しているか確認したい
● 外部APIへのアクセスもトレースしたい
● 過去のイベントログを集約して見たい
● 特定のユーザーのみアクセスが遅い or エラー

29.
● リクエストの全体像を把握したい
● どこで問題が発生しているか確認したい
● 外部APIへのアクセスもトレースしたい
● 過去のイベントログを集約して見たい
● 特定のユーザーのみアクセスが遅い or エラー
29
Use cases at SPEEDA

30.
30
画面表示が遅い場合、どこを確認する？
● CPU/Memoryが不足していないか
● データ量が多くなっている
● DBの負荷が高い
Use cases at SPEEDA

31.
31
画面表示が遅い場合、どこを確認する？
１画面で複数のAPIと通信している場合
関連がわかりずらい
Use cases at SPEEDA
● CPU/Memoryが不足していないか
● データ量が多くなっている
● DBの負荷が高い

32.
32
Use cases at SPEEDA
リソースだけ見ても、原因特定は難しい

33.
33
Use cases at SPEEDA

34.
34
Use cases at SPEEDA
Service
Deployment

35.
35
Use cases at SPEEDA
レスポンスエラーが発生している箇所が可視化される

36.
● リクエストの全体像を把握したい
● どこで問題が発生しているか確認したい
● 外部APIへのアクセスもトレースしたい
● 過去のイベントログを集約して見たい
● 特定のユーザーのみアクセスが遅い or エラー
36
Use cases at SPEEDA

37.
37
istio-
ingressgateway
Kubernetes Cluster
app
istio-proxy
SaaS Endpoint
Private Endpoint
● istio-proxy(envoy) 経由で外部へ通信
● クラスター外の通信をtrace
○ SaaSのEndpoint
○ Kubernetesに乗っていないAPI
○ Databaseへの通信
クラスター外の通信もトレースできる？
Use cases at SPEEDA

38.
38
● Service Entryを登録しておくことで、外部
エンドポイントも表示される
● Service Entryを登録していない場合は、
PassthroughCluster(Unknown) になる
Use cases at SPEEDA
www.googleapis.com
PassthroughCluster
www.googleapis.com
www.googleapis.com

39.
39
● リクエストの全体像を把握したい
● どこで問題が発生しているか確認したい
● 外部APIへのアクセスもトレースしたい
● 過去のイベントログを集約して見たい
● 特定のユーザーのみアクセスが遅い or エラー
Use cases at SPEEDA

40.
Kubernetes
Engine Stackdriver
Logging
BigQuery
40
Log Upload Log Export（永続化）
Use cases at SPEEDA

41.
Kubernetes
Engine Stackdriver
Logging
BigQuery
41
Log Upload Log Export（永続化）
Use cases at SPEEDA

42.
Containerで標準出力（JSON形式）
kubectl logs ...
Node上のファイル（log/stream/time の JSON形式）
各Nodeの /var/log/containers/[pod_name]-[namespace]-[container_name]-[container_id].log に出力
42
Use cases at SPEEDA

43.
● pathに/var/log/containers/*.log を指定
● formatでjsonをparseする
○ streamにはstdout or stderr
○ logにはコンテナで出力した
ログが入る
43
Use cases at SPEEDA

44.
Kubernetes
Engine Stackdriver
Logging
BigQuery
44
Log Upload Log Export（永続化）
Use cases at SPEEDA

45.
45
Use cases at SPEEDA
example.com

46.
Kubernetes
Engine Stackdriver
Logging
BigQuery
46
Log Upload Log Export（永続化）
Use cases at SPEEDA

47.
47
● terraformで「StackdriverのログをGCPにExportする」リ
ソースを定義
● エクスポートは日次で実施
● logName/日付ごとにテーブルが作成される
Use cases at SPEEDA

48.
48
Use cases at SPEEDA
● 日付ごとにテーブルが分けられる
● jsonPayloadの各項目を別々の
フィールドに入れてくれる

49.
49
/v1/reports/100
/v1/search
/v1/news/101
● pathごとのレスポンスタイムを確認
○ 最大/最小/平均
○ パーセンタイル
Use cases at SPEEDA

50.
GCP
Stackdriver
GKE #1 GKE #2 GKE #3
オンプレミス
k8s #1 k8s #2 k8s #3
GCE
fluentd-uploader
● GCP 公式の fluentd Plugin を改修し
オンプレミスのクラスタ対応を実施
50
Use cases at SPEEDA

51.
GCP
Stackdriver
GKE #1 GKE #2 GKE #3
オンプレミス
k8s #1 k8s #2 k8s #3
GCE
fluentd-uploader
● filterで "onpre_k8s_cluster" を追加
51
Use cases at SPEEDA

52.
GCP
Stackdriver
GKE #1 GKE #2 GKE #3
オンプレミス
k8s #1 k8s #2 k8s #3
GCE
fluentd-uploader
● オプションを付与することでオンプレ用の
タグを付与して Stackdriver に保存
52
Use cases at SPEEDA

53.
● Stackdriver の画面からオンプレの cluster のログが閲覧可能に
53
Use cases at SPEEDA
on-pre-k8s01
on-pre-k8s02
gke01
gke02

54.
54
● リクエストの全体像を把握したい
● どこで問題が発生しているか確認したい
● 外部APIへのアクセスもトレースしたい
● 過去のイベントログを集約して見たい
● 特定のユーザーのみアクセスが遅い or エラー
Use cases at SPEEDA

55.
istio-proxy
api-gateway pod
● api-gateway(kong)を経由して各APIにアク
セス
● api-gatewayで認証を実施
● fluentd-agentをサイドカーで起動し、 json
形式のログを出力
kong
istio-proxy
api pod
foo-api
55
Use cases at SPEEDA
API GatewayでのLogging

56.
56
● api-gatewayでユーザーに関するログ
を出力
● ユーザーとrequest_idを紐付ける
● 特定ユーザーのリクエストをTrace
できる
Use cases at SPEEDA

57.
57
Conclusion
● 分散システムにおいてObservabilityは重要
○ 問題発生後、スムーズに調査できる
○ 問題が顕在化する前に対応できる
● 実践しながら、理論に立ち返ると理解が進む
※全て完璧に出来ている訳ではないので日々updateしています...

58.
58
Thank You