Skip to content

Latest commit

 

History

History
46 lines (38 loc) · 5.21 KB

19-LoadBalancingAtTheFrontend.md

File metadata and controls

46 lines (38 loc) · 5.21 KB
  1. Load Balancing at the Frontend ==================================
  • この章ではhigh-level load balancing に着目。DC間ユーザトラフィックをどのように分散するのか。
  • 次の20章ではDC内のロードバランシングについて。

Power Isn't the Answer

  • 最適なトラフィック分散とは
  • 2つのcommon traffice scenarios: 検索リクエストと動画アップロード
  • 検索リクエストはレイテンシ重視なので、the nearest available datacenterに送られる
  • 動画アップロードはスループット重視なので、あまり使われてないネットワークパスにルーティングされる
  • しかし、ローカルレベルでは、最適なリソース使用率に着目し、1つのマシンが過負荷にならないようにする
  • 実際には、キャッシュを温めるために少し離れたDCに向けられたり、非インタラクティブなトラフィックをnetwork congestionを避けるために全く別のリージョンに向けることもある
  • Googleでは複数のレベルで負荷分散する。そのうちの2つを以下のセクションで説明する

Load Balancing Using DNS

  • DNSラウンドロビンによる分散 (// よく知ってるので端折っていく)
  • 最初の問題は、クライアントの動作を制御できないこと。ランダムに選択される。理論的には、SRVレコードで重み付けと優先度制御はできる。しかし、SRVレコードはHTTPでは採用されていない。
  • もうひとつの潜在的な問題は、クライアントが最も近いアドレスを選択できないこと。
    • 権威サーバにエニーキャストでクエリできたりするが、ユーザは権威サーバに直接アクセスすることはほとんどない
  • DNSの3つの観点
    • IPアドレスの再帰的解決
    • 応答経路の非決定性
    • 余分なキャッシングの複雑さ
  • IPアドレスの再帰的解決: EDNS0 で解決できる。EDNS0にはDNSクエリをなげたクライアントのサブネット情報を含められるので、リゾルバではなくユーザの観点で最適なIPアドレスをかえせる。OpenDNSやGoogle1などが対応済み。
  • 応答経路の非決定性: ネームサーバは大量のユーザにサービスを提供する責任がある。例えば、ISPのネームサーバーは、すべてのユーザーにとってより良いネットワークパスが存在するにもかかわらず、データセンターに最も適したIPアドレスの応答を返す。
  • DNSロードバランシングの best location? ユーザに最も違い場所という観点以外に、選択したデータセンターのキャパシティが十分かどうか
  • 余分なキャッシングの複雑さ: DNSのTTLを意識しましょう以外のことができない。
  • これらの問題にかかわらず、DNSは効果的なロードバランシング方法である。一方で、これだけでは不十分。DNS応答は512バイト制限 RFC 1053 がある。
    • この制限により、応答に詰め込めるアドレスの数の上限が決まる。Googleのサーバ数は上限にあたりつつある。
  • フロントエンド・ロードバランシングの問題を実際に解決するには、この初期レベルのDNSロードバランシングの後に仮想IPアドレスを利用するレベルが必要。

Load Balancing at the Virtual IP Address

// この辺はいつもやってる話

  • VIPとは。VIPで重要なのはパケット転送部分。TCPのようなステートフルプロトコルを意識した接続単位でのバランシング。
  • 単なる剰余だと、1台落ちたときに急にパケット転送先がかわる。メモリ内にすべての接続の状態を維持する必要はなく、consitent-hashing を使うと良い。
  • 具体的に、どうやってパケット転送するのか。
      1. NAT。ただし、トラッキングテーブルにすべての接続エントリを保持する必要がある。
      1. L2の情報を変更する。転送パケットのMACアドレスを変更する。DSRができる。DSRならロードバランサに状態を持たせる必要がない。同一セグメント制約がある。
  • Googleの現在のVIPソリューションは https://research.google.com/pubs/pub44824.html 。パケットのカプセル化を使っている。Generic Routing Encapsulation（GRE） https://tools.ietf.org/html/rfc1702 // LVS-TUN と同じはず
  • パケットカプセル化は、ネットワーク設計の変化に大きな柔軟性をもたらすメカニズム。しかし、パケットサイズオーバヘッドがある。IPv4 + GREの場合、24バイト。MTUを超えて、フラグメンテーションが必要になるかもしれない。
  • パケットがデータセンターに到達すると、データセンター内のより大きなMTUを使用してフラグメンテーションを回避できる。 ただし、大規模なProtocol Data Unit ((たぶんJumbo Frameみたいなやつ？) が必要。