Cloudflare 10：ロードバランシング ― 健康なサーバーへ送る

一言でいうと：健康なサーバーだけに振り分ける

Cloudflare Load Balancing は、エッジで、リクエストを複数のサーバー（や複数の場所）に振り分ける機能です。各サーバーの様子を定期的に確かめ、健康なサーバーにだけ送ります。

専用の機械のロードバランサーと比べると、次のような違いがあります。

特に3つ目が大きな利点です。「東京の AWS と、大阪の別のクラウド」のように、まったく別の場所にあるサーバーを1つのサイトとして束ねられます。1つの地域や1つのクラウド事業者が丸ごと止まっても、サイトは動き続けます。

図では、右側のオリジンが、東京と大阪の2つのプールに分かれ、それぞれに2台ずつサーバーがあります。エッジは、そのどこへ送るかを、リクエストごとに決めています。

部品は3つ：エンドポイント・プール・モニター

Cloudflare Load Balancing は、3つの部品の組み合わせでできています。

そして、これらをまとめるロードバランサーそのものは、app.example.com のようなホスト名として作ります。利用者がこの名前にアクセスすると、ロードバランサーがプールを選び、プールの中のエンドポイントを選びます。

選び方は2段です。

エンドポイントには重みを付けられます。性能の高いサーバーには多め、試験中の新しいサーバーには少しだけ、といった配分ができます。新しい版を少しずつ試す（カナリアリリース）のにも使えます。

ヘルスチェック：定期的に「元気？」と聞く

ロードバランサーの判断の土台が、ヘルスチェックです。モニターの決まりに従って、Cloudflare が各エンドポイントに定期的にリクエストを送り、返事を確かめます。

大事なのは、ヘルスチェックが世界の複数の地点から送られることです。1か所からだけ確かめると、その地点とサーバーの間の回線が不調なだけで「サーバーが落ちた」と誤解してしまいます。複数の地点の結果を合わせて判断するので、誤判定が減ります。どの地域から確かめるかは、プールごとに選べます。

もう1つ大事なのは、何を確かめるかです。「Web サーバーが返事をする」だけでは、アプリがデータベースにつながらず、実際にはエラーばかり返している状態を見逃します。/health のパスでは、データベースへの接続など、サービスとして本当に動けるかを確かめる作りにしておくと、ヘルスチェックが実態を映すようになります。

1台が不調なら、そのサーバーを外す

ヘルスチェックに失敗したエンドポイントは「不調（unhealthy）」になり、振り分けの対象から外れます。図では、東京のサーバー A1 が不調になり、東京のプールには A2 だけが残っています。

このとき、利用者は何も気づきません。リクエストは、同じプールの健康なサーバーに送られるからです。人が夜中に起きて設定を変える必要もありません。

不調だったサーバーが直ると、次のヘルスチェックで「健康」に戻り、自動で振り分けの対象に戻ります。

プールには、「最低いくつのエンドポイントが健康なら、このプールを使うか」という決まり（health threshold）もあります。例えば4台のプールで「2台以上」にしておくと、3台が落ちて1台だけになった時点で、プール全体が「不調」とみなされ、次のプールに切り替わります。1台に全部のリクエストが集中して、それも落ちてしまう、という連鎖を防ぐためです。

不調を見つけたら知らせてもらうことも大切です。プールごとに、メールや Webhook での通知を設定できます。自動で外れて利用者は困らなくても、壊れたサーバーは誰かが直す必要があるからです。

プールごと落ちたら、次のプールへ（フェイルオーバー）

では、プールの中のサーバーが全部落ちたらどうなるでしょうか。例えば、東京のデータセンターが停電した場合です。

このときは、プールごと「不調」になり、ロードバランサーは次のプールへ切り替えます。図では、東京（プール A）の2台がどちらも不調になり、全部のリクエストが大阪（プール B）へ流れています。これがフェイルオーバー（故障時の切り替え）です。

プールの並び順が優先順位になります。もう1つ、予備のプール（fallback pool）を決めておきます。全部のプールが不調と判断されたときの最後の送り先です。ここには、「ただいまメンテナンス中です」という静的なページを返すサーバーを置く、といった使い方もあります。

フェイルオーバーの力を最大に生かすには、プールを別々の障害に巻き込まれない場所に置くことです。同じデータセンターの2つのプールは、停電のときに一緒に落ちます。別の地域、できれば別のクラウド事業者に置くと、1つの事業者の大きな障害にも耐えられます。

どのプールへ送るか：ステアリング

プールが複数あるとき、どのプールへ送るかを決めるのがステアリング（traffic steering）です。いくつかの方式があります。

いちばん簡単で、多くの場合に十分なのは Off（フェイルオーバー）と Random です。前者は「普段は東京、だめなら大阪」、後者は「普段から東京と大阪で半分ずつ」です。

Geo や Dynamic は、世界中に利用者がいて、各地にプールを置いている場合に効いてきます。利用者の近くのプールに送れば、それだけ速くなります。

方式によっては、追加の契約や上位のプランが必要なものがあります。どの方式が使えるかは、公式の料金のページで確かめてください。

セッションアフィニティ：同じ人は同じサーバーへ

振り分けには、1つ困ることがあります。ログインしている人のリクエストが、毎回別のサーバーに送られると、サーバーの中に覚えていたログインの状態（セッション）が見つからず、ログアウトされたようになることがあるのです。

これを避けるのがセッションアフィニティです。有効にすると、最初の応答で Cloudflare が __cflb という Cookie を付け、その人の次からのリクエストを同じエンドポイントへ送ります。

覚えたエンドポイントが不調になれば、別のエンドポイントへ送られます。その瞬間には、やはりセッションは失われます。

だから、アフィニティは応急処置と考えるのがよいでしょう。本当は、セッションをサーバーの中ではなく、データベースや KV（20号）など共有の置き場に置き、どのサーバーに来ても同じように答えられる作りにするのが理想です。そうすれば、サーバーを足すのも外すのも自由になります。

なお、アフィニティは、次のページで見る「橙のロードバランサー」でしか使えません。Cookie を付けるには、エッジが通信を中継している必要があるからです。

橙のロードバランサーと、灰色のロードバランサー

ロードバランサーにも、01号で見た雲の色があります。どちらにするかで、動きが大きく変わります。

Web サイトや API なら、橙を選びます。切り替えが速く、キャッシュや WAF といったほかの機能も一緒に効きます。

灰色は、HTTP 以外の通信を複数のサーバーに振り分けたいときに使います。例えば、メールサーバーやゲームのサーバーです。ただし、DNS の仕組み上、リゾルバーが覚えている間は古い答えが使われるので、切り替えには時間がかかります。TTL を短くしておくことが大事です。

HTTP 以外の通信をエッジで中継したい場合は、12号の Spectrum と組み合わせる方法もあります。

導入：モニター → プール → ロードバランサー

Load Balancing は有料の追加機能なので、まず管理画面で有効にします（料金は後のページ）。そのあと、次の順で作ります。場所は、アカウントまたはゾーンの Traffic → Load Balancing です。

ロードバランサーを作ると、そのホスト名自体が DNS の行の代わりになります。同じ名前の DNS の行が既にあると、どちらが効いているのか分かりにくくなるので、移行するときは古い行を整理してください。

作ったら、切り替えを一度試しておくことをおすすめします。片方のプールのサーバーをわざと止め、ちゃんと次のプールに流れるか、通知が届くかを確かめます。障害は、試していない仕組みから順に失敗します。

使い方：モニターの設定と、確かめ方

ロードバランシングがうまく働くかどうかは、ほとんどモニターの設定で決まります。例を見てみましょう。

type            https
path            /health
expected_codes  200
expected_body   ok
interval        60      # 秒
retries         2
header Host     app.example.com

Host ヘッダーは忘れがちです。エンドポイントを IP アドレスで登録していると、ヘルスチェックのリクエストに正しいホスト名が付かず、サーバーが「知らないサイト宛て」として別のページやエラーを返すことがあります。

アプリの側には、ヘルスチェック用のパスを用意します。

app.get("/health", async (c) => {
  await db.query("select 1"); // DB につながるかまで確かめる
  return c.text("ok");
});

トップページ（/）をヘルスチェックに使うのは避けてください。重い処理が走る、ログインに転送される、あるいは Cloudflare のキャッシュが返ってサーバーの実態を映さない、といった理由で誤判定の元になります。

エンドポイントの健康の状態と履歴は、管理画面の Load Balancing の分析で見られます。どのプールにどれだけ振り分けられたかも確かめられます。

料金と制限

Load Balancing は、有料の追加機能です。無料プランを含む全プランで追加できますが、無料では使えません。

基本料金は小さい額から始められるので、「2台のサーバーでフェイルオーバーしたい」という用途なら、手の届きやすい価格です。一方、多くのエンドポイントや細かいヘルスチェックを使うと、料金は積み上がります。見積もりは公式の料金のページで確かめてください。

お金をかけない代わりの方法として、DNS に同じ名前の A 行を複数書く（ラウンドロビン）やり方もあります。ただし、これはヘルスチェックをしないので、落ちたサーバーの番号も答え続けます。「壊れたサーバーを外す」という一番大事な仕事ができません。

※2026年9月時点の情報です。料金・上限は変わるので、公式で確かめてください。

よくある落とし穴

1つ目はとてもよくある失敗です。ヘルスチェックは、Cloudflare の番号からあなたのサーバーに届きます。オリジンを守るためにファイアウォールで通信を絞っていると、ヘルスチェックまで止めてしまい、全部のサーバーが「不調」になって、予備のプールにしか流れなくなります。

逆に、ヘルスチェックのパスが甘すぎるのも問題です。本当は壊れているのに「健康」と答え続けると、ロードバランサーは壊れたサーバーに送り続けます。ヘルスチェックは「嘘をつかない」ことが何より大事です。

他の号とのつながり

「どこへ送るか」を決める仕組みは、Cloudflare に3段あると考えると整理できます。条件で決めるのがルール（09号）、健康と距離で決めるのがロードバランシング（この号）、コードで自由に決めるのが Workers（18号）です。まずは簡単なほうから試し、足りなければ次の段へ進みます。