Dev Study
AWSサービスの内部原理 コース

92. Mapは反復を子に分ける — インラインの40並列と、履歴ごと分離する分散モードの10,000並列

同じステップをデータの数だけ並べる「データ並列」が、なぜ2つのモードに分かれるのか——インラインの40並列と分散モードの10,000並列を、履歴という追記ログの設計問題として図で追っていきます。

① Map状態 — 「同じ形の仕事」をデータの数だけ並べる

JSON配列の入力[item1, item2, … , itemN]
結果を集める(fan-in)
反復1同じステップ
反復2同じステップ
反復3同じステップ
反復N同じステップ
横並び=並列に実行
結果の配列出力
  • 公式の定義: 「Use the Map state to run a set of workflow steps for each item in a dataset. The Map state's iterations run in parallel」
  • Parallel状態が「ブランチの形が違う仕事を並べる」のに対し、Mapは「同じ形の仕事をデータの数だけ並べる」
  • これはMapReduceのMapそのもの——CS基礎で言うデータ並列とfan-out/fan-inの実装

Map状態はデータセットの各アイテムに同じステップ列を走らせる「分割統治」の状態。大きすぎる仕事を独立した小さな仕事に割り、最後に結果を集める。分かれ道はこの反復を「どこで」走らせるか——ここから2つのモードに分岐します。

② インラインモード(既定) — 反復は親の文脈で走り、履歴も親に追記される

親ワークフロー実行実行履歴=1本の追記ログ
親の制約がそのまま天井になる
反復1履歴は親に追記
反復2履歴は親に追記
反復3 …履歴は親に追記
最大40並列
入力 256KiBJSON配列のみ
履歴 25,000イベント上限
並列 40同時反復の上限
  • 公式表現: 「each iteration of the Map state runs in the context of the workflow that contains the Map state. Step Functions adds the execution history of these iterations to the parent workflow's execution history」
  • 並列度は「supports up to 40 concurrent iterations」
  • 制約は「a limit of 256 KiB on the input payload size and 25,000 entries in the execution event history」
  • 既定モードはこのInline: 「By default, Map states run in Inline mode」

インラインモードでは反復は親ワークフローの中で走り、反復の実行履歴も親の1本の追記ログに書き込まれる。ゆえに親の上限——入力256KiB、履歴25,000イベント、並列40——がそのまま天井になる。この「1本のログに全部書く」設計こそが、レッスン2で見た追記ログの上限に正面からぶつかる原因です。

③ 分散モード — 反復を「子」に切り出し、履歴を階層化して上限を突破する

Map状態Mode: DISTRIBUTED
親の履歴には「子を起動した」ことだけ記録=履歴の階層化
詳細は各子のログに分かれる
子実行1独立した実行履歴
子実行2独立した実行履歴
子実行3 …独立した実行履歴
子実行M独立した実行履歴
上限の突破親は25,000イベントの壁を回避
  • 公式表現: 「the Map state runs each iteration as a child workflow execution, which enables high concurrency of up to 10,000 parallel child workflow executions. Each child workflow execution has its own, separate execution history from that of the parent workflow」
  • MaxConcurrencyを指定しない(またはゼロを指定した)場合は「Step Functions doesn't limit concurrency and runs 10,000 parallel child workflow executions」——つまり未指定なら10,000並列で走る
  • 履歴制限の回避: 「overcome execution history limitations because the child workflow executions … maintain their own, separate execution histories」

分散モードは各反復を子ワークフロー実行として起動し、子は親から独立した自分の実行履歴を持つ。つまり「1実行の履歴は25,000イベントまで」という追記ログの上限を、親は子の起動だけを記録し詳細は子のログに分ける——履歴を階層化することで突破している。ログの設計問題をログの分割で解く、という発想です。これはDynamoDB編で見た「1つの器の限界をパーティション分割で超える」のと同じ原理のログ版です。

④ 分散モードの装備 — S3を入口に、S3を出口に、Map Runで束ねる

JSONファイルS3上・配列を含む
CSVファイルS3上
S3オブジェクトリスト
S3インベントリ
バッチ単位で子ワークフロー実行へ
ItemBatcherアイテムをまとめて子に渡す
全子実行の結果をS3へ書き出す
Map Run子実行の集合を束ねる1リソース
DescribeMapRunで監視・CloudWatchへメトリクス
ResultWriter結果の出口(S3)
  • ItemReaderが受け付けるデータソース(公式)は5種: 「JSON array passed from a previous step in the workflow / JSON file in an Amazon S3 bucket that contains an array / CSV file in an Amazon S3 bucket / Amazon S3 object list / Amazon S3 inventory」——前のステップからのJSON配列も引き続き使える
  • ItemBatcher: 「process the dataset items in batches. Each child workflow execution then receives a batch」
  • ResultWriter: 「the Amazon S3 location where Step Functions writes all child workflow execution results」
  • Map Run: 「a set of child workflow executions that a Distributed Map state starts」——DescribeMapRun APIで監視でき、CloudWatchへメトリクスを出す

分散モードはS3を入口(ItemReader)にすることで入力256KiBの壁を越え、ItemBatcherでアイテムをまとめて子に渡し、結果はResultWriterでS3へ書き出す。子実行の集合はMap Runという1つのリソースに束ねられ、DescribeMapRunで監視できる。S3をデータソース兼結果置き場にする構図はS3編の復習そのものです。

⑤ 失敗の制御 — しきい値で「どこまで許すか」を宣言する

子実行: 失敗
子実行: 成功
子実行: タイムアウト
しきい値と比較して Map Run 全体を判定
許容失敗率ToleratedFailurePercentage(既定0%)
許容失敗数ToleratedFailureCount
併用時はどちらか超過で失敗
以内Map Runは失敗しない
超過States.ExceedToleratedFailureThreshold で失敗
  • 公式: 「The default percentage value is zero, which means that the workflow fails if any one of its child workflow executions fails or times out. If you specify the percentage as 100, the workflow won't fail even if all child workflow executions fail」——0%=1つでも失敗すれば全体が失敗(既定)、100%=全滅しても失敗しない
  • 超過時: 「Step Functions returns a States.ExceedToleratedFailureThreshold error」
  • パーセントの計算は「total number of failed or timed out items divided by the total number of items」——失敗だけでなくタイムアウトも数える
  • 注意: 「Step Functions may continue to run child workflows in a Map Run even after the tolerated failure threshold is exceeded, but before the Map Run fails」——超えても即座に全停止するとは限らない

バッチ処理では「1件も失敗を許さない」と「多少の欠けは許容する」を宣言で切り替えたい。ToleratedFailurePercentage/Countはその許容度のしきい値で、既定0%(1つの失敗またはタイムアウトで全体失敗)、100%(全滅しても失敗しない)。超えるとStates.ExceedToleratedFailureThresholdでMap Runが失敗する。全体をしきい値で判定するこの発想は、可観測性編のアラームがバッチ処理に現れた形です。

⑥ モードの選び方 — 履歴と並列と入力サイズの天井で決める

データ並列の仕事
対応するモードを選ぶ
小規模で収まる履歴<25,000・並列≦40・入力≦256KiB
大規模入力>256KiB・履歴>25,000・並列>40 のいずれか
インライン(既定)親の文脈で走る
分散モードStandardのみ対応
子はSTANDARD/EXPRESSを選べる(DISTRIBUTED指定時は必須)
  • 公式の選択基準: 「Use the Map state in Inline mode if your workflow's execution history won't exceed 25,000 entries, or if you don't require more than 40 concurrent iterations」
  • 分散モードを使う条件: 「The size of your dataset exceeds 256 KiB. / The workflow's execution event history would exceed 25,000 entries. / You need a concurrency of more than 40 concurrent iterations」
  • 制約: 「Distributed mode is supported in Standard workflows but not supported in Express workflows」
  • 子の実行タイプ: 「ExecutionType – Specifies the execution type for the Map workflow as either STANDARD or EXPRESS. You must provide this field if you specified DISTRIBUTED」

選び方は天井で決まる——履歴25,000イベント・並列40・入力256KiBのどれかに当たるなら分散モードへ。分散モードは親がStandardワークフローのときだけ使え、子の実行タイプはSTANDARD/EXPRESSを選べる(DISTRIBUTED指定時は必須)。大量・短時間の子はExpressに、という前レッスン(ワークフロータイプの使い分け)の実践がここに現れます。

公式ドキュメントで詳しく ↗