ADCのパフォーマンス指標を理解する
はじめに
アプリケーションを成功に導くには、アプリケーションデリバリサービスが不可欠です。スケーラビリティ、信頼性、セキュリティのいずれを向上させるサービスであっても、ほとんどのアプリケーションは1つ以上のサービスに依存しています。そのため、アプリケーションデリバリコントローラー（ADC）は、ほとんどのアプリケーション、クラウド、データセンターの設計において重要な役割を担っています。
プライベートクラウド環境を含む多くの環境では、アプリケーションデリバリサービスを提供するプラットフォームとして、現在も専用ADCハードウェアが選ばれています。これは、専用プラットフォームでは、管理された安定性と一貫性のあるリソースを利用できるためです。専用に設計されたアプライアンスでは、ハイパーバイザー、ソフトウェア、基盤となるコンピューティングプラットフォームにばらつきがなく、さらに専用ハードウェアコンポーネントによってCPUから処理をオフロードできるため、極めて要求の厳しいアプリケーションワークロードに必要なパフォーマンスと信頼性を一貫して提供できます。
では、「パフォーマンス」とは実際には何を意味するのでしょうか。一般に、ADCベンダーはパフォーマンスを示すために、主に4種類の指標を公開しています。
- 1秒あたりのリクエスト数（RPS）
- 1秒あたりの接続数（CPS）
- 1秒あたりのトランザクション数（TPS）
- スループット（多くの場合、ギガビット毎秒（Gbps）で測定）
メーカーは、スループット、SSLトランザクション数、同時接続数の表など、これらをはじめとするプラットフォーム特性を網羅したデータシートを提供しています。適切なプラットフォームを選択するには、これらの数値とアプリケーションワークロードとの関連性を読み解き、システムで想定される制限やボトルネックを把握することが不可欠です。ベンダーのデータシートを読み解き、アプリケーションに関連する指標を理解することで、ビジネスに適したプラットフォームをより効果的に選択できるようになります。
ADCの役割
Application Delivery Controllerは、アプリケーションプロキシとして機能するインフラストラクチャコンポーネントであり、トラフィック管理、負荷分散、SSL復号、アプリケーションレイヤーセキュリティ、アプリケーションのアクセス制御などのアプリケーションデリバリサービスを提供します。クライアントデバイスやサービスがADCに接続すると、ADCはアプリケーションへの接続を別途確立します（または既存の接続を再利用します）。ADCは、この論理的な接続の間にアプリケーションデリバリサービスを挿入します。
ADCのワークロードを理解するには、TCP接続とアプリケーション層のリクエストに着目すると役立ちます。ADCは、アプリケーショントラフィックにアプリケーションサービスを提供するために、TCPスタックの複数の層でタスクを実行し、さまざまな処理を行う必要があります。（図1を参照）そのため、ADCベンダーが提示するパフォーマンス指標の解釈が難しくなる場合があります。どの指標が関連するかを理解するうえで重要な前提条件は、ワークロードの種類を特定することです。
アプリケーションには多くの種類があり、それに応じてADCのワークロードも多岐にわたります。ほとんどの本番環境には複数のワークロードが混在していますが、各ワークロードの影響と要件によって、ADCのどのコンポーネントが最も多く使用されるかが決まります。同じコンポーネントでも、ワークロードによって要件は異なります。レイテンシーの影響を受けやすいワークロードもあれば、ジッターの影響を受けやすいものもあります。また、スループットの上限に左右されるワークロードもあれば、可用性への依存度が高いものもあります。
最も一般的なワークロードと、それらを支える主要な指標は次のとおりです。
- 現在、最も一般的なワークロードは、Webサイトや多くのモバイルアプリケーションで使用されるトランザクション型HTTP Webアプリケーションであり、多くの場合SSLとTLSが使用されます。このワークロードで最も重要な指標は、RPS、TPS、スループットといったすべてのSSL指標に加え、レイヤー7のRPSとCPSです。
- DNSも、ほぼすべてのインターネット通信で使用される一般的なワークロードです。DNSは頻繁に使用されますが、トラフィック量は少なく、通常はTCPではなくUDPを使用して導入されます。そのため、最も重要な指標はレイヤー3およびレイヤー4のスループットです。
- REST APIの利用は急速に拡大しており、サービスで一般的に使用されるAPIトランスポートを指します。そのため、REST APIはマシン間通信でよく使用されます。REST APIはHTTPをベースとしているため、主要な指標はHTTPと同じで、SSLに関するすべての指標（RPS、TPS、スループット）に加え、レイヤー7のRPSとCPSです。
- MQTTは、さまざまな用途に利用され、モノのインターネット（IoT）通信で急速に普及している新しいメッセージングプロトコルです。REST APIと同様に、MQTTは主にマシン間通信のアプリケーションで使用されます。MQTTの主要な指標は、レイヤー4のCPSとスループットです。
- Diameterは、レイヤー4で動作し、TCP接続を長時間維持する、RADIUS認証プロトコルの後継プロトコルです。主な指標は、レイヤー4のCPSとレイヤー4接続テーブルの堅牢性です。
- FIX、SAIL、OUCHなどの金融取引プロトコルは、レイヤー4とレイヤー7の両方でレイテンシーの影響を受けやすいため、主要な指標はレイヤー4のCPSに加え、レイヤー7のRPSとCPSです。
- WebSocketsテクノロジーは、比較的新しいワークロードタイプです。長時間維持されるレイヤー4およびレイヤー7接続を介して、サーバーからクライアントとの通信を開始できます。主な指標は、レイヤー4のCPS、レイヤー7のRPSとCPS、およびレイヤー4とレイヤー7の接続テーブルの堅牢性です。
- ロギングおよびアラートのワークロードはすべてレイヤー4で動作し、一部はレイヤー7で動作するREST APIを使用します。そのため、主要な指標はレイヤー4のCPSであり、REST APIを使用するワークロードではレイヤー7のRPSとCPSも主要な指標となります。
ワークロードの組み合わせは進化し続け、新たなワークロードも絶えず導入されています。それぞれのワークロードには、その主要な処理に応じた重要なADC指標があります。
パフォーマンス指標とその解釈方法
あらゆるネットワークデバイスのスループットは、ネットワークトラフィックの処理によって生じる遅延、すなわちレイテンシーに左右されます。少なくとも、銅線を伝わる電気信号や光ファイバーを通過する光信号には、光速による最小限のレイテンシーが生じます。しかし、ADCは有線または光ファイバー経由でデータを転送するだけでなく、ネットワークトラフィックに対して複数の処理を実行します。ADCの最大処理能力は、並列ではなく直列に実行される各処理のレイテンシーの合計によって決まります。多くの処理は並列に実行されますが、それらに要する時間は依然として全体のスループットを制約します。ADCの設計では、こうしたレイテンシーを最小限に抑え、スループットを最大化することが目標の1つです。
特定のADCの性能を評価し、特定の導入環境に適合させようとするのは容易ではありません。ネットワークベンダーは、他の指標を犠牲にして特定の指標を最大化することを目的としたテストに基づき、性能指標を公表しています。この手法を採用するのは、アーキテクチャの設計や意思決定の指針となる実用的な数値を示すためですが、ベンダーは、公表したすべての数値が同時に成立するわけではないことを認識しています。自動車に例えると、Toyotaは2017年型Camryのベースモデルについて、178馬力を発揮し、高速道路では1ガロン当たり33マイルの燃費を達成すると宣伝しています。しかし、アクセルを床まで踏み込み、6,000 RPMで最大の178馬力を発揮しながら、同時に1ガロン当たり33マイルの燃費を実現できると期待するのは現実的ではありません。同様に、ネットワークベンダーは、各性能指標についてそれぞれ最良の条件を用いて個別に示しています。一般に、公表されている性能指標の多くは、同時に再現することができません。
メトリクスとOSIレイヤーの関係
公開されている指標の中には、異なる処理レベルに適用できるものがあります。たとえば、1秒あたりのリクエスト数は、OSIレイヤー2（L2）またはOSIレイヤー7（L7）の処理性能を示す場合があります。一方、TPSはSSL鍵ネゴシエーションのみを指すことが多いのに対し、レイヤー7の1秒あたりのリクエスト数は、確立済みのSSLセッションを使用する後続の暗号化リクエストを指します。ワークロードが異なれば、各種ADC処理コンポーネントにかかる負荷も異なります。ADCの公開指標についてもう1つ重要なのは、ワークロードによって直面するパフォーマンス上の限界が異なるという点です。
OSIネットワークの各レイヤーには、そのレイヤーについて一般的に公表される複数の指標があります。たとえば、レイヤー4の指標は1秒あたりの接続数で示されることが多く、レイヤー4のスループットを示す指標もあります。OSIレイヤー5と6はIPスタックに直接対応するものではありませんが、SSL/TLSや圧縮などのサービスはレイヤー5および6に相当すると考えることができます。前述のとおり、これらの各指標のテストは、その指標に負荷をかけるよう設計されたトラフィックを使用して実施されることが多く、実環境のトラフィック負荷を表すものではありません。たとえば、SSLデータの復号にADCの処理時間が費やされないよう、長さがゼロのSSLペイロードを使用してテストすると、SSL TPSは最大値になります。これはSSLハードウェアのみの性能を測定するには妥当ですが、本番アプリケーションで長さがゼロのペイロードが送信されることはありません。同様に、SSLやレイヤー7処理を有効にするとADCの処理速度が低下するため、レイヤー2のスループットは、SSLを無効にし、レイヤー7処理を行わない状態でテストされます。しかし、多くの本番環境ではこれらの機能が使用されます。ADCの指標の多くは個別にテストされますが、ほとんどの本番環境では複数のADC機能を組み合わせて使用しており、各指標はそれぞれ異なるコンポーネントまたはコンポーネントの組み合わせに負荷をかけます。関連するコンポーネントには、CPU、ネットワークインターフェイスカード（NIC）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）などがあります。ADCに特定のコンポーネントが搭載されていない場合は、代わりにCPUが使用されます。
パケットメトリックは、ADCが1秒あたりに処理できるパケット数を示します。この処理によって最も負荷がかかるコンポーネントは、レイヤーによって異なります。たとえば、レイヤー2パケットの処理では主にネットワークインターフェイスカード（NIC）に負荷がかかる一方、レイヤー4パケットの処理では主にFPGAに負荷がかかります。すべてのレイヤーのスループットメトリックは、1秒あたりのギガビット数で表した利用可能な総スループットを示します。一方、接続メトリックは、該当するレイヤーで1秒あたりに確立できる接続数を測定します。たとえば、レイヤー4の接続メトリックは、1秒あたりに確立できるTCP接続数を測定します。
SSL処理メトリクス
SSL処理には、複数の接続にまたがってセッションが確立、管理されるという特性があります。1つの接続でSSLセッションを確立できます。これはトランザクションと呼ばれます。一方、後続の接続ではSSLセッションを再利用できます。これはリクエストと呼ばれます。そのため、トランザクションとリクエストのメトリクスは個別に記載されています。SSLトランザクションは後続のSSLリクエストよりもはるかに時間がかかるため、スループット性能の制約要因となる数値は、多くの場合トランザクションのメトリクスです。SSLセッションが確立され、後続のリクエストが行われると、データペイロードを暗号化または復号する必要があります。暗号化と復号は暗号化ASICが処理し、その性能はスループットのメトリクスで測定されます。
多くの場合、データペイロードを圧縮すると効果的です。圧縮は圧縮ASICによって処理され、その性能もスループットで測定されます。
アプリケーション層の処理
最後に、レイヤー7では複雑かつ多様なトラフィック管理オプションを利用できるため、すべての処理をCPUで実行するという点が特徴です。Cookieパーシステンスは、各ユーザーセッションをプール内の特定のサーバーに関連付ける一般的なレイヤー7機能であり、CPUによって処理されます。レイヤー7リクエストの指標は、ADCが1秒あたりに処理できるレイヤー7リクエスト数を示します。同様に、レイヤー7スループットの指標は、レイヤー7で実現可能な総スループットを示します。
最後に、接続状態を保持する必要があるレイヤーでは、ADCが接続テーブルを維持する必要があります。接続テーブルは、レイヤー4のTCP接続、SSLセッション、レイヤー7のHTTPセッションで一般的に使用されます。接続が長時間継続するプロトコルでは、ADCの接続テーブルが枯渇したり、負荷がかかったりする可能性があります。
各指標は、パフォーマンスの特定の側面を把握するのに役立ちます。各レイヤーで実行されるさまざまな処理と、それらの処理によって影響を受けるコンポーネントを理解することで、特定の導入環境におけるADCのパフォーマンス指標を評価しやすくなります。
専用ハードウェアとパフォーマンス
ADCのあらゆる機能はCPUで実現できます。実際、多くのADCハードウェアベンダーがソフトウェアのみのバージョンを提供しています。これは、CPUが利用可能なハードウェアの中で最も柔軟性が高く、データを中心とするほぼあらゆるタスクを実行できるためです。
しかし、ADCのすべての機能をCPUに委ねることには限界があります。ネットワークトラフィックを処理する主要な3種類のハードウェア（CPU、ASIC、FPGA）のうち、CPUは最も低速であり、メモリとメモリコントローラーによる支援が必要なため、おそらく最も高コストです。ネットワークトラフィックを処理する残りの2種類のハードウェアは、ASICとFPGAです。ASICは、その名のとおり、特定のタスクを実行するように設計されています。特定のタスクの実行においてASICより高速なハードウェアはありませんが、その機能はチップに組み込まれた設計の範囲に限られます。アプリケーションがASICでは提供できない機能を必要とする場合は、代わりにCPUを使用し、ソフトウェアでそのタスクを実行する必要があります。
CPUが柔軟性に優れる一方で低速、ASICが柔軟性に欠ける一方で高速だとすれば、その中間に位置する第3のテクノロジーがFPGAです。FPGAはASICより低速ですが、CPUよりはるかに高速であり、FPGAの設計者が想定していなかったタスクを実行するようプログラムできます。
適切に設計されたADCは、各ハードウェアの能力を最大限に活用します。一般的で単純なタスクはASICコンポーネントに割り当て、より複雑なタスクはFPGAコンポーネントで実行し、最も複雑で発生頻度の低いタスクはCPUで処理します。ADCの優れたエンジニアリングの多くは、さまざまなワークロードを最も効率的に処理できるよう、異なる種類のコンポーネントを連携させることで実現されています。
ADCで実行されるタスクのうち、圧倒的に頻度が高いのは、ネットワークインターフェースでのパケット処理です。標準的な市販のNICは、大量の受信トラフィック向け（デスクトップやその他のユーザーデバイスなど）、または大量の送信トラフィック向け（サーバーなど）のいずれかに最適化されています。ADCには、双方向で最大のスループットを実現するように最適化されたNICが必要であるという特有の要件があります。双方向で最大のスループットを実現するように設計された市販のNICはありません。ADCのパケット処理は頻繁に実行される比較的単純なタスクであるため、ASICでの処理に適しています。クラスタ化されたADC環境では、ディスアグリゲーター（DAG）ASICがフロントエンドのロードバランサーとして機能し、同じクライアントセッションとサーバーセッションが常に同じクラスタノードを経由するようにします。クラスタ環境でDAGを使用すると、トラフィック需要に対応するためのADCアプライアンスの水平スケーリングが容易になります。適切に設計されたADCでは、レイヤー2のパケット処理とスイッチングをすべて専用のASICハードウェアで実行できます。
レイヤー3および4の処理タスクはより複雑であるため、FPGAでの処理に適しています。FPGAは、ルーティング機能に加え、TCP SYN Cookieを含むファイアウォール機能や分散型サービス拒否（DDoS）攻撃に対する保護機能を提供できます。このレベルでFPGAを使用すると、レイヤー4の処理と保護が可能になり、後続の処理対象となるトラフィックが適切に再構成およびフィルタリングされます。
SSLやTLSなどの暗号化および圧縮処理や、HTTP/2で導入された新機能も、専用ハードウェアの用途の1つです。暗号処理には、楕円曲線ディフィー・ヘルマン鍵共有（ECDHE）などの最新暗号方式で計算負荷の高いSSL鍵ネゴシエーションを含め、専用ASICがよく使用されます。SSL鍵ネゴシエーションが完了すると、後続リクエストの一括暗号化および復号もASICハードウェアで処理できます。同様に、一般的なアルゴリズムを使用した圧縮および展開もASICハードウェアで実行できます。専用ASICコンポーネントを使用することで、暗号化および圧縮を高速に処理できます。
ASICやFPGAで処理されない残りのネットワークトラフィックは、すべてCPUで処理する必要があります。CPUはASICやFPGAと比べると低速ですが、ADC内で最も柔軟性の高いコンポーネントです。また、GUIやその他の設定処理、I/O割り込みへの対応、さらにはディスク要求の処理など、ネットワーク処理以外のタスクも担います。CPUの処理負荷はレイテンシーによって変動する可能性があり、さらにCPUはネットワークトラフィックを処理する最後のハードウェアであるため、ADCはCPUに振り分けるトラフィック処理を可能な限り抑え、より高速なASICやFPGAでできるだけ多く処理するよう意図的に設計されています。
まとめ
ベンダーが公表している指標から、実環境でのパフォーマンスを判断するのは容易ではありません。さまざまな種類のワークロード、それらが消費するリソース、ハードウェアプラットフォームの機能がどのように相互に影響するかを理解することは複雑ですが、組織に最適な購入判断を下すうえで役立ちます。
公開されているデータシートなどの資料は、適切なプラットフォームを選定するうえで役立ちますが、可能な限りベンダーの経験と専門知識を直接活用することも重要です。主要なベンダーは、ワークロードに適したプラットフォームを選定するための高度な専門知識を備えており、お客さまはその知見を容易に活用できる必要があります。
アプリケーショントラフィックの特性とプラットフォームの機能を十分に理解し、ベンダーの専門知識を活用することで、プラットフォームのプロビジョニングが過小または過剰になるリスクと、それに伴う潜在的なコストを低減できます。
2017年3月28日公開