Case Study 05

予算内で確実に売り切るトラフィック制御

負荷検証・待機ページ導入・決済システム改修

1. 直面していた状況

某人気キャラクターの年に一度のリアルイベント。その会場で販売される公式グッズの特設ECサイトが、今回のプロジェクトの舞台です。

課題①:瞬間風速によるサーバーダウン

このECサイトは、事前に告知された日時に販売が開始され、人気商品は約10分、全ての商品が約30分で完売してしまうという、瞬間風速を伴うサイトでした。そのため、販売開始の瞬間に大規模なアクセス集中が起き、「サーバーが落ちてサイトに接続できない」「ユーザーが注文画面までたどり着けない」という事態が頻発していました。

課題②:サーバーダウンが招く決済の二次被害

さらに課題となったのは「決済と注文データの不整合」です。当時のサイトでは外部の決済代行画面へ遷移する決済方式(リンク型決済)を採用していました。この方式は導入しやすく汎用的ですが、決済完了後にユーザーが自社サイトへ戻ってくる(リダイレクトされる)こと、および決済代行会社から自社サーバーへ完了通信(プッシュ通知)が送られることで注文が確定する設計になっていました。
しかし、販売開始の瞬間に自社サイトのサーバーリソースが枯渇(ダウン)してしまうと、決済を終えたユーザーの戻りも、決済代行会社からのプッシュ通知もサーバー側で正常に処理できなくなります。その結果、「決済システム側では処理が通っているのに、自社サイト側では注文が確定していない(未確定注文)」という不整合データが発生し、決済完了データと未確定注文の目視での突合作業や、それに伴う在庫超過への顧客対応(謝罪と返金)など、運用現場に多大な負荷がかかっていました。


2. どうやってその課題を解決したか?

アクセス集中下でも「落ちないサーバー」を目指すのであれば、莫大な費用を投じてサーバーを青天井式に増強すれば済みますが、数十分で完売する単発イベントにおいてそれは非現実的です。
また、当時のリンク型決済も、自社サーバーのリソース枯渇が引き金となって通信の取りこぼしが連鎖し、不整合を生んでしまう構造になっていました。
そこで私たちは、決められた予算の制約の中で「いかに賢くトラフィックを捌き、不整合を根絶するか」という、現実的な3つのアプローチを実行しました。

  • Step1: 予算内の「限界値の負荷試験」と「アプリケーションの徹底チューニング」:
    まずは「決められたサーバー予算内で、一体どこまでのアクセスに耐えられるのか」を負荷試験で正確に計測・把握しました。その過程で炙り出された原因(ボトルネック)を解消するため、データベースの大きな負担となっていた「ユーザーの接続状態の記憶」を高速な専用領域(Redis)へ移し、データの読み書き処理自体も軽くすることで、限られたリソース内で捌ける限界許容量を引き上げました。その上で、販売開始時間に合わせて事前にサーバーを最大稼働状態にしておく(プレウォーミング)運用フローを確立しました。
  • Step2: 「ソーリー(待機)ページ」によるアクセス流量制御:
    Step1で計測した「限界許容量」を上回るアクセスに対しては、サーバーを落として全員を巻き添えにするのではなく、意図的に「仮想待合室(ソーリーページ)」へ誘導する仕組みを導入。システム全体を保護しながら、ユーザーを順番に安全に案内できるようにしました。
  • Step3: 画面が切り替わらない決済(モジュール型)への移行:
    外部との通信の往復をなくし、注文処理と決済処理を自社サーバー内で同期的に完結させる「モジュール型決済」へ移行しました。これにより、アクセス集中下でも入金・在庫データが確実に紐づき、運用現場の混乱を根絶しました。

3. 導入後の成果

限られた予算内であっても、販売開始直後の急激なスパイクアクセスをソーリーページ等を用いてコントロール。
システムダウンも入金不整合も起こすことなく、30分間で全商品を確実・安全に売り切ることに成功しました。

「以前は販売開始前から『また落ちるのではないか』『不整合データの手直しで徹夜になるのではないか』と恐々としていました。タイガーテックさんが限界値を明確にして、待機列の仕組みや決済の裏側を整えてくれたおかげで、安心してイベントに臨めるようになりました。」
— お客様(プロジェクト推進責任者様)より

この確実な運用実績が高く評価され、その後、お客様都合による運用事業者(フルフィルメント)の大幅な体制変更のタイミングを迎えるまで、当システムは長きにわたり安定稼働を続けました。


🏢 4. タイガーテックのスタンス(この事例が示している本質)

「当たり前のことを、当たり前にやり切る」: 私たちは魔法のような最新技術を振りかざすことはしません。予算内で耐えうる限界を計測する。限界を超えたら待っていただく。不整合が起きる決済の仕組みを変える。そうした「ピンポイントかつ、当たり前の問題解決」を地道に実行できるのが当社の強みです。

堅実なシステム運用: 理想論やオーバースペックな提案でお客様の予算を圧迫するのではなく、「与えられた制約の中で、ビジネスを止めずに確実に売り切る」という現実的なゴールを提供し続けます。

👉 詳細はこちら:実情に合わせた堅実なインフラ、当社の「BtoC EC構築」サービス
Introduction

プロジェクト概要

年に一度のリアルイベント向けグッズ販売ECサイト。激しいアクセス集中によるサーバーダウンとリンク型決済の入金不整合問題の解決。

採用技術・ツール

  • Apache JMeter (限界値検証)
  • 仮想待合室システム(自前実装)
  • モジュール型決済モジュール

関連サービス

BtoC EC 構築
導入事例はいかがでしたか?

ページ内の目次

History
検索履歴

文章での質問も可能です。(例: EC-CUBEの保守は?)

サイト内の気になる単語を選択すると
ここに履歴が残ります