おいしい秋刀魚で秋を感じているSREのbutadoraです。
直近、過負荷対策としてCloudflare WaitingRoomを導入したので紹介します。
背景
ふるさと納税の制度改正
ふるさとチョイスのトラフィック特性により、通常12月が1年で最もトラフィックが伸びる時期で*1、
年をまたぐ直前の12月31日にピークを迎えます。
しかし、今年は2023年10月1日に制度改正が実施されました。
これに伴い、制度改正前の9月30日に年末相当のトラフィックが予測され、
急遽年末のスケールアップとスケールアウトを前倒しで実施する必要が生じました。
想定以上のアクセス増
制度改正の約1週間前、某テレビ番組で制度改正が取り上げられ、急激なアクセス数の増加が発生しました。
これにより、各種リソースは昨年大晦日相当の負荷状況に達しました。
1週間前の時点で想定以上のアクセス状況となっており、
スケールの限界に備えるための手段としてCloudflare WaitingRoomの導入を決めました。
Cloudflare WaitingRoomとは？
Cloudflare WaitingRoomは、文字通り「待合室」を実現するツールです。
これを使うことで、サービスにインフラリソースの限界を超えてユーザーがアクセスしてきた際に、
Cloudflareが提供する待機画面に誘導することで、サービスへの流入を制限することができます。
導入の決め手
- すでにCloudflare（DNS Proxyモード）を使用していたこと
ユーザ→Cloudflare→WEBサーバとトラフィックが流れている状況
- 契約中のプランにWaitingRoomが含まれており、追加費用が発生しなかったこと
- 数日以内に対策を実施する必要があったこと
- WEBコンソール上で簡単に検証し、すぐに利用できることを確認
- (検証から導入まで3日で完了することができた🚀)
設定の勘どころ
詳細な設定方法は公式ドキュメント *2 をご覧いただくとして、 ユーザーがWaitingRoom入るための条件に必要なパラメータがいくつかあります。
Total active users(総アクティブユーザー数)
WaitingRoomが発動する条件の一つで、アクティブユーザー数がこのしきい値を超えることが目安です。
当初、Google Analyticsのアクティブユーザー数を基準にしようとしていましたが、
後述のセッション時間の定義により、ここでの「アクティブユーザー」の意味が変わることが分かりました。
したがって、最初は大きな値からスタートし、Cloudflareのダッシュボードに記録されるメトリクスを追いながら微調整しました。
New users per minute(1分間あたりの新規ユーザー数)
これは総アクティブユーザー数とは別に、急激なアクセス増加時にWaitingRoomを迅速に発動させるためのしきい値です。
前述の急激なアクセス数増加が発生した際のアクティブユーザー数について、 増加傾向をGoogle Analyticsから算出し、その値を設定しました。
結果としてはWaitingRoom導入以降に急激なアクセス増は発生することはなかったため、 このパラメーターをトリガーとしたWaitingRoom発動はありませんでした。
Session duration(セッション時間)
ユーザー1人あたりが対象のサイトに滞在している時間をSession Cookieで計測しています。
こちらも総アクティブユーザー数同様、最初は大きな値からスタートし、 Cloudflareのダッシュボードに記録されるメトリクスを追いながら微調整していきました。
導入効果
結論としてはWaitingRoomのおかげでサービスダウン無く、9月30日を過ごすことができました！🎉
当日はリアルタイムでアクティブユーザー数をウォッチしつつ、パラメーターチューニングしながら見守ってました。
アクセス数は昨年末を上回りましたが、WaitingRoomのおかげでアプリケーションへのユーザー流入を制御でき、過負荷を未然に防ぐことができました。
まとめ
今回、スケールアウトやスケールアップ以外の観点でもサービスへのアクセス増に対処し、 ユーザー体験の低下を最小限に抑えることができました。
ただし、これは過負荷対策の一手段ではあるため、年末に予想される次のアクセス増に向けてアプリケーションやインフラリソースのチューニングを弊社エンジニア一丸となって取り組んでおります！💪
参考記事
以下クラスメソッドさんの記事のお陰で、WaitingRoomのパラメーター設定や発動条件理解が捗りました！ ありがとうございます🙏
エンジニア募集
弊社ではSREを絶賛募集中です。 興味がある方はぜひ一度お話ししましょう！
