load-balancing-patterns

負荷分散のパターン

シンプルなラウンドロビンからグローバルなマルチリージョンのフェイルオーバーまで、適切な負荷分散方式を使用してインフラストラクチャ全体にトラフィックを分散します。

このスキルを使用する場面

load-balancing-patterns は、次のような場合に使用します。

• 複数のアプリケーションサーバーにトラフィックを分散する
• 高可用性とフェイルオーバーを実装する
• URL、ヘッダー、地理的位置に基づいてトラフィックをルーティングする
• ステートレスなバックエンド間でセッションの永続性を管理する
• Kubernetes クラスターにアプリケーションをデプロイする
• リージョン間のグローバルトラフィック管理を設定する
• ゼロダウンタイムデプロイ（ブルーグリーン、カナリア）を実装する
• クラウド管理型とセルフマネージド型のロードバランサーを選択する

負荷分散の基本概念

レイヤー 4 とレイヤー 7

レイヤー 4（L4）- トランスポート層：

• IP アドレスとポート（TCP/UDP パケット）に基づいてルーティングします
• アプリケーションデータを検査しないため、レイテンシが低く、スループットが高くなります
• プロトコルに依存せず、クライアントの IP アドレスを保持します
• 用途：データベース接続、動画ストリーミング、ゲーム、金融取引、HTTP 以外のプロトコル

レイヤー 7（L7）- アプリケーション層：

• HTTP URL、ヘッダー、Cookie、リクエスト本文に基づいてルーティングします
• アプリケーションデータを完全に把握でき、SSL/TLS 終端、キャッシュ、WAF 統合に対応します
• コンテンツベースのルーティング機能を備えています
• 用途：Web アプリケーション、REST API、マイクロサービス、GraphQL エンドポイント、複雑なルーティングロジック

パフォーマンスベンチマークやハイブリッド方式を含む詳細な比較については、references/l4-vs-l7-comparison.md を参照してください。

負荷分散アルゴリズム

アルゴリズム	分散方法	用途
ラウンドロビン	順次	ステートレスで、サーバーの性能が同程度の場合
加重ラウンドロビン	処理能力に基づく	サーバーの仕様が異なる場合
最小接続数	アクティブな接続数が最も少ないサーバー	長時間接続
最短応答時間	最も速いサーバー	パフォーマンスが重視される場合
IP ハッシュ	クライアント IP に基づく	セッションの永続性
リソースベース	CPU／メモリのメトリクス	ワークロードが変動する場合

ヘルスチェックの種類

浅いヘルスチェック（ライブネス）： プロセスは稼働していますか？

• エンドポイント：/health/live または /live
• 戻り値：プロセス稼働中の場合は 200
• 用途：プロセスの監視、コンテナーのヘルスチェック

詳細なヘルスチェック（レディネス）： サービスはリクエストを処理できますか？

• エンドポイント：/health/ready または /ready
• 検証対象：データベース、キャッシュ、外部 API への接続
• 用途：ロードバランサーのルーティング判断

ヘルスチェックのヒステリシス： 状態の頻繁な切り替わりを防ぐため、正常と異常の判定に異なるしきい値を設定します

• 例：異常と判定するまでに 3 回の失敗、正常と判定するまでに 2 回の成功

ヘルスチェックの実装パターンについて詳しくは、references/health-check-strategies.md を参照してください。

クラウドロードバランサー

AWS の負荷分散

Application Load Balancer（ALB）- レイヤー 7：

• 用途：HTTP/HTTPS アプリケーション、マイクロサービス、WebSocket
• 機能：パス／ホスト／ヘッダーベースのルーティング、AWS WAF 統合、Lambda ターゲット
• 選択する場面：コンテンツベースのルーティングが必要な場合

Network Load Balancer（NLB）- レイヤー 4：

• 用途：超低レイテンシ（<1ms）、TCP/UDP、静的 IP、数百万 RPS
• 機能：送信元 IP の保持、TLS 終端
• 選択する場面：HTTP 以外のプロトコルを使用する場合、またはパフォーマンスが重要な場合

Global Accelerator - グローバルなレイヤー 4：

• 用途：マルチリージョンアプリケーション、グローバルユーザー、DDoS 保護
• 機能：エニーキャスト IP、自動リージョンフェイルオーバー

GCP の負荷分散

Application LB（L7）： グローバル HTTPS LB、Cloud CDN 統合、Cloud Armor（WAF/DDoS） Network LB（L4）： リージョン内の TCP/UDP、パススルー型負荷分散、セッションアフィニティ Cloud Load Balancing： 単一のエニーキャスト IP、グローバル分散、バックエンドバケット

Azure の負荷分散

Application Gateway（L7）： WAF 統合、URL ベースのルーティング、SSL 終端、自動スケーリング Load Balancer（L4）： Basic および Standard SKU、ヘルスプローブ、HA ポート Traffic Manager（グローバル）： DNS ベースのルーティング（優先度、重み付け、パフォーマンス、地理的位置）

クラウドプロバイダーの設定と Terraform の例について詳しくは、references/cloud-load-balancers.md を参照してください。

セルフマネージド型ロードバランサー

NGINX

最適な用途： 汎用的な HTTP/HTTPS ロードバランシング、Web アプリケーションスタック

機能：

• 複数のアルゴリズムに対応した HTTP リバースプロキシ
• TCP/UDP ストリームのロードバランシング
• SSL/TLS 終端
• パッシブヘルスチェック（オープンソース）、アクティブヘルスチェック（NGINX Plus）
• Cookie ベースのスティッキーセッション（NGINX Plus）

基本設定：

upstream backend {
    least_conn;
    server backend1.example.com:8080 weight=3;
    server backend2.example.com:8080 weight=2;
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

NGINX のパターンと高度な設定については、references/nginx-patterns.md を参照してください。

HAProxy

最適な用途： 最大限のパフォーマンス、データベースのロードバランシング、リソース効率

機能：

• 生のスループットが最も高く、メモリ使用量が最も少ない
• 10 種類以上のロードバランシングアルゴリズム
• 高度なヘルスチェック（HTTP、TCP、Redis、MySQL など）
• Cookie または IP ベースの永続化

基本設定：

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.101:8080 check
    server web2 192.168.1.102:8080 check

HAProxy のパターンについては、references/haproxy-patterns.md を参照してください。

Envoy

最適な用途： マイクロサービス、Kubernetes、サービスメッシュとの統合

機能：

• 動的設定（xDS API）に対応したクラウドネイティブな設計
• サーキットブレーカー、再試行、タイムアウト
• 高度なヘルスチェック（TCP、HTTP、gRPC）
• 優れた可観測性

Envoy のパターンについては、references/envoy-patterns.md を参照してください。

Traefik

最適な用途： Docker/Kubernetes 環境、動的設定、使いやすさ

機能：

• サービスの自動検出
• Kubernetes とのネイティブ統合
• Let's Encrypt の組み込みサポート
• ミドルウェアシステム（認証、レート制限）

Traefik のパターンについては、references/traefik-patterns.md を参照してください。

Kubernetes Ingress コントローラー

選定ガイド

コントローラー	最適な用途	強み
NGINX Ingress (F5)	汎用	安定性、広い採用実績、成熟した機能
Traefik	動的な環境	簡単な設定、サービス検出
HAProxy Ingress	高パフォーマンス	高度な L7 ルーティング、信頼性
Envoy (Contour/Gateway)	サービスメッシュ	豊富な L7 機能、拡張性
Kong	API を多用するアプリ	JWT 認証、レート制限、プラグイン
クラウドプロバイダー	単一クラウド	クラウドとのネイティブ統合

Ingress の基本例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/affinity: "cookie"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Kubernetes Ingress の完全な例と Gateway API のパターンについては、references/kubernetes-ingress.md を参照してください。

セッション永続化

スティッキーセッション（必要な場合のみ使用）

Cookie ベース： ロードバランサーが Cookie を設定し、サーバーへの接続を維持します

• 正確なルーティングが可能で、NAT／プロキシ環境でも動作します
• HTTP のみ対応し、Cookie によるオーバーヘッドが発生します

IP ハッシュ： クライアント IP をハッシュ化してバックエンドサーバーを選択します

• Cookie は不要で、HTTP 以外でも動作します
• NAT／プロキシ環境では分散が不適切になる場合があります

欠点： 負荷が不均等に分散される、サーバー障害時にセッションが失われる、スケーリングが複雑になる

共有セッションストア（推奨）

アーキテクチャ：ステートレスなアプリケーションサーバー + 集中型セッションストレージ（Redis、Memcached）

メリット：

• スティッキーセッションが不要
• 適切なロードバランシングが可能
• サーバー障害時もセッションが失われない
• 水平スケーリングが容易

クライアントサイドトークン（API に最適）

JWT（JSON Web Token）：サーバーが署名済みトークンを生成し、クライアントが保存してリクエストとともに送信します

メリット：

• サーバーを完全にステートレスにできる
• ロードバランシングに最適
• セッションストレージが不要

セッション管理のパターンとコード例については、references/session-persistence.md を参照してください。

グローバルロードバランシング

GeoDNS ルーティング

地理的位置に基づき、最寄りのサーバーにユーザーをルーティングします：

• DNS はクライアントの場所に応じて異なる IP アドレスを返します
• レイテンシを低減し、コンプライアンスと地域別コンテンツに対応します
• 実装例：AWS Route 53、GCP Cloud DNS、Azure Traffic Manager

マルチリージョンフェイルオーバー

プライマリ／セカンダリリージョン構成：

• ヘルスチェックでプライマリリージョンの状態を判定します
• セカンダリへの DNS フェイルオーバーを自動で行います
• クライアントからは透過的に動作します

CDN 統合

負荷分散と CDN を組み合わせます：

• GeoDNS が最も近い CDN PoP にルーティングします
• CDN がコンテンツをグローバルにキャッシュします
• キャッシュミス時はオリジンで負荷分散します

Terraform を使用したグローバル負荷分散の完全な例については、references/global-load-balancing.md を参照してください。

判断フレームワーク

L4 と L7 の選択

次の場合は L4 を選択します：

• プロトコルが TCP/UDP（HTTP ではない）
• 超低レイテンシーが重要（<1ms）
• 高スループットが必要（数百万 RPS）
• クライアントの送信元 IP を保持する必要がある

次の場合は L7 を選択します：

• プロトコルが HTTP/HTTPS
• コンテンツベースのルーティングが必要（URL、ヘッダー）
• SSL 終端が必要
• WAF 統合が必要
• マイクロサービスアーキテクチャを採用している

クラウドとセルフマネージドの選択

次の場合は クラウド管理型 を選択します：

• 単一のクラウドにデプロイする
• 自動スケーリングが必要
• チームにロードバランサーの専門知識が不足している
• マネージドサービスを希望する

次の場合は セルフマネージド を選択します：

• マルチクラウドまたはハイブリッド環境にデプロイする
• 高度なルーティング要件がある
• コスト最適化が重要
• 完全な制御が必要
• ベンダーロックインを避けたい

セルフマネージドの選択

• NGINX： 汎用、Web スタック、HTTP/3 サポート
• HAProxy： 最高のパフォーマンス、データベースの負荷分散、最小のリソース使用量
• Envoy： マイクロサービス、サービスメッシュ、動的な構成
• Traefik： Docker/Kubernetes、自動検出、簡単な構成

構成例

動作する完全な例は examples/ ディレクトリにあります：

クラウドプロバイダー：

• examples/aws/alb-terraform.tf - パスベースのルーティングを使用する AWS ALB
• examples/aws/nlb-terraform.tf - TCP 負荷分散用の AWS NLB

セルフマネージド：

• examples/nginx/http-load-balancing.conf - NGINX HTTP リバースプロキシ
• examples/haproxy/http-lb.cfg - HAProxy の構成
• examples/envoy/basic-lb.yaml - Envoy クラスターの構成
• examples/traefik/kubernetes-ingress.yaml - Traefik IngressRoute

Kubernetes：

• examples/kubernetes/nginx-ingress.yaml - TLS を使用する NGINX Ingress
• examples/kubernetes/traefik-ingress.yaml - Traefik IngressRoute
• examples/kubernetes/gateway-api.yaml - Gateway API の構成

モニタリングと可観測性

主なメトリクス

スループット： 1 秒あたりのリクエスト数、転送バイト数、接続率 レイテンシー： リクエスト所要時間（p50、p95、p99）、バックエンドの応答時間、SSL ハンドシェイク時間 エラー： HTTP エラー率（4xx、5xx）、バックエンド接続の失敗、ヘルスチェックの失敗 リソース使用率： CPU、メモリ、アクティブな接続数、接続キューの深さ ヘルス： 正常／異常なバックエンドの数、ヘルスチェックの成功率

ロードバランサーのログ

アクセスログを有効にして、リクエスト／レスポンスの詳細、クライアント IP、応答時間、エラーを追跡します

• AWS ALB： S3 に保存し、Athena で分析します
• NGINX： カスタムログ形式を使用し、ログを一元管理システムに送信します
• HAProxy： Syslog 統合、構造化ログ

トラブルシューティング

負荷分散の偏り

症状： 1 台のサーバーが不均衡に多くのトラフィックを受信する 原因： クライアント数が少ない場合のスティッキーセッション、NAT 集中による IP ハッシュ、長時間持続する接続 解決策： 最小接続数方式に切り替える、スティッキーセッションを無効にする、接続ドレインを実装する

ヘルスチェックの頻繁な切り替わり

症状： サーバーが正常と異常の間を頻繁に切り替わる 原因： ヘルスチェックのタイムアウトが短すぎる、しきい値が低すぎる、ネットワークが不安定 解決策： 間隔とタイムアウトを延長する、ヒステリシスを実装する、詳細なヘルスチェックを使用する

フェイルオーバー後のセッション喪失

症状： サーバー障害時にユーザーがログアウトされる 原因： レプリケーションのないスティッキーセッション、インメモリセッション 解決策： 共有セッションストア（Redis）を実装する、クライアント側トークン（JWT）を使用する

統合ポイント

関連するスキル：

• infrastructure-as-code - Terraform/Pulumi を使用したロードバランサーのデプロイ
• kubernetes-operations - K8s のトラフィック管理向け Ingress コントローラー
• network-architecture - ロードバランシングのためのネットワーク設計とトポロジー
• deploying-applications - ロードバランサーを介したブルーグリーンデプロイとカナリアデプロイ
• observability - ロードバランサーのメトリクス、アクセスログ、分散トレーシング
• security-hardening - WAF の統合、レート制限、DDoS 保護
• service-mesh - Ingress とサービスメッシュプロキシの両方としての Envoy
• implementing-tls - TLS 終端と証明書管理

クイックリファレンス

選択マトリックス

ユースケース	推奨ソリューション
HTTP ウェブアプリ（AWS）	ALB
HTTP 以外のプロトコル（AWS）	NLB
Kubernetes の HTTP Ingress	NGINX Ingress または Traefik
最高のパフォーマンス	HAProxy
サービスメッシュ	Envoy
Docker Swarm	Traefik
マルチクラウドでの移植性	NGINX または HAProxy
グローバルな分散	CloudFlare、AWS Global Accelerator

アルゴリズムの選択

トラフィックパターン	アルゴリズム
ステートレスで、サーバーの性能が同等	ラウンドロビン
ステートレスで、サーバーの処理能力が異なる	加重ラウンドロビン
長時間接続	最少接続数
パフォーマンス重視	最短応答時間
セッション維持が必要	IP ハッシュまたは Cookie
サーバー負荷が変動	リソースベース

ヘルスチェックの設定

サービスタイプ	チェックタイプ	間隔	タイムアウト
ウェブアプリ	HTTP /health	10s	3s
API	HTTP /health/ready	10s	5s
データベース	TCP 接続	5s	2s
重要なサービス	HTTP 詳細チェック	5s	3s
バックグラウンドワーカー	HTTP /live	30s	5s

まとめ

ロードバランシングは、トラフィックの分散、高可用性の確保、水平スケーリングの実現に不可欠です。生のパフォーマンスと HTTP 以外のプロトコルには L4 を、コンテンツに基づくインテリジェントなルーティングには L7 を選択してください。シンプルさと自動スケーリングを重視する場合はクラウド管理型ロードバランサーを、マルチクラウドでの移植性と高度な機能を重視する場合はセルフマネージド型を優先してください。ヒステリシスを考慮した適切なヘルスチェックを実装し、可能な場合はスティッキーセッションを避け、主要なメトリクスを継続的に監視してください。

デプロイパターンについては、examples/aws/、examples/nginx/、examples/kubernetes/ などのプロバイダーディレクトリにある例を参照してください。