Egress Gateway のパフォーマンス調査

Egress Gateway の追加によるパフォーマンスへの影響を検証します。

2019年1月31日 | Jose Nativio (IBM) 著

この調査の主な目的は、外部サービス（この場合は MongoDB）にアクセスするためにサービスメッシュに Egress Gateway を追加した場合のパフォーマンスとリソース使用率への影響を特定することでした。外部 MongoDB 用の Egress Gateway を構成する手順は、ブログ外部 MongoDB サービスの利用で説明されています。

この調査で使用されたアプリケーションは、航空会社の予約システムをシミュレートした Acmeair の Java バージョンでした。このアプリケーションは Istio の毎日のビルドのパフォーマンステストで使用されていますが、その設定ではマイクロサービスは Egress Gateway を使用せずに、サイドカーを介して外部 MongoDB に直接アクセスしていました。

以下の図は、Acmeair と Istio を使用して現在パフォーマンステストがどのように実行されているかを示しています。

Acmeair benchmark in the Istio performance regression patrol environment
Istio のパフォーマンステスト環境における Acmeair ベンチマーク

もう 1 つの違いは、アプリケーションがプレーンな MongoDB プロトコルを使用して外部 DB と通信することです。今回の調査のために行った最初の変更は、より現実的なシナリオとして、アプリケーション内で実行されている MongoDB とそのクライアント間の TLS 通信を確立することでした。

メッシュから外部データベースにアクセスするためのいくつかのケースがテストされ、次に説明します。

Egress トラフィックのケース

ケース 1: サイドカーをバイパス

この場合、サイドカーはアプリケーションと外部 DB 間の通信を傍受しません。これは、MongoDB の CIDR を持つ init コンテナ引数 -x を設定することで実現され、これによりサイドカーはこの IP アドレスとの間のメッセージを無視します。例:

    - -x
    - "169.47.232.211/32"
Traffic to external MongoDB by-passing the sidecar
サイドカーをバイパスした外部 MongoDB へのトラフィック

ケース 2: サイドカー経由、サービスエントリを使用

これは、サイドカーがアプリケーションポッドに挿入されたときのデフォルト設定です。すべてのメッセージはサイドカーによって傍受され、外部サービスとの通信を含む、構成されたルールに従って宛先にルーティングされます。MongoDB はServiceEntryとして定義されました。

Sidecar intercepting traffic to external MongoDB
外部 MongoDB へのトラフィックを傍受するサイドカー

ケース 3: Egress Gateway

Egress Gateway と対応する宛先ルールおよび仮想サービスリソースは、MongoDB にアクセスするために定義されています。外部 DB との間を行き来するすべてのトラフィックは、Egress Gateway (Envoy) を通過します。

Introduction of the egress gateway to access MongoDB
MongoDB にアクセスするための Egress Gateway の導入

ケース 4: サイドカーと Egress Gateway 間の相互 TLS

この場合、サイドカーとゲートウェイの間にセキュリティの追加レイヤーがあるため、パフォーマンスへの影響が予想されます。

Enabling mutual TLS between sidecars and the egress gateway
サイドカーと Egress Gateway 間の相互 TLS の有効化

ケース 5: SNI プロキシを使用した Egress Gateway

このシナリオは、ワイルドカードドメインにアクセスするために別のプロキシが必要な場合を評価するために使用されます。これは、Envoy の現在の制限により必要になる場合があります。Nginx プロキシは、Egress Gateway ポッドにサイドカーとして作成されました。

Egress gateway with additional SNI Proxy
追加の SNI プロキシを使用した Egress Gateway

環境

結果

Jmeter は、HTTP リクエストを作成するクライアントの数を増やしながら、それぞれ 5 分間の実行シーケンスで構成されるワークロードを生成するために使用されました。使用されたクライアントの数は、1、5、10、20、30、40、50、および 60 でした。

スループット

以下のグラフは、さまざまなケースで得られたスループットを示しています。

Throughput obtained for the different cases
さまざまなケースで得られたスループット

ご覧のとおり、アプリケーションと外部 MongoDB の間にサイドカーと Egress Gateway を配置しても大きな影響はありませんが、相互 TLS を有効にして SNI プロキシを追加すると、スループットがそれぞれ約 10% および 24% 低下しました。

応答時間

トラフィックが 20 クライアントで駆動されているときに、異なるリクエストの平均応答時間が収集されました。以下のグラフは、各ケースの平均値、中央値、90%、95%、および 99% の平均値を示しています。

Response times obtained for the different configurations
さまざまな構成で得られた応答時間

同様に、最初の 3 つのケースでは応答時間に大きな違いはありませんが、相互 TLS と追加のプロキシにより、顕著な遅延が追加されます。

CPU 使用率

すべての Istio コンポーネントと、実行中のサイドカーの CPU 使用率が収集されました。公平な比較のために、Istio が使用した CPU は、特定の実行で得られたスループットで正規化されました。結果を次のグラフに示します。

CPU usage normalized by TPS
TPS で正規化された CPU 使用率

トランザクションあたりの CPU 消費量に関して、Istio は Egress Gateway + SNI プロキシの場合にのみ、大幅に多くの CPU を使用しました。

結論

この調査では、パフォーマンスを比較するために、TLS 対応の外部 MongoDB にアクセスするためのさまざまなオプションを試しました。Egress Gateway の導入は、パフォーマンスや意味のある追加の CPU 消費量に大きな影響を与えませんでした。サイドカーと Egress Gateway 間で相互 TLS を有効にする場合、またはワイルドカードドメインに追加の SNI プロキシを使用する場合にのみ、いくらかの低下が見られました。

この記事を共有する