定期処理の実行時間を監視してますか？

【JAWS-UG 神戸 #15】残暑！LT会
登壇資料です
https://jawsug-kobe.connpass.com/event/407581/

1. Nealle NEALLE 定期処理の実行時間を 監視してますか？ 2026.10.23 JAWS-UG 神戸 #15「残暑！LT会」 株式会社ニーリー 宇田川 涼平 1
2. 自己紹介 Nealle Ryohei Udagawa 宇田川 涼平 [所属・役職] 株式会社ニーリー SRE [経歴] HRテックにエンジニアとして入社し、エンジニア〜EMまで担当。 2026/03にSREとして、ニーリーに入社 [趣味] ・サウナ ・海釣り（最近はじめました） [SNS アカウント] X：@Ryoheiengineer 2
3. プロダクト紹介 Nealle 「Park Direct」は駐車場の募集から契約、決済、管理までをオンラインで完結させるモビリティ 領域のOperating System（Mobility OS）です。 [ここにプロダクト概要図を貼る（前のデッキの3枚目の図）] 3
4. 目次 Nealle 1．なぜ実行時間を監視するのか？ 2．どう検知するか？ 3．まとめ 4
5. Nealle 1．なぜ実行時間を監視するのか？ 5
6. 1．なぜ監視するのか？ - エラー通知の構成 - Nealle 定期処理は Step Functions 経由で実行し、失敗したら Slack に通知していた EventBridge Step Functions ECS RunTask バッチごとの cron ルール 全バッチ共通の1本 Fargate でバッチを実行 失敗（FAILED）したら EventBridge Execution Status Change Lambda 通知文を作る AWS Chatbot SNS （現 Amazon Q Slack Developer） 6
7. Nealle ユーザーが増えてきたある日、ビジネスサイドから 「処理が終わっていないので、状況を 確認してほしい」 エラーではない → 失敗通知は鳴らない 想定時間の超過を検知できず、影響が出る前に打ち手を実行できない状態でした😢 7
8. 1．なぜ監視するのか？ - 遅れも検知したい - Nealle 定期処理の先には、クリティカルな業務がある 定期処理が遅れる 後続の業務が始められない これまで これから 失敗したら通知 失敗したら通知 クリティカルな業務に影響 ＋完了後に、遅れていた実行を通知 8
9. Nealle 2．どう検知するか？ 9
10. 2．どう検知するか？ - 何で測るか- Nealle Step Functionsの完了イベントから開始時刻、終了時刻、想定時間を渡し、Lambdaで計算して通知する ようにした メトリクス: Step Functionsに実行時間（ExecutionTime）はあるが、全バッチが1本のグラフに混ざって区別できない 完了イベント: 実行時間の項目はないが、開始・終了時刻から計算でき、input でバッチも分かる 方式 バッチごとの閾値 バッチ実行経路への変更 判定 CloudWatch Alarm （ExecutionTime） 不可（1系列に混ざる） なし 不採用 Step Functions 内で判定 可 あり（全バッチに波及） 不採用 完了イベント＋Lambda 可（input の閾値） なし 採用 採用理由: ・バッチごとに閾値を変えられる ・責任分離（定期処理の実行は Step Functions、監視は Lambda） 出典: docs.aws.amazon.com/step-functions/latest/dg/procedure-cw-metrics.html 10
11. 2．どう検知するか？ - 実行時間アラートの構成 - Nealle メトリクスではなく、完了イベントで判定する EventBridge Step Functions ECS RunTask input にバッチ名・閾値 全バッチ共通の1本 Fargate でバッチを実行 成功（SUCCEEDED）したら EventBridge Execution Status Change Lambda 実行時間と閾値を比較 AWS Chatbot SNS （現 Amazon Q Slack Developer） Lambda は完了イベントを受け取り、実行時間（stopDate - startDate）を自分で計算して input の閾値と比較 完了後の通知 → 処理時間が伸びている傾向を早めにつかむ用途（実行中の検知は次の課題） 出典: docs.aws.amazon.com/step-functions/latest/dg/eventbridge-integration.html 11
12. 2．どう検知するか？ - Terraform で閾値を必須にする - Nealle 閾値はバッチ定義（Terraform）に持たせ、EventBridge の input で Lambda まで渡す 定期処理の定義（共通モジュールの呼び出し） module "batch_xxx" { source = "../../modules/eventbridge/scheduled_task" batch_job_name = "xxx" ... # 必須（default なし・10分以上） duration_threshold_minutes = 30 Terraform の変数 duration_threshold_minutes = 30 EventBridge の input_template 実行 input に閾値を埋め込む } Step Functions の実行 input 完了イベントにそのまま入る 未指定だと terraform validate が失敗 → 今後追加される定期処理も、想定時間の入力が必須 Lambda input の閾値を読んで判定 12
13. 2．どう検知するか？ - 通知された様子- Nealle 通知内容にはランブックも添付して、すぐにアクションできるようにしています 12
14. Nealle 3. まとめ 9
15. まとめ Nealle エラーだけではなく、実行時間の監視も必要 ・想定より実行時間が伸びたときに、思わぬ形でユーザーへの影響が出る Step Functions 1本構成なら、メトリクスではなくイベントで見る ・ExecutionTime の次元は StateMachineArn → バッチを区別できない ・完了イベントの input に閾値を持たせて判定する 形骸化しないように、新たに定期処理を追加するときも想定時間を必須化 ・Terraform のバリデーションで想定時間を必須にする 13
16. Nealle Thank you 14