安定性と負荷試験
FesRegi
Load Test
「当日、混雑したら止まりませんか」に数字でお答えします
導入をご検討いただく先生から、いちばん多くいただくご質問です。文化祭は 1 日か 2 日しかなく、やり直しがききません。もしレジが止まれば、生徒のみなさんが半年かけて準備した模擬店の売上が失われます。
「たぶん大丈夫です」では、責任を持って導入をご判断いただけないはずです。そこで実際にお使いいただいているものと同じ本番サーバーに対して、壊れるまで負荷をかけました。その結果を、うまくいかなかったことも含めて公開します。
実施日
2026年8月20日
対象
本番環境(実測値)
結果
注文の失敗 0 件
01
測定した結果
同時に営業した模擬店
600 店
同時に接続した端末
7,200 台
試験中に処理した注文
21,526 件
注文の失敗
0 件
サーバーエラー
0 件
同時接続の切断
0 台
注文ボタンを押してから完了まで
平均 0.08 秒
 (遅いときでも)
0.18 秒
キッチン画面に注文が届くまで
平均 0.05 秒
 (遅いときでも)
0.15 秒
リアルタイム通知の取りこぼし
0 %
「遅いときでも」は、100 回のうち 95 回はこれより速いことを示す数値です。いちばん遅かった 1 回でも 0.33 秒でした。
さらに一段階下の 500 模擬店では、10 分間ぶっ通しで 199,172 回のアクセスを処理して失敗ゼロでした。1 秒あたり 316 回のアクセスを 10 分間止まらずに捌いた計算です。
02
自校の規模だと、どれくらいの余裕ですか
数字だけではイメージしづらいと思いますので、置き換えてみます。
一般的な高校の文化祭で、食品を扱う模擬店は 20〜40 店ほどかと思います。仮に 30 店とすると、今回問題なく動いた 600 模擬店はその 20 倍にあたります。
30 校が同じ日にいっせいに文化祭を開催し、 その全校が FesRegi を使っても大丈夫、という水準です。
1 校だけでお使いいただく場合は、かなりの余裕があるとお考えください。同時接続の 7,200 台も同様で、1 校ならレジ・キッチン・来場者のスマートフォンを合計しても数百台です。
03
しかも、この試験は実際の文化祭よりずっと厳しい条件です
ここが最もお伝えしたい点です。今回の数字は「600 模擬店すべてが、同時に、ピークの忙しさのまま動き続ける」という条件で出したものです。現実には、これほど極端な状況は起こりません。
FesRegi がこれまでに実際に経験した最も混雑した瞬間と、今回の試験条件を並べます。
実際の注文ペース(これまでで最も混雑した瞬間)
1 分間に 23 件
 → 今回の試験
1 分間に 1,500 件(約 65 倍)
1 模擬店あたりの接続台数(実際の平均)
2〜3 台
 → 今回の試験
12 台(約 4〜6 倍)
つまり、これまでで最も混雑した瞬間の 60 倍以上の速さで注文が入り続ける状態を 10 分間続けても、失敗はゼロでした。1 模擬店あたりにつながる端末の数も、実際の平均の 4〜6 倍で試しています。
さらに、全国の文化祭が同じ日・同じ時刻に重なることはまずありません
文化祭の開催日は学校ごとにばらけますし、同じ校内でも全模擬店の行列が寸分たがわず同時にピークを迎えるわけではありません。今回はその「いちばん重なった瞬間」がさらに何十倍にもなった状態を、あえて人工的に作って試しています。実際の当日は、ここからさらに余裕がある状態でお使いいただけます。
04
「もし壊れたら」への備えも実際に試しました
性能と同じくらい大切なのが、壊れたときに元に戻せるかです。試験を始める前にサーバーの全データ(注文履歴・商品・画像・設定)をバックアップし、それを別の場所に復元して、元と 1 件残らず一致するかを照合しました。
復元して照合した結果
データベースの全 44 項目の件数が完全一致
注文・利用者・模擬店・注文明細のすべての識別子を照合して完全一致
データベースの構造(制約・索引)も完全一致
試験の実施にあたって
文化祭のない平日を選び、営業中の学校が 1 校もないことをシステムで確認してから開始
試験中も「実際のご注文が 1 件でも入ったら即中止」という監視を継続(結果は最後まで 0 件)
試験後は投入した仮想データを完全に削除し、模擬店数・注文数が試験前の値に戻ったことを確認
「バックアップを取っています」と申し上げるのは簡単ですが、取ったものが本当に戻せるか確かめていないバックアップは、無いのと同じです。ここは実際に復元して確認しています。
05
正直に申し上げます:測りきれなかったことがあります
600 模擬店を超えたところで、数字が急に悪化しました。750 模擬店(9,000 接続)にすると、リアルタイム通知の遅延が 0.15 秒から6.4 秒に跳ね上がったのです。
原因を突き止めるためサーバー側の設定を 4 通り変えて測り直しましたが、何を変えても数字が動きません。そしてサーバーを調べると、処理能力にもメモリにもまだ余裕がありました。
最終的に分かったのは、限界に達していたのが試験を実施した側のインターネット回線だったということです。9,000 本もの接続を 1 台のパソコンから 1 本の回線に通そうとすると、家庭用の通信機器の処理上限に先にぶつかります。
600 模擬店までは「問題なく動く」と確認できました。 それ以上はサーバーではなく測定側の限界で、まだ天井が見えていません。
実際の運用では各学校がそれぞれ別の回線から接続されるため、今回のように 1 本の回線へ集中する状況は起こりません。実際の上限はさらに高いはずですが、測れていないことを測れたようには書けません
06
秋の文化祭シーズンが終わり次第、2 回目を実施します
測りきれなかったままにはしません。秋の文化祭シーズンが終わったあと、2 回目の負荷試験を行います。
理由は 2 つあります。ひとつは、秋の本格稼働は今年が初めてだからです。今回の試験条件は春シーズンの実績をもとに組み立てました。秋にどれだけの学校・模擬店が同時に使われるかという実データが集まれば、より現実に即した条件で検証し直せます。
もうひとつは、測定環境の改善です。次回は複数の場所から同時に負荷をかけられるようにして、今回届かなかった 600 模擬店より上の天井を確かめます。
2 回目で確かめること
秋シーズンの実データを反映した、より現実に近い条件で再検証する
複数拠点から測定し、600 模擬店より上の限界を明らかにする
結果は今回と同じように、うまくいかなかった点も含めてこのページで公開する
07
見つかった弱点は、その日のうちに直しました
試験は「合格しました」で終わらせては意味がありません。見つかった問題は当日中に修正しています。
サーバーの受付部分に割り当てていたメモリが不足していました。接続 1 本あたり約 69 キロバイトを消費することが実測で分かり、9,000 接続で上限に達していたのです。サーバー全体では 23 ギガバイトのうち 21 ギガバイトが空いていたため、割り当てを 4 倍に広げました
一方で「効きそうだけれど効果を確認できなかった」変更は元に戻しました。根拠のない変更を本番環境に残さないというのが、今回自らに課したルールです。
08
まとめ
600 模擬店・7,200 台の同時接続で、注文の失敗ゼロ・エラーゼロを確認しました
一般的な高校の文化祭(20〜40 模擬店)に対して、十数倍から数十倍の余裕があります
注文は 0.1 秒前後で完了し、キッチンへのリアルタイム通知も 0.1 秒台で届きます
バックアップは「取っている」だけでなく、実際に復元して全件一致を確認しています
しかもこの試験条件は、これまでで最も混雑した瞬間と比べて 60 倍以上の注文ペースです。実際の当日はさらに余裕があります
600 模擬店より上は測定環境の都合で未測定です。秋の文化祭シーズンが終わり次第、2 回目の試験で確かめます
文化祭は 1 年に 1 度、やり直しのきかない日です。その日に安心してお使いいただけるよう、これからも数字を公開してまいります。
「うちの規模で大丈夫か」といった具体的なご相談も歓迎しております。お気軽にご連絡ください。
導入のご相談・ご質問はこちらから
開発・運営者の横山が直接お返事いたします。学校でのご検討に必要な情報は「先生方へ」にまとめています。
お問い合わせ
先生方へ(導入検討資料)
FesRegi
FesRegi(フェスレジ)は、文化祭の模擬店に特化した完全無料の POS レジアプリ。
プロダクト
キャンペーン
負荷テスト
変更履歴
リソース
導入事例
メディア掲載
スポンサー
開発者プロフィール
サポート
先生方へ
よくある質問
お問い合わせ
© 2025-2026 FesRegi ·
運営者 横山眞
利用規約
プライバシーポリシー
特定商取引法に基づく表記