Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵

SRE Next 2023 の発表スライドです

Transcript

1. Warningアラートを放置しない！
   アラート駆動でログやメトリックを
   自動収集する仕組みによる恩恵
   SRE NEXT 2023
   【TrackB】2023.09.29 15:50 - 16:10
   面白法人カヤック 池田将士 @mashiike
   

   View Slide

2. @mashiike
   その他事業部 SREチーム
   データエンジニア
   主にデータのお悩み事相談や
   多種多様なメトリックを眺める
   https://github.com/mashiike/shimesaba
   Mackerelを使ったSLI/SLO/エラーバジェット計算ツール
   https://github.com/mashiike/prepalert
   アラートに関するトイル削減ツール
   趣味:
   ● 利茶 (聞茶)
   ● ネトゲ
   ● 睡眠
   

   View Slide

3. 主にWeb技術を得意とする
   ゲームやコミュニティなど
   多種多様な事業を展開する
   おもちゃ箱のような会社。
   

   View Slide

4. アジェンダ！
   ● Warningアラートとは？・Warningアラートにまつわるトイル
   ● アラート駆動でログやメトリックを自動収集する仕組みの恩恵
   ● まとめ
   

   View Slide

5. アラート
   人間が即座にアクションを起こして対応し、
   状況を改善しなければならなことが生じている、
   あるいは生じようとしていることを知らせます。
   書籍版 SREサイトリライアビリティエンジニアリング p10 より
   通常、アラートにはSeverity(重要度)をつけて人間に通知します。
   Warningアラートとは、このSeverityがWarningであるものを本発表では
   意味します。
   

   View Slide

6. SeverityがWarningのアラートは一般には、
   『即座にアクションを起こす必要は無いが、
   これから重大なことが生じようとしている可
   能性があるので警告しておく』という意味合
   いのものが多いと思います。
   ● リクエスト 5xx エラー 1件
   ● 平均レスポンスタイム500ms
   ※監視サービス Mackerelでの設定例
   Warningアラートの実例
   

   View Slide

7. Severityによる取り扱いの差
   Warningアラート Criticalアラート
   Slackにメンションなし
   ひっそりと
   channelメンションや
   オンコール付き
   

   View Slide

8. Warningアラートは結構な頻度ででる。
   例えば、Application Load Balancer(ALB)に
   AWS WAFを設定している場合。
   すべてWarningアラート
   https://aws.amazon.com/jp/waf/sla/
   月次稼働率 99.95% なので
   『ALBの1分間のレスポンスで5xxが1件以上』なら、
   1週間で5件Warningアラートが発生しても不思議ではない
   

   View Slide

9. Warningアラートの確認
   だいたい週次定例でWarningアラートについて振り返ります。
   例えば、ALBのログをもとに、なぜエラーになったのかを確認します。
   右側はなにか潜んでる可能性がありますね。
   理由によっては、対策が必要になります。
   Warningアラートの放置は重大な事故につながる可能性があります。
   こっちはWAFのエラーなんで
   アプリケーションのエラーじゃないですね。
   こっちはALBの後ろにいるNginxが500と
   504を返してるみたいですね。
   あとそれとは別の理由のもありますね
   【ハインリッヒの法則】
   1
   29
   300
   重大な事故
   軽微な事故
   事故未遂
   

   View Slide

10. Warningアラートにまつわるトイル
    アラートの確認の為にログやメトリックを調べたりする行為は
    以下の性質を持ちやすい
    ● 手作業である
    ● 週次定例のたびに繰り返される
    ● 戦術的である
    ● 長期的には直接的な価値をもたらさない
    ● サービスの成長に比例して増加する
    しかし、確認作業はマニュアル化しやすく、自動化可能である。
    つまり、Warningアラートの調査はトイルになりがち
    

    View Slide

11. ● 週次定例の時間をオーバーして
    振り返れないものが出る
    ● 調査Issueがたくさんできる。
    ● 調べる人が固定化されがち
    ● etc…
    トイルのもたらす現象
    

    View Slide

12. github.com/mashiike/prepalert
    アラート駆動でログやメトリックを自動収集する仕組み
    - OSS『prepalert』-
    MackerelとAWSを使ってる方は、ぜひ使ってみてください！
    

    View Slide

13. OSS『prepalert』の概要
    アラートが発生したら、
    Webhook経由でLambda関数が起動！
    Redshift,S3,Cloudwatchなどにアクセスし
    その結果をMackerelのアラートのメモに貼る！
    導入前
    導入後
    

    View Slide

14. アラート駆動でログやメトリックを自動収集する仕組み
    - OSS『prepalert』-
    Prepalert自体については本発表ではあまり触れないので、続きはブログで
    

    View Slide

15. 仕組みを入れたことによる恩恵 - 振り返り時間短縮
    1. 週次定例中にWarningアラートを振り返りきることができる
    重大な事故に繋がりそうであるか？という初期判断に必要な情報が
    出揃っている状態なので、スムーズに振り返りができる。
    この場合、『response timeのp99が1.5秒より長い』
    というWarningアラートに対して、
    『その期間のリクエストのパスごとにレスポンスタイムを集計した
    結果、
    画像アップロードのAPIが1件 17.9秒かかっている。』
    という情報がメモに自動的に書かれた状態にある
    大きめの画像をアップロードした場合に
    長く時間がかかるということがわかっているので、
    エラーバジェットがまだあるので放念する。
    ということがすぐ意思決定できる。
    

    View Slide

16. 仕組みを入れたことによる恩恵 - 収集内容の拡充
    2. 初期判断に必要な情報が拡充される。
    週次定例中に判断するには情報が足りないとなったら、
    『prepalert』の設定に書き足せば良いだけなので、
    『この情報もほしい』というのが増えた。
    

    View Slide

17. 仕組みを入れたことによる恩恵 - 収集内容の拡充
    例: 『ALB Target 5xx Request > 0 』のWarningアラートに関して
    ● Nginxのupstream側が5xxであった
    『Applicationのログ情報』を見る必要があるので追加
    ● NginxはHTTP 499 Client Closed Requestのケースが有る
    ALB側がTimeoutで切断しているか確認するために
    『ALBのLog情報』を追加
    ● 影響するユーザーがどれくらいいるのかを判断したくなった。
    Applicationが使用している
    『Aurora MySQL由来の基幹DB情報』を追加
    導入初期: 『Nginxのログをパス別に集計した結果』のみ
    

    View Slide

18. 仕組みを入れたことによる恩恵 - 早期に問題を発見
    ● 謎の15秒タイムアウト犯人捜索事件簿
    Nginxのログがない
    ApplicationのError Logもない
    ALBのLogだけある
    ● ALBのログはある。
    ● ALBによればTarget(接続先)が503を返している
    ● しかし、接続先のNginxはアクセスログがない。
    ● 他のアラートも15秒できっちり揃っている。
    ● ALBのタイムアウトは15秒より長く設定している
    一体誰が接続を切っているんだ (・・?
    

    View Slide

19. 仕組みを入れたことによる恩恵 - 早期に問題を発見
    ● 謎の15秒タイムアウト犯人捜索事件簿
    Timeout!!!!!
    実はApp Meshの設定由来だった。
    マイクロサービスのプロダクトで、
    コントロールプレーンにEnvoyがいました。
    EnvoyがTaskにくる通信を
    Proxyしているのようですが、
    Nginxが何かしらの理由で通信できなかったようで
    す。
    その結果、envoyがHTTP Status 503を返していた
    ようです。
    App Meshの15秒タイムアウト設定に
    気がついてなかった！！！
    

    View Slide

20. 仕組みを入れたことによる恩恵 - 早期に問題を発見
    ● 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿
    ALB Target 5xx > 0 のWarningアラート。
    500で、見知らぬPath、見知らぬエラーログ。
    09:10:20.67568+09:00
    

    View Slide

21. 仕組みを入れたことによる恩恵 - 早期に問題を発見
    ● 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿
    Caught exception in engine "End of stream encountered while parsing part body at
    /home/app/xxxxxxxxxxxx/local/lib/perl5/HTTP/Entity/Parser/MultiPart.pm line 157.
    POST /FCKeditor/editor/filemanager/connectors/asp/connector.asp
    ASP.NET版のFCKeditorへの攻撃のようですね。
    Perl5のアプリケーションでHTTPリクエストの
    ボディとして解釈できずに500エラーになったようです。
    https://jvndb.jvn.jp/ja/contents/2009/JVNDB-2009-002835.html
    Perl5のパーサーが優秀なので、
    有効な攻撃にはなっていないが、
    しかし、5xxエラーを返しているので
    エラーバジェットは無駄に削れている。
    

    View Slide

22. 仕組みを入れたことによる恩恵 - 早期に問題を発見
    ● 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿
    ALBに到達したうえで5xxエラーなると
    SLO違反でエラーバジェットが削れます。
    なので、
    WAFで対策を入れました。
    Application側には到達しません
    また、これがWAFの設定を
    見直すいい機会にもなりました。
    

    View Slide

23. まとめ
    ● アラートにはSeverityがWarningの物がある。
    ○ すぐには重大な事故に繋がらないが、可能性があるもの
    ○ そこそこの頻度で発生する。
    ○ Warningアラートの初期判断のための調査はトイルである。
    ● Warningアラートにまつわるトイル削減のために仕組みを入れた。
    ○ アラートが発生したらWebhookを受け取り、ログやメトリックスを自動
    収集する仕組み
    ○ 危ないかどうか？の初期判断ための情報は人が集めなくてもいい状態へ
    ● 仕組みを入れた結果いくつかの恩恵があった。
    ○ Warningアラートの振り返り時間の短縮
    ○ 初期判断のための情報拡充
    ○ 重大な事故に繋がる前に、早期に問題を発見できたことも
    

    View Slide

24. Kayac Techblogもよろしく!
    

    View Slide