2つのロードバランサーを比較【前編】
“OSI参照モデル”で見た第4層、第7層の「ロードバランサー」の違いはこれだ
「ロードバランシング」(負荷分散)は、いまやWebサービスや業務システムを支える不可欠な仕組みだ。ネットワークとアプリケーション、2つの負荷分散の仕組みを解説する。
「ロードバランシング」(負荷分散)は、もはや現代のITサービスに欠かせない仕組みだ。オンラインショッピングやニュースの閲覧、投資情報の確認といった一般的なインターネットサービスはもちろん、大企業のITインフラで運用される業務システムも、ロードバランシングなしでは正常に機能しないと言って過言ではない。
トラフィック(ネットワークを流れるデータ)を複数のシステムに分散させるのがロードバランシングだ。その仕組みは、地理的に離れたデータセンターや、世界各地に分散する仮想サーバといった広範囲にまたがって構成されていることがある。ロードバランシングがなければ、ニュースサイトの閲覧でもオンラインショッピングでも、全てのユーザーが同じサーバにアクセスすることになり、結果としてサーバが過負荷に陥り、サービスの提供が困難になる恐れがある。これを防ぐために、ロードバランサー(負荷分散装置)はトラフィックを各サーバへ適切に振り分ける。
とはいえ一口にロードバランシングと言っても、その仕組みは大きく「ネットワークロードバランシング」と「アプリケーションロードバランシング」の2種類に分けることができる。これは、「OSI参照モデル」(OSI:開放型システム間相互接続)の7階層のうち、どの階層で処理をするかによって区別される。ネットワークロードバランシングは第4層(レイヤー4、トランスポート層)で機能し、アプリケーションロードバランシングは第7層(レイヤー7、アプリケーション層)で機能する。以降では、この2つのロードバランシングの処理が、それぞれどのような結果の違いを生むのかを解説する。
ネットワークロードバランシングとは何か
ネットワークロードバランシングは、ルーターのような機能を持つ専用のシステムや機器として実装されるが、多くの場合はハードウェア面でもソフトウェア面でも負荷分散の目的に応じて設計されている。この負荷分散方式は、OSI参照モデルの第4層、トランスポート層で動作し、主にTCP(Transmission Control Protocol:伝送制御プロトコル)やUDP(User Datagram Protocol:ユーザーデータグラムプロトコル)といったトランスポート層のプロトコルを使用する。TCPは全てのパケットが正しく転送されることを保証するのに対し、UDPは転送の保証がない通信の仕組みだ。
エンドユーザーがWebサービスにリクエストを送信する際は、一般に既知のドメイン名が使われる。例えば、米ニュースメディア「CNN」のWebサイトを閲覧しようとするリクエストは、そのドメインにひも付けられたIPアドレスを持つロードバランサーに送られる。ロードバランサーは、CNNのコンテンツを提供する複数のバックエンドシステムのIPアドレスをルーティングテーブル(宛先までの経路情報をまとめた表)に登録しており、受信したリクエストを即座に適切なサーバへと振り分ける。
ネットワークロードバランサーは、リクエストの内容を解析せず、パケット(送受信データを小分けにした単位)のヘッダ情報のみを基に処理を実行する。そのため、リクエスト内容に応じた転送先の選定はしない。ただし、応答しないサーバを自動的に振り分け対象から除外する機能を備えているため、全体としての信頼性は向上する。
アプリケーションロードバランシングとは何か
アプリケーションロードバランシングは、OSI参照モデルの第7層、アプリケーション層で動作するロードバランシング方式だ。サーバにインストールされたアプリケーションが、HTTPS(Hypertext Transfer Protocol Secure)やSMTP(Simple Mail Transfer Protocol)といったアプリケーション層のプロトコルによる通信内容を解析し、その内容に応じて処理を振り分ける。この方式では、リクエストの内容に沿ってサーバに処理を割り当てることができる。例えばオンラインショッピングでは、ユーザーのリクエスト内容に応じて、該当する商品カテゴリーの在庫情報を管理しているシステムに処理を振り分けるといった制御が可能になる。
ネットワークロードバランシングがリクエストを単純に転送するのに対し、アプリケーションロードバランシングでは、リクエストのヘッダ情報を解析し、アプリケーション層のプロトコルに含まれるデータ内容を精査する。この解析には時間がかかるものの、その分リクエストの内容に基づいて、最適なサーバへの振り分けを判断できるという利点がある。
ロードバランシングのアルゴリズム
ロードバランサーはリクエストを受信すると、さまざまなアルゴリズムを使って転送先の候補を選定する。アルゴリズムには、大まかに2つの種類がある。一つはあらかじめ定義されたルールに従ってリクエストを振り分ける「静的アルゴリズム」。もう一つはサーバのワークロード(システムにかかる処理負荷やその種類)や応答時間などの状況に基づいて転送先を調整する「動的アルゴリズム」だ。以下に、ロードバランシングでよく用いられる主なアルゴリズムの例を挙げる。
- ラウンドロビン方式
- 宛先の候補を順番に循環させて振り分ける、シンプルな静的アルゴリズム。
- 重み付きラウンドロビン方式
- ラウンドロビン方式の一種。ネットワーク管理者が各システムの性能に応じて重みを設定できるため、サーバの処理能力が均一でない場合に適している。
- IPハッシュ方式
- クライアントのIPアドレスをハッシュ化(一定のルールに基づいて一意の値を生成する処理)し、同じIPアドレスからのリクエストは常に同じサーバに送信されるようにする静的アルゴリズム。セッション(1つの通信の開始から終わりまで)の維持が必要なステートフルアプリケーションに有効。
- 最小接続数方式(最小未処理リクエスト方式)
- 動的アルゴリズムの一つで、接続数や待機リクエスト数が最も少ないサーバを選び、最速の応答を得ることを目的とする。効率は高いが、接続の終了や待機リクエストの処理ごとにサーバからロードバランサーへの通知が必要になるため、通信量が増えるという課題もある。
- 重み付き最小接続数方式
- サーバの処理可能なアクティブ接続数(現在進行中のセッション数)に応じて重みを設定し、接続状況に基づいて動的にサーバを選ぶ。重みの考え方は重み付きラウンドロビン方式と似ているが、判断基準はリアルタイムの接続数となる。
- 最小応答時間方式(最速応答方式)
- サーバの応答時間を計測し、最も迅速に応答できるサーバを選択する動的アルゴリズム。最小接続数方式に、接続の完了や待機リクエストの処理時間などの平均応答時間を加味することで、より精度の高い振り分けが可能になる。
- リソースベース方式
- 各サーバにインストールされたソフトウェアエージェントが、CPUやメモリなどのリソース使用状況を収集し、それに基づいてリクエストを割り振る動的アルゴリズム。リソースの可用性に応じた最適な負荷分散が可能になる。
次回はネットワークロードバランシングとアプリケーションロードバランシングをどう選べばよいのかを解説する。
Copyright © ITmedia, Inc. All Rights Reserved.
TechTarget発 世界のインサイト&ベストプラクティス
米国TechTargetの豊富な記事の中から、さまざまな業種や職種に関する動向やビジネスノウハウなどを厳選してお届けします。
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[サイボウズ株式会社] DXに必要な「Dスキル」「Xスキル」を持った人材を育成するには? -
市場調査・トレンド
[サイボウズ株式会社] データで見る、DXが「順調に進む企業」と「つまずく企業」の違い -
製品資料
[サイボウズ株式会社] 賛否が割れがちな「Notesからの移行」 新環境への移行を納得してもらうには? -
事例
[ServiceNow Japan合同会社] 農林中金に学ぶ内製開発 処理効率を約2倍に高めAI活用も加速させた方法とは? -
事例
[ServiceNow Japan合同会社] NTTグループのデジタル変革術、17万人が利用する決裁プロセス刷新の全貌
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは?
-
2
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
3
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
4
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
5
kintoneで実践 製造業のための「見積もり管理」改善のヒント
-
6
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
7
MS月例パッチが1000件突破 人手不足の情シスを襲う「月1回メンテ」の崩壊
-
8
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
9
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
10
DXを阻む「動くだけ」のレガシーシステムに決別するための生成AI活用術
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
3
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
4
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
-
5
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
6
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
7
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
8
マンガで解説:「ゼロトラスト」「SASE」の必要性とメリット
-
9
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
10
情報セキュリティ対策早分かりガイド:25の自社診断で弱点と解決策を理解
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー