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