ログ収集基盤を導入したらエラーログが99%以上削減された話

Transcript

1. ログ収集基盤を導入したら エラーログが99%以上削減された話 DMM.com 小芝 涼太
2. あなたは誰？ TwitterとかQiitaとか: @_r548 DMM.com 動画配信事業部のエンジニア
3. DMM動画について
4. DMMの売り上げを支え続けてきた 20年前から続くサービス
5. 提供しているサービスや 対応するデバイスも年々増える
6. もちろん技術負債もたまる
7. 主な仕事：技術負債の返済 開発効率の向上 障害発生率を減らしコスト削減
8. 今までやってきたこと DBの利用状況調査 (general_logから分析, Spark, EMR) 本番環境のクラウド化、コンテナ化 (GKE, Istio, Spinnaker等の技術検証中) UIパーツのコンポーネント化 (Vue.js, Storybook) ログ収集基盤の構築、運用 (EFK, KFH, Lambda)
9. 今までやってきたこと DBの利用状況調査 (general_logから分析, Spark, EMR) 本番環境のクラウド化、コンテナ化 (GKE, Istio, Spinnaker等の技術検証中) UIパーツのコンポーネント化 (Vue.js, Storybook) ログ収集基盤の構築、運用 (EFK, KFH, Lambda) ←
10. これまでDMM 様々な事業部が乗っかるモノリシック (動画、電子書籍、物販などなど) ↓ 各事業部に合わせた サーバの設定ができない
11. アクセスログやアプリケーションログ を取得することができていなかった
12. 1年前 事業部ごとにサーバを分離 ↓ 各事業部に合わせたサーバの設定が可能
13. やっとログ収集ができる！
14. ログ収集やろう
16. fluentdでサーバのログをAWS上の Kinesis Firehoseへ転送
17. S3：アクセスログ＆エラーログ Elasticsearch：エラーログのみ
18. アクセスログは Athenaを用いて抽出できるように
19. エラーログはKibanaから検索できるように
21. とりあえず作った
22. ただ、誰も使ってくれていない
23. しかも 数十万件のエラーログが発生していた
24. どうい状況？？ 数種類のログが大半を占めていそう サービスに大きな影響を与えるものではない
25. それにしてもノイズが多すぎる 本来みたいログが見れない 新たなエラーログを検知できない
26. ログ基盤の意味をなしていない
27. エラーログを撲滅させよう！
28. エラーログ撲滅の流れ
29. エラーログから該当するコードを調査 ↓ アクセスログからエラーログの再現性を確認 ↓ 該当箇所を修正してエラーログが出ないことを確かめる
30. 　↑この辺 エラーメッセージ毎のログをカウント
31. チームメンバー数人で エラーログランキングの上位から １つ１つ潰していく地道な作業
32. 数週間で80%ほど削減できた
33. それでも残り数万件が存在
34. ここが一番やばい
35. 種類が多すぎるし、なかなか減らない
36. いつ終わんのこれ？？
37. もっと周りを巻き込もう
38. 事業部全体のSlackチャンネルに 毎朝エラーログの状況を投下する
40. 前日のエラーログ件数を取得し、 毎朝Slackへ通知
41. 事業部全体のSlackチャンネルに 毎朝エラーログの状況を投下する ↑エンジニア以外も含む
42. ↑この数字がエンジニアの焦り具合を表している
43. いい感じ
44. 今までなぜこんな状況になっていたか ↓ やばそうなことは分かっているが どのくらいやばいかは分からない
45. 負債を数値化 ↓ どのくらいやばいかがやっと分かった
46. < 俺このエラーログ対応するわ！ < じゃあ自分はこれ！ < みんなでやっていこー！ < やるぞー！
47. みんなでエラーログを撲滅させよう！ ↑他事業部(インフラやビッグデータ)のエンジニアも参加
48. 自分がやるべきこと
49. エラーを潰すこと ↓ ログ基盤をよりよくする
50. 改めて、エラーログ撲滅の流れ
51. エラーログから該当するコードを調査 ↓ アクセスログからエラーログの再現性を確認 ↓ 該当箇所を修正してエラーログが出ないことを確かめる
52. エラーログから該当するコードを調査 ↓ アクセスログからエラーログの再現性を確認 ↓ 該当箇所を修正してエラーログが出ないことを確かめる
53. アクセスログからエラーログの再現性を確認 問題点：Athenaを利用 　　　=> AWSにログインする必要 => S3のログを基にあらかじめテーブルの作成 アクセスログの調査を全員ができない状況
55. Crawlerがログフォーマットを自動識別し Data Catalogにテーブルとして追加
56. RedashからAthenaを操作
57. 自動化することで 自分の手から離れた
58. 現在どうなっているか
59. 当初より99.9%以上削減された
60. めっちゃ減った✌
61. エラーログが撲滅されることで どんないいことがあったか
62. リリースの品質向上 ユーザに影響を与える前にバグや障害を検知
63. 他にも
64. 負債や主要項目の通知が当たり前に SonarQubeの静的解析結果 APIのレスポンスが遅いランキング GAの主要な値(ユーザ数, CVR) その他
65. いい感じの流れ
66. ただし 握り潰されているエラーも多数存在する
67. 今日の話はあくまでもここ 今後はここを掘り出す
68. まとめ - 目的は作ることではなく、使ってもらうこと - 負債の数値化、可視化で周りを巻き込む - 自分に降りかかる作業を減らすため、可能な限り自動化 今後は顕在化してないバグを掘り起こしていきたい