サーバーのレイテンシを低減する方法：実際に効果のある8つの対策

レイテンシとは、リクエストとレスポンスの間に生じる遅延のことです。インタラクティブなアプリケーションの場合、100msを超えると動作が重く感じられ、500msを超えるとユーザーは離脱し始めます。本記事では、レイテンシが高くなる実際の原因、それを低減するための8つの手法、そして予算やアーキテクチャに応じてどの手法を採用すべきかについて解説します。

高遅延の原因

サーバーのレイテンシのほとんどは、次の3つの要因によって生じます：

• 物理的な距離。光はファイバー内を真空中の速度の約3分の2で伝播します。クライアントとサーバー間の距離によって往復時間には絶対的な下限があり、いくら調整してもこれを下回ることはできません。
• ネットワークルーティング。パケットが最短経路を通ることはめったにありません。パケットはトランジットプロバイダー、インターネットエクスチェンジ、ピアリングポイントを経由して跳ね回り、それぞれが数マイクロ秒から数ミリ秒の遅延を加えます。ピアリングの状態が悪いと、理論上の最小値の2倍から3倍になることもあります。
• サーバー側の処理。リクエストが到着した後も、サーバーはそれを処理しなければなりません。構文解析、データベースクエリ、ディスクI/O、アプリケーションロジックなどです。たった1つの遅いクエリが数秒の遅延を引き起こし、ネットワーク部分の遅延を完全に凌駕することもあります。

知っておくべき大まかな往復時間（RTT）の目安：

• LAN：1ms未満
• 同一地域：10～30ms
• 国内（米国東西間）：60～80ms
• 大西洋横断：70～100ms
• 太平洋横断：130～180ms
• 静止軌道衛星：500ms以上（StarlinkのようなLEOサービス：20～50ms）

サーバーのレイテンシを低減する8つの方法

1. エッジコンピューティングで処理をユーザーに近い場所に移動させる

エッジコンピューティングでは、単一の中央データセンターではなく、ユーザーに物理的に近いサーバー上でアプリケーションロジックを実行します。各リクエストがラウンドトリップを引き起こすワークロード（対話型API、リアルタイムゲーム、AI推論など）の場合、これによりネットワーク部分のレイテンシを1桁ミリ秒台に短縮できます。 レイテンシに敏感なワークロードを持つ、世界中に分散したユーザーに最適です。

2. CDNにコンテンツをキャッシュする

CDNは、静的コンテンツや、ますます増えつつある動的コンテンツを世界中のエッジノードに保存するため、ユーザーはオリジンサーバーではなく、最も近いコピーからコンテンツを取得します。これは、グローバルなトラフィックを扱うあらゆるサイト、特にキャッシュ可能なメディア、JavaScript、CSS、およびAPIレスポンスにおいて、最も簡単かつ大きな効果を得られる方法です。最新のCDNは、リクエストヘッダーに基づくリアルタイムのキャッシュ削除やキャッシュルールをサポートしています。

3. プライベートVLANによるトラフィックの分離

プライベートVLANはネットワークトラフィックを分離されたサブネットワークに分割し、無関係なワークロードがブロードキャストドメインを共有しないようにします。QoSポリシーと組み合わせることで、同じ物理インフラ上で他に何が実行されていても、レイテンシに敏感なサービス（VoIP、データベースレプリケーション、ビデオ通話）への帯域幅を保証します。 単一サーバー向けというよりは、マルチテナントや大規模LAN向けのソリューションです。

4. QoSによる重要トラフィックの優先順位付け

QoS（Quality of Service）ルールは、輻輳時にどのパケットを優先すべきかをネットワーク機器に指示します。データベースクエリやAPI呼び出しには高速レーンが割り当てられ、バックアップや一括レプリケーションには残りの帯域が割り当てられます。定期的に飽和状態になるリンクでは真に効果的ですが、決して飽和しないリンクでは無意味です。

5. 高速なハードウェアへのアップグレード

サーバー側で最大の効果をもたらすのは、以下の数種類のコンポーネントです：

• SATA SSDをNVMeストレージに置き換え、I/Oレイテンシを10～100倍低減
• 高いパケット処理レートに対応した、RSS、RDMA、またはDPDKをサポートする最新のNIC
• ホットデータをメモリに保持し、ディスク読み取りを回避できる十分なRAM
• コンテキストスイッチの競合を回避できる、十分なコア数とコアあたりの性能を備えたCPU

適切に構成された単一のサーバーは、不適切な構成のクラスターよりも高いパフォーマンスを発揮することがよくあります。

6. サーバー間で負荷を分散させる

ロードバランシングはリクエストを複数のバックエンドに分散させるため、単一のサーバーがボトルネックになることはありません。標準的なアルゴリズム（ラウンドロビン、最小接続数、重み付け）はステートレスなサービスに適しています。ステートフルなサービスではスティッキーセッションが重要です。エニーキャストやGeoDNSによる地理的ロードバランシングは、ユーザーを最も近い正常なサーバーにルーティングし、世界中のユーザーにとってのRTTを短縮します。

7. アプリケーションとデータベースの最適化

多くの場合、これが最大の改善効果をもたらします。主な改善点は以下の通りです：

• データベースインデックスの欠落または未使用
• ORMの誤用によるN+1クエリパターン
• 並列処理が可能な場面での順次I/O
• 繰り返し行われる読み取り処理の前にインメモリキャッシュ（Redis、Memcached）がない
• 頻繁に実行されるコードパスでのブロック操作

最適化を行う前にプロファイリングを実施してください。py-spy、perf、または適切なAPMツールを使用することで、想定している箇所ではなく、実際に時間が費やされている箇所を特定できます。

8. 継続的に監視する

見えないものは修正できません。RTT、パケットロス、ジッター、および応答時間のパーセンタイル（p50、p95、p99）を追跡してください。p99は通常、悪いユーザー体験（UX）が潜んでいる場所です。知っておくべきツール： mtr パス診断にはSmokeping、トレンド分析にはPrometheusとGrafana（時系列データ用）、アプリケーションレベルの可視化にはAPM（Datadog、New Relic、Sentry）が有効です。

8つのアプローチの比較

適切なリソースの選び方

以下のうち、最もリソースが不足している項目に基づいて選択してください：

• 限られた予算。アプリケーションとデータベースの最適化から始め、次に監視機能を追加し、その後で帯域幅管理を導入します。これらはインフラではなく、エンジニアリングの時間を要するものです。
• エンジニアリング時間が限られている場合。CDNとハードウェアのアップグレードは、導入の手間が少なく大きな効果をもたらします。
• 世界中に分散したユーザー。まずはCDNを導入し、キャッシュできない部分にはエッジコンピューティングを追加します。
• レイテンシが重要なワークロード（リアルタイムゲーム、取引、AI推論）。ハードウェアのアップグレードとエッジ展開を併用します。アプリケーションの最適化だけでは不十分です。
• すでにトラフィックが多い場合。他の拡張を行う前に、ロードバランシングと監視体制を整備しておくべきです。

まとめ

最大の効果は、CDNやエッジノードによる物理的な距離の短縮と、50msのネットワーク遅延を500msの総応答時間にしてしまうサーバー側の非効率性を解消することの2点から得られます。多くのチームは後者を過小評価しています。

レイテンシーに敏感なワークロードの場合、上層のコードと同様に、下層のネットワークも重要です。 FDC の専用サーバーは、70 以上のグローバルロケーションにまたがる、ピアリングの充実したネットワーク上で提供され、帯域幅無制限、最新のハードウェア（EPYC、NVMe）を備えています。これにより、コードでは修正できない部分でボトルネックが発生しない基盤が提供されます。