本講座は、ITエンジニアの為の明日から役に立つシステム構築スキルや技術・製品スキルなどをご提供します。まだお客様へご提案したことがない製品や技術でも、ポイントを押さえた実務知識を短時間に把握したい方にお勧めです。
Macnica Networks Corp.
1台のサーバでアプリケーションを提供するには、多くのユーザからのアクセスに耐えうるだけのパフォーマンスを備えたサーバが必要になります。ただ、ハイパフォーマンスのサーバは当然コストが高く、さらにパフォーマンスを向上させる際にも限界が出てきます。そこで役立つのが、1台当たりの負荷を下げて快適なサービスを提供できるよう、同じ機能を持つサーバを複数台用意してアクセスを分散させる負荷分散装置です。
高度な機能を持つ負荷分散装置は、単にアクセスを均等に分散するだけではありません。サーバに振られているアクセス量やサーバの状態を動的に判断しながら分散させることができるようになっています。
AppDirectorは他のロードバランサ製品に比べ、ローエンドモデルと競合できる価格設定ながら、ハイエンドモデルにも劣らない幅広い高機能を高いパフォーマンスで実現できる性能を備えています。ここでは技術的な部分に焦点を当てながら、AppDirectorの機能を紹介します。
AppDirectorでは、最大スループットが4Gbpsと16Gbpsの2つの筐体を用意しています。また、ライセンスによって200Mbpsや1Gbpsなどのモデルも提供していますが、これらの製品はすべて4Gbpsの筐体を活用しています。つまり、200Mbpsのモデルであっても、筐体的には4Gbpsのスループットに対応できるパフォーマンスを有しているのです。
筐体が同じだからこそ、当初導入したモデルより高いスループットのモデルが必要になった場合でも、ライセンスの追加購入だけで対応することが可能です。導入当初は将来的なパフォーマンス予測が難しいものですが、AppDirectorであれば莫大な初期コストをかけることなく、需要に見合った投資を行うことができます。
さらに、ライセンスで制限されているのは最大スループットのみで、CPU性能などは200Mbpsのモデルでも4Gbpsのモデルと同じです。低価格モデルでもCPU性能などは制限されないため、優れたパフォーマンスを出すことができます。一般的な低価格製品では、処理可能なトランザクション数が少ない場合など、スループット以外の要素を機器選定に考慮することが多いものですが、AppDirectorの場合はこのような考慮をする必要がありません。
また、AppDirectorはOn Demand Switchの全モデルでSSLオフロードにも対応しています。SSLの復号化処理は、ソフトウェアながら最大で毎秒5000トランザクションまで処理可能な性能を備えています。
さらにSSLの処理性能が必要な場合には、SSL処理をハードウェアで行うことで毎秒10000トランザクションまで対応できるXLモデルを用意。パフォーマンスが必要なSSLにも最適です。
L7パーシステンスとL7条件分岐
例えば、携帯電話からのアクセスがあるサーバでは、アクセスする度にそれぞれのキャリア内で異なるゲートウェイから異なるIPアドレスが割り振られる場合があり、IPアドレスやポート番号による接続維持がそもそも無意味になってしまいます。このような場合に備え、AppDirectorではアプリケーションレイヤー（L7）の情報も参照しながらパーシステンスを行うことが可能となっています。
具体的には、サーバからコンテンツが返ってくる時に、サーバごとに異なる特定の文字列がCookieとして埋め込まれているなら、再度クライアントから要求があった時にそのCookieを読み、同じサーバにアクセスさせることができます。
また、例えサーバで埋め込まれるCookieが不特定文字列（アクセス元ユーザにより異なるなど）であったとしても、AppDirectorでCookieの文字列を動的に学習しながら接続を維持することができます。
携帯電話のパーシステンスに関しては構築術の部分で詳しく紹介しますので是非ご参照下さい。
負荷分散装置の下に紐づくサーバ群が複数存在する場合、どのサーバ群に分散させるかの条件は、アクセスするIPアドレスやポート番号によって変わってきます。
AppDirectorでは、例え同じIPアドレスであっても、80番ポート（HTTP）でアクセスした場合はサーバ群①に、443番ポート（HTTPS）でアクセスした場合はサーバ群②に分散させるといった動作を実現することができます。
また、L7の情報であるHTTPヘッダやアクセス先のURLの文字列を参照して、上記のように分散させるサーバ群を変えることも可能です。HTTPヘッダのUser-Agent内にあるアクセス元ユーザのブラウザ情報を参照し、InternetExplorerならサーバ群①に、Firefoxならサーバ群②に、といった形で分散させることができます。さらに、URL内に特定の文字列があった場合にはサーバ群①、他の特定の文字列が有った場合には②、それ以外の場合にはサーバ群③に分散させるなど、ユーザの要件に応じた柔軟な方法を選択することが可能です。
まず導入時に必要となるのが、導入構成の検討です。AppDirectorでは、AppDirectorでセグメントを分けるL3構成だけでなく、セグメントを分けないL2構成で導入することもできます。
L2構成では、AppDirectorを冗長する際に、一般的な冗長構成であるBridge冗長構成の他に、AppDirectorを1本足で接続するワンレッグ冗長構成を選択することができます。ワンレッグ冗長構成では、L2のBridge冗長構成で問題となるループ経路が発生しないため、周辺のSwitchの設定もあまり気にする必要がなく、容易に導入することが可能です。
ワンレッグ冗長構成には、戻りパケットをAppDirector経由にさせることで「リバースプロキシ型」と「SourceIP透過型」の2つの方法が選択できます。
リバースプロキシ型構成は、AppDirectorでClientIPをNATすることにより、戻りのパケットがAppDirectorを経由するように設定します。サーバから見たときにはSourceIPがAppDirectorのNATIPになってしまうものの、HTTPヘッダの中にClientIPを埋め込むことで、ClientのIPアドレスをサーバで読むことも可能です。
SourceIP透過型構成は、ClientIPはNATせず、サーバのデフォルトゲートウェイをAppDirectorに向けることにより、戻りパケットもAppDirectorを経由させる方法です。サーバでClientIPをそのまま知ることができるため、サーバのデフォルトゲートウェイが変更可能であれば、簡単な変更で容易にL2の冗長構成を実現することができます。
ただし、既存のL2ロードバランサのリプレースにおいて、ネットワーク構成を変更できないためにどうしてもBridge冗長構成で導入しなければならない場合もあるかと思います。
一般的なBridge冗長構成では、冗長の切り戻り（Primary機が復旧してBackup機から戻る時）の際にループ経路が発生するので注意が必要です。しかし、AppDirectorはこのような場合もループ経路の発生を防ぎ、Bridge冗長構成でのL2構成を実現するノウハウを用意しています。
まず1つ目は、冗長の切り戻り時にループ経路が発生するのを防ぐため、Primary機の復旧による切り戻りは手動で行うように設定します。手動で切り戻るよう設定すれば、Primary機がダウンしてBackup機に切り替わる時と同じ状態になるため、ループ経路の発生を防ぐことができます。
次に、冗長が切り替わる際に、Downした方の機器に繋がるすべての物理ポートを一定時間LinkDown(電気的にダウン)させるように設定します。LinkDownすることによりAppDirectorに接続されたスイッチのMACテーブルを削除させ、新たな経路でMACテーブルを作成させることが可能になります。
最後に、サーバのデフォルトゲートウェイはAppDirectorの冗長用VIPに向けます。サーバのデフォルトゲートウェイがルータに向いたままでは、切り替わりの際にスイッチでルータのMACテーブルが即座に変更されず、切り替わり完了までに時間がかかる場合があります。ゲートウェイをAppDirectorに向けておけば、AppDirectorのVIPはスイッチに隣接しているため、上記のLinkDownによってすぐにMACテーブルが切り替わり、最小限の切断時間で切り替えることが可能です。
ロードバランサ製品は、分散対象とするサーバの状態を常にチェックし、サービス提供可能なサーバのみにアクセスを振り分けるヘルスチェックの機能を持っています。このヘルスチェック機能の判断方法も明暗が分かれる部分です。
AppDirectorは、このヘルスチェックにおいても多様な方法を用意しています。Pingによってサーバへの疎通を確認できるのは勿論、サーバで提供するアプリケーションが利用可能かどうかTCPポートでチェックしたり、WebサーバであればHTTPコンテンツが提供可能な状態かどうかをHTTPGetでチェックしたりすることもできます。
HTTPGetのチェックでは、分散対象のサーバ自体だけでなく、背後にあるDBサーバも併せてサービスが提供可能な状態にあるかどうかチェックできます。ヘルスチェックにはHTTP Getをサーバに送信し、指定したReturn Code（デフォルトは200OK）を受け取れるかによって監視する方法がありますが、この時に指定した文字列が取得できるかどうかをチェックOKの条件に加えることができます。サーバにデータベースから文字列を取得するようなスクリプトを用意しておき、そのスクリプトに対してHTTP Getを行うことで、間接的にDBサーバのヘルスチェックが可能です。
AppDirectorの冗長で用いるVRRPでは、Primary機の実インターフェースIPアドレスを冗長用IPアドレスとしてBackup機と共有させることにより、別途仮想IPアドレスを設けることなく冗長の実現が可能です。Primary機とBackup機の実IPアドレスのみで冗長を実現することから「2IP冗長」と呼ばれます。AppDirectorのインターフェースにグローバルIPアドレスを割り当てている場合など、必要なIPアドレスの節約に貢献することが可能です。
ただし、フェールオーバーによりBackup機に切り替わり、Primary機のIPアドレスを引き継いだ時に、そのIPアドレスに対するPingには応答しなくなります。これはVRRPの仕様により、厳密にはPrimary機のIPアドレスではなく、IPアドレスに対するMACアドレスを引き継いでいるためです。
そのため、上位のファイアウォール等からAppDirectorをPingにて監視したい、といった要件がある場合には、敢えてインターフェース冗長用IPアドレスとして実IPアドレスの他にPrimary機とBackup機で共用の仮想IPアドレスを設けることで、常時Pingに応答するIPアドレスを用意することができます。Primary機とBackup機それぞれの実IPアドレスに加え、共用の仮想IPアドレスを用いて冗長を実現することから「3IP冗長」と呼ばれます。
下位のサーバのデフォルトゲートウェイをAppDirectorに向ける場合も、この仮想IPアドレスに対して向ければ大丈夫です。Primary機やBackup機へのマネジメントアクセスは、それぞれ実IPアドレスで行うことができます。
実インターフェースIPアドレスでの2IP冗長と仮想IPアドレスによる3IP冗長は、要件に応じて選択可能です。ただし、前述したBridge冗長のケースなどフェールバック時に手動切り戻しにしたい場合は、3IP冗長が必須になる点を押さえておく必要があります。
導入先の要件によっては、サーバからメールが送信されるなど、サーバからアウトバウンドで外部インターネットに通信が必要な場合があります。L2構成であれば問題ない場合がほとんどですが、AppDirectorはL3構成で導入される場合が多く、サーバが存在するセグメントは外部と隔てられることになります。そのままではサーバからアウトバウンドで通信できませんが、AppDirectorにはアウトバウンド用のNAT機能もあり、使用することでアウトバウンド通信も実現することが可能になります。
原理はルータ等が備えるIPマスカレードと同じです。サーバの実IPアドレスをNAT元IPアドレスに設定し、外部にアクセス可能なNAT先IPアドレスを指定することで、アウトバウンド通信の際にSourceIPがNATされ、外部インターネットと通信可能になります。
アウトバウンド用NATは負荷分散対象のサーバ以外にも使うことができます。別にアウトバウンド通信させたいクライアントPCなどがあっても、AppDirectorでNATさせることが可能です。
さらに、AppDirectorでグローバルIPアドレスとローカルIPアドレスのセグメントを分けており、NATIP用のグローバルIPアドレスを用意するのが負担になるような場合には、外部からサーバにアクセスする際の仮想IPアドレスをアウトバウンド用のNATIPに使っていただくことで、IPアドレスの節約も可能です。ただしこの場合は、NAT可能なのはサーバ群に属する負荷分散対象のサーバのみになるため注意が必要です。
L7の情報を判断する携帯サイトの負荷分散
AppDirectorの高機能の特徴であるL7の機能を応用することにより、AppDirectorは携帯サイトの負荷分散にも対応することができます。
携帯サイトの負荷分散を実現する場合、docomoやauといった携帯キャリア毎にそれぞれ対応するコンテンツを用意する必要があります。そのため、アクセス元ユーザの携帯キャリアを判断して分散させるサーバ群を変えなければなりません。
また、携帯電話からのアクセスは、特徴の部分で前述した通り、同じ携帯電話からのアクセスであっても、アクセスの度にキャリア内で異なるIPアドレスでアクセスしてくることがあるため、接続維持もアプリケーションレイヤー（L7）の情報を参照して行わなければなりません。
※携帯電話においても、ショッピングサイトなどセッション維持が必要なサイトは今や当たり前となっており、ロードバランサでの接続維持は必須です。
ただ、アプリケーションの情報を細かく参照するためには、今まではiRuleといったLinuxベースでスクリプトを書く機能を用いなければ実現が不可能とまで言われていました。しかし、AppDirectorはこの携帯サイトの負荷分散であっても、難しいスクリプトを書くことなくWebGUIでの設定だけで行うことができます。
携帯サイトの負荷分散を実現する流れは下記の通りです。HTTPのヘッダを読んで条件分岐と接続維持を行うことにより、携帯サイトの負荷分散を実現します。
まずはどの携帯キャリアからのアクセスかを判別します。携帯電話からのアクセスは、HTTPヘッダの中にどのキャリアからのアクセスであるか情報が埋め込まれており、この内容を読むことで携帯キャリア毎にそれぞれ異なるコンテンツのサーバ群に振り分けることが可能です。
例えば、HTTPヘッダの中のUser-Agentに「DoCoMo」と記載されていれば、Docomoからのアクセスであると分かります。その場合は、Docomo用のコンテンツを提供するサーバに振り分けるように設定を入れればよいのです。これがauからのアクセスであれば「x-up-subno」、SoftBankであれば「x-jphone-uid」とHTTPヘッダに記載されています。
さらに、携帯からのアクセスをサーバに振り分けた後は、再度アクセスがあった時のために、同じサーバへの接続維持を行います。携帯サイトの場合は、アクセスする度にユーザ毎にランダムな値がHTTPヘッダのUser-Agentに埋め込まれて返ってくるため、この値をL7パーシステンスにより動的に学習、同じ携帯電話からのアクセスを同じサーバに振り分けることが可能です。
ショッピングサイトで買い物するなど、携帯電話でもPCと同様にサイトを活用することが当たり前になってきています。今後も携帯電話からインターネットを活用するニーズは増えるはずで、それに伴って携帯サイトにおける負荷分散の需要もますます高まると思われます。
｢Shutdown｣モードでノンストップなサービス
最後に、運用時にメリットがある「Shutdown」モードを紹介します。
サーバに障害が発生した場合には、ヘルスチェック機能によってそのサーバにアクセスが振られないようになりますが、サーバにアクセスを振らないようにする動作を手動で行うことも可能です。
手動でアクセスを振らないようにできるため、バージョンUPなどサービスメンテナンス時に複数のサーバを1台ずつ切り離してメンテナンスを行うことができます。ただ、普通にサーバを切り離すとその時点でサーバにアクセスしていたユーザのセッションが切れてしまうため、セッションの維持が必要なサイトでノンストップなサービスの提供を重視したいユーザには不向きです。
そこで役立つのが、AppDirectorが提供する「Shutdown」というモードです。Shutdownモードは、新規のアクセスは振らないようにしながら、既存のセッションについてはユーザからのアクセスがなくなるまで維持し続けるモードです。既存のセッションが全て切れた段階でサーバを切り離せば、ユーザ側のセッションを途中で切ってしまう心配もありません。
何台かに分けてShutdownモードを使うことにより、ユーザが完全にサービスの停止を意識することなく、システムの切り替えを行うことが可能となっています。
以上、ロードバランサの活用の幅を広げる、AppDirectorの特徴および構築術を紹介しました。他にもこんな要件に対応したい、このような場合はどうすればよいのかなどの疑問については、是非弊社営業を通してご相談下さい。
加藤 洋樹
マクニカネットワークス 技術統括部 Radware担当エンジニア。負荷分散装置を中心にRadware製品全般の提案・導入・コンサルティングを行っており、AppDirectorの提案・導入など様々な案件に対して幅広く携わっている。
- Radware AppDirector製品詳細
http://www.macnica.net/radware/appdirector.html - ［SIerの為の実践講座］バックナンバー
Mimosa NearPointのExchange 2003 → 2007マイグレーションへの活用術
http://www.macnica.net/lanch/lanch09au/si01.html/
BlueCoat ProxySGシリーズ構築における注意したい7つの落とし穴
http://www.macnica.net/lanch/lanch09sm/si01.html