Loading
|
|
|
|
Loading
|
| ＠IT > F5 Tech Tour 2005 |
 |
|
|
|
新野氏は最近の企業内ネットワークのトレンドを解説しつつ、
といった問題が今後発生することが予想されると指摘する。 このような環境下では社内のネットワークのトラフィックをより高いレイヤでマネジメントできるような製品が必要とされるほか、Webサーバの負荷を抑えるためにロードバランサ機能はもちろんのこと、SSLアクセラレータ・HTTP圧縮機能などがより重要性を増してくると語った。 一方で予算が限られている環境下では現在よりもネットワーク管理者を増やすことができない企業がほとんどであるうえ、個人情報保護法（個人情報の保護に関する法律）に対応した情報漏えい対策なども緊急の課題であることから、これまで以上にネットワークの統合管理による省力化や、社内に存在するさまざまな認証システムの統合によるセキュリティの強化も重要な課題であると新野氏は述べ、今後は前述したようなより高度なトラフィックマネジメント機能とこれら管理性・セキュリティの向上を両立した製品こそが求められると語り講演を締めくくった。
まず最も大きな変更点はOSカーネルを含む内部アーキテクチャの変更だろう。従来のBIG-IP v4.x系がBSDIカーネルの内部に直接トラフィック管理のコードを埋め込んだ形で提供されていたのに対し、v9ではベースとなるOSがLinuxに変更された上、一般的なLinuxカーネル上で同社が「TM/OS」と呼んでいるトラフィック管理デーモン（TMMデーモン）が動作するという形に変更された。 またそれに伴い、v9で一新されたTMMデーモンは「フルプロクシアーキテクチャ」を取る。これにより従来製品では基本的にサーバからクライアントに対して送られるコンテンツの中身についてはCookieの挿入などごく限られた操作を除いてほとんどタッチすることができなかったのに対し、v9ではサーバから送り出されるトラフィックの中身についても大きく変換・制御を行うことが可能になった。そのほか従来製品が基本的にTCPにしか対応していなかったのに対し、v9ではUDPパケットも正式にサポートすることになった点も見逃せない。 では具体的にどのようなトラフィック変換が可能になるのかを紹介していきたい。まずサーバの負荷低減に効きそうなのが、サーバとBIG-IPの間のhttpコネクションをkeep-aliveしておき、クライアントからBIG-IPにhttpリクエストが届いた場合にはそのkeep-aliveしたコネクションを利用して接続を行う「OneConnect」だ。 OneConnect自体は従来のv4.x系にも搭載されていた機能であり、これだけでもhttpセッションのopen／closeという負荷のかかる処理を大きく減らせるのだが、v9ではこれに加えHTTP/1.1で追加されたHTTPリクエストのパイプライン化に対応。このため複数のクライアントから届いたHTTPリクエストを1つのパケットにまとめてサーバに送ることができるほか、HTTP/1.0にしか対応していないクライアントに対してはサーバからパイプライン化されて送られたレスポンスをBIG-IPでHTTP/1.0ベースの単独レスポンスに分離して送るといったことが可能になり、かなりサーバ負荷の低減に効果がある。 またサーバからのレスポンスを変換するという点でもう1つ紹介したいのが、gzipによるHTTPコンテンツボディの圧縮をサポートする点。gzipによるコンテンツ圧縮は過去にも2ちゃんねるなど多くのサイトでデータ転送量の低減に効果を発揮しているが、一方でWebサーバ側でのgzip圧縮はサーバのCPU負荷の増大を招くという問題点があった。これに対しv9ではサーバから送られた非圧縮トラフィックをBIG-IP内部でgzip圧縮してクライアントに送ることができるようになり、サーバ負荷を上げずに転送量を低減することが可能になった。また圧縮の対象とするファイルタイプなども個別に設定できるので、あまり圧縮の効果がない種類のファイルについては対象から外すといった細かいチューニングもできる。 ここまではVirtual IPの設定メニュー（GUI画面）から利用できる機能だが、より細かいコンテンツ変換を行いたい場合には「iRule」と呼ばれるスクリプトを利用することも可能だ。v9では従来のiRuleから文法を一新し、TCLベースのスクリプトの形に文法が変更されたことで、BIG-IPが独自に実装する関数とTCLの標準関数の大部分（セキュリティ的に危険と考えられる関数が一部除かれているとのこと）が利用可能になったほか、TCLの制御構文や変数が利用できるなど、かなりスクリプト言語としての自由度が増している（そのためv4.x系のiRuleとは互換性が失われているので注意）。具体的にどのような作業が可能になるかについては図を参照して欲しいが、基本的にはHTTPヘッダ・コンテンツ共にほとんど好きなように内容を書き換えられるといって過言ではない。
これ以外にも、クライアントがアクセスしてくるVirtual IPアドレスや前述したiRuleの設定内容に応じてレスポンスのための帯域幅を自由に設定できる「Rate Class」機能や、日本市場では重要と思われるIPv6対応なども重要な新機能だ。 特にIPv6対応についてはBIG-IPがIPv6／IPv4ゲートウェイとして動作することも可能なため、BIG-IPを入れることでIPv6未対応のWebサーバを簡単にIPv6対応にすることもできる。草薙氏は「おそらくIPv4／v6に両対応するロードバランサは、現在市場に出ているものとしてはBIG-IPのみではないか」とコメントする。
管理面もより簡単に、そしてより柔軟な運用ができる機能が追加された。従来はVirtual IP単位でそれぞれ個別に設定を記述しなければならなかったのが、あらかじめ記述しておいた設定内容を「プロファイル」として登録しておき、同じ設定を複数のVirtual IPに適用したい場合はそのプロファイルを選択するだけで設定が完了するようになった。 また、細かい設定変更の場合も既存のプロファイルを親プロファイルとしてそこから子プロファイルを作成できるなど「オブジェクト指向の設定が可能になった」という。それ以外にもGUI画面でVirtual IPごとに管理用の名前を付けられるようになったほか、Virtual IPの検索機能なども追加されており、管理性の向上にも力が注がれている、と草薙氏は語った。
大島氏がBIG-IPを使うことになったきっかけは、2000年に@TOWER.JPのシステム更新を検討することになった際に、当時はまだタワーレコードの日本法人が米国の子会社だった関係で（現在は独立）、米国本社に行ってプレゼンを行った時のことだという。既に米タワーレコードではショッピングサイトなどでBIG-IPを採用してサイト運営を行っていたことから、向こうの技術者にBIG-IPの採用を薦められた。そして日本に戻ってから具体的な検討を行った結果、採用に至ったという。 その際の採用理由として大島氏は
といった点を挙げた。 そして2001年7月に現在のサイトがオープンして以降、サービスを停止したのは2002年末にDBサーバの負荷が増大しDBサーバの入れ替えを行った際のみで、Webサーバの入れ替えなどがあった際もサービスは一切停止していない。またこれまでBIG-IPに起因する障害は一度も発生していないという。 さらにNMNLではbounce.com（タワーレコードのフリーペーパー「bounce」のネット版）のニュースをYahoo! JAPANに提供している。「Yahoo! JAPANが音楽ニュースのソース元としてbounce.comのニュースをトップに掲載するとアクセスが急増することがあるが、そういった際の対策としても（BIG-IPは）効果があった」と大島氏は述べ、BIG-IPの効果が非常に大きい様子を語った。 現在のシステムもオープンから３年半以上が経過したため、同社では今年新たなサービス展開に向けたシステムの更新を検討しているそうだが、それについても「DBをクラスタ化する以外は今と同じような構成を考えており、BIG-IPも新製品を引き続き採用したい」と大島氏は語り、BIG-IPへの信頼の高さをうかがわせた。
同氏は「まともにサーバやロードバランサなどを増設したのでは5000万円以上の費用がかかるうえに管理オーバヘッドが大きく増大するような事例が、395万円のBIG-IPを導入するだけで解決できる場合もある」として、BIG-IPの優位性を訴えていた。
提供：F5 ネットワークスジャパン株式会社 企画：アイティメディア 営業局 制作：アイティメディア 編集第2局 掲載内容有効期限：2005年3月25日 |
|
アプリケーショントラフィック管理でおなじみのF5ネットワークスジャパンが、同社の主力商品である「BIG-IP」シリーズやSSL-VPN製品「FirePass」などに関する最新動向を解説する技術者向けセミナー「F5 Tech Tour 2005」が、2月8日／9日に東京・品川プリンスホテルにて開催された。初日の8日は、2004年9月に発表されたBIG-IPシリーズの最新バージョン「BIG-IP v9」に関する技術解説が行われたほか、BIG-IPの実際の導入事例としてタワーレコードのオンラインショッピングサイト「@TOWER.JP」の例などが紹介された。
