ジョブ管理システムをAWS Step Functionsに移行する時の勘所

ジョブ管理システムをAWS Step Functionsに移行する際に考えるべきこと注意することをまとめてみました。

Transcript

1. ジョブ管理システムを
 AWS Step Functionsに移行する時の勘所
 AWS事業本部 コンサルティング部 のんピ

2. 2 自己紹介 { "ニックネーム": "のんピ", "Twitter ID": "@non____97", "部署": "AWS事業本部 コンサルティング部", "興味のあること": "面白そうなブログネタ探し", "好きなAWSサービス" : [ "AWS Step Functions", "AWS Transit Gateway", "Amazon FSx for NetApp ONTAP" ], "称号" : [ "2022 APN ALL AWS Certifications Engineers", "2022 APN AWS Top Engineers (Networking)" ] }
3. 3 ジョブ管理システムの運用って 大変なことが多い
4. 4 そもそもジョブ管理システムとは 複数のジョブの起動や終了を制御するシステム
5. 5 ジョブ管理システムの仕組み
6. 例) Web/DBサーバーのバックアップのジョブネット 6 ジョブ管理システムのイメージ Webサーバーの 停止 DBサーバーの 停止 Webサーバーの バックアップ DBサーバーの 起動 Webサーバーの 起動 DBサーバーの バックアップ
7. 7 ジョブ管理システムの主な機能 • ジョブの実行スケジューリング • ジョブの監視 • 自動リトライ • ジョブの実行結果のロギング
8. 8 よくあるジョブ管理システム運用の課題 • 非常に高い可用性が求められる • マネージャーとなるサーバーの管理が必要 • ジョブ管理システムのライセンス費がかかる
9. 9 それ、もしかして AWS Step Functionsに置き換えられるかも
10. 10 AWS Step Functionsとは サーバーレスなワークフローを作成できるマネージドサービス AWS Step Functions をゼロからざっくり理解する AWS再入門ブログリレー 2022 AWS Step Functions編
11. 11 200以上のAWSサービスと連携可能 API呼び出しなどの処理を繋 げてワークフローを構成でき る [アップデート] AWS Step Functionsが200以上の AWSサービスと連携できるようになりました
12. 12 CloudWatch Logs以外にも複数の実行履歴確認方法が AWS Step Functionsのコンソール AWS Step Functionsの新しい実行詳細 ページのコンソールを使ってみた
13. 13 CloudWatch Logs以外にも複数の実行履歴確認方法が X-Ray
14. 14 少なくとも考えるべき方式の一覧 • API / サーバー上のスクリプト実行方式 • スケジュール実行方式 • ステートマシン間連携方式 • 異常終了通知方式 • リトライ方式 • ステートマシンのデプロイ方式
15. 15 API / サーバー上のスクリプト実行方式の例 AWSのAPIの呼び出しはステートマシンで直接 & サーバー上のスクリプト実行は Systems ManagerのRun Command
16. 16 200以上のAWSサービスと連携可能 (再掲) API呼び出しなどの処理を繋 げてワークフローを構成でき る [アップデート] AWS Step Functionsが200以上の AWSサービスと連携できるようになりました
17. 17 呼び出しがサポートされていないAPIの場合 Lambda関数からAWS SDKを使う
18. 18 サポートされているAPIか確認する方法 AWS公式ドキュメントかマネージメントコンソールから確認 Supported AWS SDK service integrations - AWS SDK service integrations
19. 19 サーバー上のスクリプト実行はSSM Run Command "AWS-RunShellScript" or "AWS-RunPowerShellScript" で実行 /usr/local/sbin/stop-httpd.sh
20. 20 オンプレミスのサーバーは? オンプレミスサーバーにSSM Agentをインストールして対応 AWS Systems Managerでオンプレ環境のWindowsを管理する
21. 21 SSM Run Commandの注意点 実行が完了したか定期的にポーリングする必要がある • SSM RunCommandでスクリプトを実行する • ListCommandInvocations APIを呼び出す • SSM RunCommandが正常終了したかどうか確 認する • まだ実行中であれば10秒間待機して再度 ListCommandInvocations APIを呼び出す • 正常終了していれば次の処理に移る • 異常終了していればステートマシン自体を異常終 了させる
22. 22 スケジュール実行方式の例 EventBridgeルールのCron式で制御
23. 23 EventBridgeルールのCron式の例 スケジュール Cron式 毎日午前 10:00 (UTC+0) に実行 cron (0 10 * * ? *) 毎日午後 12:15 (UTC+0) に実行 cron (15 12 * * ? *) 毎週月曜日から金曜日まで午後 6:00 (UTC+0) に実行 cron (0 18 ? * MON-FRI *) 毎月 1 日の午前 8:00 (UTC+0) に実行 cron (0 8 1 * ? *) 15 分ごとに実行 cron (0/15 * * * ? *) 月曜日から金曜日まで 10 分ごとに実行 cron (0/10 * ? * MON-FRI *) 月曜日から金曜日まで午前 8:00 から午後 5:55 (UTC+0) の間に5 分ごとに実行 cron (0/10 * ? * MON-FRI *) 月曜日から金曜日まで開始日の午後10時から翌日の午前2時 (UTC) の間、30分間隔で実行 cron (0/30 20-2 ? * MON-FRI *)
24. 24 Cron式で表現が難しい場合 「祝日や締め日のみ実行 or 実行しない」 • AWS Systems Manager Change Calendarを活用する • ワークフローの前段でSSM Change CalendarのGetCalendarState APIを呼び出して後続の処理を実行すべきか、そうでないかを判 断 • 複数のカレンダーを組み合わせ、ANDやORで評価したい場合も 対応可能
25. 25 SSM Change Calendarとの連携例 GetCalendarState APIで 今日が祝日かどうか判断 祝日をSSM Change Calendarに登録 祝日である場合スキップ(Pass) 祝日でない場合本来の処理(Success)
26. 詳細は以下記事参照 26 SSM Change Calendarとの連携 [AWS Step Functions] AWS Systems Manager Change Calendarと 連携して定期実行処理のイレギュラーケースに対応してみた
27. 27 ステートマシン間連携方式の例 EventBridgeルールのイベントパターンで連携
28. 28 イベントパターンの例 { "source": ["aws.states"], "detail-type": ["Step Functions Execution Status Change"], "detail": { "status": ["SUCCEEDED"], "stateMachineArn": ["<先行ステートマシンのARN>"] } }
29. 29 先行ステートマシンが複数ある場合 • 先行ステートマシンが完了する度に後続ステートマシンを実行 • 後続ステートマシン内で先行ステートマシンが処理した結果が正 しいかを判断
30. 30 先行ステートマシンが複数ある場合の例
31. 31 イベントパターン どの先行ステートマシンが実行完 了した際も、ステートマシンαが起動 するように設定 { "source": ["aws.states"], "detail-type": ["Step Functions Execution Status Change"], "detail": { "status": ["SUCCEEDED"], "stateMachineArn": [ "<ステートマシンAのARN>", "<ステートマシンBのARN>", "<ステートマシンCのARN>" ] } }
32. 32 ステートマシンAのみ実行が完了した場合 1. ステートマシンA〜Cが処理した結果が正しいかを確認する (ステートマシンαを実行しても良い状態か判断) 2. ステートマシンB〜Cの処理が行われていないことを確認 3. ステートマシンαを終了
33. 33 ステートマシンA〜Bの実行が完了した場合 1. ステートマシンA〜Cが処理した結果が正しいかを確認する (ステートマシンαを実行しても良い状態か判断) 2. ステートマシンCの処理が行われていないことを確認 3. ステートマシンαを終了
34. 34 ステートマシンA〜Cの実行が完了した場合 1. ステートマシンA〜Cが処理した結果が正しいかを確認する (ステートマシンαを実行しても良い状態か判断) 2. ステートマシンA〜Cの処理が行われたことを確認 3. ステートマシンαで本来やりたかった処理を続行
35. 35 後続のステートマシンが別アカウントの場合は? EventBridgeルール使用して別アカウントの EventBusにイベントを送信する
36. 36 別アカウントのEventBusにイベントを送信
37. 37 異常終了通知方式の例 EventBridgeルールでメールやSlackに通知
38. 38 異常終了通知のパターン 　
39. 39 参考 　 AWS Step Functions上でエラーが発生した場合の効果的な通知方法を検討してみた
40. 40 リトライ方式の例 ステートマシンを最初から実行しても問題がない ように冪等性のある仕組みにする & タスク毎にリトライ設定を組み込む
41. 41 ステートマシンの途中からの再実行はできない
42. 42 最初から実行し直すことを考慮する 冪等性が重要 • ある操作を1回行っても複数回行っても結果が同じであるようにす る • 対応方法 • 再実行時に実行済みのタスクをスキップする • エラー発生時に最初の状態にロールバックする
43. 43 再実行時に実行済みのタスクをスキップする 同じIDのデータが既にある場合は データを追加しない
44. 44 エラー発生時に最初の状態にロールバックする 　 “Process” で異常が発生した場合 ”Delete Data” で ”Put Data“で追加 したデータを削除する
45. 45 タスクごとに再実行の設定をすることも可能 以下エラー発生時に2 秒、4秒、8秒と待機して最大3回 再実行 • Lambda.ServiceException • Lambda.AWSLambdaException • Lambda.SdkClientException
46. 46 ステートマシンのデプロイ方式例 CDK Pipelinesで複数のアカウントにデプロイ
47. 47 CDK Pipelinesでステートマシンをデプロイ
48. 48 まとめ ジョブ管理システムをAWS Step Functionsに移行する際に考 えることはたくさんある • どのようなジョブネットが稼働しているのか、どうやって運用してい るかを把握しておくことが重要 • AWS Step Functions ≠ ジョブ管理システムなので不足機能がある 場合の対応方法を考える • 例) 休日シフトや日別展開など