サーバーの選び方
実際のファネルを使用した本番インスタンスに負荷をかけ、すべてを計測しました。結果として、月額約$20 の最も控えめな VPS（4 vCPU / 8 GB）でも、Qubix は毎秒約1,900件のランディングビューを処理できます — 月間数千万件のアクセスに相当し、1件あたり約25 ms、負荷下でのエラーゼロを達成しています。サービス全体の RAM 使用量は約1.3 GBに収まり、メモリリークもなく、24/7 稼働に対応して構築されています。
これが上限ではありません。12コアでは毎秒約6,800件のビューを処理 — スループットはコア数に比例して増加します。
以下に、トラフィックに応じたサーバーの選び方と、これらの数値の根拠となる完全なテスト結果を示します。
サーバーの選び方
| お客様のトラフィック（概算） | サーバー | スループット |
|---|---|---|
| 最大約500万訪問/日（ピーク最大約1,000/秒） | 4 vCPU / 8 GB（約$20/月） | 約1,900ビュー/秒 — 実測値、ランディング約25 ms |
| 約500万〜1,500万/日（ピーク約1,000〜3,000/秒） | 8 vCPU / 16 GB | 約4,000ビュー/秒 — 推定値（コアあたり約500） |
| 1,500万+/日（ピーク5,000+/秒） | 12 vCPU / 16 GB | 約6,800ビュー/秒 — 実測値 |
シンプルな計算式：コア数 ≈ ピーク訪問数/秒 ÷ 500。推奨構成には8 GB の RAM で十分で、余裕を持たせるなら16 GB。
処理能力と計測方法
テスト条件：
- テスト対象サーバー： DigitalOcean クラウド VPS — 4 vCPU / 8 GB、SSD、Debian 13（カーネル 6.12）、フランクフルトリージョン。月額約$20の標準的なマシン。
- 負荷生成： 別サーバー（12コア）— インスタンスがテスト自体ではなく、自身の処理にリソースを集中できるようにするため。ツール — bombardier（keep-alive 付き HTTP）、同時接続数50〜1000で段階的に増加、1回のテスト15〜30秒。
- 負荷対象： 設定済みの本番ファネル — クローキング判定付きリアルドメイン（クローキングされたランディング〜45 KB）と、コンバージョンポストバック。
- 監視項目： CPU、メモリ、スワップ、レイテンシー — テスト全体を通じてリアルタイムで監視。
- スケーリング検証： 同じテストを 12 vCPU / 64 GB サーバーで実施。
推奨サーバー、4 vCPU / 8 GB：
| リクエスト種別 | 処理数 | レイテンシー | エラー |
|---|---|---|---|
| フルランディング（クローキング済み、約45 KB） | 約1,900/秒 | 約25 ms（250同時接続でも0.13秒） | 0 |
| コンバージョンポストバック | 約13,000/秒 | 約25 ms | 0 |
| 軽量リクエスト | 約16,000/秒 | 約20 ms | 0 |
同時接続数1000以内ではエラーは1件も発生しませんでした。過負荷時もインスタンスはクラッシュせず、リクエストをドロップしません — レイテンシーのみ増加し（定格を大きく超える負荷時は約25 msから0.13〜0.26秒に上昇）、ピークが収まると即座に通常値に戻ります。
ピーク時のボトルネック。 全4コアが95〜100%で稼働 — 上限は CPU であり、これがコア数に比例したスケーリングの理由です。メモリは安定していました：負荷下で約1.1〜1.3 GB、スワップなし、常に3.8 GB 以上が空き状態。
メモリリークなし。 個別に4回の負荷サイクルを間隔を空けて連続実行し、メモリを監視しました：アイドル時はサービスが約 0.7 GB を使用し、ピーク負荷時には約 1.2 GB に上昇、休止期間中は 約0.8 GB に戻ります — サイクルをまたいだ累積は見られませんでした。インスタンスは継続的な24/7 稼働に適しています。
コアによるスケーリング。 12 vCPU サーバーでの同一テスト：
| サーバー | フルランディング | 軽量リクエスト |
|---|---|---|
| 4 vCPU | 約1,900/秒 | 約16,000/秒 |
| 12 vCPU | 約6,800/秒 | 約80,000/秒 |
スループットはコア数に比例して増加 — vCPU あたり約500ランディングビュー/秒（実測値：475〜567）。上記のコア数計算式の根拠はここにあります。
Cloudflare 経由でさらに高速化 — 無料
Qubix はすべてのドメインを Cloudflare — 世界規模のサーバーネットワーク — 経由でサービングし、DNS と SSL を自動で管理します。高速ロードはデフォルトで有効（設定 → Cloudflare で管理）：サイトの静的ファイル（スクリプト、スタイル、アイコン、スクリーンショット）は最寄りの Cloudflare サーバーから訪問者に配信されます。
- 訪問者にとって大幅に高速 — ページファイルが地球の反対側にあるお客様のサーバーではなく、最寄りの Cloudflare サーバーから配信されます。世界中でランディングがほぼ瞬時に開きます。
- サーバー負荷が数十分の一に — 各ページは数十の静的ファイル（スクリプト、スタイル、アイコン、スクリーンショット）を読み込みますが、Cloudflare がそれらを自身のサーバーから配信します。お客様のサーバーは動的な部分のみを処理 — 同じハードウェアで数十倍多くの訪問者に対応できます。
- 無料 — Cloudflare ネットワークもキャッシュも費用はかからず、Qubix がすべて設定します。
動的な部分 — クローキング判定とランディング自体 — は引き続きお客様のサーバーで実行されます（上記の数値が計測している処理がまさにこれです）；Cloudflare はその周辺をすべて担います。詳細はドメインをご参照ください。
必要なディスク容量
フル稼働時 — 全訪問のスクリーン録画、すべての統計とファネル、クリエイティブライブラリを含めても — 20 GB で月間約30万件の訪問を処理でき、何年も持ちます：1年以上前の録画は自動削除され、トラフィック履歴の増加は年間約0.5 GB のみです。実際のディスク消費はクリエイティブ（永続保存）です：ライブラリが大きくなるほど容量が必要になります。ここでも Qubix は容量を節約します — 同じクリエイティブを2度保存することはなく（微妙に変更されたコピーも重複排除）、この同じ機能が統計を支えています（数百の広告にまたがる1つのクリエイティブは1件としてカウントされ、ROAS は合算されます）。20 GB は約2,500本の動画または3万枚の画像に相当します；大量に読み込む場合（100万件のクリエイティブはすでにテラバイト規模）は、それに比例して大きなディスクを取得してください — いつでも拡張できます。
SSD と HDD — ここでコストを節約できます。 ランディングページはどちらのディスクでも同等の速度で訪問者に表示されるため、安価な HDD サーバーを選んでも問題ありません。SSD との差が出るのは管理パネル内、かつ大規模なデータ量の場合のみです：レポートがディスクから履歴を読み込む際、HDD では少し遅くなります — これは訪問者へのランディング表示速度には影響しません。