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

by SansanTech

Slide 1

Slide 1 text

Log Analytics を使った実際の運⽤ - Sansan Data Hub での取り組み Sansan株式会社道下環久

Slide 2

Slide 2 text

2 © Sansan, Inc. ⾃⼰紹介 2022年に中途で Sansan に⼊社。以来 Sansan Data Hub の開発メンバーとして活動している。現在は Sansan Data Hub の海外開発拠点の⽴ち上げに奔⾛中。道下環久（Waku Michishita）

Slide 3

Slide 3 text

3 © Sansan, Inc. 1. 監視のコンポーネントごとにみる Sansan Data Hub の監視 2. Sansan Data Hub における運⽤今⽇お話すること

Slide 4

Slide 4 text

監視のコンポーネントごとにみる Sansan Data Hub の監視

Slide 5

Slide 5 text

5 © Sansan, Inc. ● 今回は『⼊⾨監視』にて紹介されている監視のコンポーネントの単位で Sansan Data Hub の監視を紹介監視のコンポーネント

Slide 6

Slide 6 text

6 © Sansan, Inc. ● データ収集 ● データストレージ ● 可視化 ○ 今回は割愛 ● 分析とレポート ● アラート監視のコンポーネント

Slide 7

Slide 7 text

7 © Sansan, Inc. ● 先ほどの5つの要素はすべて Azure Monitor にて賄われている Azure における Log の収集や分析画像引⽤元: Azure Monitor overview

Slide 8

Slide 8 text

8 © Sansan, Inc. ● データ収集 ● データストレージ ● 可視化 ○ 今回は割愛 ● 分析とレポート ● アラート監視のコンポーネント

Slide 9

Slide 9 text

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 を収集データ収集

Slide 10

Slide 10 text

10 © Sansan, Inc. Sansan Data Hub のアーキテクチャ

Slide 11

Slide 11 text

11 © Sansan, Inc. Sansan Data Hub のアーキテクチャ

Slide 12

Slide 12 text

12 © Sansan, Inc. ● データ収集 ● データストレージ ● 可視化 ○ 今回は割愛 ● 分析とレポート ● アラート監視のコンポーネント

Slide 13

Slide 13 text

13 © Sansan, Inc. ● 取得されたデータはその種類によって保管する場所が変わる ○ Metrics の場合 Azure Monitor Metrics ○ Log の場合 Azure Monitor Logs ■ Application Insights から送られる Log は Log Analytics Workspace に保管されるデータストレージ

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

15 © Sansan, Inc. ● デフォルトで取り込まれる Metrics のみで⼗分かどうかはプロダクトの運⽤に応じて決まる ● Sansan Data Hub は「顧客の環境からデータを取り込み、各種処理をした後顧客の環境に反映させる」というプロダクト ○ ⼤量にデータが⼊ってきた場合（⼤量にメッセージがエンキューされた場合）、スループットは変わらないが全部のデータを処理するのに時間がかかってしまう場合がある ■ メッセージの流⼊数・処理数だけでは全部を処理するのにどれだけ時間がかかるかわからない ● そこで⽤いられるのが Custom Metrics ○ ⾃分たちで Metrics の定義をして保存・活⽤することができる既存の Metrics のみで⼗分か？

Slide 16

Slide 16 text

16 © Sansan, Inc. ● やりたいこと ○ ある時点でキューに存在するメッセージの処理にどれだけ時間がかかっているかを知りたい ● ⽤意したもの - Consumer Delay ○ キューに残っている⼀番古いメッセージがエンキューされた時刻から現在時刻までの秒数 ■ これにより「N分前に来たメッセージがまだ処理されないまま残っている」を確認できる（対応できる） Custom Metrics - Consumer Delay

Slide 17

Slide 17 text

17 © Sansan, Inc. ● Azure Monitor Logs に送られた Log は Log Analytics Workspace のテーブルに保管される ○ 例えばある App Service に対する 500 エラーの Log は以下のように検索できる Log Analytics Workspace での Log の調査

Slide 18

Slide 18 text

18 © Sansan, Inc. ● Application Insights から送信される Log は全てとは限らない ○ 操作ID ごとに Log を保持するか保持しないか決定される（サンプリング） ○ デフォルト設定の場合、操作 Log の⼀部がサンプリングされて取り込まれる ○ ユーザー操作系の Log をサンプリングしてしまうと調査の際に困ってしまうので注意が必要 ● サンプリングにより Log の取り込み・保存にかかるコストを⼀定抑えることができる参考: Application Insights におけるサンプリング Azure Monitor Application Insights のサンプリング

Slide 19

Slide 19 text

19 © Sansan, Inc. ● Log や Custom Metrics の取り込み・保存にはお⾦かかるが ○ その中でも特に⼤きいのが Log の取り込み ● Analytics Logs プランの場合は以下のとおり実際 Log の取り込み・保存にどのくらいかかりますか？画像引⽤元: Azure Monitor Pricing

Slide 20

Slide 20 text

20 © Sansan, Inc. ● データ収集 ● データストレージ ● 可視化 ○ 今回は割愛 ● 分析とレポート ● アラート監視のコンポーネント

Slide 21

Slide 21 text

21 © Sansan, Inc. ● Azure Monitor Metrics に保存した Metrics は Metrics Explorer を使ってグラフを起こせる（以下は Consumer Delay の場合）分析とレポート

Slide 22

Slide 22 text

22 © Sansan, Inc. ● ダッシュボードを使って状況を⼀覧で確認している ○ 複数の指標を⼀度に確認できるので状況を把握しやすくなる（ex. 流⼊は増えたが順調に処理できている、スループットが落ちている）ダッシュボード

Slide 23

Slide 23 text

23 © Sansan, Inc. ● データ収集 ● データストレージ ● 可視化 ○ 今回は割愛 ● 分析とレポート ● アラート監視のコンポーネント

Slide 24

Slide 24 text

24 © Sansan, Inc. ● Azure Monitor Metrics/Logs に保存された情報を⽤いたアラート ○ Alert Rule を作成し、その条件に合致したらアラートを発報 ● Log Analytics のクエリベースでのアラート作成も可能アラート画像引⽤元: What are Azure Monitor alerts?

Slide 25

Slide 25 text

Sansan Data Hub における運⽤

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 © Sansan, Inc. ● 顧客が触れる UI や API で500エラーが発⽣した場合にアラートを発報 ○ 発⽣していることを検知すること⾃体が重要なので即発報 ■ アラートにすぐ対処できるよう Slack に通知している ■ 検知したら「どこのエンドポイントで発⽣しているのか？」を確認 ● アラートにクエリのリンクを載せることで対応しているポイント1: 顧客がエラーを体験したらすぐ対応ここに Log Analytics のクエリページのリンクが載ってます

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 © Sansan, Inc. ● Log Analytics のクエリベースで具体的な問題を知らせてくれるアラートを作成 ○ 遅延の予兆となる事象が検知された時点でお知らせ ● アラートに対応⼿順書が載っていることですぐに⾏動に移せるポイント2: ⾏動を促すアラート Notion の⼿順書のリンク

Slide 30

Slide 30 text

30 © Sansan, Inc. ● 普段から Dashboard をみることで状況を確認できる ○ 「なんかスループット落ちてる気がする」「このキューで Consumer Delay が伸び始めてる」といった予兆を感じたら先⼿を打つポイント3: 普段から Dashboard をみてアンテナを貼る

Slide 31

Slide 31 text

31 © Sansan, Inc. ● みんな⽬的意識を持ってアラートを作る ● しかし時代の流れによって以下のような問題が発⽣する ○ 作ったアラートが要らなくなる ○ 当初想定していたよりもアラートが多くなってしまう（オオカミ少年） ● アラートが適切に機能していないと軽視されてしまう可能性が出る ○ 「アラートがでた！」→「調査したけど問題なかった！」→「またアラートが出た！」→「やはり問題なかった！」→…を繰り返すと「そもそもこのアラート意味ないのでは？」と感じてしまう昔作ったアラートに噛まれる

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

No content