📖 はじめに
弊社では、チケットペイ というチケット販売サービスを提供しています。
ライブ・舞台・スポーツ・トークなど、さまざまなイベントのチケット予約・購入をオンラインで受け付けています。
近年の需要増加に伴い、特定イベントの販売開始直後にアクセスが集中するようになり、インフラ設計の見直しが必要になってきました。
この記事では、「サーバを自動的にスケーリングする仕組み」 を実装し、急激な負荷に耐えるための工夫についてケース別に紹介します。
👉 この仕組みにより、販売者は安定したチケット販売運営を、購入者はサーバトラブルに悩まされることなくスムーズにチケットを購入できるサービスを実現しています。
🎫 背景
特に人気の高い抽選販売チケットなどは、販売開始直後に一斉アクセスが集中し、販売ページにアクセスしづらくなる問題が発生していました。
これまでは担当者が手動で Web サーバや DB のリソースを増強していましたが：
- 深夜・休日に運用対応が必要になる
- 対応が間に合わず障害が発生する、または過剰リソースでコストがかさむ
といった課題があり、運用負担が増していました。
🔥 課題と検討ポイント
☁️システム構成図
📝 主な課題
- 💸 常時高スペック維持はコスト面で非現実的
- ⚠️ 通常のAuto Scalingでは間に合わない場合がある
- 👤 手動で対応するため、深夜・休日対応で運用負荷が高い
こうした課題を解決するため、自動化の検討を進めることになりました。
🔄 対応方針
AWSには以下のような「自動スケーリング機能の選択肢」もあります：
- アプリケーション：Amazon ECS Auto Scaling
- データベース：Amazon Aurora Serverless v2
…こうしたAWSサービスだけでもある程度の自動化は可能です。
しかし今回は、既存のシステム資産を活かしつつ柔軟性・運用性を両立するため、
次の観点からEventBridge＋Step Functions＋Lambdaベースの構成を採用しました：
- 現行構成との親和性（RDSのDBインスタンスやECS構成）
- スケーリングタイミングの柔軟性
- Slack通知やDBのインスタンス名・タグ付与(削除時の処理)といった周辺処理
🎯 プロダクト要望と🛠設計方針
検討段階で、プロダクト担当者からは以下のような要望が挙がりました：
| 🎯 プロダクト要望 | 🛠 設計方針 |
|---|---|
|
販売開始前に自動でスケールアップし、終了後には自動でスケールダウンしてほしい |
⏱ 指定日時スケーリング：EventBridge と Step Functions で事前にスケーリング計画を登録し、販売開始に合わせて自動でスケールアップ、終了後はスケールダウンを実行 |
|
複数の予約スケジュールを事前に登録・管理できる仕組みが欲しい |
📂 複数予約の一括管理：S3 にアップロードされた予約ファイルを3時間ごとに処理し、複数のスケジュールを一括更新 |
| 設定ミスを減らすため、担当者が設定を変更する場所（ユーザインターフェース）を一元化してほしい | 🛠 設定統一：全ての予約・スケーリング設定をEventBridgeルールとS3予約ファイル管理に集約し、担当者が迷わず操作できるよう統一 |
| ステータスを即時に把握できるようにSlack等で通知してほしい | 🔔 Slack通知で運用負荷軽減：予約状況や処理経過を Slack へ通知することで、運用担当者がリアルタイムに状況の把握が可能 |
今回の仕組みでは、予測可能な販売スケジュールに基づくスケーリングのみを自動化対象としています。
突発的な対応や異常系の処理は、運用担当者による手動対応やしきい値監視によるオートスケール機能でカバーしています。
🗂 ケース別スケーリング処理イメージ
代表的なユースケースとして3パターンがあり、以下のようにケース別で処理イメージを整理しました。
ケース1：Webのみの負荷に対応する構成
-
ユースケース：Webレイヤーのみに負荷が集中する場合
-
処理イメージ図：
-
ポイント：DBは固定構成
ケース2：WebとDB読み込み負荷に対応する構成
-
ユースケース：WebとDB読み込みに負荷がかかる場合
-
処理イメージ図：
-
ポイント：
- リードレプリカの追加・削除をEventBridge+Step Functions+Lambdaで制御
- webのスケーリングはケース1のものを流用して使用
ケース3：WebとDB読み書き両方の負荷に対応する構成
-
ユースケース：WebとDBの読み書き両方に負荷がかかる場合
-
処理イメージ図：
-
ポイント：
- DBライターのサイズ変更(フェイルオーバー)とリーダー数のサイズ変更・増減を組み合わせてEventBridge+Step Functions+Lambdaで制御
- webのスケーリングはケース1のものを流用して使用
💻 コード実装（EventBridge・Step Functions・Lambda）
コードは、ケースごと（Webのみ / DB読み込み / DB読み書き）やスケーリング方向ごと（スケールアウト・スケールイン）の用途に応じて、それぞれEventBridge・Step Functions・Lambdaを共通化しつつ複数個を用意しています。
共通処理は再利用しながら、パラメータや処理の流れで個別のシナリオに対応できる構成です。
🧪 工夫した点
-
✅ Lambdaの再利用性
複数の Step Functions ユースケースで共通利用できるように Lambda を汎用化。処理ごとにパラメータを切り替える形にして、スケール処理や通知処理も1つの仕組みで対応。 -
✅ Slack通知による即時把握
スケーリング処理の進捗や異常検知をリアルタイムで Slack に通知。「今何が動いているか」が見える化され、運用チームが安心して自動化を活用できる環境を整備。 -
✅ 担当者操作負荷の最小化
S3に予約ファイルをアップロードするだけで複数スケジュールを管理可能。インターフェースを統一することで、設定漏れやミスを防止。
📈 効果と成果
🚀 分間数十万リクエストに耐える安定性の提供
👨💻 担当者による深夜・休日対応の削減
💸 ECS・RDSコストの最適化
こういった仕組みを活用することで、急激なアクセス集中にも柔軟に対応できるだけでなく、運用負荷やコストを最適化しながら持続可能なサービス運営を実現できるようになりました。
📝 おわりに
急激に負荷が上がったり、下がったりするようなサービスにおいては、「必要なときだけスケールする」アプローチがコスト最適化とサービス安定性の鍵です。
この記事が同様の課題を持つ方のヒントになれば幸いです！