LinuCレベル4 システムアーキテクト 可用性の設計 問4
可用性の設計／負荷分散と障害の局所化動画配信サービスで、リクエストは小さいがレスポンスは非常に大きい。現在はNAT方式のL4ロードバランサを使っており、ロードバランサを通過する通信量が性能の上限になっている。バックエンドのサーバーはロードバランサと同じL2セグメントにある。機器の増強に頼らず、構成の変更でこの上限を解消したい。この状況で採用する方式として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- ADirect Server Return方式に変え、バックエンドからの応答をロードバランサを経由せずにクライアントへ直接返す
- BNAT方式のまま、ロードバランサ自体をより処理能力の高い機器にスケールアップして通信量の上限を引き上げる
- CL7ロードバランサに置き換え、URIやHTTPヘッダを見て動画の種類ごとに適したバックエンドへ振り分ける
- Dロードバランサを廃止してDNSラウンドロビンに切り替え、クライアントが各バックエンドへ直接接続するようにする
正解：A
解説
NAT方式では、往路だけでなく応答の復路もロードバランサを通るため、レスポンスが大きいサービスではロードバランサの転送能力がボトルネックになります。Direct Server Return（IPVSではDirect Routing）方式では、ロードバランサは往路のパケットだけを転送し、バックエンドは応答をクライアントへ直接返すため、大きな応答の通信量がロードバランサに掛かりません。前提として、バックエンドが同じL2セグメントにあることや、各バックエンドがVIPをループバック等に持ち、そのVIPへのARP応答を抑止する設定が必要です。また、ロードバランサが復路を見ないため、L7の処理や応答の加工はできないというトレードオフがあります。
選択肢ごとの解説
- A正しい。復路がロードバランサを経由しなくなるため、応答が大きいサービスでのロードバランサの通信量のボトルネックを根本的に解消できます。
- B誤り。一時的な改善にはなりますが、応答のすべてがロードバランサを通る構造は変わらず、通信量の増加に合わせて機器を増強し続ける必要があります。
- C誤り。L7ロードバランサは内容に基づく振り分けに向きますが、応答も経由するうえ処理負荷が増えるため、通信量のボトルネックの解消にはなりません。
- D誤り。DNSラウンドロビンは停止したサーバーのアドレスも返してしまい、ヘルスチェックに基づく振り分けができないため、可用性が下がります。