Serverlesspresso バリスタの舞台裏

~Happy Coffee, Happy Coding !

2024-06-04
デベロッパーのためのクラウド活用方法

Author : 下川 賢介 (kensh)

バリスタに憧れて

みなさん、こんにちは Serverless Specialist の Kensh です ! (こちらのアイコンは昔飼っていた愛犬です)

じつは、幼少の頃から、コーヒーショップのダンディなバリスタに憧れていました。近所の喫茶店ではヒゲの生えたカッコいい紳士が、まだ小さかった僕にホットミルクを入れてくれました。

大人になった今は、Coding のお供にはコーヒーは欠かせない存在になっています。

そんな僕ですが、学生の頃に一度もバリスタのアルバイトをしなかったことを今でも後悔しています。(人生ではやりたいことはやっておくことが大事です。)

もう、バリスタになることは出来ないんだろうな、、、と思っていたら、AWS Summit Japan でバリスタができることになりました !


Serverlesspresso をご存知ですか ?

みなさんは、僕がバリスタを務める Serverlesspresso をご存知ですか ?

Serverlesspresso は、スマートフォンから注文できるコーヒー カウンター用のマルチテナント・イベント駆動型サーバーレス アプリケーションです。 2022 年、Serverlesspresso は世界中のテクノロジーイベントで 20,000 件を超える注文を処理しました。

2022年 の re:Invent では、Amazon CTO の Werner Vogels の基調講演で取り上げていました。ここではビジネス変化に合わせて簡単に進化できるイベント駆動型アプリケーションの例として紹介されています。

ソースコードは こちら に置かれています。

また、2023年秋に Serverlessのコミュニティによって開催された、ServerlessDays Tokyo でも Serverlesspresso で振る舞われたコーヒー、エスプレッソを多くの Serverless Developer たちが堪能しました。

この様子は X にも公開されています ので一度ご覧になってみてください。


Serverlesspresso はどのようなアプリですか?

Serverlesspresso での注文の流れは以下の通りです。

  1. 頭上のモニターには、5 分ごとに変わる QR コードが表示されます。お客様はスマートフォンを使用してこの QR コードをスキャンして注文します。 QR コードは 5 分間で 10 杯まで利用でき、ドリンクがなくなると画面から消えます。これにより、バリスタが注文に忙殺されるのを防ぐことができます。
  2. お客様は、QR コードによって読み込まれた スマートフォンのブラウザ上で注文を行います。バックエンドは注文を検証し、注文番号を作成して、バリスタがそれを利用できるようにします。
  3. バリスタは、注文がバリスタ側のアプリに表示されるのを確認します。注文のステータスを変更して、いま作成中か、いつ完了したか、または注文をキャンセルされたかをお客様に表示することができます。
  4. お客様はスマートフォンですべてのバリスタによる注文状態の更新を確認できます。現地には大型のディスプレイが設置されており、現在注文されているオーダーや完成したコーヒーのステータスが表示されます。

なぜ、AWS Summit Japan 2024 で Serverlesspresso をするのですか ?

Summit の広い会場とエキサイティングなセッションの合間に美味しいコーヒー☕️で一服していただき、Summit を心行くまで楽しんで頂きたいからです !

また、Serverlesspresso は、ワークフローアーキテクチャ / イベント駆動アーキテクチャに基づいて実装されているため、これらのアーキテクチャパラダイムを学習する教材という側面もあります。

こちらの 「Serverlesspresso: ☕︎イベント駆動型アプリケーションをゼロから構築する」ワークショップはハンズオン形式になっており、サーバーレスならではのアジリティや拡張性を得ながら、ワークフローで複雑なロジックを制御しながら、イベント駆動なアプリケーションを構築していくことができます。

実装される Serverlesspresso の裏側はこんなアーキテクチャになっています。

図の左側のフロントエンドには、お客様が注文時に利用するスマートフォン (Ordering app) や注文の状態を可視化するディスプレイ (Display app)、そしてバリスタがドリンクを用意していく際にステータスを更新していくアプリ (Barista app) があります。それぞれのフロントエンド端末からは、お店が混みすぎていないかなどを確認する QR 検証サービス (QR validator service) や、注文するときにアクセスする注文管理サービス (Order Manager service) といったマイクロサービスが呼び出されます。

実際の検証処理や、注文処理が AWS Lambda などのコンピュートで処理されていないことがこのアーキテクチャの肝心な部分になります。 これらの API で公開されているマイクロサービスは Amazon EventBridge にイベントを送信するまでが仕事になります。

EventBridge から受け取ったイベントに応じて、図の右側の AWS Step Functions がそれぞれの処理ロジックとなるワークフローの実行を担っています。そして、ワークフローの実行によりドリンクのステータスが変わった場合にはお客様に通知する必要がありますが、それを担うのが 発行サービス (Publisher service) になります。発行サービスでは、AWS IoT Core がホストする WebSocket を利用してフロントエンドへの通知を行います。


イベント駆動とはどういうものですか ?

Serverlesspresso の実装、そしてワークショップではコレオグラフィーパターン (Choreography pattern) が紹介されています。

Serverlesspresso で、ユーザーがコーヒーを注文したというイベントは、顧客が QR コードをスキャンするたびに発行されます。

Amazon EventBridge という「イベント」を受け取り複数のターゲットに同じイベントを複製して伝えることのできるサーバーレスサービスを使って、注文を受けて、さまざまなマイクロサービスやワークフローサービスがあらかじめ決められた挙動をするように仕組まれています。この “あらかじめ決められた挙動” がまるで振り付けされたまま踊る踊り子のようだということで、コレオグラフィーというパターン名になっています。コレオグラフィーとは “振付” の意味になります。

イベントに応じて処理を実行することを “イベント駆動” と呼び、そのイベント駆動のパターンの一つが今回紹介したコレオグラフィーパターンになります。
上の全体アーキテクチャの中でコレオグラフィーパターンを担っている部分はこちらに該当します。

Event Bus を中心に図の左のイベントが、注文サービスなどフロントエンドから注文メッセージになります。これを受けて EventBus の適切なターゲットに届く設定があらかじめなされています。そのイベントが図の右に記載されているイベントになります。ターゲットとして今回はワークフローがイベントを受け取り実行することになります。


ワークフローとはどのようなものですか ?

コーヒー注文アプリケーションでは、各お客様の注文は次の一連の手順に従います。

  1. 最初の QR コード スキャンにより、注文プロセスが開始されます。
  2. アプリケーションは、バリスタの待ち行列がいっぱいになっていないかをチェックします。バリスタが一度に扱えるドリンクの数は 20 杯までです。行列がいっぱいの場合、注文プロセスは停止します。
  3. 「エスプレッソ」など、お客様がドリンクの内容を注文するまで 5 分ほど待ちます。 5 分経過しても何も注文されない場合、注文はタイムアウトになります。
  4. バリスタがドリンクを作るまで 15 分待ちます。 15 分経過してもドリンクを用意できなかった場合、注文はタイムアウトになります。
  5. 注文は最終的にバリスタによって完了またはキャンセルされます。


各お客様のドリンクの注文は、それぞれ別のワークフローが実行されます。このようなワークフローロジックをプログラミングコードに埋め込むと、多くのネストされたロジック分岐が発生したり、状態を管理するためにデータベースを用いることが多かったのではないでしょうか ? また、タイムアウトを処理するには、許容時間を超えた注文に対してキャンセルを実行するための別の監視常駐プロセスも必要になったのではないでしょうか?

このような ワークフローロジックは、サーバーレスなステートマシンで実装するのがお手軽です。Serverlesspresso では、AWS Step Functions を使用して、特定のドリンクの注文に対するさまざまなステップをすべて処理できるステートマシンを構築しています。

1 時間あたり 1 杯のドリンクであっても、1 分あたり 100 杯のドリンクであっても、Step Functions は複雑なカスタムコードを必要とせずにスケールしますし、すべての個別の実行を独立して互いに干渉することなく実行できます。

Step Functions のような、中央管理のワークフローがあり、個別機能を実装したマイクロサービスを中央からコントロールするパターンを オーケストレーションパターン (Orchestration Pattern) と呼びます。この “指揮者の指示に従った挙動” がまるでオーケストラのようだということで、オーケストレーションというパターン名になっています。オーケストレーションとは “指揮” の意味になります。

上の全体アーキテクチャの中でオーケストレーションパターンを担っている部分はこちらに該当します。

検証ワークフロー

こちらはお客様の注文を新たに受け入れることができるかを検証するワークフローになります。たとえばお店が開店しているか (Shop Open?) や、想定以上の注文量が来て混雑しすぎていないか (Is capacity available?) を検証しています。

注文ワークフロー

こちらはお客様の注文を新たに受け入れてバリスタたちにドリンク作成の指示を送るワークフロー実行になります。実際にドリンクをつくるかどうか (Make OR Unmake?) など人の意思決定を介在させるなど多様なワークフローを構築できます。

また、AWS Step Functions のマネジメントコンソールには、ワークフローの構築を簡素化する Workflow Studio と呼ばれるビジュアルビルダーツールが用意されています。これによりワークフローを視覚的にドラッグ&ドロップで構築したり、実行されたフローの結果を可視化することもできます。


バリスタたちから最後に一言

さて、みなさん AWS Summit Japan での Serverlesspresso で美味しい一杯を ゲットできたでしょうか ?

暖かいエスプレッソとともに、みなさんに今日から Step Functions や EventBridge に興味を持っていただき、Serverlesspresso のようなスケーラブルで拡張性の高いご自身のアプリケーションを構築していただくことを期待して、バリスタたちは心を込めてお届けしております。

ぜひ、興味を持たれた方は以下の参考コンテンツにもアクセスしていただき、より良いアプリケーション開発に活かしていただければバリスタたちの コーヒーショップでの疲れも吹き飛ぶと思います !

本日は Serverlesspresso に、ご来店ありがとうございました !
Happy Coffee, Happy Coding !

参考コンテンツ


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

下川 賢介 (@_kensh / Speakerdeck / Qiita)
アマゾン ウェブ サービス ジャパン合同会社
シニア サーバーレススペシャリスト ソリューションアーキテクト

バックエンドエンジニアとして主にサーバーサイド開発に従事し、その後 AWS に入社。Serverlessの嬉しい特徴をデベロッパーやビジネスオーナーと一緒に体験し、面白いビジネスの実現を支えるために日々活動しています。最近は地方創生に興味あり。

 

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する