非同期処理サービスの全体像
AWS の非同期処理サービスは「メッセージの送り方」と「処理のトリガー」で大きく分類できる。
| サービス | パターン | オンプレ対応 | 主な用途 |
|---|---|---|---|
| SQS | キュー（Pull型） | MQ / ActiveMQ / RabbitMQ（一部） | 処理の非同期化・スパイク吸収 |
| SNS | Pub/Sub（Push型） | メッセージブローカー / Kafka（一部） | 1対多通知・ファンアウト |
| EventBridge | イベントバス / スケジューラー | JP1 / Cron / イベント連携基盤 | 定期実行・AWS サービス間イベント連携 |
| Step Functions | ステートマシン（ワークフロー） | JP1 / Workflow ツール | 複雑なジョブ依存関係・エラーハンドリング |
判断フロー
SQS — キューイング（Producer-Consumer）
SQS（Simple Queue Service）はメッセージキューサービスだ。 送信者（Producer）がキューにメッセージを送り、受信者（Consumer）がポーリングで取得して処理する Pull 型のモデルだ。
SQS を選ぶケース：
- リクエストのスパイクをキューで吸収し、バックエンドへの負荷を平準化したい
- 注文処理・決済処理など、取りこぼしなく1件ずつ確実に処理したい
- Consumer の処理が遅い場合に Producer をブロックしたくない（疎結合化）
SQS のキュータイプ：
| タイプ | 特徴 | 向いているケース |
|---|---|---|
| 標準キュー | 高スループット・少なくとも1回配信（重複あり）・順序保証なし | スループット重視・処理が冪等なケース |
| FIFOキュー | 厳密な順序・1回のみ配信（重複なし）・スループット上限あり | 順序と重複排除が必要（金融・在庫など） |
💡 デッドレターキュー（DLQ）を必ず設定する
処理に繰り返し失敗したメッセージは DLQ（Dead Letter Queue）に移動させる設定を入れること。DLQ がないと、処理できないメッセージがキューに留まり続け、Consumer が無限ループでリトライし続けるコスト問題が発生する。
SNS — Pub/Sub（1対多配信）
SNS（Simple Notification Service）は1つのメッセージを複数の受信者に同時配信する Pub/Sub モデルだ。 トピックに発行（Publish）されたメッセージは、サブスクライブしているすべてのエンドポイント（Lambda / SQS / HTTP / Email など）に配信される。
SNS の主な用途：
- ファンアウト：1つのイベントを複数の SQS キューに同時配信（例: 注文完了 → 在庫更新キュー + 配送依頼キュー）
- アラート通知：CloudWatch アラーム → SNS → Email / Slack（Lambda 経由）
- モバイルプッシュ通知：iOS / Android 向けプッシュ通知
✅ SNS + SQS の組み合わせが定番
SNS で 1対多に配信し、各受信者は SQS キューを経由して非同期処理する「SNS → SQS → Lambda/ECS」のパターンが最も一般的だ。SNS に直接 Lambda をサブスクライブすることもできるが、SQS を挟むことでバッファリング・リトライ・DLQ の機能が追加される。
EventBridge — イベントバス・スケジューラー
EventBridge はサーバーレスのイベントバスで、AWS サービス間・SaaS・自社アプリからのイベントを ルールに基づいてターゲット（Lambda / ECS / SQS 等）に配信する。 また EventBridge Scheduler は Cron 式での定期実行や1回限りの未来時刻実行をサポートする。
EventBridge を選ぶケース：
- 定期バッチ（Cron の代替）：「毎日 2:00 に Lambda を実行」→ EventBridge Scheduler + Lambda
- AWS サービス間のイベント連携：「EC2 インスタンスが停止したら自動で Lambda を実行」
- SaaS イベント連携：Salesforce / Zendesk 等の SaaS イベントを AWS サービスに連携
- カスタムイベントバス：マイクロサービス間のイベント駆動アーキテクチャ
💡 JP1 / Cron の移行先
オンプレの JP1 や crontab による定期バッチは、EventBridge Scheduler + Lambda または ECS タスクで置き換えるのが標準的だ。ジョブ間の依存関係が複雑な場合は Step Functions と組み合わせる。
Step Functions — ワークフローオーケストレーション
Step Functions はステートマシンベースのワークフローサービスだ。 複数の Lambda / ECS タスク / API 呼び出しを 条件分岐・並列実行・エラーリトライ・タイムアウトを含む形で定義できる。
Step Functions を選ぶケース：
- 複数ステップのジョブに依存関係がある（ジョブ A 完了後にジョブ B を実行など）
- ステップごとのエラーハンドリング・リトライ・フォールバックが必要
- 長時間実行のワークフロー（Lambda の15分制限を超える処理の組み合わせ）
- 人間の承認（ヒューマンアプルーバル）が途中に入るワークフロー
ワークフロータイプ：
- Standard：実行状態を保持。最大1年間。監査ログ完備。コストは実行ごと
- Express：高スループット・短時間処理向け。最大5分。コストは実行数＋時間
オンプレ対応マッピング
| オンプレ | AWS サービス | 補足 |
|---|---|---|
| crontab / at コマンド | EventBridge Scheduler | Cron 式をそのまま使える |
| JP1 / A-AUTO（ジョブスケジューラー） | EventBridge + Step Functions | ジョブ依存関係は Step Functions |
| ActiveMQ / RabbitMQ（キュー） | SQS（標準 or FIFO） | AMQP 互換は Amazon MQ も選択肢 |
| Kafka（メッセージストリーム） | MSK（Managed Streaming for Kafka） | Kafka 互換 API をそのまま使えるマネージドサービス |
| 独自イベント連携基盤 | EventBridge（カスタムバス） | イベントスキーマのレジストリ機能あり |
実務での組み合わせパターン
実際の移行でよく使う組み合わせパターンを示す。
パターン1：非同期 API 処理（スパイク吸収）
Web API → SQS → Lambda（またはECSタスク）→ DB
パターン2：定期バッチ（Cron 代替）
EventBridge Scheduler → Lambda（軽量処理）
EventBridge Scheduler → ECS タスク（重い処理・15分超）
パターン3：複雑なジョブワークフロー
EventBridge Scheduler → Step Functions（ワークフロー制御） → Lambda / ECS（各ステップ）
パターン4：イベント駆動ファンアウト
アプリ → SNS（トピック） → SQS キュー × n本 → Lambda × n本（並列処理）
✅ 次の章では…
PART 07 では監視・ログの選び方を解説する。CloudWatch / X-Ray / OpenSearch Service の使い分けと、オンプレの Zabbix / Nagios からの移行パターンを整理する。