IPU がマイクロサービス・ベースのアプリケーションのネットワーク・レイテンシーを改善

マイクロサービスとは

マイクロサービスとは、大規模なアプリケーションを小規模で独立した疎結合のサービスに分割する最新のソフトウェア開発アプローチを指します。Amazon、eBay、Netflix、Twitterなどの有名企業を含むクラウドサービスプロバイダーは、アプリケーションを従来のモノリシックソフトウェアシステムとして実装するのではなく、従来のモノリシック設計ではなくマイクロサービスとして実装することが増えています。

マイクロサービスには次のような利点があります。

• スケーラビリティ: マイクロサービスでは、個々のサービスを互いに独立してスケーリングできるため、スケーラビリティが向上します。つまり、開発者は、アプリケーションの他の部分に影響を与えることなく、必要なサービスのみをスケールアップまたはスケールダウンできます。

• 柔軟性: マイクロサービスを使用すると、アプリケーション全体に影響を与えることなく個々のサービスを更新できるため、システムへの変更が容易になります。これにより、新しいテクノロジーの採用、さまざまなプログラミング言語の実験、新機能のテストが容易になります。

• 障害の分離: 各マイクロサービスは独立したコンポーネントであるため、1 つのサービスに障害が発生しても、アプリケーションの他の部分には影響しません。これは、開発者がシステム全体に影響を与えることなく、問題を迅速に特定して修正できることを意味します。

• 開発速度の向上: マイクロサービスにより、小規模で集中的な開発チームが特定のサービスで独立して作業できます。これにより、開発プロセスがスピードアップし、大規模で複雑なシステムの管理が容易になります。

• フォールト トレランスの向上: マイクロサービスを使用すると、各サービスがエラーを個別に処理するように設計できるため、フォールト トレラント システムの構築が容易になります。つまり、システム全体の回復力が高まり、障害が発生する可能性は低くなります。

• テストの改善: 各マイクロサービスは独立しているため、個々のサービスを簡単にテストできます。つまり、開発者はサービスを分離してテストできるため、バグの検出と修正が容易になります。

マイクロサービスベースのソフトウェアアーキテクチャには重要な利点がありますが、ネットワークのオーバーヘッドが大きいため、ネットワーク遅延などのパラメーターがアプリケーション全体のパフォーマンスとデータセンターのコストに大きな影響を与えます。Napatech の仮想化データプレーン・ソフトウェアを実行する インテル FPGA インフラストラクチャー・プロセシング・ユニット (IPU) を活用することで、サービス・プロバイダーはネットワーク・インフラストラクチャーのパフォーマンスを最大化し、データセンター全体の設備投資と運用費を最小限に抑えながら、他の方法では達成できなかったレベルのパフォーマンスを実現できます。

マイクロサービスのネットワーキングの課題

マイクロサービス アーキテクチャでは、コンテナーまたは仮想マシン (VM) に実装された仮想化サービスが仮想化ネットワークを介して相互に通信するため、ネットワーク待機時間が大きな課題となります。たとえば、マイクロサービスは頻繁に相互に通信するため、大量のネットワーク トラフィックが発生する可能性があります。このネットワーク トラフィックの増加は、ネットワークの輻輳と待機時間の増加につながり、システムのパフォーマンスに悪影響を与える可能性があります。同様に、マイクロサービス アーキテクチャでは、多くの場合、サービスはタスクを完了するために他のサービスを呼び出す必要があり、各ネットワーク呼び出しによってシステムに待機時間が追加されます。サービスの数とシステムの複雑さが増すにつれて、ネットワーク呼び出しの数も増加し、遅延の大きな課題につながる可能性があります。最後に、マイクロサービスが異なれば、通信に使用するネットワーク プロトコルも異なります。たとえば、あるサービスは REST (再プレゼンテーション状態転送) を使用し、別のサービスは gRPC (Google リモート プロシージャ コール) を使用する場合があります。異なるネットワークプロトコル間で変換すると、システムに遅延が増加する可能性があります。

従来、仮想化されたデータプレーンは完全にソフトウェアに実装され、そのコンピューティングサイクルの多くは、VM間のネットワークトラフィックをルーティングする仮想スイッチ(vSwitch)の実行によって消費されます。各 vSwitch 操作にはかなりの数の CPU サイクルが必要になるため、このアーキテクチャでは、システムに許容できない遅延が発生し、システムが必要な全体的なパフォーマンスまたはスループットを達成できなくなる可能性もあります。同時に、仮想データプレーンの実行で使用率の高い CPU では、アプリケーションやサービスの実行に利用できるコアが少なくなるため、データセンターのワークロードをサポートするために必要なサーバー数が増え、CAPEX と OPEX の両方が増加します。図 1 を参照してください。

インテル® FPGA IPUベース・アーキテクチャーの活用

より効率的でコスト効率の高いシステムレベルのアーキテクチャでは、インテル FPGA IPUを活用してサーバーのCPUからvSwitchをオフロードし、サーバーのCPUを解放してアプリケーションやサービスを実行します。

データセンター・サーバーの標準ネットワーク・インターフェイス・カード (NIC) に代わる IPU は、vSwitch をハードウェアに実装し、プログラマブル・FPGA (フィールド・プログラマブル・ゲート・アレイ) を使用して、コントロール・プレーンを実行する汎用 CPU と組み合わせてデータプレーンを実行します。vSwitch は、業界標準の API (アプリケーション プログラミング インターフェイス) を VM に提供し、このアーキテクチャを利用するときに VM 自体を変更する必要がないようにします。図 2 を参照してください。

IPU ベースのアーキテクチャーは、マイクロサービスベースのアプリケーションを実行するデータセンターに、次の 3 つの主な利点を提供します。

• 超低レイテンシーにより、マイクロサービス間の遅延トラフィックが最小限に抑えられます。

• システムとアプリケーションの全体的なスループットを最大化する高性能。

• vSwitch データプレーンが消費するサーバー CPU コアがなく、サーバーの CPU 使用率を最適化します。これにより、ワークロード全体に必要なサーバーの総数が最小限に抑えられ、データセンターの設備投資と運用費も最小限に抑えられます。

MIT 分析

マサチューセッツ工科大学 (MIT) は、実際のシナリオにおける vSwitch オフロードのメリットを定量化するために、2 つのマイクロサービスベースのユースケースのパフォーマンスを分析し、従来のソフトウェアベースの vSwitch を使用した結果と、SmartNIC および IPU ソリューションの大手プロバイダーである Napatech の仮想化データプレーン・ソフトウェアを稼働インテル IPUを使用して得られた結果を比較しました。これら 2 つのユース ケースは、複数の層にわたるデータ転送にメッセージ パッシングを使用するパブリッシュ/サブスクライブ "pub-sub" アプリケーションと、Web サーバー、メモリ内キャッシュ、およびバックエンド データベースで構成される 3 層 TCP アプリケーションでした。このベンチマーク・イニシアチブの結果は、 MIT が発行 した論文「Microservice Benchmarking on Intel IPU running Napatech Software」

Pub-Sub アプリケーションのパフォーマンス分析

"パブリッシュ/サブスクライブ アプリケーション" の略である pub-sub アプリケーションは、さまざまなコンポーネントまたはサービス間の通信と調整を容易にするために分散システムで一般的に使用されるメッセージング パターンです。pub-sub パターンを使用すると、メッセージの送信者 (パブリッシャーと呼ばれる) がサブスクライバーと呼ばれる特定の受信者を知る必要がない非同期および分離された通信が可能になります。Pub-sub アプリケーションは、次のようなユースケースに適用できます。

• フロアプランを作成し、それに座席を割り当ててから、ライブ座席予約イベントを管理する座席予約システムクライアントがチケットを購入すると、pub-subシステムはどこでもリアルタイムでフロアプランを更新し、分散キャッシュシステムの同期を維持します。クライアントは、閲覧/ショッピング段階にある間に誰かがそれを購入したことを知るためだけに座席を要求することは決してありません。

• 信頼性の低い Wi-Fi や予測できない携帯ネットワークなどの問題が発生することが多いウェブベースのアプリを介して、学生が教室に参加できるようにする教育ツールです pub-subシステムは、ネットワークに再参加したときに接続を回復し、オンライン参加者数の急激な変化を処理できます。

• 組織内の加入者への株価、市場指数、取引データ、注文書の更新などの市場データの配布などの金融アプリケーション

• モノのインターネット (IoT) システム: pub-sub は多数の IoT デバイス間の通信を容易にし、効率的なデータ配布を可能にします。センサーがデータを公開すると、サブスクライバーはそのデータをリアルタイムで受信して処理できます。

、開発者が多様な言語と開発者フレームワークをサポートしながら、クラウドとエッジの両方で実行される回復性があり、ステートレスでステートフルなアプリケーションを構築できるポータブルなイベント ドリブン ランタイムである、Daprのパブリッシュ サブ通信モデルで開発された 5 層チェーン トポロジを評価し ました。 各層は、出力をダウンストリーム層にブロードキャストする前に、ユーザーが指定した時間だけ CPU を集中的に使用する計算を実行します。図 3 を参照してください。

5 層の pub-sub アプリケーション内では、2 つの OVS 対応サーバーにサービスを配置することで、依存するサービスが異なる物理マシン上で実行されることが保証され、有効になっている場合、階層間のすべてのトラフィックが IPU を通過するようになります。

MIT は、IPU ベースのオフロードがある場合とない場合の両方で、pub-sub システムのパフォーマンスを分析し、毎秒数千クエリ (kQPS) で表されるさまざまな負荷にわたるメッセージング・レイテンシーを測定しました。図 4 を参照してください。

オフロードが無効で、末尾 (つまり最悪の場合) のレイテンシーを考慮すると、グラフの変曲点で示されているように、アプリケーションは 90kQPS で飽和状態を開始します。その負荷レベルを超えると、システムは要求に効率的に対応できなくなります。これはおそらく、TCP 再送信につながるパケットドロップが原因です。ただし、オフロードが有効になっている場合でも、システムは、このテストで使用される最大レートである 140kQPS の負荷で要求に対応しており、 IPU が許容可能なテール・レイテンシーを維持しながらスループットを 50% 向上させることを示しています。これにより、システム容量が大幅に向上し、サーバーの総コストとエネルギー消費量の両方で30〜40%節約されます。

3 層 TCP アプリケーションのパフォーマンス分析

3層TCP(伝送制御プロトコル)アプリケーションとは、アプリケーションを3つの論理層または層に分割し、それぞれが特定の機能を担当するソフトウェアアーキテクチャ設計を指します。これらの層は、通常、プレゼンテーション層、アプリケーション層、およびデータ層と呼ばれます。TCP プロトコルは、次の層間の通信に使用されます。

• プレゼンテーション層: ユーザー インターフェイス (UI) 層とも呼ばれるこのレイヤーは、アプリケーションの情報をユーザーに提示し、ユーザーの入力を受け取る役割を担います。Webページ、フォーム、デスクトップインターフェイスなどのグラフィカルユーザーインターフェイス(GUI)コンポーネントを扱います。プレゼンテーション層はアプリケーション層と通信し、必要に応じてデータを取得または更新します。

• アプリケーション層: アプリケーション層には、アプリケーションのビジネス ロジックと処理ロジックが含まれています。コア機能を処理し、データ検証、ビジネス ルールの適用、アプリケーション固有の操作などのタスクを実行します。この層は、プレゼンテーション層からの要求を処理し、データ層と通信してデータを取得または格納します。

• データ層: データ層 (データ アクセス層またはデータベース層とも呼ばれます) は、データの格納と取得の管理を担当します。データのクエリや更新など、データベースシステムとの対話を処理します。データ層は、アプリケーション層から要求を受け取り、要求されたデータを返すか、必要なデータ変更を実行します。

3 層 TCP アプリケーションでは、これらの層間の通信は TCP プロトコルを使用して容易になります。TCPは、層間のデータの信頼性の高い順序付けられた配信を保証し、接続指向のストリームベースの通信メカニズムを提供します。アプリケーションをこれら 3 つの層に分離することで、3 層の TCP アーキテクチャにより、アプリケーションのモジュール性、スケーラビリティ、および保守が容易になります。各層は個別に開発および拡張できるため、コンポーネントの柔軟性と再利用性が容易になります。

この分析のために、MITは、 フロントエンドWebサーバーとして NGINX メモリキャッシュ層として Memcached ストレージを備えたバックエンドデータベースとしてMongoDBクライアントは NGINX とやり取りし、キーと値のペアが Memcached にキャッシュされているかどうかを確認し、キャッシュされている場合はその値をクライアントに返します。そうでない場合、NGINXはMongoDBとインターフェースして出力をフェッチし、さらにMemcachedにキャッシュします。図 5 を参照してください。

MIT は、IPU ベースのオフロードがある場合とない場合の両方で、3 層 TCP アプリケーションのパフォーマンスを分析し、前の例と同様に、毎秒数千クエリ (kQPS) で表されるさまざまな負荷にわたるメッセージング待機時間を測定しました。図 6 を参照してください。

オフロードを無効にし、末尾 (つまり最悪の場合) のレイテンシーを考慮すると、グラフの変曲点で示されているように、アプリケーションは約 17kQPS で飽和状態を開始します。その負荷レベルを超えると、システムは要求に効率的に対応できなくなります。これはおそらく、TCP 再送信につながるパケットドロップが原因です。一方、オフロードが有効になっている場合、飽和状態は 26kQPS の負荷まで開始されません。これは、 IPU により、許容可能なテール・レイテンシーを維持しながらスループットを 53% 向上させることを示しています。前の例と同様に、これはシステム容量の大幅な改善を表しており、サーバーの総コストとエネルギー消費の両方で30〜40%節約されます。

システム構成

MITがマイクロサービスのベンチマークに使用したシステム構成は次のとおりです。

• 2 台の Inspur デュアルソケット・サーバーは、それぞれ 48MB キャッシュを備えた インテル® Xeon® Gold 6338 プロセッサーを搭載し、2.0GHz、ターボ速度 3.2GHz で動作します。各サーバーは、512GBメモリ、480GBブートドライブ、デュアル1.6TB P6410NVMeストレージモジュール、および1つの10G インテル® イーサネット・コントローラー XL710 NICで構成されていました。

• 標準 NIC に加えて、各サーバーは、インテル® Stratix® FPGAおよび インテル® Xeon® D システムオンチップ (SoC) に基づいて、デュアル 10/25G SFP28 ポートと PCIe 3.0 ホスト・インターフェイスを備えた 1 つの インテル IPU C5000X アダプターで構成されていました。図 7 を参照してください。

• 各 IPU は Napatech のリンク仮想化 4.3.3 ソフトウェアを実行し、Open vSwitch (OVS)、VirtIO サポート、ライブ・マイグレーション、VM 間ミラーリング、VLAN / VxLAN カプセル化 / カプセル化解除、Q-in-Q、RSS ロードバランシング、リンク・アグリゲーション、Quality of Service (QoS) などの機能を含む、オフロードおよび高速化された仮想化データプレーンを提供していました。