Log Analytics を使った実際の運用 - Sansan Data Hub での取り組み

■ イベント
Azure勉強会 - Entra ID と Log Analytics と Cosmos DB -
https://sansan.connpass.com/event/344953/

■ 発表者
技術本部 Sansan Engineering Unit Data Hubグループ
道下 環久

■ Sansan Data Hub 開発エンジニア 採用情報
https://media.sansan-engineering.com/datahub-engineer

Transcript

1. Log Analytics を使った実際の運⽤ - Sansan Data Hub での取り組み Sansan株式会社 道下 環久
2. 2 © Sansan, Inc. ⾃⼰紹介 2022年に中途で Sansan に⼊社。以来 Sansan Data Hub の開発メンバーとして活動している。 現在は Sansan Data Hub の海外開発拠点の⽴ち上げに奔⾛ 中。 道下 環久（Waku Michishita）
3. 3 © Sansan, Inc. 1. 監視のコンポーネントごとにみる Sansan Data Hub の監視 2. Sansan Data Hub における運⽤ 今⽇お話すること
4. 監視のコンポーネントごとにみる Sansan Data Hub の監視
5. 5 © Sansan, Inc. • 今回は『⼊⾨ 監視』にて紹介されている監視のコンポーネントの単位で Sansan Data Hub の監視を紹介 監視のコンポーネント
6. 6 © Sansan, Inc. • データ収集 • データストレージ • 可視化 ◦ 今回は割愛 • 分析とレポート • アラート 監視のコンポーネント
7. 7 © Sansan, Inc. • 先ほどの5つの要素はすべて Azure Monitor にて賄われている Azure における Log の収集や分析 画像引⽤元: Azure Monitor overview
8. 8 © Sansan, Inc. • データ収集 • データストレージ • 可視化 ◦ 今回は割愛 • 分析とレポート • アラート 監視のコンポーネント
9. 9 © Sansan, Inc. • Azure Monitor は様々なものを監視対象とできる。また監視対象によっ てデータの収集⽅法等が異なる。例えば… ◦ Azure Resource ▪ Activity Log と Platform Metrics は⾃動で収集される ▪ diagnostic setting を設定することで Resource Logs も収集できる ◦ アプリケーション ▪ Azure Monitor SDK や Application Insights SDK を通じて Log やメトリクス、 トレースを収集 ◦ Virtual Machine ▪ Azure Monitor Agent を通じて Log を収集 データ収集
10. 10 © Sansan, Inc. Sansan Data Hub のアーキテクチャ
11. 11 © Sansan, Inc. Sansan Data Hub のアーキテクチャ
12. 12 © Sansan, Inc. • データ収集 • データストレージ • 可視化 ◦ 今回は割愛 • 分析とレポート • アラート 監視のコンポーネント
13. 13 © Sansan, Inc. • 取得されたデータはその種類によって保管する場所が変わる ◦ Metrics の場合 Azure Monitor Metrics ◦ Log の場合 Azure Monitor Logs ▪ Application Insights から送られる Log は Log Analytics Workspace に保管さ れる データストレージ
14. 14 © Sansan, Inc. • リソースによって送られる Metrics は異なる ◦ 例1) Service Bus ▪ Queue/Topic に存在するメッセージ数 / Count of messages in a Queue/Topic ▪ メッセージの流⼊数・処理数 / Incoming/Outgoing Messages ◦ 例2) SQL Database ▪ CPU の使⽤率 / CPU percentage ▪ データ I/O / Data IO ▪ DTU の使⽤率 / DTU percentage Azure Monitor Metrics に送られる Metrics
15. 15 © Sansan, Inc. • デフォルトで取り込まれる Metrics のみで⼗分かどうかはプロダクトの 運⽤に応じて決まる • Sansan Data Hub は「顧客の環境からデータを取り込み、各種処理をし た後顧客の環境に反映させる」というプロダクト ◦ ⼤量にデータが⼊ってきた場合（⼤量にメッセージがエンキューされた 場合）、スループットは変わらないが全部のデータを処理するのに時間 がかかってしまう場合がある ▪ メッセージの流⼊数・処理数だけでは全部を処理するのにどれだけ時間が かかるかわからない • そこで⽤いられるのが Custom Metrics ◦ ⾃分たちで Metrics の定義をして保存・活⽤することができる 既存の Metrics のみで⼗分か？
16. 16 © Sansan, Inc. • やりたいこと ◦ ある時点でキューに存在するメッセージの処理にどれだけ時間がかかっ ているかを知りたい • ⽤意したもの - Consumer Delay ◦ キューに残っている⼀番古いメッセージがエンキューされた時刻から現 在時刻までの秒数 ▪ これにより「N分前に来たメッセージがまだ処理されないまま残っている」 を確認できる（対応できる） Custom Metrics - Consumer Delay
17. 17 © Sansan, Inc. • Azure Monitor Logs に送られた Log は Log Analytics Workspace のテー ブルに保管される ◦ 例えばある App Service に対する 500 エラーの Log は以下のように検 索できる Log Analytics Workspace での Log の調査
18. 18 © Sansan, Inc. • Application Insights から送信される Log は全てとは限らない ◦ 操作ID ごとに Log を保持するか保持しないか決定される （サンプリング） ◦ デフォルト設定の場合、操作 Log の⼀部がサンプリングされて 取り込まれる ◦ ユーザー操作系の Log をサンプリングしてしまうと 調査の際に困ってしまうので注意が必要 • サンプリングにより Log の取り込み・保存にかかるコストを ⼀定抑えることができる 参考: Application Insights におけるサンプリング Azure Monitor Application Insights のサンプリング
19. 19 © Sansan, Inc. • Log や Custom Metrics の取り込み・保存にはお⾦かかるが ◦ その中でも特に⼤きいのが Log の取り込み • Analytics Logs プランの場合は以下のとおり 実際 Log の取り込み・保存にどのくらいかかりますか？ 画像引⽤元: Azure Monitor Pricing
20. 20 © Sansan, Inc. • データ収集 • データストレージ • 可視化 ◦ 今回は割愛 • 分析とレポート • アラート 監視のコンポーネント
21. 21 © Sansan, Inc. • Azure Monitor Metrics に保存した Metrics は Metrics Explorer を使って グラフを起こせる（以下は Consumer Delay の場合） 分析とレポート
22. 22 © Sansan, Inc. • ダッシュボードを使って状況を⼀覧で確認している ◦ 複数の指標を⼀度に確認できるので状況を把握しやすくなる （ex. 流⼊は増えたが順調に処理できている、スループットが落ちている） ダッシュボード
23. 23 © Sansan, Inc. • データ収集 • データストレージ • 可視化 ◦ 今回は割愛 • 分析とレポート • アラート 監視のコンポーネント
24. 24 © Sansan, Inc. • Azure Monitor Metrics/Logs に保存された情報を⽤いたアラート ◦ Alert Rule を作成し、その条件に合致したらアラートを発報 • Log Analytics のクエリベースでのアラート作成も可能 アラート 画像引⽤元: What are Azure Monitor alerts?
25. Sansan Data Hub における運⽤
26. 26 © Sansan, Inc. • Log は集めるだけでは意味ない • アラートも出すだけでは意味ない • 「どういうことが起こったときにどういうアクションができるか」 が⼤事 で、あなたはどういう運⽤をしたいの？
27. 27 © Sansan, Inc. • 顧客が触れる UI や API で500エラーが発⽣した場合にアラートを発報 ◦ 発⽣していることを検知すること⾃体が重要なので即発報 ▪ アラートにすぐ対処できるよう Slack に通知している ▪ 検知したら「どこのエンドポイントで発⽣しているのか？」を確認 • アラートにクエリのリンクを載せることで対応している ポイント1: 顧客がエラーを体験したらすぐ対応 ここに Log Analytics の クエリページのリンクが載ってます
28. 28 © Sansan, Inc. Sansan Data Hub のアーキテクチャ
29. 29 © Sansan, Inc. • Log Analytics のクエリベースで具体的な問題を知らせてくれる アラートを作成 ◦ 遅延の予兆となる事象が検知された時点でお知らせ • アラートに対応⼿順書が載っていることですぐに⾏動に移せる ポイント2: ⾏動を促すアラート Notion の⼿順書のリンク
30. 30 © Sansan, Inc. • 普段から Dashboard をみることで状況を確認できる ◦ 「なんかスループット落ちてる気がする」「このキューで Consumer Delay が伸び始めてる」といった予兆を感じたら先⼿を打つ ポイント3: 普段から Dashboard をみてアンテナを貼る
31. 31 © Sansan, Inc. • みんな⽬的意識を持ってアラートを作る • しかし時代の流れによって以下のような問題が発⽣する ◦ 作ったアラートが要らなくなる ◦ 当初想定していたよりもアラートが多くなってしまう（オオカミ少年） • アラートが適切に機能していないと軽視されてしまう可能性が出る ◦ 「アラートがでた！」→「調査したけど問題なかった！」→「またアラ ートが出た！」→「やはり問題なかった！」→…を繰り返すと「そもそ もこのアラート意味ないのでは？」と感じてしまう 昔作ったアラートに噛まれる
32. 32 © Sansan, Inc. • 有志が以下の⽬的を掲げてアラート改善の活動をした アラート改善活動
33. 33 © Sansan, Inc. • アラート開発のガイドラインを策定 アラート改善活動紹介
34. 34 © Sansan, Inc. • 管理表を作成することで棚卸しを容易にした ◦ 現在四半期に⼀回棚卸しを⾏っている アラート改善活動紹介 ここに具体的なアラート名が記載されている
35. 35 © Sansan, Inc. • 「思ったよりアラートが発報されるからしきい値直したい」みたいな要 望は常にやってくる ◦ これを放置するのではなく、気づいたら都度改善していくしかない アラート改善活動が終わっても