こんにちは、Reiです。
先日、私が参加した大規模イベントの先着チケット予約で、ちょっとしたハプニングがありました。
私はチケットを確実に手に入れたいと思い、
予約開始のタイミングでサイトにアクセス。
ところが――
Webサイトがまったく開かない。
SNSやチャットでも……
「予約できないよ〜」
「弾かれるよ〜」
といった声が飛び交い、
予約開始直後の現場はかなりのパニック状態でした 💦
なんとその時点では、
チケットが数枚しか確保できていなかったという状況だったそうです。
後日、運営側がサーバを増強して販売は再開されましたが、
予約開始の瞬間はまさに大混乱でした。
でも、こういうときに
Webの仕組みを少し知っていると、状況を冷静に判断できることがあります。
今回は、
「予約ボタンの裏側で何が起きていたのか」
という視点から、
ブラウザとサーバの通信を少しだけのぞいてみましょう 👀
＼＼ この記事で学べること ／／
・予約ボタンの裏側で起きている通信の流れ
・ブラウザの「開発者ツール」で通信を見る方法
・HTTPステータスが何を意味しているのか
・アクセス集中時にサーバ側で何が起きるのか
少しエンジニア目線の話になりますが、
Webの裏側を理解する入り口として読んでみてください！
予約ボタンの裏側で何が起きていたのか
今回の予約サイトでは、
「予約する」ボタンを押すと、裏側ではいくつかの処理が順番に実行されていました。
普段Webサービスを使っていると、
ボタンを押すだけで簡単に予約できているように見えます。
しかし実際には、
ブラウザとサーバの間で複数の通信が行われています。
今回の予約処理も、大きく次の2つのステップに分かれていました。
① カード決済の準備（トークン発行）
まず最初に行われるのが、
カード決済の準備処理です。
ここでは、決済サービスのサーバに対して
カード情報を使えるかどうかを確認し、
「このカードは決済に使用できます」
という 決済トークン を取得します。
このトークンは、
カード情報そのものを直接送らずに決済を行うための
一時的な認証情報のようなものです。
② 予約の実行（席の確保）
次に行われるのが、
イベントの席を実際に確保する処理です。
先ほど取得した決済トークンを使って
予約APIにリクエストを送り、
・席の空き状況を確認
・予約を確定
といった処理が行われます。
予約ボタンの裏ではこのような通信が動いている
つまり、予約ボタンを押すと
裏側では次のような通信が順番に実行されています。
このように、
1回のボタン操作でも複数のAPI通信が動いていることは
Webアプリではよくあります。
そして今回の混乱は、この2つの処理のうち
「席を確保するAPI」
の部分にアクセスが集中したことが主な原因でした。
サーバの返事はブラウザで確認できる
こうした通信の様子は、
実はブラウザから確認することができます。
そのために使うのが
ブラウザに標準で入っている 開発者ツール（DevTools） です。
開発者ツールの開き方
ブラウザ上で次のキーを押すと開発者ツールを表示できます。
Windows
F12
Mac
Fn + F12
または
option + command + I
もしくは、ブラウザ右上の ︙（三点メニュー） から
その他のツール
↓
開発者ツールを選択して開くこともできます。
Networkタブで通信を確認する
開発者ツールを開いたら
Network（ネットワーク）タブをクリックします。
すると、
- ページを開いたとき
- ボタンを押したとき
などに発生する すべての通信 を
リアルタイムで確認することができます。
画面には、ブラウザとサーバの間で行われている通信が
一覧として表示されます。
そしてここを見ると、サーバからの返事として
HTTPステータス という情報が表示されています。
このHTTPステータスを見ることで、
・通信が成功しているのか
・サーバ側でエラーが起きているのか
・アクセス制限がかかっているのか
といった サーバがどのようにリクエストを処理したのかを
確認することができます。
HTTPステータスとは？
HTTPステータスとは、
サーバがリクエストをどう処理したか を表す番号です。
ブラウザからサーバへリクエストが送られると、
その結果が HTTPステータス という形で返します。
例えば、
- 成功した
- エラーが起きた
- アクセスを拒否した
といった状態を、
3桁の数字で表したものがHTTPステータスです。
普段Webサービスを使っていると
あまり意識することはありませんが、
ブラウザの開発者ツールのNetworkタブを見ると
すべての通信にHTTPステータスが付いています。
そのため、この番号を見ることで
・通信が成功しているのか
・サーバ側でエラーが起きているのか
・アクセス制限がかかっているのか
といった サーバの状態をある程度読み取ることができます。
今回の通信ログにも、
いくつかのHTTPステータスが登場していました。
ここでは、今回特に重要だった
2つのステータスを見ていきます。
① 429：Too Many Requests
・ 意味
アクセスが多すぎてサーバが処理しきれない
・ 状態
サーバに大量のリクエストが短時間で集中し、
処理能力が追いつかなくなっている状態です。
サーバはすべてのリクエストを同時に処理できるわけではないため、
一定以上のアクセスが集中すると
リクエストを一時的に拒否することがあります。
例えば、
・人気イベントのチケット販売
・セール開始直後のECサイト
・ログインが集中するサービス
など、短時間に大量のアクセスが集まる場面で発生することがあります。
・ 対応
時間を少し置いてから
再度アクセスすると成功することがあります。
② 403：Forbidden
・ 意味
サーバがアクセスを拒否している状態
・ 状態
サーバが「このリクエストは許可できない」と判断し、
意図的にアクセスをブロックしている状態です。
このステータスは、
サーバ側のさまざまな制御によって発生します。
例えば、
・ログインしていないユーザーが管理画面へアクセスした
・APIの利用回数制限を超えた
・セキュリティ対策によってアクセスがブロックされた
といった場合に発生することがあります。
つまり403は、
サーバがルールに基づいてアクセスを拒否している状態です。
・ 対応
この場合はユーザー側では対処できないケースが多く、
サーバ側の制御が解除されるのを待つ必要があります。
実際に起きていた通信の流れ
では、実際の通信ログを見てみると、
予約処理の中でどこで問題が起きていたのかを
ある程度読み取ることができます。
Webアプリでは、ボタンを押したときに
複数のAPI通信が順番に実行されることがよくあります。
そのため、通信ごとのHTTPステータスを見ることで、
・どの処理までは成功しているのか
・どの段階で失敗しているのか
を判断することができます。
今回の予約の裏側では、大きく次の2つの通信が行われていました。
・ 決済トークン取得
・ 予約API
このように処理が分かれているため、
どの通信でエラーが出ているのかを見ることで、
システムのどこで問題が起きているのかを推測できます。
① 予約APIで 429 Too Many Requests
最初に「申し込む」ボタンを押したときの通信ログは次のようになっていました。
決済トークン取得 → 成功
予約API → 429
このログから分かる重要なポイントは次の2つです。
・決済トークン取得 → 正常
・席確保API → 失敗
ここから読み取れるのは、
サイト全体が停止しているわけではないという点です。
例えば、
・ログイン
・ページ表示
・決済準備
などの処理は正常に動いている一方で、
席を確保するAPIだけがアクセス集中で処理できなくなっていた
可能性が高いと考えられます。
通信ログを見ることで、
「どの機能が止まっているのか」を切り分けることができます。
② 再実行 → トークン取得で 403 Forbidden
エラーになったので、すぐにもう一度申し込みをすると、
今度は決済トークン取得の段階でエラーが発生していました。
通信ログは次のようになっていました。
トークン取得 → 403 Forbidden
これは決済システム側の仕様として
- 一度発行したトークンは一定時間有効
- 同じカードで連続発行できない
といった再発行制限に引っかかった可能性があります。
通信の流れを整理すると次のようになります。
最初の申し込み
トークン取得 → 成功
予約API → 429
再実行
トークン取得 → 403ここで注目したいのは、
最初のエラーとは別の場所でエラーが発生している という点です。
最初は「予約API」で失敗していましたが、
再実行では「決済トークン取得」で失敗しています。
つまり、
・最初の処理が途中で失敗
・トークンだけが残る
・再実行で決済側の制限に引っかかる
というエラーの連鎖が起きていた可能性があります。
通信ログを追っていると、
このようにエラーの原因が変化していることにも気付くことができます。
③ さらにアクセス集中 → 予約APIも 403
アクセスがさらに増えてきたタイミングでは、
予約APIの通信ログに次のステータスが返るようになっていました。
予約API → 403 Forbidden
これは システム側がアクセス制限をかけた状態 だと考えられます。
大規模サービスでは、
・WAF（Web Application Firewall）
・CDNのレート制限
などの仕組みがあり、
アクセスが急増したときに自動的にリクエストを制限することがあります。
これは、一部のアクセスを制限することでサービス全体の停止を防ぐ
ための防御機能です。
アクセスが急激に増えたことで、
システム側の防御機能が働いた可能性があります。
このように通信ログを追っていくと、
・アクセス集中が起きているのか
・システムが防御モードに入っているのか
といった サーバ側の状況を推測できるようになります。
今回のHTTPステータスの流れ
今回のチケット予約を整理すると、
通信は次のような流れになっていました。
① 予約実行
予約API → 429 Too Many Requests（アクセス集中）
② 再実行
決済トークン取得 → 403 Forbidden（トークン再発行制限）
③ さらにアクセス増加
予約API → 403 Forbidden（アクセス制限）
つまり今回のトラブルは、
アクセス集中 → 再実行 → セキュリティ制御
という流れでエラーが連鎖していた可能性があります。
HTTPステータスを追うことで、
- どこで失敗しているのか
- サーバがどんな状態なのか
が少しずつ見えてきます。
こうした通信ログを読むことができると、
「サービスがうまく動かない」といった現象でも
・サーバが落ちているのか
・アクセス集中なのか
・セキュリティ制限なのか
といった違いを判断でき、状況をより冷静に理解できるようになります。
HTTPを読めるようになると何が分かる？
HTTPステータスを理解できるようになると、
通信ログから システムの状態をある程度読み取れるようになります。
例えば、次のようなことが判断できるようになります。
・エラーの原因が 自分側（ブラウザ）なのかサーバ側なのか
・どの APIの処理で問題が発生しているのか
・アクセス集中なのか、認証エラーなのか といったエラーの種類
つまり、
「なぜ動かないのか」
感覚ではなく 技術的に判断できるようになります。
例えば、今回のようなチケット予約でも
・サーバが完全に落ちているのか
・アクセスが集中して一時的に処理できないのか
・セキュリティ制限に引っかかっているのか
といった違いを、
通信ログからある程度推測することができます。
これはエンジニアだけでなく、Webサービスを使う側としても
「今は待つしかないのか」
「再試行すれば通る可能性があるのか」
といった状況を、冷静に判断する助けになります。
エンジニアは、こうした通信ログを手がかりに
・どのAPIでエラーが発生しているのか
・どのタイミングでアクセスが増えているのか
を調査し、システムの問題点を特定していきます。
つまりHTTPステータスは、
Webサービスのトラブルを読み解くための「ヒント」のようなものです。
まとめ
今回は、チケット予約のトラブルを例に HTTPステータスと通信の流れ を見てきました。
＼＼ 今回のまとめ ／／
・予約ボタンの裏では複数のAPI通信が動いている
・ブラウザの開発者ツールで通信内容を確認できる
・HTTPステータスはサーバの状態を表す番号
・429は「アクセス集中」
・403は「アクセス拒否」
・エラーは1つだけでなく、処理の流れの中で連鎖することがある
・通信ログを見るとトラブルの原因が見えてくる
こうした仕組みを少し知っているだけでも、
「なぜ動かないのか？」
「サーバで何が起きているのか？」
を落ち着いて理解できるようになります。
こうした仕組みを知ると、
普段使っているWebサービスの見え方も
少し変わってくるかもしれません。
コメント