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

PHPカンファレンス関西2024での発表資料です
https://fortee.jp/phpcon-kansai2024/proposal/42712995-5f3e-4c68-a951-39584eac95a1

Transcript

1. アプリケーションエンジニアこそ 
 「監視」だよね！ 
 と私が考える訳 PHPカンファレンス関西2024 Hideki Kinjyo GitHub: o0h / X: @o0h_ [配布版]
2. 今日はちょっと監視の話をしていきますよ • というイメージで話していきます • 優しい気持ちで、リラックスして聞いてもらえればな〜という気持ち • なるべく小難しい話は避けたつもりです！！！ 
3. それではそれでは
4. とっても優しい監視の話
6. ここから何かを読み取るのが大事です どう思います？
7. ほら、色々書いてある。 色々分かるじゃろ？
8.  ここから何かを読み取るのが大事です 障害？ 攻撃？ バグ？？ ブツリ・ブッコワレ？ オペミス？ え、やっぱり問題ないの？
9. 「監視」って何か怖いもの 
 ・・・かも知れない？
10. 何となくのイメージ─── • ベテランや“長”が活躍している • 「インフラの人」がやってるもの • 異常の発生や問題を見つけるのに役立つ、だけど 
 (問題が起きてﾃﾝﾔﾜﾝﾔを連れてくる・・・
11. 「とっつきにくい」「聖域」 
 「しゃしゃり出ても邪魔になりそう」 みたいな印象を持っていたりしませんか？ 
 (私はそんな事を言われた経験があります！)
12. まとめ
13. お話したすることのまとめ • 監視に興味を持つことで、 
 もっとアプリケーションやサービス開発を好きになれる！！はず • 監視に手を染めて、 
 開発者としての成長曲線に角度をつけていきましょう！！ • 単なる数字やデータを眺めるのではなく、 
 「物語」として捉える想像力を養おう！ 
14. 自己紹介 • 金城秀樹 / きんじょうひでき • GitHub:@o0h / Twitter:@o0h_ • 好きなFWはCakePHP • アイコンは 
 美味しい鮭親子丼の写真です 
15. おしながき 1.監視って何なのさ 2.どういうことしてるの？ 3.本当はアプリケーションの知識が必要だぜ！！！ 4.アプリケーションエンジニアこそ「監視」だよね！と私が考える訳
16. §1 監視って何なのさ
17. 例えば さっきの図 
18. 例えば さっきの図  CPUの使用率が・・ メモリが減ってる・・ 意外とリクエストは増えてない・・・・？？ appエラーってよりリクエストが変？
19. 例えば さっきの図  CPUの使用率が・・ メモリが減ってる・・ 意外とリクエストは増えてない・・・・？？ appエラーってよりリクエストが変？ 色々と分かって嬉しいね！！
20. 色々と分かる ≒ 何も分からない • ただ「雑多に集めただけ」のデータは、何も語ってくれません • 使えないデータは存在しないに等しい • 参考: データと情報の違い https://ja.wikipedia.org/wiki/データ • 「数字」の裏にある「なぜ？」を想像するためのデータ収集 • 「物語」を読み取れるか？が、監視と仲良くなるためのポイント！！ 
21. 例えば • かぼちゃについて考えてみましょう • 「かぼちゃの監視」は、みなさんにとっても身近な題材です [イラスト出典]ゆるかわいい無料イラスト素材集 | いらすとん https://www.irasuton.com/2013/02/blog-post_5475.html 
22. 「かぼちゃを監視する」(例え話) かぼちゃの「状態」を表すのには、どんな項目があるでしょう？ • 匂い • 味 • 形 • 黄色さ • 大きさ • 重さ • 糖度 • 収穫後日数 • 水分量 • 感触 • 弾力 • カロリー 
23. 「かぼちゃを監視する」(例え話) あなたなら、 
 どの項目で「南瓜信頼性Pumpkin-Reliability」を測る！？ • 匂い • 味 • 形 • 黄色さ • 大きさ • 重さ • 糖度 • 収穫後日数 • 水分量 • 感触 • 弾力 • カロリー かぼちゃの「状態」を表すのには、どんな項目があるでしょう？ 
24. 「かぼちゃの提供による価値実現」(例え話) 何を提供したいか？によって重要な項目が変わります • スーパーや八百屋で販売する • 売れやすい・食事に使いやすさに紐づくのは？(味・経過日数かなぁ • 絵画や写真の素材として提供したい • 映えるかぼちゃとは？(色や形かもね • 販売者目線でなく、調理者として食べ頃を知りたい • 「かぼちゃの不吉な臭い」を気にしておけば、まずハズレを除外できそうだ 目的が違うはずだよね！ 
25. なぜ監視を行うのか × インフラ(etc)を監視する？ • じゃあ「運用の人」「インフラの人」のミッションなのか・・？ 
26. なぜ監視を行うのか × インフラ(etc)を監視する 
 ◯ 「ユーザーがちゃんと使えているか」を監視する • アプリケーション開発者は「動くもの」を作りますよね？ • 監視は「作ったものがちゃんと使えるか」を気にする行為 • (目指しているところは同じですよね 
27. なぜ監視を行うのか • システムの提供したい「目的」を果たせているか？を監視する • 「CPU使用率」や「全APIの平均返答時間」を一生懸命眺めても・・ • これらのデータ自体には、意味が生まれにくい • こうした項目を理解すること！！！が、「監視を始める一歩」ではない • 「いま使っているユーザーに何が起きている？」という物語 
 にこそ価値がある • 「サーバーの処理が追いつかなそう」 
 「いつもは早い応答が鈍っている」ことに気づくことが必要 • 数値や変化を可視化したら、その意味(=影響)を考える 
28. §2 どういうことしてるの？
29. Webサービスって複雑・・ [イラスト出典]かわいいフリー素材集 いらすとや https://www.irasutoya.com/
30. 「お〜い！ページ表示が重いよ〜！」 ユーザーの声って簡単・・ [イラスト出典]かわいいフリー素材集 いらすとや https://www.irasutoya.com/
31. 「お〜い！ページ表示が重いよ〜！」 ユーザーの声って簡単・・ => ここから「なぜ」を紐解いていくための視点が必要
32. だから分解して考える E2E 外形/死活監視 ネットワーク アプリケーション サーバー/サービス 
 OSメトリクス 連携コンポーネント 対抗先システム 
 疎通監視
33. 分解して考えると・・・ • 1つ1つは凄く単純なデータになる • 変化の有無、量が判断しやすい • 「重かったり、動きが変になっているのはどこ？」の目線 • コンポーネントでの分解 • アプリケーションサーバー？データベース？ストレージ？etc • 範囲での分解 • 全体？特定ページやユーザー？ • 最大値の異常？平均？最小？ 
34. たとえば「何のデータ」を集めるか？ 
 〜監視対象ってどんなものがあるの〜
35. よく使う監視①: OSのメトリクス • OSの機能やハードウェア的なところの監視 • CPU使用率とかメモリ使用量とかディスク残量とか サーバー/サービス 
 OSメトリクス 連携コンポーネント 
36. よく使う監視②: ネットワークのメトリクス • コンポーネントがどのくらいのやりとりをしているか • リクエスト数とか転送量とかスループット(時間当たりの転送量)とか • レスポンスのHTTPステータスとか「タイムアウト」数とか接続数とか も見れたりするかも ネットワーク 
37. よく使う監視③: アプリケーション監視 • アプリケーションが正常(期待する／許容範囲の)動きをしているか • ログ数とかエラー数とか処理完了時間とか アプリケーション 
38. よく使う監視④: 外形監視 • サービスの外から見て、機能が動いているか • 例えば「どっかのサーバーからトップページにアクセスして、一定時 間以内に応答して、指定した文字列(jsonでもHTMLでも)が含まれてい るか」をみたり 外形/死活監視 
39. よく使う監視⑤: RUM/EndToEnd/サービス監視 • 「実際にサービスを使っている人のデータ」を集めるもの • JSのSDKを埋め込んで、パフォーマンスやエラーのデータを収集するも のもあるし • Google Analyticsみたいな解析ツールを使うこともあるし • 「ログイン数」「注文数」とかのサービス利用状況を見たりも E2E 
40. 覚えること色々ある？ 
 (同時に全部を考えているのか・・？)
41. 複雑さにどう立ち向かうか？というのが大事 • 組み合わせるから「複雑」が生まれる • ある要素が、それ以外の要素に対して反応する関係性／作用が生まれる • 「DBが重くなって、レスポンスも遅くなっている」 • 単純と複雑を行き来しながら、物語を語れると勝ち！ • いま起きている問題は何？どこで？を考えて、その発生要因をつきとめる！ • 「DBが重くなったのは、CPU負荷が上がったからっぽい」 
 「リクエストや接続数の増加はない」「実行時間が長いクエリが増えている」 
 「さっき複雑な集計機能を出したからだ！」 
42. 例えば なんかCPU使用率が上がったらしい！ "QQ$16 
43. 例えば "QQ$16 リクエスト数も増えてた！！ ϦΫΤετ਺ 
44. 例えば "QQ$16 じゃあ、普通っちゃ普通か！ ϦΫΤετ਺ 
45. 例えば "QQ$16 まだ限界までは余裕ある => ならヨシ！！ ϦΫΤετ਺ 
46. 例えば② サーバーの応答が遅くなっているみたい・・ -#ϨΠςϯγʔ 
47. 例えば② なんかDBの負荷が上がってる！ 3%#సૹྔ -#ϨΠςϯγʔ 
48. 例えば② アプリサーバーの負荷は変わってないっぽいな〜 3%#సૹྔ "QQ$16 -#ϨΠςϯγʔ 
49. 例えば② (アプリサーバーの仕事量が変わってないのに重くなってるのか〜) 3%#సૹྔ "QQ$16 -#ϨΠςϯγʔ 
50. 例えば② キャッシュの利用失敗(存在しなかった)が上がってる〜！ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ 
51. 例えば② キャッシュの生成が間に合っていないとか、ロジック変わったとか？ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ 
52. 例えば② 遅いページを調べてみたら、ランキングの奥深くだったぞ 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
53. 例えば② (ほとんどのユーザーが見ないページだから、気にしすぎなくて良いかな〜) 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
54. 例えば② 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD 
     TVUFLJQSPEVDUSBOLJOH QBHF TFD コレを踏まえた監視としては・・ • 応答速度について、 
 「トップページの基準」と「サイト全体の基準」を分けよう • トップページ = どんなユーザーにも影響を与える箇所(の例) • トップページは「サイト全体平均」よりも厳し目にする 
55. 考えるヒント • 「HTTPのリクエストが、どこから来てどこを通るのか？」の 
 イメージを持てていると良いです • つながりで考えていく こいつに注目！ 
56. §3 本当は 
 アプリケーションの知識が必要だぜ！！！
57. Webサービスって複雑・・
58. 「お〜い！ページ表示が重いよ〜！」 ユーザーの声って簡単・・
59. 「知っていること」が異なる • 「どういう機能があり、どういうデータを使っているか」は 
 アプリケーションの中にあるロジックによって決められているもの • 「mypageの下にある“興味のあるラーメン屋リスト”って、どう作ってるの？」 • 「どういうデータを」≒ 「どういうコンポーネントを」につながる • RDBなのか、キャッシュなのか、アプリケーション側で集計をしているのか 
60. 「知っていること」が異なる キャッシュの生成が間に合っていないとか、ロジック変わったとか？ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ 
61. 「知っていること」が異なる キャッシュの生成が間に合っていないとか、ロジック変わったとか？ 3%#సૹྔ "QQ$16 $BDIFϛε -#ϨΠςϯγʔ ここにピンと来て、判断をしに行くのは 
 「ロジックを作っている人」の方が有利と言える 
62. 監視におけるアプリケーションの貢献 • アプリケーションのロジックが、複雑さに与えている影響は大きい • 「このクエリなんですか？」「それは、◯◯のページです」 • つまり、機能を作った人が 
 「これはこういう負荷をかけるかも」 
 「正常な動作をしていれば、そんなに負荷が上がるはずは・・？」 
 という予見を持てると最高になれるという話に • 設計・実装の予見 • リリース後、障害発生時の分解・掘り下げ 
63. すなわち・・ • ←の人の「お〜い！」を分解するのは、みんなでやろう • アプリケーションの中身を知っている人は、 
 そこから「物語」を紐解くところに貢献しやすい • 良い監視は、良い「物語の想像力」から・・ 
64. §4 アプリケーションエンジニアこそ 
 「監視」だよね！と私が考える訳
65. 監視★マインド • アプリケーションを作っている時に、 
 「動くものを」「役に立ちますように」の気持ちがあるはず • デプロイした後、運が良ければ予想通りに動くかも知れないし、 
 運が悪ければ動かなかったり問題を引き起こしたりする • 「動くコードを書く」のと「書いたものが動くか見届ける」のは 
 非常に近い領域の話ではないかな、と考えます • しかも、それを他の人よりも上手くやれる可能性が高いんだぜ・・・とも 
 
66. 「次の1歩」に★オススメ • 「最近、コードを書けるようになってきた気がするぞ」 
 「フレームワークを使えるようになった」みたいな感覚があるな〜〜 という、そこのあなた！ • 次に進む1歩として、監視は結構おすすめできます • 決して「インフラ領域の専門性を身に着けよう！！」みたいなハードルが高い 話ではないのです 
67. 「次の1歩」に★オススメ • 「インフラ系の知識」という意味では、↓の要素は抑えましょう • どうしたらCPUの利用率が上がるのか • どんな処理をしたら、メモリを消費するのか • ネットワーク越しのデータ量(転送量)って？ • が！！ 
 結局これは「ロジックの書き方」「データの扱い方」と直結するもの • 言い換えると、あんまりｲﾝﾌﾗｲﾝﾌﾗしていなくても、身につけたいことです 
68. 技術的な刺激、成長★チャンス • 普段から「監視」の目線を持って開発ができたら・・・ • 例えば「遅くないクエリを書く」とか「正常/異常の見分けが付きやすいように ログを出す」とかの意識が持てるようになっていって • 自分が書くコードについて、考える視点が増える。 
 多角的に捉えて(セルフ)フィードバックを出せるようになる • すなわち、「良いコード」について考える物差しが増える！ • 「数字」や「結果」が判別しやすいので、手応えにつながる！ 
69. まとめ
70. お話したことのまとめ • 監視に興味を持つことで、 
 もっとアプリケーションやサービス開発を好きになれる！！はず • 監視に手を染めて、 
 開発者としての成長曲線に角度をつけていきましょう！！ 
71. お話したことのまとめ • 単なる数字やデータを眺めるのではなく、 
 想像力を持って、「物語」として捉えることで 
 監視は怖いものではなくなるはずだ・・・！というお話でした 
72. 自分が作ったものに胸張りたくない？ • せっかく一生懸命書いたコード、 
 ちゃんと動いているな〜ユーザーに使ってもらえているな〜〜 
 っていうところまで、自分で見届けられた方が 
 きっとアプリケーション開発は楽しくなると思っています！！ • やっていきましょう！ 
73. このトークで、 
 「監視って大事そうだな」 
 「自分にもできることがありそうだ」 
 「やっていきたいな！！」 
 と感じる人が増えてほしい〜〜
74. おしまい！ お付き合いいただき ありがとうございました!!
75. Appendix
76. 参考書籍 • 個人的に、非常に強い影響を受けてるのが「入門 監視」です • 「ユーザー目線の監視」を始め、監視についての自分のコアになる概 念をいくつも提供されました • 「ユーザー目線の監視」「アラートは誰かを叩き起こすもの」「監視はスキル」 などが、特に好きな概念 • 今回の発表よりは少し難しい(監視の実戦経験がある初級 者〜なイメージ)かも知れませんが、文量も多すぎずとっ つきやすい1冊だと思います “ հ “ “ “ 入門 監視 ―モダンなモニタリングのためのデザインパターン 
 オライリージャパン 
 Mike Julian (著), 松浦 隼人 (翻訳)
77. 関連資料 監視周りで、自分が過去に発表した内容も貼っておきます 
 (必ずしも、今回の発表と対象者が同じものではありません) • 入門 入門 監視 (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