13年物プロダクトの監視を起点とした改善活動

by atsushi.oshima

Slide 1

Slide 1 text

13年物プロダクトの監視を起点とした改善活動 PHP Conference Japan 2021 Hamee株式会社　日野陽平　大嶋淳司

Slide 2

Slide 2 text

自己紹介日野陽平(@money166) • Hamee株式会社 • 2016年新卒入社 • Webアプリケーションエンジニア • 温泉・サウナが好き

Slide 3

Slide 3 text

自己紹介大嶋淳司 (@atsusics) • Hamee株式会社 • 2020年中途入社 • SRE • もうすぐパパになります

Slide 4

Slide 4 text

今回の発表の対象 - 対象 - まだ監視をしていない人 - 監視をしているけどうまく運用できていない人 - 13年物のプロダクト開発・運用に興味がある人

Slide 5

Slide 5 text

- Hameeとネクストエンジンについて - 抱えていた課題 - 改善方法 - まとめ目次

Slide 6

Slide 6 text

目次 - Hameeとネクストエンジンについて - 抱えていた課題 - 改善方法 - まとめ

Slide 7

Slide 7 text

小田原でネットショップの運営と ECの業務を自動化する企業

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

在庫0個在庫0個在庫0個在庫0個在庫情報の更新 A B C 在庫1個在庫1個在庫1個在庫1個複数ショップの運営は大変

Slide 10

Slide 10 text

ネクストエンジン

Slide 11

Slide 11 text

EC運営の作業をラクにする機能がたくさんネクストエンジン

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

- 2007年 Hamee内での提供開始　 - 2008年外部向けサービス提供開始 - 2013年ネクストエンジンAPI公開 - 2021年オンプレからAWSへの移行中 2007 2021 13年機能強化・対応モール強化を続けサービス成長し続けて来ました。ネクストエンジンの歴史

Slide 14

Slide 14 text

- PHPとMySQLのwebアプリケーション - PHPコード - 8000ファイル - 50万行 - 処理しているプロセス - Webリクエストプロセス - バッチプロセス - メール受信プロセスシステムと処理するプロセスに関して

Slide 15

Slide 15 text

ネクストエンジンのバッチ処理の重要性 - ネットショップ運営の中で重要な処理がたくさん実行されている - ネットショップからの注文情報の取り込み処理 - 注文状情報に対して在庫を割り振る処理 - ネットショップへの在庫数更新処理 - etc...

Slide 16

Slide 16 text

目次 - Hameeとネクストエンジンについて - 抱えていた課題 - 改善方法 - まとめ

Slide 17

Slide 17 text

改善する前の監視 - インフラ視点 - 問題が起きた場合にメールで結果を通知 - DB接続 - CPU・メモリ - アプリ視点 - 監視はしていない - 特定機能でのエラーメール通知

Slide 18

Slide 18 text

問題が発生 1: 操作 2: 問い合わせ 3: 調査依頼お客様カスタマーサポートエンジニア障害認知大量のメール改善前の障害認知方法

Slide 19

Slide 19 text

今回改善する課題 - お客様からのお問い合わせで障害と判明することがほとんど(受動的) - アプリ視点での監視をしていない - 必要・不要の判断がつかないメールが多い

Slide 20

Slide 20 text

目次 - Hameeとネクストエンジンについて - 抱えていた課題 - 改善方法 - まとめ

Slide 21

Slide 21 text

理想の形エラー、ログレイテンシーインフラメトリクス etc Slack通知緊急度高、ログレベル高すぐ反応したいチャンネル緊急度低知っておきたいイベントが流れるチャンネル

Slide 22

Slide 22 text

Slide 23

Slide 23 text

実施した具体的なアクション • Datadogの整備 • パフォーマンス定点観測会

Slide 24

Slide 24 text

実施した具体的なアクション • Datadogの整備 • パフォーマンス定点観測会

Slide 25

Slide 25 text

Datadogとはシステム、アプリケーション、サービス横断で監視可能な監視プラットフォーム • ログデータの分析/調査 • AWSとの連携 • リアルタイムダッシュボード構築 • 高機能なアラート設定 Datadog公式

Slide 26

Slide 26 text

理想の形（再）エラー、ログレイテンシーインフラメトリクス etc Slack通知緊急度高、ログレベル高すぐ反応したいチャンネル緊急度低知っておきたいイベントが流れるチャンネル Alert チャンネル Notify チャンネル

Slide 27

Slide 27 text

　Alertチャンネル緊急度高、ログレベル高、すぐ反応したい　↓ ユーザー業務に支障が出ているもの（ユーザー影響が出るもの） SRE サイトリライアビリティエンジニアリング入門監視モダンなモニタリングのためのデザインパターン

Slide 28

Slide 28 text

通知設計 Alertチャンネルユーザー影響があるものが通知されるSlackチャンネル Notifyチャンネルユーザー影響はないが知っておきたいイベントが通知される Slackチャンネル

Slide 29

Slide 29 text

実際に設定しているアラートその中でもユーザー影響が大きなもの例 • Batchエラー • Batchパフォーマンス • Webリクエストエラー（5XX,4XX）

Slide 30

Slide 30 text

Batch エラー

Slide 31

Slide 31 text

ログレベル設計（アプリケーション側）レベル概要状況取り扱い方例 ERROR 要対応重要な動作に支障発生を監視発生した場合に解消を試みるバッチ失敗・パフォーマンス低下、DB接続失敗 WARNING Weekly確認用動作に支障 or 準正常系発生状況を監視多発した場合に影響が出ているか確認リトライで復旧可、バリデーションエラー、操作ミス INFO 情報正常に動作パフォーマンス監視等に利用ログイン成功、バッチ成功 DEBUG デバック開発時の詳細な情報本番環境では記録しない開発時に必要に応じて利用する Alert Notify

Slide 32

Slide 32 text

name wait-time run-time batch1 200ms 2000ms batch2 10000ms 50ms Batch パフォーマンス

Slide 33

Slide 33 text

Webリクエストエラー（5XX,4XX）

Slide 34

Slide 34 text

結果 • 障害発覚が早くなった • 「ユーザーからお問い合わせで障害と判明」が少なくなった • Datadogが便利なので、原因調査が楽になった

Slide 35

Slide 35 text

実施した具体的なアクション • Datadogの整備 • パフォーマンス定点観測会

Slide 36

Slide 36 text

パフォーマンス定点観測会とは？通称「パフォ会」パフォーマンス、問題点を確認する週次MTG SREのみで実施していたが、その後アプリケーション側でも開始エウレカ株式会社様パフォーマンス定点観測会の取り組み

Slide 37

Slide 37 text

大事にしていること社内ドキュメントを拝借

Slide 38

Slide 38 text

パフォーマンス定点観測会 • 毎週木曜日 15:00-16:00 • 手順 o zoomに集合 o 共有事項があれば共有 o 3,4人になるようにブレイクアウトルーム o 各チームで確認、深堀、考察（20分ほど） ▪ Datadogダッシュボード ▪ ログ、パフォーマンス o 再度集まり、問題・気づきを共有、必要があればタスク化

Slide 39

Slide 39 text

ダッシュボード例

Slide 40

Slide 40 text

クエリーパフォーマンス例

Slide 41

Slide 41 text

パフォ会起点で改善できた例 • ログレベル適正化 o ユーザー影響が出ていないのに、Alert通知されていた • 潜在的なバグ発見、修正 o ユーザー問い合わせが来ていないエラー • お客さんの設定ミスを発見、サポート経由での協力 o 問い合わせ前の発見 • アラートの改善 o 閾値変更、新たなアラート追加

Slide 42

Slide 42 text

結果 • 監視運用が回っている o 陳腐化してない！！！ • アプリケーション特性を毎週見ることで傾向把握 o 在籍が長い人の肌感をデータで • Datadogに慣れた o 機会が増え、操作感把握 • アラート対応に積極的になっていった o 改善が進むことで、重要なアラートに絞られていった

Slide 43

Slide 43 text

目次 - Hameeとネクストエンジンについて - 抱えていた課題 - 改善方法 - まとめ

Slide 44

Slide 44 text

ネクストエンジンの障害検知（改善前）問題が発生 1: ネクストエンジンを操作 2: 問い合わせ 3: 調査依頼お客様カスタマーサポートエンジニア障害認知大量のメール

Slide 45

Slide 45 text

ネクストエンジンの障害検知（改善後）問題が発生 1: ネクストエンジンを操作お客様カスタマーサポートエンジニア障害認知　アラート

Slide 46

Slide 46 text

課題改善から生まれた文化 - ユーザー目線で障害判断・システム改修 - アプリエンジニアとSREエンジニアの密な連携 - パフォーマンスなどのシステムの変化を疑う思考

Slide 47

Slide 47 text

課題に対する改善のまとめ　改善前改善後障害対応の確認受動的な対応能動的な対応アプリからのalert 不必要な通知が大量重要な通知に反応できない不必要な通知が減少重要な通知に反応できるアプリ視点での監視特定機能のメールのみパフォ会で毎週確認

Slide 48

Slide 48 text

本題終了(次のスライドから宣伝)

Slide 49

Slide 49 text

お知らせ PHPカンファレンスのオンラインチラシにて Hamee本店で使用できるクーポンを配布しています。

Slide 50

Slide 50 text

Hameeでは一緒に働く仲間を募集 - 小田原に住んでる人 - 「小田原手当」制度 - 小田原に住んでいない人 - 「いざ！小田原」制度 - その他リモート補助制度も存在します。新幹線と小田急ロマンスカーの停車駅である小田原の地の利を活かし、通勤手段として新幹線・特急電車・飛行機・船・高速バスの利用を可能とする小田原周辺地域に住む社員に対して月2万円の手当金を支給する「小田原手当」制度

Slide 51

Slide 51 text

Hamee 採用