SRE Book #19 フロントエンドにおけるロードバランシング 輪読会補助資料

通称 SRE本の 19章の「フロントエンドにおけるロードバランシング」の19-2 「DNSを使ったロードバランシング」が初見で理解ができなかったので絵付きで解説を試みたログを書き残しています. もし、輪読会を開催されている方で同じような悩みを持たれている方と悩みを少しでも共有できればと思い共有します.

Transcript

1. 1 SRE Book #19 フロントエンドにおける ロードバランシング 19-2 「DNSを使ったロードバランシング」輪読会補助資料.
2. 2 資料化の背景 　通称 SRE本の 19章の「フロントエンドにおけるロードバランシング」の19-2 「DNSを使ったロードバランシング」が初見で理解ができなかったので絵付きで 解説を試みたログを書き残しています. もし、輪読会を開催されている方で同じ ような悩みを持たれている方と悩みを少しでも共有できればと思い共有します. 途中で調べたサイトはなるべく本文中にリンクを記載するようにしていますの で、適宜参照しながら読むことをお勧めします.
3. DC A 3 シンプルなAレコードを複数返すロードバランシング. DNS コンテンツ クライアント コンテンツ コンテンツ ① contents.com はどこ? ② 1.1.1.1 2.2.2.2 3.3.3.3 だよ 1.1.1.1 2.2.2.2 3.3.3.3 ③ ② で受け取った 値からランダム 　シンプルに名前解決で複数のAレコードを返す(RFC 1035 3.4.1) ので、クライ アント側で何の方策もなく対象のサーバにアクセスする. クライアントの挙動 がほとんど制御でき ない 地理最適 DC B DC C
4. 4 SRVレコードを利用したロードバランシング. DNS コンテンツ クライアント コンテンツ コンテンツ ① contents.com はどこ? ② address pr 1.1.1.1 1 2.2.2.2 2 3.3.3.3 3 だよ 1.1.1.1 2.2.2.2 3.3.3.3 ③ priority 高いし1 だな。 　SRVレコード(RFC2782)を利用して、重み付け(weight)や優先付け(priority) を指定可能だが、HTTP ではサポートされていない. クライアントが コントロールされている 地理最適 でもHTTPでは使えない...
5. 5 潜在的な問題. DNS コンテンツ クライアント コンテンツ コンテンツ ① contents.com はどこ? ② address pr 1.1.1.1 1 2.2.2.2 2 3.3.3.3 3 だよ 1.1.1.1 2.2.2.2 3.3.3.3 ③ priority 高いし1 だな。 　優先順位をクライアントに返却できるとしても、通常はクライアントに 最も近いアドレスをDNS側では判断できない. クライアントが コントロールされている 地理最適 でもHTTPでは使えない... 近 い ？ 近 い ？ 近 い ？
6. 6 エニキャストによって回避することはできる. DNS コンテンツ クライアント コンテンツ コンテンツ ① contents.com はどこ? をエニキャストで問い合 わせ 1.1.1.1 2.2.2.2 3.3.3.3 ③ よし！1.1.1.1 に行こう 　権威 DNS サーバーにエニーキャストアドレスを使って DNS クエリすること で、最も近いデータセンターへルーティングするアドレスを返却する. ※ 条件は結構厳しそう. 地理最適 DNS DNS ② 一番早く、 address 1.1.1.1 を返却
7. 7 (補足)エニキャストによって回避することはできる. 　(日本語訳を少し意訳による補足を加えて丁寧に.) We can mitigate this scenario by using an anycast address for authoritative nameservers and leverage the fact that DNS queries will flow to the closest address. 権威サーバーにエニキャストを利用し問い合わせすることで(この最も近いアド レスを判断できないという)シナリオは回避することができ、DNS のクエリが最 も近傍なアドレス(最も近傍な DNS が結果としてクライアント側からも最も近傍 な A レコードを返却)に行き着く、というエニキャストの性質をうまく活用でき る。
8. 8 さらに良い方法. DNS コンテンツ クライアント コンテンツ コンテンツ ① contents.com はどこ? をエニキャストで問い合 わせ 1.1.1.1 2.2.2.2 3.3.3.3 ③ よし！1.1.1.1 に行こう 　すべてのネットワークとそのおおよその物理的な位置の対応表を構築し、その 表に基づいてDNSのレスポンスを返す. ※ 複雑なDNSの実装が必要になってしまう... 地理最適 DNS DNS DNS Where? Address DNS1 Closest 1.1.1.1 DNS2 Middle 2.2.2.2 DNS3 furthest 3.3.3.3 ② 対応表を見て、Address 1.1.1.1 を返そう.
9. 9 でもでも... DNS コンテンツ クライアント コンテンツ コンテンツ ① contents.com はどこ? をエニキャストで問い合 わせ 1.1.1.1 2.2.2.2 3.3.3.3 ③ よし！1.1.1.1 に行こう 　非常に複雑なDNSサーバーの実装と、位置の対応表を最新に保つ処理のパイプ ラインの保持というコストが生じる. 地理最適 DNS DNS DNS Where? Address DNS1 Closest 1.1.1.1 DNS2 Middle 2.2.2.2 DNS3 furthest 3.3.3.3 ② 対応表を見て、Address 1.1.1.1 を返そう. 覚えられない
10. 権威 DNS DC A 10 実際には, 中間に再帰的なDNSがいるので複雑だ... 権威 DNS コンテンツ クライアント コンテンツ コンテンツ 1.1.1.1 2.2.2.2 3.3.3.3 　エンドユーザが権威DNSサーバに直接問い合わせすることはほとんどなく、代 わりに、再帰的な DNS がユーザとサーバの中間でプロキシする。 地理最適 DC B DC C 再帰的な DNS 権威 DNS 中間に存在して、再帰的 に権威サーバに問い合わ せする.
11. 11 (補足) 実際には, 中間に再帰的なDNSがいるので複雑だ... 　(日本語訳を少し意訳による補足を加えて丁寧に.) Of course, none of these solutions are trivial, due to a fundamental characteristic of DNS: end users rarely talk to authoritative nameservers directly. 勿論、エンドユーザが権威サーバに直接問い合わせをすることがほとんどないと いう DNS の基本的な性質のために、これら上記で挙げた解決策は些細なもの(単 純なもの)ではない。
12. 権威 DNS DC A 12 そのせいで... IP アドレスが再帰的に解決される. 権威 DNS コンテンツ クライアント コンテンツ コンテンツ DNS応答による最適化 が機能する区間はここ のみ. 1.1.1.1 2.2.2.2 3.3.3.3 　再帰的に名前解決されるので、権威DNSが見るアドレスが再帰的なリゾルバに 属するので本来のクライアントの情報がわからない。DNS 応答による最適化が行 われる区間にミスマッチが生じる. 地理最適 DC B DC C 再帰的な DNS 権威 DNS クライアント はどこ？ 5.5.5.5 本来最適化したい 区間
13. 権威 DNS DC A 13 解決方法. EDNS0拡張. 権威 DNS コンテンツ クライアント コンテンツ コンテンツ クライアントが所属す るサブネットは 1.0.0.0/8 です. 1.1.1.1 2.2.2.2 3.3.3.3 　再帰的なリゾルバが送信するDNSクエリにクライアントのサブネットに関する 情報を含むことでクライアントの目線で対応できるようになる. 地理最適 DC B DC C 再帰的な DNS 権威 DNS 5.5.5.5 1.0.0.0/8 であれば、 1.1.1.1 を返そう. contents.com はどこ?