ペパボのオブザーバビリティ研修2024 説明資料

GMOペパボ株式会社における2024年の新卒技術研修の一つ「オブザーバビリティ研修」の説明用資料です。
https://tech.pepabo.com/2024/07/23/o11y-training-2024/ に研修内容の詳細や研修の設計意図などを記載しています。ぜひ合わせてお読みください。

Transcript

1. 1 オブザーバビリティ研修 社外公開版 2024年ペパボ新卒技術研修
2. 2 • 研修担当者と研修受講者の顔合わせ • 受講者がオブザーバビリティ研修の進め⽅を把握する • 受講者がオブザーバビリティ技術の概要を理解するこ とで、⼿を動かす準備ができる この会の⽬的
3. 3 アジェンダ 1. この会の⽬的 2. 事務連絡 3. オブザーバビリティについて 3.1. オブザーバビリティの重要性 3.2. テレメトリー 3.2.1. メトリクス 3.2.2. ログ 3.2.3. トレース 3.3. 監視
4. 4 こんにちは 技術部プラットフォームグループ 2022年 新卒⼊社 染⽮健⼈ Someya Kento • よく使うIDは @kesompochy • 業務ではSREな活動が多いです • Bunが好きです • 得意技ははかいこうせんです
5. 事務連絡（社外公開⽤に省略） 5 研修の進め方の説明や、タイムスケジュールの確認などをする
6. 本編 6
7. オブザーバビリティ 7
8. オブザーバビリティの概要 8 - オブザーバビリティ - Observability - O11y - ｵﾌﾞｻﾞｰﾊﾞﾋﾞﾘﾃｨ - 可観測性 - かかんそくせい 呼ばれ⽅はいろいろ
9. オブザーバビリティの概要 9 - 制御⼯学においては、システムの外部出⼒からシステムの内部状態を 推測できる度合い - 現代のWebシステムにおいても同じ - 具体的には - コードを変更せずともデバッグができるかどうか - 異常の調査を⾏き詰まることなくやり切れるかどうか - システムがどんなに斬新で奇妙な状態であってもその状態を正確 に説明できるかどうか オブザーバビリティとは？
10. オブザーバビリティの概要 10 - 「テレメトリー」を収集、調査できるようにする - テレメトリーとは、システムの状態を外部に保存するための情報 - テレメトリーが⼗分に収集できていて、かつそのテレメトリーを調査 できる状態であれば、オブザーバビリティが⾼いと⾔えるだろう オブザーバビリティを⾼めるためには？
11. オブザーバビリティ はなぜ重要？？ 11
12. ケーススタディ 12 想像してみてください
13. ケーススタディ 13 あなたはエンジニアとして サービスに配属されました
14. ケーススタディ 14 そこで出会うのは
15. ケーススタディ 15 社外公開用マスク 実際に動いているサービスの 詳細な構成図 「複数のシステムが複雑に絡み合っている」 ということを伝えたい。
16. ケーススタディ 16 社外公開用マスク 実際に動いているサービスの詳細な構成図 その２ とにかく巨大で、初見では絶対に太刀打ちできないと感じてもらいたい。 この構成図はすでに現実に追いついていないことも説明しながら、 最新ドキュメントあるある「 ない」を紹介する。
17. ケーススタディ 17 巨⼤で⼊り組んでいて変化しつづける建築物 サグラダ‧ファミリア
18. ケーススタディ 18 あっアラートが鳴った！
19. ケーススタディ 19 経験豊富な先輩は直感で対処している
20. ケーススタディ 20 「このアラートが出たときは あの辺を再起動したら直りがち」
21. ケーススタディ 21 あなた「なるほど（わからん）」
22. ケーススタディ 22 先輩、退職
23. ケーススタディ 23 エンジニアの寿命はシステムの寿命より短い
24. ケーススタディ 24 あっまたアラートが鳴った！
25. ケーススタディ 25 あなたには先輩のような勘は備わっていない ドキュメントは更新されていない テレメトリーは収集されていない
26. ケーススタディ 26 さあ、どうする？
27. ケーススタディ 27 （ケーススタディ終わり）
28. オブザーバビリティはなぜ重要？ 28 - エンジニアの寿命はシステムの寿命よりも⻑い - システムやサービスの終了よりもエンジニアの退職の⽅が起きがち - 経験や勘によるデバッグ能⼒は組織として持続可能ではない - オブザーバビリティが低いシステムにおいて、最⾼のデバッガーは組織の中で 最も経験豊富なエンジニア - オブザーバビリティが⾼いシステムにおいて、最⾼のデバッガーは組織の中で 最も好奇⼼が強いエンジニア 暗黙知に頼らないデバッグ
29. オブザーバビリティはなぜ重要？ 29 - 単純モノリスなアーキテクチャなら問題が起きがちな箇所は限られる - クラウドネイティブで複雑なアーキテクチャだと⼤変 - コンテナは⼤量に⽣まれたり死んだりする - 複数のマイクロサービス同⼠が通信しあう - イミュータブルなインフラにはデバッグのための変更を加えにくい - 複雑なシステムのデバッグのために、外部から調査可能なデータがほしい 現代のシステムは複雑すぎる
30. オブザーバビリティはなぜ重要？ 30 - SRE（Site Reliability Engineering） - サービスの品質をエンジニアリングする - SREingではシステムが出す複数の指標を⽤いながらエンジニアリング が⾏われる - つまり、SREingを実践するためには⾼いオブザーバビリティが必要 SREの成熟
31. オブザーバビリティはなぜ重要？ 31 - システムの外部出⼒からシステムの内部状態を推測できる度合いがオ ブザーバビリティ - 現代におけるWebシステムの開発‧運⽤では⾼いオブザーバビリティ の実現が必要 オブザーバビリティまとめ
32. 可観測性ツール 32
33. 可観測性ツール 33 - ペパボで使っているのは次のもの - SaaS - Datadog - New Relic - Mackerel - OSS - Grafana - SaaS版も提供されている 世の中にはたくさんのオブザーバビリティツールがある
34. 可観測性ツール 34 - 多機能な可観測性ツールを提供するSaaS - ログ - APM - メトリクス - クラウドセキュリティ - などなど - パブリッククラウドとの統合も可能 Datadog
35. 可観測性ツール 35 - APM（アプリケーションパフォーマンスマネジメント）に強みを持つ SaaS - APM ≒ トレース New Relic
36. 可観測性ツール 36 - ホスト管理、メトリクス収集、監視に強みを持つSaaS - プラグインが作りやすい - Mackerelは英語で鯖 Mackerel
37. 可観測性ツール 37 - オープンソースの可視化ツール - 複数のデータソースにデータを問い合わせてダッシュボードを作れる - エコシステムが豊富 - この研修ではGrafanaとその周辺プロダクトを使います Grafana
38. テレメトリー 38
39. オブザーバビリティの概要 39 - 「テレメトリー」を収集、調査できるようにする - テレメトリーとは、システムの状態を外部に保存するための情報 - 質の⾼いテレメトリーが⼗分に収集できていて、かつそのテレメト リーを調査できる状態であれば、オブザーバビリティが⾼いと⾔える だろう オブザーバビリティを⾼めるためには？（再掲）
40. テレメトリー 40 - 「メトリクス」「ログ」「トレース」がよく収集対象になるテレメト リーである - 英語の単複を統⼀するなら「メトリック」「ログ」「トレース」あるいは「メトリクス」「ログス」「トレーシーズ」で は......？ - メトリクス: 定量的に表せるデータ - ログ: テキストとして表現されるデータ - トレース: 処理の順番や経過時間を追跡したデータ 主要なテレメトリー
41. メトリクス 41
42. メトリクス 42 - システムが出⼒する定量データ - 定期的に収集され、時系列データとして表されがち - 具体例 - マシンのCPU使⽤率 - リクエスト数 - キャッシュヒット率 メトリクスとは
43. メトリクス 43 - Prometheusはオープンソースのメトリクス収集‧アラート管理ツール - 指定したエンドポイントをスクレイプしてメトリクスを収集する - いわゆる「pull型」 - 対義語は「push型」 Prometheus
44. メトリクス 44 - Prometheusが収集したデータはPromQLという⾔語で調査できる - 例えば、「namespaceごとのreadyなpodの数」を⾒たいときは `sum(kube_pod_container_status_ready) by (namespace)` PromQL
45. ログ 45
46. ログ 46 - システムが出⼒するテキストデータ - たとえば - エラーログ - プログラムでエラーが発⽣したときにエラー内容などを出⼒する - アクセスログ - システムへのアクセスが発⽣したときにアクセス元情報などを出⼒する - 監査ログ - システム内で何かの作業が⾏われたときに作業者や作業内容などを出⼒する ログとは
47. ログ 47 - 構造化されているとシステムが機械的に情報を扱えるようになるので調査が捗る - 現代だとLLMによって⾮構造化ログも効率的に扱えるかも - JSON形式やlogfmt形式での構造化がよく使われる - ⾮構造化ログの例 - 構造化ログの例 - key=valueの連続構造 - パースしやすい ログの構造化 14:30:15 User john.doe logged in from 192.168.1.100 4:30:20 Basic authentication accepted by user john.doe 14:30:27 Request succeeded response_time=0.5s time=14:30:15 event=login user=john.doe ip=192.168.1.100 time=14:30:20 event=auth method=basic user=john.doe time=14:30:27 event=request status=success response_time=0.5s
48. ログ 48 - Lokiはオープンソースのログ収集‧検索ツール - Prometheusの開発者や周辺コミュニティによって作られた - Promtailがログを収集し、backendのLokiに送信される - PromQLと同様にLogQLという⾔語でクエリする Loki
49. トレース 49
50. トレース 50 - 処理の呼び出し順番や処理にかかった時間を追跡したデータ - たとえば - HTTPリクエストからレスポンスまで、内部でどのような処理が実⾏され、それぞ れ何秒かかったのか？ - プログラムでエラーが発⽣した際に、どのような順番で関数が呼び出されたの か？ トレースとは
51. トレース 51 - 複数の分かれたサービス間での⼀連の処理を追跡したもの - マイクロサービスだと、分散トレースがあると便利 - 裏を返して、分散トレースがない世界を想像してみよう - サービスAの対象トレースを探し、 - サービスBのトレース⼀覧を眺め、 - サービスBのトレースをサービスAの対象トレースの時刻と突合して... - たぶんこのトレースとこのトレースが⼀連だ（と思う） 分散トレース
52. 52 社外公開用マスク 実際に動いているサービスで マイクロサービス間の分散トレースが収集できており、 それをGrafanaで可視化できている様子
53. OpenTelemetry 53
54. OpenTelemetry 54 - オブザーバビリティ技術を標準化するためのオープンなプロジェクト - メトリクス、ログ、トレースの収集‧処理‧送信⽅法を標準化している - どの⾔語でも同じプロトコルでテレメトリーを扱える - 特定のベンダーへの依存性が減る - 現在、トレースの実装は主要な⾔語でStableになっている OpenTelemetryとは
55. OpenTelemetry 55 - アプリケーションがそれぞれ 計装（Instrumentation）する - 計装されたテレメトリーを OTel Collectorに送信する - OTel Collectorを使わないこともできる - OTel Collectorが処理したデータを 任意のBackendにExportする OpenTelemetry概略
56. 監視 56
57. 監視 57 - 対象を継続的に観察し、意図していない状態になっていないかどうかを確 認すること - たとえば - 外形監視 - https://pepabo.comにGETリクエストを投げて1秒以内に200が返るか？ - メトリクス監視 - ホストマシンのCPU使⽤率が90%を超えないか？ - ログ監視 - “Error”を含むログが出ないか？ 監視とは
58. 監視 58 - monitoringとobservabilityはしばしば対として語られがち - monitoringは、既知の未知に素早く対処するためのリアクティブなアプ ローチ - observabilityは、未知の未知に対処するためのプロアクティブなアプロー チ 監視とオブザーバビリティ
59. 監視 59 - ツール依存 - 監視を⽀えにする - 監視を「ロール」として扱う - 偽陽性アラート - 作ってそのまま - ユーザーのことを考慮しない監視 アンチパターン
60. 監視 60 - 「このツールを⼊れればすべて解決します！」 - 銀の弾丸はない - ⼿段ではなく⽬的を考えよう アンチパターン -ツール依存-
61. 監視 61 - 「監視を⼊れてるから何かあれば気づけるね！」 - 検知に⼒を⼊れるより、修復に⼒を⼊れるべき アンチパターン -監視を⽀えにする-
62. 監視 62 - 「このチームではあなたが監視役ね！」 - 監視は役割ではなくスキル - 全員が⼤まかにでも監視スキル、ｵﾌﾞｻﾞｰﾊﾞﾋﾞﾘﾃｨスキルがあってほしい アンチパターン -監視という役割-
63. 監視 63 - 「とりあえず気付きたいから全部Criticalな通知だ！」 - なんでもかんでもアラートとして通知すると、疲れる - オオカミ少年の寓話 - 本当に重⼤な通知を⾒逃す可能性が⾼まる アンチパターン -偽陽性アラート-
64. 監視 64 - 作って放置ではなく継続的に改善しよう - 不要なアラートの削除とか - 閾値の調整とか アンチパターン -作ってそのまま-
65. 監視 65 - 監視は、サービスの信頼性を⾼めるために実装する - 最終的にはユーザーの体験をよくするため - ユーザーから遠い位置の指標より、ユーザーに近い位置の指標を監視し たい - CUJ、SLI/SLOという考え⽅につながる アンチパターン -ユーザー視点の⽋落-
66. 総合演習 66
67. 総合演習 67 - 次のすべての内容を含むデモの発表を求めます！ - ⾃分のサービスを任意の⽅法で壊す - アクセスできない（可⽤性の問題） - エラーが出る（可⽤性の問題） - データがおかしい（完全性の問題） - ⾒えてはいけないデータが⾒える（機密性の問題） - サーバーに侵⼊された（機密性の問題） - 監視システムによってサービスが壊れたことを検知する - 向上した可観測性によって、壊れた原因を特定できる - 直す 総合演習を完成させよう！
68. おすすめの本 68 - 『オブザーバビリティ‧エンジニアリング』 - 2023年01月　Charity Majors、Liz Fong-Jones、George Miranda 著、大谷 和紀、山口 能迪　訳　オライリー・ジャパン - 『⼊⾨ 監視 ―モダンなモニタリングのためのデザインパターン』 - 2019年01月　Mike Julian 著、松浦 隼人 訳　オライリー・ジャパン - 『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性 を⽀えるエンジニアリングチーム』 - 2017年08月　Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy 編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔 監訳、Sky株 式会社 玉川 竜司 訳　オライリー・ジャパン 参考⽂献