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

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

Transcript

1. Warningアラートを放置しない！ アラート駆動でログやメトリックを 自動収集する仕組みによる恩恵 SRE NEXT 2023 【TrackB】2023.09.29 15:50 - 16:10 面白法人カヤック 池田将士 @mashiike
2. @mashiike その他事業部 SREチーム データエンジニア 主にデータのお悩み事相談や 多種多様なメトリックを眺める https://github.com/mashiike/shimesaba Mackerelを使ったSLI/SLO/エラーバジェット計算ツール https://github.com/mashiike/prepalert アラートに関するトイル削減ツール 趣味: • 利茶 (聞茶) • ネトゲ • 睡眠
3. 主にWeb技術を得意とする ゲームやコミュニティなど 多種多様な事業を展開する おもちゃ箱のような会社。
4. アジェンダ！ • Warningアラートとは？・Warningアラートにまつわるトイル • アラート駆動でログやメトリックを自動収集する仕組みの恩恵 • まとめ
5. アラート 人間が即座にアクションを起こして対応し、 状況を改善しなければならなことが生じている、 あるいは生じようとしていることを知らせます。 書籍版 SREサイトリライアビリティエンジニアリング p10 より 通常、アラートにはSeverity(重要度)をつけて人間に通知します。 Warningアラートとは、このSeverityがWarningであるものを本発表では 意味します。
6. SeverityがWarningのアラートは一般には、 『即座にアクションを起こす必要は無いが、 これから重大なことが生じようとしている可 能性があるので警告しておく』という意味合 いのものが多いと思います。 • リクエスト 5xx エラー 1件 • 平均レスポンスタイム500ms ※監視サービス Mackerelでの設定例 Warningアラートの実例
7. Severityによる取り扱いの差 Warningアラート Criticalアラート Slackにメンションなし ひっそりと channelメンションや オンコール付き
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アラートが発生しても不思議ではない
9. Warningアラートの確認 だいたい週次定例でWarningアラートについて振り返ります。 例えば、ALBのログをもとに、なぜエラーになったのかを確認します。 右側はなにか潜んでる可能性がありますね。 理由によっては、対策が必要になります。 Warningアラートの放置は重大な事故につながる可能性があります。 こっちはWAFのエラーなんで アプリケーションのエラーじゃないですね。 こっちはALBの後ろにいるNginxが500と 504を返してるみたいですね。 あとそれとは別の理由のもありますね 【ハインリッヒの法則】 1 29 300 重大な事故 軽微な事故 事故未遂
10. Warningアラートにまつわるトイル アラートの確認の為にログやメトリックを調べたりする行為は 以下の性質を持ちやすい • 手作業である • 週次定例のたびに繰り返される • 戦術的である • 長期的には直接的な価値をもたらさない • サービスの成長に比例して増加する しかし、確認作業はマニュアル化しやすく、自動化可能である。 つまり、Warningアラートの調査はトイルになりがち
11. • 週次定例の時間をオーバーして 振り返れないものが出る • 調査Issueがたくさんできる。 • 調べる人が固定化されがち • etc… トイルのもたらす現象
12. github.com/mashiike/prepalert アラート駆動でログやメトリックを自動収集する仕組み - OSS『prepalert』- MackerelとAWSを使ってる方は、ぜひ使ってみてください！
13. OSS『prepalert』の概要 アラートが発生したら、 Webhook経由でLambda関数が起動！ Redshift,S3,Cloudwatchなどにアクセスし その結果をMackerelのアラートのメモに貼る！ 導入前 導入後
14. アラート駆動でログやメトリックを自動収集する仕組み - OSS『prepalert』- Prepalert自体については本発表ではあまり触れないので、続きはブログで
15. 仕組みを入れたことによる恩恵 - 振り返り時間短縮 1. 週次定例中にWarningアラートを振り返りきることができる 重大な事故に繋がりそうであるか？という初期判断に必要な情報が 出揃っている状態なので、スムーズに振り返りができる。 この場合、『response timeのp99が1.5秒より長い』 というWarningアラートに対して、 『その期間のリクエストのパスごとにレスポンスタイムを集計した 結果、 画像アップロードのAPIが1件 17.9秒かかっている。』 という情報がメモに自動的に書かれた状態にある 大きめの画像をアップロードした場合に 長く時間がかかるということがわかっているので、 エラーバジェットがまだあるので放念する。 ということがすぐ意思決定できる。
16. 仕組みを入れたことによる恩恵 - 収集内容の拡充 2. 初期判断に必要な情報が拡充される。 週次定例中に判断するには情報が足りないとなったら、 『prepalert』の設定に書き足せば良いだけなので、 『この情報もほしい』というのが増えた。
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のログをパス別に集計した結果』のみ
18. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 謎の15秒タイムアウト犯人捜索事件簿 Nginxのログがない ApplicationのError Logもない ALBのLogだけある • ALBのログはある。 • ALBによればTarget(接続先)が503を返している • しかし、接続先のNginxはアクセスログがない。 • 他のアラートも15秒できっちり揃っている。 • ALBのタイムアウトは15秒より長く設定している 一体誰が接続を切っているんだ (・・?
19. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 謎の15秒タイムアウト犯人捜索事件簿 Timeout!!!!! 実はApp Meshの設定由来だった。 マイクロサービスのプロダクトで、 コントロールプレーンにEnvoyがいました。 EnvoyがTaskにくる通信を Proxyしているのようですが、 Nginxが何かしらの理由で通信できなかったようで す。 その結果、envoyがHTTP Status 503を返していた ようです。 App Meshの15秒タイムアウト設定に 気がついてなかった！！！
20. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿 ALB Target 5xx > 0 のWarningアラート。 500で、見知らぬPath、見知らぬエラーログ。 09:10:20.67568+09:00
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エラーを返しているので エラーバジェットは無駄に削れている。
22. 仕組みを入れたことによる恩恵 - 早期に問題を発見 • 他システム向けの脆弱性攻撃でエラーバジェット損失！事件簿 ALBに到達したうえで5xxエラーなると SLO違反でエラーバジェットが削れます。 なので、 WAFで対策を入れました。 Application側には到達しません また、これがWAFの設定を 見直すいい機会にもなりました。
23. まとめ • アラートにはSeverityがWarningの物がある。 ◦ すぐには重大な事故に繋がらないが、可能性があるもの ◦ そこそこの頻度で発生する。 ◦ Warningアラートの初期判断のための調査はトイルである。 • Warningアラートにまつわるトイル削減のために仕組みを入れた。 ◦ アラートが発生したらWebhookを受け取り、ログやメトリックスを自動 収集する仕組み ◦ 危ないかどうか？の初期判断ための情報は人が集めなくてもいい状態へ • 仕組みを入れた結果いくつかの恩恵があった。 ◦ Warningアラートの振り返り時間の短縮 ◦ 初期判断のための情報拡充 ◦ 重大な事故に繋がる前に、早期に問題を発見できたことも
24. Kayac Techblogもよろしく!