グーグルのクラウドを支えるテクノロジー　＞　第2回　分散型ロードバランサーを実現するMaglev（パート２）

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー　＞　第2回　分散型ロードバランサーを実現するMaglev（パート２） 」を公開しました。

＃＃＃
はじめに
　前回のコラムでは、分散型ロードバランサー「Maglev」を理解する準備として、一般的なロードバランサーの動作を解説した上で、「分散処理を実現する上での課題」を説明しました。Maglevは、これらの課題をどのように解決しているのでしょうか?　公開論文「Maglev: A Fast and Reliable Software Network Load Balancer」に基づいて、その仕組みをひも解いていきましょう。

分散型ロードバランサーを実現するポイント
　前回あげた課題は、コネクショントラッキングとDSR（Direct Server Return）に関連するものでした。まず、DSRの課題から説明すると、DSRの構成でロードバランサーから転送先のWebサーバーにパケットを送信する際は、L2レイヤーでの転送が必要になります。小規模な環境では、すべてのWebサーバーを同一のサブネットに配置すれば、L2レイヤーでの転送が可能ですが、複数のデータセンターにまたがって負荷分散するような際は、これは現実的な構成ではありません。

　Maglevにおけるこの問題の解決方法は、実は意外とシンプルです。先ほどの論文によると、GREトンネルによるオーバーレイネットワークを用いて、L3ネットワーク上でL2接続を実現しているそうです。ちなみに、この論文では、Googleが実サービス環境でMaglevの使用を開始したのは、2008年からと説明しています。最近では、SDN、あるいは、ネットワーク仮想化の考え方が広まるにつれて、オーバーレイネットワークもそれほどめずらしいものではなくなりました。その一方で、Googleでは、2008年の段階でオーバーレイネットワークを実活用していたというのは、興味深い事実ではないでしょうか。

Maglevハッシングアルゴリズム
　次は、コネクショントラッキングの説明です。コネクショントラッキングでは、5tuple、すなわち、IPパケットのヘッダーに含まれる「プロトコル番号（TCP/UDP/ICMPなど）、送信元IP、送信元ポート番号、宛先IP、宛先ポート番号」の組から、転送先のWebサーバーを一意に決定する必要がありました。この際、5tupleと転送先Webサーバーの対応は、すべてのMaglevサーバーで同一に保つ必要があります。これが必要な理由を図1の全体像を用いて説明していきます。

この続きは以下をご覧ください
(リンク »)