本文へスキップ
BecomeCoder

AWS SAA（ソリューションアーキテクト）コース　·　第8章　回復性・高可用性の設計　·　レッスン47

サーバーレス連携とオーケストレーション

導入

SQS・SNS・EventBridgeでコンポーネントを疎結合につなげるようになったら、次は「外部からどう呼び出すか」「複数のステップをどう順序立てて実行するか」を考える番です。

説明

Amazon API Gateway は、Lambdaなどのバックエンドの前段に立つ、フルマネージドの APIの入り口 です。

  • REST/HTTP/WebSocket APIを作成・公開できる
  • スロットリング（リクエスト数の上限制御）でバックエンドを過負荷から守る
  • 認証（IAM、Cognito、Lambdaオーソライザー）、キャッシュ、リクエスト検証もAPI Gateway側で完結できる

AWS Step Functions は、複数のAWSサービス呼び出し（Lambda関数など）を、順序・条件分岐・並列実行・リトライを含めて ワークフローとして状態管理 するサービスです。「ステップA成功→ステップB、失敗→ステップC」のような複雑な処理フローを、Lambda関数内にコードとして書き込む代わりに、ステートマシンとして視覚的に定義できます。

flowchart LR
    U["利用者"] --> AG["API Gateway<br/>（スロットリング・認証）"]
    AG --> SF["Step Functions<br/>（ワークフロー状態管理）"]
    SF --> L1["Lambda: 在庫確認"]
    SF --> L2["Lambda: 決済処理"]
    SF --> L3["Lambda: 発送手配"]
    L2 -.失敗時.-> L4["Lambda: 決済ロールバック"]

これらを組み合わせることで、サーバー管理不要な サーバーレス・イベント駆動アーキテクチャ の全体像ができあがります。

flowchart TD
    Client["クライアント"] --> APIGW["API Gateway"]
    APIGW --> Lambda1["Lambda"]
    Lambda1 --> SNS["SNS/EventBridge"]
    SNS --> SQS["SQS"]
    SQS --> Lambda2["Lambda"]
    Lambda1 --> SF["Step Functions<br/>（複雑な処理はここで調整）"]

このパターンの利点は、各コンポーネントが独立してスケールし、どこか1つが障害・遅延を起こしても、キューやリトライの仕組みで吸収できることです。

具体例

「注文から発送まで」の一連の処理を、サーバーレスで組む例です。

外部からの入り口はAPI Gateway。スマホアプリの注文リクエストを受け、Cognitoで認証し、スロットリングで過負荷から守ってから、後続へ渡します。

その先の複数ステップを束ねるのがStep Functions。「①在庫確認 → ②決済処理 → ③発送手配」を順番に実行し、②決済が失敗したら自動でリトライ、それでもダメなら決済ロールバックへ分岐、という流れをワークフローとして定義します。もしこれを1つの巨大なLambda関数に全部書くと、途中で落ちたときの巻き戻しやリトライを自前で実装せねばならず複雑化しますが、Step Functionsなら状態管理を任せられます。

各ステップの実処理はLambdaが担当し、疎結合な連携にはSQS/SNSを挟む。結果として「サーバーを1台も持たず、各コンポーネントが独立してスケールし、障害はキューとリトライで吸収する」構成に。「APIの入り口＝API Gateway、複数ステップの順序・分岐・リトライ管理＝Step Functions」と結びつけます。

読んでみよう

「サーバー管理なしでAPIを公開したい」はAPI Gateway＋Lambda、「複数ステップの処理を順序立てて管理し、失敗時のリトライや分岐も扱いたい」はStep Functionsと結びつけましょう。SAAでは「疎結合」「サーバーレス」「イベント駆動」という単語が同じ問題群でセットで登場します。

次のレッスンへ →