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

■イベント
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チーム 上司陽平
   

   View Slide

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

   View Slide

3. © Sansan, Inc.
   

   View Slide

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

   View Slide

5. オブザーバビリティとは
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. 1年前のBill Oneの状況
    

    View Slide

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

    View Slide

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

    View Slide

20. 何が起きたか
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. 理想的なデバッグ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

42. © Sansan, Inc.
    Sansan 技術本部
    Bill One 開発エンジニア
    採⽤情報
    https://media.sansan-engineering.com/billone-engineer
    

    View Slide

43. View Slide