AzureでWaiting roomをつくる！ 新米アーキテクトの挑戦記 2023/12/15 第１回 JAZUG for Women 馬場ひろの Hirono Baba

スピーカーについて ◼ 馬場ひろの ◼ (株)オルターブース所属 ◼ エンジニア4年生 ◼ Azureや.NETがんばってます ◼ 趣味：犬と遊んだり化粧品集めたり お買い物したり @nina-sensei

発表内容について ◼ 今日話すこと ◼ Waiting roomについて ◼ Waiting Roomとは ◼ AzureでWaiting roomのアーキテクチャーを考えよう ◼ 目的 ◼ Waiting roomを通してアーキテクチャーの構成練習を行うこと ◼ 対象者 ◼ Azure初～中級者向け（AZ-204の内容に近いと思います） ◼ アーキテクト目指し中！のひと ◼ アーキテクチャーレビューしてやるよ！なひと（お願いしますm(__)m）

カートインから 決済ページまでの間 販売ページが表示 されるまでの間

昨今の限定商品の争奪戦模様(消費者視点) ◼ 時間になると商品販売ページがオープン ◼ 従来よりよくある方法、サーバーダウンが散見 ◼ ECサイト内での事前抽選販売 ◼ 抽選開始時間にアクセスが集中、サーバ―ダウンが散見 ◼ ECサイト外での事前抽選販売 ◼ LINEなど別媒体を利用し抽選に応募する ◼ Waiting room（仮想待合室、Virtual Waiting room） ◼ サーバーダウンが起きないようWebサイトへの流入量をアプリ側で調整 ネットショッピングの

Waiting Roomとは ◼ Webサイトにアクセスするユーザーを順番に管理する ◼ サーバーの負荷を軽減する ◼ ユーザーは待ってる間、離脱やリロードしてはいけない 最前列 最後尾 ECサイト 待ち行列をWeb上で再現したもの

Waiting roomのパターン ✕ 混雑解消後はWaiting roomはなく なり直接アクセスできるように アクセス順にWaiting roomへ 販売開始時間になると順番にECサイトへ 販売開始時間前にWaiting roomがオープン ランダムにアクセスできる順番がふられる 時間になると販売ページがオープン 決済画面に行く前にWaiting roomが出現 ランダム OPEN OPEN OPEN ① ② ③ 混雑解消後

Waiting roomを実装するなら？ ◼ 既存サービスのAPI、SDKを使う ◼ Queue it、Queue-Fairなど ◼ 他のクラウドと合わせてマルチクラウドで運用 ◼ Cloudflare、AWSなど ◼ Azureにはテンプレート等はない！ので考えてみました ECサイト のアプリ Waiting room のアプリ 混雑時 ECサイトがすでに Azureにデプロイされ ている場合

AzureでWaiting roomの アーキテクチャーを考えよう

AWSのテンプレート https://aws.amazon.com/jp/solutions/implementations/virtual-waiting-room-on-aws/

Azureに置き換えてみた Azure Cosmos DB Azure Front Door Azure Front Door Azure Front Door Azure API Management Azure API Management Azure API Management Azure API Management Azure Key Vault Azure Functions Azure Functions Azure Functions Azure Functions Azure Functions Azure Monitor Azure Event Grid Azure Functions Azure Monitor Azure Queue Storage Azure Blob Storage Azure Blob Storage Azure Service Bus Azure Cache for Redis Private Endpoint VNet

構造を分解して必要なものを整理 ◼ 販売ページ(ECサイト)に入れる上限を決められる ◼ 待機時間、人数が表示される ◼ 何秒かに一回待機時間、人数が更新される ◼ ECサイトの入室可能上限数を下回ったら入室できる ◼ アクセス順に入室順が保証される … ECサイト 出たら入れる 1 2 9 8 7 6 5 4 3

アクセス順に入室順が保証される仕組み ◼ 待ち行列を表すには→ Queueを使う ◼ Queue Storageとの比較 1 2 3 4 5 Queue（キュー） 機能 Service Bus Queue Queue Storage 順序の保証 先入れ先出し (FIFO) なし 配信保証 少なくとも 1 回 At-Most-Once At-Least-Once 重複検出 ○ ✕ ID によるメッセージ セッ ションの取得 ○ ✕ 最大キュー サイズ 1 ～ 80 GB 500 TB

はじめに考えた構成 Web Apps Web Apps Service Bus SQL Database(ECサイト) Functions ③買い物完了ボタンを押 すとDBからセッション IDが削除される （わざと設置） ②入室するとセッション IDが保存される カウントして人数を管理 ④タイマートリガーでDB を見に行く 人数が上限を下回ったら Service Busからデキュー しECサイトにリダイレクト する ①Waiting roomにアクセス するとセッションIDを Service Busに追加する Waiting room ECサイト Client

構成の見直し ◼ ECサイトのDBを見に行く構成になっている ◼ Waiting roomは後付けになることが多い ◼ ECサイトの構造がわからなくてもWaiting room側で管理できる方が汎用性高くなる … ECサイト 出たら入れる 1 2 9 8 7 6 5 4 3 次の人どうぞ 見に行って管理しているか 手元で管理しているか

DBをWaiting room側にして再構成 Web Apps Web Apps Service Bus SQL Database (Waiting room) Functions Waiting room ECサイト Functions ②デキューされたらDBに セッションIDを保存する ③DBで人数を管理 ①買い物完了ボタンを押す とService Busの1番目の メッセージをデキューする （※ここだけECサイトの書 き換えが必要） ④タイマートリガーでDB を見に行く 人数が上限を下回ったらEC サイトにリダイレクトする Client

他に考慮が必要なこと① ◼ ECサイトのURLを知っていれば入れる構成になっている Web Apps Service Bus SQL Database (Waiting room) Functions Waiting room ECサイト Functions Front Door Client トークン等付与し、 Front Doorで 「トークンがないとECサイトに入れない」 というルールを作成する

他に考慮が必要なこと② ◼ SQL Databaseである必要性は？ ◼ SQL Databaseは高い ◼ 人数管理をしたいだけであればAzure Storage Tableや Azure Cosmos DBを検討 SQL Database Table Cosmos DB Cache for Redis Redisは料金高めなので 候補から一旦除外

他に考慮が必要なこと③ ◼ 結局ECサイトから独立した構成になっていない Web Apps Web Apps Service Bus SQL Database (Waiting room) Functions Waiting room ECサイト Functions Client ECサイトの退出ボタン等はそもそ もない Waiting roomのDBで人数管理が できているなら、Functionsのタイ マ―トリガーでデキューすればよ い？

他に考慮が必要なことその他 ◼ 認証は？ ◼ シークレットの管理は？ ◼ モニタリングは？ ◼ ネットワークは？ ◼ などなど…

疑問 ◼ Azure FunctionsのタイマートリガーとAzure SignalR Service ◼ ポーリングする時どちらがいいか結局わからなかった ◼ ご意見くださいm(_ _)m Functions SignalR Service

ふりかえり ◼ 掘り下げていくと思ったより複雑な構成だった ◼ 汎用的な構成に仕上げるのは難しい ◼ 各サービスの特性をもっと知らなきゃいけない ◼ Azureアーキテクチャーセンターで設計学ぶ ◼ 納得いく形になるよう今後も開発続けようと思う