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

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

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

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

オブザーバビリティとは

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

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

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

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

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

（参考）オブザーバビリティ成熟度モデルオブザーバビリティが⾼い状況の定義は多種多様 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

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

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

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

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

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

1年前のBill Oneの状況

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

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

何が起きたか

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

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

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

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

理想的なデバッグ

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

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

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

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

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

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

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

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

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

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

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

- インシデント時にサービスマップなどで全体を俯瞰した上でドリルダウンしながら原因を特定できる仕組みが必要 - 今回は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.

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

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

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

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

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

SansanTech
PRO

More Decks by SansanTech

Other Decks in Technology

Featured

Transcript