トラフィック急増に対応するオンライン投票システムの負荷テスト

投票は午前9時に開始されます。9時04分までにはサポートラインが鳴り響きます。投票ページがぐるぐる回り、ログインは500エラーを返し、郡書記官が電話で「なぜ誰も投票できないのか」と問い合わせてきます。システムはテスト中は問題ありませんでした。昨日も問題ありませんでした。しかし、昨日は18000人が同じ4分間に投票を試みることはありませんでしたので、今は問題があります。

これはほぼすべての投票サイトの障害のパターンです。トラフィックは予測可能でしたが、その形状は計画されていませんでした。安定したライセンス更新の流れを快適に処理する政府のポータルは、同じインフラストラクチャが一度に全有権者の投票を受け入れる必要がある瞬間に落ちる可能性があります。

ロードテストは、有権者が問題に直面する前にその限界を見つける方法です。そしてオンライン投票はそれを行うための最も明確なケースの一つです。なぜなら、急激なピークがあり、締切が固定されていて、正しく処理するための再チャンスがないからです。このガイドでは、投票負荷で何が壊れるのか、実際の投票に匹敵するテストの構築方法、および当日を乗り切れるかどうかを教える指標について解説します。

投票トラフィックが他とは異なる理由

ほとんどのウェブトラフィックは分散します。忙しい小売サイトでも訪問者は一日を通してばらつきがあり、ピークは数時間かけて形成され、減少します。投票イベントはその逆です。固定され、既知の人口を数回の鋭い時間帯に圧縮し、そのタイミングは徐々の需要ではなく人間の締切に左右されます。

ダメージを与えるのは2つの瞬間です。1つ目は投票開始時で、待っていた全員が一斉にログインする時です。2つ目で通常はもっと厳しいのは、締切直前の1時間で、選挙人の中で最も遅れている人たちが一斉に現れる瞬間です。日単位では管理可能に見えた投票率は、60分間の狭い範囲に大半が集中すると大きな壁になります。

そして投票数は限られているものの大きいです。誰が投票できるかはほぼ正確にわかるので、これは稀で有益な情報です。しかし、その上限は容赦ありません。たとえば4万人が資格を持ち、3万人が投票すると、そのうちのかなりの数が締切直前の期間にシステムへアクセスしてきます。これはあなたのサーバーが準備できているかどうかに関わらず起こります。これがスケーラビリティテストが通常のサイトよりも重要である理由です。無制限の観客を推測するのではなく、厳しい数値上限に対して検証を行うのです。

もう一つの複雑さは、投票は単一のページビューではないことです。有権者は認証し、投票用紙を読み込み、選択を行い、多くの場合確認を確認し、送信します。それぞれが別のリクエストで、送信ステップは一貫性があり監査可能なデータベースへの書き込みが必要です。したがって実際の負荷は人数の数倍であり、最も重い部分は書き込み経路に集中し、ここを失うことは最も避けたいところです。

投票システムが負荷を受けると実際に何が壊れるか

投票サイトがダウンすると、通常フロントエンドが非難されます。なぜならそれが有権者が目にする部分だからです。しかし実際の故障はほとんど常にもっと深いところにあります。ここではどの部分に負荷がかかり、どこから壊れ始めるかのおおよその順序で説明します。

データベースの書き込み経路。読み込みはスケールしやすいのに対し、書き込みはそうではありません。提出された投票はすべて、コミットされ、一貫性を維持し、監査トレイルを残す必要があります。同時に込み合うとコネクションプールが枯渇し、投票テーブルの書き込みロックが積み上がり、トランザクションが順番待ちを始めます。これが最も頻繁に投票システムをダウンさせる階層であり、本当の並列処理をかけるまで可視化されません。

認証とセッション管理。有権者は投票前に自分が誰かを証明する必要があり、そのチェックはIDプロバイダーや有権者登録の照会を呼ぶことが多いです。数千人が同時に認証すると、その依存先がボトルネックになります。投票ページ自体は問題ないかもしれませんが、人々はそれを使えません。

CDNは救えません。コンテンツ配信ネットワークは静的資産をキャッシュし、ロゴやスタイルシートは高速で読み込めますが、投票用紙はパーソナライズされ、投票の送信は動的なため、重要なリクエストはキャッシュから提供できません。負荷を壊すトラフィックは、どんなにCDNが優れていてもオリジンサーバーに直接届きます。

オートスケーリングは遅すぎる反応をします。クラウドのオートスケーリングは負荷発生後に反応し、新しいインスタンスも起動・ウォームアップに１～２分かかります。投票のピークはそれより速く到来します。キャパシティが追いつく頃には締切のラッシュは終わり、エラーは既に出てしまいます。予めキャパシティプランニングを検証して、スケーリングルールが十分に速く起動するか、遅延を完全に避けられるだけの予備を用意したかを確認する以外方法はありません。

これらはいずれも軽いテストでは現れません。実際の投票の同時性を再現した時にのみ表面化します。これが、スモークチェックではなく適切なロードテストを行う意義の全てです。

オンライン投票は実際にどこで行われているか

オンライン投票は多くの場面を含みます。国レベルの法的拘束力のある選挙は依然として争点がありセキュリティ主導の議論の対象であり、このガイドで扱う分野とは別です。パフォーマンス準備と選挙のセキュリティはいずれも重要であり、どちらも互いを代替するものではありません。

すでに日常的に行われているのはその下の範囲全てです。労働組合の批准投票。株主総会の委任投票。大学や学生自治会の選挙。住宅所有者や管理組合の選挙。専門職協会や認定機関の投票。そして公共側では参加型予算ポータル、意見募集システム、地域のタウンホールなど、コミュニティが一定の期間内に意思決定に参加するためのツール。

これら全てに共通のトラフィック特徴があります。既知で限られた集団と、尖った締切が多くの負荷を狭い時間帯に集中させることです。だから同じテスト手法を使い、公共の参加ポータルを運営する政府チームも、株主投票イベントの企業チームと同じピーク問題に直面します。LoadViewが公共部門チームと共に行う仕事は住民が実際にログインして使う政府向けパフォーマンステストの領域にあります。

実際の投票に合致するロードテストの構築方法

ロードテストは実際の投票がシステムに与える影響を再現する場合にのみ有効です。つまり次の3点に合致させる必要があります：ピークの形、実際に投票者が取るステップ、そして投票者がどこから来るか。この3点を正しく設定すれば数字は意味を持ちます。無視するとファンタジーに対してテストしたことになります。LoadViewは完全管理されたクラウドから負荷を実行するので、テストの構築に注力でき、トラフィックを作るためにサーバーを立てる必要はありません。

平均ではなくピークに合わせる

まず資格のある投票者プールと過去の投票率を元に締切直前の負荷曲線を作ります。過去の投票で最後の2時間に70％の投票が集中する場合、テストは均等にユーザーを分散させるのではなくその窓に急激に増やす必要があります。LoadViewはこれを実現するために3つの負荷曲線オプションを提供しています。一定数の同時ユーザーを鋭いピークに押し上げる負荷ステップカーブ、目標同時数に到達できるか検証するゴールベースカーブ、問題が出始める場所をリアルタイムに調整できるダイナミックカーブです。

その後、予想されるピークを超えてテストします。たとえば閉鎖時間に18000人が投票すると予測するなら、22000人か25000人のテストを実行し、どこで壊れるかを見ます。破損点を投票日前の数週間前にチャートで把握したいのです。これがロードテストとストレステストの違いでもあります。前者は想定されたピークが安全か確認し、後者は壁を見つけます。

ページの読み込みだけではなく投票用紙全手順をスクリプト化する

投票用紙のURLへ大量のリクエストを送るだけではほとんど何もわかりません。実際の投票者は1ページを読み込む以上のことをします。ログイン、動的な投票用紙の読み込み、選択、確認、そして送信。その全旅程をポイント＆クリックスクリプティングを使い、EveryStepレコーダーで記録し、すべての仮想投票者が同じ認証、同じ動的投票用紙レンダリング、送信時の同様な書き込みを通過するよう再現します。

これがプロトコルレベルのスクリプトより実ブラウザテストが優れている理由です。モダンな投票インターフェースはJavaScript、シングルページフレームワーク、クライアント側の検証に大きく依存します。プロトコルだけのテストではこれらが実行されず、実際の負荷を過小評価し、フロントエンドのボトルネックを完全に見逃します。実際のブラウザで投票用紙を操作してこそ、有権者のセッションがインフラにどれだけの負荷をかけるかが分かります。より複雑なインターフェースならウェブアプリケーションロードテストでクライアント側の処理も計測に含めるとよいでしょう。

負荷を実際の地理的分布に広げる

全国組織や複数州にまたがる団体の有権者が単一のデータセンターから接続することはありません。彼らは様々なネットワーク、距離からアクセスし、それがレイテンシや地域インフラへ負荷のかかり方へ影響します。単一の発信源から負荷を作るとこれらが隠されます。地域分散負荷注入を実際の有権者がいる地域から利用すると、平均的な値ではなく、実際の体験に近い結果が得られます。

実際の投票イベントからの3つのシナリオ

上記のパターンは抽象的なものではありません。ここに、チームが実際に運営する3種類の投票イベントでどのように現れるかを示します。なお詳細は一般化しています。

異なるイベントですが、教訓は同じです。問題は総投票数ではなく集中度であり、この集中を再現したテストだけがそれを示し、修正する時間を与えます。

どの指標が生存を示すか

ロードテストは大量の数値を生みます。これらは準備ができているか否かを決めるもので、各指標が答える質問です。LoadViewレポートでは全体の経過でこれらを細かく分解しますが、まずは以下のロードテスト指標の順に注目してください。

指標	示す内容	投票で重要な理由
エラー率	失敗またはタイムアウトしたリクエストの割合	失敗したリクエストは投票できなかった有権者を意味します。これは障害を定義する数値です。
応答時間（95パーセンタイル／99パーセンタイル）	最も悪い体験の遅さ（平均ではない）	平均は痛みを隠します。99パーセンタイルは午後11時58分に投票用紙がフリーズする有権者です。
スループット	1秒あたりのリクエスト数および完了した投票数	システムが提出された投票に追いついているか、遅れているかがわかります。
最初の故障時の同時接続数	エラーが増え始めるユーザー数	実際の処理限界です。予想ピークと比較し、ギャップを判断します。
最初のバイトまでの時間	サーバーが応答を開始するまでの時間	早期警告です。TTFBは明確なエラーの前に上昇し、故障前の負荷を示します。

これらを単独ではなく合わせて読みます。平均応答時間が低くてもエラー率が増加し、99パーセンタイルが10秒を超えていれば意味がありません。「準備完了」を示す組み合わせは、エラー率が横ばいで、応答時間のパーセンタイルが許容範囲内で、ピークを通じてスループットが提出に追従していることです。

投票システムテストのベストプラクティス

有用な投票システムテストを単なるチェックボックス演習と差別化する多くは、いくつかの習慣に帰着します。

本番に近い環境でテストする。小さすぎるステージング環境でのテストはステージング環境のことを教えるだけです。できる限り本番の容量、設定、データ量を鏡写しにし、実際の投票より前にクリアされるテスト用投票とテスト有権者レコードを使い、本物のコードパスを本物の票なしで動かします。

早めにテストし、その後も繰り返す。最初のロードテストを投票の数週間前に行い、見つけた問題を修正する時間を確保します。投票用紙、インフラ、認証フローに変更があった際も再テストを行います。1つのボトルネックの修正は次のものを露出させることが多いためです。

自分たちの管理外の依存も含める。ID提供者、支払いや認証サービス、登録照会はすべて投票経路にあり、独自の限界があります。これをテストから除外すると、最も驚かされやすいボトルネックを除外することになります。これは、政府関連ウェブサイトのロードテストで共有バックエンドサービスに依存するチームが直面するパターンと同じです。

開始時ではなく締切に備えた計画を。開始のラッシュを乗り切るキャパシティがあっても、締切のピークで失敗することがあります。締切の方が通常ピークが高く、リマインダーメールも同時に届くためです。最も重いテストを締切に合わせて設計しましょう。

上限を超えた時のフォールバックを用意する。テストで投票率が安全な同時接続数を超え得ると判明したら、仮想待機室で有権者を順序良く待たせ、サイトのクラッシュを防ぎます。負荷テストして圧力に耐えられる仮想待機室か確認することも重要です。でなければ壊れた待機室は無いのと同じだからです。

FAQ

投票システムのピーク容量を評価するチームからよくある質問。