実践Observability

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

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

45. 45 Use cases at SPEEDA example.com

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 ﬂuentd-uploader ● GCP 公式の ﬂuentd Plugin を改修しオンプレミスのクラスタ対応を実施 50 Use cases at SPEEDA

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

52. GCP Stackdriver GKE #1 GKE #2 GKE #3 オンプレミス k8s #1 k8s #2 k8s #3 GCE ﬂuentd-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で認証を実施 ● ﬂuentd-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

実践Observability

You are reading a preview.

実践Observability

More Related Content

Similar to 実践Observability

Featured

Related Books

Related Audiobooks