mslb技術考案

動機

2009年頃、所属がクラウド関連になったとき、クラウドといえば負荷分散だなー、負荷分散といえばNATだなー、NATといえばアプリケーションとの相性問題だなー、などとぼーっと思いました。そして、アプリケーションとの相性の問題が無い負荷分散技術を作れないかなーと考え始めたのが、出発点です。

背景

NAT(Network Address Translator: RFC1631：The IP Network Address Translator (NAT)) とアプリケーションの相性問題は、知っている人は知っていて、最も有名なものは、ファイル転送(ftp)だと思います。ところが、このような問題について全く認識しない人は大勢います。RFC3235: Network Address Translator (NAT)-Friendly Application Design Guidelinesという動きもありますが、特にネットワークにあまり興味のない人の中には、通信は糸電話だと思っている人も少なくなく、いくら説明しても、なかなか理解に至らないというのは、散見されていました。クラウドが普及して、負荷分散がそれまで以上に使われるようになると、相性問題がより問題になる可能性を感じました。

考案技術の簡単な説明

NATベースの負荷分散技術は、サーバを複数用意して、サーバ宛のパケットの宛先アドレスを、これらサーバのどれかのIPアドレスに書き換えて分散させることにより実現します。ところが、サーバから見ると、自身のIPアドレスと、クライアントが指定したIPアドレスが異なることになります。このIPアドレスの不整合は、問題にならないアプリケーションももちろん存在するのですが、問題になるケースもあって、これが、アプリケーションとの相性問題になります。

そこで思いついたのは、宛先IPアドレスの書き換えは、分散させることが目的ですので、分散させたのちに、相性問題の原因であるIPアドレスの不整合を解消してしまえば良いのでは、というアイデアでした。具体的には、IPアドレスを書き換えて分散させる前段装置と、処理を割り振られる複数のサーバで構成される、従来の構成に対し、サーバ側に後段装置を追加して、そこで宛先IPアドレスを書き換える前のものに書き戻すのです。こちらの構成では、サーバには、クライアントが指定するIPアドレスを割り当てます。すなわち、前段装置とサーバに、同じIPアドレスが割り当てられることになります。この処理の追加により、サーバから見ると、自身のIPアドレスと、クライアントが指定したIPアドレスが同一になり、IPアドレスの不整合は解消されます。

これを考案して、早速特許を執筆しました。特許が出願されたのは、2010年1月6日です。考案して、特許の明細書を書いたのは、その数ヶ月前だと思います。所属変更が9月ですので、割と早くアイデアに恵まれたようです。

なお、負荷分散技術には、様々な技術があり、私の理解では、アプリケーション毎に特化した負荷分散技術と、NATベースの負荷分散技術がに分類できるのではないかと思っています。後者はネットワークエンジニアに馴染み深いと思います。前者の具体例は、例えばラウンドロビンDNSや、HTTP Reverse Proxyなどがあり、こちらは、サーバエンジニアに馴染み深いと思います。

考案技術の特徴

ここで、技術の特徴について整理しておきたいと思います。この技術の特徴は、以下の3点あると思っています。

1. アプリケーションの相性の解消<br>
   先に述べた通り、前段装置でIPアドレスを書き換え、分散後の後段装置でIPアドレスを書き戻してサーバに渡すことにより、IPアドレス不整合を解消しました。

2. 分散先のポリシー設定<br>
   負荷分散技術としては、パケット単位で分散先を決めることが理想系と思いましたが、この技術では、クライアントに対して、分散先のサーバを固定化できることも取り入れました。その理由は、どこかで触れられればと思います。

3. サーバから前段装置を経由せずにクライアントへ返信できる<br>
   IPアドレスの書き換えのみで実現される技術では、サーバからクライアントへの返信のパケットについても、書き換えが必要になります。その結果、サーバとクライアント間でやり取りされるパケットは全て書き換え対象となり、その結果、書き換えの装置がボトルネックになる可能性を秘めています。考案技術では、サーバからクライアントへの通信は、IPアドレスの書き換えが不要となり、前段装置を経由させる必要がなくなり、ボトルネックを解消できました。

特許

アイデアがまとまった時点で、特許出願すべく、明細書の執筆に取り掛かりました。出願されたのは2010年1月6日です。とりあえずは、ここでひと段落です。なお、この特許は、PCTで出願され公開されたのは、約1年半後の2011年7月14です。さらにその1年半後の、2013年1月3日に米国で登録、その半年後の2013年9月13日に日本で登録されました。

PoCの実施

特許明細書を書き終わった時点で、ひと段落ですが、この技術では、ソフトウェア試作すべく、活動を進めました。目的は、考案技術の効果を実際に動かして確認することですが、この技術の場合、同一IPアドレスを持つホストが、複数のサブネットに存在する、ヘンテコな構成ですので、実装できるのか、実装を用いて、このような構成を作り上げてきちんと動くのかを確認しておきたいと考えました。

半年程度で、試作ができ、小規模の構成で確認を行いました。ftpなど、NATと相性の悪いアプリの確認はもちろんですが、デモにならないので、Windows XPに当時搭載されていたNetMeetingも使ってみました。NetMeetingは、1:1のビデオ会議が可能なアプリで、H.323プロトコルが使われています。H.323はITU-Tで開発されたプロトコルで、NATと相性の悪いプロトコルでした。厳密にはサーバ負荷分散ではないのですが、クライアントから同じIPアドレスを指定すると、分散され、分散先とビデオ会議ができるようなデモです。ついでに、Windows XPのIPsec機能を用いて、ペイロードを暗号化してみました。これもうまく動き、考案技術の効果を実証することができました。

この確認で、ひと段落としました。