こんにちは、shunです。

今回は、「AWS Virtual Waiting Room」のハンズオンをやってみたので、その手順と感想をまとめた記事です。

詳細なサービスの仕組みは解説を行っていないので、知りたい方はAWS公式ドキュメントなどをご覧ください。

はじめに

きっかけ

まず今回のハンズオンをやろうと思ったきっかけですが、Auto Scalingが間に合わない場合ってどのように対応するのがいいんだっけ、待合室のような画面が表示されるサイトがあるな、それってどうやって実装しているんだろ、といった流れでこのハンズオンに辿り着きました。

AWS Virtual Waiting Roomの紹介

ハンズオンで構築する「AWS Virtual Waiting Room」の紹介をします。

このソリューションは、トラフィックの大規模なバースト中にウェブサイトへの着信ユーザーリクエストをバッファリングするのに役立ちます。着信トラフィックを一時的にウェブサイトにオフロードするように設計されたクラウドインフラストラクチャを作成し、仮想待合室をカスタマイズおよび統合するためのオプションを提供します。待合室は、ウェブサイトへの訪問者の待機場として機能し、十分な容量があるときにトラフィックが通過することを許可します。

ウェブサイトのトラフィックの急増を引き起こす可能性のある大規模なイベントの例は以下のとおりです。

• コンサートやスポーツイベントのチケットの販売開始
• 特売や他の大規模なセール (ブラックフライデーなど)
• 多くの人々に向けたマーケティング関連の発表を伴う新製品のリリース
• オンラインの試験や講義のための試験へのアクセスやクラスへの出席
• 診療予約枠の解放
• アカウントの作成と支払いを必要とする新しい D2C サービスの開始

引用： AWS ソリューションライブラリ Virtual Waiting Room 

概要

構成図

構成図は以下となります。

引用： AWS ソリューションライブラリ Virtual Waiting Room 

各リソースの役割

 

ざっくりと各リソースの役割について、記載します。

• Amazon CloudFront : クライアントにパブリック API コールを配信。
• Amazon API Gateway : パブリック API とプライベート API リソースを持ち、トークンの検証とキューリクエストの処理をサポート。
• Amazon SQS : キューメッセージのトラフィックを調整し、バッチ処理を支援。
• AWS Lambda : API リクエストを検証・処理し、応答を返す。
• Amazon DynamoDB : トークンやキューの位置などのデータを保存。

ハンズオンでやること

以下がハンズオンの流れになります。

1. Amazon API Gateway からの Amazon CloudWatch ログ記録の有効化
2. Virtual Waiting RoomのAWS CloudFormation テンプレートの起動
3. 立ち上がった待合室を使ってみる

リソースのコスト

ソリューションの維持コストは、10.0$/d ほどです。

検証が終わった際は、AWS CloudFormation のスタックを削除し、リソースを忘れずに削除しましょう。

ハンズオン

以下のハンズオンは、AWSが公式で提供している手順に沿って、行っております。

手順書：AWS での Virtual Waiting Room AWS 実装ガイド（PDF）

1. Amazon API Gateway からの Amazon CloudWatch ログ記録の有効化

まずは、Amazon API Gatewayのコンソールにサインインし、ハンズオンを実施するリージョンを選択します。

次に、左側のナビゲーションペインから「設定」を選択します。

「設定」→「ログ記録」→「編集」の流れで進みます。

以下画像内の「Cloud Watch ログのロール」にARNが存在している場合は、この手順をスキップしてください。

ARNが存在しない場合は、Amazon API GatewayのCloud Watch のロールをデプロイしてくれる AWS CloudFormation テンプレートを活用しましょう。

手順書のp31からインストールできます。

 

2. AWS Virtual Waiting RoomのAWS CloudFormation テンプレートの起動

続いて、本体であるAWS Virtual Waiting RoomのAWS CloudFormation テンプレートの起動を行いましょう。

テンプレートは、手順書のp32からインストールできます。

テンプレートは、デフォルトではバージニア北部リージョンで起動されるので、適切なリージョンに変更します。

インストールしたテンプレートを AWS CloudFormation へセットします。

 

スタック名には任意の名称を入力し、他はデフォルト設定で進みます。

タグや失敗時のオプションなどを入力し、実行をする際に以下の項目にチェックをつけます。

聞かれている内容は、

AWS CloudFormationでIAMを作りますけど、設定とか大丈夫ですか？

AWS CloudFormationを実行するときに、ネストされたスタックを使いますけど、大丈夫ですか？

と、言った感じです。上記を確認し、実行します。

 

実行完了までに約30分ほどかかるので、それまで待ちます。

 

3. 立ち上がった待合室を使ってみる

先ほどのAWS CloudFormationがちゃんとデプロイできているかを確認します。

「CREATE_COMPLETE」がネストされたスタック含め、4つあれば問題ないです。

続いて、立ち上がった待合室を使ってみたいと思います。

だが、その前に。

管理画面に入るために認証が必要になります。認証方法には、アクセスキーとシークレットキーを使用します。新たにユーザーを作成するもしくは既存のユーザーをテンプレートによって作成されたIAMグループの「 ProtectedAPIGroup」に追加します。

ここでやっと、サンプルの待合室へ入室ができる準備が完了です。

AWS CloudFormationのコンソール内の「出力」から「 ControlPanelURL」を見つけ、開きます。

 

画像上部の「Configuration 」内の「Show」を押下し、先ほどIAMグループへ追加したユーザーのアクセスキー、シークレットキーを入力します。

入力内容を確認し、「USE」を押下します。

 

 

そうすることによって、最初は何も表示がされていなかった箇所に、

「Connected」が出ているかと思います。

 

これで管理画面との接続は完了です。

 

ここから実際に待合室を触ってみます。

先ほどと同じ流れでAWS CloudFormation内の「出力」から「WaitingRoomURL」を開きます。

そうすると、以下の画面が開かれますので、「Reserve」ボタンを選択して待合室に入ります。

画面左上の「My Position」から自分が何番目に並んでいるのかを確認することができます。（私一人なので、当然一人目ですね。）

 

再度、管理画面へ戻り、ユーザーへ待合室から購入サイト（仮）へ遷移できるようにします。

以下の「Increment Serving Counter」から、「Change」 ボタンを押します。

 

 

100人のユーザーが待合室から購入サイト（仮）へ遷移できるようになりました。

 

続いて、待合室へ戻ります。

そうすると、先ほどは表示がされていなかった、「Check out now!」のボタンが表示されているので、押下します。

 

 

要はあなたの順番が来ましたよーってことですね。

購入サイト（仮）へ遷移するので、「Purchase now」を押下します。

 

 

「Complete!」が表示されます。

これで一連の流れは完了です。

 

ちょっとだけ覗いてみる

せっかくなので、少しだけどういった仕組みで動いていたのかを紹介します。

URL

まず、最初にアクセスをした「WaitingRoomURL」を見てみます。

https://xxxxxxxxxxxx.cloudfront.net/waiting-room-site/index.html?eventId=Sample&publicApiUrl=https://xxxxxxxxxxxx.cloudfront.net&commerceApiUrl=https://xxxxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/store

分解すると、以下のようになります。

• Base URL:
  • https://xxxxxxxxxxxx.cloudfront.net/waiting-room-site/index.html
  • 上記は、CloudFront経由でホストされているウェブページを指しています。
• Query Parameters:
  • ?eventId=Sample&publicApiUrl=https://xxxxxxxxxxxx.cloudfront.net&
commerceApiUrl=https://xxxxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/store
  • 3つのクエリパラメータがあります。
    • eventId=Sample: 今回のイベントIDを示しています。
    • publicApiUrl=https://xxxxxxxxxxxx.cloudfront.net:Waiting roomへの入室を記録するためのAPI
    • commerceApiUrl=https://xxxxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/store:購入フローになんらかの形で組み込まれるAPI（今回は、実態がないため形だけ）

 

最初にアクセスしたタイミングで、以下の4つの処理がされていることがわかります。

1. CloudFrontのオリジンに設定されているS3へ転送
2. イベントIDの識別
3. 待合室に入室したユーザーの順番をLambda、SQSを経由し、DynamoDBへ保存するためのAPI
4. 購入フローになんらかの情報を記録するためのAPI（実体がないため、詳細は不明です。）

 

DynamoDB

DynamoDBには、3つのテーブルが作成されていました。

まず、一つ目は待合室の入室を管理するテーブル

 

「entry_time」はUNIX時間で書かれていますが、計算してみると先ほど私が待合室に入室した時間でした。

 

次に、二つ目のテーブルは、待合室から購入サイト（仮）に何名進めるかを管理しているものでした。

先ほどは、100名待合室から購入ページへ遷移できるように設定したので、それが記録されているみたいですね。

わかりやすいように、次は1,000人増やしてみます。

 

最初の100人に加えて、1,000人を追加したので、1,100人になってますね。

最後に3つ目のテーブルを見ます。

これは、購入サイト（仮）を管理しているテーブルになります。

購入サイト（仮）は入室から1時間以内に購入を行う必要があります。そのために、購入サイト（仮）に、何時に何番目に待っていたユーザーが入ってきたのかということを記録します。1時間を過ぎてしまうと、次に待っていたユーザーへ購入する権利を与えるために使うみたいですね。

 

まとめ

待合室の全体構造はまだ読み解けていない部分もありますが、非常に勉強になるハンズオンになりました。

サーバーレスサービス単体で触ることはあるのですが、組み合わせて触ることは少なかったので、各サービス間の繋がりを読み解いていくことに苦労しました。しかし、段々と全貌が見えていくにつれ、この構成の面白さに気付くこともできました。

実施したハンズオンでは、全リソースを一括でデプロイするものでしたが、ユーザー画面、管理画面など細かくテンプレートを区切って行えるハンズオンもあります。一部分だけ試してみたい、興味があるといった方でも試すことができると思います。

今回作成したような構成を要望に沿った形で自分の力で設計できるように、日々の業務に取り組もうとモチベーションをもらいました。

最後まで記事を読んでいただき、ありがとうございました。