監視・ログ分析を最初から始めるイマドキの事情と理由・その1（混乱編）

後回しに
しない
❗
1
監視･ログ分析を最初から始める
イマドキの事情と理由・その
〜俯瞰混乱編〜
渡辺聖剛
ソリューションアーキテクト
AWS事業本部パートナーアライアンス部
2020.07.03

View Slide

2
監視回　その1
https://dev.classmethod.jp/news/developers-io-2020/

イマココ

View Slide

3
Agenda

View Slide

4
Agenda
まえおき - 前提となる話
50:50 - SREの話
SかMか - 監視の話
3-4-3 - 可観測性（o11y）の話
それから?
→以下、その2へ続く

View Slide

5
本日のゴール

View Slide

6
本日のゴール
Modern Application Development
急にモダンなアプリケーションをデベロップメントする
ことになっても、
「え、監視とかどうすれば・・？」
と悩まずにすむようになること
https://www.irasutoya.com/2015/12/blog-post_51.html

View Slide

7
免責事項
時間が限られているので
すごくざっくりした話しかしません
流れをつかんでもらうのが目的です

View Slide

8
免責事項　その2
時間が限られているので
スライドに書いてあること全てを話しません
興味がわいたらあとから読んで頂けますと！

View Slide

9
自己紹介
渡辺聖剛 ( Seigo Watanabe )
● クラスメソッド株式会社
AWS 事業本部
パートナーアライアンス部
● 前職までは
所謂インフラエンジニア
● 運用・監視(Monitoring)
● 好きな AWS サービス
○ ACM, Route 53
○ AWS Systems Manager
https://dev.classmethod.jp/author/watanabe-seigo/

View Slide

10
※未承諾広告
モニタリングまわりの記事を担当
AWSにかなり限定した内容に
なってます
重複するところは多いですが、
本ではかけなかった話
＋アップデートを話します
https://gihyo.jp/book/2020/978-4-297-11329-2

View Slide

11
本題

View Slide

12
モダンな監視を語る上で外せない
前提となる話

View Slide

13
前提となる話
● アーキテクチャとコンピュート能力
● ビジネス要件と開発・運用体制
これらの変化について

View Slide

14
アーキテクチャとコンピュート能力
モノリシックからマイクロサービスへ
- Container, k8s, FaaS ...
コンピュート性能の爆発的向上
- 計算・I/O性能、ストレージコストは低減
- 超高速ネットワーク
- 仮想化技術などの技術革新
Software Deﬁned X (SDx)
- X = Network, Infrastructure ...
- 従来ハードウェアだったものがソフトウェアで
置き換えられていく

View Slide

15
ビジネス要件と開発・運用体制
より早いサイクルでのサービス向上が求められる
開発・運用体制
- ウォーターフォールからDevOps
- DevOpsからSRE
https://pixnio.com/ja/media/ja-2227252

View Slide

16
つまり現在は…
扱う対象は複雑化し数も膨大になり
速度と変化と信頼性のバランスが
求められる世の中
https://commons.wikimedia.org/wiki/File:Rubik's_cube_almost_solved.svg
https://www.pexels.com/photo/cargo-container-lot-906494/
https://ja.wikipedia.org/wiki/DevOps

View Slide

17
SREの話
50:50

View Slide

18
監視なのになぜSRE？
いまの世の中避けて通れない
SREの文脈を抑えておくことで
ベストプラクティスが見えてくるから

View Slide

19
SREってなんぞ
Site Reliability Engineering（または〜Engineer）
技術であり、そのためのエンジニアロール
SREの目的は「信頼性の向上」
- 変化し続けるサイト（システム）を前提に、
そのサイトで安定的に「サービスを提供すること」
- サイトを「安定稼働させること」ではない
ちゃんと動いているかどうかを知ることが必要
従来との違い → SREは攻めの運用

View Slide

20
GoogleにおけるSRE
”SREは、これまで運用チームが行ってきたことをソフ
トウェアの専門性を持つエンジニアが行い、エンジニア
が人手による管理を自動化するソフトウェアを設計し実
装する能力を持ち、それをいとわないということから成
り立っています“
- “SRE サイトリライアビリティエンジニアリング”
https://www.oreilly.co.jp/books/9784873117911/

View Slide

21
GoogleにおけるSRE(cont.)
● 仕事の半分はコードを書くこと
○ 自動化、Infrastructure as Code
○ 必要なメトリックを収集する仕組みの組み込み
○ プルリク
○ その他「信頼性をあげる」ために必要なこと
● 残りの半分で、
チケット、オンコール、手作業といった運用業務
観念ではなく、明確に工数を分ける

View Slide

22
つまりSREとは
コードを書くことがSREの仕事（の半分）
SREは運用業務を自動化で減らし、サイトの信頼性を
上げつつ、コードを書く時間を捻出する必要がある
“You Build It, You Run It.”
- Werner Vogels, Amazon CTO
- とってもDevOps
https://dl.acm.org/doi/pdf/10.1145/1142055.1142065

View Slide

CALMS - DevOpsの哲学のキーポイント
- Culture
- Automation
- Lean
- Measurement
- Sharing
DevOpsにとってMeasurementは
重視されるべきもの
23
DevOpsの文化

View Slide

SREがサイトの「信頼性」を維持するためには、
何が起こっているかを監視しなくてはならない
→ SREの文脈に沿って「監視」を行うことが
　いまのベストプラクティス
24
つまり

View Slide

25
「監視」の話
S or M

View Slide

26
そもそも「監視」とは？
システムを常時観測・計測し
異常が検知できたら
それに対して対処する
対処
Respond / Resolve
検知
Detect
計測
Measurement
https://www.irasutoya.com/

View Slide

27
監視と言えば　入門「監視」
発行：2019.01
一大監視ブームを巻き起こした
うなずくことが多い一方で、
読んでいてどこか違和感がある
文句なしの良書ではあるけど、
ぼくの知ってる監視とは何か違う…

View Slide

28
Q
あなたの監視は「S」ですか？
それとも「M」ですか？

View Slide

29
再掲：監視とは
システムを常時観測・計測し
異常が検知できたら
それに対して対処する
対処
Respond / Resolve
検知
Detect
計測
Measurement

View Slide

30
あなたの監視はSかMか？
検知を重視 = 「問題が起こらないこと」
= S（Surveillance）な監視
対処
Respond / Resolve
検知
Detect
計測
Measurement

View Slide

31
あなたの監視はSかMか？
計測を重視 = 「何が起こっているのか」
= M（Monitoring）な監視
注：監視のSとかMとか言ってるのは独自研究です
対処
Respond / Resolve
検知
Detect
計測
Measurement

View Slide

32
辞書的な定義
monitorもsurveillanceもobserveもsuperviseも、
日本語にするとみんな「監視」になる
一方で、日本語の「監視」には「S」な意味合いが強い
● 監視カメラ : Video surveillance, CCTV
● 監視社会 : surveillance society, watchdog society
● PCモニタのことを「監視装置」とは訳さない
https://pixnio.com/ja/
https://flic.kr/p/3iapit

View Slide

33
トラディショナルな監視の定義
Nagiosまではそんなに違和感なかった
● チェック監視 = Nagios
リソース監視 = Cacti
● Zabbixは両方できる
○ 当時はそれが画期的でもあった
○ そのあたりから混乱が始まってる感
（個人の感想です）
可観測性までくると違いが際立ってくる
https://commons.wikimedia.org/

View Slide

34
Sな監視「も」必要であり適切
「ちゃんと作ればちゃんと出来る」時には有効
○ 建築や製造業など
○ 守ること・事故を起こさないことそのものが目的
○ 単純な閾値チェック
本来の「サーベイランス」はそうであるべき
○ 収監、検疫など
○ 単純化による判断・対処の迅速化
○ 命に関わるものはそれが最優先

View Slide

35
一方で、
● ソフトウェアでは「ちゃんと作る」と時間がかかる
● 不具合のないソフトウェアを作ることはもはやムリ
● 仮に「ちゃんと出来」たとしても、
あっという間に古くなる
● 検知にだけ注目すると、単純な閾値チェックで
事足りる -> コンテキストが失われる
複雑化したモダンアプリにおいて、
「S」な監視を行っていては追いつかない
https://torange.biz/jp/fx/background-modular-modern-blue-abstract-arrows-creative-215352

View Slide

36
monitorの意味
“to watch and check something over a period of
time in order to see how it develops, so that you
can make any necessary changes.”
- Oxford Learner's Dictionary
「必要な変更を加えることが出来るように、ある期間に
わたって、それがどのようにして発展したかを把握する
目的で、見て、そしてチェックすること」
https://www.oxfordlearnersdictionaries.com/definition/english/monitor_1?q=monitor

View Slide

37
つまり：M（Monitoring）な監視では
計測結果が対処とワンセットに
○ 「まず世に出してから修正する」には
こっちがハマる
“Done is better than perfect”
○ Mark Elliot Zuckerberg, CEO of Facebook, Inc.
○ 「完全なものなどないという前提のもと、完全に近づく
ために細かな継続的改善・反復が重要だ」ということ
○ 現状の把握（Monitoring）なしでは為しえない
https://medium.com/@amachino/done-is-better-than-perfect-%E3%81%AE%E6%84%8F%E5%91%B3-dc2c74069ece
https://commons.wikimedia.org/wiki/File:Mark_Zuckerberg_F8_2018_Keynote.jpg

View Slide

38
古典「推測するな、計測せよ」
Notes on Programming in C
“ルール1: （略）どこがボトルネックなのかをはっきり
させるまでは、推測を行ったり、スピードハックをして
はならない”
“ルール2: 計測すべし。計測するまでは速度のための調
整をしてはならない。（後略）”
- Robert "Rob" C. Pike
https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6
http://www.lysator.liu.se/c/pikestyle.html

View Slide

39
入門「監視」による言及
“そう言った人たちは、何か問題がおきた時にアラートを
出すことが監視システムの目的だと信じているのです。
（中略）監視にはもっと高い目的があります。
「監視は、質問を投げかけるためにある。」”
“監視とはアラートを出すために存在しているのでは
ありません。アラートは結果の1つの形でしかないのです”
邦題：入門「監視」
原題：Practical Monitoring
https://www.oreilly.com/library/view/practical-monitoring/9781491957349/

View Slide

40
つまり：今どきの監視とは
アラートのためではない、
よい運用を行うための情報収集(monitoring)
● パフォーマンスチューニング
● トラブルシューティング
→次の開発サイクル（Iteration）のため
https://www.flickr.com/photos/fcrippa/7967994338/

View Slide

41
収集してどうする？
人間が受け取る：手動で対処
○ Devがうけとる：コードの修正
○ Opsがうけとる：メンテナンス、リソースマネジメント
機械が受け取る：自動処理のトリガー
○ AutoScaling
○ AutoRecovery
○ Failover
○ Retry

View Slide

42
ここまでのまとめ
変化にあわせて意識もかえよう
SREが必要としているのはM

View Slide

43
可観測性
Observability (o11y)
3-4-3

View Slide

44
じゃあ具体的に何をモニタリングしましょう
おさらい：
SREの目的は「信頼性の向上」
信頼性（Reliability）とは？

View Slide

45
Failure mode, SLI, SLO
ENT308-S - Build your next microservices
application with modern AWS services
https://youtu.be/msxD0bTFu2A?t=2505
https://dev.classmethod.jp/articles/201912-report-reinvent-2019-ent308/

View Slide

46
Failure mode, SLI, SLO (cont.)
failure mode SLI SLO SLA
何をもって
故障とするか
それの重要度
(RRN)はどの
くらいか
何を使ったら
それが測れる
か
それが具体的
にどんなとき
に「正常」と
するのか
それをどう
顧客と約束す
るか・しない
か（見せるか
見せないか）
例) サイトの
表示が遅い
表示速度の
p95
99%が
7秒以下
99.99%
https://youtu.be/msxD0bTFu2A?t=2505
https://dev.classmethod.jp/articles/201912-report-reinvent-2019-ent308/

View Slide

47
つまり
まず「異常（信頼性が損なわれた状態）」を定義
SLI = 定めた「異常」を計る上でキーとなる指標
SLO = そのSLIに対して、どうである時を正常あるいは
異常(故障)と判断するかを定義したもの
“SREの日々のタスクやプロジェクトは、
SLOによって駆動されます”
- サイトリライアビリティワークブック

View Slide

48
つまり
正常な判断のためには、SLI/SLOにつながる監視を
● なんでもかんでも見る必要はない
● 見る意味のあるデータについてだけ観れば良い
一方で、
「見る意味があるものは何か？」を知る必要がある
○ 本と検索エンジンの話に似ている

View Slide

49
基本方針：全体を見ましょう
全体をみて方針を決め
ドリルダウンして対処する
その材料としてデータの収集を
※その2で詳しく話します
https://www.pexels.com/photo/cargo-container-lot-906494/

View Slide

50
着目点
3 Pillars
4 Golden Signals
3 Dimensions

View Slide

51
The Three Pillars of Observability
Metrics（数値、低コンテキスト）
Event Logs（含メタデータ、高コンテキスト）
Tracing（事象の関連性・分散トレーシング）
- Distributed Systems Observability
https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html

View Slide

52
The Four Golden Signals
Latency (パフォーマンス・遅延)
Traﬃc (トラフィック量)
Errors (エラー発生率)
Saturation (利用率、キャパシティ)
- SREサイトリライアビリティエンジニアリング
https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/

View Slide

53
Three dimensions
Functionally (その機能が正しく動いているか)
Availability (その機能が使えるか)
Speed (遅くないか)
- Best Practices for Monitoring E-Commerce
Performance
https://newrelic.com/resources/tutorials/best-practices-for-monitoring-ecommerce-performance

View Slide

54
雑な関連
Metric
数値
Event Log
高コンテキスト
Trace
関連性
Latency
遅延
Traﬃc
流量
Errors
エラー
Saturation
キャパシティ
Functionally
機能の正常性
Availability
可用性
Speed
速度・性能
何を取得するかシグナル観点
※線がないから取れない・関係がない、というわけではありません
遅すぎる⇔使えない
情報量の違い

View Slide

55
SRE的な観点
● 「エラーバジェット」という考え方
● MTTR

View Slide

56
「エラーバジェット」という考え方
サイトリライアビリティを語る上で欠かせない概念
エラーバジェットを使って何をするか？
● ひとつの考え方
○ 「試験は通ったが本番で動かない」ケース
○ どうせなら、本番稼働で検知して即対応できたほうが
良いのでは？
■ →誰よりも早く運営チームが気付く必要性
● もうひとつの考え方
○ エラーバジェットが許す範囲で復旧できたらいい

View Slide

57
MTTRも気にしよう
Mean Time To Repair = 復旧までの最小平均時間
Mean Time To Resolution = 解決までの最小平均時間
SLO 99.9% = 毎月30〜40分止まっても許される？
○ 「1回の停止は5分以内」のような定義も必要
○ SLOを日単位、時間単位でも設定する
■ 99.9%/day = 8.64sec.

View Slide

58
ここまでのまとめ
● SREはSLOによって駆動される
● SLOを求めるには計測(監視)しかない
● ここでいう監視はMのこと

View Slide

59
可観測性 = 広義の「可視化」その性能
見えなかったものを見えるようにする
- つながり・連続性の可視化 = (分散)トレース
- 数値表現から図示・グラフ化 = ダッシュボード
可観測性（Observability）
= そのシステムがそなえている性質・性能
- Availability, Capability, Scalability ...

View Slide

60
何に着目するか
3-4-3（前述）
Metric
Event Log
Trace
Latency
Traﬃc
Errors
Saturation
Functionally
Availability
Speed

View Slide

61
何に着目するか（cont.）
3-4-3（前述）
Metric
Event Log
Trace
Latency
Traﬃc
Errors
Saturation
Functionally
Availability
Speed

View Slide

62
「性能は機能」
つまるところ「速いは正義」
● 使えない
= ユーザーから見たら「無限に遅い（帰ってこない）」
= タイムアウト
● 応答時間と離脱率には相関がある
レスポンスタイムを上げることが業績に繋がる

View Slide

63
「監視エージェント入れたら性能下がりました^^」
よく聞く話ですが。。。
例）
- エージェントいれたらCPU負荷が10%増えた
- PageSpeed Insightsのスコアが20下がった
※あとでお話しします

View Slide

64
ログの話

View Slide

65
そもそも「ログ」とは
トラディショナルなイメージ
● 取りあえず出力されるもの
● /var/log/ほげほげ
● ほっとくとディスクを食い潰す
● たまにエラーが吐かれてて気をつけなきゃならない
● デバッグログが大量に出ているが放置
https://help.sumologic.com/01Start-Here/Quick-Start-Tutorials/Set-Up-Sumo-Logic-Tutorial

View Slide

66
可観測性では
「コンテキスト豊かな監視データ」と捉える
- 高コンテキスト = 情報量が多い、事象の背景
- 正規化・非正規化どちらもある
- 正規化ログ = JSON（Stack Traceなど）
- 非正規化ログ = テキスト1行（Apacheなど）

View Slide

67
Event Log（Events）？
● メタデータが正規化されたログ、
あるいはコンテキスト豊富なメトリック
● 一方で、メトリックにメタデータを付与するような
動きもあり
○ Prometheus, OpenMetrics（後述）
● 境界がグレーになってきている
○ メトリックとイベントの境、イベントとログの境
○ 厳密なものではなく、感覚で捉えていいと思う

View Slide

68
ログをどう使う？
2つの方向性（従来から大きくは変わっていない）
● ログからキーワードをひろう
● イベント発生時にどんなログが出ていたかを掘り起
こせるように収集する
死活監視・リソース監視と考え方は同じ
トレースログなどはログとして扱うのではなく、
分散トレース（APM）で扱う

View Slide

69
具体的には
ツールにため込んで可視化
保存
重要度別に通知・アラート

View Slide

70
ログの可視化
コンテキストが多い = ぱっとみよく分からん
有望有効な情報が埋もれているかもしれない
→もったいない
可視化・有益なデータを掘り起こす
そのための分析ツール
※その2で詳しく

View Slide

71
長期保存と中・短期保存
長期 = アーカイブ、記録や監査のため
○ 日単位、数年単位
○ 何かあったときに掘り起こせれば良い
中期 = 傾向の把握（短期との比較）
○ 時間単位、数日〜1週間〜数ヶ月、13ヶ月
○ シーズナルな影響をどうみる？
短期 = 「いま」何が起きているか
○ 分単位、〜数日
○ 時代は準リアルタイム（秒単位）へ

View Slide

72
重要度
Lambdaのログレベル方針について、チームで話して明
文化してみた | Developers.IO
https://dev.classmethod.jp/articles/lambda-log-level/

View Slide

73
So, since when?
(で、いつから？)

View Slide

74
前提：監視とは
“監視とは継続的なテストである”
- 監視とは継続的なテストである、という話 (もしくは
cronlog とテストスクリプトを組み合わせた監視手法につい
て)
- https://planet.mysql.com/entry/?id=23085
“監視とは、あるシステムやそのシステムのコンポーネ
ントの振る舞いや出力を観察しチェックし続ける行為で
ある。”
- 入門「監視」

View Slide

75
いつから取り始めればよい？
“世界中のディベロッパーの42%以上が、
開発ライフサイクルにおけるテストのタイミングが
遅すぎると回答”
- DevSecOpsに関するグローバルアニュアル調査の
結果を発表：ソフトウェア開発チームの役割の
変化が明らかに｜GitLab Inc.のプレスリリース
https://prtimes.jp/main/html/rd/p/000000003.000056974.html

View Slide

76
いつから取り始めればよい？(cont.)
(再掲)正常な判断のためには、なんでもかんでもデー
タを見る必要はない、見る意味のあるデータについてだ
け観れば良い
● そのためには、「見る意味があるものは何か？」を
知る必要がある
○ 大量のデータをみておく必要性

View Slide

77
いつから取り始めればよい？(cont.)
予め「取れるだけとっておく」ことが大切
○ あとから「あれを見ておけばよかった」となった時のこ
とを考えておく
○ 観測コストも保存コストも、年々安くなっている
○ ※法的な保存期間についての議論はまた別の話
それが判断できるのはいつか？本番稼働後でいい？
○ 開発段階でも有効な情報が得られるのでは？
○ そもそも、運用と開発を明確なフェーズに分けられる時
代じゃないですよね？
→可観測性を高めるため、計測できる状態に作り上げる

View Slide

78
W-Aによる言及
“ワークロードを設計する際には、すべてのコンポーネ
ントにわたって内部状態 (メトリクス、ログ、トレース
など) を理解するために必要な情報が送出されるように
します。これにより、適時に必要な応答を提供できる
ようになります”
- Well-Architected 「運用上の優秀性」
設計段階から用意しましょう
https://aws.amazon.com/jp/blogs/news/aws-well-architected-whitepaper/

View Slide

79
(再掲)「監視エージェント入れたら性能下がりました^^」
● 本末転倒、ミイラ取りがミイラ
● 二度と入れたくならない

View Slide

80
(再掲)「監視エージェント入れたら性能下がりました^^」
ベースとなる性能の設定（基準）がおかしい
エージェント込みで性能評価する必要
● 計測している状態が基準
計測していない状態はただの追い風参考記録
○ 安全装置はずして世界記録だして楽しいですか？
そのためには最初からエージェントを前提に
「計器のない車はありえない」
※影響を減らすための工夫の仕方はあります（後述）

View Slide

81
本日のまとめ

View Slide

82
まとめ
SREはMonitoringする生き物
SLI/SLOを計測する
計測（エージェントの組み込み）は最初から

View Slide

83
Q
大量の情報を
最初から取ってると
どうなる？

View Slide

84
A
あふれます
続きはその2で！
https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/

View Slide

85

View Slide

監視・ログ分析を最初から始めるイマドキの事情と理由・その1（混乱編）

監視・ログ分析を最初から始めるイマドキの事情と理由・その1（混乱編）

Seigo Watanabe

More Decks by Seigo Watanabe

Other Decks in Technology

Featured

Transcript