今回は、マルチホーミングの専用アプライアンスにおいてデファクト・スタンダードであるRadware社のLinkProof を取り上げます。マルチホーミングとは、企業などのインターネットへの接続口であるISP回線を複数束ねることで、耐障害性の向上や回線の負荷軽減を実現し、結果としてパフォーマンス向上を可能にする技術です。

1. なぜマルチホーミング専用アプライアンスが求められるのか
2. LinkProof 最大の特徴「無停止拡張」を実現したOnDemand Switch
3. LinkProof 構築時に注意したい6つのポイント

ご存知の方も多いかもしれませんが、実はマルチホーミングを行うためには、LinkProof などの専用アプライアンスを使用せずとも、BGPというプロトコルでも同様のことができます。では、なぜ専用アプライアンスが必要となるのでしょうか。それぞれの手法で実現した場合の特徴を書きだしてみました。
 
BGP で実現するマルチホーミングを実現する場合

1.	BGPに精通したエンジニアが必要である。
2.	格安の接続サービスが使えない。
3.	S番号（Autonomous System number）と呼ばれる番号を各ISPから取得する必要がある。
4.	動的な負荷分散が困難である。 特にインバウンド・トラフィックは、意図的に分散することは困難である。

LinkProof などの専用アプライアンスでマルチホーミングを実現する場合

1.	比較的容易に導入が可能で、回線追加も容易である。
2.	回線の障害をすばやく検知し、シームレスな回線の切り替えが可能になる。
3.	独自のアルゴリズムによって動的に負荷分散できる。 さらにインバウンド・トラフィックについても意図的に分散できる。 （専用アプライアンスの中には制御できないものもあります。）
4.	接続サービスに依存しない（ADSL , 専用線の混在も可能）ため、既存で利用しているサービスをそのまま継続して利用できる。
5.	すべて主回線として使用できる。

専用アプライアンスによるマルチホーミングは、BGPを利用する方法に比べて高価ではあるものの、ルーティングやDNSなどの一般的なネットワーク知識さえあれば導入でき、技術的なハードルも低くなります。また専用アプライアンスを利用すれば、動的負荷分散や回線帯域の制限、コネクション数制限など様々な機能が活用できます。さらに、接続サービスを選ばないため、既存の接続サービスを継続したままマルチホーミングを実現できるというメリットがあります。

上記では、専用アプライアンスのメリットについてお話しましたが、当然デメリットもあります。それは、パフォーマンス毎に筐体が分かれている製品が多く、今後発生するサービスの拡張などに伴って、筐体自体の買い替えが必要となってしまうことです。だからこそ、導入先のスケールアップを見越したサイジングが必要となります。購入する側としては、コストと利便性の見極めが重要なファクターの一つになってきます。
そんな中、Radware社のLinkProofでは、OnDemand Switchと呼ばれる、最大スループットが4Gbpsと16Gbpsの二つの筐体を用意しており、上記のようなユーザの悩みを解決しています。
この製品は、一つの筐体に対して、ライセンスによって最大スループットにソフトウェア的な制限をかけています。つまり、初期導入時に最小の100Mbps のライセンスを購入した場合でも、その後のサービスや人員増加など帯域の増加に合わせてスループットの拡張が可能となり、規模に応じた適切な投資を実現します。さらに、ライセンス拡張は無停止で行うことができるため、サービスを提供している場合であっても、サービスへの影響を心配する必要がありません。 また、ライセンス制限がかかっているのは、最大スループット部分だけとなり、CPUなどのリソースは、たとえ100Mbps のライセンス契約であっても、4Gbps ライセンス使用時と遜色なく使用することが可能です。また、CPUなどの筐体的なメリットに加え、4Gbpsトラフィック時の最大セッション数を想定しているため、サイジング時は、基本的にスループットを意識するだけ。導入時のハードルを大幅に下げられます。

LinkProof では、レイヤー4までのセッション維持を行うことが可能です。具体的には、①送信先/送信元IPアドレスによるセッション維持、②送信元/送信先IPアドレスとPort 番号によるセッション維持の二つの手法が活用できますが、基本的には①のセッション維持を利用しています。
②のセッション維持は、例えばLinkProof配下にProxy サーバのようなIPアドレスを終端するような装置がある場合が想定されます。この場合、送信元・送信先IPアドレスが一致してもPort 番号が異なれば、負荷分散のアルゴリズムによって回線選択が改めて行われるため、①の場合に比べて負荷分散としての効果が期待通り得られることがあります。一方で、クライアントからInternet 上にある特定のWebページを取得しようとする場合、ブラウザによっては、同時に複数のコネクションを張ることもあります。そうなると、例えばWebページの文字情報は回線Aから、画像情報は回線Bからといったように、アクセスが分散することも考えられます。そのため、接続先のアプリケーションによっては正しい結果を得られないことがあるので、その点は注意が必要です。 LinkProof では、直近のルータだけではなく、その先にあるルータやその他のインターネット上のリソースに対しても、直近ルータを経由させてヘルスチェックできます。回線のアベイラビリティをチェックすることで、障害が発生している回線を回避することも可能です。
LinkProof では下記の図内にあるHTTPでのヘルスチェックやDNSでのチェックなど様々なヘルスチェック機能がありますが、基本的に通信経路のアベイラビリティが確保できていればよいため、アプリケーションレベルのヘルスチェックは不要となり、Ping でのヘルスチェックで十分であると考えています。ただし、Ping でのヘルスチェックができないようなケースもあり、そういった場合にHTTP やDNSでのチェックが行われます。 LinkProof では、任意の送信元 / 送信先IPアドレス帯、アプリケーションポートによって、ポリシーを作成し、振り分ける回線を自由に選択させることができます。
例えば下記の図のように、重要度の高い取引用Webサーバへのアクセスやクラウドサービス利用、社外取引事務部門の通信などに関しては、基本的に回線C（100Mbps帯域保障型の回線）を利用し、その他の雑多なトラフィックに関しては、他のブロードバンド回線A、 Bを使用するように分散制御を行います。さらに、社外から取引用Webサーバへアクセスする場合は、社内からのクラウドサービス利用や社外取引事務部門の通信に比べて重要であるため、100Mbpsのうち、常に50Mbps 以上の帯域を確保します。その場合、社内からのクラウドサービス利用や社外取引事務部門の通信を50Mbps までと帯域の上限値を設定し、社外アクセスからの帯域を確保します。このとき、制限が設けられた社内からの通信に関しては、他のブロードバンド回線A、Bを利用するようにバックアップを設けておきます。
このように、LinkProof では、用件に合わせた柔軟なトラフィックの制御を行うことができます。 LinkProof では、公開されたサービスへのローカルリソースに対するインバウンド・トラフィックについても負荷分散制御できますが、その場合はDNSの仕組みを利用します。具体的には、既存のDNSサーバと連携し、既存のDNSサーバからLinkProofが持つDNSへNSレコードで権限を委任し、最終的にLinkProofがAレコードを返すようにします。
このとき、LinkProof は、各回線のアベイラビリティや負荷状況に応じた回線からアクセスするように、Aレコード応答をします。

①	クライアントからのDNSリゾルバに対してDNSリクエストを送信
②	DNSリゾルバから公開DNSにAレコードの保持先を問い合わせ
③	LinkProof がAレコードを保持していることを返信
④	LinkProof にAレコードを問い合わせ
⑤	回線のアベイラビリティ、負荷状況によってAレコードを返信
⑥	DNSリゾルバよりクライアントへDNSリクエストの回答を返信

前述した通り、既存のDNSサーバで応答している公開サーバのAレコードを、LinkProof にて応答させるため、NSレコードでLinkProof を指定する必要があります。一例として、BINDの設定変更の例を記述します。サブドメイン無しのホストについては、NSレコードで権限委譲することができないため、DNSサーバ自体で解決するようにします。また、MXレコードについても、DNS上のプレファレンス値を利用し、DNSサーバ自体で制御します。 LinkProof を導入する場合、複数のIPアドレスが必要となります。下記では、一例として、公開サーバが3台あり（公開DNSを含めると4台）、インターネット接続する複数のクライアント端末があると想定した場合の、一つのISPで必要となるIPアドレス数を書き出しました。 必要となるグローバルIPアドレスの数

1.	ルータのIPアドレス
2.	正系LinkProof の物理インターフェイスのIPアドレス
3.	公開サーバ用の公開DNSサーバへのアクセス用のNATアドレス
4～6.	外部公開サーバ用のNATアドレス(公開サーバ台数分が必要)
7.	クライアントがInternet へアクセスするためのNATアドレス(動的IPマスカレード) さらに、機器の冗長化を行う場合は、下記の分のIPアドレスも必要となります。
8.	副系LinkProof の物理インターフェイスのIPアドレス
9.	LinkProof のDNS機能用のIPアドレス （非冗長時は正系の物理インターフェイスで対応可能なため不要）

大学などでよく使用が見られるSINET（学術情報ネットワーク）を使用している場合など、既存で公開しているサーバのIPアドレスにグローバルIPアドレスが付与されている場合があります。この場合、LinkProof では、下記のようにLinkProof で①Internet 側のグローバルIPセグメントと②公開サーバ群側のグローバルIPセグメントに分けます。そこに、③新規契約したISPのグローバルセグメントを追加します。 ①から②への通信を行う場合（逆も然り）、当然ながらLinkProofではルーティング処理によってトラフィックを転送します。ただし、LinkProof の設定上では”No　NAT” という、敢えてNATしないという設定を投入する必要があります。それは、インバウンド・トラフィック処理時にLinkProof がAレコードを応答するとき、Aレコード（= 公開サーバのアドレス）に紐づく、NATアドレスを参照するという仕組みのため、敢えてNATしない”No NAT” として、登録する必要があります。

ちなみに、③から②への通信を行う場合（逆も然り）、③のセグメントのグローバルIPアドレスに対して、②のセグメントのIPアドレスでNATし、トラフィック転送を行います。
 
以上、マルチホーミング専用機の必要性とLinkProof を構築する場合のコツについて紹介しました。LinkProof をご提案・ご検討される場合は、弊社営業までご連絡いただけると幸いです。