自分の理解を深めるためにまとめてみました。18章の続きです。
19章 フロントエンドにおけるロードバランシング
DNSを使ったロードバランシング
DNSのレスポンスとして複数のAもしくはAAAAレコードを返し、クライアントに任意のIPアドレスを選んでもらう。シンプルではあるが、以下の課題がある。
- クライアントの挙動がほとんど制御できない。
- 理論的にはSRVレコードを使ってレコードの重みや優先順位を指定できるが、SRVレコードはまだHTTPには採用されていない。
- 通常はクライアントに最も近いアドレスを判断できないということから生じる。
- 権威DNSサーバにエニーキャストアドレスを使い、DNSのクエリが最も近いアドレスに流れることを利用すれば問題は軽減される。
DNSは最もシンプルなロードバランシングの方法であるが、レスポンスを512バイトに収めないといけないというRFC1035の影響で、1つのDNSレスポンス内に収めることのできるアドレス数には上限ができてしまい、その値はGoogleのサーバ数を下回ってしまう。
仮想IPアドレスでのロードバランシング
仮想IPアドレスはユーザからは単一のIPアドレスに見えるが、裏側では多くのデバイスで共有されている。実際にはネットワークロードバランサーで行われている。
リクエストの振り分け方としていくつかパターンがある。
- 最も負荷の低いバックエンドを選択する。
- ステートフルなプロトコルの場合は破綻する。
- セッションIDを使って同一のバックエンドを選択する。
- バックエンドの故障に対して弱い。
- コンシステントハッシュ法によって上記課題は解決できる。
ロードバランサーはどのようにしてバックエンドにパケットをフォワードするのか。解決策はいくつかある。
- 変換テーブルを保持して、ネットワークアドレス変換を行う。
- データリンク層（レイヤ2）の情報（MACアドレス）を書き換える。（DSR）
- ロードバランサから直接端末が接続できる必要があるため大規模な環境では使えない。
- 別のIPアドレスパケットで元のパケットをカプセル化してしまう。
- 大きな柔軟性を持っているが、パケットサイズが大きくなってしまうことでパケットが分割されてしまう点が課題。
（20章に続く）