Googleってどうやって負荷分散してんだろ

id:Kappuccinoと先週だったかな?にした話(といってもチャットですが)。大学時代から良く色々チャットであれはどーなんだろこれはどーなんだろとやってたりするんですが、ディザスタリカバリの話かなんかからGoogleの負荷分散てどうなってんだろって話に。台数とか相当だろうし、ロードバランサ使ってるのはもちろんだろうけど、どんくらいあるのかとかとか。んで気になったのでその場で早速digる。

$ dig www.google.com

; <<>> DiG 9.4.2-P2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64198
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		508020	IN	CNAME	www.l.google.com.
www.l.google.com.	243	IN	A	66.249.89.104
www.l.google.com.	243	IN	A	66.249.89.147
www.l.google.com.	243	IN	A	66.249.89.99

~~ 

アドレス3つだけ。ラウンドロビンでどれかに分散されるとはいえたった3つのアドレスだけで受けきれるの?と。バランサいれても結局受け口のとこは一つのはずなんだからそれを考えるとたった3つのロードバランサだけでアホみたいな量のトラフィックの受け口を賄えるんだろうか、と。んで、今さっき「google、負荷分散」で調べてみたらこんなのがhit

http://netscaler.serverworks.co.jp/

コレ使ってるらしい。スペック情報はこれ。

http://netscaler.serverworks.co.jp/product/editions.php

値が大きすぎてピンとこないけど、一番よさそうなやつで同時TCPコネクションが500万。x3で150万。
DSR(Direct Server Return。この辺を参照http://d.hatena.ne.jp/yamaz/20060817)を使えば、実際ロードバランサは右から左へうけ流すだけだから。いけないでもない気がするけど。実際測ってみないとなんともいえないなぁ。SNMPのデータとれねーかな....。

$ snmpwalk -v2c -c public www.google.com
Timeout: No Response from www.google.com

流石に無理 w。さっきのロードバランサのページにYahooでも使ってるって書いてたのでこっちもdigってみた。

$ dig www.yahoo.com

; <<>> DiG 9.4.2-P2 <<>> www.yahoo.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17653
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.yahoo.com.			IN	A

;; ANSWER SECTION:
www.yahoo.com.		111	IN	CNAME	www.wa1.b.yahoo.com.
www.wa1.b.yahoo.com.	8	IN	CNAME	www-real.wa1.b.yahoo.com.
www-real.wa1.b.yahoo.com. 15	IN	A	209.131.36.158

一つだけ....だと...( ゚д゚)...?。どーなってんの?対してyahoo.co.jpは

$ dig www.yahoo.co.jp

; <<>> DiG 9.4.2-P2 <<>> www.yahoo.co.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15597
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.yahoo.co.jp.		IN	A

;; ANSWER SECTION:
www.yahoo.co.jp.	261	IN	A	124.83.139.192
www.yahoo.co.jp.	261	IN	A	124.83.147.202
www.yahoo.co.jp.	261	IN	A	124.83.147.203
www.yahoo.co.jp.	261	IN	A	124.83.147.204
www.yahoo.co.jp.	261	IN	A	124.83.147.205
www.yahoo.co.jp.	261	IN	A	124.83.167.212
www.yahoo.co.jp.	261	IN	A	203.216.227.176
www.yahoo.co.jp.	261	IN	A	203.216.235.154
www.yahoo.co.jp.	261	IN	A	203.216.235.201
www.yahoo.co.jp.	261	IN	A	203.216.243.218
www.yahoo.co.jp.	261	IN	A	203.216.247.225
www.yahoo.co.jp.	261	IN	A	203.216.247.249
www.yahoo.co.jp.	261	IN	A	124.83.139.191

アドレス、イパーイ。なんでやねん....そこはノリ的に一個にしとけよ....。まあソフトバンク傘下だからそもそも組織として違うだろうし違ってあたりまえか。こんくらい数あればなんとかなりそうだけどyahoo.comの方の一つはどーしても納得いかん。と思ってtcpdumpしながら何度かtelnetで80たたいてソースアドレスみてみた。

# tcpdump -n dst host 192.168.0.99 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

しながら

$ telnet www.yahoo.com 80

結果は

14:09:22.155312 IP 209.131.36.158.http > 192.168.0.99.51491: S 1245076509:1245076509(0) ack 208189204 win 65535 
14:09:24.471504 IP 209.131.36.158.http > 192.168.0.99.51491: . 1:1403(1402) ack 8 win 32947 
14:09:24.471866 IP 209.131.36.158.http > 192.168.0.99.51491: . 1403:2805(1402) ack 8 win 32947 
14:09:24.472341 IP 209.131.36.158.http > 192.168.0.99.51491: . 2805:4207(1402) ack 8 win 32947 
14:09:24.619121 IP 209.131.36.158.http > 192.168.0.99.51491: . 4207:5609(1402) ack 8 win 32947 
14:09:24.619595 IP 209.131.36.158.http > 192.168.0.99.51491: . 5609:7011(1402) ack 8 win 32947 
14:09:24.619771 IP 209.131.36.158.http > 192.168.0.99.51491: . 7011:8413(1402) ack 8 win 32947 
14:09:24.620000 IP 209.131.36.158.http > 192.168.0.99.51491: FP 8413:9491(1078) ack 8 win 32947 
14:09:24.755980 IP 209.131.36.158.http > 192.168.0.99.51491: . ack 9 win 32946 

何度やってもこんな感じでやっぱり。同じソースアドレスからしかとんでこない。わざわざソースアドレス偽装とかしてるのかなー?。アドレスバレたら嫌だろうから、まあないとは言い切れないけど行きも帰りも全部1カ所を絶対通ってるんだろうか...。どうしても腑に落ちん。

実際この辺まで細かいとこ調べたのはついさっきで。id:Kappuccinoと話したのは複数台の物理サーバを仮想的に1つに見せられないか?という話。それならアドレス一つでも処理できるのでないかと。一瞬グリッドだの分散だのって単語がよぎったけどアレはタスクを分割してみんなに計算してもらいましょーというものだったと思うので概念的には違うものでしょうね。技術的にはやってやれんことはないんじゃないかな見たいな事を話をしてました。別の話も色々してたんで、たぶん異なる筐体の複数の物理インタフェースが一つの仮想アドレスにバインドされてパケットがセッション単位で同じ物理インタフェースに飛べばいいんぢゃないかみたいななんとなーくで話は終わったんですが、ちょっと調べてみた所こんなのが見つかりました。

http://ja.wikipedia.org/wiki/%E5%AF%86%E7%B5%90%E5%90%88%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%83%BC

概念的には上で行ってることと合致してると思うんですが、下の方の説明の一部はそれってフェールオーバークラスターだから結局処理してるホストって1台だしちょっと違うのではっていう感じがしますね。実装されてるのとかないのかなぁ。GoogleとかYahooだと自分たちで実装してたりしそうだけど...。

追記

寝て起きたら、(*゚ロ゚)ハッ!! っと思いついたんだけど、

もしかしてbindのViewみたいな機能つかって特定のソースアドレス単位で返すアドレス変えてるんじゃなかろーか?

つまり日本のアドレス帯からなら

111.111.111.111

アメリカからなら

222.222.222.222

みたいに返すようにする。そうすれば、問い合わせ元に物理的に近い場所にあるサーバに誘導したりもできるし、自分のところから見えるアドレスの数が少ないのも納得いきます。

改めてwww.google.comのアドレスを見ると

www.google.com.		463598	IN	CNAME	www.l.google.com.
www.l.google.com.	243	IN	A	66.249.89.104
www.l.google.com.	243	IN	A	66.249.89.147
www.l.google.com.	243	IN	A	66.249.89.99

結構近いレンジに全部入ってますね。たぶん同じサブネット内で近い場所にあるんじゃないでしょうか。よくよくみるとわざわざサブドメイン切ってCNAME向けてるし、これだと各々のViewにおけるゾーンの設定でCNAMEのみ向け先を変えれば簡単に振り先を返られるし増々怪しい。

http://www.seomoz.org/ip2locでアドレスから場所を調べる限りは全部、西海岸にあるみたいですねー。これで国内とかにあれば確信したんだけどな。翌々考えたら国内は基本的にgoogle.co.jpに行くだろうしそもそもドメインが違うか。まあそれでも聞きにくる場所によっては、アメリカ国内の西、東の2カ所くらいで分散して答えてそうだと思うけど確信が持てないなー。

どっか外国から調べられんかな?と思って外国のlookupとかしてくれそうなサイトを探してみました。んで見つけたのがこれ。

http://www.zoneedit.com/lookup.html?host=www.google.com&type=A&server=&forward=Look+it+up

さっそくwww.google.comのAレコードを引いてみる。

Host	Type	Value
www.google.com.	A	209.85.171.103

おぉおぉおおおおおおお。アドレス違う.....。

ビンゴぉおおおおおおお

上記サイトは一個しかでないですけど、不安だったので他のサイトからも調べてみたところ。

http://network-tools.com/nslook/Default.asp

name	class	type	data	time to live
www.l.google.com	IN	A	209.85.225.103	300s	(5m)
www.l.google.com	IN	A	209.85.225.147	300s	(5m)
www.l.google.com	IN	A	209.85.225.99	300s	(5m)
www.l.google.com	IN	A	209.85.225.104	300s	(5m)

4つあるみたいですね。先ほどのサイトで場所を調べた所さっきより少し南に進んだロスあたりが表示されました。この分だとアメリカ国内に複数ありそうだなー。ヨーロッパとかだと東海岸あたりに向いてるんじゃないでしょうか。たぶんwww.yahoo.comの方も同じようなことしてるんでしょうねー。意外にシンプルな解決方法でしたね。運用的な視点からみるとシンプルな方がいざという時に困らないっていうところもありますし、良い方法だなと思います。負荷分散面白いなー。今大学に戻って研究できるならこの分野をやりたいと思いますね〜。クラウドコンピューティングとかも含め分散技術は絶対今後必要になってくるとこだと思いますし。