オブザーバビリティの探求 〜性能劣化から始まった旅路〜

■ イベント
オブザーバビリティ実践までの道のり〜各社の課題とアプローチ方法とは？〜
https://findy.connpass.com/event/328935/

■ 発表者
技術本部 Bill One Engineering Unit SREチーム　上司 陽平

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

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. オブザーバビリティの探求 〜性能劣化から始まった旅路〜 Sansan株式会社 Bill One Engineering Unit SREチーム 上司陽平
2. 自己紹介 じょーし Sansan株式会社 @paper2parasol - Sansan株式会社でBill OneプロダクトのSREチームに 2022年8月から所属 - 前職はSIer企業でコンテナ技術やSREの普及活動、 AWS・AzureでのKubernetesサービスの設計・構築に 従事 - 現職ではSREチームのミッション定義や負荷試験によ る性能改善、IaC化と文化醸成などを推進 - 最近はCI/CDのオブザーバビリティに興味を持ってい る - 好きなものはラーメンとCloud Run
3. ©Sansan, Inc.
4. アジェンダ オブザーバビリティとは 向上に取り組んだきっかけ 活用事例 真因の探求
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. ベテランではなく好奇心の強いエンジニアが チーム内の最高のデバッカーになれる 引用：オブザーバビリティ・エンジニアリング Charity Majors, Liz Fong-Jones, and George Miranda チームにもっとも長く在籍しているエンジニアが、チーム最高のデバッガーであり、 最後の砦のデバッガーとなることが多いのです。...逆に、オブザーバビリティを実践 しているチームは、根本的に違う方向に傾きます。オブザーバビリティツールでは、 チーム内の最高のデバッガーは、通常、もっとも好奇心の強いエンジニアです。
9. 向上に取り組んだきっかけ
10. 高負荷時に性能劣化が発生 Backend Service B Backend Service A BFF (backend for frontend) Backend Service Z ・・・ DB Bill One DB DB
11. 負荷試験による性能劣化原因の特定と解消 GCE 原因：DBのログ量が多い場合にクエリレイテンシが悪化していた Backend Service B Backend Service A BFF (backend for frontend) Backend Service Z ・・・ DB Bill One DB DB
12. 原因特定長期化の理由：アプリを中心に原因調査していた Service DB 俺は早い DBが遅い - 一部のトレースログでDBのクエリが 遅いことに気づく - 目確認かつサンプル数も少ないので Google Cloudのメトリクスより信用 しきれなかった - アプリ中心に原因分析をしてかなり の時間を消費した - Google Cloudのメトリクス - 実際にはクエリレイテンシが 高くなっていたのにメトリク スには反映されていなかった
13. 各スパンのレイテンシ → リクエストの開始と終了時刻を計算すればわ かる... 各サービスをまたぐリクエストの流れ → トレースのIDで絞ったログを心眼で見ればわ かる... 各APIエンドポイントごとのレイテンシーの統計 値 → BigQueryで集計すればわかる... 特定タイミングでのシステム全体の状況 → 考えるな！感じろ！ （参考）トレースの詳細情報の取得 当時はログから抽出して気合いでなんとかしてた LBを通って... これはBFFのログだから この辺でBFFを通って... これはサービスAのログ だからサービスAを通って... 各サービスをまたぐリクエストの流れを心眼で見る時のイメージ
14. この状況だと今後の成長に伴う性能問題に組織 として立ち向かえないという課題感があった
15. オブザーバビリティ向上の取り組み
16. - トラブルシュート時にサービスマップなどで全体を俯瞰した上でドリルダウ ンしながら原因を特定できる仕組みが必要 - 今回は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.
17. - APM製品の比較・選定 - Google Cloudのコンテナサービス（Cloud Run）特有の仕様に合わせた トレースコンテキストの伝搬を実装 - バックエンドサービス（Kotlin/JVM）の計装 - BFF（Node.js）の計装 - Spanにカスタム属性を追加 - 顧客ごとのID - ユーザごとのID - コンテナのID...etc. 具体的にしたこと
18. サービスマップの拡充 - 既存、新規サービスの 計装を順次実施 - コンポーネント数は1 年間で36→60に - BOの複雑なシステム を俯瞰してトラブルシ ュートができるように なった
19. 活用事例
20. 今同じ問題が起きたら Service DB 俺は早い DBが遅い - DBのクエリレイテンシが統計 的に遅いことがすぐわかる - サポートへの問い合わせ判断 や根拠の収集などが全体的に 早くなるはず - Google Cloudのメトリクス - 実際にはクエリレイテンシが 高くなっていたのにメトリク スには反映されていなかった
21. マイクロサービスのどこが問題なのか特定が早くなった Backend Service B Backend Service A BFF (backend for frontend) Backend Service Z ・・・ DB Bill One DB DB
22. 主機能の請求書検索の性能改善に活かせた - 請求書検索画面の検索条件にデフォルト期間を指定することで性能改善 - 事前に計装を行い、請求書検索の利用方法を分析 - 影響が少なく改善効果が高い方法を模索できた - Elasticsearchの活用なども検討したが今回は見送った
23. 真因の探求
24. そもそもオブザーバビリティは 向上したのか
25. 向上した！！ • マイクロサービスのような複雑な構成のトラシューがより容易 になった • よりデバッグしやすい環境は確実に整った ただ、理想まで道のりは遠いと感じる オブザーバビリティが高い状況（再掲） ソフトウェアシステムのどんな状態でも、どんなに斬新で奇妙な問題でも デバッグして正しい原因を素早く見つけられる状況
26. 真因を探求する 心意気も重要（根性論）
27. 一緒に探求しませんか？ （お約束）
28. ©Sansan, Inc. Sansan 技術本部 Bill One 開発エンジニア 採用情報 https://media.sansan-engineering.com/billone-engineer