イベント会場のコーヒー注文受付（Serverlesspresso）

イベント会場のブースで、来場者のコーヒー注文からバリスタの提供までを支えるサーバーレス構成です。QRコードによる注文受付、Step Functions による注文ワークフロー、バリスタアプリと店舗設定の管理、IoT Core を介したリアルタイム通知を API Gateway・Lambda・DynamoDB・EventBridge で組み合わせています。あわせて、注文ごとのイベント履歴を記録し、経過を示すHTMLを S3 に保存して CloudFront で可視化します。出典: https://github.com/aws-samples/serverless-coffee/tree/9d494a250600a0bb7012762620a68d78061149a1 （著作権表示: Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.／ライセンス: MIT No Attribution（MIT-0））。元のファイルを変更せずに掲載しています。

アクター

来場者（注文客）
バリスタ
店舗管理者
ディスプレイアプリ
AWS IoT Core（リアルタイム配信）

ユースケース

注文用QRコードの表示
QRコード読取による注文開始
ドリンク注文の確定と状況確認
バリスタによる注文対応
店舗設定の変更と配信
注文ジャーニーの記録とHTML生成
注文ジャーニーの閲覧

この構成図は、サーバーレス構成「Serverlesspresso」の中核となるスタックを描いたものです。Serverlesspressoは、イベント会場のブースで来場者がコーヒーを注文してから、バリスタが提供するまでを扱います。API Gateway・Lambda・DynamoDB・EventBridgeを組み合わせて、QRコードによる注文受付、Step Functionsによる注文ワークフロー、バリスタアプリと店舗設定の管理、IoT Coreを介したリアルタイム通知を組み立てています。出典はaws-samples/serverless-coffeeの01-appCore/template.yaml（ライセンスMIT-0）です。

主なリソースとデータの流れ

入口は3つのREST API（Validator API・Order Manager API・Config API）です。Validator APIは、QRコードの取得と検証をLambdaで処理し、時間帯ごとの検証コードをValidatorテーブルに保存します。検証に成功すると、EventBridgeバスServerlesspressoにValidator.NewOrderが発行され、注文処理ワークフロー（Step Functions）が始まります。注文処理ワークフローは、設定テーブルで営業状態と同時受付数を確認し、カウンタテーブルで注文番号を採番します。Order Manager APIは、注文管理ワークフローを起動します。注文管理ワークフローは注文整形関数を呼び出して注文をテーブルへ保存し、SendTaskSuccessで待機中の注文処理ワークフローを再開します。Config APIは、API Gatewayの直接統合で設定テーブルを読み書きします。設定の変更は、DynamoDB Streamsから設定変更関数、EventBridge、設定配信関数を経てIoT Coreへ届きます。また、すべてのServerlesspressoイベントを注文ジャーニーワークフローが記録し、注文ごとの経過を示すHTMLをS3に保存して、CloudFrontで配信します。

ユースケースごとの処理の流れ

構成図には次のユースケースを記述しています。(1) 注文用QRコードの表示：ディスプレイアプリがGET /qr-codeで時間帯ごとのQRコードを取得します。(2) QRコード読取による注文開始：来場者のPOST /qr-codeを検証し、注文処理ワークフローを起動します。(3) ドリンク注文の確定と状況確認：注文を確定し、注文テーブルへのGetItem/Queryで状況を返します。(4) バリスタによる注文対応：注文状態のGSIで作成待ち・作成中の注文一覧を取得し、作成・完了・キャンセルを注文管理ワークフロー経由で反映します。(5) 店舗設定の変更と配信。(6) ワークフロー状態の注文テーブル反映（WorkflowStarted / WaitingCompletion）。(7) 注文タイムアウト処理（OrderTimeOut）。(8) 注文状態のリアルタイム通知：Publisher関数がserverlesspresso-adminとserverlesspresso-user-<ID>のトピックへ発行します。(9) 注文ジャーニーの記録とHTML生成。(10) 注文ジャーニーの閲覧：キャッシュにないとき、CloudFrontがOAI経由でS3オリジンから取得します（TTL 5秒）。(11) デプロイ時のテーブル初期化：カスタムリソースが、設定テーブルとカウンタテーブルに初期データを投入します。

元のIaC（ファイルと主なリソースの型）

元になったのは、AWS SAM（Transform: AWS::Serverless-2016-10-31）で書かれたCloudFormationテンプレート01-appCore/template.yamlです（aws-samples/serverless-coffee、コミット9d494a250600a0bb7012762620a68d78061149a1、MIT-0）。主なリソースの型は次のとおりです。AWS::Serverless::Function（QRコード取得・検証、Publisher、設定変更、注文状態更新、HTML生成など）、AWS::Serverless::StateMachine（注文処理・注文管理・注文ジャーニー）、AWS::Serverless::Api（3つのREST API）、AWS::DynamoDB::Table（注文・設定・カウンタ・Validator・ジャーニーイベント）、AWS::S3::Bucket、AWS::CloudFront::DistributionとCloudFrontOriginAccessIdentity、AWS::Events::Rule、AWS::IAM::Role / Policy、AWS::Logs::LogGroup、AWS::CloudFormation::CustomResource。EventBridgeバス、IoT Coreのエンドポイント、Cognitoユーザープールは、このテンプレートでは作成せず、パラメータで参照しています。

この構成図の作り方

公開リポジトリのIaC（上記のtemplate.yaml）をAIが読み取り、IceShore（アイスショア）のMCP（Model Context Protocol）を通して構成図の記述（ADL）を書きました。それをIceShoreが描画しています。テンプレートの外で用意されるIoT Coreは、外部システムとして表しています。来場者数などの数値はAIが置いた仮の想定値で、元のIaCには書かれていません。

よくある質問

CloudFormation / SAMのテンプレートから構成図を自動生成できますか？

この構成図は、SAM形式のCloudFormationテンプレートをAIが読み取って作りました。AIがIceShoreのMCPを通して構成図の記述を書き、IceShoreが描画しています。リソースだけでなく、ユースケースごとにどのリソースを通るかもあわせて記述しています。

EventBridgeバスやIoT Core、Cognitoが構成図のリソースとして見当たらないのはなぜですか？

元のテンプレートでは、これらを作成していないためです。ServerlesspressoEventBus・IoTRealtimeParameter・UserPoolARNParameterなどのパラメータで参照しています。構成図では、IoT Coreを外部システムとして描き、EventBridgeバスはイベントを受け渡す経路として描いています。

構成図にある来場者数などの数値は実測値ですか？

いいえ。来場者数10,000人などの数値はAIによる仮置きの想定値で、元のIaCには含まれていません。

出典: aws-samples/serverless-coffee（MIT-0）

IaC を読み込むと、あなたのシステムでもこのような構成図を作れます。 IceShore とは