👋
AWS Step Functions を使ったバッチ処理方式の設計書を完成させる
AWS Step Functions を使ったバッチ処理方式の設計書を完成させるには、以下の3つの観点から情報を集めて、整理し、アウトプットを作成する必要がある。
1. 確認すべきこと（情報収集項目）
| 項目 | 内容 | 補足 |
|---|---|---|
| 処理全体の目的 | 何のためのバッチ処理か？ | 業務要件やトリガー条件も確認 |
| 各ステップの処理内容 | 各ステップで何をするのか？ | Lambda、Batch、Glue など利用するサービス |
| 実行順序・依存関係 | ステップ間の順序・条件分岐は？ | 並列実行や条件による分岐も含める |
| 入出力データの形式 | JSON, CSV, DBなど | ステート間でのデータ受け渡し内容も |
| エラーハンドリング | 失敗時の対応・リトライ戦略 | Catch/Retryポリシー、DLQ活用有無 |
| 実行トリガー | 手動 or イベント駆動？ | CloudWatch Events, EventBridge, API Gatewayなど |
| 実行頻度 | 毎時・毎日・月次など | スケジューリング要件（cron式など） |
| タイムアウト/実行時間の目安 | 各処理の最大所要時間 | SLAやタイムアウト設定に影響 |
| 実行環境 | 実行するリージョン、IAMロール | 最小限の権限で設計する原則に注意 |
| モニタリング・ログ | CloudWatch Logs / メトリクスなど | ログ出力内容、Datadog連携なども確認 |
2. 確認する手段・方法
| 方法 | 対象 | 説明 |
|---|---|---|
| 関係者ヒアリング | 業務担当者、開発者、SRE | 要件や現行フローの把握 |
| システム仕様書の確認 | 既存設計書・運用資料 | 既存バッチの処理内容・条件確認 |
| プロトタイピング | Step Functions ワークフロー作成 | 動作確認を通じた設計精度の向上 |
| AWSサービスのドキュメント確認 | Step Functions、Lambda、Batchなど | パラメータ・制限事項などの把握 |
| 実運用ログの調査 | CloudWatch Logs、S3など | 実績に基づく設計調整（処理時間、エラー率など） |
3. 設計書としてのアウトプット
| セクション名 | 内容 |
|---|---|
| 背景・目的 | なぜこのバッチが必要か、Step Functionsを使う理由 |
| 処理概要 | ワークフロー図（フロー図 or ASLコード）と説明 |
| ステップ定義 | 各処理の詳細（Lambda名、入力形式、出力形式など） |
| データフロー | データ構造、スキーマ、流れ（JSON例など） |
| エラー処理 | リトライ戦略、Catch構成、アラート連携 |
| トリガー設定 | イベント or スケジュール設定の詳細 |
| 実行環境 | IAMポリシー、リージョン、ステージング/本番の違い |
| 非機能要件 | 可用性、スケーラビリティ、性能、セキュリティなど |
| モニタリング・運用 | CloudWatchメトリクス、ログ管理、通知設計 |
| 想定される運用・障害対応フロー | 手動対応が必要なケースと対応方法 |
Discussion