サービスプロバイダー規模におけるインフラ効率化の意味

Shoaib Yusufプリンシパルプロダクトマーケティングマネージャー | F5

サービスプロバイダーは、従来からネットワークパフォーマンスを綿密に測定してきました。スループットとレイテンシーは今も重要ですが、それだけでは、そのパフォーマンスを実現するために必要なインフラストラクチャの規模を運用担当者が把握することはできません。

CPUとメモリの消費量は、サーバー要件、ワークロード密度、電力、冷却、および他のサービスに割り当て可能な残りのキャパシティに影響します。Kubernetes環境へ移行するネットワーク機能が増えるにつれ、これらの要素はますます重要になります。

F5は、The Tolly Groupに委託し、F5 BIG-IP Cloud-Native Editionのインフラストラクチャ効率とパフォーマンスを、テスト対象の仮想ネットワーク機能（VNF）デプロイメントと比較して独立評価しました。両者はRed Hat OpenShift環境で、サービスプロバイダーの代表的な2つのワークロード、すなわちDNSクエリ処理と、レイヤー4およびキャリアグレードNAT（L4+CGNAT）を使用して評価されました。

Tollyは、スループットとレイテンシに加え、CPUとメモリの消費量を測定しました。その目的は、各デプロイメントがどの程度の有用な処理を実行でき、そのためにどのようなインフラストラクチャリソースが必要かを把握することでした。

パフォーマンスを支えるインフラストラクチャを測定

テスト結果から、従来のパフォーマンス指標と併せてリソース消費量にも注目する価値があることがわかります。

Kubernetes環境では、クラスタのリソースポリシーによっては、未使用のCPUとメモリを、プラットフォームが他のワークロードをスケジュールするために利用できる状態にしておけます。そのため、リソース消費量を抑えることで、運用担当者は導入済みのインフラストラクチャをより柔軟に活用できます。

2つのTollyワークロードは異なるパフォーマンス特性を示しましたが、テスト対象の構成では、いずれもBIG-IP Cloud-Native EditionのCPU要件が大幅に削減されました。

DNS：より少ないCPUでスループットを向上

DNSは、比較的小規模なトランザクションを大量かつ迅速に処理する必要がある、大量トラフィックを扱うサービスです。TollyのDNSテストでは、BIG-IP内のDNS Express機能を使用し、持続的なクエリスループット、CPU使用量、メモリ効率、平均レイテンシを測定しました。

BIG-IP Cloud-Native Editionは、テスト対象のVNFが1秒あたり34,463件だったのに対し、1秒あたり64,985件のDNSクエリを継続的に処理しました。これは、約1.9倍のDNSクエリスループットに相当します。

CPU要件にも大きな差がありました。BIG-IP Cloud-Native Editionの消費量は341 mCoresだったのに対し、VNFは4,003 mCoresを消費し、テストに割り当てられた4コアのCPUリソースをほぼすべて使用しました。したがって、テスト対象の構成では、CNEのCPU使用量は91.5%少ない結果となりました。

平均DNSレイテンシは、VNFの2.82ミリ秒に対してCNEでは1.47ミリ秒となり、48%短縮されました。

Tollyは、メモリ消費量に対するDNSパフォーマンスの正規化も行いました。BIG-IP Cloud-Native Editionは、メモリ1 GBあたり毎秒515,759クエリを処理し、VNFの4,194クエリと比較して、このテストではメモリ1 GBあたりのDNSクエリ数が123倍となりました。

テスト対象の構成では、F5 BIG-IP Cloud-Native EditionはCPU使用量を91.5%削減し、平均レイテンシを48%短縮しながら、約1.9倍高いDNSスループットを実現しました。

大規模なDNSサービスを運用する担当者にとって、実務上の検討事項は、所定のワークロードを支えるために必要なインフラストラクチャの規模です。CPUとメモリの要件が低ければ、Kubernetes環境内で追加サービスや将来の拡張に利用できる容量をより多く確保できます。

L4+CGNAT：同等のスループットを、より少ないリソースで

L4+CGNATテストでは、異なる結果が得られました。

どちらのデプロイメントも、約3 Gbpsのスループットを実現しました。BIG-IP Cloud-Native Editionは3,064 Mbpsを維持したのに対し、テスト対象のVNFは3,177 Mbpsを維持し、VNFの結果が約3.7%上回りました。

インフラストラクチャのリソース消費量には、さらに大きな差がありました。

BIG-IP Cloud-Native Editionの使用量は812 mCoreで、VNFの4,000 mCoreと比較して、CPU消費量が79.7%少ない結果となりました。

メモリ消費量は、BIG-IP Cloud-Native Editionが129 MiB、VNFが8,396 MiBで、テスト対象の構成では98.5%削減されました。

Tollyはp95レイテンシも測定し、VNFの26ミリ秒に対して、BIG-IP Cloud-Native Editionでは4.73ミリ秒となり、82%削減されました。

テスト環境では、スループットの差は3.7%以内に収まる一方、BIG-IP Cloud-Native EditionはCPUとメモリの使用量を大幅に抑え、p95レイテンシも低減しました。

F5 BIG-IP Cloud-Native Editionは、テスト対象の構成において、同等のL4+CGNATスループットを維持しながら、CPU使用量を79.7%、メモリ使用量を98.5%、p95レイテンシを82%削減しました。

リソース効率が重要な理由

サービスプロバイダー環境では、CPU、メモリ、電力、物理容量に限りがあるインフラストラクチャ全体で、大量のトラフィックを処理する必要が生じることがよくあります。

リソース効率は、クラスター内で実行できるワークロードの数、新しいサービスに利用できる残りのキャパシティ、需要の増加に伴って必要となるインフラストラクチャの規模に影響する可能性があります。

この点で、Tollyの結果が特に役立ちます。DNSとL4+CGNATは、独立したテストの対象として選定された2つの代表的なワークロードです。これらはBIG-IP Cloud-Native Editionで利用可能なすべての機能を代表するものではありませんが、Kubernetesネイティブのデプロイモデルによってネットワークサービスのリソースプロファイルがどのように変化し得るかを示す具体例となります。したがって、これらの調査結果は、他のBIG-IP Cloud-Native Editionサービスに関するパフォーマンス上の主張ではなく、テスト対象のワークロードと構成に関する結果として捉える必要があります。

この結果は、ネットワーク機能のアーキテクチャを評価する際に、運用担当者が検討すべき別の指標も示しています。スループットは引き続き重要ですが、CPU、メモリ、レイテンシを見ることで、そのスループットを実現するために必要なインフラリソースを把握できます。

Kubernetesベースのネットワークサービスを計画しているサービスプロバイダーは、その情報をキャパシティプランニング、ワークロード配置、インフラストラクチャ利用に関する意思決定に役立てることができます。

詳細については、Tolly Groupの完全版レポートをご覧ください。F5 BIG-IP Cloud-Native Editionのサービスプロバイダーインフラストラクチャ効率に関する独立した評価をご確認いただけます。また、ブログ「AIおよび5G/6G時代に向けたクラウドネイティブモダナイゼーション」もご覧ください。

著者について

Shoaib Yusufプリンシパルプロダクトマーケティングマネージャー | F5

Shoaib Yusufのその他のブログ記事