e コマース プラットフォームの負荷テスト: ブラック フライデーのトラフィックに備える

Shopify は、2024 年のブラック フライデー/サイバー マンデー中に加盟店は合計 93 億ドルの売上を上げたと報告しました。この 96 時間のダウンタイムの 1 分ごとに、数千ドルの収益損失が発生します。 負荷テストは、トラフィックのピーク時に適切にスケールするプラットフォームと、最悪の瞬間にクラッシュするプラットフォームの違いです。しかし、ほとんどの企業は、テスト中ではなく実際のイベント中にプラットフォームの限界点を発見します。

重要なポイント

• 生のリクエスト数だけでなく、現実的なトラフィック パターンを使用した負荷テスト -- 閲覧からチェックアウトまでの実際のユーザー ジャーニーをモデル化
• インフラストラクチャの変更とコードの最適化のための時間を確保するために、ピークイベントの 8 ～ 12 週間前に負荷テストを開始します。
• ボトルネックを段階的に特定します。各レイヤーを個別にテストしながら、ベースラインから予想されるピークの 2 倍まで段階的に増加させます。
• テスト後の分析はテスト自体と同じくらい重要 -- 応答時間をインフラストラクチャのメトリクスと関連付けて、真の制約を見つけます

---

負荷テスト ツールの比較

適切な負荷テスト ツールの選択は、チームの技術スキル、インフラストラクチャ、テスト要件によって異なります。

k6: ほとんどのチームに推奨

k6 は、ほとんどの e コマース負荷テストに推奨されるツールです。テスト スクリプトに JavaScript を使用し、CI/CD パイプラインと統合し、応答時間のパーセンタイル、スループット、エラー率などの詳細なメトリクスを生成します。これはローカルまたはクラウドで実行され、その出力はリアルタイム監視のために Grafana ダッシュボードと統合されます。

k6 テストは、シナリオ (ユーザーの動作をシミュレートする HTTP リクエストのシーケンス) を実行する仮想ユーザー (VU) を定義します。各 VU は独自のセッション状態 (Cookie、ヘッダー) を維持し、現実的な認証ワークフローを可能にします。

大砲: 素早いセットアップに最適

Artillery は、一般的なシナリオに対して YAML ベースの構成を使用し、複雑なロジックに対して JavaScript をサポートします。数時間のスクリプト作成ではなく、数分で結果が必要なクイックスタート負荷テストに優れています。 Socket.io および WebSocket テストのネイティブ サポートもあります。

---

現実的な交通パターンのモデル化

負荷テストにおける最大の間違いは、実際のユーザーの動作と一致しない均一なトラフィックを送信することです。実際のトラフィックには、さまざまなボトルネックを引き起こす特定のパターンがあります。

ユーザージャーニーのモデリング

e コマース負荷テストでは、個々のエンドポイント ヒットだけでなく、完全なユーザー ジャーニーをモデル化する必要があります。現実的なテストには、次のユーザー タイプが適切な比率で含まれます。

トラフィックランプパターン

ピーク負荷に直接ジャンプしないでください。徐々に傾斜を上げて限界点を特定します。

ブラック フライデー テストの増加パターン:

1. ベースライン (0 ～ 10 分) -- 通常の毎日のトラフィックから開始して、パフォーマンスのベースラインを確立します
2. 予想されるピークまで増加します (10 ～ 30 分) -- 予想されるブラック フライデーのトラフィックまで徐々に増加します
3. ピークの維持 (30 ～ 60 分) -- ピーク負荷を維持して、持続的なパフォーマンスとリソース リークをテストします。
4. スパイク テスト (60 ～ 70 分) -- 30 秒間で 3 ～ 5 倍のトラフィック スパイクによるフラッシュ セールの開始をシミュレートします。
5. 回復 (70 ～ 80 分) -- 通常の負荷に戻り、手動介入なしでシステムが回復することを確認します。
6. ソーク テスト (個別に実行、4 ～ 8 時間) -- 適度な負荷を継続してメモリ リークと接続プールの枯渇を検出します。

考える時間とペース

実際のユーザーは、できるだけ早くリクエストを発行しません。彼らはコンテンツを読み、製品を比較し、フォームに記入します。リクエスト間の現実的な思考時間を含めます。

• ページビュー間の間隔: 5 ～ 30 秒
• チェックアウトフォームの記入: 30 ～ 120 秒
• 製品説明を読む: 10 ～ 60 秒
• 検索とフィルター: アクション間の間隔は 3 ～ 10 秒です

思考時間がないと、テストでは実稼働トラフィック パターンと一致しない非現実的な集中負荷が生成されます。

---

ボトルネックの特定

負荷テストではボトルネックが明らかになりますが、どこを調べればよいのかを知っておく必要があります。テスト結果とともにインフラストラクチャのメトリクスを監視して、応答時間の低下とリソースの枯渇を相関させます。

データベースのボトルネック

症状: 応答時間は負荷に応じて直線的に増加し、データベース CPU は 90% 以上になり、低速クエリ ログが急速にいっぱいになります。

一般的な原因:

• 頻繁にクエリされる列のインデックスが欠落している
• 同時ユーザー数が増加する N+1 クエリ
• チェックアウト中の在庫更新時のロック競合
• 接続プールの枯渇 (使用中のすべての接続、新しいリクエストのキュー)

診断: アクティブなクエリについては pg_stat_activity、シーケンシャル スキャン数については pg_stat_user_tables、および接続プール メトリクスを監視します。 データベース クエリの最適化 に関する詳細なガイドを参照してください。

アプリケーションサーバーのボトルネック

症状: CPU が 100% に急上昇し、イベント ループ ラグが増加し (Node.js)、ガベージ コレクションの一時停止によりレイテンシが急上昇する

一般的な原因:

• イベントループをブロックする同期操作 (画像処理、PDF 生成)
• メモリ リークによりガベージ コレクションが頻繁に発生する
• CPU バウンドの操作を行うためのワーカー プロセスが不十分
• 負荷の高い計算のためのキャッシュが欠落している

診断: アプリケーション インスタンスごとの CPU、メモリ、イベント ループ ラグ、ガベージ コレクション メトリックを監視します。

ネットワークとインフラストラクチャのボトルネック

症状: 帯域幅の飽和、接続タイムアウト、負荷時の SSL ハンドシェイクの遅延

一般的な原因:

• 帯域幅を消費する非圧縮応答
• CDN ではなくアプリケーションサーバーから提供される静的アセット
• ロードバランサーではなくアプリケーションサーバーでのSSL/TLS終端
• サーバー インスタンス タイプに対してネットワーク帯域幅が不十分です

---

キャパシティプランニング

負荷テストはキャパシティ プランニングに反映され、ピーク イベントに必要なインフラストラクチャの量を決定します。

キャパシティプランニングの公式

1. ピーク時のトラフィックの予測を決定 -- 昨年のデータと成長予測を使用します。初めての大規模な販売の場合は、マーケティング範囲と業界のベンチマークに基づいて見積もります
2. 安全マージンを追加 -- 予期しないウイルス トラフィックに対処するために、予想されるピークの 2 ～ 3 倍を計画します
3. 目標容量で負荷テストを実行 -- インフラストラクチャが 2 ～ 3 倍のピークを許容可能な応答時間で処理できることを確認します。
4. コストの計算 -- ピーク容量のインフラストラクチャ コストを決定し、自動スケーリングと事前プロビジョニングのどちらの方がコスト効率が高いかを判断します。

事前スケーリングチェックリスト

イベントの 8 ～ 12 週間前に準備を開始します。

自動スケーリングと事前プロビジョニング

自動スケーリングは需要メトリクスに基づいて容量を調整しますが、新しいインスタンスの追加には 3 ～ 10 分かかります。突然のトラフィックの急増（フラッシュ セールの開始、ソーシャル メディアへの投稿のバイラル）については、事前プロビジョニングによって遅延を回避できます。

推奨されるアプローチ: 予想されるピークに対処するために事前プロビジョニングし、事前にプロビジョニングされた容量を超える予期しないサージに備えて自動スケーリングを構成します。

---

テスト後の分析

負荷テスト自体は値の半分にすぎません。テスト後の分析により、生データが実行可能な最適化の優先順位に変わります。

分析すべき主要な指標

アクションプランの作成

ビジネスへの影響に基づいて調査結果に優先順位を付けます。

1. ピーク時のエラー -- 負荷がかかっているときに 5xx を返すリクエストはすべて修正する必要があります。これらは販売損失です。
2. チェックアウトのパフォーマンス -- チェックアウトの応答時間が 2 秒を超える場合は、最初にこのパスを最適化します。チェックアウトが遅いと、コンバージョンに直接影響します。
3. 検索と閲覧のパフォーマンス -- 製品の発見が遅いため、表示されるアイテムとカートのサイズが減少します。
4. 管理部門とバックオフィス -- これらは、収益に影響を与えることなく、ピーク時に機能が低下する可能性があります。必要に応じて優先順位を下げます。

---

よくある質問

インフラストラクチャを制御していない場合、Shopify ストアの負荷テストを行うにはどうすればよいですか?

カスタム テーマ コード、サードパーティ アプリ、外部統合など、自分が制御するものに焦点を当てます。フロントエンドのパフォーマンス テストには Lighthouse CI などのツールを使用します。 Webhook 処理エンドポイントとインベントリ同期 API を負荷の下でテストします。 Shopify Plus 販売者の場合は、Shopify の販売者成功チームと協力して、特定のストアのキャパシティを確認してください。

負荷テストとストレス テストの違いは何ですか?

負荷テストでは、システムが予想されるピーク トラフィックを許容可能なパフォーマンスで処理できるかどうかを検証します。ストレス テストでは、予想される限界を超えて限界点を見つけ、正常な劣化を検証します。既知のイベントに備えてテストをロードします。ストレス テストにより、未知の限界を発見し、システムが壊滅的に故障するのではなく安全に故障することを確認します。

負荷テストは本番環境で行うべきですか?それともステージング環境で行うべきですか?

本番環境を可能な限り反映した環境でテストします。ステージング環境では、多くの場合、データベースが小さく、サーバーの数が少なく、ネットワーク構成が異なります。可能であれば、トラフィックの少ない時間帯に実稼働インフラストラクチャに対する負荷テストを実行します。少なくとも、ステージング データベースでは運用サイズのデータ​​を使用してください。

負荷テストで現実的な支払い処理をシミュレートするにはどうすればよいですか?

テスト カード番号を受け入れる支払いプロバイダーのサンドボックス/テスト モードを使用します。 Stripe、PayPal、その他のプロバイダーは、実際のカードに請求せずにトランザクションを処理するテスト環境を提供しています。支払い API 呼び出しを含む完全なチェックアウト フローをテストして、統合のボトルネックを特定します。決済プロバイダーのレート制限を監視します -- 一部のプロバイダーは、運用環境とは異なる方法でサンドボックス リクエストを調整します。

負荷テストはどのくらいの頻度で実行する必要がありますか?

主要なトラフィック イベント (ブラック フライデー、製品発売、マーケティング キャンペーン) の前に、包括的な負荷テストを実行します。自動化された小規模な負荷テストを毎週実行するか、CI/CD の一部として大幅なコード変更後に実行します。高トラフィックのエンドポイントに影響を与える変更については、導入チェックリストに負荷テストを含めてください。

---

次は何ですか

現在の実稼働トラフィック パターンに対するベースライン負荷テストから始めます。上位 3 つのボトルネックを特定し、次のテストを実行する前にそれらを最適化します。プラットフォームが予想される 2 ～ 3 倍のピーク トラフィックを応答時間 500 ミリ秒未満で快適に処理できるようになるまで、このサイクルを繰り返します。

より広範なパフォーマンス エンジニアリングのコンテキストについては、[ビジネス プラットフォームのスケーリング] (/blog/scaling-business-platform-performance) に関する柱ガイドを参照してください。負荷テストで負荷がかかるインフラストラクチャを最適化するには、[インフラストラクチャのスケーリングと負荷分散] (/blog/infrastructure-scaling-load-balancing) に関するガイドをお読みください。

ECOSIRE は、Shopify および Odoo の e コマース プラットフォームの負荷テストとパフォーマンスの最適化を提供します。イベント前のパフォーマンスの準備については、チームにお問い合わせください。

---

ECOSIRE によって発行 — Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。