サービス開発課のくればやしです。Step Functionsの分散マップモードを使って、ステートマシンの実行のハード制約を回避する取り組みを行いましたので、ご紹介します。

概要

AWSの運用自動化ツールのCloud Automatorは、様々なAWSの運用のオペレーションを自動化する運用ジョブのご利用が多いですが、「EBSバックアップチェック」という機能も広くご利用頂いています。

この機能は、お客さまのEBSのバックアップ状況をチェックし、バックアップ漏れがあった場合に、メールで通知させて頂くサービスです。本サービスの実現には、バックエンドにStep Functionsを用いています。

Step Functionsのハード制限としてイベント履歴が25,000 という制約があります。イベント履歴がこの値を超えると、ステートマシンの実行に失敗してしまいます。

docs.aws.amazon.com

EBSバックアップチェック機能ですが、大変多くのお客さまにご利用頂いており、さらに対象のAWSアカウントが増えていくたびにStep Functionsの実行イベントが増えていくアーキテクチャとなっていたため、ある日イベント履歴数の上限に達してしまう事態となりました。

そこで、上記リンクでも紹介されている通り、分散モードを用いたマップの実行に切り替えることで、イベント数の上限に実質的に達することの無いように改修することにしました（EBSバックアップチェック機能リリース時は分散モードがまだ無かった）。

分散モードを導入したとしても、子ワークフローそれぞれのイベント履歴数上限は存在するため、イベント履歴の消費がマップの中の単一の直列の実行で多く消費されているとしたら、分散マップモードに変更しても子ワークフローの中でイベント履歴を多く消費してしまい、リスクの回避につながらないかもしれません。しかし、今回のケースでは並行処理の数が多いことがイベント履歴数が多い原因となっていましたので、分散モードの導入が効果的と考えられました。

長時間の実行でこのクォータに達しないようにするには、次のいずれかの方法を試行できます。マップステートを分散モードで使用します。このモードでは、Map 状態は各反復を子ワークフロー実行として実行します。これにより、最大 10,000 件という高い並列性を持つの並列子ワークフロー実行が可能になります。それぞれの子ワークフローの実行には、親ワークフローとは別の実行履歴があります。履歴のクォータに到達しないようにする - AWS Step Functions

docs.aws.amazon.com

やったこと

分散モードの導入は非常に簡単で、基本的にはマップの定義箇所に以下を追加するだけです。

"ProcessorConfig": {
  "Mode": "DISTRIBUTED",
  "ExecutionType": "EXPRESS"
},

ハマった点として、分散モードの場合、マップの実行は子ワークフロー実行として、親ワークフローとは別々の実行になるため、親と子は別の実行名となります。既存のEBSバックアップチェックの実装では、実行名をコンテキストオブジェクトから取得して利用していましたが、子ワークフローから親ワークフローの名前は取得できないようなので、親の実行名をイベントオブジェクトを介して取り回すこととしました。

また、分散モードの導入に直接関係はありませんが、マップで以前から使用可能となっていた Iterator や Parameters 属性は非推奨となっていたため合わせて修正しました（現時点では変更してもしなくても動作影響は無いようです）。

Although you can continue to include Map states that use the following fields, we highly recommend that you replace Iterator with ItemProcessor and Parameters with ItemSelector. docs.aws.amazon.com/step-functions/latest/dg/concepts-asl-use-map-state-inline.html