Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

hideki kinjyo

February 11, 2024
Tweet

More Decks by hideki kinjyo

Other Decks in Programming

Transcript

  1. アプリケーションエンジニアこそ

    「監視」だよね!

    と私が考える訳
    PHPカンファレンス関西2024


    Hideki Kinjyo


    GitHub: o0h / X: @o0h_
    [配布版]

    View full-size slide

  2. 今日はちょっと監視の話をしていきますよ
    • というイメージで話していきます


    • 優しい気持ちで、リラックスして聞いてもらえればな〜という気持ち


    • なるべく小難しい話は避けたつもりです!!!

    View full-size slide

  3. それではそれでは

    View full-size slide

  4. とっても優しい監視の話

    View full-size slide

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

    View full-size slide

  6. ほら、色々書いてある。


    色々分かるじゃろ?

    View full-size slide


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

    View full-size slide

  8. 「監視」って何か怖いもの

    ・・・かも知れない?

    View full-size slide

  9. 何となくのイメージ───


    • ベテランや“長”が活躍している


    • 「インフラの人」がやってるもの


    • 異常の発生や問題を見つけるのに役立つ、だけど

    (問題が起きてテンヤワンヤを連れてくる・・・

    View full-size slide

  10. 「とっつきにくい」「聖域」

    「しゃしゃり出ても邪魔になりそう」


    みたいな印象を持っていたりしませんか?

    (私はそんな事を言われた経験があります!)

    View full-size slide

  11. お話したすることのまとめ
    • 監視に興味を持つことで、

    もっとアプリケーションやサービス開発を好きになれる!!はず


    • 監視に手を染めて、

    開発者としての成長曲線に角度をつけていきましょう!!


    • 単なる数字やデータを眺めるのではなく、

    「物語」として捉える想像力を養おう!

    View full-size slide

  12. 自己紹介
    • 金城秀樹 / きんじょうひでき


    • GitHub:@o0h / Twitter:@o0h_


    • 好きなFWはCakePHP


    • アイコンは

    美味しい鮭親子丼の写真です

    View full-size slide

  13. おしながき
    1.監視って何なのさ


    2.どういうことしてるの?


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


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

    View full-size slide

  14. §1


    監視って何なのさ

    View full-size slide

  15. 例えば さっきの図

    View full-size slide

  16. 例えば さっきの図

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

    View full-size slide

  17. 例えば さっきの図

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

    View full-size slide

  18. 色々と分かる ≒ 何も分からない
    • ただ「雑多に集めただけ」のデータは、何も語ってくれません


    • 使えないデータは存在しないに等しい


    • 参考: データと情報の違い https://ja.wikipedia.org/wiki/データ


    • 「数字」の裏にある「なぜ?」を想像するためのデータ収集


    • 「物語」を読み取れるか?が、監視と仲良くなるためのポイント!!

    View full-size slide

  19. 例えば
    • かぼちゃについて考えてみましょう


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

    View full-size slide

  20. 「かぼちゃを監視する」(例え話)
    かぼちゃの「状態」を表すのには、どんな項目があるでしょう?
    • 匂い


    • 味


    • 形


    • 黄色さ


    • 大きさ


    • 重さ


    • 糖度


    • 収穫後日数


    • 水分量


    • 感触


    • 弾力


    • カロリー

    View full-size slide

  21. 「かぼちゃを監視する」(例え話)
    あなたなら、

    どの項目で「南瓜信頼性Pumpkin-Reliability」を測る!?
    • 匂い


    • 味


    • 形


    • 黄色さ


    • 大きさ


    • 重さ


    • 糖度


    • 収穫後日数


    • 水分量


    • 感触


    • 弾力


    • カロリー
    かぼちゃの「状態」を表すのには、どんな項目があるでしょう?

    View full-size slide

  22. 「かぼちゃの提供による価値実現」(例え話)
    何を提供したいか?によって重要な項目が変わります


    • スーパーや八百屋で販売する


    • 売れやすい・食事に使いやすさに紐づくのは?(味・経過日数かなぁ


    • 絵画や写真の素材として提供したい


    • 映えるかぼちゃとは?(色や形かもね


    • 販売者目線でなく、調理者として食べ頃を知りたい


    • 「かぼちゃの不吉な臭い」を気にしておけば、まずハズレを除外できそうだ
    目的が違うはずだよね!

    View full-size slide

  23. なぜ監視を行うのか
    × インフラ(etc)を監視する?


    • じゃあ「運用の人」「インフラの人」のミッションなのか・・?

    View full-size slide

  24. なぜ監視を行うのか
    × インフラ(etc)を監視する

    ◯ 「ユーザーがちゃんと使えているか」を監視する


    • アプリケーション開発者は「動くもの」を作りますよね?


    • 監視は「作ったものがちゃんと使えるか」を気にする行為


    • (目指しているところは同じですよね

    View full-size slide

  25. なぜ監視を行うのか
    • システムの提供したい「目的」を果たせているか?を監視する


    • 「CPU使用率」や「全APIの平均返答時間」を一生懸命眺めても・・


    • これらのデータ自体には、意味が生まれにくい


    • こうした項目を理解すること!!!が、「監視を始める一歩」ではない


    • 「いま使っているユーザーに何が起きている?」という物語

    にこそ価値がある


    • 「サーバーの処理が追いつかなそう」

    「いつもは早い応答が鈍っている」ことに気づくことが必要


    • 数値や変化を可視化したら、その意味(=影響)を考える

    View full-size slide

  26. §2


    どういうことしてるの?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. だから分解して考える
    E2E
    外形/死活監視
    ネットワーク
    アプリケーション
    サーバー/サービス

    OSメトリクス
    連携コンポーネント
    対抗先システム

    疎通監視

    View full-size slide

  31. 分解して考えると・・・
    • 1つ1つは凄く単純なデータになる


    • 変化の有無、量が判断しやすい


    • 「重かったり、動きが変になっているのはどこ?」の目線


    • コンポーネントでの分解


    • アプリケーションサーバー?データベース?ストレージ?etc


    • 範囲での分解


    • 全体?特定ページやユーザー?


    • 最大値の異常?平均?最小?

    View full-size slide

  32. たとえば「何のデータ」を集めるか?

    〜監視対象ってどんなものがあるの〜

    View full-size slide

  33. よく使う監視①: OSのメトリクス
    • OSの機能やハードウェア的なところの監視


    • CPU使用率とかメモリ使用量とかディスク残量とか
    サーバー/サービス

    OSメトリクス
    連携コンポーネント

    View full-size slide

  34. よく使う監視②: ネットワークのメトリクス
    • コンポーネントがどのくらいのやりとりをしているか


    • リクエスト数とか転送量とかスループット(時間当たりの転送量)とか


    • レスポンスのHTTPステータスとか「タイムアウト」数とか接続数とか
    も見れたりするかも
    ネットワーク

    View full-size slide

  35. よく使う監視③: アプリケーション監視
    • アプリケーションが正常(期待する/許容範囲の)動きをしているか


    • ログ数とかエラー数とか処理完了時間とか
    アプリケーション

    View full-size slide

  36. よく使う監視④: 外形監視
    • サービスの外から見て、機能が動いているか


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

    View full-size slide

  37. よく使う監視⑤: RUM/EndToEnd/サービス監視
    • 「実際にサービスを使っている人のデータ」を集めるもの


    • JSのSDKを埋め込んで、パフォーマンスやエラーのデータを収集するも
    のもあるし


    • Google Analyticsみたいな解析ツールを使うこともあるし


    • 「ログイン数」「注文数」とかのサービス利用状況を見たりも
    E2E

    View full-size slide

  38. 覚えること色々ある?

    (同時に全部を考えているのか・・?)

    View full-size slide

  39. 複雑さにどう立ち向かうか?というのが大事
    • 組み合わせるから「複雑」が生まれる


    • ある要素が、それ以外の要素に対して反応する関係性/作用が生まれる


    • 「DBが重くなって、レスポンスも遅くなっている」


    • 単純と複雑を行き来しながら、物語を語れると勝ち!


    • いま起きている問題は何?どこで?を考えて、その発生要因をつきとめる!


    • 「DBが重くなったのは、CPU負荷が上がったからっぽい」

    「リクエストや接続数の増加はない」「実行時間が長いクエリが増えている」

    「さっき複雑な集計機能を出したからだ!」

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  52. 例えば②
    TVUFLJQSPEVDUSBOLJOH QBHF TFD
    TVUFLJQSPEVDUSBOLJOH QBHF TFD
    TVUFLJQSPEVDUSBOLJOH QBHF TFD
    TVUFLJQSPEVDUSBOLJOH QBHF TFD
    TVUFLJQSPEVDUSBOLJOH QBHF TFD
    TVUFLJQSPEVDUSBOLJOH QBHF TFD
    コレを踏まえた監視としては・・


    • 応答速度について、

    「トップページの基準」と「サイト全体の基準」を分けよう


    • トップページ = どんなユーザーにも影響を与える箇所(の例)


    • トップページは「サイト全体平均」よりも厳し目にする

    View full-size slide

  53. 考えるヒント
    • 「HTTPのリクエストが、どこから来てどこを通るのか?」の

    イメージを持てていると良いです


    • つながりで考えていく
    こいつに注目!

    View full-size slide

  54. §3


    本当は

    アプリケーションの知識が必要だぜ!!!


    View full-size slide

  55. Webサービスって複雑・・

    View full-size slide

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

    View full-size slide

  57. 「知っていること」が異なる
    • 「どういう機能があり、どういうデータを使っているか」は

    アプリケーションの中にあるロジックによって決められているもの


    • 「mypageの下にある“興味のあるラーメン屋リスト”って、どう作ってるの?」


    • 「どういうデータを」≒ 「どういうコンポーネントを」につながる


    • RDBなのか、キャッシュなのか、アプリケーション側で集計をしているのか

    View full-size slide

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

    View full-size slide

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

    「ロジックを作っている人」の方が有利と言える

    View full-size slide

  60. 監視におけるアプリケーションの貢献
    • アプリケーションのロジックが、複雑さに与えている影響は大きい


    • 「このクエリなんですか?」「それは、◯◯のページです」


    • つまり、機能を作った人が

    「これはこういう負荷をかけるかも」

    「正常な動作をしていれば、そんなに負荷が上がるはずは・・?」

    という予見を持てると最高になれるという話に


    • 設計・実装の予見


    • リリース後、障害発生時の分解・掘り下げ

    View full-size slide

  61. すなわち・・
    • ←の人の「お〜い!」を分解するのは、みんなでやろう


    • アプリケーションの中身を知っている人は、

    そこから「物語」を紐解くところに貢献しやすい


    • 良い監視は、良い「物語の想像力」から・・

    View full-size slide

  62. §4


    アプリケーションエンジニアこそ

    「監視」だよね!と私が考える訳

    View full-size slide

  63. 監視★マインド
    • アプリケーションを作っている時に、

    「動くものを」「役に立ちますように」の気持ちがあるはず


    • デプロイした後、運が良ければ予想通りに動くかも知れないし、

    運が悪ければ動かなかったり問題を引き起こしたりする


    • 「動くコードを書く」のと「書いたものが動くか見届ける」のは

    非常に近い領域の話ではないかな、と考えます


    • しかも、それを他の人よりも上手くやれる可能性が高いんだぜ・・・とも


    View full-size slide

  64. 「次の1歩」に★オススメ
    • 「最近、コードを書けるようになってきた気がするぞ」

    「フレームワークを使えるようになった」みたいな感覚があるな〜〜
    という、そこのあなた!


    • 次に進む1歩として、監視は結構おすすめできます


    • 決して「インフラ領域の専門性を身に着けよう!!」みたいなハードルが高い
    話ではないのです

    View full-size slide

  65. 「次の1歩」に★オススメ
    • 「インフラ系の知識」という意味では、↓の要素は抑えましょう


    • どうしたらCPUの利用率が上がるのか


    • どんな処理をしたら、メモリを消費するのか


    • ネットワーク越しのデータ量(転送量)って?


    • が!!

    結局これは「ロジックの書き方」「データの扱い方」と直結するもの


    • 言い換えると、あんまりインフラインフラしていなくても、身につけたいことです

    View full-size slide

  66. 技術的な刺激、成長★チャンス
    • 普段から「監視」の目線を持って開発ができたら・・・


    • 例えば「遅くないクエリを書く」とか「正常/異常の見分けが付きやすいように
    ログを出す」とかの意識が持てるようになっていって


    • 自分が書くコードについて、考える視点が増える。

    多角的に捉えて(セルフ)フィードバックを出せるようになる


    • すなわち、「良いコード」について考える物差しが増える!


    • 「数字」や「結果」が判別しやすいので、手応えにつながる!

    View full-size slide

  67. お話したことのまとめ
    • 監視に興味を持つことで、

    もっとアプリケーションやサービス開発を好きになれる!!はず


    • 監視に手を染めて、

    開発者としての成長曲線に角度をつけていきましょう!!

    View full-size slide

  68. お話したことのまとめ
    • 単なる数字やデータを眺めるのではなく、

    想像力を持って、「物語」として捉えることで

    監視は怖いものではなくなるはずだ・・・!というお話でした

    View full-size slide

  69. 自分が作ったものに胸張りたくない?
    • せっかく一生懸命書いたコード、

    ちゃんと動いているな〜ユーザーに使ってもらえているな〜〜

    っていうところまで、自分で見届けられた方が

    きっとアプリケーション開発は楽しくなると思っています!!


    • やっていきましょう!

    View full-size slide

  70. このトークで、

    「監視って大事そうだな」

    「自分にもできることがありそうだ」

    「やっていきたいな!!」

    と感じる人が増えてほしい〜〜

    View full-size slide

  71. おしまい!
    お付き合いいただき


    ありがとうございました!!

    View full-size slide

  72. 参考書籍
    • 個人的に、非常に強い影響を受けてるのが「入門 監視」です


    • 「ユーザー目線の監視」を始め、監視についての自分のコアになる概
    念をいくつも提供されました


    • 「ユーザー目線の監視」「アラートは誰かを叩き起こすもの」「監視はスキル」
    などが、特に好きな概念


    • 今回の発表よりは少し難しい(監視の実戦経験がある初級
    者〜なイメージ)かも知れませんが、文量も多すぎずとっ
    つきやすい1冊だと思います

    հ



    入門 監視 ―モダンなモニタリングのためのデザインパターン

    オライリージャパン

    Mike Julian (著), 松浦 隼人 (翻訳)


    View full-size slide

  73. 関連資料
    監視周りで、自分が過去に発表した内容も貼っておきます

    (必ずしも、今回の発表と対象者が同じものではありません)


    • 入門 入門 監視 (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

    View full-size slide