Comments
Description
Transcript
1 ロードバランサから ADCへ
第 2 特集 ネットワークエンジニア養成 ロードバランサの教科書 CHAPTER 1 基本機能と最新機能を整理 ロードバランサから ADC へ 文：鶴長 鎮一 （つるなが しんいち） [email protected] 協力：F5ネットワークスジャパン㈱ ギド フォスメア Web サーバの普及でロードバランサの需要が高まっています。ロードバランサを導入する ことで、サーバの負荷分散やシステムの冗長化が可能です。本稿では、F5 ネットワークス ジャパン社の協力のもとに、前半でロードバランサの基本動作について解説し、後半で最 近の動向を解説します。 ロードバランサの機能 負荷分散のためのロードバランサ 複数のサーバに分散させるのに、特別なしくみ が必要になります。それを可能にしているのが 「ロードバランサ （負荷分散装置） 」 です。 ロードバランサにはサーバにインストールし て 利 用 す る も の か ら、米 F5 Networks 社 の サーバにかかる負荷を減らし、大量のリクエ 「BIG-IP シリーズ （写真 1） 」 に代表されるネット ストを捌くには、サーバの CPU やメモリを増強 ワークアプライアンスまでさまざまなものがあ するか、サーバの台数を増やす必要があります。 ります。専用のネットワークアプライアンスは、 サーバを増強する方法は 「スケールアップ （垂直 サーバとインターネットの間に設置でき、サー スケール） 」 と呼ばれ、よりハイスペックなサー バの構成を大きく変えたり、特殊なチューニン バに置き換えることで処理能力を向上しますが、 グを施したりする必要がないため導入が簡単で ハイスペックなサーバは費用が高く、値段と性 す （図 1） 。 能が比例しません。そのため、2 倍の費用をか ることができません。またサーバが停止すれば ロードバランサ以外の負荷分散方法と 課題 システム全体がダウンする危険性があり、アベ ロードバランサを使用せずに、負荷を分散さ イラビリティの面で不安が残ります。サーバの せる方法もあります。たとえばクライアント側 台数を増やす方法は 「スケールアウト （水平ス で、www1、www2 のようにホスト名を変えれ ケール） 」 と呼ばれ、アクセス数の増加に応じて ば、リクエストを複数のサーバに分散できます。 サーバの台数を増やすことで大量のリクエスト ただし、どのサーバにアクセスするかは、クラ に対応します。サーバ台数を 2 倍に増やせば、性 イアントしだいとなるため、アクセス数やトラ 能も比例して向上するため費用対効果が高く、 フィック量に応じてサーバを割り振ることはで ければ、性能も 2 倍になるといった予測をたて スケーラビリティに優れています。また複数の サーバで処理を行うため、そのうちの 1 台が停 止してもほかのサーバで処理を継続できるなど、 アベイラビリティも優れています。スケーラビ リティやアベイラビリティで有利なスケールア ウトですが、クライアントからのリクエストを 1 - Software Design ▼写真 1 F5 Networks 社の BIG-IP シリーズ 基本機能と最新機能を整理 ロードバランサからADC へ きません。また指定したサーバに障害が発生し シュによりタイムラグが生じてしまうため、即 ても、ほかのサーバに処理を引き継ぐこともで 座に構成変更を反映できません。 きません。何よりクライアント側でホスト名を 「DNS ラウンドロビン」 と呼ばれる方法なら、 ラウンドロビン／コンテンツスイッチ ング／動的振り分け クライアントでホスト名を変えなくても、アク DNS ラウンドロビンを使った負荷分散は、費 セスするサーバをその都度変えられます。通常 用をかけずに利用できるものの、耐障害性や分 変えるのは利便性が良くありません。 DNS サーバのゾーンレコードには、1 つのホス 散方式に問題があり、24 時間 365 日連続稼働を ト名に対し 1 つの IP アドレスを記述しますが、 要求されるシステムには不向きです。よりミッ 1 つのホスト名に対し複数の IP アドレスを記述 ションクリティカルなシステムには、さまざま することで、DNS 問い合わせのたびに違うアド な分散方式を備えたロードバランサを使用しま レスを返すようにでき、結果的にアクセスする す。分散方式には主なものだけでも表 1 のよう サーバを分散させられます。ただし DNS ラウン なものがあります。順番にサーバを割り振る 「ラ ドロビンでは、処理能力が高いサーバへのアク ウンドロビン方式」 には、単純に設定された順に セスは高頻度に、処理能力が低いサーバは低頻 割り振り同じ割合でサーバを使用する方式のほ 度にといった、サーバの処理能力に合わせてア かに、優先順位に従って割り振る 「優先順位方 クセス頻度を変えることはできません 。また 式」 や、あらかじめ決められた割合で割り振るこ 注1 障害が発生したサーバへの アクセスを防止することも 1 ▼表 1 負荷分散の方式 方式名 負荷分散の方法 できません。さらに DNS の ラウンドロビン方式 バックエンドサーバを順番に使用 変 更 を 行 っ て も、キ ャッ 優先順位方式 設定した優先順位に従う 重み付け方式 設定した割合に従う 注 1） SRV レコードを用いれば DNS だけで冗長化と負荷分散を実 現できますが、SRV レコード に対応したクライアントは多 くありません。 CHAPTER コンテンツスイッチング HTTP ヘッダや URL、ペイロードによってバックエ ンドサーバを決定 最速応答時間方式 応答が最も早いバックエンドサーバを優先 最少コネクション方式 接続しているコネクション数が最少のサーバを優先 最少トラフィック方式 トラフィック量が最も少ないサーバを優先 ▼図 1 ロードバランサの役割 インターネット 仮想サーバ 負荷分散 ヘルスチェック ロードバランサ （負荷分散装置） セッション維持 仮想サーバに対し リクエストを実行 アドレス変換 バックエンドサーバ 1 バックエンドサーバ 2 バックエンドサーバ 3 バックエンドサーバ 4 Apr. 2014 - 2 第 2 特集 ネットワークエンジニア養成 ロードバランサの教科書 とができる 「重み付け方式」 があります。 え、HTTP ヘッダや URL といったアプリケー 優先順位方式では、各サーバに 「優先順位 ションレベル （L7 注 3） で割り振るサーバを変更で （Priority） 」 を設定し、優先順位の高いサーバか きる 「コンテンツスイッチング方式」 もあります。 らリクエストを割り振り、それが一定以上超え URL に 「img」 が含まれていたらサーバ 1 に、拡 た場合に、次に優先順位が高いサーバに割り振 張子が 「.php」 だったらサーバ 2 へといった割り ります。優先順位が低いサーバを普段はほかの 振りが可能です。画像や HTML といった静的コ 用途に使用しピーク時にだけ利用したり、優先 ンテンツと、PHP や Java といった動的なコン 度が最も低いサーバに 「アクセス集中のため表示 テンツを分けることができます。またキャッシ できません」 といったコンテンツを用意してお ング機能と組み合わせれば、さらにレスポンス き、アクセスが混雑していることをユーザに告 を高めることも可能です。 知したりできます。 ラウンドロビンやコンテンツスイッチングは、 重み付け方式では、割り当てるサーバの頻度 あらかじめ設定したとおりに動作する 「静的」 な を 「重み （Ratio） 」 で変えることができます。分散 ものですが、状況に応じて 「動的」 に動作する方 させるサーバの性能に差がある場合、低スペッ 式もあります （図 2） 。応答速度、トラフィック クなサーバへの割り振りを減らし、高スペック 量、コネクション数、CPU 負荷といったデータ なサーバへの割り振りを増やすといったことが を、この後解説する 「ヘルスチェック」 でモニタ 可能になります。たとえば高スペックなサーバ リングし、割り振るサーバをロードバランサが に対する重みを 「3」 に、低スペックなサーバに その都度決定します。 「最速応答時間方式」 では 対する重みを 「1」 に設定することで、3：1 の割 応答が最も早いバックエンドサーバを優先し、 「最少コネクション方式」 や 「最少トラフィック方 合で高スペックなサーバへの割り振りを増やせ 式」 では、接続中のコネクション数やトラフィッ ます。 （L4 こうした TCP レベル ） の負荷分散に加 ク量が最も少ないサーバを優先し割り振ります。 注2 注 2） OSI 参照モデルのトランスポート層（第 4 層）。 注 3） OSI 参照モデルのアプリケーション層 （第 7 層） 。 ▼図 2 動的な負荷分散方式 インターネット 応答速度／トラフィック量／コネクショ ン数／ CPU 負荷で、サーバを決定 ロードバランサ （負荷分散装置） サーバが停止した場合， 分散対象から切り離す 障害発生 サーバ 1 40 コネクション数 3 - Software Design 52 トラフィック量 サーバ 2 サーバ 3 サーバ 4 32 60 43 45 72 28 ……… 基本機能と最新機能を整理 ロードバランサからADC へ 動的な負荷分散では、各サーバのモニターデー で正常性を確認します。レスポンスコードや応 タをロードバランサ内部に保持する必要がある 答速度を調べることもできるため、サーバの状 ため、ロードバランサの負担が大きくなります。 態をより明確に検知できます。また Web システ 高レスポンスを実現するには、より高性能なロー ムのように、DB サーバやアプリケーションサー ドバランサが必要になります。 バといった複数のサーバが連携するシステムで ロードバランサによっては複数の方式を組み は、各システムの状態をヘルスチェックページ 合わせることもできます。たとえば最速応答時 に動的に埋め込むことで、システム全体として 間方式と最少コネクション方式を組み合わせ、 の正常性まで確認できます。 サーバの負荷状況をより反映させたり、ラウン PING チェックや TCP チェックは、サーバ側 ドロビン方式と優先順位方式を組み合わせ、あ に特別な準備はいりませんが、アプリケーショ る一定量まではプールされたサーバをラウンド ンチェックでは、サーバ側の作りこみが必要に ロビンで分散し、閾値を越えたときだけ、オフ なります。またアプリケーションのログに、ヘ ロード用のサーバを使用したりします。 ルスチェックのログが出力されてしまい、ポー ヘルスチェック になります。 ヘルスチェックでサーバ停止を判定する際、 対象から切り離すのに 「ヘルスチェック」 が使わ ダウン検出回数を適切に設定しないと、検知時 れます。ヘルスチェックには PING チェック 間が長くなり、障害中のサーバにリクエストを 、TCP チェック （L4 チェック） 、 （L3 注 4 チェック） 割り振ってしまう危険性が大きくなります。サー アプリケーションチェック （L7 チェック） が用い バ停止の検出時間は 「ヘルスチェックのポーリン られます。 グ間隔×検出回数」 で決まります。ポーリング間 PING チェックでは、サーバに PING パケッ 隔を長くするとサーバ停止を検出する時間が長 トを送信し応答の有無で死活を判断します。 くなり、ポーリング間隔が短いとサーバ負荷が TCP チェックではサーバのサービスポート 高くなりレスポンスが遅くなったときに、停止 と誤認してしまいます。 認を行います。PING チェックではネットワー TCP ポートを使ったサービスのヘルスチェッ クの到達性しか監視できませんが、TCP チェッ クは容易ですが、UDP ポートを使ったサービス クならサービスの接続性まで監視できます。そ だと信頼性を保証できないため、設定が難しく れでもアプリケーションが正常に動作している なります。 かまでは監視できません。たとえば Web サーバ 1 リング間隔が短いと大量のログが発生すること ロードバランサがサーバ障害を検知し、分散 （Web サービスなら TCP 80 番） に対して接続確 CHAPTER としてサービスは起動していても、コンテンツ セッション維持 を正しく配信しているかは PING や TCP では確 HTTP のようにコネクションレスなプロトコ 認できません。アプリケーションレベルまで監 ルだと、アクセスするたびに新たなセッション 視するには、アプリケーションチェックが必要 として扱われます。たとえばログインページで になります。一般的に利用されるのが、ヘルス ユーザ認証に成功したとしても、クライアント チェック用のダミーコンテンツを使った方法で が次の画面に遷移すれば、違うセッションとし す。各サーバにデータ量の小さい監視専用のコ て扱われ、認証に成功した情報を引き継ぐこと ンテンツを用意し、ロードバランサが一定間隔 ができません。そのため Web システムではセッ ション情報をサーバに保持し、同一クライアン 注 4） OSI 参照モデルのネットワーク層（第 3 層）。 トからのリクエストならセッション情報を引き Apr. 2014 - 4 第 2 特集 ネットワークエンジニア養成 ロードバランサの教科書 継ぐようにしています。ロードバランサでリク ス IP アドレスと割り振ったサーバとのマッピン エストを振り分ける際、最初に振り分けたサー グ情報を管理するだけで済むため、負担が軽く バと別のサーバに振り分けてしまうと、最初に なります。Cookie パーシステンス方式はクライ 作成されたセッション情報が利用できません。 アントの識別がより正確に行えますが、ロード Web サーバ側でセッション情報をほかのサーバ バランサ側で Cookie 情報にサーバ ID を埋め込 もありますが、そうした手法 むため、より負担が重くなります。またアプリ は複雑です。こうした問題をロードバランサ側 ケーションデータが暗号化された HTTPS の場 と共有する方法 注5 で解決するには、同一クライアントからのリク 合、Cookie パーシステンス方式は利用できませ エストを継続して同じサーバに振り分けるよう ん。HTTPS のセッション維持には、ソース IP にします。それが 「セッション維持 （セッション・ アドレスか SSL Session-ID を利用します。た パーシステンス） 」 です （図 3） 。 だ し、BIG-IP の よ う に ロ ー ド バ ラ ン サ で リクエストが同一クライアントのものかどう HTTPS を終端させられる場合は、データの中 か判断するのに、クライアントのソース IP アド 身を見られますので Cookie パーシステンスも利 レスを使う 「ソースアドレス・アフィニティ・ 用できます。 パーシステンス方式」 と、HTTP ヘッダの Cookie 最新ロードバランサの 動向 情報に識別用 ID を埋め込む 「Cookie パーシステ ンス方式」 があります。クライアントがプロキシ サーバを使っていたり NAT 環境下にあると、 ソース IP が変更になる可能性があるため、クラ ADC への進化 イアントをソース IP アドレスで識別するのが困 EC サイトやオンラインバンキングといった 難になります。ただしロードバランサは、ソー より高い信頼性が求められる Web サービスの普 及とともに、ロードバランサが広く使われるよ 注 5） Apache Tomcat のようなアプリケーションサーバでは、メ モリ、ディスク、RDBMS にセッション情報を保存するセッ ションレプリケーションが提供されている。 うになりましたが、最近ではソーシャルゲーム やモバイルアプリといったリッチコンテンツが ▼図 3 セッション・パーシステンス セッション・パーシステンスなし サーバ 毎回違うサーバに 割り振られる 1 ロードバランサ インターネット サーバ 2 サーバ 3 セッション・パーシステンスあり サーバ クライアントに応じて 同じサーバに割り振る ロードバランサ 1 2 3 サーバ インターネット サーバ 5 - Software Design 基本機能と最新機能を整理 ロードバランサからADC へ 急拡大し、ロードバランサにより多くの機能が ストールできる仮想アプライアンスの 「Virtual 求められるようになっています。またユーザエ Edition （VE） 」 といったものなど、多種多様な製 クスペリエンスの重要性が叫ばれるようになり、 品がラインナップされています。これらの製品 快適にコンテンツを配信することも一段と重要 は、扱えるコネクション数やトラフィック量と になっています。単純なトラフィックの分散に いったパフォーマンスやキャパシティが異なる 加え、ネットワークやアプリケーションの最適 のみで、機能面では共通化が図られています。 化、コンテンツの圧縮、DDoS や DoS といった そ れ を 実 現 し て い る の が 基 盤 OS の 「TMOS 攻撃に対する防御、アプリケーションレベルで （Traffic Management Operating System） 」 です。 のファイアウォール、SSL オフロード、地理的 F5 の全 BIG-IP プラットフォームには TMOS が に離れたデータセンタ間の広域負荷分散といっ インストールされており、各機能は TMOS 上で たものが求められています。こうした要望に応 動作するモジュールとして提供されています。 えられるようアプリケーションレイヤ （L7） での たとえば負荷分散は 「LTM （Local Traffic 機能を中心に拡充したのが 「ADC （Application Manager） 」 モジュール、Web アプリケーション Delivery Controller） 」 です。最新ロードバラン ファイアウォール （WAF） は 「ASM （Application サ／ADC の動向を BIG-IP を例に解説します。 BIG-IP 1 Security Manager） 」 モジュールといったものが 用意されています。これらのモジュールは、専 用のアクセラレーションハードウェアとともに ミッションクリティカルなサービスを支え、 インストールされた状態で出荷され、実際にモ ロードバランサの進化を牽引してきたのが F5 ジュールを使用する段階で、ライセンス情報を プラット Networks 社 （以 降、F5） の 「BIG-IP」 注6 。たとえば 投入し制限を解除します （図 4） フォームです。ロードバランサ市場で大きなシェ 「BIG-IP LTM」 として購入したものに、 「ASM」 アを誇り、ADC の分野でもほかを大きくリード のライセンスを購入することで WAF 機能が利 しています。通信キャリアで使用されるハイエ 用できるようになります。 ンドなシャーシ・ブレードタイプの 「VIPRION BIG-IP プラットフォームに明確に ADC をう 4800 （写真 2） 」 から、日本市場に特化したローエ たったモデルはありません。それはモジュール ンドモテルの 「BIG-IP 800」 まで、さらに Xen や を組み合わせることで ADC 相当として機能する VMware ESXi のようなハイパーバイザにイン ためです。F5 では、Fast （早い） ／Secure （安全 ▼写真 2 F5 Networks 社の VIPRION 4800 CHAPTER な） ／Availability （可 用 性） を実現したものが ADC と位置づけています。 高速配信 年々肥大化するコンテンツをより高速に遅延 なく配信し、ユーザエクスペリエンスを高める ことがロードバランサの重要な課題となってい ます。リクエストの結果が返ってくるまでにか かる遅延時間を減らすよう、サーバ側で行う処 理をロードバランサ側で高速に処理したり、ネッ トワークを最適化しトラフィックを効率化した 注 6） BIG-IP 800 はモジュール追加に非対応。 Apr. 2014 - 6 第 2 特集 ネットワークエンジニア養成 ロードバランサの教科書 りとさまざまな手法がとられています。 が多様化し、最適な値もそれぞれの状況に応じ SSL オフロードは従来から使われてきた高速 て変わってきます。BIG-IP には端末やネット 化手法です。コンテンツの暗号化やキーの作成 ワーク環境ごとに最適化されたプロファイルが といった HTTPS で行われる処理を、サーバに 用意されており、チューニングやコンフィギュ 代わってロードバランサが行います。サーバと レーションにかかる手間を削減し設定を瞬時に ロードバランサとは通常の HTTP で通信するた 行えるようにしています。また無駄なトラフィッ め、サーバの負担を減らすことができます。ま クを削減するよう、キャッシュ機能を搭載し、 た SSL サーバ証明書のインストールはロードバ 同一のリクエストに対しサーバに代わってロー ランサ側だけで済みます注 7。最近は鍵長が 2048 ドバランサが代理応答できるようにしています。 ビットに拡張した SSL が一般的になっており、 アプリケーションレベルの効率化では、HTTP より SSL 処理が重くなっています。BIG-IP の 圧縮機能でコンテンツを圧縮転送したり、プロ ように SSL オフロード専用のハードウェアを搭 トコルの優先度で帯域を確保したりできるよう 載した製品なら、ほかの処理に影響を及ぼすこ にしています。BIG-IP では、圧縮効果の高い となく高速処理が可能です。IPv6 対応でも、サー ファイルのみを圧縮したり、遅延の大きい回線 バ側は IPv4 のままにし、ロードバランサ側で に対するレスポンスのみを動的に圧縮したりと IPv6 に対応することでクライアントと IPv6 通 よりインテリジェンスに機能するようになって 信ができるようになります。 います。また圧縮をハードウェアで処理させ、 トラフィックの効率化はネットワークレベル レスポンス遅延を最小限にしています。 とアプリケーションレベルの両面で行われてい ます。ネットワークレベルでは、TCP に関わる セキュリティ機能 パラメータを調整し遅延処理やコネクション制 サーバやアプリケーションの数が多くなると、 御を最適化します。最近は端末やネットワーク セキュリティ管理にかかるコストが大きくなり 注 7） SSL サーバ証明書は全サーバにインストールする必要はあ りませんが、台数分購入する必要があります。証明書発行 機関によっては、割安なメニューが用意されている場合も あります。 ます。ロードバランサはゲートウェイに設置さ れるため、セキュリティ管理を一括して行うこ とができ、人員や時間を削減できます。DoS/ ▼図 4 Web UI でライセンスを投入しモジュールを使用可能に 7 - Software Design 基本機能と最新機能を整理 ロードバランサからADC へ DDoS の よ う な L3 や L4 レ ベ ル の 攻 撃 か ら、 する関心が高まっています。データセンタレベ SQL インジェクションのような L7 レベルの攻 ルでアクセスを分散する 「広域負荷分散」 機能で 撃までマルチレイヤで対応するため、ネットワー そうした要望に応えることができます。BIG-IP ク FW、IDS/IDF、WAF を別々に設置する必 は DNS を使った方法で広域負荷分散を実現して 要がありません （図 5） 。攻撃防御には、正しい います。クライアントはリクエストを送信する と定義されたトラフィックのみアクセスを許可 前に送信先 IP アドレスを DNS サーバに問い合 する 「ポジティブ・セキュリティ」 と、脅威を検 わせます。その際、正常に動作しているデータ 知するためのデータベース （シグネチャ） を使っ センタの IP アドレスを返すことで、障害でダウ た 「ネガティブ・セキュリティ」 を同時に設定で ンしたデータセンタへのアクセスを防ぎます （図 き、既知や未知の攻撃を防御します。BIG-IP は 6） 。また BIG-IP は 「ジオロケーション」 機能で 手間のかかる DDoS 攻撃元の特定や設定の自動 クライアントから一番近いデータセンタを割り 化が可能です。また DoS/DDoS をハードウェア 出し、遅延と修正を最小限にします。 で処理するためパフォーマンスが劣化しません。 DNS を利用するため、DNS データのキャッ WAF 機能では、ポジティブ／ネガティブ・ シュ時間 （TTL） を極端に短く設定する必要があ セキュリティに加え、SQL インジェクション攻 ります。そのため DNS サーバへのアクセスが多 撃のような高度な処理、情報マスキングによる 発し、DNS サーバにかかる負荷が大きくなりま 情報漏洩対策が可能です。Web アプリケーショ す。サービス品質を低下しないよう BIG-IP プ ンをセキュアにプログラミングしたり、最新パッ ラットフォームが DNS サーバとなり、DNS の チを全サーバに適用したりするには、コストや パフォーマンスを強化します。また同時に DNS 時間がかかりますが、ロードバランサで対策す に対する攻撃も防ぎます。 ることでリスクを低減できます。BIG-IP はセ 専用エンジンとハードウェアで、ほかの通信に 仮想アプライアンスとハードウェアア プライアンス 影響することなく高速に処理します。また IP ア ネットワークもサーバも仮想化が主流となり、 ドレスをもとに位置を特定する 「ジオロケーショ BIG-IP からも Xen や VMware ESXi といった ン」 を搭載しているため、特定地域や国単位でア ハイパーバイザ上で動作する仮想アプライアン クセスを拒否することが可能です。 ス製品の 「Virtual Edition （VE） 」 がリリースされ キュリティ基準の PCI DSS 要件 6.6 に対応し、 CHAPTER 1 ています。ただし、すべての処理をソフトウェ 拠点間冗長 アで行うため、ハードウェアアプライアンスに 震災以降、ディザスタリカバリーや BCP に対 は及びません。データセンタのゲートウェイに ▼図 5 BIG-IP のセキュリティ機能 アクセス アクセス DDos 攻撃 AFM LTM ASM アクセス AFM：Advanced Firewall Manager LTM：Local Traffic Manager ASM：Application Security Manager BIG-IP プラットフォーム アクセス アクセス アクセス アクセス ゼロデイ 攻撃 ファイアウォール アクセス アクセス アクセス DDos 対策 アプライアンス ロードバランサ WAF Web サーバ Apr. 2014 - 8 第 2 特集 ネットワークエンジニア養成 ロードバランサの教科書 ハードウェアアプライアンスのロードバランサ が注目されているように、他ベンダとのシステ を、IaaS 基盤には仮想アプライアンスを配置し、 ム 連 携 が 重 要 に な っ て い ま す。BIG-IP は 全体のコストとパフォーマンスを適正にします。 OpenFlow プロトコルには対応していませんが、 多数のロードバランサが同時に配置されると、 VXLAN や NVGRE といった新世代のネット 管理問題が発生しますが、BIG-IP は後述する ワーク仮想化プロトコルに対応し、旧来のネッ システム連携機能で、設定や運用管理にかかる トワーク仮想化プロトコルである VLAN との 手間を抑えることができます。 ゲートウェイとして利用できます。また、内部 他システムとの連携 と同じように 「コントロールプレーン （制御） 」 と で SDN （Software Defined Network） のモデル 大量の機器が導入されると、設定や運用にか 「データプレーン （トラフィック転送を処理） 」 に かるコストが問題になります。また最近は特定 分かれています。コントロールプレーンは SOAP ベンダに依存する 「ベンダロックイン」 を避ける や REST ベースのインターフェースが公開され 傾向にあります。こうした問題を解決するには、 ているため、BIG-IP を操作するアプリケーショ 他ベンダとのシステム連携機能を解放し、プロ ンをプログラミングし、外部から BIG-IP を設 グラムで設定を変更できるようにします。どの 定できます （図 7） 。クラウドシステムと連携し ベンダとも相互に接続できる 「SDN/OpenFlow」 たオンデマンドなインフラ構築が可能です。｢ ▼図 6 BIG-IP の拠点間冗長 DNS サーバ サーバ LTM ・サーバロードバランス ヘルスチェック GTM ・DNS ロードバランス ・データセンタ間 ロードバランス ※GTM との混在や 冗長構成可 インターネット ※冗長構成も可 ①DNS クエリ ②DNS レスポンス Local DNS データセンタ A ヘルスチェック サーバ LTM ③HTTP ・サーバロードバランス ※GTM との混在や 冗長構成可 GTM : Global Traffic manager LTM : Local Traffic manager データセンタ B ヘルスチェック（データセンタ間） ヘルスチェック（サーバ） ユーザ ▼図 7 外部システムとの連携が可能 コントロールプレーン（iControl） SOAP/REST データプレーン（TMOS） BIG-IP プラットフォーム 外部システム （クラウド基盤など） TMOS：Traffic Management Operating System 技術評論社刊 月刊『Software Design』2014 年 4 月号より抜粋 9 - Software Design