サーバーレスアーキテクチャ — Lambda・Step Functions・EventBridge
Lambdaの同時実行制御とスロットリング、Step Functionsによるワークフローオーケストレーション、イベント駆動設計の落とし穴を解説します。
インフラ管理から解放され、需要に応じて自動的にスケールするアーキテクチャの中核が サーバーレスです。本記事ではLambdaを中心とした主要サービスを解説します。
SAA レベル:基礎概念
Lambdaの基本
- コードをアップロードするだけで実行環境が自動的にプロビジョニングされる、イベント駆動型のコンピューティングサービス
- 実行時間とメモリに応じた従量課金(アイドル時のコストはゼロ)
SAA 試験のポイント
Lambda関数の最大実行時間は15分です。それを超える長時間処理には、Step FunctionsやECS/Fargateなど別のサービスを検討する必要がある、という制約がSAAで頻出します。
主要なトリガーサービス
| サービス | トリガーの性質 |
|---|---|
| API Gateway | 同期的なHTTPリクエスト |
| S3イベント | 非同期(オブジェクト作成等) |
| SQS | ポーリングベースの非同期処理 |
| EventBridge | イベントルールに基づく非同期処理 |
SAP レベル:高度な設計シナリオ
同時実行制御とスロットリング
SAP 試験のポイント
Lambdaにはアカウント全体で共有される同時実行数のクォータがあります。特定の関数が予期せず大量のリクエストを受けた場合、アカウント内の他の重要な関数の実行枠まで奪ってしまうリスクがあります。これを防ぐため、SAPレベルでは重要度の低い関数に予約済み同時実行数 (Reserved Concurrency) で上限を設け、逆に重要な関数にはプロビジョニング済み同時実行 (Provisioned Concurrency) でコールドスタートを回避しつつ安定した実行枠を確保する設計が問われます。
| 設定 | 効果 |
|---|---|
| 予約済み同時実行数 | その関数専用の実行枠を確保(同時に他関数のリソースを圧迫しない) |
| プロビジョニング済み同時実行 | 事前にウォームアップされた実行環境を維持し、コールドスタートを回避 |
Step Functionsによるワークフローオーケストレーション
SAP 試験のポイント
複数のLambda関数やサービス呼び出しを組み合わせた複雑な業務フローを、Lambda関数のコード内で直接連携(Lambda同士を呼び出し合う)させる設計は、エラーハンドリングの複雑化、可観測性の低下、実行時間の合算による15分制約への抵触などの問題を引き起こします。SAPレベルでは、Step Functionsでワークフロー自体を宣言的に定義し、各ステップの実行・リトライ・エラーハンドリングをオーケストレーションする設計が推奨されます。
イベント駆動設計の落とし穴
設計上の落とし穴
EventBridgeを使った疎結合なイベント駆動設計は柔軟性が高い反面、イベントの流れが分散し、システム全体の処理フローを追跡しにくくなるという課題があります。SAPレベルでは、X-Rayによる分散トレーシングや、EventBridge Schema Registryによるイベント構造の一元管理を組み合わせ、可観測性を担保する設計が問われます。また、イベントの重複配信を前提としたべき等性(Idempotency)のある処理設計も必須の考慮事項です。
Dead Letter QueueとFailure処理
- 非同期呼び出しやイベントソースマッピングでの処理失敗に備え、Dead Letter Queue (DLQ) やLambdaのDestinations機能を設定し、失敗したイベントを後から分析・再処理できるようにする設計がSAPレベルの実務で重要視される
まとめ
- SAA: Lambdaの15分実行時間制約、主要なトリガーサービスの非同期/同期の違いを理解する。
- SAP: 同時実行制御によるリソース競合対策、Step Functionsによる複雑なワークフローのオーケストレーション、イベント駆動設計における可観測性とべき等性の確保ができる。
次は **コンテナ基盤設計(ECS/EKS/Fargate)**を見ていきましょう。