Load Balancing

解決する課題

• 1つのオリジンに障害が起きてもサービスを止めたくない（自動フェイルオーバー）
• 複数リージョンのオリジンへユーザーを最も近い場所へ誘導したい
• メンテナンスやスケールに応じてトラフィックの配分比率を柔軟に変えたい
• オリジン専用のロードバランサ機器を持たずに、エッジ側で振り分けを完結させたい

主要概念と用語

• ロードバランサ（Load Balancer）: 特定のホスト名（例えばwww.example.com）宛のリクエストを、定義したルールに従って複数オリジンへ振り分ける設定単位
• オリジンプール（Origin Pool）: 振り分け先となるオリジンサーバー群のまとまり。各オリジンには重み（weight）を設定できる
• オリジン（Origin）: プール内の個々の実サーバー。IPアドレスまたはホスト名で指定
• ヘルスモニター（Health Monitor）: HTTP／HTTPS／TCP／UDP／ICMPなどでオリジンの死活を定期監視する設定。異常時にプールから自動的に除外する
• フォールバックプール（Fallback Pool）: 優先プールが全滅した際に切り替わる予備のプール
• ステアリングポリシー（Steering Policy）: プール内でどのオリジンへ振り分けるかの方式。ラウンドロビン・地理位置（proximity）・重み付け（random／dynamic weighted）・レイテンシ最小化などから選ぶ
• セッションアフィニティ（Session Affinity）: Cookieベースで同一クライアントを同一オリジンへ継続して結びつける機能
• プールの優先順位／地理別ルーティング（Geo Steering）: リクエスト元の地域ごとに優先するプールを変え、最寄りリージョンへ誘導する仕組み

仕様・制限・クォータ

• Cloudflareのグローバルエッジ網で動作するため、専用ハードウェアやリージョン限定のインフラを用意する必要がない
• ヘルスモニターはリージョンごとの複数拠点から監視でき、誤検知を避けるための地域指定が可能
• プール数・オリジン数・モニター数にはプランに応じた上限があり、詳細は公式ドキュメントとダッシュボードの表示に従う
• DNSベースの仕組みのため、最終的な切替速度はTTLとクライアント側のリゾルバキャッシュに影響される
• HTTP／HTTPSだけでなく、TCP／UDPアプリケーション向けの振り分け（Spectrumとの組み合わせ）にも対応する

内部の仕組み

Load Balancingは、対象ホスト名へのリクエストをCloudflareのエッジで受け、ヘルスモニターの結果を踏まえて生きているオリジンだけに振り分けます。

リクエストが到着すると、まずステアリングポリシーに従って候補オリジンプールを評価します。地理ステアリングであればリクエスト元の位置に最も近いプールを優先し、そのプールの全オリジンが異常であればフォールバックプールへ自動的に切り替わります。プール内では、重み付けやラウンドロビンなどのポリシーに従って個々のオリジンへ配分します。

ヘルスモニターは独立して定期的にオリジンへ疎通確認を行い、異常を検知するとそのオリジンをプールから即座に除外します。この判定はDNS応答やプロキシ経路の決定に反映されるため、アプリケーション側の変更なしに障害時の切り替えが行われます。

設計パターン / ベストプラクティス

• プライマリプール＋フォールバックプールの構成を基本とし、リージョン障害時に自動でセカンダリへ逃がす
• 複数リージョンにオリジンを分散させ、地理ステアリングでユーザーに最も近い拠点へ誘導しレイテンシを下げる
• ヘルスモニターのパス・しきい値・間隔を実際のアプリケーション挙動に合わせて調整し、誤検知による無駄なフェイルオーバーを避ける
• 段階的なリリースやカナリアテストには重み付けステアリングを使い、少しずつ新環境へトラフィックを寄せる
• セッションが必要なアプリケーションにはセッションアフィニティを使いつつ、可能な限りオリジン側をステートレスに設計する

運用・監視

• ダッシュボードやAPIで各プール／オリジンのヘルス状態をリアルタイムに確認できる
• ヘルスモニターの失敗やフェイルオーバーの発生を**通知（Notifications）**で受け取り、異常を早期に検知する
• ログやアナリティクスで振り分け結果とヘルスチェック履歴を追跡し、しきい値の妥当性を継続的に見直す
• フェイルオーバーが想定どおり動かない場合は、まずヘルスモニターの監視パスと認証設定、次にプールの優先順位設定を確認する

コスト

Load Balancingは基本的にプランに応じた月額または従量の料金体系で提供され、主にロードバランサ数・オリジン数・追加のヘルスチェック地域数などが変動要素になります。具体的な金額は変わりやすいため、契約中のプランと公式の料金ページで確認することが望ましいです。

セキュリティ

• プロキシ経由（オレンジクラウド）で利用すれば、WAF・DDoS保護・Bot Managementなど他のセキュリティ機能と自然に組み合わさる
• オリジン側はCloudflareからの通信のみを許可し、直接インターネットからアクセスされないようにファイアウォールを構成する
• オリジン間の通信やヘルスチェックにはTLSを使用し、証明書の有効期限を継続的に管理する
• APIトークンでロードバランサ設定の変更権限を最小化し、誰がいつ振り分けルールを変えたかを監査する

関連サービス・比較

Load BalancingはCloudflareのDNSおよびヘルスチェック機能と密接に連動します。AWSではRoute 53のルーティングポリシー群やElastic Load Balancingが近い役割を担います。

ハンズオン / CLI例

Cloudflareのロードバランサはダッシュボードから設定するのが一般的ですが、wranglerからCloudflare APIを呼び出す運用スクリプトの一例を示します。

# wrangler経由でCloudflare APIトークンの有効性を確認
wrangler whoami

# オリジンプールを作成（Cloudflare APIを直接呼び出す例）
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/load_balancers/pools" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "primary-pool",
    "origins": [
      { "name": "origin-a", "address": "203.0.113.10", "weight": 1, "enabled": true }
    ],
    "monitor": "monitor-id-xxxx"
  }'

# ヘルスモニターを作成
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/load_balancers/monitors" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "https",
    "path": "/healthz",
    "interval": 60,
    "retries": 2
  }'

# ロードバランサ本体を作成し、プールとフォールバックプールを紐付け
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/load_balancers" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "app.example.com",
    "default_pools": ["primary-pool-id-xxxx"],
    "fallback_pool": "fallback-pool-id-xxxx",
    "proxied": true
  }'