勘に頼らず原因を⾒つけるためのオブザーバビリティ

by SansanTech

Slide 1

Slide 1 text

勘に頼らず原因を⾒つけるためのオブザーバビリティ Sansan株式会社 Bill One Engineering Unit SREチーム上司陽平

Slide 2

Slide 2 text

⾃⼰紹介上司陽平 Sansan株式会社 @paper2parasol - Sansan株式会社でBill OneプロダクトのSREチームに2022年8⽉から所属 - 前職はSIer企業でコンテナ技術やSREの普及活動、 AWS・AzureでのKubernetesサービスの設計・構築に従事 - 現職ではSREのミッション定義や信頼性向上の⽂化づくり、オブザーバビリティの向上、負荷試験による性能改善、IaC化などを推進 - 好きなものはラーメンとCloud Run

Slide 3

Slide 3 text

Slide 4

Slide 4 text

アジェンダオブザーバビリティとは１年前のBill Oneの状況理想的なデバッグオブザーバビリティ向上の取り組み

Slide 5

Slide 5 text

オブザーバビリティとは

Slide 6

Slide 6 text

オブザーバビリティとは引⽤：オブザーバビリティ(可観測性)とは？ - Splunk https://www.splunk.com/ja_jp/data-insider/what-is-observability.html システムの出⼒を調査することによって内部の状態を測定する能⼒を指します。

Slide 7

Slide 7 text

オブザーバビリティが⾼い状況とはソフトウェアシステムのどんな状態でも、どんなに斬新で奇妙な問題でもデバッグして正しい原因を素早く⾒つけられる状況ソフトウェアシステムのどんな状態でも、どんなに斬新で奇妙でも、⾼カーディナリティ・⾼ディメンションのテレメトリーデータを任意に切り刻んで必要なビューにすることで理解でき、コア分析ループを使って⽐較しながらデバッグして問題の正しい原因を素早く切り分け、それらのデバッグニーズを事前に定義または予測する必要がなければ、あなたのシステムにはオブザーバビリティがあると⾔えるでしょう。引⽤：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda

Slide 8

Slide 8 text

オブザーバビリティが⾼くない状況とは？？？

Slide 9

Slide 9 text

勘と経験に頼ったデバッグをしている引⽤：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda 検索機能が遅い？？どーせサービスBのDBやろ！！ Service B Service A 真因 DB DB 直感や勘を⼤切にするリアクティブなモニタリングベースのアプローチは、確証バイアスによって問題の本当の原因を⾒えなくしてしまう傾向があります。

Slide 10

Slide 10 text

⻑く在籍するベテランエンジニアがチームの最⾼のデバッカー引⽤：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda チームにもっとも⻑く在籍しているエンジニアが、チーム最⾼のデバッガーであり、最後の砦のデバッガーとなることが多いのです。...逆に、オブザーバビリティを実践しているチームは、根本的に違う⽅向に傾きます。オブザーバビリティツールでは、チーム内の最⾼のデバッガーは、通常、もっとも好奇⼼の強いエンジニアです。

Slide 11

Slide 11 text

（参考）オブザーバビリティ成熟度モデルオブザーバビリティが⾼い状況の定義は多種多様 New Relic https://docs.newrelic.com/docs/new-relic-solutions/observability- maturity/introduction Honycomb https://www.honeycomb.io/framework-for-an-observability-maturity-model-using- observability-to-advance-your-engineering-product

Slide 12

Slide 12 text

引⽤：Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md オブザーバビリティを⽀えるPrimary Signals

Slide 13

Slide 13 text

- システムやアプリケーションの動作を定量的に理解するための数値データ - 根本原因を特定するために必要なハイレベルな概要のみを⽰すことが多く、必ずしも根本原因を明らかにするわけではないメトリクス Metrics Traces Logs メトリクスの種類例システム CPU 使⽤率、メモリ使⽤率、ディスク使⽤率...etc. アプリケーションレスポンス時間、エラーレート、スループット（リクエスト/秒）...etc. ビジネス DAU、コンバージョン率、チャーン率...etc.

Slide 14

Slide 14 text

- システムやアプリケーションが⽣成するテキストのストリーム - 情報、警告、エラーメッセージなどシステムの動作に関する詳細な情報を時刻とともに提供 - 根本原因を特定する情報が含まれる可能性が⾼いがトレースに紐付けない場合情報量が多いログ Metrics Traces Logs

Slide 15

Slide 15 text

- 複数のサービスコンポーネントにまたがるリクエストの処理フローを追跡するためのデータ - 特定のリクエストがシステムを通過する流れを可視化し、パフォーマンスの問題やエラーの原因を特定するのに役⽴つ - 複雑なシステムやマイクロサービスアーキテクチャでの問題解決に特に有⽤トレース Metrics Traces Logs

Slide 16

Slide 16 text

⽤語説明：トレース、スパン引⽤：Jaeger documentation https://www.jaegertracing.io/docs/1.8/architecture/#span ⽤語説明スパンスパンは分散トレーシングの基本単位で、処理の開始と終了時刻を含む。⼦スパンを持ち、処理の階層を表すことができる。トレーストレースは複数のスパンから成り、⼀つのトランザクションを表す。リクエストの経路や時間、問題点を把握できる。

Slide 17

Slide 17 text

1年前のBill Oneの状況

Slide 18

Slide 18 text

1年前のBill Oneのオブザーバビリティ Metrics Traces Logs 活⽤の余地あり！！ - GCPがデフォルト提供するメトリクスが基本 - ⼀部の重要箇所でカスタムメトリクスを作成 - GCPがデフォルト提供するログとアプリケーションログが基本 - 各ログはトレースのIDに紐付けており、フィルタが可能 - ログから⼀部メトリクスの作成なども実施

Slide 19

Slide 19 text

各スパンのレイテンシ → リクエストの開始と終了時刻を計算すればわかる... 各サービスをまたぐリクエストの流れ → トレースのIDで絞ったログを⼼眼で⾒ればわかる... 各APIエンドポイントごとのレイテンシーの統計値 → BigQueryで集計すればわかる... 特定タイミングでのシステム全体の状況 → 考えるな！感じろ！トレースと同等の情報ログから抽出して気合いでなんとかしてた LBを通って... これはBFFのログだからこの辺でBFFを通って... これはサービスAのログだからサービスAを通って... 各サービスをまたぐリクエストの流れを⼼眼で⾒る時のイメージ

Slide 20

Slide 20 text

何が起きたか

Slide 21

Slide 21 text

複雑な問題はベテランにしかデバッグができないログ分析ツールを使いこなし、システム全体の挙動を容易にイメージできるベテランだけが即時にデバッグができる状況に...

Slide 22

Slide 22 text

- ログをトレースでフィルタできれば⼤抵の問題は誰でもデバッグできた - 複雑な問題も少なかったのでベテランがデバッグをすればなんとかなったただ、しばらくは意外と困らなかったサービス規模が⼤きくなり、性能などの複雑な問題の発⽣頻度が増え始め、ベテランに頼らないデバッグの必要性が⾼まった

Slide 23

Slide 23 text

改めて複雑なシステムにおける理想的なデバッグを考えてみる

Slide 24

Slide 24 text

（参考）Bill Oneのアーキテクチャ概要図 Backend Service B Backend Service A BFF (backend for frontend) Backend Service Z ‧‧‧ 処理量が多いBFFや機能が多い主要サービス Aの問題が起きやすい傾向がある。 DB DB DB

Slide 25

Slide 25 text

理想的なデバッグ

Slide 26

Slide 26 text

理想的なデバッグ：ドリルダウン探索原因が潜む範囲を狭めつつ、全体から細部へドリルダウンを繰り返しながら的確に原因を特定していくドリルダウン探索勘と経験に頼った探索原因

Slide 27

Slide 27 text

具体例：ドリルダウン探索サービスマップからレイテンシが悪化しているサービスBを特定サービス全体のレイテンシが悪化しアラートサービスBのトレースを複数確認し、⼀部のトレースでDBのレイテンシが⾼いことを発⾒サービスBのDBのパフォーマンダッシュボードを確認し、原因となるクエリを特定

Slide 28

Slide 28 text

具体例：ドリルダウン探索 ※ スクリーンショットはイメージです。サービスBのトレースを複数確認し、⼀部のトレースでDBのレイテンシが⾼いことを発⾒サービスBのDBのパフォーマンダッシュボードを確認し、原因となるクエリを特定サービスマップからレイテンシが悪化しているサービスBを特定サービス全体のレイテンシが悪化しアラート

Slide 29

Slide 29 text

具体例：ドリルダウン探索サービスマップからレイテンシが悪化しているサービスBを特定サービス全体のレイテンシが悪化しアラートサービスBのトレースを複数確認し、⼀部のトレースでDBのレイテンシが⾼いことを発⾒サービスBのDBのパフォーマンダッシュボードを確認し、原因となるクエリを特定 ※ スクリーンショットはイメージです。

Slide 30

Slide 30 text

Slide 31

Slide 31 text

具体例：勘と経験に頼った探索どーせ、よく問題が起こる主要サービスAのDB やろ！！.....違った！！じゃあ遅くなっている機能的にサービスBのDB かもな...！！勘と経験に頼った探索サービスBのDBのパフォーマンダッシュボードを確認し、原因となるクエリを特定サービス全体のレイテンシが悪化しアラート

Slide 32

Slide 32 text

実際のところ熟練者の経験と勘による探索はとても頼りになる

Slide 33

Slide 33 text

じゃあ、何が問題になる...？

Slide 34

Slide 34 text

- システムに対する豊富な知識と経験があるベテランでないと複雑な問題のデバッグが困難 - 複合要因を⾒逃すことがある - 勘による思い込みで調査が難航する場合がある勘と経験に頼った探索の問題点

Slide 35

Slide 35 text

複合要因を⾒逃すことがあるドリルダウン探索勘と経験に頼った探索 DBのクエリが遅くなっていたのは⼀部のトレースだけだった...何故全体のレイテンシが上がった？？ DBクエリが悪かった！頑張って直そうな！！もしかしてアプリケーション側にも問題が？？ DBクエリのタイムアウトが⻑く、既にユーザが諦めているクエリでコネクションプールが占有されていた。取得待ちが⻑くなりそれがさらに影響を⼤きくしていたことが判明。 DBクエリのタイムアウトを改善。

Slide 36

Slide 36 text

勘による思い込みで調査が難航する場合があるドリルダウン探索勘と経験に頼った探索サービス全体のレイテンシが悪化しアラート BFFのレイテンシが⾼くなっていてサービスA のエラー率も上がっている！！レイテンシが⾼い期間の⼀部でしかサービスAのエラー率が上がっていないので別問題として調査しよう BFFの共通処理で原因を発⾒！！全体が遅くなる系はサービスCだな。あれ違った。じゃあ主要サービスAかな。お、エラーでてんじゃん。これや、これや。うーん⼀時的なものにも⾒える。。でもエラー率上がっているからこれだと思うんだよな〜。DBの⽅も⾒てみるか.... サービス全体のレイテンシが悪化しアラート

Slide 37

Slide 37 text

オブザーバビリティ向上の取り組み

Slide 38

Slide 38 text

- インシデント時にサービスマップなどで全体を俯瞰した上でドリルダウンしながら原因を特定できる仕組みが必要 - 今回はAPM製品により解決する⽅針とした - OpenTelemetryとの親和性やコストなどを含め総合的に判断して Splunk®を採⽤オブザーバビリティを向上するための⽅針 Splunk, Splunk>, and Turn Data Into Doing are trademarks or registered trademarks of Splunk Inc. in the United States and other countries. All other brand names, product names, or trademarks belong to their respective owners. © 2023 Splunk Inc. All rights reserved.

Slide 39

Slide 39 text

- APM製品の⽐較・選定 - Google Cloudのコンテナサービス（Cloud Run）特有の仕様に合わせたトレースコンテキストの伝搬を実装 - バックエンドサービス（Kotlin/JVM）の計装 - BFF（Node.js）の計装 - Spanにカスタム属性を追加 - 顧客ごとのID - ユーザごとのID - コンテナのID...etc. 具体的にしたこと

Slide 40

Slide 40 text

- ドリルダウン探索が可能となり問題の特定が早くなった - 誰でも経験と勘に頼らないデバッグができる仕組みが整った - APMベンダの社外のエンジニアがインシデント時のAPMのデータだけを利⽤して性能問題の原因に辿り着けた - 複合要因を的確に捉え、改善に繋げることができた効果 Metrics Traces Logs Metrics Traces Logs

Slide 41

Slide 41 text

- 多くの開発者がデバッグにAPMを利⽤してドリルダウン探索をしていけるように布教していく - 基本的なAPMの使い⽅の勉強会を実施 - 実環境でのドリルダウン探索のデモやハンズオン - システムに合わせてスパンに付与するカスタム属性を検討 - ⼀部対応できていないサービスの計装 - Pub/Subの計装 - 組織内での活⽤例の探索・事例化・横展開...etc 今後やりたいこと