ロードバランシングとフェイルオーバー

1）目的と条件

バランシングは、パフォーマンスとレジリエンスのために、インスタンス/ゾーン/リージョン間でトラフィックを分散します。
フェイルオーバー-フェイルオーバーを制御。
RTO/RPO：リカバリ時間の目標と許容可能なデータ損失。
SLO：可用性/レイテンシの目標レベル。自動feiloverおよびロールバックのための「ゲート」として役立ちます。

2）層のバランスをとること

2.1 L4 （TCP/UDP）

長所：パフォーマンス、シンプルさ、TLSパススルー。短所：ルートの理解/クッキーはありません。
例：NLB/GLB、 HAProxy/Envoy L4、 IPVS。

2.2 L7 （HTTP/gRPC）

長所：パスルーティング/ヘッダー、カナリアウェイト、粘着性。短所：CPU/レイテンシではより高価です。
例：NGINX/HAProxy/Envoy/Cloud ALB/APIゲートウェイ。

2.3グローバル

DNS/GSLB： health-checks+geo/weighted response。
Anycast/BGP：世界中で1つのIP、最も近いアナウンスポイント。
CDN/Edge：周囲のキャッシュ/Feilover。

3）配布アルゴリズム

ラウンドロビン/重み付け-基本。
最低接続/レイテンシ-「重い」リクエストの場合。
一貫したハッシング-センターセッションなしのユーザー/テナントの粘着性。
ハッシュベースのローカリティ-キャッシュとステートフルサービス。

4）セッションと粘着性

Cookie-sticky： L7 LBはインスタンスに戻るためのCookieを設定します。
Src-IP sticky： L4では、NAT/CGNATで悪化します。
一貫性のあるハッシュ：水平キャッシュ/チャットに適しています。
目的：可能であれば、ステートレスサービスを実行します。そうでなければ、状態（Redis/DBのセッション）を取り出してフェイルオーバーを簡素化します。

5）信頼性： 健康チェックと回転からの除去

アクティブチェック：HTTP 200/deepビジネスパスプローブ（例：依存関係を持つ'/healthz/withdraw'）。
パッシブ（アウトリアー検出）：5xx/タイムアウト時のバックエンドイジェクション。
ウォームアップ：新しいインスタンスのスムーズなインクルード（スロースタート）。
Graceful drain-プールから削除→リクエストが完了するのを待ちます。

NGINX（例）：

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Envoy outlier検出（フラグメント）：

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6）欠陥管理： タイムアウト/再試行/回路破壊

タイムアウト：クライアントのタイムアウトより短い。ルートごとに指定します。
再試行：ジッタおよびidempotencyの1-2；idempotenceキーなしでPOST上のリトレイを禁止します。
遮断器：同時に要求/エラーを制限すること；「セミオープン」回復。
予算：自己DDOSを整理しないように、バーストの制限/合併を再配置します。

7） Kubernetesパターン

ClusterIP/NodePort/LoadBalancer/Ingress-基本プリミティブ。
準備/活気：既製のボードでのみトラフィック。
PodDisruptionBudgetは同時にNレプリカをドロップできません。
HPA/VPA： CPU/REDメトリックによるスケーリング、LBへのリンク。
ServiceTopology/Topology Awareヒント：ゾーンごとの局所性。
Service type=LoadBalancer （zonal）：各AZの少なくとも2つのレプリカ。

重要なルートの準備の例：

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8）クロスゾーンとクロスリージョナルトラフィック

マルチAZ（領域内）：均等に分散（ゾーンLB）、ストレージ-同期レプリカ。

複数の地域：

アクティブ-アクティブ：両方の地域がトラフィックを提供します。より複雑に-データのレプリケーション、一貫性、および地理的なルーティングが必要です。
アクティブ-パッシブ：主な地域が提供しています、予約-"ホット/ウォーム/コールド。"簡単で高速なスイッチングが、より高いRPO。

GSLB戦略：

Geo-DNS（最寄りの地域）。
重み付けDNS（カナリア/再配布）。
遅延ベース（RTT測定）。
フェイルオーバー=健康/可用性シグナル（複数の視点からのプローブ）。

9）データとフェイルオーバー

キャッシュ/状態：可能であれば-地域的にローカル；アクティブ-アクティブ-CRDT/一貫性のあるハッシュ。

DB：

同期レプリケーション=低いRPO、より高いレイテンシ。
Asynchronous=lower latency、しかしRPO> 0。
キュー：ミラーリング/マルチクラスタトピカル；イベント重複排除。
操作とリプレイメカニクスの特異性を設計します。

10）周囲： DNS/Anycast/BGP/CDN

DNS：短いTTL （30-60代）+ネットワークからの健康チェック。
Anycast： 1つのIPを持ついくつかのPOP-最も近いものはトラフィックを受信し、feiloverはルーティングレベルにあります。
CDN/Edge：保護のためのキャッシュおよび「ゲートウェイ」、originが落ちるとき静的/媒体は整備されます；origin-shield+ポップヘルス。

11）サンプル構成

HAProxy L7：

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINXスティッキークッキー：

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout （route）：

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12）自動フェイルオーバー： 信号とゲート

Tech-SLI： 5xxレート、p95/p99、飽和、TLSハンドシェイク、TCPリセット。
ビジネスSLI：預金/支出の成功、PSPでの支払いエラーはありません。
ゲート：しきい値を超えた場合、ゾーン/インスタンスをオフにし、安定したプールの重みを上げ、GSLBを切り替えます。
Runbook：ステップバイステップのロールバック命令。

13）テストおよび点検（混乱及びゲーム日）

カオステスト：AZ/リージョンの無効化、DB/キャッシュの劣化、パケット損失シミュレーション。
ゲームデー：オンコールチームをフィーチャーしたトレーニングフェイローバー。
Diagnostics：周囲からバックエンドへのトレース、リリースアノテーションとメトリックの一致。

14）安全性とコンプライアンス

LB↔servisyの間のmTLS、周囲のWAF/Rateの限界。
障害/セグメンテーションゾーン：blast-radius isolation。
ポリシー：単一障害点（SPOF）禁止、「最小N レプリカ/AZ」の要件。

15）アンチパターン

すべてのトラフィック（SPOF）に対して1つのLB/1ゾーン。
ディープチェック'/healthz'はありません（緑-しかし、DB/キューは利用できません）。
idempotency→double transactions/paymentのない再トレイ。
質量NAT→不均衡でIPあたり粘着性があります。
高いTTL（切替える前の時間）のDNSのfeilover。
劣化した場合の優雅な排水はありません-リクエストの破損。

16）実装チェックリスト（0-45日）

0-10日

AZ ≥ 2へのポストインスタンス；準備/生活、健康チェックを有効にします。
L7-timeouts/retries （1試行）、外れ検出を設定します。
優雅な排水管および遅い開始を可能にして下さい。

11-25日

周囲のGSLB（地理/重み付け）またはAnycastを入力します。
カナリアウェイト/ルートポリシー；クッキー/一貫性のあるハッシュで粘着性があります。
自動feilover （p95/5xx+ビジネスSLI）用のSLOゲート。

26-45日

地域のDR：翻訳テストでアクティブ-アクティブまたはアクティブ-パッシブ。
AZ/リージョンがオフの混乱日、RTO/RPOレポート。
runbook'と（pause/shift/rollbackスクリプト）を自動化。

17）成熟度の指標

マルチAZカバレッジ≥クリティカルパスの99％です。
DNS/GSLB/Anycastはパブリックエンドポイント用に実装されています。
1つのAZが落ちたときのMTTR <5分（p95）。
重要なデータ≤ターゲットのRPO（例えば、≤ 30秒）。
四半期ごとのゲーム日数と成功した予定のfeilover。

18）結論

信頼性の高いバランシングとフェイルオーバーは、ローカルL7-policies （タイムアウト/リトライ/CB、ヘルスチェック）、正しい粘着性とハッシング、クロスゾーンの安定性、周囲のGSLB/DNS/Anycastなどのレイヤーアーキテクチャです。SLOゲート、idempotency、優美なドレイン、定期的なカオステストを追加します。ノード、ゾーン、または領域の損失は、予測可能なRTO/RPOで管理可能なイベントになります。

ロードバランシングとフェイルオーバー