このページの本文へ

前へ 1 2 次へ

アプリケーショントラフィック管理入門 第3回

サーバー以外の負荷分散や広域ロードバランシングを学ぶ

ますます高機能化するロードバランサーの技術

2010年03月29日 06時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

誕生以来、ロードバランサーはますます機能強化を続け、単なるサーバーへの負荷分散を超えるアプリケーショントラフィックの管理装置に成長している。今回はWebサーバー以外の負荷分散や広域なロードバランシングなどの機能を総ざらいしていきたい。

本記事は「アプリケーショントラフィック管理入門」の第4回です。過去の記事も合わせてご覧ください。

ますます拡がる
ロードバランサーの適用範囲と機能

 ロードバランサーは、クライアントからのリクエストを複数のサーバーに分散して振り分け、サーバーの負荷を減らす。また、故障したり、高い負荷のかかったサーバーに対しては、リクエストを振り分けないように調整し、システム全体のパフォーマンスや可用性を高める。こうした利点から、1990年代後半、ロードバランサーはアクセス数の多いEコマースサイトやWebサイトなどで数多く導入され、市民権を得た。

 その頃登場した代表的なロードバランサーとしては、F5ネットワークスの「BIG-IPシリーズ」やアルテオンウェブ・システムズ(現ラドウェア)の「AlteonACEDirectorシリーズ」などが挙げられる。その後、シスコシステムズやファウンドリーネットワークスなども市場に参入した。21世紀に入っても、機能や価格の面で激しい競争を繰り広げている。

 その結果、ロードバランサーはますます進化を続け、適用範囲を拡げている。以下、発売当初から拡張された機能について見ていこう。

Webサーバー以外の冗長化

 当初、ロードバランサーは対象をWebサーバーに絞っていた。ドットコムブームにおけるロードバランサーの需要の中心は、Webサイトでの負荷分散だったので、当然といえば当然だ。

 しかし、Webサーバーを防御するためのファイアウォールやIDS、ルータなどの処理能力が遅ければ、当然サイトのパフォーマンスとしては低くなってしまう。また、Webサーバー以外にも、メールサーバーやデータベースサーバーなどアクセス過多により、過負荷に陥る可能性がある。特に2000年以降、WAN回線が一気にブロードバンド化したことで、セキュリティ機器やサーバーの処理能力はシステム全体から見て、大きなボトルネックになってしまったのだ。

 こうしたことから、現在のロードバランサーでは、(1)HTTP、SMTP、POP3、DNS、RADIUS、LDAP、SIPなどの各種サーバー、(2)ルータやスイッチなどのネットワーク機器、(3)ファイアウォールやVPNゲートウェイ、IDS・IPSといったセキュリティ機器など、幅広い装置の負荷分散に対応している(図1)

図1 サーバー以外の機器のロードバランシング

 特にソフトウェアベースのファイアウォールは、ブロードバンド化に追従できず、パフォーマンスも劣化しているにも関わらず、簡単に置き換えることもでない状況だ。こうした場面で、ロードバランサーの利用価値は非常に高い。ちなみに、さまざまな機器を冗長化するロードバランサー自体も、ダウンしたらサイト全体が停止してしまうことになる。そのため、ロードバランサーを複数台用意し、いずれかが障害を起こしてもサービスが継続できる冗長化が施されている機種が増えている。

グローバルな負荷分散

 登場した当初のロードバランサーが対象としていたのは、あくまで単一のサイトにあるローカルのサーバーであった。しかし、サーバールームで停電が起こったり、自然災害で同じ場所に置かれたサーバーがすべてダウンしたら、サイトは利用不能になってしまう。こうした事態を避けるために、ロードバランサーは地理的に複数のサイトにまたがるグローバルな負荷分散機能を搭載するようになった。

 代表的なF5のBIG-IP Global Traffic Manager(BIG-IP GTM:旧称3-DNS)でのグローバル負荷分散の機能を用いて、3カ所のサイトの負荷分散を行なう例を見てみよう。BIG-IP GTMはDNSを用いて、複数サイトを適切に使い分ける機能を持っている。

 まず、BIG-IP GTMを3カ所のサイトに設置し、各サイトのサーバー等にヘルスチェックを行なうようにしておく。そして、そのうち1台をDNSサーバーとして動作させ、クライアントのリクエストが来た時点で、各サイトのBIG-IP GTMに問い合わせをかける。その結果、いくつかの条件からもっとも最適なサイトのIPアドレスをクライアントに戻すわけだ(図2)

図2 DNSを用いた広域なロードバランシング

 ローカルと比べて、グローバル環境での負荷分散は、ヘルスチェックはより詳細に行なう必要がある。単なるPingやTCPコネクションの接続チェックのみならず、各サーバーへの往復時間(ラウンドトリップタイム)やパケットロス率などを測定し、適切な応答時間を割り出す。また、IPアドレスを調べ、地理的な場所を特定するデータベースと照らし合わせることで、適切な言語のページを表示させるという「地理的ロードバランシング機能」もある。この機能を用いると、たとえば日本のユーザーの場合は日本語ページを、米国のユーザーの場合は英語ページを表示するといったユーザーに最適なコンテンツを表示することが可能になる。

(次ページ、サービスの可用性を確保)


 

前へ 1 2 次へ

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事

アクセスランキング

  1. 1位

    ビジネス・開発

    いますぐ捨てたいITサービスは? AI推しにそろそろ飽きてません? 情シスさんのホンネを「ゆるっとナイト」で聞いた

  2. 2位

    ITトピック

    「AI導入で人員を減らしても収益は増えない」その理由/「専任情シス不在」中小企業の3社に2社/ユーザーアカウント流出が加速、ほか

  3. 3位

    エンタープライズ

    基盤も古いし、コードも酷い! そんなクエストにGitHub Copilotで試行錯誤しまくった「みんな」こそ最高

  4. 4位

    Team Leaders

    Power AutomateでSharePoint APIを使う ― SPOリストを自動作成するフローを作ろう

  5. 5位

    sponsored

    完全自動運転の実現へ、チューリングが開発基盤にGMO GPUクラウドを選んだ理由

  6. 6位

    ソフトウェア・仮想化

    日本の自治体がみんな使っている「ManageEngine」 IT運用のすべての課題解決を目指す

  7. 7位

    クラウド

    「すでに開発コードの4分の3はAI生成」 Google Cloud CEO、エージェント時代の戦略を語る

  8. 8位

    スマホ

    ここまで便利なのか! 子どもの居場所を90秒間隔で教えてくれる、安心の見守りガジェットがすごいぞ

  9. 9位

    ビジネス・開発

    「粗悪記事」「ゼロクリック」「搾取」からクリエイターをどう守るか? AIに強いnoteが挑む創作エコシステム

  10. 10位

    ソフトウェア・仮想化

    AIエージェントを野放しにしない ― ServiceNowは“AI司令塔”で自律とガバナンスを両立

集計期間:
2026年05月11日~2026年05月17日
  • 角川アスキー総合研究所