Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

SansanTech
September 26, 2023

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

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

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

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

SansanTech

September 26, 2023
Tweet

More Decks by SansanTech

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 上司陽平 Sansan株式会社 @paper2parasol - Sansan株式会社でBill OneプロダクトのSREチーム に2022年8⽉から所属 - 前職はSIer企業でコンテナ技術やSREの普及活動、

    AWS・AzureでのKubernetesサービスの設計・構 築に従事 - 現職ではSREのミッション定義や信頼性向上の⽂ 化づくり、オブザーバビリティの向上、負荷試験 による性能改善、IaC化などを推進 - 好きなものはラーメンとCloud Run
  2. 勘と経験に頼ったデバッグをしている 引⽤:オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda 検索機能が遅い??

    どーせサービスBのDBやろ!! Service B Service A 真因 DB DB 直感や勘を⼤切にするリアクティブなモニタリングベースのアプローチは、 確証バイアスによって問題の本当の原因を⾒えなくしてしまう傾向があります。
  3. ⻑く在籍するベテランエンジニアが チームの最⾼のデバッカー 引⽤:オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda

    チームにもっとも⻑く在籍しているエンジニアが、チーム最⾼のデバッガーであり、 最後の砦のデバッガーとなることが多いのです。...逆に、オブザーバビリティを実践 しているチームは、根本的に違う⽅向に傾きます。オブザーバビリティツールでは、 チーム内の最⾼のデバッガーは、通常、もっとも好奇⼼の強いエンジニアです。
  4. - システムやアプリケーションの動作を定量的に理解 するための数値データ - 根本原因を特定するために必要なハイレベルな概要 のみを⽰すことが多く、必ずしも根本原因を明らか にするわけではない メトリクス Metrics Traces

    Logs メトリクスの種類 例 システム CPU 使⽤率、メモリ使⽤率、ディスク使⽤率...etc. アプリケーション レスポンス時間、エラーレート、スループット (リクエスト/秒)...etc. ビジネス DAU、コンバージョン率、チャーン率...etc.
  5. 1年前のBill Oneのオブザーバビリティ Metrics Traces Logs 活⽤の余地あり!! - GCPがデフォルト提供 するメトリクスが基本 -

    ⼀部の重要箇所で カスタムメトリクスを 作成 - GCPがデフォルト提供す るログとアプリケーショ ンログが基本 - 各ログはトレースのIDに 紐付けており、フィルタ が可能 - ログから⼀部メトリクス の作成なども実施
  6. 各スパンのレイテンシ → リクエストの開始と終了時刻を計算すればわ かる... 各サービスをまたぐリクエストの流れ → トレースのIDで絞ったログを⼼眼で⾒ればわ かる... 各APIエンドポイントごとのレイテンシーの統計 値

    → BigQueryで集計すればわかる... 特定タイミングでのシステム全体の状況 → 考えるな!感じろ! トレースと同等の情報 ログから抽出して気合いでなんとかしてた LBを通って... これはBFFのログだから この辺でBFFを通って... これはサービスAのログだから サービスAを通って... 各サービスをまたぐリクエストの流れを⼼眼で⾒る時のイメージ
  7. (参考)Bill Oneのアーキテクチャ概要図 Backend Service B Backend Service A BFF (backend

    for frontend) Backend Service Z ‧‧‧ 処理量が多いBFFや機能が多い主要サービス Aの問題が起きやすい傾向がある。 DB DB DB
  8. 勘による思い込みで調査が難航する場合がある ドリルダウン探索 勘と経験に頼った探索 サービス全体のレイテンシが悪化しアラート BFFのレイテンシが⾼くなっていてサービスA のエラー率も上がっている!! レイテンシが⾼い期間の⼀部でしか サービスAのエラー率が上がっていないので 別問題として調査しよう BFFの共通処理で原因を発⾒!!

    全体が遅くなる系はサービスCだな。 あれ違った。じゃあ主要サービスAかな。 お、エラーでてんじゃん。これや、これや。 うーん⼀時的なものにも⾒える。。 でもエラー率上がっているからこれだと 思うんだよな〜。DBの⽅も⾒てみるか.... サービス全体のレイテンシが悪化しアラート
  9. - インシデント時にサービスマップなどで全体を俯瞰した上でドリルダウ ンしながら原因を特定できる仕組みが必要 - 今回は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.
  10. - APM製品の⽐較・選定 - Google Cloudのコンテナサービス(Cloud Run)特有の仕様に合わせた トレースコンテキストの伝搬を実装 - バックエンドサービス(Kotlin/JVM)の計装 -

    BFF(Node.js)の計装 - Spanにカスタム属性を追加 - 顧客ごとのID - ユーザごとのID - コンテナのID...etc. 具体的にしたこと