続く障害からの脱却 オブザーバビリティで立て直すサービス開発

PHPカンファレンス名古屋2025

Transcript

1. #phpcon_nagoya #s 続く障害からの脱却 オブザーバビリティで立て直すサービス開発 in PHPカンファレンス名古屋2025 @yamato_sorariku
2. #phpcon_nagoya #s 自己紹介 @yamato_sorariku / 足利 大和 株式会社カオナビ • バックエンドエンジニア ◦ 軸はPHPer ◦ 必要なことはなんでもやります • 猫とコーヒーと飛行機が好き 2
3. #phpcon_nagoya #s 障害が頻発し苦境に陥り プロダクト自体の機能開発も改善も進まない状況のチーム そんなチームで私がやってきたことをお話します 3
4. #phpcon_nagoya #s 今回のトークで登場するサービスの概要 4 提携しているメディアの記事リスト を取得するcronジョブ 取得リストをもとに 順次実行して記事を取得する cronジョブ 取得した記事を使って ユーザごとにレポート生成 するcronジョブ 調査レポート 提供している価値 取得先は数千件以上 総取得数は数万件以上 ユーザごとに設定された調査条件に合 致したデータを取得しレポート化 レポートに対する追加情報の取得 記事の注目度など
5. #phpcon_nagoya #s プロダクトチームの状況 5
6. #phpcon_nagoya #s 2週に1度は大小さまざまな障害が発生 6
7. #phpcon_nagoya #s 最重要なデータ収集バッチが 数日間実行エラーで稼働せず データ取得遅延・欠損 7
8. #phpcon_nagoya #s 提供するレポート用追加情報の 取得が数日間すべて失敗し続けデータ欠損 8
9. #phpcon_nagoya #s プロダクトチームの状況 2週に1度は大小さまざまな障害が発生 • 最重要なデータ収集バッチの停止 • ユーザに提供するレポート用追加情報の取得エラー どちらも数日間気づくことなく、CS部門からの問い合わせで発覚 9
10. #phpcon_nagoya #s プロダクトチームの状況 ほぼCS部門からの問い合わせで発覚 これがつらい。 10
11. #phpcon_nagoya #s 11 この表示って正しいですか？
12. #phpcon_nagoya #s 12 この表示って正しいですか？ これデータ壊れてません？
13. #phpcon_nagoya #s これなんか起きてませんか？ 13 この表示って正しいですか？ これデータ壊れてません？
14. #phpcon_nagoya #s プロダクトチームの状況 ほぼCS部門からの問い合わせで発覚 サービスとしての安定感はゼロ、CS部門からの信頼もやばい CS部門の方が毎日見回りをルーティンタスクとして設定する事態 14
15. #phpcon_nagoya #s プロダクトチームの状況 当然チームには良くない空気が流れる • 対応に追われてプロダクトへの機能実装はうまく進捗できない ◦ レガシーなコードやインフラの改善も進まない 15
16. #phpcon_nagoya #s プロダクトチームの状況 当然チームには良くない空気が流れる • 対応に追われてプロダクトへの機能実装はうまく進捗できない ◦ レガシーなコードやインフラの改善も進まない • なにかアクションを起こすと問題が起きる 16
17. #phpcon_nagoya #s プロダクトチームの状況 当然チームには良くない空気が流れる • 対応に追われてプロダクトへの機能実装はうまく進捗できない ◦ レガシーなコードやインフラの改善も進まない • なにかアクションを起こすと問題が起きる ◦ 起きる問題に自分たちで気付けない ◦ 行動しないことが安全に繋がってしまう 17
18. #phpcon_nagoya #s プロダクトチームの状況 当然チームには良くない空気が流れる • 対応に追われてプロダクトへの機能実装はうまく進捗できない ◦ レガシーなコードやインフラの改善も進まない • なにかアクションを起こすと問題が起きる ◦ 起きる問題に自分たちで気付けない ◦ 行動しないことが安全に繋がってしまう 18 自分たちで気付けるようになろう ↓ システム監視から始める立て直しへ
19. #phpcon_nagoya #s システム監視 19
20. #phpcon_nagoya #s シンプルなシステム監視に着手 • CPUなどのサーバリソースの監視 • 各種ジョブ処理(cron実行)の実行結果を収集 • ログの監視とSlack通知 20
21. #phpcon_nagoya #s シンプルなシステム監視に着手 21 CPUの負荷状態
22. #phpcon_nagoya #s シンプルなシステム監視に着手 22 CPUの負荷状態 これはやばい？
23. #phpcon_nagoya #s シンプルなシステム監視に着手 23 CPUの負荷状態
24. #phpcon_nagoya #s シンプルなシステム監視に着手 24 CPUの負荷状態 これは平和？
25. #phpcon_nagoya #s シンプルなシステム監視に着手 • CPUなどのサーバリソースの監視 ◦ 余裕があるからと言って問題なく稼働してるかはわからない ◦ 使用率99%でも適切にサービス提供できれいれば問題ない • 各種ジョブ(cron実行)の実行結果を収集 • ログの監視とSlack通知 25 目安: 5分
26. #phpcon_nagoya #s シンプルなシステム監視に着手 26 ジョブの終了コードが0ならOK 1ならなにか問題が起きている
27. #phpcon_nagoya #s シンプルなシステム監視に着手 27 おや？
28. #phpcon_nagoya #s シンプルなシステム監視に着手 • CPUなどのサーバリソースの監視 ◦ 余裕があるからと言って問題なく稼働してるかはわからない ◦ 使用率99%でも適切にサービス提供できれいれば問題ない • 各種ジョブ処理(cron実行)の実行結果を収集 ◦ 終了コードにが0なら正常終了している判定 ▪ エラーなのに0応答しているコードが稀に…… • ログの監視とSlack通知 28
29. #phpcon_nagoya #s シンプルなシステム監視に着手 • CPUなどのサーバリソースの監視 ◦ 余裕があるからと言って問題なく稼働してるかはわからない ◦ 使用率99%でも適切にサービス提供できれいれば問題ない • 各種ジョブ処理(cron実行)の実行結果を収集 ◦ 終了コードにが0なら正常終了している判定 ▪ エラーなのに0応答しているコードが稀に…… • ログの監視とSlack通知 ◦ 対応不要なエラーログの山によるノイジーアラート 29
30. #phpcon_nagoya #s シンプルなシステム監視に着手 • CPUなどのサーバリソースの監視 ◦ 余裕があるからと言って問題なく稼働してるかはわからない ◦ 使用率99%でも適切にサービス提供できれいれば問題ない • 各種ジョブ処理(cron実行)の実行結果を収集 ◦ 終了コードにが0なら正常終了している判定 ▪ エラーなのに0応答しているコードが稀に…… • ログの監視とSlack通知 ◦ 対応不要なエラーログの山によるノイジーアラート 30 ちゃんと稼働してるかわからん
31. #phpcon_nagoya #s ※ インフラなどの監視はもちろん重要 • インフラレイヤで起きる問題も当然あるのでリソース監視なども必要 • 我々はWebアプリケーションエンジニアなので 「アプリケーション（サービス）」の監視が重要 • アプリケーションが正しく動作できていなければ価値は提供できていない 31
32. #phpcon_nagoya #s ※ インフラなどの監視はもちろん重要 • インフラレイヤで起きる問題も当然あるのでリソース監視なども必要 • 我々はWebアプリケーションエンジニアなので 「アプリケーション（サービス）」の監視が重要 • アプリケーションが正しく動作できていなければ価値は提供できていない 32 システムが価値が提供できていることを見えるようにしたい ↓ オブザーバビリティから始める立て直しへ
33. #phpcon_nagoya #s オブザーバビリティとは？ 33
34. #phpcon_nagoya #s オブザーバビリティとは？ オブザーバビリティとは、システムの外部出力の知識から 内部状態をどれだけ正確に推測できるかの尺度 引用: https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md 34
35. #phpcon_nagoya #s オブザーバビリティの3本柱 引用: https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md 35 メトリクス ログ トレース
36. #phpcon_nagoya #s オブザーバビリティの3本柱: メトリクス • システムの状態を数値で表現したもの ◦ 例：CPU使用率、メモリ使用量、リクエスト数/秒 • リアルタイムで収集され、時系列データとして保存、グラフ化しやすい ◦ システム全体の状態把握、異常の早期発見 36
37. #phpcon_nagoya #s オブザーバビリティの3本柱: ログ • システム内で発生したイベントの詳細な記録 ◦ アプリケーションログ、システムログ • テキスト形式で記録され、詳細な情報を含める（個人情報などには注意が必要） ◦ 1行のテキスト形式からJSONL形式など形は様々 37
38. #phpcon_nagoya #s オブザーバビリティの3本柱: トレース • リクエスト単位でイベントを記録する ◦ PHP、DB、外部APIなどごとの処理時間などを追うことができる • 全リクエストを対象にすると膨大なデータになるためサンプリングが必要 38
39. #phpcon_nagoya #s 内部状態をどれだけ正確に推測できるか 39
40. #phpcon_nagoya #s 内部状態をどれだけ正確に推測できるか ↓ システムが価値を提供できているか推測できるか 40
41. #phpcon_nagoya #s データの取得状況をすべて構造化ログとして出力 41
42. #phpcon_nagoya #s データの取得状況をすべて構造化ログとして出力 42 提携しているメディアの記事リスト を取得するcronジョブ 取得リストをもとに 順次実行して記事を取得する cronジョブ 取得した記事を使って ユーザごとにレポート生成 するcronジョブ レポートに対する追加情報の取得
43. #phpcon_nagoya #s データの取得状況をすべて構造化ログとして出力 43 提携しているメディアの記事リスト を取得するcronジョブ 取得リストをもとに 順次実行して記事を取得する cronジョブ 取得した記事を使って ユーザごとにレポート生成 するcronジョブ レポートに対する追加情報の取得
44. #phpcon_nagoya #s 価値が提供できていることを推測する 44 構造化ログをPHPで出力 構造化ログをNew Relicへ転送 構造化ログを集計して メトリクスへ変換
45. #phpcon_nagoya #s 価値が提供できていることを推測する 45 構造化ログを集計してメトリクスに -> 時系列のデータとして見える 目安: 10分
46. #phpcon_nagoya #s 価値が提供できていることを推測する 46 構造化ログを集計してメトリクスに -> 時系列のデータとして見える 安定して取得できてそう！
47. #phpcon_nagoya #s 価値が提供できていることを推測する 47 構造化ログを集計してメトリクスに -> 時系列のデータとして見える
48. #phpcon_nagoya #s 価値が提供できていることを推測する 48 構造化ログを集計してメトリクスに -> 時系列のデータとして見える 取得できてない時間が一定時間を超えた -> アラート発報 取得できなくなったメディアの確認 -> 全部？ 一部？
49. #phpcon_nagoya #s 価値が提供できていることを推測する 49 構造化ログを集計してメトリクスに -> 時系列のデータとして見える 取得できてない時間が一定時間を超えた -> アラート発報 取得できなくなったメディアの確認 -> 全部？ 一部？ ログとメトリクスを組み合わせてサービスが 価値を正しく提供できているか推測可能に
50. #phpcon_nagoya #s どのようなリードをしてきたか 50
51. #phpcon_nagoya #s どのようなリードをしてきたか • 自分がチームに来たときは完全な「サバイバルモード」 ◦ 起きる問題に振り回されて改善の時間がない ◦ 「改善していこう！」と言うだけでは前に進めない状況 ◦ なんとかして「ゆとり時間」を作らないといけない 51 参考: https://www.oreilly.co.jp/books/9784873118024/
52. #phpcon_nagoya #s どのようなリードをしてきたか • 自分がチームに来たときは完全な「サバイバルモード」 ◦ 起きる問題に振り回されて改善の時間がない ◦ 「改善していこう！」と言うだけでは前に進めない状況 ◦ なんとかして「ゆとり時間」を作らないといけない 52 参考: https://www.oreilly.co.jp/books/9784873118024/ ↓ 一人でたたき台を作ってしまおう！
53. #phpcon_nagoya #s どのようなリードをしてきたか • ダッシュボードのたたき台を作成 • チームイベントなどで共有し、サービスの状態が把握できることをアピール • 気づきを得てチームで改善を繰り返すことで「チームの共通認識」に 53
54. #phpcon_nagoya #s 共通認識となったことで • チームのメンバーが主体的に ◦ オブザーバビリティ向上のためのログ・メトリクスの追加 ◦ ダッシュボードへ新しい視点での監視の追加 ◦ オブザーバビリティに関する研修への参加 54
55. #phpcon_nagoya #s 共通認識となったことで • チームのメンバーが主体的に ◦ オブザーバビリティ向上のためのログ・メトリクスの追加 ◦ ダッシュボードへ新しい視点での監視の追加 ◦ オブザーバビリティに関する研修への参加 55 ↓ チームでオブザーバビリティ向上アクションに取り組めるように
56. #phpcon_nagoya #s チームでオブザーバビリティに取り組めるようになる 56 早期問題の検知と対処 改善や機能開発に 使える時間が増える プロダクトの安定性向上 価値を高める機能の追加
57. #phpcon_nagoya #s チームでオブザーバビリティに取り組めるようになる 57 早期問題の検知と対処 改善や機能開発に 使える時間が増える プロダクトの安定性向上 価値を高める機能の追加 改善のループが回り始めた
58. #phpcon_nagoya #s まとめ 58
59. #phpcon_nagoya #s まとめ • 小さく少しずつ始めよう ◦ シンプルな監視や構造化ログの出力から着手し、少しずつ改善を積み重 ねる。 • 価値を可視化しよう ◦ ログやメトリクスを活用し、サービスが正しく価値を提供できているか わかるようにする。 • チームで育てよう ◦ ダッシュボードの共有や継続的な改善を通じて、オブザーバビリティを 文化として根付かせよう。 59
60. #phpcon_nagoya #s サービスのオブザーバビリティを高め ガードレールを作り安心安全な プロダクト開発につなげて価値を高めていこう 60
61. #phpcon_nagoya #s 参考資料 • Re:Define 可用性を支える モニタリング、パフォーマンス最適化、そしてセキュリティ ◦ https://speakerdeck.com/pyama86/re-define-ke-yong-xing-wozhi-eru-monitaringu-pahuomansuzui-shi-hua-sositesekiyuritei • メトリクス、ログ、トレースをうまく使い分けて可観測性を高めよう！ ◦ https://speakerdeck.com/masayoshi/metorikusu-rogu-toresuwoumakushi-ifen-keteke-guan-ce-xing-wogao-meyou • Observability Whitepaper ◦ https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md#what-is-observability • O'Reilly オブザーバビリティ・エンジニアリング ◦ https://www.oreilly.co.jp/books/9784814400126/ • O'Reilly エラスティックリーダーシップ ◦ https://www.oreilly.co.jp/books/9784873118024/ 61
62. #phpcon_nagoya #s We are hiring!! - 株式会社カオナビ https://corp.kaonavi.jp/recruit /list/ 62 https://hrmos.co/pages/kaonavi/jobs/casual21 選考を希望する⽅ まずは話を聞いてみたいという⽅