
【Event Report】
「IP Network Technology & Solution Meeting」
ワークショップB-2
「ECサイト構築で求められる負荷分散ネットワーク技術」
鈴木淳也
アットマーク・アイティ 編集局
(取材協力:RBB TODAY)
2002/3/1
![]() |
| 講師:リアルネットワークス 鍋島公章氏 |
増大するトラフィックをいかにさばき、ダウンしないWebサイトを構築するか。これは、技術者にとっての大きな課題だろう。「サーバ負荷分散」という言葉はよく聞かれるが、実際にどのような技術があり、どのようなネットワークを構築すればいいか、その手法が語られる機会は意外と少ない。求める情報が得られないというジレンマに、いらだつ読者の方も多かったのではないだろうか?
今回は、2002年1月31日に開催された「IP Network Technology & Solution Meeting」(主催:インターネット総合研究所/RBB TODAY/アットマーク・アイティ)のイベント・レポート第3弾として、ワークショップA-2「ECサイト構築で求められる負荷分散ネットワーク技術」(講師:リアルネットワークス 鍋島公章氏)で語られた、基礎技術部分を中心にお送りしていこう。
複数のサーバに対してトラフィックを割り振り、処理にかかる負荷を分散させるのが負荷分散技術だが、大きく分けて「水平負荷分散」と「垂直負荷分散」の2つの技術が存在する。水平負荷分散が複数のサーバを並べて純粋にトラフィックを振り分けていく方法なのに対し、垂直負荷分散では機能別にサーバを分ける方法をとる。
さらに、水平負荷分散にも、サーバ群の前に「負荷分散装置」と呼ばれる機器を配置する方法と、各サーバにミドルウェアを導入してトラフィックを互いにやりとりさせる方法の2種類の実現方式がある。後者はコストの割にパフォーマンスが出ないため、最近では使われることはないという。今回の講演では、負荷分散装置を用いた水平負荷分散技術を中心テーマとして取り扱うと前置きし、解説へと入っていった。
■負荷分散技術の基礎知識
負荷分散技術の基礎知識として、まずDNSによる負荷分散についての解説が行われた。
●DNSによる負荷分散
DNSを使った負荷分散技術は古典的な技法であり、1996年くらいまでは全盛だったという。DNS名に対して複数のIPアドレスを割り当て、DNSサーバにアクセスしてきたユーザーに対して、順番に別々のIPアドレスを返答することで、複数のサーバに対してトラフィックを割り振る。つまり、この方法で負荷分散を実現している(参考記事「連載:DNSの仕組みと運用(3)『DNS導入に向けての予備知識』」)。
DNSには役割に応じていくつか種類がある。ユーザーが目的のサイトにアクセス場合に、最低でも3種類のDNSサーバにお世話になることになる。ユーザーが目的のサイトにアクセスする際に、まず最初に自身が属するサイトのDNSサーバ(ローカルDNSサーバ)に名前解決を依頼する。ローカルDNSサーバは、目的のサイトのDNSサーバの情報を知るために、まずルートDNSサーバにアクセスする。そこで得られた情報を基に、目的のサイトのDNS情報を持つDNSサーバに対してアクセスを行い、IPアドレスを得る。この際に得られた情報は、ローカルDNSサーバにキャッシュされ、次回、アクセスがあった際に高速に反応することが可能となる。
ここで1つ問題がある。DNS情報がキャッシュされてしまった場合(通常は数週間)、この方法による負荷分散は行えなくなってしまう。また、目的のサーバがダウンしてしまっていた場合、DNSサーバにとってはその情報を把握できていないため、本来であればアクセスできないサーバのIPアドレスを返答してしまうのだ。このため、DNSによる負荷分散ではサーバ障害には対応できない。
●スイッチによる負荷分散
そこで登場するのが、スイッチによる負荷分散だ。通常、スイッチといえばレイヤ2でのトラフィック制御を行う機器だが、今回の話で登場するのは、それよりもさらに上位にあたる、レイヤ3/レイヤ4/レイヤ7での制御が行えるスイッチ製品だ。
|
||||||||||||
| 表1 レイヤ3以上のスイッチ製品 |
ここで、講演で話題の中心となるのがレイヤ4以上で動作するスイッチである。レイヤ3スイッチでは、IPアドレスを基に特定のポートに対してパケットを振り分けるのが主な動作だったが、レイヤ4以上のスイッチでは負荷分散のために、NAT(Network Address Translation)によるアドレス書き換えや、MAT(Mac Address Translation)による直接サーバ返答(Direct Server Return:DSR)などの技法が用いられる。
●NATとMAT
NATについては、その動作をご存じの読者も多いだろう。ルータが外部ネットワークと内部ネットワークの窓口となり、やりとりされるパケットのアドレス変換を行う技術だ。NAT機能を持つ負荷分散装置は、VIPと呼ばれるIPアドレスを持ち、仮想サーバとしてユーザーからのリクエストを受け取る。負荷分散装置がパケットを受け取ると、NATによるアドレス変換を行い、各サーバへとトラフィックを振り分ける。NATによるアドレス変換が行われているため、サーバには自身の持つIPアドレスとユーザー同士が直接やりとりしているように見える。ここでサーバにより返答されたパケットは、いちど負荷分散装置で元のVIPのIPアドレスへと変換が行われ、ユーザーのところに届けられる。
一方のMATは、レイヤ2レベルでMACアドレスによる振り分けを行う。MATでは、複数のサーバに同一のVIPを持たせている。ところがイーサネットでは、IPアドレスを基にARP応答を行い、送信先ホストのMACアドレスを特定しているため、このままでは正常な通信が行えない(すべてのサーバが同時に返答を行ってしまうため)。この問題の回避のため、ARPに対して応答を行わないループバック・インターフェイスに対してVIPを振っておき、負荷分散装置にはサーバ群のMACアドレス・テーブルを持たせておく。これら手法により、MATが実現される。NATとは異なり、MATではIPアドレスの変換が行われないため、返答のために負荷分散装置を介さない直接サーバ返答(DSR)が可能である。
■負荷分散装置の動作
このように、負荷分散装置の役割とは、ユーザーからVIPへのリクエストを複数の実サーバに割り振ることである。その際に、障害の起こったサーバをリクエスト割り振りの対象から外すことも重要である(フェイル・セーフ)。もちろん、回復すれば元の状態に戻すことも必要だ。
●フェイル・セーフ
フェイル・セーフの実現には、対象となるサーバ群に対して、定期的にその状態を確認する必要がある。これを、ヘルス・チェックと呼ぶ。ヘルス・チェック内容としては、以下の項目が挙げられる。
|
||
| 表2 サーバのヘルス・チェック項目 |
注意点としては、極力短い間隔でヘルス・チェック発行を行うと迅速な障害検知が可能になるが、それによりサーバやネットワークの負荷を上昇させてしまったり、アクセス・ログにヘルス・チェックの結果が残ってしまうことである。また、超高負荷の状態でサーバがヘルス・チェックに応答できず、負荷分散装置がサーバがダウンしたと誤認してしまう問題もある。そのため、サーバの切り離しを行うのではなく、割り振り解除のみを行うべきである。またこの場合は、低いレイヤでのヘルス・チェックのほうが反応しやすいので、上記項目の上のほうからチェックを試してみるといいだろう。
●負荷分散の振り分けアルゴリズム
負荷分散における割り振りには、大きく分けて「均等割り振り」と「オーバーフロー割り振り」の2種類が存在する。均等割り振りは、単純に全サーバに対して均等にリクエストを振り分ける。オーバーフロー割り振りでは、高負荷状態に耐えられるパフォーマンスの高いサーバがあった場合などに、そちらのほうに積極的にリクエストを割り振る。
その際の振り分けアルゴリズムとして、ラウンドロビンと呼ばれる方法がある。サーバがダウンしていない限り、リクエストを順番に複数のサーバに対して割り振っていく。また、サーバの能力の違いにより「純粋ラウンドロビン(サーバ能力が同じ場合)」「重み付けラウンドロビン(サーバ能力が異なる場合)」の2種類を使い分けられる。
次に、コネクションに応じた振り分けがある。コネクションの判断基準にも「同時接続数」「応答時間」の2種類があり、同時接続数の場合は、処理しているコネクションが少ないサーバに対してリクエストを割り振る。応答時間の場合は、応答時間が短いサーバに対してリクエストを割り振る。
これら振り分けアルゴリズムについて、簡単に表にまとめてみたので、参照してほしい。
|
||
| 表3 代表的な振り分けアルゴリズム |
●負荷分散装置と接続維持
負荷分散装置では、コネクションを均等に複数のサーバに振り分けるため、場合によっては困った問題が発生する。例えば、ECサイトで買い物を行う場合など、買い物カゴに商品を入れて最後に会計することがあると思うが、コネクションが複数のサーバに分散させられていたとすると、買い物カゴの情報が複数のサーバにばらけてしまい、うまく会計処理が行えない結果となる。
この現象を回避するためには、あるユーザーの接続状態を維持しておく必要がある。そこで、接続維持のために、あるユーザーのリクエストを1つのサーバに割り振ることになる。通常の負荷分散では、リクエスト単位でリクエストを割り振っているが、ユーザーの最初のリクエストが割り振られたサーバに、2回目以降もリクエストを割り振り続け、接続を維持する。つまり、ユーザー単位にリクエストを割り振るのだ。最近の負荷分散装置では、この機能をサポートしているという。
あるリクエストがどのユーザーからのものなのかを特定するための認識方法として、「IPアドレス」と「Cookie」がある。IPアドレスは最も簡単で汎用性の高い手法だが、プロキシ・サーバが途中に介在していたりすると、特定のIPアドレスから集中的に大量のリクエストが送られてくる可能性がある。基本的には、ユーザーとIPアドレスが1対1の関係にあると上手く動く。もう一方のCookieを使う手法は、現在よく利用されている。Webブラウザに、Cookie文字列と対応するURLを保存させておき、そのURLにアクセスするたびに、保存されたCookie文字列をWebサーバが受け取る。Cookieは便利だが、多用するとWebブラウザのキャッシュが効かなくなりパフォーマンスが落ちるため、HTMLファイルだけにCookieを適用するなどの工夫が必要だ。
■負荷分散システムの構築
負荷分散システムの構築にあたって、どのようなネットワーク構成をとるかが重要になってくる。負荷に強く、落ちないサイトを実現するために、ネットワークを構成する機器にそれぞれ冗長性を持たせておく必要があるだろう。
●負荷分散装置の冗長化
サーバの冗長化については、これまで書いてきたとおり、負荷分散装置によって実現できる。負荷分散装置の冗長化は、ネットワーク・プロトコルによって実現される。複数の負荷分散装置を使ってシステムを構築する場合、普段は動作しない待機マシンが稼働マシンを置き換える「アクティブ-スタンバイ」、すべてが稼働マシンとして動作する「アクティブ-アクティブ」の、主に2つの動作モードがある。もし、いずれかのマシンに障害が発生した場合、残ったマシン(もしくは待機中のマシン)がその動作を引き継ぐ(フェイル・オーバー)。また、セッションやクッキー情報などを定期的にスタンバイ機に送信し、ダウン時に機能を引き継ぐことを、ステイトフル・フェイル・オーバーと呼ぶ。
●デフォルト経路の問題
一般に、サーバや負荷分散装置では、デフォルト経路が1つしか指定できないため、指定したルータに障害が発生すると、インターネットと接続できなくなってしまう。そこで、ルータ(デフォルト経路)の二重化が必要となる。そこで、VRRP(Virtual
Router Redundancy Protocol)を使う。同一IPアドレス(デフォルト経路)を2台のルータに持たせ、通信の際はVRRPの優先度が高いほうを優先する。アクティブ・スタンバイ方式をとり、アクティブ機からは、定期的にパケットを送り、スレーブ機(待機中のマシン)はパケットが到着しなくなったらアクティブ機に障害が発生したと判断する。
ここまで、負荷分散の基本的な技術についてざっとまとめてきた。本講演は、講師の鍋島氏が監訳した「サーバ負荷分散技術」(オライリー・ジャパン刊)がベースになっており、より深い情報を入手したいという方は、こちらを参考にしてほしい。実際のシステム構築例や、いくつか市販の負荷分散装置を取り上げ、その設定方法などについても解説している(こちらをクリックすると書評のページに移動します)。
![]() |
サーバ負荷分散技術 Tony Bourke 著、鍋島公章 監訳、上谷 一/横山晴庸 訳 |
@ITでは、さらに詳細にセッション内容を紹介した記事を順次アップしていく予定なので、もし本記事を読んで興味を持たれたテーマがあったら、期待してお待ちいただきたい。
| 関連リンク | |
| IP Network Technology & Solution Meetingのページ | |
| 書評:IP Networkフォーラム担当編集の気になる書籍 | |
| 連載:DNSの仕組みと運用(3)「DNS導入に向けての予備知識」 | |
| Index | |
| 「IP Network Technology & Solution
Meeting」 〜イベント・レポート総合インデックス |
|
| ITの軸になるのはIPネットワーク General Sessionの概要を速報レポート! (NewsInsight 2002/2/1) |
|
| エンジニアよ、チャンスは無限にある! Work Shop各セッションの簡単な紹介 Special Sessionのパネル・ディスカッションの詳細レポート (Master of IP Network 2002/2/8) |
|
| Workshopレポート A-1〜「IPv6ネットワークの実像と今後の展開」 (Master of IP Network 2002/4/9) |
|
| Workshopレポート A-2〜「高速IPネットワーク『IP-VPNサービス』の技術最前線と今後の展望」 (Master of IP Network 2002/2/21) |
|
| Workshopレポート A-3〜「必要とされるIP技術者・その条件」 (近日公開) |
|
| Workshopレポート B-1〜「広域LANサービスによる基幹業務システムの再構築とその技術」 (Master of IP Network 2002/4/16) |
|
| Workshopレポート B-2〜「ECサイト構築で求められる負荷分散ネットワーク技術」 (Master of IP Network 2002/3/1) |
|
| Workshopレポート B-3〜「現場エンジニアが語る、IPネットワーク技術者の実像」 (近日公開) |
|
| 「Master of IP Network総合インデックス」 |
ホワイトペーパー(TechTargetジャパン)
- どこまで出る? LTEの通信速度 (2010/3/17)
光ファイバに匹敵する通信速度を実現すると期待されているLTE。ホントにそんなに出るの? という疑問に答えます - インターネット世界の地図 (2010/2/23)
荷物の届け先まではどの道を通っていけばいいのでしょう? それを決める「経路選択」の仕組みを説明します - Androidアプリはビジネスになるのか (2010/2/12)
「iPhoneアプリの次はAndroid?!」NECビッグローブのAndroidアプリ販売サイト「andronavi」を通して、その可能性に迫る - 知られざるLTEのネットワーク構成 (2010/1/13)
LTEのネットワーク構成やプロトコルスタックを詳解。それぞれどんな役割を果たしているかを解説します
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約! “業務”用APサーバ大百科 New! |
| ◆ | 一気に解説! 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New! |
| ◆ | クラウド的ユーザー体験の変化は脅威か? 仮想化技術を使いこなす運用管理術を紹介 New! |

| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは? New! |
| ◆ | おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |

| ◆ | Twitterのアカウントはなぜ突破された? メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ! Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |

| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は? |
| ◆ | 業務効率と情報セキュリティ対策を両立! 手間なく確実に機密情報を守る方法とは? |

| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |

| ◆ | 【CTC事例】約30の基幹システムを統合! 膨大なバッジジョブを制御した方法は? |
| ◆ | 仮想化すればコストは削減できるか? 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |








