第4章の最後は、Load Balancing（ロードバランシング：負荷分散）です。ここまでの2ページは「守る」（Magic Transit・Spectrum）と「つなぐ」（Cloudflare WAN）の話でしたが、このページは「振り分ける」話です。
Webサイトやサービスが成長すると、いずれサーバー1台では処理しきれなくなります。また、サーバーが1台しかない限り、その1台が止まればサービス全体が止まります。複数のサーバーを並べ、アクセスをうまく振り分け、壊れた1台を自動で切り離す。この役割を担うのがロードバランサーで、Cloudflareはそれをネットワーク側の機能として提供しています。
このページで分かること
- 負荷分散とは何か、なぜ必要になるのか
- Cloudflare Load Balancingの構成要素（エンドポイント・プール・モニター）
- ヘルスチェックとフェイルオーバーの仕組み
- トラフィックの振り分け方（ステアリング）の種類
- 料金の考え方と、導入前に検討すべきこと
負荷分散とは：2つの問題を同時に解決する
負荷分散が解決するのは、性能と可用性という2つの問題です。
1つ目は性能です。アクセスが増えたとき、サーバーを1台の高性能機に置き換える方法（スケールアップ）には限界と高コストが伴います。そこで同じ役割のサーバーを複数並べて処理を分担させます（スケールアウト）。このとき、届いたアクセスを各サーバーへ配る係が必要になります。
2つ目は可用性です。サーバーが1台だけの構成では、その1台が単一障害点（そこが壊れると全体が止まる箇所）になります。複数台に分けた上で、壊れた1台を自動で切り離して残りに任せれば、利用者からはサービスが止まっていないように見えます。この切り替えをフェイルオーバーと呼びます。
従来この係は、データセンターに設置する専用機器や、自前で構築するソフトウェアが担ってきました。Cloudflare Load Balancingは、この係をCloudflareの世界規模ネットワークの上で肩代わりするサービスです。DNSとプロキシ（第1章）の仕組みの延長で動くため、機器の購入も追加のソフトウェアも不要です。
Cloudflare Load Balancingの構成要素
設定は次の3層で組み立てます。
- エンドポイント（オリジン）：転送先となる個々のサーバーです
- プール：エンドポイントをまとめたグループです。たとえば「東京のサーバー2台」「大阪のサーバー2台」をそれぞれプールにします
- ロードバランサー：どのプールへどうトラフィックを送るかを決める本体です。ホスト名（例：www.example.com）に対して設定します
そして監視役としてモニターを設定します。モニターは世界各地のCloudflareデータセンターから各エンドポイントへ定期的にヘルスチェック（死活確認）を行います。HTTP・HTTPS・TCPでの確認に対応し、「応答が返るか」だけでなく「ステータスコードが200か」「応答本文に特定の文字列が含まれるか」まで検査できます。
ヘルスチェックに失敗したエンドポイントは、自動的に振り分け対象から外されます。プール内の全エンドポイントが倒れた場合は、あらかじめ決めた順序で次のプールへ切り替わります。「東京プールが全滅したら大阪プールへ」という災害対策構成が、設定だけで実現できるわけです。復旧が検知されれば、自動で元の構成に戻ります。
トラフィックの振り分け方（ステアリング）
複数のプールが健在なとき、どこへトラフィックを送るかは複数の方式（ステアリングポリシー）から選べます。
- 固定順：常に第1プールを使い、倒れたときだけ次へ。純粋なフェイルオーバー構成です
- ラウンドロビン・重み付け：複数プールへ順番・比率で分配します
- 地理ベース（Geo）：訪問者の地域ごとに使うプールを指定します。「日本からは東京プール、欧州からはフランクフルトプール」という構成です
- レイテンシベース（Dynamic）：実測の応答時間がもっとも良いプールへ送ります
- 近接ベース（Proximity）：訪問者との物理的な距離が近いプールへ送ります
このほか、ログイン状態のあるアプリ向けに、同じ訪問者を同じエンドポイントへ送り続けるセッションアフィニティや、リクエストの内容に応じて挙動を変えるカスタムルールも用意されています。利用できる方式や設定数はプランによって異なり、上位プランほど選択肢が増えます。
どのプランで使えるか
Load Balancingは、Freeを含むどのプランにも追加できる有料アドオンです（2026年8月時点）。料金は固定額ではなく、オリジン数や処理量に応じた従量制で、小規模なら月数ドル程度から始められます。主な制限は次のとおりです。
- 非Enterpriseプランでは、ロードバランサー・プール・エンドポイントは各20個まで
- ヘルスチェックの最短間隔は、Proで60秒、Businessで15秒。Enterpriseはさらに短くでき、ICMPなど監視方式の選択肢も増えます
- カスタムルールの数や高度なステアリングは上位プランほど拡充されます
初心者が注意するポイント
- サーバー1台のうちは不要です：個人ブログや小規模サイトなら、まず第1章のキャッシュ活用が先です。Load Balancingが要るのは「サーバーを複数並べる必然性が出てから」で構いません
- 検知にはタイムラグがあります：ヘルスチェックは間隔ごとの確認なので、障害発生から切り離しまで最短でも数十秒は掛かります。瞬断ゼロを保証する仕組みではありません
- データの同期は自分の仕事です：Load Balancingが面倒を見るのは振り分けだけです。サーバー間でデータベースやファイルの内容を揃えておく仕組み（レプリケーションなど）は別途自分で用意する必要があります
- セッションを持つアプリは要設計：ログイン情報をサーバー内に持つ構成のまま振り分けると、リクエストごとに別サーバーへ飛んでログインが切れます。セッションアフィニティを使うか、セッションを外部に持たせる設計にしてください
- オレンジ雲と組み合わせて真価が出ます：プロキシ経由（オレンジ雲）ならリクエスト単位で瞬時に振り分けできます。DNSだけの利用（グレー雲）では、DNS応答の切り替えに頼るため反映がキャッシュに左右されます
関連サービス
- DNS・プロキシ：Load Balancingの土台。オレンジ雲の延長で動く（第1章）
- CDN：そもそもキャッシュで捌ければサーバー負荷自体を減らせる（第1章）
- Spectrum：TCP/UDPアプリでもLoad Balancingと組み合わせて振り分けできる（前ページ）
- Workers：サーバー管理そのものをなくす選択肢。次章で扱います
まとめ
- 負荷分散は、性能（処理の分担）と可用性（障害時の切り替え）の2つの問題を解決する仕組み
- Cloudflare Load Balancingは、エンドポイント・プール・ロードバランサーの3層とモニターで構成される
- 世界各地からのヘルスチェックで障害を検知し、壊れたサーバーやプールを自動で切り離す（フェイルオーバー）
- 振り分け方は固定順・ラウンドロビン・地理・レイテンシなどから選べる
- どのプランでも使える従量制アドオン。ただしサーバー複数台構成が前提の機能なので、導入は規模が育ってからで十分
これで第4章「ネットワークサービス」は完結です。次章からは話題が大きく変わり、Cloudflareをインフラとしてではなく「開発プラットフォーム」として使う世界に入ります。その入口がCloudflare Workersです。
次に読む
※本記事の情報は 2026年8月時点のものです。