クラウド・アプリケーション配信システムを最適化する

トラフィック管理技術によって仮想インフラストラクチャーを最大限活用する

クラウドの構造に求められることは、クラウドを構成するすべてのコンポーネントが有効なリソースを効果的に使用できるように最適化することです。それは、アプリケーション配信システムなどのコンポーネントにしても例外ではありません。そこでこの記事の著者が紹介するのが、クラウド・アプリケーションの配信にプラスに影響するように設計された「トラフィック管理」モデルを構成する概念です。この記事を読んで、アプリケーション配信コントローラー (ADC: Application Delivery Controller) について理解し、サービスのレジリエンシー (障害から回復する能力) とユーザーに対する応答性を高める機能を使用する方法、Web インフラストラクチャー内でのスケーラビリティーの問題を ADC によって克服する方法、そしてさまざまなロード・バランシング手法の違いを学んでください。そして、実際にこれらの概念を適用する例を通して、真のアプリケーション・アクセラレーションが実際に機能する仕組みを理解してください。

Alex Gosse, Solutions Architect, Zeus Technology

Alex Gosse は、Zeus Technology のソリューション・アーキテクトです。Zeus Technology の主力製品である Zeus Traffic Manager は、組織が可用性に優れたインターネット・サービスを運用し、これらのサービスにビジネス・ロジックを適用することを可能にするアプリケーション配信コントローラーです。Alex は、British Columbia Institute of Technology (BCIT) で電気通信を専攻し、システム管理を学びました。2006年に英国に移住して以来、Zeus Technology に勤務しています。これまで Zeus のトレーニングおよび認定プログラムの作成を担当してきた彼は、現在、研究開発部門とシステム・エンジニアリング部門の間を橋渡しする連絡窓口の役目を勤めています。



2011年 7月 29日

誰かがクラウド・アプリケーションの配信の最適化について口にすると、私は即座にアプリケーション配信コントローラー (ADC: Application Delivery Controller) に関連する 3 つの機能を思い浮かべます。それは、アクセラレーション、高可用性 (HA)、そしてインテリジェント制御です。この 3 つのうち、この記事で私が提案する「トラフィック管理」モデルは、アクセラレーションと高可用性の側面に重点を置いています。

  • アクセラレーション: 各種ロード・バランシング・アルゴリズムの選択肢とコンテンツ・キャッシングについて理解し、IP 透過が Web アプリケーションのアクセラレーションにマイナスの影響を与える根本的な理由を理解してください。
  • HA: クラスタリングによって HA を実現する方法、そしてアプリケーション・インフラストラクチャー内の障害にグレースフルに対処する方法を学んでください。

アプリケーション配信コントローラー (ADC) とは、前述のとおり、アクセラレーション、HA、インテリジェント制御に関連するデバイス、あるいは技術のことです。ADC の実際の実行内容の基本を理解するには、一般に知られているネットワーキング技術との関連で ADC を位置付けると参考になります。

  • ネットワーク・スイッチは、Ethernet データのフレームを LAN セグメントに書き込みます。
  • ルーターは、インターネット・トラフィックを特定の IP アドレスに送信します。
  • NAT/ファイアウォールは、TCP 層または UDP 層のトラフィックに作用するポリシーを実装するために使用します。

どうしても曖昧な説明になってしまいますが、ADC はその名前が示唆するとおり、アプリケーション・トラフィックの配信方法を制御および管理するために使用されます。ADC は通常、ファイアウォールと多数のアプリケーション・サーバーの間で機能します。

それではまず、最適化に伴うアクセラレーションの側面について見て行きます。

アクセラレーションの要素

トラフィックが厳重に管理されたクラウド・システムでは、トラフィックを分散するために使用するロード・バランシング・アルゴリズムが、アプリケーション・アクセラレーションの重要な側面となります。Web アプリケーションの場合、HTTP 多重化を特定の Web サーバーと関連付けて用いることで、速度を大幅に向上させることができます。

その一方、このアクセラレーションの効果にマイナスに影響する要素も多数あります。その一例は、IP 透過です。IP 透過は、HTTP 多重化による有効なメリットを完全に打ち消してしまいます。

ロード時間を短縮すると同時に、Web サーバーの負荷を軽減するには、コンテンツ・キャッシングが極めて効果的な方法となります。

アクセラレーションの問題に対処するため、この記事では以下の点について説明します。

  • 各種ロード・バランシング・アルゴリズムの長所と短所
  • 局所性を認識したリクエスト分散
  • Web サーバーのスケーラビリティーと HTTP 多重化
  • IP 透過
  • HTTP キャッシング

上記の概念のそれぞれについて、これから詳しく説明します。

選り抜きのロード・バランシング・アルゴリズム

ロード・バランシングには多種多様なアルゴリズムがあります。そのうち、最もよく知られていて、十分に理解されているロード・バランシング・アルゴリズムは、おそらく操作が最も単純なラウンドロビンでしょう。それよりも複雑な他のアルゴリズムを理解するには、多少の説明が必要です。例えば、あるアルゴリズムでは、レスポンス時間が他よりも短いサーバー、あるいは接続数が最も少ないサーバーに対して、リクエストを優先して送信するといった動作をします。

ロード・バランシング・アルゴリズムにはどのような選択肢があるかを紹介するため、表 1 に一般的なロード・バランシング・アルゴリズムの概要を記載します。

表 1. 一般的なロード・バランシング・アルゴリズム
アルゴリズム説明
ラウンドロビンリクエストは各アプリケーション・サーバーに順に配信されます。単純な決定性アルゴリズムであり、通常はデフォルトの選択肢となります。
重み付けラウンドロビンラウンドロビンと同じですが、他のマシンに比べて処理能力の低いマシンに過剰な負荷がかからないように、手動で重み付けを追加します。
ランダム・ノードアプリケーション・サーバーを無作為に選択します。
最小接続 他のアプリケーション・サーバーよりも同時接続数が少ないアプリケーション・サーバーにリクエストを優先して転送します。
重み付け最小接続最小接続アルゴリズムと同じですが、他のマシンに比べて処理能力に劣るマシンに過剰な負荷がかからないように、手動で重み付けを追加します。
最速レスポンス他のアプリケーション・サーバーよりもレスポンス時間が短いアプリケーション・サーバーにリクエストを優先して転送します。レスポンス時間は一般に、あるマシンが他のマシンより多くのトラフィックを処理できることを示します。
認知型最小接続と最速レスポンスを組み合わせたアルゴリズムです。ただし、新しく追加されたアプリケーション・サーバーや最近回復したアプリケーション・サーバーに送信するトラフィック量を徐々に増加させるためのロジックも組み込まれます。

通常、各リクエストがアプリケーション・サーバーにかける負荷がほとんど変わらないようなトラフィックには、最小接続アルゴリズムが適しています。すべてのアプリケーション・サーバーが同程度のコンピューティング能力を保有するわけではない場合は、重み付け最小接続アルゴリズムを使用して、コンピューティング能力の違いを考慮に入れることができます。

最小接続アルゴリズムは、2 つのリクエストがアプリケーション・サーバーに与える負荷が著しく異なる可能性のあるトラフィックには適していません。Web アプリケーションに最適なアルゴリズムは一般に、最速レスポンスです。

局所性を認識したリクエスト分散

使用している ADC によっては、より高度なロード・バランシング・アルゴリズムに、データの局所性を認識してリクエストを分散する LARD (Locality-Aware Request Distribution) と呼ばれる機能が組み込まれている場合もあります。Web サーバーのベースにあるオペレーティング・システムは、最近ディスクから読み込まれたファイルを物理メモリーにキャッシュします。オブジェクトをメモリー内に保管している Web サーバーは、ディスクからファイルを読み取らなければならない Web サーバーよりも短時間でリクエストに応答する傾向があります。したがって、LARD は同じ URL に対するリクエストを同じサーバーに転送するための巧妙なテナント性を導入することによって、システム全体のパフォーマンスを向上させます。

Web サーバーのスケーラビリティーと HTTP 多重化

同時接続ごとに固有のプロセスが必要となるように設計されている Web サーバーは、実際のアプリケーションではスケーラビリティーがありません。スケーリングするには、少なくとも助けが必要です。

このようなシステムでは、Web サーバーのベースにあるカーネルが (プロセスに CPU が処理しなければならないワークがあるかどうかを調べるために) プロセス切り替えを行う際のオーバーヘッドがボトルネックになります。これが理由で、(一例として) Apache Web サーバーでは、生成する同時プロセスの数に制限 (ソフト制限とハード制限の両方) を設けています。

この同時プロセス数の制限という問題が表面化しがちなのは、クライアント接続に以下の特徴がある場合です。

  • 接続数が多い
  • 接続にある程度の失敗を伴う
  • さまざまな程度で遅延が発生する

実験環境でベンチマークを実行したときに測定された、1 秒あたりに処理可能なリクエスト数が、本番環境ではそのわずか 10 分の 1 (あるいはそれ以下) にしかならなかったとしたら、かなり落胆するはずです。

スケーラビリティーの問題に対処するには、HTTP 多重化という手法を利用することができます。多数の接続を単独のプロセスで処理するように設計されている ADC には、Apache サーバーと同じようなスケーラビリティーの問題はありません。ADC は多数の同時接続をクライアント側で終端してバッファリングした後、Web サーバーに対して常にオープン状態の少数の固定接続を介して HTTP リクエストを集約することができます。ADC はクライアント側の接続をバッファリングしてからアプリケーション・サーバーに転送するため、ADC をアプリケーション・サーバーに接続しているネットワークが優れたものであれば、サーバー側でのリクエストはかなり短時間で完了します。

アプリケーション・サーバーを 1 台しか使用していないとしても、この手法を使用すれば、ビジー・サイトで 2000 パーセントものパフォーマンス・ゲインを実現できることは驚くには値しません。

注意する点として、この手法を使用するには、ADC がレイヤー 7 モードで動作する必要があります。そうでないと、クライアントとサーバーの両方が HTTP キープアライブ接続をサポートするかどうかを ADC が判断できないためです。一般に、レイヤー 4 のロード・バランサーには、この手法から得られるメリットはありません。実のところ、反対にパフォーマンスを低下させる場合もあります。

IP 透過

多くのオペレーターは、Web サーバーのアクセス・ログに (さまざまな理由から) ユーザーのアクセス元の IP アドレスを記録する必要があることに気付くと、その必要に対処するため、直感的に ADC を透過モードで動作するように構成します。

透過モードでは、ADC は各クライアントの IP アドレスを SRC IP アドレスとして各パケットに含めてから、そのパケットをアプリケーション・サーバーに送信します。このプロセスは、スプーフィングと呼ばれることもあります。

ユーザーのアクセス元の IP アドレスを記録するために ADC を透過モードで動作させるという手段を採るのは極めて理に適っていますが、IP 透過の有効化は、パフォーマンスにとっては不利な条件です。IP 透過が有効になっている場合、クライアントと ADC、そして ADC とサーバー接続数の比率は n:1 ではなく、1:1 になります。そのため、HTTP 多重化は完全に効力を失ってしまいます。

IP 透過という手段を採る前に、クライアントの IP 情報を取得する別の方法を慎重に検討してください。例えば、各リクエストに HTTP cookie を挿入するように ADC を構成することもできます。あるいは、ADC 自体でアクセス・ロギングを行える場合もあります。

HTTP キャッシング

Web アプリケーションを高速化するのに最も効果的であり、頻繁に使用されている手法の 1 つは、キャッシング・リバース・プロキシーを Web アプリケーションの前面に配置することです。HTTP キャッシングを行うなかで最も肝心な部分は、キャッシュに保管できるオブジェクト、キャッシュ内のオブジェクトの有効期限などを決定することです。キャッシング・デバイスはこれらの事項に対する答えを出すために、リクエスト・ヘッダーおよびレスポンス・ヘッダーのすべてを構文解析しなければなりません。

ADC は、コンテンツ・キャッシングを行うのに理想的な条件を備えています。ADC がレイヤー 4 モードではなく、レイヤー 7 モードで動作するように構成されるということは、どのみちヘッダーを構文解析することになるためです。


高可用性の問題

さまざまなクラウド・プロバイダーが、さまざまな高可用性ソリューションを使用しています。問題が発生した場合、実行されているインスタンスをある物理リソースから別のリソースに移すという方法を採っているプロバイダーもあれば、単純に IP アドレスをインスタンス間で移すというプロバイダーもあります。常に手っ取り早い手段となるのは、IP アドレスをある場所から別の場所に移すだけの方法です。

ADC には、ある種の IP フェイルオーバー・メソッドが組み込まれています。通常、このメソッドでは ARP ブロードキャスト (アドレス解決プロトコル) を使用して、IP アドレスが移動したことをネットワーク・インフラストラクチャーに通知します。さらに、マルチキャスト MAC アドレス指定を使用して、単一の IP アドレスを複数の ADC インスタンスに分散するという手法もあります (メディア・アクセス制御)。

移動可能であるか、そうでなくてもクラスターのメンバーが共有できる IP アドレスは、仮想 IP アドレスと呼ばれることがよくあります。インターネット・サービスが HA であると見なされるには、このような仮想 IP アドレスを少なくとも 1 つはリッスンするように構成されていなければなりません。

高可用性について、このセクションでは以下の詳細を取り上げます。

  • クラスタリング
  • ADC のフォルト・トレランス
  • アプリケーションの正常性の監視

クラスタリング

有効なプラクティスは、重要なインフラストラクチャーには決して単一障害点を取り込まないようにすることです。すべての ADC には、ある種のクラスタリング・メカニズムがあります。クラスター化されたデプロイメントでは、一連の ADC が構成を共有し、共に扱っているアプリケーション・セッションの状態に関する情報を共有できるようになっています。使用している製品によっては、構成管理を一元化することも、分散することも可能です。ADC 構成システムのなかには、マスター・スレーブ・モデルに従うものもあれば、マルチマスター・モデルに従うものもあります。

ADC のフォルト・トレランス

クラスタリングされた ADC は、ある種のハートビート・メカニズムを使用して障害を検出し、フェイルオーバー・メカニズムを使用して HA を実現します。クラスタリングされた ADC のうちの 1 つで障害が発生した場合には、その ADC が処理していたトラフィックの作業負荷が、クラスター内の残りの正常なメンバーの間で分配されます。

また、障害が発生したマシンに (もちろん、そのマシンが回復した後) サービスが自動的にフェイルバックできるようにすることも望まれます。

アプリケーションの正常性の監視

Web サーバーのいずれかで障害が発生した場合、ユーザーはいくつかの措置が実施されることを期待しますが、なかでも該当するサーバーに新しいトラフィックが送信されることは少なくとも避けたいと考えます。

しかし不適切な期待は、問題につながる可能性があります。それを防ぐために、以下にフォルト・トレランスに関する検討事項をリストアップします。

  • 配信システムを通過している実際のトラフィックをモニタリングしているかどうか
  • アプリケーションに対して帯域外テストを行っているかどうか
  • チェックの頻度
  • アプリケーションに対するテストの詳細レベルおよびテストの範囲
  • 連続して何回障害が発生したら、障害イベントとするべきか
  • 障害の検出方法
  • 障害の検出時に自動的に行われる措置 (そのような措置がある場合)
  • 通知の送信方法

以上の事項は障害が検出されるまでの時間に影響するため、詳細に検討してください。障害をその発生と同時に検出することは不可能であり、フェイルオーバーの検出の速さと過度な検出感度との間での妥協点を見つけなければなりません。正常性の監視の感度があまりにも高いと、ネットワーク内のごく些細な異常でさえもアラームを起動させてしまうからです。

次のセクションでは、私が関わっている実際のシステムを通して、これまでに説明した概念のいくつかを具体的に紹介します。


実際のトラフィック・マネージャーの例

Zeus Traffic Manager

Zeus Technology の Traffic Manager は、最も一般的な Web/アプリケーション・サーバーおよびプロトコルを最適化するように設計された、ソフトウェア・アプリケーション配信コントローラーです。この製品は現在、世界の通信事業者や、whitepages.com、BBC などのサイトで使用されています。

  • 速度: この製品には、この記事で説明しているアクセラレーションおよび最適化の手法が多数採り入れられています。例えば、SSL、XSLT および圧縮処理のオフロード、そして HTTP コンテンツ・キャッシングなどの手法によって、アプリケーションを高速化すると同時に、サーバーの負荷を軽減します。
  • 可用性: ロード・バランシング・メソッド、セッション・パーシスタンス、そして正常性の監視を使用して、アプリケーションをオンライン状態に維持し、サービス・レベルの監視および帯域幅管理を行うことにより、ユーザーがハイレベルなサービスを利用できるようにします。
  • セキュリティー: 実証済みのアプリケーション・ファイアウォールを使用して DoS 攻撃から保護します。
  • データ・アナリティクス: アプリケーションの実際のレスポンス時間を監視して、ログ、レポート、およびグラフを利用して SLA を追跡することができます。リアルタイムのアナリティクスを使用して、接続と同時にそのパターンをフィルタリングすることにより、問題を素早く診断することができます。
  • ユーザー制御: TrafficScript と Java 拡張機能によって、ユーザーがトラフィック管理ポリシーをカスタマイズできるようになっています。

最後のセクションでは、この記事で紹介した概念を具体的に説明するために、Zeus Technology の Traffic Manager による以下のトラフィック管理手法を取り上げます。

  • クラスターの作成による高可用性。
  • トラフィック IP アドレス・グループ。トラフィック IP アドレス・グループを使用することにより、トラフィック・マネージャーはシングル・ホスト・モードまたはマルチ・ホスト・モードで IP アドレスを制御することができます。
  • 簡単にデプロイできる新規サービス。
  • 簡単に変更できるロード・バランシング・アルゴリズム。
  • 簡単に使用できるコンテンツ・キャッシング。

クラスターの作成による高可用性

Zeus の管理コンソールは分散モデルに従っていて、トラフィック・マネージャーごとに 1 つの管理プロセスを実行するようになっています。この管理プロセスには Web ベースのユーザー・インターフェースが組み込まれていて、任意の数のオペレーターがクラスターのさまざまなメンバーに同時にログインして構成を変更することができます。構成の変更内容はいずれも、サブミットされると同時に、他のすべてのクラスター・メンバーに転送されます。

これらの変更に他の変更内容と競合するものがない限り、すべての変更は正常に反映されます。変更が競合する場合には、オペレーターに対し、その競合を解決するよう求めるプロンプトが出されます。

例えば、クラスターを作成する準備ができている一組のマシンがあるとします。その場合、クラスター参加ウィザードを以下の手順に従って実行することができます。

  1. Zeus のユーザー・インターフェース (UI) の右上隅にあるウィザードのドロップダウン・ボックスから、「Join a Cluster (クラスターへの参加)」を選択します。必要に応じて「Next (次へ)」をクリックします。
  2. トラフィック・マネージャーが、マシン上の各インターフェースのブロードキャスト・ドメインにクラスター検出メッセージを送信します。すると、これらのブロードキャスト・ドメイン内に常駐する他のすべてのトラフィック・マネージャーがレスポンスを返します。レスポンスを返したすべてのマシンが、参加可能なクラスターのリストに表示されます。
  3. クラスターのリストから設定済みクラスター・ホストを選択し、「Next (次へ)」をクリックします。
  4. 設定済みクラスター上で管理ユーザーのクレデンシャルを入力します。この時点で、クラスターに参加しているメンバーに対し、すぐにトラフィックの処理を開始するのか、それともクラスターが構成されるのを待ってからトラフィックの処理を開始するのかを指定することができます。このオプションは、少なくとも 1 つのトラフィック IP アドレス・グループが構成されていない限り、変更しても効果がありません。
  5. 今以降に行う作業の内容が要約されて表示されます。作業を開始するには、「Finish (終了)」をクリックます。

これで実際に動作するクラスターが用意できたので、今度はトラフィック IP アドレス・グループの作成 (および、クラスター内のマシンのいずれかで障害が発生した場合にはフェイルオーバーさせるための設定) に取り掛かります。トラフィック IP アドレス・グループを使用する目的は、これから構成しようとしているサービスに高可用性をもたらすことです。注意しておく点として、技術的な観点から言うと、トラフィック IP アドレス・グループやサービスを作成する前にクラスターを作成しなければならないわけではありません。ここでは単に、記事の目的に応じたワークフローのステップに従っているだけです。

トラフィック IP アドレス・グループ

Zeus Traffic Manager の高可用性機能で中心的役割を果たすのは、トラフィック IP アドレス (Zeus の用語では、VIP (Virtual IP Address)) です。トラフィック IP アドレス・グループ (TIP グループ) という論理単位にグループ化されるトラフィック IP アドレスは、複数の Zeus Traffic Manager からなるクラスターでホストされます。クラスターに参加できるトラフィック・マネージャーの数や、クラスターがホストできるトラフィック IP アドレスの数に上限はありません。1 つのアクティブなトラフィック IP アドレスに対し、n 個のトラフィック・マネージャーという構成で、単一のトラフィック IP アドレスを多数のトラフィック・マネージャーでホストすることもできます。

通常、Zeus Traffic Manager はアクティブ ― アクティブのペアの形でデプロイされます。アクティブな各トラフィック・マネージャーでのリソース需要が高くなってきたら、必要に応じて新しいマシンを追加することができます。

1 つのトラフィック・マネージャーが、個別に制御できる多数のトラフィック IP グループをホストすることもできます。クラスター内に機能しているトラフィック・マネージャーが 1 つでもあれば、すべてのトラフィック IP アドレスは到達可能な状態を維持します。トラフィック IP グループは、シングル・ホスト・モードでもマルチ・ホスト・モードでも操作することができます。

シングル・ホスト・モード
シングル・ホスト・モードでは、トラフィック IP アドレスのそれぞれが、クラスター内の 1 つのトラフィック・マネージャーでホストされます。グループに複数の IP アドレスが含まれる場合、これらの IP アドレスは、それぞれ異なるトラフィック・マネージャーでホストされて、可能な限り均一に分散されます。

例えば、2 台の Zeus マシンからなるクラスターと、3 つの IP アドレスが含まれる TIP グループがあるとすると、一方のマシンが 2 つの IP アドレスをホストし、もう一方のマシンが 1 つの IP アドレスをホストすることになります。

マルチ・ホスト・モード
マルチ・ホスト・モードでは、各トラフィック IP アドレスをクラスター内のすべてのトラフィック・マネージャーで同時にホストすることができます。マルチ・ホスト・モードでトラフィック IP アドレスをデプロイするには、ZTM または ZLB 仮想アプライアンスを実行しているか、Zeus Kernel Modules for Linux (Zeus Community サイトからダウンロード可能) がインストールされている必要があります。適切なモジュールが実行されている場合、各アドレスをグループ内のすべてのマシンで有効にするための選択肢が表示されます (図 1)。

図 1. マルチ・ホスト・モードでは、各アドレスをグループ内のすべてのマシンで有効にすることができます
マルチ・ホスト・モードでは、各アドレスをグループ内のすべてのマシンで有効にすることができます

この時点で、トラフィック・マネージャーのクラスターと、少なくとも 1 つのトラフィック IP グループが作成されました。ネットワークでパケット・スニファーを使ってみると、それぞれのトラフィック・マネージャーが起動を完了し、IGMP/マルチキャスト・ハートビート・メッセージを使用してその正常性を宣言していることがわかるはずです。デフォルトでは、これらのメッセージは 500 ミリ秒ごとに送信されます。あるトラフィック・マネージャーのハートビートが他のトラフィック・マネージャーによって確認されない時間が 5 秒間に及ぶと、クラスターの残りのトラフィック・マネージャーは、そのトラフィック・マネージャーで障害が発生したと見なし、フェイルオーバーの処理を開始します。これで、トラフィック IP グループを使って、クラスターで実行されるサービスを高可用な状態に維持できるというわけです。

簡単にデプロイできる新規サービス

Zeus Traffic Manager で新しいサービスをデプロイする方法は、驚くほどに洗練されています。クラスターを作成する場合と同様、新規サービスについてもウィザードに従って作成することができます。

一例として、以下は、HTTP の負荷を多数の Web サーバーに分散する「Web」という新しいサービスを作成する場合の手順です。

  1. UI の右上隅にあるドロップダウン・リストから、「Wizards (ウィザード)」 > 「Manage a new service (新規サービスの管理)」の順に選択します。
  2. 「Web」という名前のサービスを新規に作成します。
  3. 内部プロトコルを HTTP に設定します。
  4. リッスンするポートとして 80 が指定されます。
  5. Next (次へ)」をクリックします。
  6. 追加するアプリケーション・サーバーごとに、ホスト名 (または IP アドレス) を入力して「Add Node (ノードの追加)」をクリックするという操作を繰り返します。デフォルト・ポートのフィールドは、ウィザードのステップ 2 で指定されたポートと同じになることに注意してください
  7. アプリケーション・サーバーを追加し終わったら、「Next (次へ)」ボタンをクリックします。
  8. 要約ページを一読して確認したら、「Finish (終了)」をクリックしてウィザードを完了します。

ウィザードを完了すると、ホーム・ページの「Services (サービス)」セクションに仮想サーバーが表示されます (図 2)。

図 2. 作成された仮想サーバー
作成された仮想サーバー

デフォルトでは、「Manage a new service (新規サービスの管理)」ウィザードを使って作成するサービスは、トラフィック IP グループを含む、各クラスター・メンバーで使用可能なすべての IP アドレスをリッスンします。つまり、追加の設定を行わなくても、サービスは基本的に高可用性サービスとして作成されるということです。これは、1 つのサービスだけを実行している場合には好都合です。しかしトラフィック・マネージャーを使用している場合には、複数のサービスを実行している可能性があるため、以下の手順に従って、特定のトラフィック IP アドレス・グループでリッスンするようにサービスを構成します。

  1. 「Services (サービス)」 > 「Virtual Servers (仮想サーバー)」 > 「Web」の順にナビゲートします。
  2. Listen on specific Traffic IP address groups (特定のトラフィック IP アドレス・グループでリッスンする)」の隣にあるラジオ・ボタンをクリックします。
  3. サービスにリッスンさせる各トラフィック IP アドレス・グループのチェック・ボックスにチェック・マークを付けます。
  4. Update (更新)」をクリックします。

簡単に変更できるプールのロード・バランシング・アルゴリズム

プールのロード・バランシング・アルゴリズムを変更するのも同じく非常に簡単です。

  1. Zeus UI で「Services (サービス)」をクリックします。
  2. Pools (プール)」タブをクリックします。
  3. 編集するプールの「Edit (編集)」リンクをクリックします。
  4. Load Balancing Edit (ロード・バランシングの編集)」リンクをクリックします。
  5. load_balancing!algorithm リストから、目的のアルゴリズムを選択します。
  6. 重み付けアルゴリズムのいずれかを使用する場合には、重み付けフィールドに入力します。
  7. Update (更新)」をクリックします。
図 3. 一番上に表示されるのはラウンドロビンです!
一番上に表示されるのはラウンドロビンです!

Zeus Traffic Manager のロード・バランシング・エンジンには、 (HTTP サービスの場合には常に) HTTP マルチプレクサーが不可欠であるため、これを無効にすることはできません (無効に設定するというケースは皆無です)。LARD のメリットを生かして Web アプリケーションを管理したいという場合には、最速レスポンスまたは認知型アルゴリズムのいずれかを試してみてください。

簡単に使用できるコンテンツ・キャッシング

トラフィック・マネージャーのキャッシュ機能を有効にする手順は以下のとおりです。

  1. Services (サービス)」をクリックします。
  2. Virtual Servers (仮想サーバー)」タブをクリックします。
  3. 目的の仮想サーバーの「Edit (編集)」リンクをクリックします。
  4. Content Caching (コンテンツ・キャッシング)」リンクをクリックします。
  5. webcache!enabled: option (webcache!enabled: オプション)」を「Yes (はい)」に設定します。
  6. ページの一番下までスクロールダウンして、「Update (更新)」をクリックします。

コンテンツ・キャッシング機能が有効に設定されると、トラフィック・マネージャーはキャッシング・プロキシーのような役割を果たすようになり、RFC 2616 準拠のキャッシング・プロキシーに関係するすべてのポリシーにインテリジェントに従います。Web ブラウザーからは、Web サーバー上でのシステム負荷が大幅に低下していること、そしてロード/レスポンス時間が短縮されていることを確認できるはずです。そして何よりも嬉しい点は、別個のキャッシング・デバイスをインストールすることによって、インフラストラクチャーを余計に複雑にしなくても済むことです!


まとめ

この記事で説明した機能および方法は、ADC によって実現できる内容を表面的にかじったに過ぎません。特定の ADC に意図された (ロード・バランシングを行うことだけにとどまらず) 接続を賢く処理するための仕組みは、アプリケーション・アクセラレーションの基本になっています。そのため、ADC が内部でどのように機能しているのかをある程度理解しておくことが重要となります。コンテンツ・キャッシングは、比較的少ないコストで、しかも簡単に Web サイトのロード時間を大幅に短縮する方法です。この記事では、トラフィックの評価や優先順位付けについてはまったく取り上げなかったので、ある程度の時間をかけて調べるにはお勧めの分野です。例えば、以下のトピックについて調べてください。

  • ネットワーク・サイドのスクリプティング
  • 帯域幅の管理
  • リクエストの頻度の調整
  • 自動スケーリング

Zeus Technology には、公式の製品マニュアルのすべてを無料で公開している優れたコミュニティー・サイトがあります。アプリケーション配信についてさらに詳しく知るには、Zeus コミュニティーを調べてみてください。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=742519
ArticleTitle=クラウド・アプリケーション配信システムを最適化する
publish-date=07292011