ベンチマークテストでうまくいくネットワーク機器選び【第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
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー