Short Polling：概要、仕組み、使用例

Short Pollingとは

Short Polling は、クライアントが事前に定義された間隔でサーバーに定期的にHTTPリクエストを送信し、サーバーが各リクエストを同期的に処理して即座に結果を返す通信パターンです。ポーリング間隔はクライアント側でタイマーを使用して設定され、データの鮮度要件に応じて通常1〜60秒の範囲です。

Short Pollingは、Webアプリケーションでリアルタイム通信を実現する最初のメカニズムでした。2000年代初頭、第2世代のXMLHttpRequest以前は、Webページは<meta http-equiv="refresh">や定期的なiframeリロードを使用してコンテンツを更新していました。2005年のAJAX（Asynchronous JavaScript and XML）技術の登場により、Short Pollingはページ全体をリロードせずにデータを更新する標準的なアプローチになりました。

Short Pollingのアーキテクチャ

Short Polling のアーキテクチャは、クライアントタイマー、HTTPリクエスト、サーバーハンドラーの3つのコンポーネントで構成されます。クライアントがインターバルタイマーを開始し、タイマーが発火するたびにサーバーにGETリクエストが送信されます。サーバーはデータベースや他のソースにクエリを実行し、レスポンスを生成して即座にクライアントに返します。クライアントはインターフェースを更新し、次のタイマー発火を待ちます。このサイクルはアプリケーションがアクティブな間、無限に繰り返されます。

冗長なリクエストの問題

Short Polling の主な問題は、避けられない空リクエストです。データの変更が稀な場合、ほとんどのリクエストは「変更なし」の結果を返し、ネットワーク帯域幅とCPU処理時間を浪費します。ポーリング間隔5秒で10,000のクライアントがいる場合、サーバーは毎秒2,000のリクエストを受信しますが、更新頻度が1分間に1イベントの場合、その大部分は無駄になります。

Short Pollingの仕組み

Short Polling はシンプルなサイクルで動作します：クライアントが一定期間（例：5000ms）のインターバルタイマーを設定します。タイマーが発火するたびに、クライアントはサーバーエンドポイントにHTTP GETリクエストを生成します。通常は最後の更新のタイムスタンプパラメーターが付与されます。サーバーはリクエストを受信し、指定されたタイムスタンプ以降の新しいデータを確認して、新しいデータがある場合はそれを、ない場合は更新がないことを示すレスポンスを返します。

Short Polling の設定における重要なパラメーターはポーリング間隔です。間隔が短すぎると（3秒未満）、サーバーとネットワークに高い負荷がかかります。長すぎると（30秒超）、データの鮮度が低下します。最適な間隔はシナリオによって異なります：監視ダッシュボードでは5〜15秒、ニュースフィードでは30〜60秒、重要なアラートでは1〜3秒です。間隔の選択は常にデータの鮮度とインフラ負荷のトレードオフです。

適応型ポーリング間隔

アイドル期間中の負荷を軽減するために、適応型間隔が使用されます：連続する複数のリクエストが空の結果を返した場合、間隔が増加します（例：5秒から15秒）。新しいデータが表示されると、間隔は最小値にリセットされます。指数バックオフアルゴリズムにより、更新頻度が低い場合に空のリクエスト数を3〜5倍削減できます。

JavaScriptでのShort Polling実装例

setIntervalとFetch APIを使用したクライアント側のShort Polling実装を見てみましょう。この関数はエンドポイントURLとポーリング間隔（ミリ秒）を受け取ります。

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("受信しました", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("ポーリング失敗：", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer)による停止

コードは5秒間隔のポーリングを作成し、最後の更新のタイムスタンプをサーバーに渡します。サーバーはこのパラメーターを使用してデータをフィルタリングし、新しいレコードのみを返すことで、送信される情報量を削減できます。関数はポーリングを停止するためのタイマー識別子を返します。

Short Pollingのサーバー側

Short Pollingのサーバー側の実装は非常にシンプルです。GETリクエストを受け入れ、現在の状態または指定されたタイムスタンプ以降に変更されたデータを含むJSONレスポンスを返す、通常のRESTエンドポイントです。

const express = require("express");
const app = express();

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

サーバーはsinceパラメーターを受け取り、タイムスタンプが指定値を超えるレコードをフィルタリングします。このアプローチにより、各レスポンスのデータ量が最小限になり、増分変更のみが返されます。新しいデータがない場合、サーバーは空の配列を返し、クライアントはスケジュールに従ってポーリングを続行します。

Short Polling vs Long Polling

Short Polling とLong Pollingは同じ問題（サーバーからクライアントへのデータ配信）を解決しますが、効率性が根本的に異なります。Short Pollingは固定のリクエスト間隔を使用して予測可能な負荷を生成する一方、Long Pollingはイベントが発生するまで接続を開いたままにして、空のレスポンス数を最小限に抑えます。

技術の選択はデータの更新頻度に依存します。イベントが10秒に1回以上発生する場合、両方のアプローチで同等の負荷が発生し、Short Pollingの方がシンプルです。イベントが稀な場合（変更間隔が数時間または数分）、Long Pollingは空のリクエストを生成しないため推奨されます。中間のシナリオでは、インフラストラクチャの制約とWebSocketを使用する可能性によって選択が決まります。

Short Pollingの適用ケース

Short Polling は、データの鮮度要件が低く、効率性よりも実装のシンプルさが優先されるシナリオで使用されます。最も典型的なケースは、内部管理パネル、アラート頻度の低い監視システム、15〜30秒の遅延が許容されるアプリケーションです。

• 監視ダッシュボード — 10〜30秒ごとに更新されるメトリクスのダッシュボードで、変更に対する即時応答は不要です。
• ステータスページ — サービスの可用性を確認するページで、データは30〜60秒ごとに更新され、遅延は重要ではありません。
• 分析レポート — 定期的なデータ収集を行う内部分析システムで、最大1分の鮮度が許容されます。
• シンプルなゲーム — リアルタイム要件のないターンベースのマルチプレイヤーゲームで、ターンは数秒ごとに更新されます。
• テスト — 負荷テストやデバッグのシナリオで、Short Pollingが他の技術との比較のための参照ポーリング方式として使用されます。

重要な制限 — Short Pollingは、1秒の遅延も許容されない時間重視のアプリケーション（取引端末、緊急警報システム）には適していません。そのようなシナリオでは、WebSocket、Server-Sent Events、またはLong Pollingを使用する必要があります。Short Pollingでシステムを設計する際は、リクエスト予算を計算する必要があります：5秒間隔で1,000のクライアントがいる場合、サーバーは毎分12,000のリクエストを処理し、それに見合ったリソースベースが必要です。