seminar/2022/06/27/ヤプリ - 豚吐露＠wiki

顧客影響に気づけるアラート設計と原因特定が素早くできるSREへ ヤプリが乗り越えてきた監視運用の失敗と改善

望月 真仁 株式会社ヤプリ SREグループ マネージャー
佐々木 千枝 New Relic 株式会社 オブザーバビリティ技術本部 部長

---

障害の分類
　気づける←→気づけない
　理解できる←→理解できない
actionableな監視

気づこう

オライリー 監視入門

ユーザー視点の監視：ユーザーが使えてるか？大事。
→UX

理解しよう

エンジニアスキルに頼るしかない状態
→データドリブンなトラシュー
　→システムからデータを収集
　　→集めたい情報→武器
　　　　M：メトリクス
　　　　E：イベント
　　　　L：ログ
　　　　T：トレース

NewRelic：
ヤプリ：
SRE：

監視ツールの選定ポイント

アクセスのスパイク
主機能の障害を２週連続で起こした
→①障害の緊急性にふさわしいレベルで通知されなかった
→②障害サーバからアラート通知がなかった
→③特定のエンジニアしか対応できない障害だった
→④状況把握、原因調査に時間がかかった
→⑤事前の予兆に気付けなかった

検知
障害対応
プロアクティブ

①
監視NewRelicからslackのinfo/warn/errorへ通知
　→errorチャンネルのみalert
　→利用者：クーポン、ポイントカード、スタンプが使えない
　　→CPU使用率が高い程度の認識

Appium→外形監視

ping形式の外形監視：上手く障害を検知できない

ScriptedAPI：E2E監視
→JS利用して監視
　→requestを自由に加工
　→assertで独自の条件
　→条件分岐自由に設定
　→ユーザ操作をシナリオ化

②飛んでほしい通知が飛んでなかった
→通知見直し
　→levelに加えサービスごとの通知を追加
　　→必要なaction毎の通知分類

③
最初に気づいたエンジニアが何をしたら良いかわからない。
→対処方法はわかるが、その権限が無かった

④
旧：PHP on EC2
新：Go on Fargate

APM
→特定条件で大量loopが発生する不具合発生
　→根本原因は別にあった

真の原因：table lock
→解除待ち大量発生
　→conn枯渇
　　→DB接続不良をトリガに任意レスポンスを出す
　　　→任意レスポンスをトリガに大量loop
　　　　→DB connがより枯渇
　　　　　→悪循環

APM大事
→目立った事象に囚われず多角的視野が必要

⑤
予兆1：CPU使用率が日々上昇、一方徐々にCPU使用率が低下する鯖があった
予兆2：半年前と比較し全体的なCPU使用率が高くなっていた
→いずれもしきい値の範囲内。
　→見える化：ダッシュボード

監視環境のupdate

監視サービスの移行
→NewRelicへ移行

SLI/SLO監視

検証環境も監視対象とし、検証環境で事前に課題を見つける
→予算がいくらあっても足りない
　→NewRelicOne

---

更新日： 2023年08月17日 (木) 22時56分35秒