ADC パフォーマンス メトリックの理解

アプリケーション配信サービスは、アプリケーションの成功に不可欠です。 このようなサービスがスケーラビリティ、信頼性、またはセキュリティを追加するかどうかにかかわらず、ほとんどのアプリケーションは 1 つ以上のサービスに依存します。 したがって、アプリケーション配信コントローラ (ADC) は、ほとんどのアプリケーション、クラウド、およびデータ センターの設計において重要な位置を占めます。

プライベート クラウド インストールを含む多くの環境では、専用の ADC ハードウェアが依然としてアプリケーション配信サービスを提供するのに適したプラットフォームです。 これは、専用プラットフォームには、制御された安定した一貫性のあるリソースが組み込まれているためです。 専用の目的に合わせて構築されたアプライアンスは、ハイパーバイザー、ソフトウェア、または基盤となるコンピューティング プラットフォームに違いがないため、最も要求の厳しいアプリケーション ワークロードでも必要なパフォーマンスと信頼性を一貫して提供できます。さらに、CPU からタスクをオフロードするための特殊なハードウェア コンポーネントの利点もあります。

しかし、「パフォーマンス」とは実際には何を意味するのでしょうか? 一般的に、ADC ベンダーはパフォーマンスを示すために主に 4 種類のメトリックを公開しています。

• 1秒あたりのリクエスト数 (RPS)
• 1秒あたりの接続数 (CPS)
• 1秒あたりのトランザクション数 (TPS)
• スループット（通常はギガビット/秒（Gbps）で測定）

メーカーは、スループット、SSL トランザクション数、同時接続の表など、これらの特性やその他のプラットフォーム特性をリストした包括的なデータ シートを提供しています。 これらの数値とアプリケーションのワークロードとの関連性を解釈し、システムの制限やボトルネックの可能性を理解することは、適切なプラットフォームを選択するために不可欠です。 ベンダーのデータシートを解釈し、アプリケーションに関連する指標を理解することで、ビジネスに適したプラットフォームをより効果的に選択できるようになります。

アプリケーション配信コントローラは、アプリケーション プロキシとして機能するインフラストラクチャ コンポーネントであり、トラフィック管理、負荷分散、SSL 復号化、アプリケーション層セキュリティ、アプリケーションのアクセス制御などのアプリケーション配信サービスを提供します。 クライアント デバイスとサービスは ADC に接続し、ADC はアプリケーションへの別の接続を作成します (または既存の接続を再利用します)。 この論理ギャップに、ADC はアプリケーション配信サービスを挿入します。

ADC のワークロードを理解するには、TCP 接続とアプリケーション層の要求を調べると役立ちます。 ADC は、TCP スタックの複数のレイヤーでタスクを実行し、アプリケーション トラフィックにアプリケーション サービスを提供するためにさまざまなアクティビティを実行する必要があります。 （図1参照） これにより、ADC ベンダーからのパフォーマンス メトリックの解釈が困難になる可能性があります。 どのメトリックが関連しているかを理解するための重要な前提条件は、ワークロードの種類を識別することです。

アプリケーションにはさまざまな種類があり、したがって ADC ワークロードも多種多様です。 ほとんどの本番環境の展開にはさまざまなワークロードが混在していますが、各ワークロードの影響とニーズによって、ADC のどのコンポーネントが最も使用されるかが決まります。 コンポーネント内でも、ワークロードのニーズは異なります。 一部のワークロードはレイテンシの影響を受けやすく、他のワークロードはジッターの影響を受けやすく、また一部のワークロードはスループット制限の影響を受けやすく、また一部のワークロードは可用性に大きく依存します。

最も一般的なワークロードと、それらをサポートする主要なメトリックは次のとおりです。

• 現在、Web サイトや多くのモバイル アプリケーションで使用される最も一般的なワークロードは、多くの場合 SSL と TLS を使用するトランザクション HTTP Web アプリケーションです。 このワークロードにとって最も重要なメトリックは、すべての SSL メトリックです。 RPS、TPS、スループット、およびレイヤー 7 RPS と CPS。
• DNS は、ほぼすべてのインターネット エクスチェンジで使用されるもう 1 つの一般的なワークロードです。 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 になります。
• WebSocket テクノロジは比較的最近ワークロード タイプに追加されたもので、これによりサーバーは長時間持続するレイヤー 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 のパフォーマンスを評価し、それを特定の展開に適合させることは困難な場合があります。 ネットワークベンダーは、他のメトリックを犠牲にして特定のメトリックを最大化することを目的としたテストに基づくメトリックを公開します。 このアプローチの理由は、アーキテクチャと意思決定の指針となる使用可能な数値を公開することですが、ベンダーは公開された数値がすべて同時に当てはまるわけではないことを理解しています。 車の例えを使うと： トヨタは、2017 年型カムリのベースモデルが 178 馬力を発揮し、高速道路で 1 ガロンあたり 33 マイルの燃費を達成すると宣伝していますが、6,000 RPM でアクセルを床まで踏み込んだ状態で 178 馬力のフルパワーを発揮しながら、同時に 1 ガロンあたり 33 マイルの燃費を実現することを期待するのは無理があります。 同様に、ネットワークベンダーは、それぞれについて最良のシナリオを使用して個別のパフォーマンスメトリックを表示します。 原則として、公開されているパフォーマンス メトリックの多くは同時に再現できません。

公開されたメトリックの一部は、さまざまなレベルの処理に適用できます。 たとえば、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 ペイロードの長さがゼロのテストでは SSL TPS が最大になるため、SSL データの復号化に ADC 処理時間はかかりません。 SSL ハードウェアのパフォーマンスのみを判断するには妥当ですが、実稼働アプリケーションでは長さがゼロのペイロードは送信されません。 同様に、レイヤー 2 のスループットは、SSL を有効にせず、レイヤー 7 処理も行わずにテストされます。これは、これらの機能を使用すると ADC が遅くなるためです。ただし、多くの実稼働環境ではこれらの機能が使用されます。 ほとんどの ADC メトリックは個別にテストされますが、ほとんどの運用環境では ADC 機能の組み合わせが使用され、各メトリックは異なるコンポーネントまたはコンポーネントの組み合わせに負荷をかけます。 関係するコンポーネントには、CPU、ネットワーク インターフェイス カード (NIC)、特定用途向け集積回路 (ASIC)、フィールド プログラマブル ゲート アレイ (FPGA) などがあります。 ADC に特定のコンポーネントが欠けている場合は、代わりに CPU が使用されます。

パケット メトリックは、ADC が 1 秒あたりに処理できるパケット数を示し、この処理によって最も負荷がかかるコンポーネントはレイヤーによって異なります。 たとえば、レイヤー 2 パケットの処理では主にネットワーク インターフェイス カード (NIC) に負荷がかかり、レイヤー 4 パケットの処理では主に FPGA に負荷がかかります。 すべてのレイヤーのスループット メトリックは、ギガビット/秒単位で利用可能な合計スループットを示します。一方、接続メトリックは、特定のレイヤーで 1 秒あたりに確立できる接続数を測定します。 たとえば、レイヤー 4 接続メトリックは、1 秒あたりに確立できる TCP 接続の数を測定します。

SSL 処理は、接続全体にわたってセッションが確立され、管理されるという点で独特です。 1 つの接続で SSL セッション (トランザクションと呼ばれる) を確立でき、後続の接続では SSL セッション (リクエストと呼ばれる) を再利用できます。 したがって、トランザクション メトリックとリクエスト メトリックは別々にリストされます。 SSL トランザクションは後続の SSL リクエストよりも大幅に長くかかるため、スループット パフォーマンスの制限数値は多くの場合、トランザクション メトリックになります。 SSL セッションが確立され、後続のリクエストが行われると、データ ペイロードを暗号化または復号化する必要があります。 暗号化 ASIC は暗号化と復号化を処理し、パフォーマンスはスループット メトリックで測定されます。

多くの場合、データ ペイロードを圧縮すると便利です。 圧縮は圧縮 ASIC によって実行され、そのメトリックもスループットです。

最後に、レイヤー 7 は、複雑で多様なトラフィック管理オプションが利用可能であり、レイヤー 7 の処理はすべて CPU 経由で実行されるという点で独特です。 Cookie の永続性は、各ユーザー セッションをプール内の特定のサーバーに結び付け、CPU によって実行される一般的なレイヤー 7 機能です。 レイヤー 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 クッキーを含む、ルーティング機能のほか、ファイアウォールや分散型サービス拒否 (DDoS) 保護も提供できます。 このレベルで FPGA を使用すると、レイヤー 4 の処理と保護が可能になり、さらに処理する必要があるトラフィックが適切に組み立てられ、フィルタリングされることが保証されます。

SSL や TLS などの暗号化および圧縮処理、および HTTP/2 によって導入された新しい機能も、専用ハードウェアのもう 1 つの用途です。 多くの場合、楕円曲線 Diffie-Hellman 暗号化 (ECDHE) などの最新の暗号の計算集約型 SSL キーネゴシエーションを含む暗号化処理には、専用の ASIC が使用されます。 SSL キーのネゴシエーションが行われると、後続のリクエストの一括暗号化と復号化も ASIC ハードウェアによって処理できるようになります。 同様に、一般的なアルゴリズムを使用した圧縮と解凍も ASIC ハードウェアで実行できます。 専用の ASIC コンポーネントを使用することで、暗号化と圧縮を高速に処理できます。

ASIC および FPGA で処理されないネットワーク トラフィックの残りの処理は、CPU で処理する必要があります。 CPU は ASIC や FPGA に比べると低速ですが、ADC の中で最も柔軟性の高いコンポーネントです。CPU には、GUI やその他の構成作業、I/O 割り込みの処理、ディスク要求の処理など、ネットワーク処理とは関係のないタスクも割り当てられています。 CPU に対する要求はレイテンシによって変化する可能性があり、CPU はネットワーク トラフィックを処理する最後のハードウェア タイプであるため、ADC は意図的に CPU へのトラフィック処理をできるだけ少なくし、代わりにより高速な ASIC と FPGA でできるだけ多くの処理を実行するように設計されています。

ベンダーが公開した指標を実際のパフォーマンスに変換するのは難しい場合があります。 さまざまな種類のワークロード、それらが消費するリソース、ハードウェア プラットフォームの機能間の相互作用を理解することは、複雑ではありますが、組織にとって最適な購入決定を行うのに役立ちます。

公開されているデータシートやその他のリソースは、適切なプラットフォームの指定を容易にするのに役立ちますが、可能な限りベンダーの経験と専門知識に直接頼ることも重要です。 大手ベンダーは、ワークロードをプラットフォームに適合させる深い専門知識を持っており、その専門知識は顧客がすぐに利用できる必要があります。

アプリケーション トラフィックの特性とプラットフォームの機能に関する十分な理解とベンダーの専門知識を組み合わせることで、プラットフォームのプロビジョニング不足または過剰によるリスクと潜在的な費用が軽減されます。