ベンチマークテストでうまくいくネットワーク機器選び【第5回】
スイッチやルータとは違う、「ロードバランサ」の実力の見どころ
カタログ情報だけでは分からない製品の本当の実力を見抜くため、重要な手掛かりとなるのがベンチマークテスト。今回はロードバランサのベンチマークテストについて見てみよう。
前回まではスイッチやルータのベンチマークテスト結果を見てきた。今回からロードバランサやファイアウォールなどのネットワーク機器のベンチマークテスト結果を見ながら、ベンチマークリポートを見る際の注意点を説明していく。スイッチやルータのテストと、ロードバランサ、ファイアウォールなどの検証方法は大きく異なる。そもそも使用するテスターや設定するパラメータが全く異なり、テスト結果の中から見るべき点も大きく違う。具体的に説明しよう。
連載:ベンチマークテストでうまくいくネットワーク機器選び
ロードバランサは「負荷分散装置」とも呼ばれる通り、クライアントからサーバへのリクエストを複数のサーバに振り分けることで、サーバ1台当たりの処理数を減らしたり、サーバの故障時やメンテナンスの際にサービスを止めずに済む導入効果がある。
実際のテストリポートを見ながら、カタログには記載されないロードバランサの実力値を読み解いていく。
検証で使用するテスターについて
スイッチやルータはパケット転送機器なので、受信したパケットを正しくかつ早く次の宛先へ転送するのが役目である。処理しているパケットが通信相手の了承なくデータを送りつける「コネクションレス型」のトラフィックなのか、通信相手の了承を得てからデータを送る「コネクション型」のトラフィックなのかを意識していない。
スイッチやルータの検証用途では、テスターはコネクションレスのトラフィックを送信できればよいので、パケットジェネレーターを使用して試験できる。一方、ロードバランサやファイアウォールはコネクション型トラフィックを処理するネットワーク機器であるため、これらを検証するテスターはコネクション型トラフィックを送信できる必要がある。
筆者が従事している@benchmarkでは、スイッチやルータを試験する場合は米Spirent Communicationsの「Spirent TestCenter」、ロードバランサやファイアウォールなどを試験する場合はコネクション型トラフィックが出せる「Spirent Avalanche」を使用している。
TCP新規コネクション数/秒
ロードバランサが使用されるということは、クライアントからのリクエスト数が多く、2台以上のサーバで処理を分散させることになる。この場合、サーバ1台当たりのリクエスト処理数もさることながらロードバランサの負荷分散処理能力が肝になる。この処理能力はベンダーのカタログに記載されることが多いが、実は記載されている意味合いがバラバラである。例えば先の@benchmarkで実施しているテストリポートには以下の記載がある。
- レイヤー4モード HTTP
- レイヤー7モード HTTP
- SSLクライアント証明なし(鍵長 2048ビット)
- SSLクライアント証明あり(鍵長 2048ビット)
ロードバランサがどういう設定でどのような動作をしているかにより、処理できるパフォーマンスは大きく変わる。その違いを調べるため、異なる試験を実施している。
レイヤー4モードではOSI参照モデルのトランスポート層、つまりTCPコネクションをベースに負荷分散を行う。一方のレイヤー7モードではOSI参照モデルのアプリケーション層、つまり流れるデータの中身を見て負荷分散する。
当然ながらレイヤー4モードの負荷分散処理よりレイヤー7の負荷分散処理の方が、ロードバランサにとってはきつい仕事(処理)になるためパフォーマンスが下がる。機器のカタログスペックを見る際は、どの負荷分散モードのスペックであるのか確認する必要がある。
また、最近はクライアントとサーバ間の通信をできるだけ安全に保つためにSSLサーバ証明書を利用したWebアクセスが主流となりつつある。ロードバランサがこの役割を担うことになるのだが、安全な通信であることを証明するためのSSLサーバ証明書を通信の中で取り入れているので、SSLサーバ証明書を使用しないプレーンな負荷分散処理と比べてロードバランサの仕事(処理)が忙しくなる。その分、負荷分散処理パフォーマンスが低下する。
図3のテスト結果を見ると、
- HTTP(レイヤー4モード)
- HTTP(レイヤー7モード)
- SSLクライアント証明なし(レイヤー4モード)
- SSLクライアント証明あり(レイヤー4モード)
の順で、ロードバランサの負荷分散処理が増大し、パフォーマンスが下がっていくのが分かる。SSLサーバ証明書の鍵長によってもロードバランサの処理が変わるため、カタログスペックを見る際は、併せて確認してほしい。
帯域
ロードバランサを導入したときにネットワークの「帯域」(詳細は後述)がどのくらいになるのかも重要である。せっかくスイッチやルータを10Gbpsにして回線を増強してもロードバランサが処理できる帯域が著しく低いと、せっかくのスイッチ・ルータの性能を十分に活用できなくなる。
本稿では、スイッチやルータでいう「スループット」と区別して表現したいので、あえて「帯域」と書いている。スイッチやルータのカタログスペックに書かれるスループットとは、パケット損失がないときの最大パケット転送レートだ(第2回「スイッチに期待できる能力をスペックの行間から読み解く」参照)。ただしロードバランサの場合、スループットは「パケットロスの有無にかかわらずどれだけのトラフィックを処理したか」の最大レートを指している。読者の皆さんがロードバランサのカタログを読むときは、「スループット=帯域」だと理解していただきたい。
図4はロードバランサが最もパフォーナンスよく負荷分散処理できるL4モード(プレーン)のときの帯域と、同じくL4モードでSSLサーバ証明書の処理を組み合わせたときの負荷分散帯域の比較である。L4モードで帯域が10Gbps近く出ているがロードバランサがSSL処理をするときは帯域が大きく下がるのが分かる。これを見ることで、ロードバランサの利用シーンに合った帯域を導入前に確認できる。
負荷分散ルール
クライアントからのリクエストを処理するサーバをロードバランサが振り分けるとき、幾つかのルールに沿って負荷分散している。最もシンプルなルールは複数台のサーバに順番に処理を振り分けていくラウンドロビン方式だ。他にはサーバの処理可能な能力を定期的に確認し、処理可能な能力が高いサーバに対して順にリクエストを振り分けていく方式もある。これ以外にもいろいろな負荷分散ルールがあるが実際にどのような負荷分散がされているか、テストリポートを見て確認できるので最後に載せておく。
| 疑似サーバIPアドレス | トランザクション毎秒(TPS) |
|---|---|
| 10.22.22.11 | 2359 |
| 10.22.22.12 | 2360 |
| 10.22.22.13 | 2357 |
| 10.22.22.14 | 2359 |
| 10.22.22.15 | 2359 |
| 10.22.22.16 | 2359 |
| 10.22.22.17 | 2358 |
| 10.22.22.18 | 2359 |
| 10.22.22.19 | 2361 |
| 10.22.22.20 | 2360 |
| 表 ロードバランサの負荷分散結果 | |
テスターが多数のWebクライアントを疑似し、同時に同じページを見にいくテストシナリオを準備した。そのクライアントからのWebリクエストを同じくテスターが疑似している10台のサーバに対してリクエスト処理を振り分けているロードバランサの負荷分散結果が上の表だ。
この結果を見ると全てのサーバに対してクライアントからのWebリクエストが均等に振り分けられている(ラウンドロビン)ことが結果から読み取れる。
サーバスペックが同じ場合はこの分散で正しいが、サーバスペックが異なる場合はこの分散結果が正しい(期待通りの)分散結果かどうか、テストリポートから確認することができる。
次回はファイアウォールにフォーカスしてベンチマークテストリポートの読み方をお伝えする。
執筆者紹介
中村彰宏 (なかむら あきひろ) 株式会社東陽テクニカ
検証用測定器のセールス、サポートを通じて測定の個別コンサルティング(プロフェッショナルサービス)を展開中。近年はIT機器ベンチマークテストサービス「@benchmark」を立ち上げパステルネットワークスと共同で運営。会員(有料)に対してベンチマークテストの実施、テストリポートの公開、技術情報の公開(リポートの活用方法、検証に関する技術情報)、コミュニティー(情報交換の場)といったサービスを提供している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
技術文書・技術解説
[SAS Institute Japan株式会社] 生成AIを予知保全に組み込むことで「産業設備保全」はどこまで進化できるのか -
市場調査・トレンド
[SAS Institute Japan株式会社] 製造企業が「AIによる価値創出」を迅速に実現する方法 -
技術文書・技術解説
[株式会社日立ソリューションズ] 開発と運用の分断を解消、実践知に基づくプラットフォームエンジニアリングとは -
事例
[株式会社日立ソリューションズ] 開発・運用の属人化をどう打破した? 日立ソリューションズの実践事例 -
技術文書・技術解説
[Eleven Labs Japan合同会社] 問い合わせ解決単価を約9割削減する試算も 音声AIエージェントのROIと活用例
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜMicrosoftは「Rust」を標準言語に? AIで進むC/C++書き換えの課題
-
2
なぜ「WSUS」を捨てない? 非推奨でも35%が使い続けるワケ
-
3
Microsoft 365統一で「SharePoint」が1日2TB増 富士フイルムはどう管理した?
-
4
なぜ「Claude Code」拡張は消しても危ないのか? Cursorで不正版配信
-
5
8割がアナログに逆戻りする“やっぱりな理由” DXを阻む2つの落とし穴
-
6
停滞する製造業のDX、開発の生産性を高める可視化の実践方法
-
7
Web攻撃を受ける企業に共通するセキュリティ対策の誤り
-
8
IT人材不足は言い訳だ 採用を妨げる元凶は「スパゲティ状態」のシステム
-
9
ログインの「3回に1回は高リスク」 MFAだけでは防げない「正規認証」の悪用
-
10
脱VMwareの真実:データセンター大手がNutanixを選んだ「コスト以上の理由」
ホワイトペーパーランキング PR
-
1
「IT史に名を残すシステム障害」8選
-
2
AIが苦手な「汚いデータ」になっていない? AI投資を無駄にしないための注意点
-
3
急増する高度なフィッシング詐欺 先回りしてブロックするには何が必要?
-
4
法人向け光回線のプランはどう選ぶ? 機能面/保守体制/コストを一覧で比較
-
5
「テスト内製化&自動化」事例集:ディー・エヌ・エーなど9社に学ぶ実践のコツ
-
6
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
7
有識者が語る、中堅中小企業に求められる最新のサイバーセキュリティ対策とは
-
8
10G回線の真価をフルに享受するには? 導入前にチェックしたいポイント
-
9
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
10
進化が遅れる「電話」をアップデート、AIを搭載した次世代の通話機能とは?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー