混沌とした例外処理とエラー監視に秩序をもたらす

https://x.com/Jxck_/status/770899329301159936
https://x.com/Jxck_/status/770901468383580160
https://qiita.com/yugui/items/28085697041966726964
https://speakerdeck.com/twada/php-conference-2016
https://docs.sentry.io/platforms/ruby/enriching-events/context/

Transcript

1. STORES 株式会社 混沌とした例外処理とエラー監視に 秩序をもたらす morihirok 東京Ruby会議12
2. 自己紹介 森弘 一茂 X: @_morihirok GitHub: morihirok STORES 株式会社 ソフトウェアエンジニア
3. Rubyと暮らす上で かかせないものと言えば？
4. そう！例外処理ですね！
5. とはいえ例外処理は大変 • 複数人で開発していると意外と共通認識が揃っていない • エラーの発見・監視と関係してよりややこしくなる • そもそも例外って何？例外的な状況とは？
7. デカい！ 10年超え！
8. デカい Rails ✖ 例外処理 = ヤバい！
9. そんな大変さと向き合ってきた経験を話します 少しでもみなさんの参考になれば幸いです...！
10. 今日のアジェンダ 1. 実録！例外処理とエラー監視 2. 例外処理の整理を試みる 3. 改善の軌跡
11. 実録！例外処理とエラー監視
12. ある日のこと（超脚色版） 「A機能が動作していない」 という問い合わせがあります。 原因の確認をお願いします。 怪しいログもないし コード読むか...
13. 全て握りつぶされていた！ def show result = begin ResponseGenerator.call(params) rescue nil end render json: result end
14. 問い合わせからしか異常を検知できないシステムに • 全ての例外を握りつぶしていることでユーザーに正しい フィードバックを返すことができない • エンジニアも例外の発生を検知できない • 発生した問題をエンジニアがコードを読むことでしか解決 できなくなる
15. ある日のこと２（超脚色版） 「B機能が動作していない」 という問い合わせがあります。 原因の確認をお願いします。 怪しいログもないし コード読むか...
16. 全て握りつぶされ知らないログに送られていた！ def show result = begin ResponseGenerator.call(params) rescue => e logger = Logger.new('hoge.log') logger.error(e) end render json: result end
17. 活用されないログが散らばっているシステムに • 何がどこに書き込まれているのか、それをどのように利用 するのか関係者が把握できていない • ログに書き込んだ上で、そのログをどう利用するかまで考 慮されていない
18. ある日のこと３（超脚色版） エラートラッカーに 大量の通知が来た！！！ 何が起きてるんだ！
19. 全て握りつぶされエラートラッカーに送られていた！ def show result = begin ResponseGenerator.call(params) rescue => e Sentry.capture_exception(e) end render json: result end
20. ある日のこと4（マジ） エラートラッカーに 大量の通知が来た！！！ 何が起きてるんだ！
21. ある日のこと4（マジ） それは無視していいエラーです プロジェクトに 長年関わっているエンジニア
22. エラートラッカーがオオカミ少年に • 何か例外的な事象が起きた時に最優先で取り組むための ツールのはず • 便利ログツールとして利用すると「割れ窓」になってしま う • 本当に例外的な事象が起きていても気付けない
23. このような状況を なんとかする 必要があった
24. 今日のアジェンダ 1. 実録！例外処理とエラー監視 2. 👉例外処理の整理を試みる 3. 改善の軌跡
25. 例外処理の整理を試みる
26. 例外処理をどのように考えていくか 同僚たちと議論し認識を深めました
27. https://x.com/Jxck_/status/770899329301159936
28. https://x.com/Jxck_/status/770901468383580160
29. https://x.com/Jxck_/status/770901468383580160 これをベースに 考える
30. https://qiita.com/yugui/items/28085697041966726964
31. どのように考えていくか 1. 利用者からの入力は基本的に Expected として扱う 2. コンテキストから Accept か Un Accept か決めていく 3. 例外をまるごとハンドリングしない 4. それは本当に Expected か？
32. 1.利用者からの入力は基本的に Expected として扱う • 利用者はあらゆる入力をするという前提でプログラミング をする • 「かもしれない」プログラミング
33. 1.利用者からの入力は基本的に Expected として扱う • ただひたすら入力値をチェックするということではない https://speakerdeck.com/twada/php-conference-2016
34. 1.利用者からの入力は基本的に Expected として扱う 一般に、Rubyのイディオムでは型に基づく防御的なプログラミ ングを避けます。なぜなら、Rubyで気にするのは「オブジェク トがどんなメソッドに反応できるのか」と「そのメソッドがど んなオブジェクトを返すのか」だからです。（中略）型を明示 的に検査せず、ただオブジェクトを使いましょう。 Jeremy Evans 研鑽Rubyプログラミング ― 実践的なコードのた めの原則とトレードオフ p148-149
35. 2.コンテキストから Accept か Un Accept か決めていく • Ruby の JSON.parse • JavaScript の JSON.parse
36. 2.コンテキストから Accept か Un Accept か決めていく • Ruby の JSON.parse • JavaScript の JSON.parse JSON文法（RFC 8259）に 準拠しないテキストは Un Accept としている
37. JSON文法かどうか判定してくれる 架空のWebアプリケーションを 考えてみる
38. Webにおける Accept と Un Accept • Expected / Accepted：2XX • Expected / Un Accept：4XX, 5XX ◦ Expected だが 5XX を返すケースはありうるだろう • Un Expected：5XX
39. JSONかどうか判定してくれる Web アプリケーション • Web サーバはあらゆる入力を Expected なものと扱う • JSON.parse が Un Accept しても Web サーバの振る舞 いはそれに引きずられない • コードを書くプログラマがコンテキストを踏まえて都度判 断する
40. Accept と Un Accept どちらにしよう • Expected / Accepted：2XX • Expected / Un Accept：4XX, 5XX ◦ Expected だが 5XX を返すケースはありうるだろう • Un Expected：5XX
41. Accept と Un Accept どちらにしよう • Expected / Accepted：2XX • Expected / Un Accept：4XX, 5XX ◦ Expected だが 5XX を返すケースはありうるだろう • Un Expected：5XX どちらもありえそう！
42. 3.例外をまるごとハンドリングしない • 発生しうる全ての例外をハンドリングするような実装は避 けるべき def show result = begin ResponseGenerator.call(params) rescue => e Sentry.capture_exception(e) end render json: result end こういうハンドリングを 避ける
43. 3.例外をまるごとハンドリングしない • 基本的に発生すると想定している（Expectedな）例外を 明示的に指定する • 想定していない（Un Expectedな）例外をハンドリングし ない
44. 4.それは本当に Expected か？ • Un Expected 代表例 ◦ アプリケーション環境起因の例外 ◦ データベースなどミドルウェア障害起因の例外
45. PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 より
46. （再掲）どのように考えていくか 1. 利用者からの入力は基本的に Expected として扱う 2. コンテキストから Accept か Un Accept か決めていく 3. 例外をまるごとハンドリングしない 4. それは本当に Expected か？
47. 今日のアジェンダ 1. 実録！例外処理とエラー監視 2. 例外処理の整理を試みる 3. 👉改善の軌跡
48. 改善の軌跡
49. このコードはどうなるべきか def show result = begin ResponseGenerator.call(params) rescue nil end render json: result end
50. Expected な例外がない場合はハンドリングしない def show result = ResponseGenerator.call(params) render json: result end
51. Expected な例外がある場合はそれをハンドリングする def show result = begin ResponseGenerator.call(params) rescue ResponseGenerator::SomeError return render status: :bad_request end render json: result end
52. やったか！？
53. 改善しても増え続ける まるっとハンドリング
54. 改善しても増え続けるまるっとハンドリング • 既存コードは参考にされ続けるので、新たなコードに既存 踏襲のまるっとハンドリングが書かれてしまう • （STORES 特有の事象として）様々なバックグラウンドの いろんなチームの人がリポジトリにコミットするのでアナ ウンスという形ではなかなか浸透しないがち
55. （再掲）どのように考えていくか 1. 利用者からの入力は基本的に Expected として扱う 2. コンテキストから Accept か Un Accept か決めていく 3. 例外をまるごとハンドリングしない 4. それは本当に Expected か？
56. （再掲）どのように考えていくか 1. 利用者からの入力は基本的に Expected として扱う 2. コンテキストから Accept か Un Accept か決めていく 3. 例外をまるごとハンドリングしない 4. それは本当に Expected か？ プログラマが 判断するしかない
57. （再掲）どのように考えていくか 1. 利用者からの入力は基本的に Expected として扱う 2. コンテキストから Accept か Un Accept か決めていく 3. 例外をまるごとハンドリングしない 4. それは本当に Expected か？ 機械的に 判断できる
58. 整理したことで 改善すべき課題が 明確に
59. RuboCop を活用し課題を攻める • Lint/SuppressedException https://docs.rubocop.org/rubocop/cops_lint.html#lintsuppressedexception
60. このコードも RuboCop 違反となる def show result = begin ResponseGenerator.call(params) rescue nil end render json: result end
61. .rubocop_todo.yml を活用し課題を攻める • 新たに違反するコードが増えることを防ぐことができる • .rubocop_todo.yml が改善すべきコードのリストとな り、改善ポイントが明確となる これが 改善ポイント
62. Custom Cop を活用し課題を攻める • StandardError を握りつぶせない Custom Cop # bad begin some_method rescue => e handle_error end # bad begin some_method rescue StandardError => e handle_error end # good begin some_method rescue => e handle_error raise e end # good begin some_method rescue JSON::ParserError => e handle_error end
63. このコードも RuboCop 違反となる def show result = begin ResponseGenerator.call(params) rescue => e Sentry.capture_exception(e) end render json: result end
64. こうしないといけない def show result = begin ResponseGenerator.call(params) rescue => e Sentry.capture_exception(e) raise e end render json: result end
65. こうしないといけない def show result = begin ResponseGenerator.call(params) rescue => e Sentry.capture_exception(e) raise e end render json: result end これいらないな...？
66. エラートラッカーに明示的に送りたい時 is 何？ • 基本的にランタイムで例外が発生した時にはエラートラッ カーに送られるようになっている • コンテキスト特有の値も例外ハンドリング内で行わなくて もに事前に設定しておける ◦ 例えば Sentry の場合 https://docs.sentry.io/platforms/ruby/enrichin g-events/context/
67. どういうときに明示的におくられていたのか • 何らか想定していない例外が起きた時に処理は止めたくな いが例外の発生はエラートラッカーに送りたいとき
68. どういうときに明示的におくられていたのか • 何らか想定していない例外が起きた時に処理は止めたくな いが例外の発生はエラートラッカーに送りたいとき それって Un Expected な例外を ハンドリングしていないか...？
69. PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 より
70. Sentry.capture_exception を取り締まる Custom Cop
71. 過激な Custom Cop が爆誕 def show result = begin ResponseGenerator.call(params) rescue => e Sentry.capture_exception(e) raise e end render json: result end RuboCop 違反となる
72. 立ち返るとこうすれば十分だったり def show result = ResponseGenerator.call(params) render json: result end
73. やっぱりこうすれば十分だということ def show result = begin ResponseGenerator.call(params) rescue ResponseGenerator::SomeError return render status: :bad_request end render json: result end
74. RuboCop 違反によって 立ち止まって考える タイミングを得られる
75. とはいえいろんなケースがある def show result = begin ResponseGenerator.call(params) rescue ResponseGenerator::SomeError return render status: :bad_request end render json: result end 発生自体は 知りたいケースがある
76. Expected だが発生自体はログに残したいケース • 外部システムの Web API を利用している ◦ 一定エラーが起きるケースは想定されるが、想定以上 に頻繁にエラーが起きたらそれは知りたい • リアルタイムに処理したいものではないが、後でまとめて なんらかの処理を行う必要がある
77. （再掲）エラートラッカーがオオカミ少年に • 何か例外的な事象が起きた時に最優先で取り組むための ツールのはず • 便利ログツールとして利用すると「割れ窓」になってしま う • 本当に例外的な事象が起きていても気付けない Expected だがログに残したいとき エラートラッカーを利用しない
78. ログの利用用途によって送り先を変える • 一定エラーが起きるケースは想定されるが、想定以上に頻 繁にエラーが起きたらそれは知りたい ◦ Datadog, NewRelic など APM を利用すると便利 ◦ X分以内にY回発生したらアラートを鳴らすといったこ とが簡単に設定できる
79. ログの利用用途によって送り先を変える • リアルタイムに処理したいものではないが、後でまとめて なんらかの処理を行う必要がある ◦ アプリケーションのDBに書けばよい ◦ 検索しやすいストレージもおすすめ ▪ S3に構造化して保持しておくと Athena でクエリで きる ▪ BigQuery とか
80. 用途に応じて書き込み先を変える def show result = begin ResponseGenerator.call(params) rescue => e logger = Logger.new('hoge.log') logger.error(e) end render json: result end 謎ログを やめられる
81. こうして秩序がもたらされ るための土台作りができてここからコツコツ改善していけばもたらされるのではなかろうかという雰囲気になっ たのであった
82. まとめ • 例外を整理した ◦ 利用者からの入力は基本的に Expected として扱う ◦ コンテキストから Accept か Un Accept か決めていく ◦ 例外をまるごとハンドリングしない ◦ それは本当に Expected か？ • 「例外を丸ごとハンドリングしない」という機械的な制約 をつけることで増殖を防ぎ、改善を進められた