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

■イベント
SRE NEXT 2023 IN TOKYO
https://sre-next.dev/2023/

■登壇概要
タイトル：勘に頼らず原因を⾒つけるためのオブザーバビリティ
登壇者：技術本部 Bill One Engineering Unit SREチーム 上司陽平

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. 勘に頼らず原因を⾒つけるための オブザーバビリティ Sansan株式会社 Bill One Engineering Unit SREチーム 上司陽平
2. ⾃⼰紹介 上司陽平 Sansan株式会社 @paper2parasol - Sansan株式会社でBill OneプロダクトのSREチーム に2022年8⽉から所属 - 前職はSIer企業でコンテナ技術やSREの普及活動、 AWS・AzureでのKubernetesサービスの設計・構 築に従事 - 現職ではSREのミッション定義や信頼性向上の⽂ 化づくり、オブザーバビリティの向上、負荷試験 による性能改善、IaC化などを推進 - 好きなものはラーメンとCloud Run
3. © Sansan, Inc.
4. アジェンダ オブザーバビリティとは １年前のBill Oneの状況 理想的なデバッグ オブザーバビリティ向上の取り組み
5. オブザーバビリティとは
6. オブザーバビリティとは 引⽤：オブザーバビリティ(可観測性)とは？ - Splunk https://www.splunk.com/ja_jp/data-insider/what-is-observability.html システムの出⼒を調査することによって 内部の状態を測定する能⼒を指します。
7. オブザーバビリティが⾼い状況とは ソフトウェアシステムのどんな状態でも、どんなに斬新で奇妙 な問題でもデバッグして正しい原因を素早く⾒つけられる状況 ソフトウェアシステムのどんな状態でも、どんなに斬新で 奇妙でも、⾼カーディナリティ・⾼ディメンションのテレ メトリーデータを任意に切り刻んで必要なビューにするこ とで理解でき、コア分析ループを使って⽐較しながらデバ ッグして問題の正しい原因を素早く切り分け、それらのデ バッグニーズを事前に定義または予測する必要がなければ、 あなたのシステムにはオブザーバビリティがあると⾔える でしょう。 引⽤：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda
8. オブザーバビリティが ⾼くない状況とは？？？
9. 勘と経験に頼ったデバッグをしている 引⽤：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda 検索機能が遅い？？ どーせサービスBのDBやろ！！ Service B Service A 真因 DB DB 直感や勘を⼤切にするリアクティブなモニタリングベースのアプローチは、 確証バイアスによって問題の本当の原因を⾒えなくしてしまう傾向があります。
10. ⻑く在籍するベテランエンジニアが チームの最⾼のデバッカー 引⽤：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda チームにもっとも⻑く在籍しているエンジニアが、チーム最⾼のデバッガーであり、 最後の砦のデバッガーとなることが多いのです。...逆に、オブザーバビリティを実践 しているチームは、根本的に違う⽅向に傾きます。オブザーバビリティツールでは、 チーム内の最⾼のデバッガーは、通常、もっとも好奇⼼の強いエンジニアです。
11. （参考）オブザーバビリティ成熟度モデル オブザーバビリティが⾼い状況の定義は多種多様 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
12. 引⽤：Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md オブザーバビリティを⽀えるPrimary Signals
13. - システムやアプリケーションの動作を定量的に理解 するための数値データ - 根本原因を特定するために必要なハイレベルな概要 のみを⽰すことが多く、必ずしも根本原因を明らか にするわけではない メトリクス Metrics Traces Logs メトリクスの種類 例 システム CPU 使⽤率、メモリ使⽤率、ディスク使⽤率...etc. アプリケーション レスポンス時間、エラーレート、スループット （リクエスト/秒）...etc. ビジネス DAU、コンバージョン率、チャーン率...etc.
14. - システムやアプリケーションが⽣成するテキスト のストリーム - 情報、警告、エラーメッセージなどシステムの 動作に関する詳細な情報を時刻とともに提供 - 根本原因を特定する情報が含まれる可能性が⾼い がトレースに紐付けない場合情報量が多い ログ Metrics Traces Logs
15. - 複数のサービスコンポーネントにまたがる リクエストの処理フローを追跡するための データ - 特定のリクエストがシステムを通過する流れを 可視化し、パフォーマンスの問題やエラーの原 因を特定するのに役⽴つ - 複雑なシステムやマイクロサービスアーキテク チャでの問題解決に特に有⽤ トレース Metrics Traces Logs
16. ⽤語説明：トレース、スパン 引⽤：Jaeger documentation https://www.jaegertracing.io/docs/1.8/architecture/#span ⽤語 説明 スパン スパンは分散トレーシングの基本単位で、処理の開始と終了時刻を含む。 ⼦スパンを持ち、処理の階層を表すことができる。 トレース トレースは複数のスパンから成り、⼀つのトランザクションを表す。リク エストの経路や時間、問題点を把握できる。
17. 1年前のBill Oneの状況
18. 1年前のBill Oneのオブザーバビリティ Metrics Traces Logs 活⽤の余地あり！！ - GCPがデフォルト提供 するメトリクスが基本 - ⼀部の重要箇所で カスタムメトリクスを 作成 - GCPがデフォルト提供す るログとアプリケーショ ンログが基本 - 各ログはトレースのIDに 紐付けており、フィルタ が可能 - ログから⼀部メトリクス の作成なども実施
19. 各スパンのレイテンシ → リクエストの開始と終了時刻を計算すればわ かる... 各サービスをまたぐリクエストの流れ → トレースのIDで絞ったログを⼼眼で⾒ればわ かる... 各APIエンドポイントごとのレイテンシーの統計 値 → BigQueryで集計すればわかる... 特定タイミングでのシステム全体の状況 → 考えるな！感じろ！ トレースと同等の情報 ログから抽出して気合いでなんとかしてた LBを通って... これはBFFのログだから この辺でBFFを通って... これはサービスAのログだから サービスAを通って... 各サービスをまたぐリクエストの流れを⼼眼で⾒る時のイメージ
20. 何が起きたか
21. 複雑な問題はベテランにしかデバッグができない ログ分析ツールを使いこなし、システム全体 の挙動を容易にイメージできるベテランだけ が即時にデバッグができる状況に...
22. - ログをトレースでフィルタできれば⼤抵の問題は誰でもデバッグできた - 複雑な問題も少なかったのでベテランがデバッグをすればなんとかなった ただ、しばらくは意外と困らなかった サービス規模が⼤きくなり、性能などの 複雑な問題の発⽣頻度が増え始め、 ベテランに頼らないデバッグの必要性が⾼まった
23. 改めて複雑なシステムにおける 理想的なデバッグを考えてみる
24. （参考）Bill Oneのアーキテクチャ概要図 Backend Service B Backend Service A BFF (backend for frontend) Backend Service Z ‧‧‧ 処理量が多いBFFや機能が多い主要サービス Aの問題が起きやすい傾向がある。 DB DB DB
25. 理想的なデバッグ
26. 理想的なデバッグ：ドリルダウン探索 原因が潜む範囲を狭めつつ、全体から細部へドリルダウンを繰り返し ながら的確に原因を特定していく ドリルダウン探索 勘と経験に頼った探索 原因
27. 具体例：ドリルダウン探索 サービスマップからレイテンシが悪化している サービスBを特定 サービス全体のレイテンシが悪化しアラート サービスBのトレースを複数確認し、⼀部のト レースでDBのレイテンシが⾼いことを発⾒ サービスBのDBのパフォーマンダッシュボード を確認し、原因となるクエリを特定
28. 具体例：ドリルダウン探索 ※ スクリーンショットはイメージです。 サービスBのトレースを複数確認し、⼀部のト レースでDBのレイテンシが⾼いことを発⾒ サービスBのDBのパフォーマンダッシュボード を確認し、原因となるクエリを特定 サービスマップからレイテンシが悪化している サービスBを特定 サービス全体のレイテンシが悪化しアラート
29. 具体例：ドリルダウン探索 サービスマップからレイテンシが悪化している サービスBを特定 サービス全体のレイテンシが悪化しアラート サービスBのトレースを複数確認し、⼀部のト レースでDBのレイテンシが⾼いことを発⾒ サービスBのDBのパフォーマンダッシュボード を確認し、原因となるクエリを特定 ※ スクリーンショットはイメージです。
30. 具体例：ドリルダウン探索 サービスマップからレイテンシが悪化している サービスBを特定 サービス全体のレイテンシが悪化しアラート サービスBのトレースを複数確認し、⼀部のト レースでDBのレイテンシが⾼いことを発⾒ サービスBのDBのパフォーマンダッシュボード を確認し、原因となるクエリを特定 ※ スクリーンショットはイメージです。
31. 具体例：勘と経験に頼った探索 どーせ、よく問題が起こる主要サービスAのDB やろ！！.....違った！！ じゃあ遅くなっている機能的にサービスBのDB かもな...！！ 勘と経験に頼った探索 サービスBのDBのパフォーマンダッシュボード を確認し、原因となるクエリを特定 サービス全体のレイテンシが悪化しアラート
32. 実際のところ熟練者の経験と 勘による探索はとても頼りになる
33. じゃあ、何が問題になる...？
34. - システムに対する豊富な知識と経験があるベテランでないと複雑な問題 のデバッグが困難 - 複合要因を⾒逃すことがある - 勘による思い込みで調査が難航する場合がある 勘と経験に頼った探索の問題点
35. 複合要因を⾒逃すことがある ドリルダウン探索 勘と経験に頼った探索 DBのクエリが遅くなっていたのは⼀部の トレースだけだった...何故全体のレイテンシが 上がった？？ DBクエリが悪かった！頑張って直そうな！！ もしかしてアプリケーション側にも問題が？？ DBクエリのタイムアウトが⻑く、既にユーザ が諦めているクエリでコネクションプールが 占有されていた。取得待ちが⻑くなりそれが さらに影響を⼤きくしていたことが判明。 DBクエリのタイムアウトを改善。
36. 勘による思い込みで調査が難航する場合がある ドリルダウン探索 勘と経験に頼った探索 サービス全体のレイテンシが悪化しアラート BFFのレイテンシが⾼くなっていてサービスA のエラー率も上がっている！！ レイテンシが⾼い期間の⼀部でしか サービスAのエラー率が上がっていないので 別問題として調査しよう BFFの共通処理で原因を発⾒！！ 全体が遅くなる系はサービスCだな。 あれ違った。じゃあ主要サービスAかな。 お、エラーでてんじゃん。これや、これや。 うーん⼀時的なものにも⾒える。。 でもエラー率上がっているからこれだと 思うんだよな〜。DBの⽅も⾒てみるか.... サービス全体のレイテンシが悪化しアラート
37. オブザーバビリティ向上の取り組み
38. - インシデント時にサービスマップなどで全体を俯瞰した上でドリルダウ ンしながら原因を特定できる仕組みが必要 - 今回は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.
39. - APM製品の⽐較・選定 - Google Cloudのコンテナサービス（Cloud Run）特有の仕様に合わせた トレースコンテキストの伝搬を実装 - バックエンドサービス（Kotlin/JVM）の計装 - BFF（Node.js）の計装 - Spanにカスタム属性を追加 - 顧客ごとのID - ユーザごとのID - コンテナのID...etc. 具体的にしたこと
40. - ドリルダウン探索が可能となり問題の特定が早くなった - 誰でも経験と勘に頼らないデバッグができる仕組みが整った - APMベンダの社外のエンジニアがインシデント時のAPMのデータだけ を利⽤して性能問題の原因に辿り着けた - 複合要因を的確に捉え、改善に繋げることができた 効果 Metrics Traces Logs Metrics Traces Logs
41. - 多くの開発者がデバッグにAPMを利⽤してドリルダウン探索をして いけるように布教していく - 基本的なAPMの使い⽅の勉強会を実施 - 実環境でのドリルダウン探索のデモやハンズオン - システムに合わせてスパンに付与するカスタム属性を検討 - ⼀部対応できていないサービスの計装 - Pub/Subの計装 - 組織内での活⽤例の探索・事例化・横展開...etc 今後やりたいこと
42. © Sansan, Inc. Sansan 技術本部 Bill One 開発エンジニア 採⽤情報 https://media.sansan-engineering.com/billone-engineer