スケジュールジョブ（CronJob）の実行失敗通知基盤における成功と失敗 / Success and failure in scheduled job execution failure notification infrastructure

Wantedly Tech Night 〜サービスを支えるインフラ/SRE技術〜
https://wantedly.connpass.com/event/332164/

Transcript

1. © 2024 Wantedly, Inc. スケジュールジョブ（CronJob）の 実行失敗通知基盤における成功と失敗 Nov. 20 2024 - Takayuki Kasai @unblee Wantedly Tech Night 〜サービスを支えるインフラ /SRE技術〜
2. © 2024 Wantedly, Inc. 持ち帰って欲しいこと 価値のある・説明できる基盤 を作るために 「独りよがりのプラットフォーム」 を読もう！ https://speakerdeck.com/toricls/for-whom-that-platform-runs Tori Hara, CloudNative Days Tokyo 2020
3. © 2024 Wantedly, Inc. 話すこと 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5.
4. © 2024 Wantedly, Inc. 背景 何に困っていたか 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5.
5. © 2024 Wantedly, Inc. 背景 • このスライドにおけるスケジュールジョブ の定義 ◦ ⇒ 特定の時間帯や時刻に自動的に実行される処理 • ウォンテッドリーでの事例 ◦ Kubernetes の CronJob で実行している ◦ キャッシュの暖気 ◦ 会計処理 ◦ 不要なリソースの削除 ◦ etc...
6. © 2024 Wantedly, Inc. 課題 何を解決したかったか 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5.
7. © 2024 Wantedly, Inc. 課題 • スケジュールジョブが実行途中で失敗・中断 されたり スケジュール通りに実行されない ケースはとても多い... ◦ BigQuery の内部エラーでクエリが実行できない ◦ ひとつ前のスケジュールジョブが次のスケジュールまで長時間実行された ▪ 意図せず同時実行されてしまったり、実行されなかったり ◦ 時間経過によって扱うデータ量が増加したことに気付かずメモリ不足で OOMKiller • 完璧に実行するのはとても難しい
8. © 2024 Wantedly, Inc. 課題 • そもそもスケジュール通り実行されなかったことに 気づけなかった ◦ 問題検知が遅れることで障害の規模が広がる ◦ 問題が潜在化し対処する判断ができない • スケジュール通りに実行されなかったときに 気づける仕組み が必要だった ◦ もちろん自動的に再実行できる・それで問題無いならそれが最善（全てそれで解決したい...！） ◦ べき等かがわからないスケジュールジョブがとても多かったので全てを自動的に再実行できなかった
9. © 2024 Wantedly, Inc. やったこと どうやって解決したか 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5.
10. © 2024 Wantedly, Inc. やったこと スケジュールジョブがスケジュール通り実行されなかったことを検 知してSlack に通知してくれる仕組みを作った 1. スケジュール通り実行はしたが失敗したケース 2. 実行がスケジュール通り行われなかったケース
11. © 2024 Wantedly, Inc. やったこと スケジュール通り実行はしたが失敗したケース CronJob Job Pod schedule: 0 19 * * * 実行失敗 (exit!=0) Custom Controller Slack 監視 通知
12. © 2024 Wantedly, Inc. Honeybadger Check-Ins やったこと 実行がスケジュール通り行われなかったケース Honeybadger Check-Ins とは 指定したスケジュール時刻から n分以内に HTTP リクエストが届かないと Webhook を発行するサービス Honeybadger Check-Ins とは Report Period: 0 19 * * * Grace Period: 10minutes 19:01 HTTP GET 19:11 HTTP GET 何もしない 任意の エンドポイント Webhook 発行
13. © 2024 Wantedly, Inc. やったこと 実行がスケジュール通り行われなかったケース CronJob Costom Controller CronJob の Pod Template の initContainer に Honeybadger Check-Ins のエンドポイントを curl で叩く処理を差し込む initContainers: - command: - sh - -c - curl -v https://api.honeybadger.io/v1/check_in/XXX || (echo 'retry after sleep 10s';sleep 10 && curl -v https://api.honeybadger.io/v1/check_in/XXX) || (echo 'retry after sleep 30s';sleep 30 && curl -v https://api.honeybadger.io/v1/check_in/XXX) || true Honeybadger Check-Ins とは 指定したスケジュール時刻から n分以内に HTTP リクエストが届かないと Webhook を発行するサービス CronJob 実行前の仕込み
14. © 2024 Wantedly, Inc. やったこと 実行がスケジュール通り行われなかったケース スケジュール通り実行される場合 CronJob Job Pod Honeybadger Check-Ins 19:02 curl 実行 schedule: 0 19 * * * Report Period: 0 19 * * * Grace Period: 10minutes 19:00-19:10 以内に リクエストを受け付けたので 何もしない
15. © 2024 Wantedly, Inc. やったこと 実行がスケジュール通り行われなかったケース スケジュール通り実行さ れない場合 CronJob ？ Honeybadger Check-Ins schedule: 0 19 * * * Grace Period を超えても リクエストが来ない 通知サーバー Webhook 発行 Slack 通知
16. © 2024 Wantedly, Inc. 結果どうなったか どういう成功、失敗があったか 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5.
17. © 2024 Wantedly, Inc. 結果どうなったか • 課題感である「問題に気付く」ことはできるようになった ◦ 問題検知が遅れることで障害の規模が広がる ◦ 問題が潜在化し対処する判断ができない • 新たな課題が発生した ◦ 組織設計に合わせた通知設計 ◦ 通知後のアクションがしやすい仕組み・取り組み
18. © 2024 Wantedly, Inc. 結果どうなったか 成果について 結果的に内部品質の向上に貢献 できた 👏 • 問題検知の早期化によって障害規模の拡大を防止する • 通知頻度による問題の顕在化によって改善サイクルが回る スケジュールジョブが期待したスケジュール通りに 実行されていなかったことに気づくことができるようになった 1. スケジュール通り実行はしたが失敗したケース 2. 実行がスケジュール通り行われなかったケース
19. © 2024 Wantedly, Inc. 結果どうなったか 運用したことでわかったこと • 組織設計に合わせた通知設計が必要 ◦ 退職者やチーム構成の変化等で誰が受け取って対応するのかうやむやになりがち ▪ 責務が良くも悪くも流動的な組織設計に起因する問題 • 通知後のアクションがしやすい仕組み・取り組みが必要 ◦ 誰も知識を持っていない・引き継がれずに触れなくなったものが多数ある ◦ べき等かどうかわからなくて再実行していいかどうか判断できない ◦ どのくらいの緊急度・重要度でいつまでに対応するべき問題なのかがわからない ▪ incident response における Severity のようなものが無い ▪ 数が多すぎて Severity の判断にリソースを割きづらい
20. © 2024 Wantedly, Inc. 得られた学び・まとめ 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5. 1. 2. 3. 4. 背景 課題 やったこと 結果どうなったか 得られた学び・まとめ 5.
21. © 2024 Wantedly, Inc. 得られた学び‧まとめ • ペインポイントは何かを捉える ◦ スケジュールジョブの失敗に気付きたい（これはただの How） ◦ 問題検知の早期化によって障害規模の拡大を防止したい ◦ 問題の顕在化によって改善をするためのリソース投下判断をやりやすくしたい • 計測可能な課題設定をする ◦ 計測出来ない＝成果が明確でなければ組織として基盤を使い続ける価値・仕事をした自分の価値が説明できない • 基盤設計は組織設計に寄り添う ◦ 人に何かを伝える仕組みは人の移動によって簡単に壊れる • 作って終わりではなく啓蒙活動を含む運用・改善を継続的に回す ◦ 中途半端に価値があると良くないとわかっていても、慣れてしまうことで改善のモチベーションが生まれにくくなる 価値のある・説明できる基盤を作るためにはどうすればいいか
22. © 2024 Wantedly, Inc. 持ち帰って欲しいこと 価値のある・説明できる基盤 を作るために 「独りよがりのプラットフォーム」 を読もう！ https://speakerdeck.com/toricls/for-whom-that-platform-runs Tori Hara, CloudNative Days Tokyo 2020
23. © 2024 Wantedly, Inc. ⾃⼰紹介 名前 笠井 貴之（かさい たかゆき） アカウント名 GitHub, X @unblee 所属 Infra Squad 入社 2019年新卒（6年目）
24. © 2024 Wantedly, Inc. （再）得られた学び‧まとめ • ペインポイントは何かを捉える ◦ スケジュールジョブの失敗に気付きたい（これはただの How） ◦ 問題検知の早期化によって障害規模の拡大を防止したい ◦ 問題の顕在化によって改善をするためのリソース投下判断をやりやすくしたい • 計測可能な課題設定をする ◦ 計測出来ない＝成果が明確でなければ組織として基盤を使い続ける価値・仕事をした自分の価値が説明できない • 基盤設計は組織設計に寄り添う ◦ 人に何かを伝える仕組みは人の移動によって簡単に壊れる • 作って終わりではなく啓蒙活動を含む運用・改善を継続的に回す ◦ 中途半端に価値があると良くないとわかっていても、慣れてしまうことで改善のモチベーションが生まれにくくなる 価値のある・説明できる基盤を作るためにはどうすればいいか