アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai

by hideki kinjyo

Slide 1

Slide 1 text

アプリケーションエンジニアこそ   「監視」だよね！   と私が考える訳 PHPカンファレンス関西2024 Hideki Kinjyo GitHub: o0h / X: @o0h_ [配布版]

Slide 2

Slide 2 text

今日はちょっと監視の話をしていきますよ • というイメージで話していきます • 優しい気持ちで、リラックスして聞いてもらえればな〜という気持ち • なるべく小難しい話は避けたつもりです！！！

Slide 3

Slide 3 text

それではそれでは

Slide 4

Slide 4 text

とっても優しい監視の話

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

ここから何かを読み取るのが大事ですどう思います？

Slide 7

Slide 7 text

ほら、色々書いてある。色々分かるじゃろ？

Slide 8

Slide 8 text

ここから何かを読み取るのが大事です障害？攻撃？バグ？？ブツリ・ブッコワレ？オペミス？え、やっぱり問題ないの？

Slide 9

Slide 9 text

「監視」って何か怖いもの   ・・・かも知れない？

Slide 10

Slide 10 text

何となくのイメージ─── • ベテランや“長”が活躍している • 「インフラの人」がやってるもの • 異常の発生や問題を見つけるのに役立つ、だけど   (問題が起きてﾃﾝﾔﾜﾝﾔを連れてくる・・・

Slide 11

Slide 11 text

「とっつきにくい」「聖域」   「しゃしゃり出ても邪魔になりそう」みたいな印象を持っていたりしませんか？   (私はそんな事を言われた経験があります！)

Slide 12

Slide 12 text

まとめ

Slide 13

Slide 13 text

お話したすることのまとめ • 監視に興味を持つことで、   もっとアプリケーションやサービス開発を好きになれる！！はず • 監視に手を染めて、   開発者としての成長曲線に角度をつけていきましょう！！ • 単なる数字やデータを眺めるのではなく、   「物語」として捉える想像力を養おう！

Slide 14

Slide 14 text

自己紹介 • 金城秀樹 / きんじょうひでき • GitHub:@o0h / Twitter:@o0h_ • 好きなFWはCakePHP • アイコンは   美味しい鮭親子丼の写真です

Slide 15

Slide 15 text

おしながき 1.監視って何なのさ 2.どういうことしてるの？ 3.本当はアプリケーションの知識が必要だぜ！！！ 4.アプリケーションエンジニアこそ「監視」だよね！と私が考える訳

Slide 16

Slide 16 text

§1 監視って何なのさ

Slide 17

Slide 17 text

例えばさっきの図

Slide 18

Slide 18 text

例えばさっきの図 CPUの使用率が・・メモリが減ってる・・意外とリクエストは増えてない・・・・？？ appエラーってよりリクエストが変？

Slide 19

Slide 19 text

例えばさっきの図 CPUの使用率が・・メモリが減ってる・・意外とリクエストは増えてない・・・・？？ appエラーってよりリクエストが変？色々と分かって嬉しいね！！

Slide 20

Slide 20 text

色々と分かる ≒ 何も分からない • ただ「雑多に集めただけ」のデータは、何も語ってくれません • 使えないデータは存在しないに等しい • 参考: データと情報の違い https://ja.wikipedia.org/wiki/データ • 「数字」の裏にある「なぜ？」を想像するためのデータ収集 • 「物語」を読み取れるか？が、監視と仲良くなるためのポイント！！

Slide 21

Slide 21 text

例えば • かぼちゃについて考えてみましょう • 「かぼちゃの監視」は、みなさんにとっても身近な題材です [イラスト出典]ゆるかわいい無料イラスト素材集 | いらすとん https://www.irasuton.com/2013/02/blog-post_5475.html

Slide 22

Slide 22 text

「かぼちゃを監視する」(例え話) かぼちゃの「状態」を表すのには、どんな項目があるでしょう？ • 匂い • 味 • 形 • 黄色さ • 大きさ • 重さ • 糖度 • 収穫後日数 • 水分量 • 感触 • 弾力 • カロリー

Slide 23

Slide 23 text

「かぼちゃを監視する」(例え話) あなたなら、   どの項目で「南瓜信頼性Pumpkin-Reliability」を測る！？ • 匂い • 味 • 形 • 黄色さ • 大きさ • 重さ • 糖度 • 収穫後日数 • 水分量 • 感触 • 弾力 • カロリーかぼちゃの「状態」を表すのには、どんな項目があるでしょう？

Slide 24

Slide 24 text

「かぼちゃの提供による価値実現」(例え話) 何を提供したいか？によって重要な項目が変わります • スーパーや八百屋で販売する • 売れやすい・食事に使いやすさに紐づくのは？(味・経過日数かなぁ • 絵画や写真の素材として提供したい • 映えるかぼちゃとは？(色や形かもね • 販売者目線でなく、調理者として食べ頃を知りたい • 「かぼちゃの不吉な臭い」を気にしておけば、まずハズレを除外できそうだ目的が違うはずだよね！

Slide 25

Slide 25 text

なぜ監視を行うのか × インフラ(etc)を監視する？ • じゃあ「運用の人」「インフラの人」のミッションなのか・・？

Slide 26

Slide 26 text

なぜ監視を行うのか × インフラ(etc)を監視する   ◯ 「ユーザーがちゃんと使えているか」を監視する • アプリケーション開発者は「動くもの」を作りますよね？ • 監視は「作ったものがちゃんと使えるか」を気にする行為 • (目指しているところは同じですよね

Slide 27

Slide 27 text

なぜ監視を行うのか • システムの提供したい「目的」を果たせているか？を監視する • 「CPU使用率」や「全APIの平均返答時間」を一生懸命眺めても・・ • これらのデータ自体には、意味が生まれにくい • こうした項目を理解すること！！！が、「監視を始める一歩」ではない • 「いま使っているユーザーに何が起きている？」という物語   にこそ価値がある • 「サーバーの処理が追いつかなそう」   「いつもは早い応答が鈍っている」ことに気づくことが必要 • 数値や変化を可視化したら、その意味(=影響)を考える

Slide 28

Slide 28 text

§2 どういうことしてるの？

Slide 29

Slide 29 text

Webサービスって複雑・・ [イラスト出典]かわいいフリー素材集いらすとや https://www.irasutoya.com/

Slide 30

Slide 30 text

「お〜い！ページ表示が重いよ〜！」ユーザーの声って簡単・・ [イラスト出典]かわいいフリー素材集いらすとや https://www.irasutoya.com/

Slide 31

Slide 31 text

「お〜い！ページ表示が重いよ〜！」ユーザーの声って簡単・・ => ここから「なぜ」を紐解いていくための視点が必要

Slide 32

Slide 32 text

だから分解して考える E2E 外形/死活監視ネットワークアプリケーションサーバー/サービス   OSメトリクス連携コンポーネント対抗先システム   疎通監視

Slide 33

Slide 33 text

分解して考えると・・・ • 1つ1つは凄く単純なデータになる • 変化の有無、量が判断しやすい • 「重かったり、動きが変になっているのはどこ？」の目線 • コンポーネントでの分解 • アプリケーションサーバー？データベース？ストレージ？etc • 範囲での分解 • 全体？特定ページやユーザー？ • 最大値の異常？平均？最小？

Slide 34

Slide 34 text

たとえば「何のデータ」を集めるか？   〜監視対象ってどんなものがあるの〜

Slide 35

Slide 35 text

よく使う監視①: OSのメトリクス • OSの機能やハードウェア的なところの監視 • CPU使用率とかメモリ使用量とかディスク残量とかサーバー/サービス   OSメトリクス連携コンポーネント

Slide 36

Slide 36 text

よく使う監視②: ネットワークのメトリクス • コンポーネントがどのくらいのやりとりをしているか • リクエスト数とか転送量とかスループット(時間当たりの転送量)とか • レスポンスのHTTPステータスとか「タイムアウト」数とか接続数とかも見れたりするかもネットワーク

Slide 37

Slide 37 text

よく使う監視③: アプリケーション監視 • アプリケーションが正常(期待する／許容範囲の)動きをしているか • ログ数とかエラー数とか処理完了時間とかアプリケーション

Slide 38

Slide 38 text

よく使う監視④: 外形監視 • サービスの外から見て、機能が動いているか • 例えば「どっかのサーバーからトップページにアクセスして、一定時間以内に応答して、指定した文字列(jsonでもHTMLでも)が含まれているか」をみたり外形/死活監視

Slide 39

Slide 39 text

よく使う監視⑤: RUM/EndToEnd/サービス監視 • 「実際にサービスを使っている人のデータ」を集めるもの • JSのSDKを埋め込んで、パフォーマンスやエラーのデータを収集するものもあるし • Google Analyticsみたいな解析ツールを使うこともあるし • 「ログイン数」「注文数」とかのサービス利用状況を見たりも E2E

Slide 40

Slide 40 text

覚えること色々ある？   (同時に全部を考えているのか・・？)

Slide 41

Slide 41 text

複雑さにどう立ち向かうか？というのが大事 • 組み合わせるから「複雑」が生まれる • ある要素が、それ以外の要素に対して反応する関係性／作用が生まれる • 「DBが重くなって、レスポンスも遅くなっている」 • 単純と複雑を行き来しながら、物語を語れると勝ち！ • いま起きている問題は何？どこで？を考えて、その発生要因をつきとめる！ • 「DBが重くなったのは、CPU負荷が上がったからっぽい」   「リクエストや接続数の増加はない」「実行時間が長いクエリが増えている」   「さっき複雑な集計機能を出したからだ！」

Slide 42

Slide 42 text

例えばなんかCPU使用率が上がったらしい！ "QQ$16

Slide 43

Slide 43 text

例えば "QQ$16 リクエスト数も増えてた！！ ϦΫΤετ਺

Slide 44

Slide 44 text

例えば "QQ$16 じゃあ、普通っちゃ普通か！ ϦΫΤετ਺

Slide 45

Slide 45 text

例えば "QQ$16 まだ限界までは余裕ある => ならヨシ！！ ϦΫΤετ਺

Slide 46

Slide 46 text

例えば② サーバーの応答が遅くなっているみたい・・ -#ϨΠςϯγʔ

Slide 47

Slide 47 text

例えば② なんかDBの負荷が上がってる！ 3%#సૹྔ -#ϨΠςϯγʔ

Slide 48

Slide 48 text

例えば② アプリサーバーの負荷は変わってないっぽいな〜 3%#సૹྔ "QQ$16 -#ϨΠςϯγʔ

Slide 49

Slide 49 text

例えば② (アプリサーバーの仕事量が変わってないのに重くなってるのか〜) 3%#సૹྔ "QQ$16 -#ϨΠςϯγʔ

Slide 50

Slide 50 text

例えば② キャッシュの利用失敗(存在しなかった)が上がってる〜！ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ

Slide 51

Slide 51 text

例えば② キャッシュの生成が間に合っていないとか、ロジック変わったとか？ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ

Slide 52

Slide 52 text

例えば② 遅いページを調べてみたら、ランキングの奥深くだったぞ TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD

Slide 53

Slide 53 text

例えば② (ほとんどのユーザーが見ないページだから、気にしすぎなくて良いかな〜) TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD

Slide 54

Slide 54 text

例えば② TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD TVUFLJQSPEVDUSBOLJOH QBHF TFD コレを踏まえた監視としては・・ • 応答速度について、   「トップページの基準」と「サイト全体の基準」を分けよう • トップページ = どんなユーザーにも影響を与える箇所(の例) • トップページは「サイト全体平均」よりも厳し目にする

Slide 55

Slide 55 text

考えるヒント • 「HTTPのリクエストが、どこから来てどこを通るのか？」の   イメージを持てていると良いです • つながりで考えていくこいつに注目！

Slide 56

Slide 56 text

§3 本当は   アプリケーションの知識が必要だぜ！！！

Slide 57

Slide 57 text

Webサービスって複雑・・

Slide 58

Slide 58 text

「お〜い！ページ表示が重いよ〜！」ユーザーの声って簡単・・

Slide 59

Slide 59 text

「知っていること」が異なる • 「どういう機能があり、どういうデータを使っているか」は   アプリケーションの中にあるロジックによって決められているもの • 「mypageの下にある“興味のあるラーメン屋リスト”って、どう作ってるの？」 • 「どういうデータを」≒ 「どういうコンポーネントを」につながる • RDBなのか、キャッシュなのか、アプリケーション側で集計をしているのか

Slide 60

Slide 60 text

「知っていること」が異なるキャッシュの生成が間に合っていないとか、ロジック変わったとか？ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ

Slide 61

Slide 61 text

「知っていること」が異なるキャッシュの生成が間に合っていないとか、ロジック変わったとか？ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ ここにピンと来て、判断をしに行くのは   「ロジックを作っている人」の方が有利と言える

Slide 62

Slide 62 text

監視におけるアプリケーションの貢献 • アプリケーションのロジックが、複雑さに与えている影響は大きい • 「このクエリなんですか？」「それは、◯◯のページです」 • つまり、機能を作った人が   「これはこういう負荷をかけるかも」   「正常な動作をしていれば、そんなに負荷が上がるはずは・・？」   という予見を持てると最高になれるという話に • 設計・実装の予見 • リリース後、障害発生時の分解・掘り下げ

Slide 63

Slide 63 text

すなわち・・ • ←の人の「お〜い！」を分解するのは、みんなでやろう • アプリケーションの中身を知っている人は、   そこから「物語」を紐解くところに貢献しやすい • 良い監視は、良い「物語の想像力」から・・

Slide 64

Slide 64 text

§4 アプリケーションエンジニアこそ   「監視」だよね！と私が考える訳

Slide 65

Slide 65 text

監視★マインド • アプリケーションを作っている時に、   「動くものを」「役に立ちますように」の気持ちがあるはず • デプロイした後、運が良ければ予想通りに動くかも知れないし、   運が悪ければ動かなかったり問題を引き起こしたりする • 「動くコードを書く」のと「書いたものが動くか見届ける」のは   非常に近い領域の話ではないかな、と考えます • しかも、それを他の人よりも上手くやれる可能性が高いんだぜ・・・とも  

Slide 66

Slide 66 text

「次の1歩」に★オススメ • 「最近、コードを書けるようになってきた気がするぞ」   「フレームワークを使えるようになった」みたいな感覚があるな〜〜という、そこのあなた！ • 次に進む1歩として、監視は結構おすすめできます • 決して「インフラ領域の専門性を身に着けよう！！」みたいなハードルが高い話ではないのです

Slide 67

Slide 67 text

「次の1歩」に★オススメ • 「インフラ系の知識」という意味では、↓の要素は抑えましょう • どうしたらCPUの利用率が上がるのか • どんな処理をしたら、メモリを消費するのか • ネットワーク越しのデータ量(転送量)って？ • が！！   結局これは「ロジックの書き方」「データの扱い方」と直結するもの • 言い換えると、あんまりｲﾝﾌﾗｲﾝﾌﾗしていなくても、身につけたいことです

Slide 68

Slide 68 text

技術的な刺激、成長★チャンス • 普段から「監視」の目線を持って開発ができたら・・・ • 例えば「遅くないクエリを書く」とか「正常/異常の見分けが付きやすいようにログを出す」とかの意識が持てるようになっていって • 自分が書くコードについて、考える視点が増える。   多角的に捉えて(セルフ)フィードバックを出せるようになる • すなわち、「良いコード」について考える物差しが増える！ • 「数字」や「結果」が判別しやすいので、手応えにつながる！

Slide 69

Slide 69 text

まとめ

Slide 70

Slide 70 text

お話したことのまとめ • 監視に興味を持つことで、   もっとアプリケーションやサービス開発を好きになれる！！はず • 監視に手を染めて、   開発者としての成長曲線に角度をつけていきましょう！！

Slide 71

Slide 71 text

お話したことのまとめ • 単なる数字やデータを眺めるのではなく、   想像力を持って、「物語」として捉えることで   監視は怖いものではなくなるはずだ・・・！というお話でした

Slide 72

Slide 72 text

自分が作ったものに胸張りたくない？ • せっかく一生懸命書いたコード、   ちゃんと動いているな〜ユーザーに使ってもらえているな〜〜   っていうところまで、自分で見届けられた方が   きっとアプリケーション開発は楽しくなると思っています！！ • やっていきましょう！

Slide 73

Slide 73 text

このトークで、   「監視って大事そうだな」   「自分にもできることがありそうだ」   「やっていきたいな！！」   と感じる人が増えてほしい〜〜

Slide 74

Slide 74 text

おしまい！お付き合いいただきありがとうございました!!

Slide 75

Slide 75 text

Appendix

Slide 76

Slide 76 text

参考書籍 • 個人的に、非常に強い影響を受けてるのが「入門監視」です • 「ユーザー目線の監視」を始め、監視についての自分のコアになる概念をいくつも提供されました • 「ユーザー目線の監視」「アラートは誰かを叩き起こすもの」「監視はスキル」などが、特に好きな概念 • 今回の発表よりは少し難しい(監視の実戦経験がある初級者〜なイメージ)かも知れませんが、文量も多すぎずとっつきやすい1冊だと思います “ հ “ “ “ 入門監視 ―モダンなモニタリングのためのデザインパターン   オライリージャパン   Mike Julian (著), 松浦隼人 (翻訳)

Slide 77

Slide 77 text

関連資料監視周りで、自分が過去に発表した内容も貼っておきます   (必ずしも、今回の発表と対象者が同じものではありません) • 入門入門監視 (2019) https://speakerdeck.com/o0h/reading-practical-monitoring • やさしい監視ミートアップ vol.1 (2019) https://speakerdeck.com/o0h/monitoring-at-ease • 関連記事: https://tech.connehito.com/entry/monitoring-at-ease • やさしい監視ミートアップ vol.2 (2019) https://speakerdeck.com/o0h/monitoring-at-ease-2 • 監視と平和 (2019) https://speakerdeck.com/o0h/practical-monitoring-for-server-side-devs • エラーと向き合い、自信を持ってサービス開発に取り組み、前に進む (2022) https://speakerdeck.com/o0h/phpcon-2022 • 関連記事: https://daisuki.nichiyoubi.land/entry/2020/07/01/123616